Signal consumes half of my battery (no google services or microG)

someone1239 commented 4 years ago

[x] I have searched open and closed issues for duplicates
[x] I am submitting a bug report for existing functionality that does not work as intended
[x] I have read https://github.com/signalapp/Signal-Android/wiki/Submitting-useful-bug-reports
[x] This isn't a feature request or a discussion topic

Bug description

I installed Signal a few days ago, but it consumes close to 50% of my battery, more than all my other apps combined, when I barely even used it (answered one short call, sent and received < 5 messages). I'm on grapheneOS so no google services and no microG. I posted the issue on reddit, and one person also on grapheneOS showed me a screenshot where Signal took 7% of their battery, with about the same time since full charge. Battery optimization is off, I can't even turn it on. App runs constantly in foreground (which I assume is normal for the websockets).

Steps to reproduce

use Signal with no google services or microG

Actual result: Signal takes between 40 and 50% of battery life Expected result: Signal should take ~10% of battery life

Screenshots

180aacb7-4a2f-46bc-ab2a-ce82e362eeda3

Device info

Device: Google Pixel 3a Android version: 10 Signal version: 4.62.4 (6520) from website

Link to debug log

https://debuglogs.org/ab69b49388ae783727c5d47318d25296311a9f8f0cce64991fb28ae0830f2a34

d3nnis77 commented 2 years ago

Same story here. Also Pixel 6a with GrapheneOS. Over one day about 40(!)% battery usage by Signal in the background.

I´m currently working around this by running a matrix server with a Signal-bridge that notifies my phone via Element + ntfy (Unified Push) whenever I recieve a Signal message (ntfy consumes about 0-3% of battery over the day).

But honestly, it is simply a shame that this is currently the only option to use Signal (more or less) reliably without Play services or slaughtering my battery life and that the developers obviously don´t really care. Privacy oriented people may not be their biggest user group, but we are there biggest peer group and advocates. I mean: I convinced over 8 people to use Signal for communication and most of them use GCM (obviously). But when it is only possible for me to use Signal with Play spyware installed (or with impractical, high technical workaurounds), that kinda defeats the whole purpose why I would recommend Signal to other people. Without our reccomendations, (probably) most of their userbase wouldn´t exist.

The best longterm solution I see is, to implement an GCM alternative like UnifiedPush into Signal, so that every user has the choice whether he uses GCM or not even if Play-services are installed.

But: considering the history of this problem and the response of the devs here and in their forum (other users have come up with UnifiedPush already), I have little hope, that this will ever be really solved.

maxammann commented 2 years ago

Yes, I guess we (the community) needs to get active for solving this. I don't really have time right now for such a side project, but I'll post this issue to the GrapheneOS Matrix. Maybe we can solve this as the Signal community :)

d3nnis77 commented 2 years ago

This will unfortunately probably be the case.

I can think of one possible solution: As modifying the server is no option, as we therefore would be seperated from all "normal" users, the solution has to be in the app.

Maybe it would be an option to integrate (for example) ntfy into the app, so that the app sends a push notification to a ntfy-server (most likely the standard ntfy.sh) to a number-individual push address (hashed number or something), which the modified signal client at the reciever uses as trigger to make a websocket connection.

Combined with a in-app setting to change the websocket pull intervall (15 min. or so) as fallback and for recieving messages from persons that don´t have the modified app:

modified signal app (User A)

Sends message to B
Send push to push server with hashed number of B

->

ntfy-app of B

Recieves push (listens to own hashed number push address) -> Wakes up signal

->

modified signal app of B

Wakes up -> Makes a websocket connection to get the message
Checks regulary for new messages (every 15 mins. or so) for "normal" messages

So you would only need to get the people you most oftenly chat with to get the modified version of Signal. The downside: every "normal" message would then be a little delayed.

