Battery drain #52
Comments
|
For your particular period a logcat may be useful. But overall, I also noticed some battery drain: For 21hours (including 8 hours night time with internet off) I have 613 MCS Wakelocks which accounts for 36 minutes in total. |
|
Well, I've compiled GmsCore with heartbeat interval of 5 minutes, and it's much better now, almost all night with minimal battery change. |
|
The red box area definitely is a bug. A logcat would be helpful but I guess it's not easy to reproduce. However there should be a way to fix it by ensuring every wakelock will time out, which is not the case yet. Do you remember how many wakelocks were detected by BBS (not only the time) Changing the heartbeat interval will decrease battery usage in "normal" runtime (your green area), but will not help in case of a bug like the one described. |
No, unfortunately, I wanted to capture a screenshot but forgot. I'll keep an eye on my battery usage, if something like this happens again, I'll try to capture as much information as I can. |
|
I haven't yet experienced that battery drain, but I captured a half an hour log just in case: Note that I'm using 5 minute beat interval. BetterBattery stats report allot of wasted time (1153s, 89,7%) on microG wakelocks (com.google.android.gms.microG services) but counts only 6 of them. (The phone is about two hours on battery, 15 hours of total turned on time.) |
|
Also, one thing that I don't understand: Gms should wake my phone and check for new messages, right? When I turned screen on a moment ago, few messages arrived on Viber upon connecting to wifi. Shouldn't Gms wake the phone, turn on wifi, and retrieve those messages? Option _Keep Wi-Fi on during sleep_ is set to Only when plugged in. |
|
I think this happened once again, last night. Pictures and log attached, I hope they will be of use. |
|
Unfortunately the log does not contain any meaningful entries. I'd like to encourage you to always provide logs with timestamps, as they're crucial to find battery issues (e.g. I can't say if your log is for a timescope of 24h or just 2min). You can easily add timestamps to logcat by using the Additionally, looking at the battery usage graph, it seems interesting to me, that last time the high power consumption happened when there was no wifi connection, and this time after the wifi came back... So maybe it's another issue this time? |
|
I think one problem here is (was) that the wake lock was not released when no ack message was received after a heartbeat ping message. I had the situation that no ack messages were received anymore even though heartbeat pings were sent relatively reliably here because of relatively long intervals between heartbeats (8 minutes and above seems to trigger the problem). The SSL connection reports errors only after several further ping requests as it can also be seen in the log above. From reading the code I think the wake lock is only released when an ack message is received. Is it really necessary to keep a wake lock for receiving the ack or couldn't the lock be released directly after sending the heart beat ping? Same question for the login request. On the other hand I wonder if microg shouldn't acquire a wake lock as soon as data is received in order to make sure that the device stays awake between the time when the data is received, I'm not sure about the wake locks but I've tried fixing the connectivity issues. I've done this by changing two things:
I'll test this for some more hours especially also when the phone is not connected to WiFi and the charger (where I also had these problems, there they seem to be fixed), if my tests are successful I'll open a pull request. |
|
@michitux I'm open to test your changes and report back. I also must point out that I haven't been able to reproduce this issue since long time. The problems I'm mostly facing now are:
|
|
@pejakm I've just created #74 with my changes. This should make the connection stabler, at least for me the connection works reliably with 5 minutes interval. However I could still reproduce your problem that WhatsApp did not receive a message, see #75. If your device does not have an internet connection, no messages will be received. Gms won't turn your WiFi on. The idea is that the app keeps an active connection to Google and wakes the phone up when data is received on that connection - which needs a persistent internet connection of course. However when WiFi goes off and you still have an internet connection (e.g. UMTS), the connection should be re-established using that connection. This should be the same behavior with the official Google Play Services. |
|
I had few problems with wakelocks at Nov 17, 2015 commits. Could only use gmail 4.2.2 but with amplify I could limit wakelocks to max every 15 minutes. Now just upgrading to latest GMSCore and gmail to 4.9 I have gmail hold much longer locks... ie many minutes at a time. GCM isn't on... just pure sync. An app automatically kills the connection when the screen is off and is supposed to sync gmail every 45 minutes. Once it does gmail prevents going back to deep sleep and amplify can't help since it holds the lock. From this thread it sounds like gms isn't properly failing connections. So I'm not getting new mails and the phone can't sleep. |
|
@michitux Compiled, installed, set timeout to 300 and looking forward to report back. |
|
@michitux With your changes I have a feeling that I have GAPPS installed! Thanks, it really works great now! |
|
Hi, I experienced a battery drain this week with last version. I fixed it by checking-in. Next time I'll try to get the logcat, for this report to be more helpful.. ;) |
|
Just saw something that looked weird in my logcat output - I had my interval set to 60 seconds and seemed to be getting heartbeats every 30 seconds instead. Not sure if this is normal. I noticed this due to high battery drain; switched to a 300 second interval and I seem to be getting heartbeats every 5 minutes now as expected. |
|
@jfrederickson This is intended behaviour. The ping will be sent within the interval |
|
I'm not using microg anymore, but when I implemented this [heartbeatMs/2, heartbeatMs] interval I tested this mainly with 300s as interval and this worked perfectly fine and I would actually suggest this as default value. Note that the connection is maintained permanently and push messages will also wake up your device when no ping is sent as long as the connection hasn't been dropped in the meantime. You can see connection drops in the log as microg reconnects as soon as it detects that the connection is not alive anymore. Depending on your internet provider and your router when you are using WiFi also longer intervals might work. Every time the connection is lost the stream id is reset, so if you see small values of the stream id in the log and you have had a stable and permanent internet connection (and did not switch between WiFi and mobile data) during the last hours, your interval might be too long. |
|
After update to 0.2.2-5-g6bf59b2 the microg would drain entire battery during the night, when wifi is off. Just to note, device checkin is off. I had to revert to stable 0.2.5. No logs for now, as I'm not in position to experiment these days. My best guess is that commit 2a394f9 is the cause of this. |
|
after update to microg 0.2.3 my battery holds very long. Checkin is on gcm too with 300 secs |
|
I can confirm, with 0.2.3 I cannot reproduce this anymore. |
|
Seems to be no problem anymore, closing. |
Finally, I'm using microG two days without any signs of #31. But unfortunately, I'm experiencing occasional battery drains (perhaps related to #47?) and I would like to report it, just in case. Perhaps someone could explain to me what am I actually seeing here (pics attached).
As you can see, during night, the properly went in deep sleep state (green lines). But today I plugged it off, and left it for few hours (red lines). The phone didn't go to deep sleep state, wifi wasn't active, so some messages I received on WhatsApp few hours ago arrived only when I picked the phone up and turned the screen on. (Yes, I reinstalled WhatsApp after installation of microG). Shouldn't the whole purpose of a push service be to wake the phone up and retrieve messages?
Also FWIW, BetterBatteryStats app reports
com.google.android.gms.microG servicespartial wake lock was active 94,8%. Any thoughts?The text was updated successfully, but these errors were encountered: