Hell there are comments in this thread testifying that these built-in "battery savers" even kill the built-in alarm application.
is this a bug that sometimes happens? how rare is it?
Alarm scheduled wakeups get rounded to a minute in power saving mode though.
You using Ubuntu so you’re fine with wasting time setting up stuff that’s just supposed to work, but most users are not
Case in point:
https://androidcentral.com/blocking-huawei-phones-downloadin...
I have a galaxy S9 but there should be the same or similar setting on yours.
I think the problem is, that many users do not know which apps require more energy due to the specific problem they solve and which apps are just badly engineered. So to let the user decide every case is a bad option (+ decision fatigue). Letting the developers decide is even worse, as they would simply say, that their app requires as much energy as they need. So the vendor thinks he has to make that decision (as they don't want their phone to being perceived as having a bad battery life), who neither knows anything about the specific app nor about the use-case (probably the worst option).
I think the system should simply report battery offenders (above the threshold of a well-engineered instant messaging app for example) to the user in a manner of 'App X used Y% of your battery in the last 24 hours. By limiting the battery usage, the app might not function as it is supposed to be. Do you want to limit the battery usage of this app?'
That way, most developers would have a chance to build good apps which do not get reported and users would stay in control.
I am pretty sure that my stock Android 8 is doing that already
- Skype - always killed
- Slack - always killed
- Whatsapp - sometimes killed, rarely
- Telegram - never killed
- FB Messenger - never killed
All these are fully featured apps with tons of different functionality.
Telegram and FBM never ever trigger "this app is draining your battery" while Skype triggers it regularly when I sometimes start it on phone.
I'm going to generalize and say that probably some apps are simple bad and need to be fixed instead of granting them exceptions and allowing to be battery hogs.
Though they were moving away from that model to a model where apps alive for more than a certain time interval in background were killed. So apps which you use the most heavily are more likely to be penalized.
This isn't climate change debate, it's easy to check.
If you aren't facing issues then these apps are probably already a part of the whitelist on your device.
The system you’re saying “evolved out of the manufacturers”, runtime permission requests, is from “core Android” all they way back at 6.0
And the problem has almost never been users blindly revoking permissions, it’s blindly granting permissions.
The problem the parent comment mention isn’t the method of asking for permission, it’s the fact there literally is not a permission.
And Android already has built in “active” battery management with Doze, if anything manufacturers are ruining it with poorly coded “optimizers” that do dumb things like kill their own alarm apps...
And even if Android did add a permission to allow an app to do whatever it wants in the background and kill the battery as much as it wants, manufacturers can’t be bothered to write optimizers that don’t kill a music playing app while the user listens to music, why would they bother respecting a permission they didn’t make?
If I wasn't clear, this is what I meant. Users ignore and accept permissions blindly on install.
> if Android did add a permission to allow an app to do whatever it wants
I'm not suggesting this at all. I'm suggesting that permissions systems, as granulated as they are, only make sense to developers and are mostly ignored by users.
> The problem the parent comment mention isn’t the method of asking for permission, it’s the fact there literally is not a permission.
I agree with the parent comment on this. Some permissions queries should be available on first use, rather than (or in addition to) on install.
This sounds like it should be an app permission: is this app allowed to run in the background or not?
There is a quite clear usage pattern to support this behaviour: unless I explicitly say so, I don't want apps on their own to "do stuff" no more than I want my Ubuntu to "do stuff" while I'm doing something else. I only want the application to respond when I'm viewing it.
On Ubuntu, I always disable stuff like evolution server and automatic indexing after a fresh installation. At least you can do that on Ubuntu, that isn't necessarily always possible on locked-down systems. I'm happy that Android is quite usable these days because of Doze and background task killing.