Deltachat-android: Battery usage

[reno-a]

Hello,
I see DeltaChat use more battery than other communication application (SMS/MMS, Twitter, ...), more than other IMAP applications (K-9Mail, E-Mail stock).
Test configuration : Moto G 2015 CyanogenMod/Android 6.0.1

[JobbeDeluxe]

On my g3 with lineageos it doesn't come up in the battery list. So in my case it will have less than 5 percent.

[r10s]

I also have <5 % battery usage. If you compare Delta Chat only to other apps not using Google for messaging (eg. Riot), Delta looks even better.

But in general, these things are hard to compare.

[rizzopablo]

This is my battery stats at morning, so it was mostly idle for 16 hours.

Sent from my free LineageOS device with K-9 Mail. Please excuse my brevity.

El 17 de junio de 2017 4:47:24 GMT-03:00, "Björn Petersen" [e-mail] escribió:

I also have <5 % battery usage. If you compare Delta Chat only to other
apps not using Google for messaging (eg. Riot), Delta looks even
better.

But in general, these things are hard to compare.

[reno-a]

Thanks for your answers.
@JobbeDeluxe perhaps it's different from one device to another, and also from one operating system to another OS (?)
@r10s I don't use GApps, and I dont' have a GMail adress. I can't compare with GMail application, or other on GMail.
@rizzopablo You constat DeltaChat take 2 more time battery usage than K-9Mail.
I seen also, for one same email adress, DeltaChat again more battery greedy than this EMail client.

[Hocuri]

I also think that it would be nice to have less battery use besause in my opinion 2% is quite a lot for​ a single app, even if it is a messenger. On my device it is a bit less than 2% but still about twice as much as K9 uses.
Maybe the bigger battery use is, at least partially, due to the use of a foreground task? (See also Issue #82; unfortunately, it is not possible to just disable it, as discussed in the issue's thread.)

[r10s]

this is how it looks like here:

In fact, Delta Chat does no weird things, it only waits on the websocket for new messages and takes care not to fall into doze mode - otherwise we won't receive any further notifications.

Don't get confused about the percentages at all. I do not believe they are that accurate; on shared wakelocks at least difficult to count fairly. Moreover, it depends on what you've really done with the app.

But in general, of course any PR optimizing the battery usage is welcome.

[reno-a]

Hello,
Finally, I upgraded the OS to Lineage 14.1 (Android 7.1.2) and test again the battery usage.
Good news, after a night (standby applications), I do not see difference between E-Mail client (stock) and DeltaChat. Battery usage is similar.

[r10s]

Great, that it works for you :-)

[csb0730]

Hello All,
I think there is still an issue (v0.9.3).
My friend and me see the same behaviour at two different phones (S5 with Android 6.0.1 and S3 mini with Android 4.1.2).
Delta Chat is shown as the most energy consuming app with approx 8% in "Akku" list.
There is a clear relation between using Delta Chat (charge every day necessary, my phone) and not using (charge approx. every 3-4 days necessary)!

Is someone else able to confirm this?

[csb0730]

Update:
10-12% battery consumption while lesser phone usage!
What can be seen: time of "Wach bleiben" is very high comparable to other apps.

[zoff99]

delta chat is a real battery hog. not sure if that can be made any better.
but maybe as a workaround make a setting where delta chat only checks mails every 3 hours (as an example)? this would drastically reduce battery usage, while still have a senseful interval

[kollokollo]

Maybe one can just do it the same way, the app K9 does it. There I also get new emails within a few seconds.

[reno-a]

hello,
If DeltaChat is a very good application, it uses again more battery usage the others.
The interval modification is a solution, but is not good for Chat (real time).
[android 7.1.2 (Lineage OS)/Moto G 2015]

[csb0730]

Hi all,
I agree reno-a. A long polling interval can only be a bad workaround and not ok for chat usage.
Imap push is in principal the right choice for getting incoming messages instantly.
The question is if there is a better possibility to wait for incoming TCP data at the open imap server connection in a more efficient way than now.

I suspect that many users going to use DC will not be happy with this high energy consumption.

Questions:

• What's the root cause for this in detail? What process causes the energy consumption?
  Is it DC itself? Is it the KeepAliveService? Is it the Android system because of too many
  wake ups?
• What technical possibilities are existing?

Maybe this can be cleared for a further discussion?
I'm not an expert enough to give an answer to this in the moment :(

[vitalyster]

Imap push is in principal the right choice for getting incoming messages instantly

It is not true for mobile devices.

[zoff99]

still, there should be an option to use disable "PUSH" and set a polling interval. this does not hurt. some people may want this.

now you need to force stop the app to disable PUSH. thats really bad. please add and option in the settings

[csb0730]

I think r10s should reopen this issue again?

[csb0730]

@r10s - I really see a problem in this issue.
As long as there is no better idea about the cause of it, my proposal is to implement some settings (debug settings) to enable/disable some key elements of dc and let users test what causes the battery usage.

[csb0730]

@vitalyster (7 Aug) - Why do You see imap not ok?

[vitalyster]

@csb0730 because IMAP requires persistent tcp connection, it is not possible on mobile

[csb0730]

@vitalyster - Ok this is a principal question and I don't think that it's impossible at mobile. But let's come back to the basic issue of that discussion again.

At my phone this really is an issue and I'll ask now Björn to reopen the issue again.
I would try to help as much as possible but in the moment I do not really have an idea where to start at best investigation. Additionally I even suspect that this is an issue for DC core and not here!?

Meanwhile I'm able to provide logcat and some screenshots if it would help. But I see help of Björn necessary.

[r10s]

Okay, I reopen the issue, let's see if someone who can helps have the same issue.

[Ampli-fier]

I checked on my phone (in root shell) with the command dumpsys batterystats.

It looks that DC wakelocks are very lenghty:

33m20s083ms (2) 038 +wake_lock=deltachat:"backendWakeLock"
33m21s086ms (1) 038 -wake_lock
33m21s926ms (2) 038 +wake_lock=deltachat:"*walarm*:com.b44t.messenger/.TimerReceiver"
33m24s935ms (1) 038 -wake_lock
33m32s977ms (2) 039 volt=3900
34m10s083ms (2) 039 +wake_lock=deltachat:"backendWakeLock"
34m11s087ms (1) 039 -wake_lock
34m13s414ms (2) 039 temp=340
34m21s945ms (2) 039 +wake_lock=deltachat:"wakeupWakeLock"
34m24s958ms (1) 039 -wake_lock
34m53s230ms (2) 039 temp=330
35m00s083ms (2) 039 +wake_lock=deltachat:"backendWakeLock"
35m01s087ms (1) 039 -wake_lock
35m21s965ms (2) 039 +wake_lock=deltachat:"wakeupWakeLock"
35m24s982ms (1) 039 -wake_lock
35m33s271ms (2) 040
35m50s083ms (2) 040 +wake_lock=deltachat:"backendWakeLock"
35m51s087ms (1) 040 -wake_lock
36m22s006ms (2) 040 +wake_lock=deltachat:"wakeupWakeLock"
36m25s067ms (1) 040 -wake_lock
36m40s083ms (2) 040 +wake_lock=deltachat:"backendWakeLock"
36m41s087ms (1) 040 -wake_lock
37m10s420ms (2) 040 +wake_lock=conversations:"[email protected]"
37m10s433ms (1) 040 -wake_lock
37m10s446ms (2) 040 +wake_lock=conversations:"[email protected]"
37m10s447ms (1) 040 -wake_lock
37m10s448ms (2) 040 +wake_lock=conversations:"[email protected]"
37m10s448ms (1) 040 -wake_lock

The _backendWakeLock_ is 1s and the _wakeupWakeLock_ is 3s long.
Conversations-app wakelocks are only a couple of mili seconds.
Also K9-app wakelocks are much shorter.

I wonder if this is needed/on purpose.

[zoff99]

why don't you have a user changeable setting to only update manually? that would be easy to implement.

default to: update automatically

K-9 also has such a setting

[r10s]

I wonder if this is needed/on purpose.

I am also sure, this can be optimized.

[r10s]

However, I also just got a mail from a guy who's explicitly loving the low battery usage of Delta ... :)
This seems to be really complicated, weird stuff ;)

[Ampli-fier]

Well, if the guy has Facebook Messenger, Google Now, Google Maps, ... in use then DC might look _relatively good_ :)

In TimerReceiver.java you kick off the 3 second long Partial Wakelock:

ApplicationLoader.wakeupWakeLock.acquire(3*1000);
MrMailbox.log_i("DeltaChat", "*** TimerReceiver.onReceive()");
MrMailbox.heartbeat();

Did you try it this way?

try {
ApplicationLoader.wakeupWakeLock.acquire();
MrMailbox.log_i("DeltaChat", "*** TimerReceiver.onReceive()");
MrMailbox.heartbeat();
} finally {
ApplicationLoader.wakeupWakeLock.release();
}

How long is the (expected/average) execution time for _MrMailbox.heartbeat()_, do you know that?

P.S. The app BetterBatteryStats displays most of the data from "dumpsys batterystats":

[r10s]

MrMailbox.heartbeat(); returns very fast in most cases, it only compares two timestamps.

Our current approach for a reliable connection is to keep an PUSH-IMAP connection alive with a timeout of 28 Minutes. In a second thread we check if this connection is still alive, however, Android may put this second thread also to sleep. To reconnect in this case, we also call the heartbeat function from Android.

So, there should always be a background thread alive that waits about 99.99% of the time and does nothing. So I though, a additional wakelock does not cost much ...

For trying, I've implemented your suggestions, see https://github.com/deltachat/deltachat-android/commit/ba1b5211a2167809c7b92cad64f2a65247669f0a , if there are no problems, it will be there in the next release, the statistic for wakeupWakeLock should go to 0% then, too. However, the PUSH-IMAP thread is still there and needs some (maybe very little) CPU.

[csb0730]

Hi r10s
thanks a lot for reopening the issue.

If I read this conversation about the threads: Assuming the connection (PUSH-IMAP) is open and the thread waits for incoming data and thread goes/would go into sleep/doze mode. Is it not woken up automatically by Android system if new data is arriving?

[vitalyster]

@csb0730 Doze mode forbid sockets in background. The only way is polling by schedule

[csb0730]

Hi
thanks for that information. I didn't know that. Is this specific for Android?

Am 25. September 2017 16:14:26 MESZ schrieb vitalyster [e-mail]:

@csb0730 Doze mode forbid sockets in background. The only way is
polling by schedule

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/deltachat/deltachat-android/issues/104#issuecomment-331894598

--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

[vitalyster]

In fact, you can whitelist application (and increase battery usage) on your own device but it will be difficult to explain casual user why he should do it :)

--

On 25 Sep 2017, at 17:43, Christian Schneider [e-mail] wrote:

Hi
thanks for that information. I didn't know that. Is this specific for Android?

Am 25. September 2017 16:14:26 MESZ schrieb vitalyster [e-mail]:

@csb0730 Doze mode forbid sockets in background. The only way is
polling by schedule

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/deltachat/deltachat-android/issues/104#issuecomment-331894598

--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[Ampli-fier]

There is a (lengthy) discussion about it in this k9mail issue.

[csb0730]

Thanks for this link (really a longer discussion!).
It shows that it isn't easy to get a proper solution ... !

But hopefully r10s get's a good solution with the proposed tweaks in code (see ba1b521 above)

[zoff99]

the first step would be an option to only connect manually, like k-9 has it

[r10s]

the first step would be an option to only connect manually, like k-9 has it

This may be a solution for some users.

For the majority of users, however, we expect they will use Delta Chat as an messenger and want to get messages when the device is in idle state.
For them, disable reliabity to save battery is not a good solution.

So, our current effort should go into saving battery while keeping the service reliable. There seems to be at least some points where things can be tweaked ...

[r10s]

Unfortunately, things are complicated, see https://github.com/deltachat/deltachat-android/commit/ba1b5211a2167809c7b92cad64f2a65247669f0a#commitcomment-24574975

[csb0730]

I'm looking forward very exited to have next version available for testing after last changes.
It would be very important to get any progress regarding this issue!

I think it would be welcome to get as efficient as K9 does before having DC version 1.0 !?

[csb0730]

@r10s,
I see in the notification area of the phone that the foreground service is showing the message
_"Connected_ with account xxx ..."
_"Waiting_ for messages".

So far ok, but this notification is not going away/changing when I switch the phone to aircraft mode or deactivating any network connection! But IMHO it should at least change!?

Wouldn't it be an approach for battery saving to shut down foreground service and wake up timer as long as no network connection is available?

[r10s]

@csb0730 yes, all this sounds useful IMHO

[Ampli-fier]

I was wondering how much improvement other users noticed with the changes done in version 0.9.5. My impression is, that the battery usage is very close to K9's usage now.

[csb0730]

I'm patient about it !
My first impression is that the battery screen in system shows a dramatically drop from approx 10-12% to 2-3% at my phone. This is good and very positive :-).
But on the other hand K9 I never see on this screen in spite of it's running too (some very rare exceptions).
I can remember to see a comment (I think in sources) which directed exactly in the direction that this will probably happen after the changes done now.
But spite of that positive change it worries me a little that the android screen possibly not shows the real impact of battery consumption. I have the feeling that the overall decharging time not really changes.
Maybe my impression is wrong but in each case a longer observation of the issue is necessary to estimate the real improvement.

[csb0730]

Additional hint: With K9 I'm using a dark layout !
Maybe an impact?!

[r10s]

The layout should not have a great impact on battery. Esp. as all the efforts we're talking about here affect the situations when dc is not the app in foreground, displayed on the screen.

[Ampli-fier]

Thanks for your feedback. The 'battery screen' probably calculates (or guesses ;-) both, the consumption in the background plus the consumption in the foreground.
BetterBatteryStats app provides more detailed and separated data. This data can also be incorrect, but in there I _directly_ saw the impact of the code improvements: The Wakelock time dropped from 41 to 5 mins in the same time frame.
The total discharge time of a phone depends on many factors, like screen brightness, radio coverage, alternating cell connections (to antennas), how often network connectivity changes ...

[csb0730]

I understand all this and I suspect that some of the battery consumption caused by DC is to find in the "Android OS" item and not under the app itself.

The easiest way to check this would be to purge the app from phone for a while and compare the battery life or to introduce an option to disable foreground service and/or wakelock or both together.
@r10s : can You do that in next release maybe? (Extended options?)

To purge the app I would not prefer because of many existing chats meanwhile :-/

[r10s]

Well, we may provide options for battery background/foreground in the future, but for now, we're still in the mode to figure things out. For testing, I think you can do such thinks eg. on rooted phones already now (forcing apps not to do things in background etc. - but I have not tested this out)

To purge the app I would not prefer because of many existing chats meanwhile :-/

Since 0.9.5 (or so) we have a backup-export function, see settings / advanced / import and export :)

[Ampli-fier]

There is no need to remove DC from the phone. Just stop DC and all it's processes are stopped:

Settings -> Apps -> Klick on "Delta Chat" -> Force stop.

[csb0730]

At my phone I see only a stop button at "KeepAliveService". What do I do if I'm stopping this?

After pushing this I see DC still in program list, but no more in list of programs under "Anwendungsmanager->Ausführung" !

My intention was to let run DC furthermore but without all wakeup and keepalive features on and to see what happens then!

[csb0730]

For several days now I'm terminating the foreground service by app management manually but this seems not to be a reliable method:
1) Sometimes the foreground service is started again automatically. I don't know if it's cause by DC itself after using it or by another mechanism.
2) I'm not able to see if all but main app of DC is really stopped.

Wouldn't it be possible to introduce a simple "shutdown app" function in the menu to exit the app in a regular way (See Firefox menu)?

This would make tests much easier and more predictable.

[csb0730]

Some new approaches for saving data volume and maybe energy are messing around in my head when I see what happens in logging:

1) After each reconnect to imap server DC does fetching for new messages from all folders. With knowledge in mind that imap push is used wouldn't it be enough to establish the connection and launching the IDLE command instead of full fetch?

And then, when fetching:

2) In my case only INBOX folder receives new messages but with every fetch DC tries to get messages from 10 folders (9 with no success, 1 is INBOX). Wouldn't it be a good idea to reduce fetching to INBOX in case of introducing a "single device mode" or in general !?

I know that a "single device mode" now does not exist, but it could help for simple standard use case?

These two points are some thoughts for future improvements if feasible. Especially for 1) I'm not sure if reliability is still given if no explicit fetching is done!

[r10s]

After each reconnect to imap server DC does fetching for new messages from all folders. With knowledge in mind that imap push is used wouldn't it be enough to establish the connection and launching the IDLE command instead of full fetch?

Well IDLE is only over a single folder.

In my case only INBOX folder receives new messages but with every fetch DC tries to get messages from 10 folders (9 with no success, 1 is INBOX). Wouldn't it be a good idea to reduce fetching to INBOX in case of introducing a "single device mode" or in general !?

Checking mostly all folders from time to time is about multi-device usage. Otherwise we won't get messages moved eg. from Thunderbird to the "Archive" folder while Delta Chat is offline for any reasons.

However, this issue is more about battery than data, and i close it now. the idea of changing things stays existant in the consolidated issue #269