A while back, people here kindly explained how typical commercial Android apps get push notifications. Quick version: notifiications are sent through Firebase Cloud Messaging (FCM), which communicates with Google Message Services (GMS), an always-on Android client app preinstalled on most Android phones. There's a FOSS alternative to GMS called MicroG but it's still an FCM client, and FCM is an evil Google service that client apps that use it have to enroll with even if you escape GMS on the client side.
Right now I'm interested in sending myself push notifications from a self-hosted service that I run on a VPS. Of course I don't want to deal with FCM. I also prefer to not have to develop an Android app as opposed to running something like an XMPP client.
It looks like there are some alternatives like Iris and Unified Push (unifiedpush.org). It looks to me that UP becoming the preferred solution, is that right? UP has its own always-on client that can receive messages from a UP server that you can self-host. This sounds ok to me in principle.
My main question is whether UP is somehow worse than GMS, in terms of being a background app that keeps a network connection open. Is GMS anything special in that regard, besides being preinstalled by Google? Would GMS use less battery power or anything like that?
I may also have to look into how XMPP works, if my server program is going to send messages through it. I actually have an unrelated reason to be interested in XMPP. But does that approach sound reasonable? Are there XMPP clients that are non-bloaty, don't eat battery energy in the background, etc.? I'd like a loud audio alert if I get one of these notifications from my server. Can I usually easily set up XMPP clients to allow that only from my own service, while not making sounds for anything else? I'm luddite enough that I still use IRC for online chat, but maybe I have to catch up with the ~~20th~~ 21st century about this. Is there a good community to discuss XMPP development and self-hosting? I.e. I'd want to self-host the XMPP server and use it to send messages to my phone from my own (also self-hosted) server app.
The simplest alternative I can think of is for my server program to just sometimes send me SMS messages through Twilio or similar. The alerts will be infrequent enough that I don't mind going this route. Does that sound easier? It's less in the self-hosted spirit but it gets rid of a lot of software on both the server and the phone, I guess.
Thanks!
Reportedly, GCM uses lots of clever trickery to bundle messages, decide to delay them or do whatever with it. And I'm sure they put in lots of effort to squeeze every last bit out of it. And handle lots of different situations. But I havent kept up with the Android internals, I might be wrong. Last time I checked GCM was ahead of their competition. But the question is whether this is some theoretical benefit which manifests in a few seconds of more battery per day, or whether this has a substantial impact... I hope someone else with a bit more knowledge can chime in... I'm still not sure why my old phone and my new one from a few weeks ago report vastly different numbers on that...
(Edit: And I think there is more going on. Like server-side stuff to prioritize when to wake a device etc. I don't think it includes evil magic. Other than having 99.99% of apps be part of their ecosystem. So if you're using any proprietary app on that phone, you're going to need it. And at that point installing a second service alongside will just be an additional burden. So you either have a de-googled phone and need an alternative provider anyway... Or you have GCM anyway and the additional service will be on top...)
My phone still has google stuff. I have turned off Google Play Services (GPS) and sometimes the apps squawk but meh. Is GPS somehow related to GCM/FCM? I do get notification dots from a few apps like email, messages, phone, etc. I use K-9 email and someone mentioned that it might just be holding a TCP connection open to an IMAP server, but it doesn't seem to run in the background.
There are also things like the clock/alarm app which presumably always run but which also don't show up on the list of running apps, hmm.
I guess I'm wondering if keeping a network connection open inherently uses power, and if that is how GCM works. I would think a blocked Linux process itself uses almost no power, but the kernel has to keep that connection alive. TCP timeout is usually what, 20 minutes? So there must be a wakeup at least that often.
I guess that GCM actually launches the recipient app if it isn't actually running. Presumably those UP brokers(?) can do the same.
This is also how inetd on linux works, more or less. Is there a reason we don't just use inetd on phones, come to think of it?
Added: per this stackexchange comment, GPS is in fact the client side background app that receives FCM messages and routes them out to other apps on the phone.
You can't really compare that to Linux. Android has entirely additional layers and APIs to deal with connected standby, doing background stuff etc. All of that is missing in Linux. I own a PinePhone which is running Linux. And you either have that running and drawing like a Watt constantly. Or it goes to sleep. But that means no chat notifications, no email checking in the background and no nothing until the phone wakes again. Except for the baseband, which will wake the CPU and the operating system if a call or SMS comes in. But that's pretty much it. Keeping TCP connections open or applications listening, requires good parts of the phone to stay awake.
Android on the other hand does a lot of stuff that sends apps to sleep, wakes them up again, sends most of the hardware to sleep, offer specialized API to do all of that selectively...
And as far as I remember K-9 has a few methods implemented. It will fall back on periodic polling. So you'll get your emails no matter what. But it'll try to just keep a connection alive in the background and bypass GCM entirely. I also have it running 24/7 and even a VOIP phone app which is also okay with just a connection open in the background. I'm not sure about TCP timeouts etc. But as far as I remember that's exactly how you do it as a developer if you don't use a push provider like GCM. It uses additional battery, though.
But the baseband needs to wake and deal with an incoming packet. And something needs to decide what to do with it. So if you have like 10 connections open, waking the phone at different intervals, that'll drain some battery. If you stick to one push provider, that can bundle packets and can decide server-side if it's going to wait for a few seconds or do it right now and now the phone will do it in a coordinated fashion. GCM does this. I'm just not sure if UniversalPush has something like that implemented... Regardless, keeping connections listening can't do any of that.
Thanks, yes, that is very helpful and is the type of thing I was wondering about, and also whether GCM somehow got wakeups from the baseband instead of just waiting on TCP.
I actually don't know whether I'm running anything right now that uses GCM in any important way. That presumes incoming phone calls and SMS really are alerted by the baseband and not by GCM (not sure if that is true). I'm using K9 from F-droid so presumably with no GCM credentials, and it seems to me (now that I think of it) that it polls IMAP every few minutes or so, somehow without obviously running in the background, hmm.
Anyway for this immediate application I guess I won't worry about battery impact too much unless I really notice a problem. I think listening on a socket is important enough that I should check into how well it works. The SMS approach seems like the lowest overhead in power usage though.