11 ms·

Remember, people: the real lock-in with Android is not the Google Play. It is the push notification services that are bundled with it. The Android OS is intent

Remember, people: the real lock-in with Android is not the Google Play. It is the push notification services that are bundled with it. 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.

anthropodie 5y ago
That persistent notification for application running in background is the worst. Back in the day, applications on Symbian devices could run in background without any indication. Some would argue that's a risk but then we have been using our PCs like that since forever. 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.
- easytiger 5y ago
  > Back in the day, applications on Symbian devices could run in background without any indication. Someone would argue that's a risk but then we have been using our PCs like that since forever. 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
- endless1234 5y ago
  > Back in the day, applications on Symbian devices could run in background without any indication. 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.
  - anthropodie 5y ago
    But they did it less for saving battery life and more to push their own Software. There are many things that could have been done to avoid the battery issue.
    - izacus 5y ago
      They changed API to clearly show that an app is using battery to push their own software? Who's "they" and what kind of conspiracy theories have you been reading again?
- izacus 5y ago
  > That persistent notification for application running in background is the worst. Back in the day, applications on Symbian devices could run in background without any indication. Some would argue that's a risk but then we have been using our PCs like that since forever. "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.
havkd 5y ago
> 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. So modify the OS… it’s open.
- oblio 5y ago
  Modify the OS, install it on your phone, hope that if you have an issue you still have support from the vendor or the carrier... 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.
- josefx 5y ago
  And distribute the modified OS to all your customers how exactly? You could probably sell your own android based phone as long as you find a single manufacturer that isn't part of Googles OpenHandset alliance or bound by the Play Store license to only sell Google approved Android. Alternatively you could limit yourself to India and China where Google cannot enforce these terms. There really isn't any point in pretending that Android is an open OS in the west. It is Googles proprietary stack or nothing.
Zanfa 5y ago
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.
- Aissen 5y ago
  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.
  - Spivak 5y ago
    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.
    - Aissen 5y ago
      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.
      - judge2020 5y ago
        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.
- 5y ago
qwertox 5y ago
I have a custom app which monitors my device 24/7 in the background with a persistent WebSocket connection to my server to receive push notifications. While yes, as a user you need to grant some permissions to the app, it works without a problem. 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.
- Andrew_nenakhov 5y ago
  > While yes, as a user you need to grant some permissions to the app, it works without a problem. 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 https://dontkillmyapp.com
  - NGRhodes 5y ago
    So the issue is not Android (AOSP) provided by google, but OEMs ?
    - Andrew_nenakhov 5y ago
      The issue is the locked-in requirement to rely on the sole source of push notifications built into the system. Running your own persistent app is an ugly workaround that doesn't work more often than does. Also, such apps are unloaded from time to time even on stock non-modified Androids.
Vinnl 5y ago
Relevant open source project: https://unifiedpush.org https://unifiedpush.org
- Andrew_nenakhov 5y ago
  "The Distributor is the application you install on your device to get notifications. It receives notifications and distributes them to the other applications." Such solutions are what I referred to as 'the best alternative'. No, thanks, it's not even close to the real deal.
  - Vinnl 5y ago
    The difference being, of course, that you only need one such application running, rather than every app that needs notifications running its own service. And of course, if a stock method every does become available, it only needs an update of UnifiedPush, rather than of every app that ships its own notification service.
    - Andrew_nenakhov 5y ago
      Captain Obvious, thank you. There problem is, such functionality should be at OS level to connect to chosen push notifications provider if Google Play services don't suit you. Not via some app that is subject to all android restrictions on persistent apps, including occasional unloading from memory. The OS is designed in such way requires push notifications built into its core to work properly.
      - jdiez17 5y ago
        > Not via some app that is subject to all android restrictions on persistent apps, including occasional unloading from memory 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."
dtech 5y ago
> first iterations of Android were relatively open, apps could run in the background without much issues. But then Google started tightening the grip 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.
- NotPractical 5y ago
  Restricting background apps by default is probably good. But Google didn't have to lock users in to their own service to provide a good push notification system on Android. 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 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 https://grapheneos.org/usage#sandboxed-play-services [2] https://grapheneos.org/features#features 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. [3] https://gotify.net https://gotify.net
AshamedCaptain 5y ago
> 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 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)
jdiez17 5y ago
While I agree with you that Google is abusing its power in the Android ecosystem to "encourage" (to put it nicely) developers to use their APIs, it is actually possible to manage this imbalance between what Google wants and what we, as users, want. 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 https://source.android.com/devices/tech/power/platform_mgmt [2] https://grapheneos.org https://grapheneos.org [3] https://grapheneos.org/usage#sandboxed-play-services https://grapheneos.org/usage#sandboxed-play-services [4] https://grapheneos.org/features https://grapheneos.org/features (ctrl-f Network permission toggle) [5] similar to using Apple as the notifications middleman, although the incentives are slightly different [6] https://unifiedpush.org/ https://unifiedpush.org/

