Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Skip to content

Bliss Launcher holding partial wake lock for extended periods when a work profile is active, preventing deep sleep, degrading battery life

Summary

*update: This is only observed when a work profile is active

Bliss Launcher holding partial wake lock for extended periods as reported by BetterBatteryStats

BetterBatteryStats-2021-05-19_192825049.txt

The problem

Steps to reproduce

*update 0. setup work profile using https://f-droid.org/en/packages/net.typeblog.shelter/

  1. Weather widget is set up and is displaying weather information
  2. Custom location is set (however it shouldn't be the trigger, location based and custom location has similar code paths)
  3. Update interval is set to 30 minutes
  4. Reboot, start battery usage recording and lock phone
  5. A prolonged wake lock can also be observed with adb shell dumpsys power

What is the current behavior?

Locking the phone for an hour, in total Bliss Launcher could hold a partial wake lock for more than 50 minutes

What is the expected correct behavior?

The phone should be allowed to reach deep sleep instead of staying awake for a per 30 minutes weather widget update

Technical informations

Relevant logs (adb logcat)

https://gitlab.e.foundation/e/apps/BlissLauncher/-/blob/master/app/src/main/java/foundation/e/blisslauncher/core/utils/Constants.java#L23 bliss launcher has internal logs disabled, so there's only system log :(

05-19 19:26:27.029 I/Wakelock( 6697): Substraction Wakelock [m_wakeType=0, m_name=blisslauncher:WeatherUpdateService, m_duration=6122259, m_total=47126594000] from Wakelock [m_wakeType=0, m_name=blisslauncher:WeatherUpdateService, m_duration=9647172, m_total=50912718000]
05-19 19:26:27.029 I/Wakelock( 6697): Result: Wakelock [m_wakeType=0, m_name=blisslauncher:WeatherUpdateService, m_duration=3524913, m_total=3786124000]
...
05-19 19:28:08.728 I/Wakelock( 6697): Substraction Wakelock [m_wakeType=0, m_name=blisslauncher:WeatherUpdateService, m_duration=6122259, m_total=47126594000] from Wakelock [m_wakeType=0, m_name=blisslauncher:WeatherUpdateService, m_duration=9647172, m_total=51014430000]
05-19 19:28:08.728 I/Wakelock( 6697): Result: Wakelock [m_wakeType=0, m_name=blisslauncher:WeatherUpdateService, m_duration=3524913, m_total=3887836000]
...
05-19 19:28:23.764 I/Wakelock( 6697): Substraction Wakelock [m_wakeType=0, m_name=blisslauncher:WeatherUpdateService, m_duration=6122259, m_total=47126594000] from Wakelock [m_wakeType=0, m_name=blisslauncher:WeatherUpdateService, m_duration=9647172, m_total=51015891000]
05-19 19:28:23.764 I/Wakelock( 6697): Result: Wakelock [m_wakeType=0, m_name=blisslauncher:WeatherUpdateService, m_duration=3524913, m_total=3889297000]

logcat-2021-05-19_192825248.txt

Meanwhile it can definitely hold a partial wakelock for longer than 5 minutes even though a weather request should always be timed out in 5 minutes https://gitlab.e.foundation/e/apps/BlissLauncher/-/blob/master/app/src/apiOreo/java/foundation/e/blisslauncher/features/weather/WeatherUpdateService.java#L496 (referencing apiO since apiQ and v1.3.2 are not on the repo..?)

It seems to just hold it from Bliss Launcher start as long as it is not force stopped

~> adb shell dumpsys power | grep "Wake Locks:" -A 11
Wake Locks: size=2
  PARTIAL_WAKE_LOCK              'blisslauncher:WeatherUpdateService' ACQ=-37m32s604ms LONG (uid=10064 pid=29073)
  DOZE_WAKE_LOCK                 'DreamManagerService' ACQ=-10s553ms (uid=1000 pid=3782)

Suspend Blockers: size=4
  PowerManagerService.WakeLocks: ref count=1
  PowerManagerService.Display: ref count=0
  PowerManagerService.Broadcasts: ref count=0
  PowerManagerService.WirelessChargerDetector: ref count=0

Display Power: state=OFF

Relevant screenshots

Screenshot_20210519-192633_BBS

Solutions

Workaround

Under applications, Bliss Launcher, battery usage, enable Background restriction

Android will then suspend the dangling wake lock in 1 minute after locking image

Possible fixes

Can't tell if the weather request timeout was implemented correctly with logs disabled, my guess is a wake lock was taken for weather requests and was never timed out properly

Edited by Katharine Chui