UnifiedPush – Part 2 – An Easy Practical Example

In the previous post, I’ve had a look at UnifiedPush (UP) and how it works in theory to deliver push notifications from servers to apps on mobile devices. UnifiedPush has been designed to be de-centralized, and if one does not want to self-host a UP server, there are a number of different transport options and UP server providers available for use. I use two apps on my Android device with UnifiedPush, Tusky, a Mastodon feed reader and Molly-FOSS, a de-googled Signal messenger fork. While I was tempted to go straight for a description of how Molly-FOSS uses UP, I’ve decided to defer that into a separate post and rather go for a description of how Tusky uses UP, as the setup for this use case is simpler. Let’s go from simple to more complicated!

Continue reading UnifiedPush – Part 2 – An Easy Practical Example

UnifiedPush – Part 1 – Why and How

In a previous post I’ve had a look at how I can use the Signal Messenger app on my GrapheneOS Android phone without Google’s push notification service (FCM) for incoming messages. There are a number of options and I settled for the combination of the Molly-FOSS fork of the Signal App and UnifiedPush (UP) for notification. It works like a charm so I had a more detailed look at how UnifiedPush actually works and which options there are. It was a bit challenging to get my head around the online documentation so I thought I’d write a couple of blog entries to see if I can explain the concept in simpler terms. Not only for you, but also for me, because I’m sure the topic will come up again in the future.

Continue reading UnifiedPush – Part 1 – Why and How

From Signal to Molly-FOSS and Unified Push

As you might know, I’m using the ‘Conversation’ XMPP based messenger app on Android and my Linux notebook for text, audio and video communication with friends and family. A federated self-hosted XMPP server keeps me independent from- and interconnected with others at the same time. And then there are friends and associates in a somewhat wider circle for whom it is not very appealing to use yet another messenger. Perhaps as unappealing as it is for me to use Whatsapp. But perhaps there is a middle ground?

Continue reading From Signal to Molly-FOSS and Unified Push

Keep Alive Timing of Google’s Firebase Cloud Messaging

In the previous post I had a look at the background keep-alive data traffic of messaging apps on my GrapheneOS device that do not use the Google Firebase Cloud Messaging (FCM) service for push notification. I’ve optimized my apps and servers to have keep alive timers of 5 to 6 minutes, which ensures that even aggressive NAT routers in the path do not kill the connections. So how do these values compare to Google FCM?

Continue reading Keep Alive Timing of Google’s Firebase Cloud Messaging

Background Traffic of Android Apps – An Update

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:

Continue reading Background Traffic of Android Apps – An Update

WebRTC Video Bandwidth Requirements

In a previous post I’ve been looking at the network behavior of voice calls over WebRTC on Android. In that graph, one can see that the bandwidth, independent of Wi-Fi (over DSL) or cellular is around 80 kbit/s in each direction. During the Conversations XMPP app call, we then switched from voice-only to voice+video. Needless to say that bandwidth requirements then change significantly.

Continue reading WebRTC Video Bandwidth Requirements

From Firefox to Fennec to Vanadium?

I think I’ve been using the ‘original’ Firefox web browser since 2004 on my notebook and also on Android from the day it was released. Over the years, there has been criticism around anti-privacy features that came and went, most of them probably well founded. Nevertheless, I stuck to Firefox on my smartphone until recently but decided to switch after seeing just how often Firefox ‘calls home’.

Continue reading From Firefox to Fennec to Vanadium?

Wireguard on Android – A Bit of a Mixed Bag

Earlier this year, I had (another) look at Wireguard. Beginning with Ubuntu 24.04, the client is now fully integrated in the network GUI and a Docker based server installation has become available as well. One thing I didn’t have time for at the time was to look at Wireguard on Android. So let’s have a go now.

Continue reading Wireguard on Android – A Bit of a Mixed Bag

WebRTC Handover between Wi-Fi and Cellular

I use the Conversations XMPP messenger a lot on my Android phone, not only for text, image and video chat messages, but also for voice and video calling. It’s a joy to use! While in the early days, voice calls dropped when moving between the cellular network and Wi-Fi, the process has become pretty much seamless in the meantime. When I recently jumped between Wi-Fi and cellular a number of times on purpose, I was surprised that I couldn’t hear the switch between the networks in the audio channel at all. So perhaps the call didn’t switch and staid on cellular? I decided to have a closer look.

Continue reading WebRTC Handover between Wi-Fi and Cellular

F-Droid and Aurora Now Auto-Update Apps

A quick note today about something that probably everyone but me knows already: When I last installed the F-Droid and Aurora App Store front-ends, the one thing both of them could not do were auto-updating installed apps. Not a big problem for me because I don’t mind being in control when a device updates apps. But for those in the family that would rather like things to be automated, this was not so nice. Looks like since Android 12, alternative app stores can now also automatically update apps. When I installed F-Droid and Aurora, the option did not exist, but an update down the road introduced the feature, disabled by default. Good default, I commend them for it. But actually, I have to admit that auto-update is something I would like as well, so I’ve switched it on for my device as well now. Many thanks, cool stuff!