anthropodie 5y ago

That persistent notification for application running in background is the worst. Back in the day, applications on Symbian devices could run in background without any indication. Some would argue that's a risk but then we have been using our PCs like that since forever. 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.

easytiger 5y ago
> Back in the day, applications on Symbian devices could run in background without any indication. Someone would argue that's a risk but then we have been using our PCs like that since forever. 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
endless1234 5y ago
> Back in the day, applications on Symbian devices could run in background without any indication. 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.
- anthropodie 5y ago
  But they did it less for saving battery life and more to push their own Software. There are many things that could have been done to avoid the battery issue.
  - izacus 5y ago
    They changed API to clearly show that an app is using battery to push their own software? Who's "they" and what kind of conspiracy theories have you been reading again?
izacus 5y ago
> That persistent notification for application running in background is the worst. Back in the day, applications on Symbian devices could run in background without any indication. Some would argue that's a risk but then we have been using our PCs like that since forever. "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.

havkd 5y ago

> 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. So modify the OS… it’s open.

oblio 5y ago
Modify the OS, install it on your phone, hope that if you have an issue you still have support from the vendor or the carrier... 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.
josefx 5y ago
And distribute the modified OS to all your customers how exactly? You could probably sell your own android based phone as long as you find a single manufacturer that isn't part of Googles OpenHandset alliance or bound by the Play Store license to only sell Google approved Android. Alternatively you could limit yourself to India and China where Google cannot enforce these terms. There really isn't any point in pretending that Android is an open OS in the west. It is Googles proprietary stack or nothing.

Zanfa 5y ago

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.

Aissen 5y ago
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.
- Spivak 5y ago
  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.
  - Aissen 5y ago
    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.
    - judge2020 5y ago
      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.
5y ago

qwertox 5y ago

I have a custom app which monitors my device 24/7 in the background with a persistent WebSocket connection to my server to receive push notifications. While yes, as a user you need to grant some permissions to the app, it works without a problem. 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.

Andrew_nenakhov 5y ago
> While yes, as a user you need to grant some permissions to the app, it works without a problem. 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 https://dontkillmyapp.com
- NGRhodes 5y ago
  So the issue is not Android (AOSP) provided by google, but OEMs ?
  - Andrew_nenakhov 5y ago
    The issue is the locked-in requirement to rely on the sole source of push notifications built into the system. Running your own persistent app is an ugly workaround that doesn't work more often than does. Also, such apps are unloaded from time to time even on stock non-modified Androids.

Vinnl 5y ago

Relevant open source project: https://unifiedpush.org https://unifiedpush.org

Andrew_nenakhov 5y ago
"The Distributor is the application you install on your device to get notifications. It receives notifications and distributes them to the other applications." Such solutions are what I referred to as 'the best alternative'. No, thanks, it's not even close to the real deal.
- Vinnl 5y ago
  The difference being, of course, that you only need one such application running, rather than every app that needs notifications running its own service. And of course, if a stock method every does become available, it only needs an update of UnifiedPush, rather than of every app that ships its own notification service.
  - Andrew_nenakhov 5y ago
    Captain Obvious, thank you. There problem is, such functionality should be at OS level to connect to chosen push notifications provider if Google Play services don't suit you. Not via some app that is subject to all android restrictions on persistent apps, including occasional unloading from memory. The OS is designed in such way requires push notifications built into its core to work properly.
    - jdiez17 5y ago
      > Not via some app that is subject to all android restrictions on persistent apps, including occasional unloading from memory 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."

dtech 5y ago

> first iterations of Android were relatively open, apps could run in the background without much issues. But then Google started tightening the grip 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.

NotPractical 5y ago
Restricting background apps by default is probably good. But Google didn't have to lock users in to their own service to provide a good push notification system on Android. 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 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 https://grapheneos.org/usage#sandboxed-play-services [2] https://grapheneos.org/features#features 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. [3] https://gotify.net https://gotify.net

AshamedCaptain 5y ago

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

jdiez17 5y ago

While I agree with you that Google is abusing its power in the Android ecosystem to "encourage" (to put it nicely) developers to use their APIs, it is actually possible to manage this imbalance between what Google wants and what we, as users, want. 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 https://source.android.com/devices/tech/power/platform_mgmt [2] https://grapheneos.org https://grapheneos.org [3] https://grapheneos.org/usage#sandboxed-play-services https://grapheneos.org/usage#sandboxed-play-services [4] https://grapheneos.org/features https://grapheneos.org/features (ctrl-f Network permission toggle) [5] similar to using Apple as the notifications middleman, although the incentives are slightly different [6] https://unifiedpush.org/ https://unifiedpush.org/