The flip side of this is that there were a lot a badly behaving apps, sitting in the background without a user requirement that would justify that, eating battery and network. Hence nearly all Android phone manufacturers bundling some kind of background app killer.
The correct solution here would have been a system-level, open source, provider-agnostic push notification API built into AOSP. The Web Push API is a great example of how a push API can be provider-agnostic: https://developer.mozilla.org/en-US/docs/Web/API/Push_API. It makes sense that push notifications should be consolidated to one provider -- this way, your device only needs to maintain one 24/7 TCP connection to a server which it receives all notifications from all apps through, rather than having each app run its own notification service in the background, killing your data and battery life.
Google's push service works by providing an HTTP endpoint to apps that they can use on the backend to deliver notifications. The Web Push API also works this way, but the returned endpoint can be for any provider. If you use Chrome, the domain will be `google.com`, but on Firefox, it's `mozilla.org`. But each provider's endpoint uses the same standardized API, so the backend doesn't have to care what the URL is. And this isn't a security risk, because everything sent through the service is encrypted.
This could have been done for Android, but that would have given Google much less control over the platform, so they decided to do it in a monopolistic way. This is one of the many ways Google aims to maintain their monopolistic control over "open source" Android. Another example is SafetyNet hardware-backed attestation.
Projects like GrapheneOS are really interesting because they are finally providing a real secure, private, de-Googled OS option, with excellent app compatibility thanks to sandboxed Play Services (which allows you to run Play Services without giving it root access to your device [1]). But will we ever be able to fully decouple Google from Android? I'm not sure. I expect most users of custom ROMs to continue installing Play Services on top of them for a long time, if they want something as basic as push notifications to work.
By the way, while I personally have qualms with Google, I believe users should have the choice to use Google apps, if they are comfortable with the inherit privacy risks. This belief is shared by the GrapheneOS developers. [2] My problem with Android is that it was not built to function without Play Services. Community projects that enable it to do so, like microG, will always be a cat-and-mouse game with Google. I think sandboxed Play Services is the most sane approach the problem of Play dependencies the community has come up with so far, but I think if we want real change to happen, we need to target app developers. Each developer has the choice of whether to include Google or not within their app. We just need to convince them that they don't need Google.
Google owns `developer.android.com` and points developers towards using Play Services APIs wherever possible. Perhaps the community should create their own open-source alternatives to the most commonly used APIs (e.g. push notifications) and developer documentation that provides instructions on how to switch from Google (ideally making the transition as easy as possible by emulating the Google API syntax). It would probably be possible to offer an installable platform-agnostic push notification API that developers can use. Providers could be installed as separate apps. Google could be one such provider. Perhaps we could implement a Web Push compatible API, and reverse engineer Chrome's Firebase integration to implement it as an option from the get-go, hoping other providers show up over time. We could perhaps allow users to self-host their push service as well. Modify Gotify, an open source self-hosted push server [3], to accept push notifications in the Web Push format.
In the hacker circles it seems there's two groups of people: those who think Android is a lost cause because it will always be controlled by Google, and think Linux phones are the only real alternative, and those who believe we can actually "steal" Android back from Google and make it into a true open source project. I fall into the latter, but I think a lot more work still needs to be done if we want to achieve this.
[1] https://grapheneos.org/usage#sandboxed-play-services
[2] https://grapheneos.org/features#features
> We aren't against users using Google services but it doesn't belong integrated into the OS in an invasive way. GrapheneOS won't take the shortcut of simply bundling a very incomplete and poorly secured third party reimplementation of Google services into the OS. That wouldn't ever be something users could rely upon. It will also always be chasing a moving target while offering poorer security than the real thing if the focus is on simply getting things working without great care for doing it robustly and securely.
Push services are a bit more convenient in that they require less infrastructure both in the server-side as well as client programs (e.g. they can even be shut down and still receive messages), but nothing really prevents having an ecosystem of multiple competing push services.
> Many platforms before Apple/Google worked like this
Mobile devices are an entirely different beast with strict battery life and data usage requirements.
Another factor to consider is that Android will kill long-running background apps unless you disable battery optimization for said apps through a convoluted process (even if you show a persistent notification). [1] It would be really inconvenient for users to have to manually disable battery optimization for every app that wants to send push notifications.
[1] https://github.com/gotify/android#disable-battery-optimizati...
If by notifications you are referring to Firebase Cloud Messaging, which replaced Google Cloud Messaging and is now integrated in Google Play Services, I do agree with you.
It is my opinion that Google should be forced to decouple all these Google Play Services which are not related to the "Online App-Store" which Google Play is, and ideally be forced to open source it, so that trustworthy alternatives can be used to replace it.
I mean all the components which track you, which basically is what Google Play Services is: it is a system service created to monitor every possible activity you have with your phone (location, physical activity, health) as well as the efficient, persistent data connection to transfer these bits of information to Google (and to your device as FCM), while Google grants you access to use these services in a restricted manner.
For me Amazon's Android devices are basically useless since they don't have Google Play Services installed, and you have to work around it to get it installed, which basically is illegal to do.
Without the problem for YOU, because, presumably, you have a non-shitty phone. It is a much more severe issue on the likes of Samsung / Xiaomi / Huawei. See https://dontkillmyapp.com
And if you force Google to stop verifying proper behaviour in CTS, do you expect those manufacturers to allow you to run background services at will?
They already kill off anything that's not whitelisted to keep those battery numbers up. The every new major OEM release we developers find bunch of new ways the try and kill background apps.
If you think people talk about AOSP when they talk about Android, you are always going to miss the point of these conversations.
> Unfortunately, vendors (e.g. Xiaomi, Huawei, OnePlus or even Samsung…) did not seem to catch that ball and they all have their own battery savers, usually very poorly written, saving battery only superficially, with side effects.
My apologies to NGRhodes, the link does indeed refer to an issue with OEM and not what Google supplies. I don’t really see what it has to do with the topic we were discussing however.
Also, such apps are unloaded from time to time even on stock non-modified Androids.
This is not even hypothetical, this was literally happening before background services were heavily limited in earlier Android versions.
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.
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.
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.
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.
But that doesn't align with Google's interests, so it will never happen, unless they are forced to.
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...
Even correctly behaving apps will consume much more power and network with this scheme.
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.
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.
Heh, not true anymore with the new M1 lineup. I was skeptical but they are insanely efficient.
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.
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 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'.
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.
> 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 '[email protected]' (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).
Even if you want users to give indication of something running in background there are far less intrusive ways to achieve that. But if you can't come up with those ways and persistent notification is the best you could come up with then at least give the user the ability to turn it off without turning off background process?
They know the tendency of people to clear notifications as they clutter the phone and they use this small knowledge to push their own Software. At least follow same practice for Google apps but no because then that notification area would be complete mess.
This was absolutely terrible for battery life, though. Accidentally leave the IRC client open in the background? There goes your battery. There are non-nefarious reasons why smartphones work they way they do nowadays.
I still think my Sony Ericson p910i the best smartphone. Multiple human interfaces (the multi directional wheel is the greatest invention to be abandoned) in particular and a near fully functional OS that could do anything my computer could do
"My Android phone just died at 1pm with empty battery, I don't know why! I'm buying an iPhone!" complaints are something noone from the Android side of the market wants to continue hearing. Even if that means that you now need to have a notfication clearly telling you your battery is being drained.
As far as I know, Android still allows background applications though. The only constraint is that you have to show a persistent notification (that the user can hide). IM clients like Conversations.im will attest to that.
(iOS does not -- and thus creating a real Jabber client that does not depend on push notifications is impossible)
Such solutions are what I referred to as 'the best alternative'. No, thanks, it's not even close to the real deal.
The OS is designed in such way requires push notifications built into its core to work properly.
Apps are subject to power and resource restrictions, but the user can easily lift those restrictions manually for certain apps, like UP Distributor. If the app is implemented properly, it will work just as well as Google's push service.
> The OS is designed in such way requires push notifications built into its core to work properly.
Notifications are built into the OS. A network-based push notification service is not part of the OS. It is false to say that (a particular implementation of) network-based push notifications have to be "built into the OS' core to work properly."
Specifically with regards to notifications the main things I care about are instant messaging apps (WhatsApp, Telegram, Signal and Element) and email notifications. All of these apps fall back to either their own implementation of a persistent connection or use the OS' APIs for background job scheduling and polling. In my experience, having a handful of persistent background connections does not significantly impact battery life (<5%/charge). Also, modern Android has Doze[1] mode. Unless an app is granted a battery optimization exception, its scheduled tasks (polling) will run within a brief period every N minutes, where N depends on how long the device has been inactive. This is what I want in most cases. I personally only give IM apps a battery optimization exception. Notifications from other apps are usually less urgent/important.
However if you want the convenience of having a single connection for all your notification delivery, GrapheneOS[2] (an AOSP-based OS with many security and privacy improvements) has a compatibility layer for Google Play services[3] that allows it to be run with non-system privileges (i.e. the same as every app the user installs). That means you can choose exactly which permissions are granted to it. For example, you can revoke all permissions except Network[4]. This lets you use Google's FCM service without Google knowing anything about you except your IP address (and the contents of your notifications).
Using Google as the notifications middleman is an ugly crutch though[5], but this setup is solid. This is only necessary because they have convinced Android developers to use their APIs, but alternatives can and do exist. I think UnifiedPush[6] is going in the right direction, but they haven't gained much traction yet.
[1] https://source.android.com/devices/tech/power/platform_mgmt
[3] https://grapheneos.org/usage#sandboxed-play-services
[4] https://grapheneos.org/features (ctrl-f Network permission toggle)
[5] similar to using Apple as the notifications middleman, although the incentives are slightly different
So modify the OS… it’s open.
If it were that easy as an overall solution, non-OEM Android forks would be mainstream. They're not. I hardly know any people using non-OEM Android.
The Android OS is intentionally crippled to work only with Google Play push notifications, and there are no 'stock' ways to use an alternative without modifying the OS. The best alternative is to do it via persistently running app, which is less reliable and bad for UX.
This notifications problem also applies to iOS: even if users will be eventually allowed to install apps bypassing the AppStore, these apps would just sit idly until opened by a user, which is unacceptable for a very wide range of communication apps.
However, there is a difference with Android: iOS was crippled from the start, but first iterations of Android were relatively open, apps could run in the background without much issues. But then Google started tightening the grip, so Android now closely resembles iOS in this regard.