search

signalapp / Signal-Android

A private messenger for Android.
https://signal.org
GNU Affero General Public License v3.0
25.72k stars 6.17k forks source link

Energy drain? #1298

Closed perguth closed 7 years ago

perguth commented 10 years ago

We here have the impression that Textsecure drains quite a bit of energy. Is that right/can I do something to provide metrics?

Sadly Textsecure is not listed in the energy consumption graph by android so it's more of a subjective impression of several people.

generalmanager commented 10 years ago

I haven't noticed any difference in battery drain after installing TS.

moxie0 commented 10 years ago

@pguth Just the opposite. By using GCM rather than polling, TextSecure should not have any measurable impact on battery life.

jmue commented 10 years ago

I had this impression though. With the upgrade to 2.0.4 my phone lasts about 2 days, prior to the update arround 6 days. After disabling the DirectoryRefreshListener it lasts 6 days again. Maybee this was result of another sideeffect, maybee it is related to 1af99ce. This should therefore only be a hint what to check on.

moxie0 commented 10 years ago

How did you disable DirectoryRefreshListener? That should only wake the app up once every 12 hours, can't imagine it has a measurable effect on battery performance.

jmue commented 10 years ago

I disabled this in DirectoryRefreshListener.java, line 27 and line 31. Yes, I know this sounds unrealistic, cause a manual directory resfresh take one or two seconds for me. In 2 days this should only be 4 times the case. But maybee somethings is "hanging arround" afterwards. But I'm not shure about this at all. Maybee this was caused by something else, for example more automatic updates of other apps or even worse signal for a period of time. I will build a vanilla app and test it with the next charge cycle.

lablans commented 10 years ago

I've often noticed DirectoryRefreshService running for hours. My guess is the service sometimes does not terminate correctly. This also wastes precious RAM, btw.

moxie0 commented 10 years ago

@vascorppor If Android needs the ram, it will kill the service.

lablans commented 10 years ago

@moxie0 That's only partly correct.

According to the Android API guide, "The Android system will force-stop a service only when memory is low and it must recover system resources for the activity that has user focus." Unless there is a foreground (!) activity requiring RAM, Android will afaik not kill the service. As a result, the RAM will be unavailable for other useful purposes, e.g. cached activities. Example: the cached copy of Trebuchet launcher may get kicket out of RAM and has to rebuild when you press the home button.

The same guide also states that "It's important that your application stops its services when it's done working, to avoid wasting system resources and consuming battery power."

Is it really necessary to have five services running in the background doing nothing for hours? Can't they just shutdown when they are finished?

Thanks to GCM, TS might even offer an option to run zero services - and thus guarantee that TS uses zero battery. This would be a strong argument to convince infrequent users to use TS even if they receive a message a week or less: "Why install TS?" - "Why not, it uses no battery."

perguth commented 10 years ago

"Why install TS?" - "Why not, it uses no battery."

I second that!

moxie0 commented 10 years ago

Idle services have no effect on battery life, and if Android is short on memory, it will kill them (happens all the time). If there is a battery issue here, it is unrelated to idle services. Could be that somehow the directory refresh wakelock isn't being freed, but I don't see how that'd happen.

jmue commented 10 years ago

I was able running a full charge cycle without any extra energy drain. But after rebooting I had the drain again. Beside Google Apps I'm NOT running any other Messangers or Cloud-Services, like WhatsApp, Facebook, etc.

DirectoryRefreshService running for hours: screenshot_2014-04-13-19-55-56

With energy drain: screenshot_2014-04-13-19-55-33

Without energy drain: screenshot_2014-03-24-13-24-15

moxie0 commented 10 years ago

Seems like something is going on here, but I'm almost positive it has nothing to do with an idle service. That task requests a wakelock, and maybe it's getting stuck in the network request and never timing out.

Wikinaut commented 10 years ago

I have not noticed anything like this on Y200 and Y201 (Huawei). The TextSecure does not drain the battery on my devices.

SlappyHours commented 10 years ago

jmue have you tried running Wakelock Detector?

oleid commented 10 years ago

I can confirm the problem: The last few days, I noticed that I had to charge my phone more often. I just checked what uses most battery and the overview in the Android settings shows TextSecure as top one (64% !), the rest being Display (23%), WLAN (4%), Mobile Internet (3%) and the rest < 2%. -- I'm running CM 10.2 ( Android 4.3) on Sony Xperia Z (just in case it matters).

I've killed the directory refresher and will report back, if this does anything good.

tinloaf commented 10 years ago

@oleid If you tap the app entry of TS in the battery page, it lists details.. could you tell us what it says?

oleid commented 10 years ago

Sure. It says roughly :

CPU total : ~ 29 min CPU foreground : ~ 6 min 'let active' ('aktiv lassen" in German) : ~ 19 hours Data (tx/rx) : both less than 200k

Obviously, the app doesn't sleep. Btw. I've the latest version from PlayStore installed.

Please consider sending me encrypted E-Mails. If you wonder how to do that, just ask.

oleid commented 10 years ago

I installed Wake lock detector and it shows, that in my case, the there is a wake lock for "mms connection" running for 19h. All the other locks, e.g. Vibrator or directory refresh are in the order of seconds.

oleid commented 10 years ago

After a reboot and 6 hours of runtime, there seems to be no wake lock for mms according to the wake lock detector. AFAIK my phone provider sent me a mms a few days ago, maybe something got stuck there.

moxie0 commented 10 years ago

@oleid very helpful, I think I see what is likely causing your problem.

rbx commented 10 years ago

I have the same issue on Nexus 5: screen

I have just started using new SIM card today, and some time after the insertion there was a notification from TextSecure:

Error storing MMS

The MMS was probably from the mobile operator.

devurandom commented 9 years ago

Any news about this issue?

skulumani commented 9 years ago

I have noticed that TextSecure is at the top of the battery usage screen. I'm on a Moto X 4.4.4 with TS 2.18.1. This seems to be more prevelent with some of the newer versions. I'm also only using TextSecure data messages and it is not set as the default so the MMS issue above should not be involved.

In spite of the high percentage I don't think it's actually affecting the battery life that greatly. I'm just curious why it has such a large awake time.

screenshot_2015-06-23-13-03-07 screenshot_2015-06-23-13-03-02

ghusse commented 8 years ago

Hello,

I also have an issue : signal seems to drain my battery.

Steps to reproduce:

  1. Open Signal
  2. Return to home screen
  3. Wait (15-20 min)
  4. Signal appears as an app that consumes battery. If you wait longer, it becomes the first in the list.

Here is a debug log : https://gist.github.com/anonymous/c7bf03b5f05c97ce0f9ea691d5c9f70e

This issue is very annoying, because it forces me to go to the app settings and manually kill the app every time I use it, otherwise it drains all my battery.

ghusse commented 8 years ago

I deleted all the data from Settings > Applications > Signal > Storage. It fixed the battery issue (and deleted all my messages, of course).

But at least my phone's battery last more than 1 day.

skulumani commented 8 years ago

How many messages did you have?

Maybe there's something size related after many messages On Jun 25, 2016 3:31 PM, "Guillaume Gautreau" notifications@github.com wrote:

I deleted all the data from Settings > Applications > Signal > Storage. It fixed the battery issue (and delete all my messages, of course).

But at least my phone's battery last more than 1 day.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/WhisperSystems/Signal-Android/issues/1298#issuecomment-228566501, or mute the thread https://github.com/notifications/unsubscribe/AFBaZgMfTj4VmnAOPv1IRv3ruO6XZ1P1ks5qPYINgaJpZM4Bv8jh .

perguth commented 8 years ago

I currently don't notice battery problems having about 70,000 messages and an app size of about 1 GB.

ghusse commented 8 years ago

I cannot know : I just deleted everything.

I'm using signal for a while now probably kept every conversation. So I guess there was a lot of messages and conversations. Le 26 juin 2016 1:21 PM, "Shankar Kulumani" notifications@github.com a écrit :

How many messages did you have?

Maybe there's something size related after many messages On Jun 25, 2016 3:31 PM, "Guillaume Gautreau" notifications@github.com wrote:

I deleted all the data from Settings > Applications > Signal > Storage. It fixed the battery issue (and delete all my messages, of course).

But at least my phone's battery last more than 1 day.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/WhisperSystems/Signal-Android/issues/1298#issuecomment-228566501 , or mute the thread < https://github.com/notifications/unsubscribe/AFBaZgMfTj4VmnAOPv1IRv3ruO6XZ1P1ks5qPYINgaJpZM4Bv8jh

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/WhisperSystems/Signal-Android/issues/1298#issuecomment-228596381, or mute the thread https://github.com/notifications/unsubscribe/AAgLjRGygMJg1wKjuRSs06TviqlzNoS4ks5qPmCbgaJpZM4Bv8jh .

lyciansarpedon commented 7 years ago

Following up on this, I have been having a battery drain issue since I updated to the latest version of Signal (3.25.4). Previously, it would last nearly 2 days on a full charge, but it now drains in 4-6 hours. Force stopping the application significantly slows the drain, and starting the application from the force stop begins the drain again (I have tried this at least four times to be sure). I am using a Nexus 6P running Android 7.1.1, and the debug log (if necessary) is at: https://gist.github.com/cc598cb9801b1aff369efce9c9332094

Another note is that the drain appears to be cryptic - looking at battery usage within Android settings doesn't show Signal. I have experienced this before with two other applications where the battery would burn through after installing or updating and return to normal after uninstalling, but the battery usage listing of applications never showed them. I isolated Signal as the likely source as it was the only application that updated immediately prior to the issue, and force stopping it mostly resolved it.

Update 1/14/17: It appears that the 3.26.2 version from 1/9/17 helped this issue significantly for me. Not quite back up 2 days worth of battery life, but no longer need to worry about it lasting the day (or my phone burning a hole through my pocket).

mcg commented 7 years ago

I've used Signal for a few months and today had high battery usage, "Keep Awake 3h 50m 58s". Usually Signal hardly ever even shows up as a battery "user". I am on Signal 3.62.2 from Play Store. Android 7.1.1 and Nexus 6p. Debug log: https://gist.github.com/anonymous/dae461c520138b3c4c08fd167cf933c3

rpgrunwald commented 7 years ago

Any progress on this? I reported it a couple of weeks ago with logs and screenshots. Crickets...

I will also mention that it did not seem to happen until I added a second windows client to the account. With just my phone and work machine it seemed fine. When I added my home machine, the phone seem to tank. Both desktops are Win10 with Chrome.

moxie0 commented 7 years ago

@rpgrunwald You posted logs and screenshots here? Sorry I don't see them. Under your current username?

moxie0 commented 7 years ago

As of f98c41a0136da53331c2905e74326c738da594ed all jobs that have a network requirement now use timed wakelocks instead of wakelocks that free on job completion.

This issue is really old (most comments reference TextSecure), and a lot has changed. I'm going to close this, and if people are still experiencing battery issues let's consolidate new/fresh information into a new issue.