Opened 4 months ago

Last modified 4 months ago

#2783 assigned defect

Repeated battery optimization dialogs Android 10

Reported by: zzz Owned by: idk
Priority: major Milestone: undecided
Component: apps/android Version: 0.9.47
Keywords: Cc: idk
Parent Tickets: Sensitive: no

Description (last modified by zzz)

Android 10
Answer the 'manage battery optimizations?' dialog, click yes
Click power button to turn off screen
Click power button to turn on screen, dialog appears again
happens every time


Change History (5)

comment:1 Changed 4 months ago by zzz

Description: modified (diff)
Priority: minormajor
Summary: Repeated battery optimization dialogsRepeated battery optimization dialogs Android 10

comment:2 Changed 4 months ago by idk

Not happening on the emulator for me, I'm going to see if updating Android Studio and/or using a new VM makes it happen, otherwise I'll have to go grab some Android 10 hardware. I'll be able to do it tomorrow. I don't *think* it could be that they locked down the power management permission so you can't do the workaround, or else I think it would break in the emulator too.

I think the worst-case scenario would be if it comes down to the power management permission workaround being disabled. If they did, then the answer will be to use the real permission interstitial that Google likes to lock down, and ask for permission to use it. We have lots of documentation that we "need" it per their criteria, but the decision will end up being up to them(Google). If they don't grant it, all is not necessarily lost, but it does mean we lose Google Play as a release channel. F-Droid has no such restriction, and obviously we can self-host whatever we want.

I'll dig into it, should know more soon.

comment:3 Changed 4 months ago by idk

Probably related to this issue: wontfix by Google at that link, re-opened here: looking for a workaround for the workaround

I suppose the obvious thing to do if we cannot reliably have insight into whether the permission is granted, is to store whether or not the user has *attempted* to set the battery optimizations to ignored, i.e. tapped yes on the dialog box, ourselves. We would have to assume that if they did so, whatever action they took after that we cannot have insight into they did intentionally, regardless of whether ignore battery optimizations was actually set or not. They either intentionally did or intentionally did not set the battery optimization. I don't think that's terrible.

What actually is a big pain is that it does not account for the uninstall-reinstall issue, where permissions are read as enabled but in actuality, they are disabled and were disabled when the app was uninstalled, but they still show as enabled.

Last edited 4 months ago by idk (previous) (diff)

comment:4 Changed 4 months ago by idk

Checked in a workaround at 854dac7ca846c3b2111266bb4945751f04478762 I am testing it still, but it should fix the surface problem of the repeated interstitial by always setting the "No, I do not care to set the battery optimizations" preference in our app no matter what the user does after attempting battery optimizations, and regardless of whether it works or not. Effectively it's now a "Have we asked the user to disable battery optimizations" preference. This is not the same as reading whether the battery optimizations are disabled or not from the API, and it means the app doesn't know if battery optimizations apply or not, it only knows if it has asked.

I suppose we might be able to watch for it to be killed by the battery optimizations, and store whether that occurs in a preference somewhere as well. Not sure it would be worth it but it would be a way to tell for ourselves whether battery optimizations are killing the app.

Last edited 4 months ago by idk (previous) (diff)

comment:5 Changed 4 months ago by idk

Owner: changed from Meeh to idk
Status: newassigned
Note: See TracTickets for help on using tickets.