Skip to main content


I installed #Signal and #Conversations_im on a clean install of #GrapheneOS on my Pixel 4a and measured the battery impact. The results are shocking!

Both messengers had only one contact: my regular phone.

I used my regular phone to send messages to the Pixel 4a (which was not used for anything else over the course of the experiment).

I always sent the same message via Signal and #XMPP (mixing up which app went first). In total I sent ~32 messages in intervals of 10mins to a few hours.

FediVerseExplorer reshared this.

in reply to Daniel Gultsch

Truly shocking.

What push mechanisms are you using for Signal and for Conversations?

in reply to مسعود

@masoud Both have direct connections to their respective servers because #GrapheneOS comes without Play Services. Both apps prompted me for exemptions to "Battery optimizations" which I granted.

On the sending side I made sure (by looking at the double ticks ✅ ) that the messages were delivered instantly.

in reply to Daniel Gultsch

I wonder if this is related to the bandwidth/power optimizations that XMPP clients/servers support (e.g. CSI) or just general app bloat.
@masoud
in reply to Daniel Gultsch

@masoud A big part of the reason centralized push-notifications (aka "Google Play Services") exist is for battery optimization.

You could of course just let Signal use Play Services on graphene if you like.

My experience is different (although I only have Signal, not matrix). My refurbished 7a with GrapheneOS and no Play Services at all in the owner profile lasts easily two days. (That said, it'll mostly be on WiFi while I'm at home -- so possibly the difference is that?)

in reply to Daniel Gultsch

This is in line with my experience with signal. I have revoked all battery optimization permissions and essentially allow my phone to insta-kill it once it goes to the background. I don’t receive messages unless I open it, but my battery last eons longer.
in reply to Daniel Gultsch

I did some tests in the past as well and I remember #Conversations was one of the best apps on optimal battery usage, great work Daniel! 👌
in reply to Daniel Gultsch

Do you plan to make experiments with element, too?
I would expect Conversations to perform a lot better since matrix is known to be more heavy on ressources but i mention it because it feels like an obvious direct competitor
in reply to Remus

@ikonoklast the thing about #Signal that it was at least reliable. Messages were delivered instantly (same as with Conversations). From what I've been hearing about Element is that it becomes notoriously unreliable when it’s working without an external push service. And then it obviously becomes hard to measure battery impact if the app is dead half the time.
But yes maybe. Signal vs Conversations was easy to pull off because I use both apps on a daily basis anyway. I don’t use #Matrix
in reply to Daniel Gultsch

That seems quite significant. I have looked into hosting my own XMPP server in the past. I like the idea of a small non-bigtech chat platform for my inner circle. Unfortunately, the biggest challenge is to get people to switch their conversation with you over to a different app.
in reply to Daniel Gultsch

So I suspect Signal has a wakelock problem as they haven't tested extensively on devices without Play services? The battery drain is running at almost constant speed.

Conversations is great. There's not much to modify/customise before getting it to run on my devices.

in reply to Daniel Gultsch

Signal is probably not testing/optimizing for phones without Play Services.
in reply to Daniel Gultsch

btw molly a signal soft fork have unified push support. So we can use correct software (Conversions) as a notify provider 👍
in reply to Daniel Gultsch

Not really surprised.

The CPU and Radio on your phone are both high draw devices. It's why your phone wants to kill or sleep any program as soon as possible. FCM & APNS use carrier data (& no encryption) which use much lower power stuff.
Otherwise you get what you see, or worse)

That's why Firefox only does Push it we have access to native, but also why data is encrypted.

in reply to Daniel Gultsch

While you're testing with GrapheneOS, maybe you could check if it keeps the connection open for longer when the phone is locked. Since a couple of months or so, I see 0 connections in the widget when unlocking my phone after a while, but then it reconnects quickly. However, the battery savings settings are the same as before and I don't know why it would disconnect otherwise.
in reply to Râu Cao ⚡

@raucao Both apps had no problem maintaining their respective connections. Messages were delivered instantly (as indicated by double check marks + me hearing the notification when I happened to be in the same room as the test phone)
in reply to Daniel Gultsch

I meant more like leave phone untouched for at least a few hours, then check.
in reply to Daniel Gultsch

though I am sure Signal is more battery consuming than any other XMPP app, I am unsure if the difference is as dramatic as shown in this screenshot. There is 20% usage by Signal and 12% usage by Monocles on my phone.
in reply to gumnaam

@gumnaam Note that in my testing I never actually opened or otherwise interacted with the apps. (I did make sure that messages got delivered though).

As soon as you start interacting with the apps or if/when they receive a different amount of messages your results get skewed (Screen time is obviously a big contributor to battery consumption)

in reply to Daniel Gultsch

my screen time shows 1 minute for both apps. So, I don't think the result should be THAT skewed.
in reply to Daniel Gultsch

It's a well known problem: github.com/signalapp/Signal-An…
in reply to Daniel Gultsch

Known issue since years...
github.com/signalapp/Signal-An…
in reply to Norbert Tretkowski

The infuriating part is that Signal pretends that the massive battery drain is somehow inherent to not using Play Services while my screenshot demonstrates that it clearly isn't.
This entry was edited (15 hours ago)
in reply to Daniel Gultsch

Mhh, Signal always keeps a connection to their server open for push messages. Maybe try Molly (Signal fork) with UnifiedPush and use Conversations as UnifiedPush provider.
in reply to Daniel Gultsch

I use the @mollyim fork and it looks like that it does not use that much battery
in reply to Daniel Gultsch

I wonder if it would be any better if you used the play store version and microG. That's what I'm using on CalyxOS and while my notifications from Signal are less reliable than Conversations, battery usage isn't too bad, though it is worse. Here's my top contenders right now. I'm using the F-Droid version of Conversations.
This entry was edited (1 day ago)
in reply to Daniel Gultsch

Signal needs to keep active and send regular pings to keep the WebSocket connection open. This is not a technical requirement of WebSockets, but stems from Signal using the latest advanced cloud technology on their servers which cuts the connection if it doesn't see active payload traffic.
in reply to Daniel Gultsch

interessant. Ich kämpfe auf meinem #grapheneos auch seit einer Weile mit dem Akkuverbrauch von #signal. Schade, dass in #younohost seit dem Update auf #debian 12 nicht mehr automatisch ein #XMPP Server integriert ist. Das war schon ein sehr bequemer Weg für Laien wie mich, unfallfrei, unkompliziert und günstig einen solchen zu klicken und pflegen.
in reply to Daniel Gultsch

I don't know why Signal eats so much battery but they probably don't run a lot of tests without GCM since that is their main platform. On a degoogled phone, you can use Molly with unified push. Molly is a fork of the official Signal client with very little changes. It works very nicely and UP is a great framework. You can even serve the Signal notifications through Conversations since it works as UP provider
in reply to Daniel Gultsch

I have had exactly the reversed scenario at times: Conversations draining like crazy while Signal was just fine. Sometimes the other way around. Never found an explanation. ¯\_(ツ)_/¯