[GUIDE] 0% [0.0%/h] Idle Battery Drain on Stock ROM (XPosed & Amplify Required!)

[Celestial Fury]

Hello, I followed the guide to reduce my battery drain. And thanks to that finally my battery lasts again enough! I use MIUI 9 on my Xiaomi MI5, and I noticed that whenever I limit *net_scheduler* I don't get notifications from WhatsApp anymore unless I open the app. It is an issue because the wakelock is the reason my battery was draining fast.
I tried removing from amplify anything else, and is just the *net_scheduler* if i set a limit higher than 5 minutes the issue which disables my WhatsApp notifications. Did anyone else also encounter this problem?

Android version? IIRC, KitKat relies on it for push notifications but can be safely limited on Lolipop and above as later versions do not (if still) wholly rely on it but use other means.

 

[[email protected]]

My phone has Android 7. I limited it to 10 min, and it is a good balance between notifications and battery drain. Anyway, the problem only occurs with WhatsApp, all other apps are working properly!

 

[leAndroid91]

You can test it systematically by first establishing baselines as in Post #3.

Sorry for the late reply.

Battery only drain after 8h is 1%.
I assume the actual battery only drain is 0% and the phone lost 1% during boot.

Airplane mode battery drain is 3% after 7h.
Please see BBS file and screenshots attached.

Does that help?

 

[Celestial Fury]

My phone has Android 7. I limited it to 10 min, and it is a good balance between notifications and battery drain. Anyway, the problem only occurs with WhatsApp, all other apps are working properly!

If limiting it causes WhatsApp not to receive messages then you shouldn't limit it at all. If others report the same I'll put up a note in Post #2. However, whether your drain is due to *net_scheduler* or not can only be determined (to a certain extent) with a BBS log.

 

[Celestial Fury]

Sorry for the late reply.

Battery only drain after 8h is 1%.
I assume the actual battery only drain is 0% and the phone lost 1% during boot.

Airplane mode battery drain is 3% after 7h.
Please see BBS file and screenshots attached.

Does that help?

You haven't limited (see Post #2):
CONTEXT_MANAGER_ALARM_WAKEUP
analytics
Location alarms

If you don't need continuous instant FB updates, greenify it or experiment with limiting FB alarms. Non-system apps can be safely limited without affecting phone stability.

Widgets drain much more than their respective alarms would indicate.

NETWORK_LINGER_COMPLETE in the amount triggered in your log is not normal so I check to see if you're using a custom ROM and sure enough you are.

==========
CPU States
==========
1.25 GHz (): 4 m 25 s

CPU running at top speed for minutes in idle. I usually search for a near-corresponding time elsewhere in the log and find PowerManagerService.WakeLocks (): 4 m 9 s which BBS claims to be the sum of the partial wakelocks but a quick check in your Wakelocks section shows a total of exactly 2 m. So, either that's not the case or BBS calculations are wrong or there's a hidden wakelock not shown by BBS but calculated all the same.

 

[leAndroid91]

You haven't limited (see Post #2):
CONTEXT_MANAGER_ALARM_WAKEUP
analytics
Location alarms

If you don't need continuous instant FB updates, greenify it or experiment with limiting FB alarms. Non-system apps can be safely limited without affecting phone stability.

Widgets drain much more than their respective alarms would indicate.

NETWORK_LINGER_COMPLETE in the amount triggered in your log is not normal so I check to see if you're using a custom ROM and sure enough you are.

==========
CPU States
==========
1.25 GHz (): 4 m 25 s

CPU running at top speed for minutes in idle. I usually search for a near-corresponding time elsewhere in the log and find PowerManagerService.WakeLocks (): 4 m 9 s which BBS claims to be the sum of the partial wakelocks but a quick check in your Wakelocks section shows a total of exactly 2 m. So, either that's not the case or BBS calculations are wrong or there's a hidden wakelock not shown by BBS but calculated all the same.

Thanks for your reply!

I limited CONTEXT_MANAGER_ALARM_WAKEUP, analytics, Location alarms as posted in #2.

I would like to keep instant push messages since my goal isn't to achive 0%, i would be fine with 1-5% over 7-8h.

But I'm not using a custom rom.
I'm using the factory image of google with TWRP, SU, XPosed and ElementalX kernel.

I will take a look how the battery drain will develop with the latest settings.

 

[leAndroid91]

Unfortunately the drain didn't got any better.
Is there anything else i can try

 

[DB126]

Unfortunately the drain didn't got any better.
Is there anything else i can try

Quick look suggests connectivity issues (possible weak signal) and larger than expected network activity for apps/services that should be dozing. Also some symptoms suggesting kernel incompatibility but may be a red herring given everything else that's going on. Might consider rolling back to Nougat to see if problem persists.

 

[leAndroid91]

Quick look suggests connectivity issues (possible weak signal) and larger than expected network activity for apps/services that should be dozing. Also some symptoms suggesting kernel incompatibility but may be a red herring given everything else that's going on. Might consider rolling back to Nougat to see if problem persists.

