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 )
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
Subtickets
Change History (5)
comment:1 Changed 4 months ago by
Description: | modified (diff) |
---|---|
Priority: | minor → major |
Summary: | Repeated battery optimization dialogs → Repeated battery optimization dialogs Android 10 |
comment:2 Changed 4 months ago by
comment:3 Changed 4 months ago by
Probably related to this issue: https://issuetracker.google.com/issues/37067894(Closed wontfix by Google at that link, re-opened here: https://issuetracker.google.com/issues/37069376) 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.
comment:4 Changed 4 months ago by
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.
comment:5 Changed 4 months ago by
Owner: | changed from Meeh to idk |
---|---|
Status: | new → assigned |
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.