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

Status
Not open for further replies.
Search This thread

Celestial Fury

Senior Member
Aug 19, 2013
1,000
1,434
Sim City
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.
 
  • Like
Reactions: [email protected]
Nov 29, 2011
34
5
Rome
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

Senior Member
Jan 30, 2013
258
10
Köllefornia
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?
 

Attachments

  • BetterBatteryStats-2018-03-07_075901600.txt
    179 KB · Views: 20
  • Screenshot_20180307-080022.jpg
    Screenshot_20180307-080022.jpg
    120.2 KB · Views: 308
  • Screenshot_20180307-080010.jpg
    Screenshot_20180307-080010.jpg
    143.9 KB · Views: 305
  • Screenshot_20180307-080000.jpg
    Screenshot_20180307-080000.jpg
    121.8 KB · Views: 306

Celestial Fury

Senior Member
Aug 19, 2013
1,000
1,434
Sim City
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.
 
  • Like
Reactions: [email protected]

Celestial Fury

Senior Member
Aug 19, 2013
1,000
1,434
Sim City
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.
 
  • Like
Reactions: leAndroid91

leAndroid91

Senior Member
Jan 30, 2013
258
10
Köllefornia
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

Senior Member
Jan 30, 2013
258
10
Köllefornia
Unfortunately the drain didn't got any better.
Is there anything else i can try :confused:
 

Attachments

  • BetterBatteryStats-2018-03-09_075939088.txt
    227.5 KB · Views: 18
  • Screenshot_20180309-080124.png
    Screenshot_20180309-080124.png
    171.2 KB · Views: 274
  • Screenshot_20180309-080108.png
    Screenshot_20180309-080108.png
    126.6 KB · Views: 273

DB126

Senior Member
Oct 15, 2013
15,298
10,068
Unfortunately the drain didn't got any better.
Is there anything else i can try :confused:
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

Senior Member
Jan 30, 2013
258
10
Köllefornia
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

Senior Member
Oct 15, 2013
15,298
10,068
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

Senior Member
Jan 30, 2013
258
10
Köllefornia
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

Senior Member
Oct 15, 2013
15,298
10,068
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.
 

DB126

Senior Member
Oct 15, 2013
15,298
10,068
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.
 

Celestial Fury

Senior Member
Aug 19, 2013
1,000
1,434
Sim City
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.
 
  • Like
Reactions: patrickdrd

sgtslaughter64

Senior Member
Feb 17, 2012
477
83
Samsung Galaxy Watch 4
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

Senior Member
Oct 15, 2013
15,298
10,068
... 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.
 
Status
Not open for further replies.