(Of course this would all be much easier and more reliable if the developers would integrate a GCM-alternative into the server, but I see no movement there: https://community.signalusers.org/t/use-gcm-fcm-alternatives-for-notifications/10264)

magical-heyrovsky commented 2 years ago

I wonder if they could use something like Threema Push. But I guess this would lead to too many backend changes for Signal.

panomitrius commented 2 years ago

Voting for this issue to be prioritised!

starbrights commented 2 years ago

As of me I wouldn't call battery drain excessive, but definitly more than other messangers/apps. With signal active battery lasts only a day (2 without it)! I am running it without playservices, but with microG instead. It seems not support it's push service, although it would be possible. But I just have no choice.

ioctl-user commented 2 years ago

I am running it without playservices, but with microG instead. It seems not support it's push service,

It does. But sometimes it cannot interact with the MicroG services on installation and not working with them after that. If so, try uninstall and install Signal again.

starbrights commented 2 years ago

I am running it without playservices, but with microG instead. It seems not support it's push service,

It does. But sometimes it cannot interact with the MicroG services on installation and not working with them after that. If so, try uninstall and install Signal again.

Maybe stupid question: Uninstall - will it delete all my data? Do I need to back it up before with this long key?

starbrights commented 2 years ago

The answer is yes, uninstalling deletes data. You have to backup before and recover with this huge key. But the good news, indeed it uses GCM now and that seems to be (just for a short test) a little better for battery consumption. I'll watch that.

Mr-Bajs commented 1 year ago

Certainly using UnifiedPush would be a nice option.

barrahazard commented 1 year ago

Pixel 6a, GrapheneOS 13, no GSF or Google play services, Signal 6.11.7 (121302) used 9% battery in 3 hours while idle - I haven't even opened the app.

Please prioritise this issue, I am getting close to uninstalling the app because of this issue.

gilou commented 1 year ago

This is still a very annoying problem, I do have the same behavior on CalyxOS 4.6.1 (Android 13), running Signal 6.1.x versions, no microG notifications.

UnifiedPush would be a nice feature, but that will require code server-side… That would be welcome though ;)

Signal is litteraly emptying my battery in less than 5 hours if I let it on. What saved me was that since it's not managing SMS anymore, I can actually restrict its battery usage. But I also would like to get Signal calls and messages a bit more faster than when I think about starting the app…

gilou commented 1 year ago

UnifiedPush probably is a great solution for the server part, using the FCM fallback… It was proposed somewhere around there: https://github.com/signalapp/Signal-Android/issues/11154

CommonLoon102 commented 1 year ago

My solution is a 20000mAh power bank in my backpack. Drain that, Signal!

gilou commented 1 year ago

Well I mean, the 100 AH battery I have in my van helps working around it for sure…

cautious-bread commented 1 year ago

Adding my voice here (and to another logged issue) instead of creating any new ones. Excessive battery drain since one of the recent updates. Been holding off in case the issue resolved itself.

Google Pixel 6a. Graphene OS. No Play Services - just the "background connection" web sockets notifications. Installed using the APK from Signal's website. Currently version 6.20.5 but was also happening on the previous release.

Debug logs: https://debuglogs.org/android/6.20.5/37d0a416e8d034d2d89baf8d15996f5aae2ef0f0ec20a34cce018392b9574852

zmetzing commented 1 year ago

Giving up. Moved to Molly.

gilou commented 1 year ago

How good is Molly without Firebase for battery / notification? That might be a hint at what needs to be done …

Bean-Beret commented 1 year ago

With Molly, I encounter the issue as well (Fairphone, /e/ OS without gapps/microg

Kariton commented 1 year ago

Hello Signal team and fellow users,

I wanted to share that I also experience rapid battery drain, which I accepted as a normal occurrence until I discovered a "real" solution. While searching for other information, I came across the fascinating world of ntfy and UnifiedPush. :)

During my exploration, I stumbled upon various links, issues, and forum posts, including one discussing Molly's excessive battery drain. Fortunately, there is a recently proposed solution for this problem in the form of a PR for their fork. https://github.com/mollyim/mollyim-android/pull/152

However, there is one minor inconvenience associated with this solution. Since the Signal server doesn't currently support UnifiedPush, it is necessary to run a "socket server."

To summarize the PR:

When UnifiedPush is enabled, Molly (android) creates a linked device without encryption keys then sends the linked device's credentials to MollySocket (*).
MollySocket connects to the Signal Server websocket with the linked device's credentials. Every time MollySocket receives a(n encrypted) event, it notifies Molly via UnifiedPush and Molly fetch the new messages (*).

* Modulo the configuration

Given my limited programming knowledge, I am unable to assess the quality of this pull request or determine the complexity of implementing it on the server side. However, if it were to be successfully incorporated, it would undoubtedly elevate the FOSS variant to a new level. The implementation of UnifiedPush does have the potential to enhance the functionality and user experience a lot.

I think this FCM alternative has the potential to gain significant traction and become a valuable new standard for the FOSS android community. Its ability to provide an alternative push notification solution and its integration already done in various applications, such as Element, Fedilab, FindMyDevice, and possibly even Nextcloud (which does already have an additional app to support UnifiedPush - but someone is already working on a popper integration within the "Notification" app), among others, indicates a promising future.

I hope you will consider it as an option. It would be gorgeous if signal officially integrates UnifiedPush.

p1gp1g commented 1 year ago

If the signal team is interested in this solution : the "socket server" (named mollysocket) would not be necessary if the signal server supported WebPush (UnifiedPush is compatible with WebPush). The desktop client may be able to benefit from this WebPush support too.

ismay commented 1 year ago

I think by now it's safe to assume that this is not a priority for the signal team. The google free sync could be implemented with universal push. Element allows it and it uses barely any battery. Whereas signal without google frameworks burns through my battery in less than a day. Without signal (and with element and ntfy btw.) my phone lasts 3 - 4 days.

gilou commented 1 year ago

OK, I switched to molly + mollysocket, that helps a lot.

Now, if we were to try and merge that into Signal, we'd need to provide the appropriate change to hack on the Signal Server … And if the codebase on https://github.com/signalapp/Signal-Server is actually the one we should take as what they run…

ismay commented 11 months ago

Yeah I think that without any feedback from the signal team this will be hard to address. There have been several discussions on this and similar topics in the past. Quoting from one:

the problem in this case is that moxie0 is the opinion that it is quite unnatural to use an android phone without google apps and therefore he doesn't support this situation. He accepts code for GCM-free devices, but has no interest in developing it. (from https://github.com/signalapp/Signal-Android/issues/6732#issuecomment-355126942)

I can imagine that this is still the core problem for signal. Maybe signal will be open to PRs, but at the very least android phones without GCM do not seem to be a priority.

CommonLoon102 commented 11 months ago

Unnatural? What about this? https://www.cnbc.com/2023/12/06/apple-and-google-phone-users-spied-on-through-phone-push-notifications.html

Mr-Bajs commented 11 months ago

Unnatural? What about this? https://www.cnbc.com/2023/12/06/apple-and-google-phone-users-spied-on-through-phone-push-notifications.html

Signals Meredith responded to this https://mastodon.world/@Mer__edith/111563866152334347

In signals case the notification only ping signal on the phone to wake up the signals notifications so then the signal app then fetches data such as the message and from whom etc through signals encrypted serversand not through googles or apples systems. Though i dont think many apps are constructed to work like this and send alot of data through their servers, hence thats why governments wants to spy on them.

That's atlest how I have understood it works.

gilou commented 11 months ago

Well, this does not relate directly to the issue at hand, but the problem about using Firebase/Google for notifications is not only the content and the privacy for communication. It's about letting Google know that you are using Signal, and that you are getting activity. That being tied to your terminal ID. No matter how laws and contracts can "protect" you, the data is there. And enough to be an issue for some users.

Again, that is a bit off-topic, as this has not much to do with the battery issue, though incidently, enabling UnifiedPush would get that extra privacy feature in.

ismay commented 11 months ago

@gilou Exactly. Though in a way it kind of relates to this question. After all, signal advertises itself with:

Speak Freely [...] An unexpected focus on privacy, combined with all of the features you expect.

Both google and apple's policies are not very compatible with a private user experience. It is a hostile environment for that usecase. I do trust that signal does its best to provide the user with as much privacy and security as possible within those frameworks. But why not provide better support for an experience that depends less on google or apple?

We might get this specific issue fixed, but in the long run I think the no GCM usecase would require more attention from the signal core team and a move towards a more open, less centralized approach. Anyway, maybe that is a topic better discussed in a separate issue.

d3nnis77 commented 11 months ago

Unnatural? What about this? https://www.cnbc.com/2023/12/06/apple-and-google-phone-users-spied-on-through-phone-push-notifications.html

Signals Meredith responded to this https://mastodon.world/@Mer__edith/111563866152334347

The respones gets further and is infuriating: https://mastodon.world/@Mer__edith/111563867509198309

Apple simply doesn’t let you do it another way. And Google, well you could (and we've tried), but the cost to battery life is devastating for performance [...]

Seriously? First I would like to know, where they tried to implement another push-service and second, why they say it is not possible after the community has done it successfully (Molly-UP) without "devastating battery performance" (at least as a proof-of-concept).

It´s either a plain lie for a cheap excuse or they admit that they aren´t able to make this work. And I don´t believe it´s the second. The silence from the devs in this issue and on the forum speaks for itself.

ismay commented 11 months ago

Seriously? First I would like to know, where they tried to implement another push-service and second, why they say it is not possible after the community has done it successfully (Molly-UP) without "devastating battery performance" (at least as a proof-of-concept).

It´s either a plain lie for a cheap excuse or they admit that they aren´t able to make this work. And I don´t believe it´s the second. The silence from the devs in this issue and on the forum speaks for itself.

Yeah the terrible battery performance seems to be mostly Signal's fault. Not just Molly, but also https://conversations.im and https://element.io are able to do quite well without GCM.

ismay commented 11 months ago

The respones gets further and is infuriating: https://mastodon.world/@Mer__edith/111563867509198309

This is a very interesting thread actually. Lots of people there asking for unified push, mentioning that the battery impact is not that great. I also would like to see a comparison between the battery cost of a proper universal push implementation, versus the battery life saved by not having google play services installed.

Mr-Bajs commented 11 months ago

The respones gets further and is infuriating: https://mastodon.world/@Mer__edith/111563867509198309

This is a very interesting thread actually. Lots of people there asking for unified push, mentioning that the battery impact is not that great. I also would like to see a comparison between the battery cost of a proper universal push implementation, versus the battery life saved by not having google play services installed.

Wouldn't be rather hard to compare? That would depend on how may apps are using unifiedpush? The energy save with unified push comes when you use several apps with unified push doesn't it?

jm355 commented 11 months ago

The energy save with unified push comes when you use several apps with unified push doesn't it?

In some part yes, but also some always-on notification listeners are more efficient than others. For example, tuta has their own independent notification listener that takes almost no battery, while signal has an independent one that's a battery hog. So I could have a bunch of apps with independent efficient ones like tuta and still use less battery than one unified-but-inefficient one that's as inefficient as signals.

A benefit of a unified one (besides only needing one listener in the first place, like you said) is it lets the best listener solution be found by a team focusing on that problem, and then everyone can instantly benefit from it

ismay commented 11 months ago

I can imagine it would be. I don't think unified push can realistically be more energy efficient than GCM. But I can imagine that a phone with signal using universal push, without any google services, could have similar battery life to a phone with GCM and play services.

But my core point is the ethics of it all, I care less about my battery. After reading this comment by moxie:

I understand that federation and defined protocols that third parties can develop clients for are great and important ideas, but unfortunately they no longer have a place in the modern world. Even less of a place for an organization the size of ours. Everyone outside the FOSS community seems to know it, but it took actually building the service for me to come to the same understanding, so I don't expect you to believe me. https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217339450

I think that signal's goals just don't align with mine. Anyway, I'll stop derailing this thread.

Neustradamus commented 4 months ago

The situation has changed?

dataprolet commented 3 weeks ago

This is still an issue! Device: Google Pixel 7a OS: GrapheneOS (no Google services, no MicroG) Android version: 15 Signal version: 7.21.5

HasBert commented 1 week ago

I'm getting 5 messages a day, isn't it somehow possible to give the user a setting for "Polling Interval" where I can define it for my own, if I don't use Google Play Services?

I am waiting for a answer to this problem for 2 years, now. It's hilarious how bad the communication of the devs and the Signal Foundation is in here. Here are so many people willing to help, but just noone cares.

signalapp / Signal-Android