[izacus]

> The only thing you really need is an easily accessible tool to explicitly view which apps are allowed to run in the background. This doesn't have to occupy valuable notification area space.

Those tools existed and they didn't help because users had no recurse against poorly behaving apps. Meanwhile Android kept being reamed by reviewers and media for poor battery life and people kept buying locked-down iPhones instead because they lasted longer.

I spent countless of hours trying to get Android devs to not do dumbass things with battery ("oh, I need updates? I''ll just poll the server every 20 minutes and ruin the users battery in hours. Easier than long polling!") and in the end the situation didn't improve until Google stepped on the devs neck and forced them to use GCM/FCM and started actively powering down radio without apps input.

[Andrew_nenakhov]

Oh, so because of (some) dumb users let's punish everyone by making them subject to a monopoly lock-in. Great reasoning.

Users have very effective recurse against poorly behaving apps: uninstall. You just need to inform users that the app X does use much battery. Then it should be up to the users to decide if to allow this behaviour or uninstall this app. Maybe an explicit permission to run in the background. That's it.

Solution that you like is also very beneficial for OS vendor, how convenient.

[izacus]

> Oh, so because of (some) dumb users let's punish everyone by making them subject to a monopoly lock-in. Great reasoning.

In your reasoning, "most" users would be done and "most" apps would be malicious.

But in the end, it's quite simple - dealing with power use on mobile is hard and most developers don't care (same as they don't give a crap about making your web pages fast and slim). Users care about battery life above most of other features, including your freedom. They WILL got and buy a device that lasts the longer amount of time in the smallest and lightest package.

As long as these two things are true, leaving developers to run their polling code without restrictions has a massive effect on sales of both OEM devices and Android ecosystem as a whole. As such, OEMs are actively modifying Android to not allow this - see the wonderfully depressing https://dontkillmyapp.com/ - which is a significantly worse mess than you having to use a proprietary service to send a single device wakeup ping.

[Andrew_nenakhov]

If users care about battery life, give them tools to analyse what's eating it, but handcuff it so they don't hurt themselves. That way users who care about freedom will have it, and users who care about battery life above all will just block the permission to run in the background.

But that doesn't align with Google's interests, so it will never happen, unless they are forced to.

[dtech]

You severely overestimate what the user will do. Android has these tools built-in, but they are hardly used.

It's similar to how crappy drivers causing BSODs were for a large part responsible for the "Windows is a crappy unstable mess" sentiment of the late 90's and 00's [1]. This led to Microsoft severely restricting driver manufacturers, requiring signing and WHQL etc. Less freedom but stability and perception among users has markedly improved.

[1] https://www.zdnet.com/article/why-the-blue-screen-of-death-n...

[Andrew_nenakhov]

Users are perfectly capable of using battery stats and determine which apps consume too much power, and then make an informed decision. This is not some rocket science.

[thebean11]

Every single app that uses notifications needing to run in the background is not a scalable solution..

Even correctly behaving apps will consume much more power and network with this scheme.

[Andrew_nenakhov]

Imagine. Your macOS suddenly decudes that you don't need a web server running on your macbook, so it randomly kills it to free resources for your browser. Would you be happy with this level of care shown by the manufacturer?

It is not up to the OS to decide which apps the user needs running. Be it wifi scanner, vpn or some file sync process. All the user needs is a correct tool to know which app consumes what, and then there User must decide. Not some prick in google or xiaomi or samsung or whoever else.

[izacus]

> Imagine. Your macOS suddenly decudes that you don't need a web server running on your macbook, so it randomly kills it to free resources for your browser. Would you be happy with this level of care shown by the manufacturer?

Your macOS has an unacceptable battery life already despite having a massive 58WHr battery - about 3.5x the size of a normal phone battery. Phone users don't want to lug that size of a battery around just to get battery life that's worse than they get right now from a 15WHr one.

[thebean11]

> Your macOS has an unacceptable battery life already

Heh, not true anymore with the new M1 lineup. I was skeptical but they are insanely efficient.

[izacus]

Noone will buy a mobile phone with a battery life of a M1 lineup laptop. Pixel 4 got trashed on reviews for having the double battery life of those.

[thebean11]

I’m not saying apps shouldn’t be allowed to run in the background. But for notifications specifically it’s an unacceptable solution. It just doesn’t scale to the number of apps the average user receives notifications from.

[Andrew_nenakhov]

Nobody was saying that every app needs to run in the background to deliver you notifications. I was arguing that for some apps background functionality is essential, and such functionality is obstructed by OS vendors, who strive to tie all background work to push notifications.

[thebean11]

Sure, I agree with you there, but background app permissions and push notifications seem like pretty separate issues.