Top Liked Posts

  • There are no posts matching your filters.
  • 327
    * how to do it *

    What you need

    You can debloat, freeze, greenify but what can really bring your idle battery drain to 0.0%/h is Amplify (forum link). This guide (based on Xperia Z1 KitKat (now Lolipop) / my apps / my usage patterns) will list the alarms & wakelocks and time that they've been limited that I've used to gain the result I've shown you. NOTE: This is a guide and your phone/apps/usage patterns WILL be different. See Post #3 (especially Step 7) on how to test. Do NOT limit anything that doesn't drain for you (unless it's ads or privacy related).

    Strikeouts mean that the alarms/wakelocks used to drain but no longer seem to but should still be safe for you to limit if they drain for you.

    FIX for
    suspend_backoff (kernel wakelock)

    Alarms (Allow every 7200 seconds or 2 hours)
    *
    cloud-red.png
    affects push notifications (alerts from mail, social apps, etc.) Things may get delayed if the phone has been idle for a while. Turning on the screen, connecting to a new WiFi or any event that wakes up the phone can trigger push notifications.


    - ALARM_WAKEUP_CACHE_UPDATER
    - android.net.ConnectivityService.action.PKT_CNT_SAMPLE_INTERVAL_ELAPSED
    - com.android.vending/com.google.android.finsky.services.ContentSyncService
    cloud-red.png

    - com.google.android.apps.sidekick.SCHEDULED_REFRESH
    - com.google.android.sidekick.shared.a.a.UPDATE_CALENDAR_ACTION
    - com.google.android.apps.gsa.kato.ACTION_ALARM
    - com.google.android.googlequicksearchbox/com.google.android.sidekick.main.TrafficIntentService
    - com.whatsapp.alarm.AVAILABLE_TIMEOUT
    - com.whatsapp.MessagingService.RECONNECT
    cloud-red.png



    Alarms (Allow every 43200 seconds or 12 hours)

    - android.content.syncmanager.SYNC_ALARM
    cloud-red.png

    - com.android.providers.calendar.intent.CalendarProvider2
    (use alternative calendar here)

    - com.facebook.push.mqtt.keepalive.KeepaliveManager.ACTION_INEXACT_ALARM.com.facebook.katana
    - com.facebook.common.executors.WakingExecutorService.ACTION.ALARM.com.facebook.katana.Mqtt_Wakeup
    - com.facebook.common.executors.WakingExecutorService.ACTION.ALARM.com.facebook.katana

    - com.google.android.gms.gcm.ACTION_CHECK_QUEUE
    cloud-red.png

    - com.google.android.intent.action.GCM_RECONNECT
    cloud-red.png

    (may break push notifications for custom ROMs)

    - com.google.android.gms.gcm.HEARTBEAT_ALARM
    cloud-red.png

    - com.google.android.intent.action.MCS_HEARTBEAT
    cloud-red.png

    - com.google.android.intent.action.SEND_IDLE

    - com.whatsapp.alarm.CLIENT_PING_TIMEOUT
    - com.whatsapp.messaging.MessageService.LOGOUT.ACTION
    - com.whatsapp.messaging.MessageService.CLIENT_PINGER_ACTION
    cloud-red.png


    Alarms (Allow every 86400 seconds or 24 hours)
    Custom Regex
    CONTEXT_MANAGER_ALARM_WAKEUP_[0-9]{4,}

    - android.app.backup.intent.RUN
    - com.android.internal.telephony.data-stall (reported to break WiFi calling)
    - com.google.android.gms/.checkin.EventLogService$Receiver
    - com.google.android.gms/checkin.CheckinService%Receiver

    Location alarms (both rough and fine)
    * They wake up your device to get a fix (from GPS/network/cell towers) by Google Play Services for apps like Google Now and for Google's own database. GPS may be delayed in the background for Google apps like Google Now. Refresh manually. Navigation apps do not rely on these location alarms. They access the GPS directly.
    - ALARM_WAKEUP_ACTIVITY_DETECTION
    - ALARM_WAKEUP_ACTIVE_COLLECTOR
    - ALARM_WAKEUP_BURST_COLLECTOR
    - ALARM_WAKEUP_BURST_COLLECTION_TRIGGER
    - ALARM_WAKEUP_PASSIVE_COLLECTOR

    - com.google.android.gms.flp.BATCH_FLUSH
    - com.google.android.gms.location.fused.GPS_ALARM_BALANCED_ACCURACY
    - com.google.android.location.reporting.ACTION_UPDATE_WORLD
    - com.google.android.location.ALARM_WAKEUP_IN_OUT_DOOR_COLLECTOR
    - com.google.android.location.ALARM_WAKEUP_SENSOR_COLLECTOR
    - com.google.android.location.ALARM_WAKEUP_SENSOR_UPLOADER

    - com.google.android.gms.nlp.ALARM_WAKEUP_ACTIVE_COLLECTOR
    - com.google.android.gms.nlp.ALARM_WAKEUP_ACTIVITY_DETECTION
    - com.google.android.gms.nlp.ALARM_WAKEUP_BURST_COLLECTOR
    - com.google.android.gms.nlp.ALARM_WAKEUP_BURST_COLLECTION_TRIGGER
    - com.google.android.gms.nlp.ALARM_WAKEUP_LOCATOR
    - com.google.android.gms.nlp.ALARM_WAKEUP_PASSIVE_COLLECTOR

    - GPS_ALARM_BALANCED_ACCURACY


    Alarms (Allow every 9999999 seconds or max)
    - com.facebook.analytics.service.AnalyticsEventUploader.ACTION_ALARM
    - com.google.android.gms.common.receiver.LOG.CORE_ANALYTICS
    - com.google.android.gms.common.receiver.LOG_CORE_ANALYTICS
    - com.google.android.gms.analytics.ANALYTICS_DISPATCH
    - com.google.location.internal.AnalyticsUploadIntentService


    Wakelocks (Allow every 7200 seconds or 2 hours)
    - *net_scheduler*
    - AlarmService#updateNTP
    - ConnectivityService
    - StartingDockService
    - wake:com.whatsapp/.AlarmService


    Wakelocks (Allow every 43200 seconds or 12 hours)
    -

    Wakelocks (Allow every 86400 seconds or 24 hours)

    - QcConnectivityService

    Location wakelocks (both rough and fine)
    - NlpWakeLock
    - NlpCollectorWakeLock

    Wakelocks (Allow every 9999999 seconds or max)
    - Analytics Wakelock
    - *job*/com.facebook.katana/com.facebook.analytics2.logger.LollipopUploadService
    - JobSchedulerHack-com.facebook.analytics2.logger.LollipopUploadService
    - UploadServiceLogic-com.facebook.analytics2.logger.LollipopUploadService


    DANGEROUS - DO NOT LIMIT / DENY
    Wakelocks
    - *backup* -(CAUSES REBOOT)
    - AlarmManager (alarm clock can stop working, etc.)
    - Icing (reported to force close Google Play services, etc.)
    - pkg_move_lock (bootloop reported)
    - UlrDispatchingService (Google play services has stopped)

    Alarms
    - com.oasisfeng.greenify.CLEAN_NOW (Greenify stops hibernating apps)
    - com.system.analytics.cpa.service.Myservice (reported to force close FB Messenger)

    Services
    - com.google.android.gms/.checkin.CheckinService (its related wakelock will run wild)
    - com.google.android.gms/.checkin.EventLogService (its related wakelock will run wild)
    - com.google.android.gms/com.google.android.libraries.social.autobackup.FingerprintScannerIntentService (its related wakelock will run wild)

    (also see other recommendations within Amplify)


    Not Recommended
    Wakelocks
    - ALARM_WAKEUP_LOCATOR (required for "in Vehicle" trigger in Automation apps)
    anim-new5.gif

    - AudioMix - affects notification sound
    - ALARM_ACTION(#####) - WeChat will just create another (number)
    - android.appwidget.action.APPWIDGET_UPDATE - affects widget accuracy (widgets drain battery, your call
    - StartingAlertService - calendar notifications won't trigger
    (also see other recommendations within Amplify)


    Deny these Ads/Privacy related Services
    After disabling any service, reboot the phone because it is dangerous to disable any service on-the-fly according to Amplify so it's only disabled on a reboot. Read warning here.

    - com.facebook.katana/com.facebook.backgroundlocation.reporting.BackgroundLocationReportingNewImplService
    - com.facebook.katana/com.facebook.analytics.service.AnalyticsService
    - com.facebook.katana/com.facebook.analytics2.logger.LollipopUploadService
    - com.facebook.katana/com.facebook.analytics2.logger.GooglePlayUploadService
    - com.facebook.katana/com.facebook.videoads.scheduler.VideoAdsFetchService

    - com.google.android.gms/ads.jam.NegotiationService (reported to force close Google Play Services on some devices)
    - com.google.android.gms/.ads.social.GcmSchedulerWakeupService
    - com.google.android.gms/.analytics.AnalyticsService
    - com.google.android.gms/.analytics.service.PlayLogMonitorIntervalService
    - com.google.android.gms/.analytics.service.RefreshEnabledStateService
    - com.google.android.gms/com.google.android.location.internal.AnalyticsSamplerService
    - com.google.android.gms/common.analytics.CoreAnalyticsIntentService

    - com.sonymobile.enterprise.service/.GoogleAnalyticsLogger
    - com.sonyericsson.android.socialphonebook/.analytics.GaInitService
    - com.sonyericsson.conversations/com.sonymobile.conversations.analytics.GaInitService
    - com.sonyericsson.extras.liveware/.analytics.AnalyticsService


    NOW TESTING (please help to test and confirm, thank you!)
    Nothing.
    321
    The ORIGINAL:good: Amplify Guide Thread

    View attachment 3106730
    On the Portal News! Jan 8, 2015

    bitbag-logo-white.png

    TheBitBag Thursday, January 15th, 2015

    logo_ns.png

    Noob’s Space, 2015年08月30日


    THIS IS REAL. This also goes against traditional methods/advice of reducing battery drain while idle. Idle battery drain comes mostly from Alarms and Wakelocks that want to work when they're supposed to be sleeping. This GUIDE will help you reduce your idle battery drain to 0% [0.0%/h] without turning your smartphone into a dumbphone. The EVIDENCE is all in the attachments.

    0% [0.0%/h] does not mean no battery drain. BetterBatteryStats only detects up to one decimal point so 0.0% means you have a drain of between 0.01% - 0.09% or less than 0.1% so it shows 0.0%.

    What you DON'T have to do
    NO disabling GPS
    NO disabling Auto Sync
    NO disabling Google Now
    NO disabling Location Services
    NO disabling Location History
    NO disabling Android Backup
    NO disabling WiFi
    NO disabling Google Services Framework
    NO disabling Receivers
    NO disabling Google Maps
    NO disabling Facebook / social apps
    NO converting Google Play Services to a User App
    NO breaking Push Notifications
    NO Tasker/Automation battery saving rules
    NO Custom ROM involved
    NO Init.d Battery saving scripts involved
    NO Underclocking involved
    NO changing of Governors involved
    NO blocking Google IP addresses with Firewall

    Doing any one of these "NO's" will reduce battery drain BUT you then mostly lose functionality. So how is it possible, what is involved, what do you get, and how do you do it?

    What is possible
    GPS - High Accuracy :good:
    Choose Battery Saving and no near instantaneous GPS lock. Choose Device Only and Google Maps shows your last GPS location lock (which may not be your current location).
    Auto Sync All your Accounts :good:
    Google Now, Location Services & History working :good:
    Turn off Location Services & History and Google Now doesn't work or as well and your GPS gets turned off.
    Android Backup is on :good:
    If turned off all your backups will be deleted (it's not a toggle) - thanks Google - not!
    WiFi can be kept awake (even during deep sleep) :good:
    Scanning always available :good:
    Google Services Framework is not disturbed:good:
    Receivers are not disturbed :good:
    Google Maps is available :good:
    It's still the best and has the most up-to-date maps.
    Facebook /Social Apps are available :good:
    They can be used as they are meant to be. These app can be tamed (with the exception of WeChat(!) - Whatsapp ok, Line Ok).
    Google Play Services remains a system app :good:
    As it should be - avoid complications.
    * Instant Push Notifications :good:
    (mileage may vary)
    anim-new5.gif

    No need for Tasker/Automation battery saving rules :good:
    Too many rules and they can also drain the battery. They tend to have one wakelock/alarm for each rule!
    Completely Stock Rom (rooted) without need of Init.d, Governors, underclocking, Min/Max CPU, and everything Google is working :good:

    Attachment 1: Other
    6h 29m 19s Bat.: 0% [0.0%/h]
    Deep Sleep
    6h 28m 24s 99.8%
    Awake
    54s 0.2%
    As you can see in the status bar, b & kb are being transmitted and the battery temp as well as the time, they are green in colour indicating that the device is connected to a live network - meaning WiFi is on and was never off.

    Attachment 2: Kernel Wakelock
    All under 15s for nearly 7 hours - if you have kernel wakelock problems, this guide can't help you. Amplify can't limit kernel wakelocks.

    Attachment 3: Partial Wakelock
    1s for nearly 7 hours - do you like what you see? ;)

    Attachment 4: Alarms
    Wakeups: 1 for nearly 7 hours - do you like what you see? ;) Com.google.android.gms puts all its alarms under this but each of its alarms is also Wakeups: 1 (see Attachment 5 in next thread).
    227
    * how to test *

    Screen On needs to be less than a minute as we want to find out what's draining in idle mode. If you've used the phone then there's no way to tell what's acting up when it shouldn't be and there's no way to separate the active from idle.

    In BBS Settings - Advanced
    Untick Alarms using API & Kernel Wakelocks using API (it's less accurate) unless using API is the only way to show alarms & wakelocks for your phone.


    STEPS

    Establish Baseline (battery ONLY drain)
    1. Charge battery to full (100%).
    2. Switch phone OFF.
    3. After 7 hours or so turn it on.
    4. To get drain / hour, divide % of battery reduction with number of hours the phone was off. Example, if battery % dropped by 1% after 7 hours, then 1 / 7 = [0.1%/h]. This is your battery only drain, without drain from Android OS, radio signal, WiFi, data, wakelocks, & alarms. You can't get a better drain than this without removing your battery.

    Establish Baseline (Airplane Mode)
    1. Charge battery to full (100%).
    2. Switch phone to Airplane Mode.
    3. After 7 hours or so turn off Airplane Mode.
    4. Check drain in BBS. This is your battery drain, without drain from radio signal, WiFi, and data. You can't get a better drain than your battery only baseline.

    Test Idle Battery Drain
    1. Charge battery to full (100%).
    2. Reset Amplify Device Stats NOT Reset to defaults.
      (Useful for troubleshooting which limited alarm/wakelock is causing trouble)
    3. Leave phone idle for 7 hours or more.
    4. Check phone for any unknown reboot (running time in Amplify & BBS must be the same. If BBS has a MUCH shorter time or if it shows "Boot" instead of "Unplugged" then there was a reboot as BBS doesn't keep stats after reboot).
    5. Report here for the cause of reboot and do not limit it anymore.
    6. It is easier to use BBS as a guide for battery drain. Increase time of limited alarm/wakelock and/or limit other alarms or wakelocks. Don't limit something that doesn't cause drain for you (unless it's ads/privacy).
    7. Repeat Step 1.
      Your PHONE can't get a better drain than the two baselines.

    [LINK] Why charge to 100% instead of setting custom reference and measuring from there?
    Sometimes battery levels have been observed getting stucked at lower levels and not draining at all despite being in used for over half an hour. That is level lost and voltage lost are sometimes not in sync.
    Level lost [%]: Bat.: -2%(71% to 69%) [0.3%/h]
    Voltage lost [mV]: (4066-4066) [0.0%/h]

    Level lost but no voltage lost or vice versa is not logical.
    anim-new5.gif


    How to find problems with limited alarms/wakelocks
    1. If it's not in the guide, you'll have to test it yourself.
    2. In Amplify, RESET Device Stats.
    3. Use the app you have a problem with.
    4. Check in Amplify what alarms/partial wakelocks were triggered.
    5. OR Disable Amplify, reboot and see if your problem still occurs.

    If you need help

    (Don't start using phone first - I can tell from screen on time)
    ATTACH a Text Dumpfile - in BBS, --> Share --> Text Dumpfile and ATTACH as an ATTACHMENT (not post) the textfile. (Don't attach screenshots if there's a dump available)

    IF Alarms & Wakelocks are already low OR if you have severe drain, then attach idle BBS text dumpfile + attach (as an attachment, NOT post): IDLE screenshots of

    (Android) Settings - Power management
    • Battery usage (to see app usage)
    • History details (to see mobile network signal and coverage and others)

    BetterBatteryStats
    • Graphs - in 3-vertical-dot menu (to see more detailed wakelock graph)
    • History - in 3-vertical-dot menu (to check for skipping and abnormal drain)

    WiFi Connection Manager

    • Spectrum (to check for ovelapping with other WiFi networks)

    Facing problems with abnormal battery % and shutdown ?
    (from Sony support forum - removable/built-in batteries)
    WARNING
    To be safe, turn OFF your WiFI before using this battery trick. All your saved WiFi passwords can disappear with a hard forced shutdown/restart). WiFi passwords are supposed to be saved to Google (if you have backup enabled) but they're NOT restored by Google.

    Use WiFi Connection Manager to save all your WiFi passwords onto the SD Card.

    BBS note

    NO posting in multiple threads for help (unless you didn't get a reply after a few days or want a different opinion).
    14
    Hi!

    You can also stop them by using
    So for example, the regex ALARM_WAKEUP[0-9]{6,} will restrict all ALARM_WAKEUP with six digits
    Not exactly: this regex will restrict all ALARM_WAKEUP with six digits or more.
    This is the behavior:
    {count}
    matches exactly count occurrences of the preceding regular expression;
    {min,}
    matches min or more occurrences of the preceding regular expression;
    {min, max}
    matches at least min but no more than max occurrences of the preceding regular expression.

    So, this guide can be simplified a bit: if you have ALARM_WAKEUP[0-9]{4,} then you don't really need other regexps with higher number.
    13
    Post #1 is DONE. Comments? Criticisms? Photoshop accusations? :p