-
released this
2026-09-12 15:47:27 +02:00 | 2 commits to main since this releaseSecond attempt at the weather/location battery drain. The first one (typing.8) keyed the skip
onWeatherSettingsData.managedLocation, which only exists once "managed location" has been
picked explicitly for the provider — so with an emptyweatherProviderSettingsthe guard never
fired and the worker kept requesting a location and retrying every 30 seconds.With a push-based weather provider (Breezy Weather), the worker only checked
autoLocationand
therefore requested a location even though the provider resolves its own.getWeatherData()is a
noop that always returnsnull, so the worker then returnedResult.retry()forever and never
setlastUpdate— which also meant the update interval check could never short-circuit it.Every attempt called
getLastKnownLocation(), which registers GPS and network listeners at a
one second interval and held them for up to ten minutes, so the location stack never idled. On
the device this showed up as ~46,000 delivered fixes,*location*wakelocks held ~99% of the
time, and Doze never engaging at all.- Add
WeatherProvider.isPushBasedand set it onBreezyWeatherProvider, so the check no longer
depends on any user setting. - Skip and cancel the weather work entirely for push-based providers.
- A managed location now takes the
WeatherLocationpath instead of the auto-location one, so
managed-location plugins still get their data without a location request. - Give up on a location fix after two minutes instead of ten.
LocationsRepository: don't collect the location flow when location search is off or not
permitted. As acombineTransformargument it was always collected, so every search query
registered GPS and network listeners for up to 30 seconds.
Downloads
- Add