Hacker News Reader

Comment by yason | Hacker News Reader

Killing apps is a good thing. There have been battery saver programs since the very beginning of early Android versions to kill of connectivity and clean up running apps. When Android now supports some of that natively and vendors too, even more aggressively, this is just responding to users' needs.

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.

View on HN

Did you even bother reading the complaints? These "background killers" kill background applications the user wants to run and has specifically asked for e.g. alarms, health/fitness trackers, …, usually in the most harmful way possible (e.g. straight kill -9) meaning the application can't even tell the user what the issue is, and with complex steps users have to take (possibly repeatedly) to whitelist specific applications.

Hell there are comments in this thread testifying that these built-in "battery savers" even kill the built-in alarm application.

been using android since forever. Now I'm on a s8+. I never had a case like this. maybe I didn't noticed it. But my alarm always went on like it should. my music always played.

is this a bug that sometimes happens? how rare is it?

S8 has this, but can be opted out (plus it has what I assume is a whitelist of pre-approved apps, but even those can be opted in, IIRC). It's clumsy, but sort-of works. It does break some old apps that rely on scheduled wakeups, though :(

Also the Samsung variant will not kill the app or service that is showing a notification as it should. So the three problem is limited to apps relying on dumb running in background.

Alarm scheduled wakeups get rounded to a minute in power saving mode though.

Seems it's mainly an issue with Nokia devices, the other manufacturers were minor problems in comparisons.

It is not a good thing to kill an alarm app then purposely ignore its registered alarms, or killing a media player the user wants to listen to in the background.

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 mean sure, but at least give me a way to override it. On my OnePlus 5T running Android Pie, the system will keep killing my VPN client when in sleep mode, even though I have selected that I don't want to optimize it under battery usage. With the VPN client restricting all unprotected access, it means that once the phone goes into sleep, I stop getting all notifications for anything because there is no internet connection. It's very frustrating.

Try selecting 'Lock' for the VPN App from the recent apps section (top right)[1]

[1]:https://imgur.com/Bk8jXbJ

Hmmm, I had no idea this was a thing. Will give it a try!

I use NetGuard on 5T, which is using VPN API, and that seems to stay alive. That with battery optimization off for it and with its own watchdog option enabled. I think I had it dying without watchdog though.

On my phone, if I go to the apps list>tap app I want to run in the background (VPN app for example)>battery>allow background usage.

I have a galaxy S9 but there should be the same or similar setting on yours.

It's exactly the same thing he's talking about. The issue here (I also own a OnePlus 5T) is that OnePlus' implementation of memory saving is too agressive and often ignores user configs.

Actually, I think it depends on the use-case. I mean, there are some use-cases which are inherently battery intensive. Like accurate position tracking or receiving real-time messages.

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.

> in a manner of 'App X used Y% of your battery in the last 24 hours.

I am pretty sure that my stock Android 8 is doing that already

Killing background tasks is great and Android does that automatically to save battery usage. But these manufacturers have implemented their own functionality on top of Android which cripples even critical messaging applications like WhatsApp, Slack, Gmail by not delivering Instant Messages notifications instantly.

Just as an example, only chat/messenger apps on my Oneplus with saver enabled (default):

- 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.

Those apps are explicitly whitelisted by OnePlus. There's nothing to "fix" they're by the app developer, because the killing algorithm chooses based on app name, not app battery consumption. Facebook can kill your whole battery and you'll never get a warning.

So you are saying that behind visible list of apps that are either "optimized" or excluded there is another hidden list where app that is "optimized" could be actually excluded? Ok, that can be a working hypothesis. Why is Skype not excluded the same way then? Or Slack? Millions use them and MS surely has money to promote their app this way. Why Whatsapp is not excluded? It's owned by FB.

There used to be a hidden list. I was the head of android dev for flock , a team messenger and we had gotten in touch with OnePlus who added us to the whitelist. More details here : https://hackernoon.com/notifications-in-android-are-horribly...

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.

Interesting information. I'm not doubting you here but want to clarify one thing, to understand. After you contacted Oneplus and were added to whitelist, do you still see that your app is showing as "optimized" in the settings but app behavior changed and it is no longer killed in background? And that same is applicable to other major software?

I don't know why it's not there, I'm not an exec in those companies. I know for sure that OnePlus, Huawei and Xiaomi have such whitelists. Other OEMs might have them as well.

This isn't climate change debate, it's easy to check.

I've had a Nokia 6.1 on Pie, apparently the worst-case scenario for this, for a few months. The third-party optimiser is running, and I haven't problems with Slack or Jabber clients. How are people reproducing this behaviour?

I have a OnePlus 6 and none of the apps you've just mentioned fail to receive notifications when my phone is asleep.

It does happen on oneplus devices and it's quite common to find complaints on oneplus forums like : https://bit.ly/2VSkhty . In all cases it is solved by adding these apps to the whitelist.

If you aren't facing issues then these apps are probably already a part of the whitelist on your device.

Auto-killing apps to save battery is obviously good - nobody is contesting that. The bad thing that is being highlighted here is that there's no user friendly way for app developers to request additional privileges from the user.

If you're looking for user friendly ways to request privileges, that solution should really be offered by core android in a way that works for manufacturers and users and probably won't appease all developers. App permissions systems have been a nightmare for users from the start so you can't expect users to learn a newly revamped permissions system. They'll just continue to ignore permissions on install and complained when their phones aren't working the way they expected. What's evolving out of the manufacturers is a simplified system that requires explicit permissions from the user after installation to enable problematic privileges and active governance to manage battery/data hogs.

What?

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?

> And the problem has almost never been users blindly revoking permissions, it’s blindly granting permissions.

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.

we would end in the same place where we are now, apps would nag and require that we put them on the whitelist, I have a huawei mate 20 pro, the biggest reason thah I like this phone is the battery life. it has a huge battery and with agresive management I can go with 50% from morning till evening. there are only couple of apps in my whitelist. everything else its free to manage for me automatically. before that on my nexus device I got annoying notifications from my smart watch watchface app, that was using notifications for promotions and such.

Killing apps that the user isn't using or relying on is a good thing. Randomly killing apps running in the background is a bad thing.

This sounds like it should be an app permission: is this app allowed to run in the background or not?

LG even lets you pin apps you don't want auto-killed which is useful but I rarely use it since I kill them manually before it gets to do it for me, I didn't realize this was an issue on other phones. I guess that's why LG is technically not on this list? I've always thought it was a stock Android feature.

Reply on news.ycombinator.com