It’s been 5 years since I’ve had a look at how often the apps I use on my smartphone send or receive data in the background. Keeping the amount of background traffic to a minimum is important to reduce power consumption while the phone is not actively used. Google and Apple have recognized this and are offering a single channel to each device through which notifications can be sent. While the approach is understandable, there are people like me who are not very fond of having notifications run through a single centralized entity. On Android, fortunately, apps can keep their own decentralized notification channels open in the background. Some of those apps and servers are better than others when it comes to minimize traffic and thus to reduce battery consumption. When I recently switched to GrapheneOS, it was time again to have a closer look at background data exchanges and to see if there is anything I can optimize. And here is the result:
Before I look at the apps I use 24/7, let’s have a quick look at the two basic types of background communication channels that applications can use:
Many apps use active push communication, which requires a permanent connection to a server. Notifications about incoming messages is instantaneous, but the downside is that even if no data is transferred, TCP or UDP keep alive packets need to be exchanged to ensure Network Address Translation (NAT) routers do not ‘forget’ the connection after some time and drop incoming packets.
For less urgent communication, some apps use the pull approach. Here, an app regularly checks for changes on a server. Once the check is complete, the TCP and UDP connection is terminated and no keep-alive packets are required. Pull intervals typically used are 10 minutes or more. This slows down data exchange but is very power efficient.
So in other words, using push or pull is a tradeoff between the notification speed and power efficiency. With that being said let’s have a look now at the communication behavior of the apps I use on Android:
Conversations
Conversations is my main messenger I use for communication between friends and family. It’s based on XMPP and the TCP keep alive-time is 5 minutes. That means that the modem has ample time to go to sleep. I’ve optimized my server for it many years ago and it’s good to see that despite a number of operating system updates the setting is still there and works.
Gotify
For notifications about server restarts, power failures and other infrastructure related events, I use Gotify, which offers easy http based notification messaging. It’s easily integrated into pretty much all processes and after some optimization on the server and client side, I get a consistent keep-alive time of 6 minutes.
Obviously, I must have eMail on my Android device. I use K9 Mail for the purpose and I have IMAP push activated for 2 email accounts on two different email servers. Unfortunately, the keep alive timing is horrible, the servers send keep alive packets once a minute. ONCE A MINUTE! Totally devastating. K9 has the option to switch-off IMAP push and poll in various intervals, but I have found the option not working very predicatively. Also, I have to admit, I do like my eMails to come in instantly. There is little K9 can do about this, because the keep-alive packets are sent from the server side. And as these servers are not mine, there is nothing I can do to improve their behavior.
Mastodon / Tusky
To keep me entertained, I get my daily fix of noteworthy and not so noteworthy messages via Mastodon and the Tusky app. Tusky polls for direct messages and posts in which I’m mentioned in very long intervals, and I didn’t even bother to measure it. So no power consumption implication using this app. Tusky also has the option to get push notifications via UnifiedPush, which is a super nifty mechanism to which I will dedicate a number of separate posts.
Calendar and Address Book
To synchronize my calendars and address book across quite a number of devices, I use my Nextcloud server and the Android DAVx5 connector. It works like a charm and I have configured calendar pull updates every 10 minutes. The address book synchronizes once every 4 hours.
Antenna Pod
For podcasts, I use AntennaPod and it checks for new episodes on many servers a few times a day. Again, the pull interval is very long, so haven’t bothered to have a look in my Wireshark traces for an exact timing.
F-Droid Store
And finally, I use the F-Droid store for my applications and to keep them updated. As it doesn’t have a real-time need to install updates, it also uses a very long pull interval.
The Google Stuff in the Cave…
And then, there’s the proprietary apps I keep in my Android Private Space on my GrapheneOS device that uses Google’s Firebase Cloud Messaging (FCM). FCM is a single conduit for incoming push messages for all apps that connect to it and has a keep alive timer of a few minutes. I haven’t measured the precise timing, as I only use the apps in my private space occasionally and immediately close the private space and thus terminate all apps, including FCM once I no longer need them. So no extra keep-alive messaging coming from that cave.
Summary
So except for E-Mail, my push and pull communication is quite optimized and my modem has many opportunities to go to sleep and thus save power. There is a huge potential for further improvements on the eMail side, but I don’t really see this coming in the immediate future. So I either live with it, or switch to eMail pull.