undefined | Better HN

0 pointsizacus4y ago0 comments

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

0 comments

Andrew_nenakhov4y ago

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.

izacusOP4y ago

> 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_nenakhov4y ago

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.

dtech4y ago

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

1 more reply

thebean114y ago

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_nenakhov4y ago

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.

izacusOP4y ago

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

1 more reply

thebean114y ago

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.

1 more reply

j / k navigate · click thread line to collapse

0 comments

Andrew_nenakhov4y ago

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

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

izacusOP4y ago

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

Andrew_nenakhov4y ago

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

dtech4y ago

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

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

1 more reply

thebean114y ago

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_nenakhov4y ago

izacusOP4y ago

1 more reply

thebean114y ago

1 more reply

j / k navigate · click thread line to collapse