[Andrew_nenakhov]

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.

With current notched phones which are limited to 4 notifications (you get four and a dot if there are more), you can have VPN app, XMPP client, Syncthing, and a generous space for one more incoming notification.

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

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

[Zanfa]

Again, in a world of spherical cows this could work, but in reality it didn't.

I was an Android dev pre-5.0 and believe me, having lived through the s*tshow that was push notifications at the time, there's no way it would've worked any other way. Google's own SDKs were garbage and as with everything else they kept releasing new incompatible rebranded versions annually. Last I checked, the Firebase console for managing push notification subscriptions was still one of the worst SPAs I've come across.

You'd expect a thriving ecosystem of dedicated push notification providers to pop up and outcompete Google, but all of the 3rd party offerings were even worse, in terms of battery life, UX, reliability and even pricing.

It's unfortunate, but no developer cares about your battery life, because no user is going to switch away from using their app solely because of crappy power usage, so Google had to do exactly what they did.

Maybe in a decade or two, with new battery technologies, there won't be a physical limitation and this situation would play out differently.

[Andrew_nenakhov]

> I was an Android dev pre-5.0

I was in Android dev since pre 2.0, developing an app which need to constantly run. The situation got worse since then, not better.

A thriving ecosystem of dedicated push notifications can't pop up because you can't go to Android settings and choose another push notifications provider. You have to rely on ugly crutches to even receive a push notification, and that is why they are 'even worse'.

[joshuamorton]

Can you explain how this would work, does this mean that every app needs to push all notifications to all PN servers? Like there's the Google one and a theoretical Samsung one, my app has to send all push notifications to both, right, since I don't know a priori which provider you use, and if it's a global setting all apps need to use the same one.

So you either need every app developer to maintain the list of all push providers or someone, presumably Google, to maintain the canonical list and the thing that manages sending them to all the push providers.

Oh and then there's the associated suite of privacy issues. Do you really want every push notification prouder to get even metadata about all of your push notifications?

So this can't be a global setting. Instead it has to be a per-app setting where like the app provider needs to register a callback to update the notification server and support that in app. Of course most won't.

[curryst]

Why on Earth wouldn't you just make it a setting on the phone and expose that to apps? Have the apps read it on startup, and save it as part of the user profile server side. It basically becomes an email address.

> So this can't be a global setting. Instead it has to be a per-app setting where like the app provider needs to register a callback to update the notification server and support that in app. Of course most won't.

They seem to do fine with email addresses. Again, I don't see why '[e-mail]' (or an alternative with auth embedded) would be absurdly hard for developers. Someone will write a 'SendPushNotification' function that parses out the domain to send it to and the auth to use and send it, just like we've done with email since forever.

Google will likely know where you're sending your notifications, but they won't manage sending them (though they could probably scrape the contents since they own the OS).