Signal-android: 4.25.10 - Heavy battery drain even with minimal usage

[flipzmode]

• [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

Ever since upgrading to 4.25.10 about 2 weeks ago I have seen heavy battery drain. I am a longtime Signal user (around 3 years) and have never had battery drain issues like this. Even with minimal Signal use, it is listed as the app that drains the most battery every day. Nothing on my phone changed other than Signal updating.

Steps to reproduce

• Can't really say how to reproduce it. This started happening as soon as I updated to 4.25.10.
• I did try disabling Signal as my default SMS app just to see if it helped somehow, but it's still the same.
• I have also restarted my phone and cleared out lots of old messages just to see if it somehow helped.
• This does not appear to be related to #7839 which is not only fixed already, but also I'm not having any issues with performance. But I did switch to system emoji to test and it didn't help any.

Actual result: Even with very low usage, Signal drains more battery than every other app on my phone.

Expected result: Battery drain should be minimal.

Screenshots

Device info

Device: LG V35 Thinq (AT&T)

Android version: 8.0.0. Security patch level July 1, 2018
Signal version: 4.25.10

Link to debug log

Debug log

[haaveilen]

I am having exactly same problem on Moto Z Play (2016). Also running 8.0.0.

The drain is serious (it drains about 30% of all battery, with almost no use. I hope it gets fixed asap.

[greyson-signal]

@flipzmode Is it accurate that you actually had 30 min of active use of Signal at that time? If so, it would seem that relative to other apps its battery usage is fine. It would have been run 10x more than the next most-used app, but using less than 10x the battery as the next app. If 30 min isn't accurate then that's a problem.

In general, the only good way to debug battery issues is to get something called a "bug report" from the system that can then be viewed in a tool like battery historian. However, those reports contain a full profile of all of your app usage, so I recommend against posting them on a public forum. Instead, if either of you are interested in providing a bug report to help diagnose this, you can DM me on the forum where I can give you more instructions.

Thanks!

[flipzmode]

Hey @greyson-signal, I'll work with you on getting a bug report from battery historian. I'm doing my best to try and pinpoint the best way to replicate battery drain. Meaning where I know I'm not using Signal, but it is draining. I've spent a few days out of work and so my usage has been different than normal.

I am curious if @haaveilen uses the Signal desktop app at all. I use it heavily all day on Windows and I'm just realizing I'm wondering if that's part of why battery drain seems worse than usual. It used to be that if I was using the desktop app then I wouldn't receive a notification of an inbound message on Android right away. If I was actively using the desktop app and replied to a message fairly quickly, it would never notify on my phone. At some point it changed and now I get notifications on my phone and on the desktop at the same time. I believe this could be a source of extra battery drain from Signal. I don't know if that's something related to Android 8.0, or Signal Desktop, or Signal Android.

I'll get signed up on the forums soon and send you a DM. Thanks for the reply.

[greyson-signal]

If I was actively using the desktop app and replied to a message fairly quickly, it would never notify on my phone. At some point it changed and now I get notifications on my phone and on the desktop at the same time.

So technically your phone would always _receive_ these notifications, we'd just display them silently. However, with the new changes to notification channels, these notifications will now make a noise, which is a known bug. So my gut tells me this isn't the source of the drain, but we'll see!

Looking forward to your DM. Thanks for assisting with this!

[haaveilen]

Hey @flipzmode, no I am not using Signal for desktop. I am regular user on Android. It seems like drain is not consistent as well (sometimes drain is more agressive, sometimes less). As of now I had actively used Signal for 25 minutes, it had drained 650mAh of battety, for instance Facebook that I used 1 hour, drained only 180mAh. Thank you for your input.

[greyson-signal]

FWIW I just used the new energy profiler in Android Studio 3.2, and I didn't notice any oddities on the couple phones I tested (Pixel 2 and Nexus 5X). Battery drain was classified as "light" when the app was open, and was basically non-existent when the app was backgrounded. I'm also not experiencing this battery drain in my day-to-day. So at minimum this seems to be situational or device-specific.

The only thing in 4.25.x that could impact energy usage IMO is the new logger that logs to a file. I imagine it's possible that some phones are really energy-inefficient when writing to files or something. Anyway, I'll need a bug report to get more details.

Thanks!

[gkkovacs]

@greyson-signal I've had a similar experience with 4.25.x, and now with 4.26.2 as well. According to the system battery settings, Signal now uses a similar amount of juice for 30-40 times less screen on time compared to Messenger (which I am a fairly heavy user of).

Device: LG G7 Thinq
Android version: 8.0.0. Security patch level July 1, 2018
Signal version: 4.26.2

Please tell me if I can give you any specific info to debug further.
The two screenshots are taken 4 days apart;

[greyson-signal]

@gkkovacs Thank you for the report. As mentioned in my first comment, it's good to know this is happening, but there's no action for me unless I have a Bug Report. A debug log taken at the end of the day may even be helpful to see what kind of work may have been taking place, but a Bug Report is much more useful for battery stuff. Refer to my earlier comment for details. Thanks!

[prg318]

Running into this issue on Android 9. I hardly ever even use Signal but when investigating saw that Signal is constantly in use in the background according to Android 9 battery statistics.

[greyson-signal]

@prg318 At minimum I'd need a debug log to see if anything is happening in the background. I'm also curious if you're in the beta. The beta bumped the targetsdk to 26, meaning we should have fewer opportunities to run in the background when we're not supposed to.

Anyway, besides a debug log, as mentioned in an earlier comment, to do any real analysis I'd need a bugreport.

[aaroecker]

I'm having the same issue. Here's my debug log:

https://debuglogs.org/41523615184aa9a2b9fcfe079c3b0d566be51c312d2445f7eef3678f486b01de

[greyson-signal]

@aaroecker Thanks for submitting a log! Looking at it, it seems like you're getting tons of contact sync requests from desktop and that you're likely in poor network conditions (because those requests keep failing). Can you tell me if you have a desktop instance you're keeping open, or if you were requesting a lot of contact imports on desktop or something?

[aaroecker]

I don't know, but I shouldn't anymore. I deteled signal from my phone and on my PC. I'm going to try a new install to see if that helps.

[aaroecker]

@greyson-signal thanks for looking into this.

[greyson-signal]

Ok, if this happens again, please send a desktop log along with your Android log. Might be some weird interaction where poor network on desktop caused a ton of contact syncs to go out. Thanks!

[gkkovacs]

It still happens for me with Signal 4.29.7 on LG G7, Android 8.0. Signal used 22% battery with 2 minutes of screen time.

Debug log:
https://debuglogs.org/6f974cd13bc269e5cba12d25971649824f54271c82d0429fe0ba8e9bebc3a52f

[greyson-signal]

@gkkovacs Huh, yeah, according to the logs Signal hasn't been used much at all. If we're doing something, there's usually some trace in the logs, so it's odd that we'd somehow be doing things in the background. Did your problem happen within the last two days? (That's the amount of time covered by the log).

[haaveilen]

I am pretty sure its affecting only certain chipsets, on my Moto Z Play OG (Snapdragon 630, 8.0.0 Oreo), drain issue was there, on my Moto Z OG (Snapdragon 820 8.0.0 Oreo) there is no drain issue.

I unfortunally can't send you any logs from Moto Z Play, coz it broke after falling down to the ground. However my friend with Moto X4 has the same problem, and I hope I can make him send debut log.

A bit offtopic but, do you maybe know why solid black background on Signal for Android was removed in dark mode? It was really nice with combination of OLED phone. Thank you.

[gkkovacs]

@greyson-signal Yes, what you saw was yesterday, I always take the phone off the charger in the morning. According to the system battery stats Signal is by far the biggest battery hog with 22% battery used, but interestingly it only ran 2 minutes in the foreground, and 0 in background:

[greyson-signal]

@gkkovacs That's super interesting and odd. This is a case where it'd be really helpful to have a bugreport. To quote myself from earlier:

In general, the only good way to debug battery issues is to get something called a "bug report" from the system that can then be viewed in a tool like battery historian. However, those reports contain a full profile of all of your app usage, so I recommend against posting them on a public forum. Instead, if either of you are interested in providing a bug report to help diagnose this, you can DM me on the forum where I can give you more instructions.

If you could hep out, that'd be great! Thanks!

[ivanbistrovic]

The problem is also happening with latest Signal on Samsung Galaxy Grand with Android 4.4.4 as well as on an Iphone 8. I had that problem ever since I started to use Signal, several months ago.
Debug from Samsung, Signal v4.27.4
https://debuglogs.org/82ab0f13caed8bc87e9e68ca7a8c5cddf5b891a47fdddb152362191a9b3d671a

[JVanDenBergh]

I also experience fast battery draining on my Fairphone 2 (Fairphone OS 18.04.1, Android 6.0.1);
my battery in went from full charge to no chare in about 4 hours instead of over 24 hours.

I uninstalled the app today and fast draining disappeared, but Google Play still had version 14.30 listed for update. The issue started to appear in the night of November 8-9, just after some updates.
I don't remember whether these updates included Signal. I remember I received some updates from Google apps, but I don't remember whether I received an update for e.g. Google Play Services.

The issue seems to be in the background services as I hardly used the app.
On most days there was 0 foreground usage and no messages arrived (even when on some days one or more message should have arrived).

[landry314]

I am using Signal v4.30.8 and I just noticed this same problem as well which is why I found this thread... Check my screen shot, it says Signal has been in ACTIVE use for 5h 25m and in the background for 0m since last full charge. THIS IS NOT EVEN REMOTELY TRUE. It is in the foreground for a small portion of time and in the background most of the time.

What is going on here?

[greyson-signal]

@jvandenbergh @landry314 It's really difficult for me to say anything about what may be happening without either a debug log or a bug report. Bug reports are the most useful thing, but please read my earlier comments in this thread for my warnings about what they contain. Thanks!

[3point2]

Hi @greyson-signal , I'm having the same issue.
I loaded a bug report file into battery historian and am attaching some screenshots of the results below. Let me know if you need more information and I'd be happy to provide it. If you need the full bug report, please DM me.

• graph, the issue starts at 1pm. When hovering over the blue "userspace wakelock" bar, battery historian suggests that I enable full wakelock reporting with adb shell dumpsys batterystats --enable full-wake-history. I have now enabled it and will take another bug report the next time this issue occurs to capture the extra info.
• app stats tab for org.thoughtcrime.securesms
• system stats tab
• system stats tab details. The *overflow* is odd, I confirmed that it appears verbatim in the bug report and isn't introduced by battery historian.

[greyson-signal]

@3point2 Thank you so much for the bug report screenshots! That's super interesting. Can you get me a debug log? It looks like WorkManager is holding a lock for too long, and it appears they have the Worker ID in the wakelock name, so if I had a debug log I could potentially match it up and see what job it's getting stuck on. Thanks!

[blkeller]

Hello @greyson-signal. I too am experiencing this battery drain issue, and I've taken a bug report. I tried to send you a DM on the Signal Community forums to get the report to you, but I don't think I have permission to do so, since I just created my account there two seconds ago and I appear to be restricted from sending any DMs.

Is there another channel by which I can privately send you my debug report?

Also, to corroborate what @3point2 reported, Better Battery Stats on my device is also showing *overflow* as the offending wakelock holder:

[greyson-signal]

@blkeller You can send the report via Signal to one of my test numbers: [phone]. Thanks!

[3point2]

@3point2 Thank you so much for the bug report screenshots! That's super interesting. Can you get me a debug log? It looks like WorkManager is holding a lock for too long, and it appears they have the Worker ID in the wakelock name, so if I had a debug log I could potentially match it up and see what job it's getting stuck on. Thanks!

Glad it was useful! I've messaged the bug report that I used to generate the screenshots to your test number. I didn't experience the issue today, but when I do I can follow up with another with adb shell dumpsys batterystats --enable full-wake-history enabled. Let me know if any other information would be helpful and I'll do my best to provide it.

[greyson-signal]

@3point2 Thank you! Do you think you could send me a debug log? It's separate from a bug report. This is a signal-specific thing that you can get in Settings > Advanced > Submit debug log. Thanks!

[blkeller]

@greyson-signal I just sent my bug report to the Signal number you provided. I also added a debug log for good measure.

Please let me know if I can provide any more information. I seem to be able to reliably reproduce this issue 100% of the time, even if I end all Signal tasks and restart the app, so I can probably poke and prod at this thing a bit more, if necessary. Thanks.

[3point2]

@3point2 Thank you! Do you think you could send me a debug log? It's separate from a bug report. This is a signal-specific thing that you can get in Settings > Advanced > Submit debug log. Thanks!

Ah, I wasn't aware that existed, sent! I don't see ea1f410a-6bd3-4eba-af3b-839b1cb84958 in it, but I might be missing something. Next time I experience the issue I'll do a debug log and bug report at the same time to hopefully get a worker ID match.

[greyson-signal]

@blkeller Unfortunately bug reports from 4.4 devices aren't super detailed, and the information battery historian shows is limited :( It does, however, seem like there were a few blocks of ~30min where a wakelock was held, which looks suspicious and aligns with @3point2's bugreport.

It's possible this is a bug where WorkManager is holding on to a wakelock for longer than necessary.

@3point2 Thank you for the log! Unfortunately it looks like it only covers ~3 hours, so we missed the ID, but it's ok, we'll get it next time :)

