Major battery drain when notifications enabled

[Toasterbirb]

Is there an existing issue for this?

• [X] I have searched the existing issues

Bug description

As seen in the image, Molly tops the battery usage chart by a big margin

Usually the first day or two are fine, but then the battery usage ramps up. This same issue also happened with the upstream Signal version and that was the main reason I actually moved to the FOSS Molly version. I think adding unified push as an option might be one solution.

Steps to reproduce

1. Install LineageOS without GAPPS
2. Install Signal or Molly
3. Enable notifications for Signal / Molly

Expected result: A bit more background battery usage compared to doing notifications trough Googles notification system Actual result: Major battery drain that in some cases can even prevent the phone from charging properly

Molly version

v5.44.5-1-FOSS

Android version

LineageOS 19.1

Device

Fairphone 3

Link to debug log

https://debuglogs.org/android/5.44.5/4300b088ee0dd65914037cc68f00e501434315c0cf59f6ec3cc4aef57c5606a1

[jordischoots]

I'm experiencing exactly the same issue.

[SrEstegosaurio]

Same here. Saddly I cannot provide any metrics/info due to my phone. But I noticed the impact on battery.

I have to confirm this, but I also belive that Molly could be causing my phone to have higher temperatures.

I'm using Molly-FOSS (Latest version.) running on Android 10.

Thanks for all your work! ❤️

[XMA2l]

Just found this app and wanted to try but now i dont. I use the official auto updating apk without gcm, persistent notification, no problem here, A10, lineage os, no gapps, no microg, signal just used 14% battery since a long time (los says since last 100% charge, but cause i use ACC it never gets there). Even F-Droid with 16% costed more battery.

Am i just using other apps way more excessively then anyone else here, or could my current version rlly have a better power management?

[Toasterbirb]

The battery draining doesn't seem to be consistent. Sometimes the drain goes away and it goes back to normal rates of usage. I have no clue what variables to follow though to make any conclusions on what is causing this

[XMA2l]

LibreSignal's fate incoming after this mention?^

[Toasterbirb]

Are the Signal devs meant to be not aware about the existence of this fork?

[valldrac]

They are aware of this project. There isn't any problem mentioning Molly to the Signal team.

[XMA2l]

They are aware of this project. There isn't any problem mentioning Molly to the Signal team.

Awesome! Is there a thread somewhere for reading more details about this? Srry for the offtopic.

[drkhsh]

Same here on my Pixel 6 with GrapheneOS without Google Play Services. Interestingly, on mobile data it is always worse than on Wifi.

[hialvaro]

How could battery usage for push notifications with websockets be improved?

[HarriBuh]

I'm on rooted Android 13 on Pixel 7 and have this issue as well. Could the increase in battery consumption just be the "real"/ "pure" one, while the apparent lower usage with Google's Firebase notification service is just "hidden" or concealed inside Google's Play Service own battery usage? Because everything going on on Android will always pass through it..

TL;DR: The high usage of Molly's own notification service might be "true", while Google's own notification service might be "faked".

[githubyouser]

I'm also noticing that Molly is using WAY too much battery power. As others have mentioned, the issue seems to be somewhat sporadic, but recently seems to have grown worse. Happy to provide logs or troubleshooting if it will be helpful.

[adriandelgg]

Same here, Molly is destroying my battery life.

[albirs]

may this commit helps in this case: https://github.com/signalapp/Signal-Android/commit/13470fb0c3aa70d00a565b790178a23a216a46a5

[jm355]

Can Molly bring in this pull request, to see if it does help with battery? https://github.com/signalapp/Signal-Android/pull/13337

[matchboxbananasynergy]

Can Molly bring in this pull request, to see if it does help with battery? signalapp/Signal-Android#13337

The next release will include it. The person who made that PR also develops for Molly.

[Ronkn]

Thank you so much for doing what signal refuses to do

[jayb-g]

The next release will include it. The person who made that PR also develops for Molly.

Would be a huge relief if that fixes it.

[Bean-Beret]

Thanks everyone involved for trying to resolve the issue!

However, for a quick test, I built molly with the https://github.com/signalapp/Signal-Android/pull/13337 patch included and it does not resolve the issue on a Fairphone 4 with /e/ OS 1.17. The issue seems unchanged: normal battery drain when on wifi, but extreme battery drain when on mobile network.

[valldrac]

I built molly with the signalapp/Signal-Android#13337 patch

Yesterday we improved the patch, but haven't updated the pull-request yet. Use the beta we just released instead. It includes the latest commit https://github.com/mollyim/mollyim-android/commit/7257d571bff30e4b5759ec82b15a7993cd945866.

Don't expect miracles, but you should notice less consumption.

[wiesenklee]

I've experienced similar behavior on GraphenOS with Sandboxed Google Play Services and Molly's FOSS (Fdroid) version. Today I installed the latest non-FOSS version expecting Molly to drain way less battery now using FCM (Firebase Cloud Messaging). But it did not. So I restricted battery usage in Android's battery settings and noticed that my database encryption could not keep unencrypted. Could database encryption be a part of battery drain problem's?

[jayb-g]

Could database encryption be a part of battery drain problem's?

Could definitely be. Since i'm experiencing similar battery usage where in one phone I have fresh setup of signal, in another I have 20+GB of data. Both signal apks and no play services. Unrestricted battery usage. Although the one with fresh setup uses way less battery. So the problem might be related to database handling and in upstream signal repo.

[jayb-g]

Guys, using Molly-UP (or Signal-FOSS by twinhelix if he implements UP) and setting up your own mollysocket for free(visit mollysocket-fly repo) seems to be the only solution for now for the battery drain issue. I just set this up and will report back in a few weeks with an update on how it performs.

[ghost]

@jayb-g Why does this require the setting up of an external MollySocket server? If the default one built into the app can serve WebSocket notifications why can't it serve UP notifications as well?

[jayb-g]

@48-mq Because the default way of getting notifications(using websockets) in molly and in upstream signal is causing battery drain due to improper handling of WS commections or whatever reasons. UP addresses that and eliminates possibility of battery drain due to websockets.

I have seen no user reporting low battery usage even after the said fix for it patched in molly.

[jm355]

@jayb-g the websocket connection is inefficient, so mollysocket allows it to be handled by a server connected to power (where efficiency is less important) and forward the fact that there's a new notification to molly via an efficient notification listener - unifiedpush

[ghost]

I had assumed Molly had built-in functionality to use its own MollySocket server, but not reviewing the Readme I realize that is not the case.

Why can't there be a public (airgapped) MollySocket server just available for everyone to use? The notifications are all encrypted anyway, and I can't image such a public server would consume so many resources that it would come at an exorbitant cost to the Molly community?

[jayb-g]

the websocket connection is inefficient, so mollysocket allows it to be handled by a server connected to power (where efficiency is less important) and forward the fact that there's a new notification to molly via an efficient notification listener - unifiedpush

@jm355 I get that. But so why can't apps themselves use this efficient way of sending notifications to users? I believe apps are accustomed to not worry about notifications efficiency since they have been relying on Google and Apple for that from the beginning? And you need a single server anyway to get notifications from different apps efficiently(not having an open connection for each app)

[jayb-g]

Why can't there be a public (airgapped) MollySocket server just available for everyone to use?

@48-mq yes you answered your own question. Molly is not Signal. It just uses signal backend which they don't have any control over.

[jayb-g]

the websocket connection is inefficient, so mollysocket allows it to be handled by a server connected to power (where efficiency is less important) and forward the fact that there's a new notification to molly via an efficient notification listener - unifiedpush

@jm355 you seem to be right. But I'm trying to understand this. If websocket connection is inefficient, ie uses more battery to say the least, why do so many apps fallback to websockets for persistent connection? Does it prevent phone from going into deep sleep? Does it have to, in order to maintain a persistent connection? (Also, as compared to this, how does GCM work on a phone and not use much battery while still maintaining a persistent connection? )

On the other hand, how is unifiedPush any different than websocket(from phone's perspective)? AFAIK, UP distributor app such as ntfy can use either of JSON over HTTP and websocket type connection. Would it not consume battery the same way? Moreover, for each app configured to use UP and ntfy, there are multiple connections to be maintained. Does more connections(subscriptions) in ntfy mean more battery usage or it doesn't matter?

Can you please share your insights or some references?

[jm355]

@jayb-g There are ways to do it efficiently. Tuta uses SSE (Server Sent Events), which has a very tiny battery impact on my phone. I don't know how ntfy.sh does it, but it's the unifiedpush provider I use and it also has very tiny impact on my phone.

The nice thing about unifiedpush is, even for efficient setups like ntfy and tuta, using unifiedpush means you only need one app doing it, cause even a tiny battery impact adds up when you have a lot of apps like that. I have 6 notifications set up in ntfy, so by using unifiedpush instead of requiring each one to have a separate background process, it has 1/6 the battery impact.

As I understand it though, signal has a uniquely inefficient websocket listener. The pull request https://github.com/signalapp/Signal-Android/pull/13337 (which molly uses) makes it better, but it's still not great.

[jayb-g]

@jm355

I don't know how ntfy.sh does it, but it's the unifiedpush provider I use and it also has very tiny impact on my phone.

You mean with unifiedpush provider on nextcloud server and nextpush as the distributor app?

I have 6 notifications set up in ntfy, so by using unifiedpush instead of requiring each one to have a separate background process, it has 1/6 the battery impact.

Can you share some reference for that? I tried but couldn't find any for UP in general or for ntfy.

[jm355]

@jayb-g no, I mean https://ntfy.sh/ with the ntfy.sh app on my phone. I have my own personal instance that I use, but it's effectively the same as using the default ntfy.sh server. https://unifiedpush.org/users/distributors/ apparently I should have said "distributor" not "provider"

What kind of reference do you want? It's just basic math. Let's say for this example that the bare minimum battery an app must consume in a day to listen for notifications is 1%. If you have 6 apps each listening for notifications independently, in total they will consume at least 6% in a day. If you have one app that listens for notifications for all the apps, it will only take 1% battery but provide notifications for all 6 apps. 1% is 1/6 of 6%

[jayb-g]

What kind of reference do you want?

I meant if documentation of unifiedPush or ntfy says that somewhere that ntfy keeps one connection per device and not per subscription in the app.

It's just basic math.

Yes I understand that. But it doesn't mean we can assume ntfy/other UP apps works that way.

Anyway I got the point. Will lookup for it.