Closed Alexander-- closed 5 years ago
Events were unreliable, that's why I did it.
@adolfintel sorry for nagging you, but could you explain in greater detail? The git history of project is short and does not have any traces of using startForeground, so I don't understand what things you did and why.
Have you actually tried using startForeground? What do you mean by events being unreliable? All of them or just specific subset?
Was the Service promoted to foreground when the problematic events (broadcasts?) didn't arrive?
If you look at the history, you'll see that I published the app in a mostly complete state, you won't see the various tests I did before publishing it.
Basically, doze is the worst thing that ever happened to android. It makes everything that needs to stay in background unreliable as hell. In theory, services should be able to receive events even if they get dozed, but if you look at the documentation, it says that even if the event is delivered, there is no guarantee that any code to manage it will be executed. It may be delayed for an unknown amount of time. So the problem was that when the screen had been off for a while, the service would get dozed, and when connecting airpods, it sometimes would not respond to the bluetooth event.
So if I have to choose between asking the user to disable doze or have an unreliable app, the choice is obvious for me. Fuck doze.
If you want to try and implement it, go ahead, just keep in mind that different roms handle doze differently (for instance, huawei is extremely aggressive). I did my testing on lineage 16.
Foreground Services aren't affected by Doze. You are already showing a semi-persistent notification, so there is there reason to ask user for Doze exception instead of going foreground.