High battery usage, probably network issue

[theBoatman]

I have:

• searched open and closed issues for duplicates
• read https://github.com/WhisperSystems/Signal-Android/wiki/Submitting-useful-bug-reports

---

Bug description

I noticed a very high battery usage during signal is running in the background. Signal uses 3 to 4 times more energy than K9, which has a similar task (open push connection, waiting for messages). The battery drain seems to be constantly in the background and happens even if no message is received or send. The log shows a lot of EOFExceptions in the WebSocketReader, so it seems to be a network related issue.

I tried to enable/disable the android internal battery optimization - in both cases the Exceptions happened. I also uninstalled Signal for a day to confirm that it is Signal which uses the energy and not an error in the statistics. And I checked with BetterBatteryStats for uncommon wakelocks/alarms without result.

I already reported this issue in a comment in #6717, but it seems to be a different problem.

I am using Android 7.1.1 on a phone without GAPPS.

Device info

Device : motorola Moto G (lineage_falcon)
Android : 7.1.1 (cdc512c087, lineage_falcon-userdebug 7.1.1 NOF27B cdc512c087 release-keys)
App : Signal 4.6.1

Link to debug log

https://gist.github.com/anonymous/efd6d9b9ae725b831134654ff3250bd2
https://gist.github.com/anonymous/216fae3f5f7857c88eee3af101b54c83

[moxie0]

Doesn't look like anything unusual is happening here, although it does seem as if your network connection is reset pretty regularly.

Keeping an application awake in the background non-stop while sending keep-alives to make a network connection stay awake is fundamentally going to cause battery drain. By contrast, GCM can be mostly idle, since they've negotiated idle connection windows with carriers around the world.

K9 has a much easier task, since they can use some kind of alarm manager to make periodic checks given the more relaxed latency requirements of email.

[theBoatman]

That's not the whole truth. K9 also uses push connections that stay open for instant notification of new mails, so the task is (in my opinion) comparable to signal.

But: I just learned that K9 did not resolve the issues around doze mode since android 6. So, although the options imply that it can do instant notifications, it fails to do so. And since Signal does the job right, it is at least reasonable for me now that it uses more energy than K9.

Nevertheless I think the EOFExceptions should not be in the log. If they are handled correctly, then there is no need to print the whole stacktrace to the log.

[moxie0]

The log is informational. By that logic, none of the contents of your log would need to be in the log.

[theBoatman]

This still stucks in my mind.

Until some days ago I thought this energy problem is around doze mode and signal trying to keep the connection open during doze. Now I learned that my phone (and probably all phones without gcm) does not doze. (The android documentation states that gcm is a prerequisite for doze mode.)

And therefore I don't see a reason why signal should use more energy than K9, as both have an open push connection and I did several tests to verify that both work reliable.

At the moment it appears to me that my energy problem consists of two parts: On the one hand I have an increased energy usage when my phone is ideling during night/standby, and on the other hand I have peak energy usage during SOT. The later one may be a problem on my phone, but I am not sure about it at the moment - still investigating this.

For the first one, the only hint I have are some not very special looking lines in the log like:

4721 4774 I chatty : uid=10128(org.thoughtcrime.securesms) Thread-2 expire 15 lines
4721 16389 I chatty : uid=10128(org.thoughtcrime.securesms) expire 9 lines

I have alot of them during night, and nothing else. Can someone tell me the meaning of them, or perhaps where in the code they are produced? They don't look dangerous to me, but I have no other trace at the moment.

[dtltf]

I also have a huge battery drain with Signal when I'm on cellular data. It doesn't occur with Wi-Fi connection.

Adding some more info to this topic it looks like both Riot.im and Telegram apps still manage to stay connected but don't drain the battery much (still no GAPPS). Maybe their code can be investigated and implemented similary?

[theBoatman]

I can confirm that the drain only happens on mobile data and not with WI-FI. I tried to get two logs to compare the situations:

https://gist.github.com/b27f7627301914fb058d4aaf7deae40c
https://gist.github.com/ba435d70ca348463c52bae05404098d7

The first one was during a night on WIFI and the second one with mobile data. You can see in the second one that there is constant activity. Unfortunatly the log doesn't show what happened, because Android suppressed most messages (too chatty). I will try to get a better one.

I verified that my connection was stable during the second log by keeping open an ssh connection all the time printing the server time every 10 minutes, so I am certain that there is no connection issue.

[haffenloher]

@theBoatman regarding the chattyness: maybe the 2nd and 3rd answers to this stackoverflow question can help. I guess you'll have to do the whitelisting before the log messages you're interested in are generated.

[theBoatman]

I have now whitelisted signal and took another log:

https://gist.github.com/anonymous/2e403b617f00964b7f246a738f0133dd

You can see that the connection is constantly renewed because of an EOFException. I verified that my internet connection was stable all the time.

[moxie0]

@theBoatman Looks to me like your mobile carrier is killing connections at an idle interval smaller than Signal's keepalive interval. The fact that this only happens for you on mobile data and not wifi is additional confirmation.

This is the biggest problem with not using GCM; we are not organizationally large enough or rich enough to negotiate idle connection windows with mobile carriers all over the world as Google and others have done.

To say that you've "verified that your internet connection is stable" is not entirely relevant for this case. It's not clear what your SSH session's keepalive interval is, and your carrier could likely have different idle timeout windows for different hosts, ports, etc. If you want to rule out Signal, you can write a script to simulate idle connections to Signal's production host/port to see how your mobile carrier treats it.

[dtltf]

@moxie0 I'm from a developing country and I can understand there can be possible issues with carriers. However, I'm also pretty sure that nor Riot.im or Telegram negotiated anything with them and yet they work like a charm on mobile data. I'm always connected, receive messages instantly and the battery drain is minimal.

I think it's worth investigating and I'd appreciate it.

[moxie0]

@dtltf I'm sure there is a way to keep a connection alive, probably with some kind of adaptive keepalive strategy. I don't have any devices without GCM on them, though, so I'm not really the right person to write that. I think it would be better if the people who've been advocating for non-GCM support were the ones to write the code or to investigate issues like this.

[sigenc]

I run Signal on Nexus6P with CopperheadOS without GCM and it is quite a bit more battery drain than with GCM. No matter if on wifi or mobile data. I fully understand, that moxie0 don't have the time to search and develop a better strategie for non GCM users. As for now i am happy to use the official Signal Client without gcm.

Moxie is right. We need to make the research how this could be optimized. And this doesn't mean we point to other apps that handle this sceneraio better than we do. We have to understand how.

[theBoatman]

So we agree that there is a problem and we have to determine whether it is a coding problem (and therefore solvable) or a carrier problem (and therefore out of scope for signal).

I am quite sure that it is no carrier problem. One of my ssh test servers is behind a home internet connection with dynamic ip and a randomly selected port. I don't think my carrier has a special rule for this. But I have no proof.

So, if anyone can tell me which host/port signal connects to, then I will try to do some experiments with this. If I can get a stable connection through mobile data then we need to take a deeper look in the code.

[theBoatman]

I now did some little tests. I can keep up a connection to the server for 90 seconds over both wifi and mobile data. Then the server closed the connection - probably because I did not log in or sent something.

In the source code, the keep alive timeout is specified as 55 seconds, so first I thought that should be fine, but then I took a deeper look in the logfiles and saw, that this doesn't work. If the logs are right, then the keep alive packets are sent in far longer intervalls. On Wifi it is up to an hour, on mobile data long enought that a connection timeout occurs.

I think the problem lies in the KeepAliveSender. There, Thread.sleep() is used for scheduling. I googled a little bit and found out that sleep doesn't work reliable on Android when the screen is off, so I think that might be our problem.

Can anyone confirm that the keep alive isn't sent every 55 seconds?