Signal consumes half of my battery (no google services or microG) #9729
Comments
|
Can you say if disabling battery optimization still doesn't improve anything? |
Battery optimization is already off, and I can't turn it on anyway (the option is grayed out) |
|
40 ? I got 108 % lol |
|
Update: I switched to wifi recently instead of 4g, and the battery consumption has been much better since. Here's the debug log in wifi: https://debuglogs.org/826d0a11eed1b55bbaf8d858247cae6615a7f74f3efe3a99d091d700371ead10 I switched back to 4g: https://debuglogs.org/68c5e8bba6b9c80ae09e996b91e4059e7c9c5fe410c9b92afb0babe56057b8ad and I had 4 of these errors in 30 minutes. |
|
Update : I reinstalled GrapheneOS (without Google Services / MicroG) and Signal this week and the behavior is strictly the same as the one reported in this thread. Last month, when I tested GrapheneOS and therefore Signal above, I encountered the same problem : excessive battery consumption. |
|
I have the same problem with Signal 4.67.3 (6802), battery usage by the app is very high. There are a lot of "java.io.EOFException" . It looks like 55000ms keep alive alarm is not working. |
Update. This problem and this message were caused by additional app to force Doze mode. However, even with 55000 ms timer working, battery drain is about 1%/hour. At that, there are two threads, that awake in 55 sec timeout each (you can see it in log), and after some period of running they "loose synchronization", so device wakes twice in a 55 sec. It seems they are running in IncomingMessageObserver class inside of localPipe and unidentifiedLocalPipe objects. |
|
Same problem for me with Signal 4.69.6 on a Nexus 5X |
|
Isn't this a duplicate of #8658 ? |
|
same problem, ( wifi only no problems )
|
|
My excessive drainage disappeared after downgrading to a version of omnirom without microg. (No gapps) |
|
After having had this issue on several lineageOS and a shiftOS-L device (all without gapps) I looked at the corresponding implementations of other opensource android messenger apps. As a test, I tried to replicate something similar in Signal: Close websocket connection if backgrounded, reconnect every 5 minutes or while app is in foreground. This mitigates the problem somewhat. With this method Signal still uses 3 to 5 times more battery than other messenger apps, but it came down to around 12% from 60% or more on a full charge of my samsung s6 with lineageOS (opening connection every 5 minutes). This is still not good but bearable: Bean-Beret@fda5ebe Downside to a polling mechanism like this is, that voice calls will be missed if the app is running in background (it will notify about a missed call as soon as it is polling, however. This will not be a replacement to the method Signal implements. People may prefer to have instant delivery of messages and calls over battery efficiency. However, it could be an alternative: What I could think of, is offering an advanced option to enable a such a method of periodic connection, instead of the original method (only if no gapps are detected). So people with the battery drain problem could chose it if they want. I know that Signal does not want more options by development ideology and implementing a mechanism like this might not be a solution to the root cause of the problem, but thinking of this issue being present since years and popping up again all the time, a workaround could be appropriate. |
|
There is an idea, how decrease power consumption without breaking calls. So, it seems for now battery consumed because of two reasons:
Reason 1 exists in Googled phones also, and, it seems, it doesn't consume too much battery. I have the following suggestion: Use UDP instead of TCP to check notifications. In this case Signal will wake up, send a keep alive packet and go to sleep while waiting for a response. Server can send keep alive response in the same moment when request received, or, may be, await for 30 seconds before sending it, or, may be doesn't send it at all (if one-way "ping" is enough to keep mobile connection on). In other words I suggest implement something like Google push notifications for one specific app without using Google servers. |
|
Also have those battery drain on a Huawei phone (P40) without GMS... Would also prefer a better battery life over instant notification. 👏 |
|
Using UDP is actually a good idea. Probably that's they way whatsapp does it, where delays were never an issue, but we will never know... However, I created a build with the above-mentioned workaround (periodic fetch) based on @tw-hx FOSS fork, which also lets you send locations on de-googled devices using OSM. It still is a hacky "fix", but if you like, you can kick the tires: There is a branch with 5 minute and one with 10 minute periodic fetch. On a shift5me phone with shiftOS-L the 5 minute version was enough to get the battery drain lower than the one of threema or telegram. On a galaxy S6 with lineageOS 14 the 10 minute version is necessary to do the same. I do not find enough time right now to work on this to derive a proper feature/pull request. So if anyone would like to catch up from here, please do. |
|
One more suggestion. Signal with MicroG services doesn't consume battery. Phone battery drain in sleep state reduced about 3 times comparing to that one without GAPPS/MicroG. |
|
Samsung S7 on wifi. I chatted a buddy around lunchtime. We exchanged a couple of memes. Now, 3 hours later, this. |
|
All good points and I find very high websocket battery use too. The underlying issue appears to be that some mobile networks don't exempt Signal's connection from early closure (they do for Google and a few others) so Signal has to send keepalives every 55 seconds. Both the server and the client have a short idle timeout ~1 min. Two potential fixes:
|
|
Same issue. Pixel 2. Graphene OS no google. Signal uses 10% of battery in 4 hours. Phone was 100% charged and sitting idle and unused. No option to optimize battery use as its greyed out. |
|
I'm running Signal with MicroG and still see a significant idle drain that only goes away once I use Greenify to hibernate Signal. So I can't really confirm that everything's fine wiht MicroG running as a Play services replacement. |
May be Signal is not using MicroG in your case? Check the "FCM" status in Signal log, it should be "true". If it's not, you can try reconfiguring MicroG or reinstalling Signal and reregister on server. |
The log is indeed showing FCM as "false". I'll try to change that and report back :) |
|
Problem still persists if not connected to WiFi. Pixel 5 with GrapheneOS, no Google. |
|
With MicroG Signal needs to be forced to use it on my device via However since a few months Signal then unregisters itself every few weeks. So I guess that setting breaks something else. |
|
Signal is also draining my battery super fast. The log isn't conclusive. Sometimes it seems to wake up right after setting the timer and then there's lots of garbage location ongoing: |
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? |
|
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. |
|
Certainly using UnifiedPush would be a nice option. |
|
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. |
|
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… |
|
UnifiedPush probably is a great solution for the server part, using the FCM fallback… It was proposed somewhere around there: |
|
My solution is a 20000mAh power bank in my backpack. Drain that, Signal! |
|
Well I mean, the 100 AH battery I have in my van helps working around it for sure… |
|
Adding my voice here (and to another logged issue) instead of creating any new ones. Google Pixel 6a. Graphene OS. No Play Services - just the "background connection" web sockets notifications. Debug logs: https://debuglogs.org/android/6.20.5/37d0a416e8d034d2d89baf8d15996f5aae2ef0f0ec20a34cce018392b9574852 |
|
Giving up. Moved to Molly. |
|
How good is Molly without Firebase for battery / notification? That might be a hint at what needs to be done … |
|
With Molly, I encounter the issue as well (Fairphone, /e/ OS without gapps/microg |
|
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. mollyim/mollyim-android#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:
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. |
|
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. |
|
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. |
|
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… |
|
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:
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. See also: #7014 |
|
Unnatural? |
Signals Meredith responded to this 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. |
|
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. |
|
@gilou Exactly. Though in a way it kind of relates to this question. After all, signal advertises itself with:
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. |
The respones gets further and is infuriating: https://mastodon.world/@Mer__edith/111563867509198309
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. |
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? |
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 |
|
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 think that signal's goals just don't align with mine. Anyway, I'll stop derailing this thread. |
and others
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
Actual result: Signal takes between 40 and 50% of battery life
Expected result: Signal should take ~10% of battery life
Screenshots
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
The text was updated successfully, but these errors were encountered: