Killing apps in the background and offloading them from memory is a godsend for a Android ecosystem. It is literally so much harder to make anything battery optimized since you have get information about almost everything to make it right: need radio? beware that it is in active state and only then send data. Want do background processing? Wait until user will charge it's phone. Making apps battery efficient is insanely hard task and it is solvable by just offloading everything to an OS.

I have built several push services for my previous projects it always sooo hard to implement right. iOS for example, uses 25+ different parameters to optimize push delivery depending on your app usage, on how you are using your phone and so on.

Good luck to build this as "third party" and keep everything private.

It is a godsend only up to a point when you can't run an app in the background even if you badly need to. The computers (and Android devices are computers) should not be putting their users into straight jackets so they won't hurt themselves. Users should have an option to do what they want. The system's job is to inform that what they are doing is using battery. If a user is OK with it, the system SHOULD NOT interfere.

Using such information is so hard that almost impossible. I could spend a year tailoring battery performance for a messenger and still get random guy who have some exotic phone with some strange behaviour.

There are really almost no need to run app in the background or at least constantly send data without a reason (mostly just tracking).

UPD: When deciding how to build something i have one small trick: first ask question about who can make better decision about something?

For example? Who is more capable to make decision about battery usage, about tweaking core performance, etc? It is obviously kernel or silicone itself. App will never have required information to build perfect performant app for every device. This just means that you have to build a kernel by yourself and even more: common kernel for every phone.

> Using such information is so hard that almost impossible.

Aren't battery stats not enough for you? If your app uses too much battery, you can stop using it. Or you prefer some other people to make this decision for you?

The thing is, though, that Firebase push notifications are deeply integrated with mobile networks. They get special treatment to ensure energy-efficient operation, at the cost of more idle connections hanging in the network infrastructure. Yes, with IPv6 that should/could become much less relevant, but then you loose the traffic-flood-DoS protections you get from CG-NAT.

Oh come on. Push notifications is just a modified XMPP connection that exists in the background. Actually, both FCM and APNS use XMPP to transport notification to devices.

The only 'special treatment' that happens is on Google/Apple servers which determine the priority of some of notifications.

How do I know? We're very involved with the XMPP protocol. The irony is that it is insanely hard to maintain an XMPP connection to a client on both Android / iOS, despite devices under both these OSs being an always connected XMPP clients.

Well, in your sibling I have linked a paper that talks about the negative effects of un-coordinated persistent TCP connections on the network's stability. I read a god chunk of it, and it seems to explain quite well why these push services get special treatment. Hint: it's connected to them running a keep-alive delay in the "hours" range for the mobile radio link, without imposing that on the cloud server.

Please provide evidence of this "deep integration" with mobile networks.

Moxie has cited this previously with no proof, despite protocols like xmpp performing similarly on mobile networks.

There is integration. I don't know what it is these days but it used to be mostly carriers adjusting TCP timeouts on their NAT boxes.

The issue is that a long lived TCP connection consumes some valuable RAM and a port number on a valuable IP address. It costs carriers something for push notifications to work, so, they tend to aggressively close long lived TCP connections that aren't going to recognised push datacenters.

For that to work you need business relationships with the carriers of course, stable IP addresses, and enough users of your push service for it to be worthwhile.

IPv6 would fix it by eliminating IP scarcity and CGNAT, but most mobile networks aren't provisioning handsets with IPv6 addresses.

The second page, on the right, the last bullet point, suggests such deep integration:

https://web.archive.org/web/20170708204409/www2015.wwwconfer...

Whether FCM uses these technologies, I don't know. I lack the hardware to easily inspect the mobile radio traffic on the necessary level (the best would be a DIY stingray based on one or two OsmocomBB-capable GSM phones, maybe combined with a Faraday cage to place one of them into, together with the smartphone.

The irony is, FCM is a modified XMPP

OK, Google may charge for Firebase push notifications. Including making a profit from it of course.

They may not perform anticompetitive behaviour like bundling (as they have already been fined for in the EU over Android and Play Services).

Huh? FCM is free: https://firebase.google.com/products/cloud-messaging

I don't see the anti-competitive part there. There are good reasons around consolidating resident daemons and only using a single TCP connection with a special keep-alive configuration.

And from experience, it's perfectly possible to not use FCM, at the cost of a persistent notification that alerts the user about this, so they can get rid of abusive apps.

> I don't see the anti-competitive part there.

Maybe not exactly anti-competitive (but maybe): It requires you to have hundreds of megabytes of Google blobs with root permissions on your device, which some people don't like.

If course this pales in contrast to Apples actions.

https://github.com/microg/android_packages_apps_GmsCore/wiki... claims to support this without blobs. I haven't tested it myself, but some friends seem to have no problems with their de-googled Androids.

Can you use FCM for non-Play-Store apps? I was under the impression you couldn't from the grand-grand-parent.

I think you can but you still have to link to Google play services, which is not possible for open source apps in f-droid since they need to be able to run on de-googled android which lacks Google services.

It looks like FCM is supported by the open replacement I linked in a close-by comment, here: https://news.ycombinator.com/item?id=23571663

Aren't microg supposed to get installed first on the device? Which mean if the user doesn't have it, then your app won't run? Or can you embed the FCM support into the app itself so it doesn't depend on google play service or microg availability?

You're asking the wrong person. I'd have to research just as much as you'd, and judging by upvotes and age, (almost) no one else would care. Sorry :(

I found no evidence for either side, but I can't easily test it right now.

> it would still be crippled on modern versions of Android, because it would not be able to receive push notifications

My understanding is that this is not an effect of side loading, but an app not using Google Cloud Messaging, which is not available when play services are not installed.

Yeah, that's true.

Anyone can distribute their Andrioid app using their desired way. Even via web site. Exmple: https://signal.org/android/apk/

Sending push messages to Android phone using Firebase Cloud Messaging(FCM, formerly GCM) requires "Google Play Services" installed on that Android device. Google Play Services is not depends on Google Play Store and is not requires that applications using Play Services should installed by Play Store.