Since you mentioned a potential kernel issue i rolled back to google standard kernel and again got 3% battery lost in airplane mode over night. Same result as the ElementalX kernel.
Will do another BBS analysis tonight with the google kernel without airplane mode.

 

[DB126]

Since you mentioned a potential kernel issue i rolled back to google standard kernel and again got 3% battery lost in airplane mode over night. Same result as the ElementalX kernel.
Will do another BBS analysis tonight with the google kernel without airplane mode.

3% overnight loss over 6-8 hours on your device (considering age, ROM and app portfolio) is not unreasonable even in airplane mode. If you are chasing "0.0%/h Idle Battery Drain" that ain't gonna happen short of powering down.

 

[leAndroid91]

3% overnight loss over 6-8 hours on your device (considering age, ROM and app portfolio) is not unreasonable even in airplane mode. If you are chasing "0.0%/h Idle Battery Drain" that ain't gonna happen short of powering down.

I'm not chasing 0% drain, since i didn't hat that on M either.
But i would like to get back to 1-2% over night instead of currently 2-3% / h.

 

[DB126]

I'm not chasing 0% drain, since i didn't hat that on M either.
But i would like to get back to 1-2% over night instead of currently 2-3% / h.

2-3% per hour (vs "over night") is ridiculous and almost certainly related to one of the sources already identified. If overall endurance is also taking a hit verify the battery is not failing.

 

[sgtslaughter64]

I followed the guide, but now I am having issues with SMS having significant delays in sending...can anyone help?

 

[DB126]

I followed the guide, but now I am having issues with SMS having significant delays in sending...can anyone help?

Wakelock limiting/blocking has side effects which you are now experiencing. Make sure alarms/wakelocks from your messaging app are not being limited. Better yet step away from Amplify which offers little benefit over native power management when properly implemented on Android 6 and above.

 

[Egyptiandroid]

Thanks

 

[Celestial Fury]

But I'm not using a custom rom.
I'm using the factory image of google with TWRP, SU, XPosed and ElementalX kernel.

A kernel is part of a ROM and the log doesn't differentiate it. How well does mixing and matching ROM parts work? Point is, only see such issues in custom ROMs.

I followed the guide, but now I am having issues with SMS having significant delays in sending...can anyone help?

Nothing in the guide messes with SMS. Disable Amplify in XPosed. If problem doesn't occur, then something else you limited is the cause.

In general, Amplify is a tool and XDA is all about the mods. If you want to let Android handle everything then XDA is not for you. The guide has been compiled through numerous testings and feedback. They are meant to limit alarms/wakelocks/services that:

1. misbehave (Facebook, WeChat, etc.)
2. unneeded by the user (analytics, ads)
3. unneeded by the user unless actively used (Location alarms)
4. trigger often but can be safely limited (CONTEXT_MANAGER_ALARM_WAKEUP)

And all that triggers unnecessarily for the user causes drain. If Amplify is no longer needed and the main Amplify thread gets closed down, I'll ask for this to close as well.

 

[sgtslaughter64]

A kernel is part of a ROM and the log doesn't differentiate it. How well does mixing and matching ROM parts work? Point is, only see such issues in custom ROMs.


Nothing in the guide messes with SMS. Disable Amplify in XPosed. If problem doesn't occur, then something else you limited is the cause.

In general, Amplify is a tool and XDA is all about the mods. If you want to let Android handle everything then XDA is not for you. The guide has been compiled through numerous testings and feedback. They are meant to limit alarms/wakelocks/services that:misbehave (Facebook, WeChat, etc.)
unneeded by the user (analytics, ads)
unneeded by the user unless actively used (Location alarms)
trigger often but can be safely limited (CONTEXT_MANAGER_ALARM_WAKEUP)

And all that triggers unnecessarily for the user causes drain. If Amplify is no longer needed and the main Amplify thread gets closed down, I'll ask for this to close as well.

It was actually a network problem that just happened to occur after I made the mods. Working like a champ now.

 

[DB126]

... XDA is all about the mods. If you want to let Android handle everything then XDA is not for you.

This is crap. XDA is many things including learning, developing, sharing and yes, "mods" when mods are beneficial. Sometimes status quo is the best answer. Change for the sake of change is a fool's errand.

The guide has been compiled through numerous testings and feedback. They are meant to limit alarms/wakelocks/services that:misbehave (Facebook, WeChat, etc.)
unneeded by the user (analytics, ads)
unneeded by the user unless actively used (Location alarms)
trigger often but can be safely limited (CONTEXT_MANAGER_ALARM_WAKEUP)

And all that triggers unnecessarily for the user causes drain. If Amplify is no longer needed and the main Amplify thread gets closed down, I'll ask for this to close as well.

Certainly not advocating for the thread to be shut down as there is much to be learned from the shared experiences of others - especially when supported by objective data which is increasingly rare. Those who measure (vs. just reacting to the presence of alarms and wakelocks) usually find little difference in battery endurance or favorable device performance on Android 6 and above. There are exceptions and outliers which this thread continues to serve.

 

[the_scotsman]

Closed on request of OP.