Hacker News Reader

Comment by Zanfa | Hacker News Reader

There's a good reason to not allow 3rd party background networking though. It would work in theory, but in practice every company with more than a few devs would eventually implement their own crappy version of a notification system with terrible power management. Given that even well-funded companies like Uber/Facebook have constant engineering quality issues, I definitely wouldn't want to have 20+ separate active notification connections.

This is not even hypothetical, this was literally happening before background services were heavily limited in earlier Android versions.

View on HN

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.

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

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.

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.

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.

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.

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.

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

They are totally not, because whenever you need an app do something, like, display a message sent to you, the 'official' way is to do it via push notifications. But if your user doesn't use Google Play services, you have to make the app run in the background, which is increasingly difficult in Android (and impossible in iOS).

Hypothetically, an Android vendor could build a notification service separate from Play Services and deploy it on their Android builds. Has to be a vendor (or, more broadly: "someone who controls the OS down to the kernel level") because the notification technology involves some heavy abstraction-breaking footsie between the physical link layer and the TCP stack.

But the two big challenges there are:

- odds are the first several iterations of it will suck, so they'll be competing with an already-working solution that most users have no concerns using (significant market uphill fight, with the only major value-add being "We're not Google").

- we've just traded one master for another. Ultimately, unless someone builds an open-standard at the Android distro level that includes an API to allow users to establish a notification source, the distro owner still owns the notification system (and there's no reason a priori to assume they're less evil than Google). And designing that API to be abuse-proof would be a challenge; do it wrong, and we're back to the bad old days of sub-one-day battery life on an idle phone.

It'd be a hell of a cool project for someone to take on though.

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

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

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.

In terms of screen-on-time (for comparable tasks like web browsing) they are pretty close to modern phones..

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

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.

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

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.

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.

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

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.

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 'username@notification.provider.com' (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).

Corollary: notifications should be a public service whose only purpose would be to maintain that TCP connection and have a server as a broker, with clear control given to the user over which app can use said service and be allowed to wakeup their device.

So almost literally how iOS and Android notifications work except I guess jointly owned and operated by by Google and Apple? Because public services like this are necessarily funded and operated by the companies that have a financial interest in them existing.

Not really: you can't use the service alone, without any other software. The software is not open source. And finally, the user has no control over which apps/services can send them a notification (or really, a device wakeup) at a given moment.

Those are downsides in many situations but the existing systems match your original description perfectly, unless "public" has a special description you didn't communicate.

The current situation means I can't even use my own push notifications for company owned devices running company written software. That's just ridiculous.

You could always run a custom Android build on company devices.

Sure, and by installing that custom build, you lose support and void warranty from your device provider.

That, and even worse maintaining a custom build with changes and the infrastructure such as maintaining a OTA update server, etc. is a lot of work.

Reply on news.ycombinator.com