[3point2]

@greyson-signal I have a potential candidate for you: MultiDeviceReadUpdateJob.

From the Android bug report file:

11-28 23:28:12.946  2043  2086 W PowerManagerService: Suspicious wakelock held 2078356ms when sleep: lock=687848900, flags=0x1
, tag=WorkManager: 081426f2-4295-4abb-8098-afbac56b3848 (1), ws=null, uid=10119, pid=10670
...
11-28 23:56:40.569  2043  2086 W PowerManagerService: Suspicious wakelock held 3733006ms when sleep: lock=687848900, flags=0x1
, tag=WorkManager: 081426f2-4295-4abb-8098-afbac56b3848 (1), ws=null, uid=10119, pid=10670

Loading the bug report into battery historian helped me confirm that the start time of the wakelock for WorkManager 081426f2-4295-4abb-8098-afbac56b3848 approximately matches (~5s) the first entry for the same worker ID in the Signal debug log below (see the "Actual event times" section of the popup in the screenshot. Battery Historian displays UTC whereas the Signal log timestamps are in my local timezone of UTC+2, hence the 2 hour difference).

From the Signal debug log

2018-11-28 22:43:03.438 EET I Job: 
[081426f2-4295-4abb-8098-afbac56b3848] MultiDeviceReadUpdateJob :: 
onSubmit()
...
2018-11-28 22:43:04.134 EET I Job: 
[081426f2-4295-4abb-8098-afbac56b3848] MultiDeviceReadUpdateJob :: 
Successfully completed. (Time since submission: 716 ms, Run attempt: 0, 
isStopped: false)

There are no further occurrences of 081426f2-4295-4abb-8098-afbac56b3848 after that, but the wakelock persists in the Android logs. There are subsequent runs of MultiDeviceReadUpdateJob with different worker IDs that don't leave their wakelock behind. Despite the fact that MultiDeviceReadUpdateJob runs multiple times, I haven't (yet) seen WorkManager leak more than one long-running wakelock.

As before I'll send the debug log and bug report to your test number.

Speculating on the name MultiDeviceReadUpdateJob, I wonder if using multiple devices (I use Signal Desktop) is required to trigger this bug?

It might also be worth checking if Android Vitals is alerting to these stuck partial wakelocks via Signal's Google Play Console?

Hope this is helpful, let me know if you need any further info.

[3point2]

@greyson-signal Today another long wakelock, but this time the ID links to TrimThreadJob :thinking:

The Android bug report starts with T=0 at 09:00:52 when I unplugged my phone from its charger:

Battery History (10% used, 27KB used of 256KB, 178 strings using 12KB):
                    0 (9) RESET:TIME: 2018-11-29-09-00-52
...
                    0 (2) 100 c2500020 wake_lock_in=u0a119:"WorkManager: 273838d0-753b-40ea-8f49-86cbf44e90c4 (5)"
...
         +42m16s549ms (2) 093 c2100020 -wake_lock_in=u0a119:"WorkManager: 273838d0-753b-40ea-8f49-86cbf44e90c4 (5)"

The Signal debug log shows the wakelock has actually existed since 01:07:49:

2018-11-29 01:07:49.570 EET I Job: [273838d0-753b-40ea-8f49-86cbf44e90c4] TrimThreadJob :: onSubmit()
2018-11-29 01:07:49.670 EET I Job: [273838d0-753b-40ea-8f49-86cbf44e90c4] TrimThreadJob :: doWork() (Time since submission: 109 ms, Run attempt: 0, isStopped: false)
2018-11-29 01:07:49.692 EET I Job: [273838d0-753b-40ea-8f49-86cbf44e90c4] TrimThreadJob :: doWorkInternal() (Time since submission: 109 ms, Run attempt: 0, isStopped: false)
2018-11-29 01:07:49.696 EET I Job: [273838d0-753b-40ea-8f49-86cbf44e90c4] TrimThreadJob :: Successfully completed. (Time since submission: 109 ms, Run attempt: 0, isStopped: false)

Given that the issue is happening with more than one job and that in both cases I've seen so far the job reports "Successfully completed", it's probably not an issue with the logic of any particular worker(s). My guess is some sort of problem in the interaction between Signal code and WorkManager that's preventing WorkManager from releasing the wakelock after the job completes (maybe a reference to something being hung on to when it shouldn't?).

I won't spam you with yet another bug report & debug log, let me know if you'd like me to send them over.

[letkan]

I'm on v 4.30.8 from app store on a rom with no gapps, battery not optimized. The rom is AEX 5.8 (android 8) the device Xiaomi Mi4c.
Network usage without no app usage is 1.5MB in 8 hours, just standby. This is just insane. At the same time Whatsapp doesn't even show in BetterBatteryStats/Network although I used it a bit for chat. Alarms Signal: 379, Whatsapp: 111 during the same 8 hours (whatever those alarms mean, fire, floods..). So the network usage is gone mad, check that. I noticed that with the past few releases, maybe since 4.25.x..
I just turned off syncing contact to see if it makes a difference but this is a serious bug, 1.5MB network traffic in 8 hours with no usage can't have a plausible explanation. Most I can do is send the log from within the app if it doesn't reveal personal info (you let me know) but I really doubt that with all these complaints you guys can't reproduce this on your own devices.

[greyson-signal]

@letkan As noted several times in this ticket, I can't, in fact, reproduce this, despite having 10 phones on my desk and using every profiling tool available to me. That's why I've been requesting debug logs and bug reports throughout this thread.

Also, just wanted to clarify "1.5 MB". While ideally the app shouldn't be using any data when not in use, I don't think most people would be alarmed by 1.5 MB. That's about the size of one nice-ish photo, or a 1.5 minute MP3 file.

I can't say why Signal would be using network without a debug log (the log is, in fact, stripped of personal information like phone numbers).

But as a user with no gapps, I'm guessing the usage relates to Signal's need to keep an open websocket connection in a foreground notification due to you not having the ability to receive GCM messages.

[floogit]

Thanks @greyson-signal for working on this. And sorry if this is considered as further spamming this bug report: I add a debug log and two screenshots from the android battery information. Please note that this is also a phone without gapps, if you think this would better fit in another bug report let me know. I would still very much prefer to use signal over other messaging apps, but at the moment the battery usage of the phone is unfortunately by far dominated by signal (20% to 35% according to android's battery app, without any usage of signal). What seems strange to me is that other apps which should have the same "problem" as signal (to keep an open websocket connection to enable timely notifications) do use much less battery, while still receiving messages nearly instantly (telegram). This is why I post this here, in case that there actually is a bug which goes beyond the "having-no-gapps-installed" thing.

Link to debug log:
https://debuglogs.org/b6072666bdb0343e704252dbc9d73492bd63cb3076fbccfebbe58aad9c86e4ac

screenshots of battery app, for signal and telegram and the same time period (signal not being used at all, telegram used regularly):

[greyson-signal]

@floogit Looks like you're running into:

2018-12-01 15:51:54.000 MEZ W WebSocketConnection: java.lang.IllegalArgumentException: Receiver not registered: org.whispersystems.signalservice.api.util.RealtimeSleepTimer$AlarmReceiver@91ac80d
    at android.app.LoadedApk.forgetReceiverDispatcher(LoadedApk.java:1007)
    at android.app.ContextImpl.unregisterReceiver(ContextImpl.java:1330)
    at android.content.ContextWrapper.unregisterReceiver(ContextWrapper.java:608)
    at org.whispersystems.signalservice.api.util.RealtimeSleepTimer.sleep(RealtimeSleepTimer.java:51)
    at org.whispersystems.signalservice.internal.websocket.WebSocketConnection$KeepAliveSender.run(WebSocketConnection.java:320)

This is a "no-gapps"-exclusive problem, and it seems to be causing a frequent cycling of your websocket connection, which I imagine could cause increased battery usage. This actually looks like a symptom of a bug I've seen, so I've moved this over to #8402. Thanks!

[letkan]

Also, just wanted to clarify "1.5 MB". While ideally the app shouldn't be using any data when not in use, I don't think most people would be alarmed by 1.5 MB. That's about the size of one nice-ish photo, or a 1.5 minute MP3 file.
I take that as a joke.
Look, I just tried submitting a log from within the app but I'm getting network failure, is that log saved somewhere so that I can get it and post it here? BTW, after 5-7 failed attempts to submit the log BetterBatteryStats shows 13MB of network transfer. I installed Signal the other day since I changed my rom. This problem seems to affect only the more recent updates.

[letkan]

Sorry, just found the instructions, see attachment
bugreport-aosp_libra-OPM8.181005.003-2018-12-01-21-37-38.zip

[greyson-signal]

@letkan

I take that as a joke.

Sorry, that wasn't meant to be a joke. The level of concern you had made me think you may have meant to write "GB" instead, but I can confirm via the bugreport that your 1.5MB figure was accurate.

Otherwise, digging through your log indicates you're likely experiencing #8402. The socket may be thrashing, resulting in data being transferred to re-establish a connection.

Alarms Signal: 379, Whatsapp: 111 during the same 8 hours (whatever those alarms mean, fire, floods..)

Alarms are an Android construct that just means the app is requesting some action to be taken at a future time. For non-gapps devices, a community PR was made a few releases ago that uses alarms to keep the persistent connection alive, and it appears to be causing problems like this. But that's why you see so many alarms.

That said, your bug report indicates Signal didn't use much battery (~1%). But that's because you were on Wi-Fi. I imagine if this same behavior took place while you were on a mobile network, Signal would be keeping the radio active and using a lot more battery. On some level we can't do much about this on non-gapps devices -- no GCM means we just kinda have to keep this connection open. But the alarm registration problem shown in #8402 could be causing more reconnects than necessary.

Regardless, you can continue discussion for this in #8402.

[letkan]

@greyson-signal thanks for the thorough explanation, I'll check out #8402 too. Signal itself doesn't use much resources but the wifi being active all the time does. I experienced in the past excessive battery consumption #476 for similar reasons with Tutanota email client but somehow they managed to find a solution. The thing is, with GCM I'd be forced to use gapps which I won't, or I must get a phone with a bigger battery but I trust you will figure out something.

[landry314]

Well, I do have gapps installed, opengapps nano actually, on LineageOS 15.1 and I am still having this issue.

I am wondering if my denial of permissions for Google Play Services has something to do with this. It is possible my Signal app is not using google and instead websockets and I don't even know. How would I monitor this?

Does anyone know if some of the permissions for Google Play Services have to be on for Signal to use it? I have noticed no differences in how my phone works with the permissions off and I am under the impression those permissions are just for google to collect data. Am I wrong?

[Tamriel]

I have the same issue, with Root and without Google Play Services installed:

[andmars]

I have the same issue. Signal is draining more than 40% of battery. This is unacceptable and I hope this will get fixed. Otherwise I'll have to look for a different messenger like Threema, etc.

Phone: HTC One A9
OS: LineageOS 14.1 (Android 7.1.2)
Signal: 4.31.6
No Root, no Google Play Services or Opengapps

[3point2]

I haven't experienced this issue since my phone upgraded from Signal v4.30.8 to v4.31.6. 81055e6 might have been the fix.

[4mig4]

I still have this problem in 4.31.8 on a Huawei P20 Lite
I am using the at the same time to Linux App to, which dead slow

[albirs]

I have this problem too in 4.31.8 on LG G6 (h870).
Stock ROM, root, AFWall+ (UID1000 has internet connection), No PlayStore and Google services.

[andmars]

65% battery drain. Unregistering and deleting Signal right now. This is ridiculous!

Phone: HTC One A9
OS: LineageOS 14.1 (Android 7.1.2)
Signal: 4.31.8
No Root, no Google Play Services or Opengapps

[greyson-signal]

If you don't have Google Play Services, we have to keep a connection open to deliver push notifications in a timely manner, which will result in additional battery drain. It's not unexpected. It's hard to say _how much_ battery drain though. Battery usage is notoriously hard to test and measure.

But if you have Google Play Services, there's no reason for Signal to have crazy battery usage. It's just very difficult to figure out what can be happening. If you experience drain, at minimum please submit a debug log (Settings > Advanced > Submit a debug log) and post the link here. But what's really helpful is a bug report (I'll quote myself from earlier):

In general, the only good way to debug battery issues is to get something called a "bug report" from the system that can then be viewed in a tool like battery historian. However, those reports contain a full profile of all of your app usage, so I recommend against posting them on a public forum. Instead, if either of you are interested in providing a bug report to help diagnose this, you can DM me on the forum where I can give you more instructions.

Someone submitted a bug report earlier that indicated that WorkManager may have a wakelock bug that could result in battery drain. That's been reported directly to their team, and I'm updating to new versions as they release them.

[albirs]

hi greyson, are there alternative apps for "battery historian"? For me as a "normal user" the installation seems quite complex...

[albirs]

After waiting a wile whats happend with the new Version (4.32.8) and change from the WorkManager to beta1 seems all the same: Heavy battery drain from Signal ....

[bug report] -> mailed to [email protected]

Signal: 4.32.8
Device: LG G6 (h870)

Stock ROM (debloated) Oreo 8.0.0, root, AFWall+ (UID1000 has internet connection) and Blokada, Signal is white-listed, No PlayStore or Google services.

[albirs]

It seems that after a restart the phone there is no excessive battery consumption anymore for me ... [edit] seems only on wifi works correct. On mobile data i have heavy Battery drain again ...

[ghost]

There's a discussion about this heavy battery drain issue on the Signal forums - https://community.signalusers.org/t/very-high-battery-drain-on-4-34-8-without-google-play-services/6536/18

theBoatman posted a test build and it seems to have fixed the battery drain issue for me when on cellular (haven't tested Wi-Fi but it doesn't appear to be an issue on Wi-Fi according to @albirs). I've only been using it a day but unplugged my phone from the charger 10 hours ago and it's only eaten 30% of my battery with signal at 2% battery usage and 6m39s radio time which is A LOT better than before. I'd be at 30% battery left in 4 hours before.

Please test it out if you can and post your results here or on the forums, then ping @greyson-signal so that it can be implemented :).

[five-c-d]

ping greyson-signal so that it can be implemented

No, do not do that please. It is a waste of signal foundation money, and of Greyson's time -- surest way to lower the chances that pull#70 gets upmerged, is to pester and bother and waste the time of the person with commit-access. Do not bump issues and definitely please do not directly bother the paid signal foundation folks with pet issues.

I realize that there was a smiley attached, so that was perhaps only joking, but please realize that not everybody who reads github understand emoji that well (including me), or for that matter, understand english that well (also including me).

Please test it out [the pull#70 apk]

Yes please. This can be done on real physical devices (but it is experimental so please do not risk your main chat-history and your daily-driver device unless you know how to make an encrypted backup-blob as well as restore one and are comfy with the risks).

Also valuable would be tests against stock ROMs to make sure no unintended side-effects occur, including virtual SQA using the AndroidEmulator that ships with AndroidStudio for instance.

post your results here or on the forums

Yes please, ideally each person would

• capture a debuglog BEFORE installing experimental test-APK, i.e. from your normal setup,
• and then, kick the tires on the experimental test-APK for 24 hours or 36 hours or whatever,
• and finally, upload the URL of a 2nd debuglog.

Better to post these into the thread on signalUsers though methinks, to avoid github traffic about an unofficial experimental patch that has not yet been upmerged == https://community.signalusers.org/t/very-high-battery-drain-on-4-34-8-without-google-play-services/6536/43 is currently the best place probably.

[ghost]

It really sucks that the most privacy conscious users (those that don't want Google on their phones) can't even use Signal due to this battery drain issue.

I'd love to recommend this app to friends and family which is a hurdle in itself but then explaining the benefits of them using it while not being able to use it myself isn't very productive.

Is this issue being treated with any priority by the Signal team? It seemed to have gotten some attention but other than theBoatman's unofficial fixes (which definitely help but still don't solve the problem entirely) it seems to have died off.

Any official updates?

[five-c-d]

other than theBoatman's unofficial fixes

These are a priority for myself and @theBoatman , but the official devs are hindered (as I myself am hindered) because I do not have any gApps-free devices, both of my handsets are incompatible with LineageOS. Thus I cannot test whether github.com/libsignal-service-java/issues/pull/70 is any good for battery-drain, nor for dangling websockets.

But I can read debuglogs, if people that ARE impacted, upload them.

not being able to use it myself

You on the other hand, might be able to help move pr70 towards completion, because it sounds like you do have gApps-free android capable of

1. making an encrypted backup-blob, write down passphrase, store both of those off-device
2. capture debuglog from >24 hours usage of the official signalapp apk, upload debuglog URL to https://community.signalusers.org/t/call-for-testing-fixing-realtimesleeptimer-to-work-in-concurrent-threads/7189
3. sideload and do some tests for 24+ hours on experimental unofficial apk by theBoatman
4. upload 2nd debuglog, noting whether you experienced

• A) improved battlife under similar conditions, plus whether battlife degradation in stock apk is "user-visible" or just shows up in the quantitative stats without hindering UX much, and in particular whether when operating the handset on battery and purely on dataplan i.e. away from wifi causes a noticeable impact, since baseband radio eats far more juice

• B) improved connectivity-retention when switching network-transports e.g. dataplan to wifi and back to dataplan, or similar sorts of potentially-dangling-websocket situations

• C) any other impact you notice, or suggestions/enhancements you think of

We are wanting to move pr70 and then get another one (addressing additional fixes and improvements) into the review-queue, but SQA results in the form of debuglogs are needed, please, por favor, thank ye most kindly? https://community.signalusers.org/t/very-high-battery-drain-on-4-34-8-without-google-play-services/6536/52

In particular, I'm suspicious that the heavy-battery-drain scenario is somehow correlated with device-model and/or living in an urban area (lots of cell-towers exacerbating the switch-to-a-"new"-transport thing). We may need to find an enduser with a device that is impacted, and do the horrible-sounding Battery Historian thing. https://github.com/signalapp/Signal-Android/issues/8217#issuecomment-455634891

Any official updates?

Thank you for not pinging Greyson this time. But you still emailed 700+ repo watchers, that it sucks 8217 is still open. And now I'm about to do the same, for my Unofficial Update :-/

• When and if
• there are official updates,
• somebody official,
• will update us.
• They know where their own github is
• They know #8402 is open (the spinoff)
• They know 8217 is open (this one)
• ./blob/master/CONTRIBUTING.md#dont-bump-issues pls :-)

That said, there is an official-person-speaking-in-their-individual-unofficial-forum-participant-capacity update that I am aware of, related to battery-drain caused by androidWorkManager issues on devices WITH playStore+playServices+etc (certain rare ones of unspecified class/category seem to eat battlife but I don't believe anybody pinned down exactly which models/androidVersions were worst-impacted). Signalapp used to have their own jobMgr thing, before switching to workMgr, and is switching away again. https://community.signalusers.org/t/signal-with-password-encryption-poc/6159/83 To the extent that the androidWorkManager wakelock thing was draining battlife, this should be an improvement. It looks like that process is still ongoing, 4.39.2 commit about a week ago was still evicting androidx.work.* from the encrypted perimeter == https://github.com/signalapp/Signal-Android/commit/cef5de2be42e674a818e58864a1f7142741904b8

[LoveIsGrief]

I'm impacted and it's gotten worse (no g-apps)

Here's a debug log

[uspoma]

Hello folks,

I am affected too. I don't think it's necessary to post another debug log. @greyson-signal is this going to change with the coming work manager you are working on? Because it seems this severe bug is receiving almost no attention so far so I was wondering what the reason might be.

[LoveIsGrief]

@uspoma simply complaining, isn't going to change anything. It's an open-source project and a free product. Not every issue is critical to everybody. They have no obligation to respond to anybody.

Add a debug.log, give the issue and its PR signalapp/libsignal-service-java#70 a thumbs up to give it a better ranking, and if you can, follow @five-c-d's instructions from his comment. It'd be great if everybody did the same.

[andmars]

@uspoma simply complaining, isn't going to change anything. It's an open-source project and a free product. Not every issue is critical to everybody. They have no obligation to respond to anybody.

All true, but what's your point? Signal is competing for us, the users and it's competing against WhatsApp, Telegram, Threema, etc. And frankly Signal is getting more and more irrelevant. (It's not even mentioned anymore in many comparison-articles in 2019).

Last year it took me weeks and months to convince my closest friends to get Signal. When we finally had a group together I had to uninstall it due to the battery drain issue. And there is no way I'll ever get them to get Signal again.

imho it doesn't matter how much it's open-source and free and how much the devs aren't obliged to respond. At the end of the day the free market punishes those with bad products and rewards those with good products. Simple as that.

[PeekFreansCDN]

Everyone's no gapps solutions are different it's really hard to code for them all. For example raw AOSP or Custom Ron with Microg etc

The code Google's written for GCM has no moral compass so boycotting using GCM over privacy concerns when you're using GCM to enable privacy enhancing applications such as signal seems self neutering and ideological at best.

[albirs]

Everyone's no gapps solutions are different it's really hard to code for them all. For example raw AOSP or Custom Ron with Microg etc

Besides Signal, I also use Threema and its "polling solution" for users who don't use Google Services, would be sufficient for me as an alternative or setting option. I'm not a programmer and don't know how much implementation is required, but I can imagine that this is easier than a completely custom real-time notification solution.

But of course I would prefer a working real-time notification solution with "normal" battery consumption without GCM.

[LoveIsGrief]

Have you tested @theBoatman's patch @albirs ? He has a thread with it over on the signal-community.

It helped me and I'm sticking with it until this bug is closed or I can use an alternative client. You can also give the bug a :+1: as well as signalapp/libsignal-service-java#70 if the patched version works for you.

[albirs]

Have you tested @theBoatman's patch @albirs ? He has a thread with it over on the signal-community.

Yeah, I'm using this patched version since May now. Currently I'm on its last version https://github.com/theBoatman/fixing-signal (4.42.2). For me its working.

[Krawei]

Is there any progress here? Will @theBoatman 's patch being integrated in the official signal app?
If not, please note your decision here and close this ticket.

[JerryShort]

9170

Finally merged 🙌

[greyson-signal]

Given that most people seem to indicate that the changes by @theBoatman resolved their issue, I'll close this.

[kallaballa]

I have been using up to date versions of signal for years and it always drained my battery heavily (up to 60% percent) while I use it minimally. I'm using a custom ROM without gapps and that should be alright, considering that no other messenger app has a problem with it.