yashsingh1/xdaforums huggingface dataset:
[BetterBatteryStats] chamonix:
Alarm_rtc has nothing to do with alarms in the common sense, those are events causing your phone to wake up.

Your main alarms are:

com.android.phone (): Wakeups: 2890

com.google.android.gsf (): Wakeups: 857

com.facebook.katana (): Wakeups: 535

com.blau.android.phandroidnews (): Wakeups: 46

I suggest that you do following:

- update to 1.7 as the dump add some more info about alarms

- take another reading "since unplugged" as "since charged" is too unprecise in your case

So much I can tell: facebook and phandroid news are one the the main causes of wakelock / wakeups
[BetterBatteryStats] chamonix:
Your main cause of drain are alarms. Please update to 1.7 as it contains a fix for a bug preventing all alarms to show.
[BetterBatteryStats] chamonix:
Keeping WLAN on keeps your phone awake. You could try changing your wifi sleep policy to "off when screen off". Is the device stock?
[BetterBatteryStats] chamonix:
You are right, sync is your main problems. Especially the high SyncLoopWakeLock tells us that one of the synced services are slow or you were suffering from bad network coverage. If it is reproducable I would disable the accounts one by one to see when that wakelock stops. I'd start with soundcloud
[BetterBatteryStats] cdmackay:
Carefully read the first 4 posts of this thread; the OP has dones a great job of documenting things.

Also, read the online notes referenced in post 3. They explain what you should be doing and how to collect the data.

When you've read all that, and collected the data, you can discuss it further here; there are lots of clever people experienced at looking at the logs (I don't include myself).
[BetterBatteryStats] chamonix:
Release 1.7

Version 1.7 is out (and rolling out on Google Play).
[BetterBatteryStats] Googa:
Hi, could you guys provide some help reading this?

I used this last night during the overnight hours. I have a log of 5.5 hours uninterrupted.

ICS 4.0.3 CM9(OpenSensation) on HTC Sensation

Thanks!
[BetterBatteryStats] jpk411:
Could anyone help me in figuring out why my awake time was so high overnight. As you can see, the screen was only on for 3 minutes. It appears the kernel wakelocks for "wlan" were high, but I can't figure out why. Thanks in advance.
[BetterBatteryStats] Register_:
Note darining battery

Hi,

I've got a Samsung Note and recently the battery drain seems to go berserk.

I consumes something like 2 to 7 mA then after some use it started to consume in the best cases 45mA and on the worst 120mA, during an several hours.

Stop some time after reboot or at one of my numerous tries to solve the problem including killing app or desinstalling some, putting on fly-mode... But can find a pattern which put back the consumption to normal. Think some time the drain stop by itself. Can find a process with excessive CPU time (for me)...

When looking at CPU usage with "system tuner" it seems to jump regularly at 30% but process aren't exceeding 1%

I attach a one hour stats from BBS, don't know if it could help.

Thank for you help.
[BetterBatteryStats] chamonix:
Your main problems are alarms:

- maps location

- battery monitor widgeg

- slice
[BetterBatteryStats] chamonix:
rx_wake means that your phone gets woken up by incoming packets. To avoid this turn your wifi off or use Wireshark to diagnose the source / cause
[BetterBatteryStats] chamonix:
Starting by getting rid of jd and repost a dump
[BetterBatteryStats] jpk411:
Thank you, chamonix. Would you agree by looking at the file this was really the only major thing that would have dropped my battery life so much?
[BetterBatteryStats] Googa:
Awesome, thank you.

I have e-mailed Slice about this using their Feedback feature, and got a response.
[BetterBatteryStats] KJ98653:
Yeah. Drain was pretty good though during music play. The back end was were I started losing a lot rapidly after I stopped playing music. Everything is pretty good now, but everytime I plug then unplug it seems another wakelock that wasn't really present in the dumps before shows up. Now exchange services (awake was 1hr 40min O_O) and GTALK_ASYNC causes a lot of awakes, but I've disabled autosync for everything across the board. So I'll see what the next one says.
[BetterBatteryStats] jackwang050203:
I still couldn't figure out the error so I plugged into PC and ran the command instead. But thanks for your tips!
[BetterBatteryStats] TNSMANI:
I have not analysed the dump with more than 30 minutes screen on time as we can only analyse an idle dump like the other one.

Good signal is not great signal. A good signal still drains more battery than a great signal.

BT can be switched off for the next dump. Watch (I presume) was draining battery.

Was Location/Scanning on? Please switch off for next dump.

Instagram was one of the culprits.

sns_smd sensor was on almost the whole time. Not sure but can you disable anything connected with motion detection and for good measure, anything connected to Pocket mode, Double Tap, Pickup to wake etc? Or if your ROM has the option to switch off sensors as a whole, then try it for the next dump.

After taking care of the above, please post a fresh dump.
[BetterBatteryStats] Oswald Boelcke:
I've to highlight that fact, too. We live in a rural area with sparse cell tower coverage i.e. signal quality also depends on weather conditions. I nearly never achieve a great signal but if I've a good signal for the majority of time I get a more than acceptable idle battery drainage of 0.3% per hour like last night. However, if the moderate signal takes precedense as it occasionally occurs I had drainages of up to 08.% per hour with exactly the same device, system and everything else.

Latest idle dump (using hastebin as the direct upload of the txt file failed as usual and I didn't want to attach a zip):

Hastebin: Send and Save Text or Code Snippets for Free | Toptal®

Hastebin is a free web-based pastebin service for storing and sharing text and code snippets with anyone. Get started now.

www.toptal.com
[BetterBatteryStats] ppell:
Thanks for having a look at it.

Here is the new log. unfortunately i now have even more drain :-/

i switched off bluetooth. location is usually always off.

pocket mode, d2tw, pickup to wake etc. is not activated. i dont know about motion detection either.

I have some automated tasks (automate app), but i disabled all those too.

The file you mentioned doesn´t have 30 min screen on time, but awake (screen off) if i see correctly.

maybe you can use this dumpfile too.
[BetterBatteryStats] TNSMANI:
Sorry I didn't see it properly. Now coming to the current dump:

This is the main reason for the increased drain. The earlier one had atleast good signal whereas this one has mostly moderate, good and poor signal.

This I suspect means that the system was trying to shut down some apps for nearly an hour. Roughly the same value was there in the earlier dump. Some apps seem to be misbehaving. Since you have shut down most of what I suggested, there should be other apps which cause this but no obvious ones jump up.

Was your watch still connected? I see some alarms related to it.

You said Location is switched off. Is wifi/BT scanning also switched off in Location or elsewhere? You still have alarms related to Location. It looks like some app/s is/are trying to update location. Is a wrist band connected? Or anything connected to health, fitness etc? Or geofencing?

Again Instagram contributed.

There were background downloads/uploads but some of them happened on mobile data instead of the wifi. Your mobile signal being what it is, data download/upload is a huge drainer. When did you last reset your wifi router? Switch it off for >10 seconds and then switch it on. If any other device especially like a printer is connected to the router, disconnect it for the duration of the next dump.

sns_smd sensor was again on almost the whole time. Have you switched on anything connected to motion detection?

If nothing works or you are not able to find the culprit with these tips, you have to try a factory reset/clean flash with all the attendent time consuming setting up etc.
[BetterBatteryStats] bill10:
Is this not available in the playstore store anymore? I paid for this app and now I can't find it.
[BetterBatteryStats] Lughnasadh:
Please read the OP, especially Post #2.
[BetterBatteryStats] ppell:
For this dump i checked wifi/bt scanning, everything is off. I set my watch into airplane mode this time. BT on the phone was on though.

Except for the watch i dont have anything connected.

I rebooted router and access point. Cleared recent apps.

I got 0.8% per hour over night. Although there were poor signal, half an hour awake (screen off), 1 and a half hour android.system.suspend, sns_smd sensor, similar to the files i posted before....??

Edit: I took another one tonight. To all the things I did yesterday, I disabled sync over night. Now drain was at 1,4% per hour. I don't get what's going on there.
[BetterBatteryStats] TNSMANI:
Regarding the 0.8% per hour dump, now that all offending apps and settings are out of the way, you are getting 0.8%. This despite the mobile signal being poor almost the whole time. Just imagine what the drain will be like if you get a great signal. This establishes that those apps and settings that you earlier had were the reason for the drain. May be by changing your provider (if possible), you may get a better signal and a better drain rate. You may still have other drainers but they are not visible in BBS atleast to my eyes.

Putting your watch on airplane mode is no guarantee that BT related wakelocks/alarms will not fire:

Regarding sync, I just have a guess that apps might still be attempting to sync though sync itself is shut off. Your BT behaves the other way around.

The only other thing that you can do is a factory reset/clean flash.
[BetterBatteryStats] ppell:
since I sometimes, albeit rarely, get a drain of just a few percent overnight, I was hoping to find a specific app or setting that might be responsible for that drain. Since this is not the case, and switching off everything is not very comfortable, I think I have to live with this quite high battery drain. I testet several roms, but none changed this noticeably.

Thanks again for your help and effort.
[BetterBatteryStats] shaggyskunk:
"No Stats Collected Yet" is weird.

BBS works fine when the phone is first unplugged & continues to work until the battery charge drops down - But I haven't been able to determine exactly at what point?

It behaves similar to Wakelock Detector app - Both work as expected.. for a while.

There's no Battery Optimization enabled for BBS & there's no limit to allowing it to run in the background.

I've seen a few other posts on this issue - But I haven't seen if anyone was able to figure it out?

BBS v2.6-382 XDA Edition

Samsung Galaxy S20 Ultra Snapdragon variant running One UI V3.1 [No Root].

All permissions granted by adb.

Here's a couple of screen shots - The first one shows BBS working at 82% battery & the next one not working at 62%
[BetterBatteryStats] dagrim1:
@shaggyskunk

Apparently version 2.5.341 has more chances of working properly (at least on android12, perhaps also on 11)..

Also make sure to set hidden api policies:

adb shell shell settings put global hidden_api_policy 1

Although I had to do "adb shell" first and do "settings put global hidden_api_policy 1" in there sperately.

But for me it also does not work more often then it does, but the creator already mentioned it's quite a lot of work to get it working with android 12 at least and personal life+work just takes up a lot of time (can't blame him there of course!) so prolly gonna take a long time, if it comes at all.
[BetterBatteryStats] TNSMANI:
Switching off everything is not an option for anyone. The purpose of that was in trying to figure out what exactly was the cause of the drain. In your case nothing conclusive has been established. If you are still interested, a clean flash followed by installing one app at a time and watching out for the drain figures may find the culprit. But it is not for everyone.
[BetterBatteryStats] fadedave:
I have enabled the hidden_api_policy but bbs still can't contact the battery service. On my first install, this part worked, but it couldn't get kernel wakelocks, so I started installing other editions, in hopes of having kernel wakelock info. Since then however many times I turn on and off hidden_api_policy, bbs cannot contact the remote parcel. Any ideas on how to solve?
[BetterBatteryStats] TNSMANI:
Android version, device and BBS version details please.
[BetterBatteryStats] shaggyskunk:
Yeah - BBS is behaving exactly like Wakelock Detector - Once the battery drops down to ~ 70% it is no longer able to report stats.

Samsung Galaxy S20 Ultra Snapdragon variant running One UI V4.0
[BetterBatteryStats] tze_vitamin:
I have rooted phone but can not find working version , can some help me what app to install to work properly?

I give all permission everything.. and I get this..
[BetterBatteryStats] tze_vitamin:
Why I have this info ?
[BetterBatteryStats] TNSMANI:
Which version of Android and which device?

You may have a non working version of BBS installed. Which version is it?

The last 6 or 7 pages contain all the info that you may require about the working version and what adb commands to use.
[BetterBatteryStats] Oswald Boelcke:
I also have this notification permanently, and I take it just as the information that BBS is working. You can disable the notification if this is the question why you have it.
[BetterBatteryStats] contevo:
Hello, I'm using PixelDust 12 Jan 26 build on Pixel 3 XL. BBS build 2.5.341, I used

settings put global hidden_api_policy 1, and proper permissions. BBS is working fine so far.
[BetterBatteryStats] parser:
Did dev abandon the project or is he busy w life?

Edit: found my answer in one of the comments.
[BetterBatteryStats] Utini:
Does this still look normal?

Around 0,9% drain per hour during the night.

Dual SIM with 2x whatsapp, 2x mail account.
[BetterBatteryStats] TNSMANI:
The usual culprits: Location, mobile signal, Fairmail, unstable wifi etc.

Kernel wakelocks and sensor data not available. Since you are on A12 and coupled with the above, I think that the current drain should be acceptable.
[BetterBatteryStats] Oswald Boelcke:
I use FairEmail for years and it has permissions granted for permanent email reception respectively pushes and never had any battery drainage issues. However, FairEmail offers a very "complex" ability to adjust its settings i.e. you need to look into its settings very closely to establish a battery consumption acceptable use. But Marcel (aka M66B) indicated pretty well and reliable in the settings, which ones could increase drainage.
[BetterBatteryStats] Lughnasadh:
Just to add to what @TNSMANI said...As someone who has this phone who saves BBS dumps almost every morning, I can agree that this is acceptable. On stock kernel I am averaging .81%/hr idle drain on the January build. Obviously we have different apps installed, different settings, etc., which would account for the slight, but negligible, differences in our idle drains.

Enjoy your phone 😀
[BetterBatteryStats] Utini:
Thanks m8 :)
[BetterBatteryStats] varunpilankar:
I just noticed 2 major battery hoggers under my BBS consuming battery

1. Partial Wakelock: Android System - AnyMotionDetector

2. Alarms: Android - DeviceIdleController.sensing

Does anyone know how to disable or fix them?
[BetterBatteryStats] TNSMANI:
Most likely the first one is happening during screen on. If so, tampering with it may result in unintended consequences. As for the second one, it is part of the Doze system and necessary.
[BetterBatteryStats] DiamondJohn:
Im not so sure about the motion sensor only during screen on. When a device goes into deep-idle (screen obviously off), shaking the device will get it out or keep it out of deep-idle. From memory, in the doze parameters, there is even a parameter to control the delay after motion, before it will enter deep-idle.
[BetterBatteryStats] TNSMANI:
I defer to you since I am not a tech savvy person. Whatever I learned about battery hoggers is from this thread.

Doesn't a partial wakelock kick in only during screen on?
[BetterBatteryStats] varunpilankar:
It's occurring in both state - screen off and on.

I'm trying to figure out how to disable it.. I remember it was possible using Ampilfy or other Wakelock blocker.. None of them work anymore.

So I'm trying to find alternative or new way of doing the same.
[BetterBatteryStats] DiamondJohn:
The type of wakelock generated, I never investigated. I was just testing the effect of continuously physically (and violently) shaking the phone, had on doze; with screen off. There is a parameter labeled "MOTION_INACTVE_TIMEOUT" and another labeled "SENSING_TIMEOUT" or in the code as motion_inactive_to & sensing_to. Oh, and shaking the phone kept it in light idle, I *think*. it was a few years ago, so may of been a full wake to normal. Its pretty easy to check/visualize with the doze graph in TeMeFI

The attached is the doc (extracted from code comments I think) that I found on them at the time.
[BetterBatteryStats] varunpilankar:
Does that mean I can turn it off using - MOTION_INACTVE_TIMEOUT and SENSING_TIMEOUT?
[BetterBatteryStats] DiamondJohn:
I dont think you can turn it off, but minimise the time it stays awake. I have never tried putting zero values in.
[BetterBatteryStats] DiamondJohn:
I havent checked this, but to me, it would seem that any screen on event would be a full wake lock, and any screen-off wake-lock would mean it gets out of idle to do processing (eg maintenance periods) but does not turn the screen on.; ie a partial wakelock. Its awake enough to allow processing, but it isnt awake enough to burn the screen.
[BetterBatteryStats] TNSMANI:
I haven't seen partial wakelocks on the idle dumps. But I see them in the in-use dumps. That was why I said that they would kick in only during screen on.
[BetterBatteryStats] DiamondJohn:
I just did a quick search, and the first hit was https://developer.android.com/topic/performance/vitals/wakelock

I didn't read much further, but the bit I did read implies the partial wake lock occurs "AFTER" the screen is off.
[BetterBatteryStats] varunpilankar:
I'll try putting zero or lowest to see if there any difference.

True.. And alarms trigger in either of the screen state, which also triggers cpu wakelocks
[BetterBatteryStats] ele3131:
Try installing the app "NapTime" and enabling "Disable Motion Detection", worked just fine here, also aggressive doze option can help too.
[BetterBatteryStats] DiamondJohn:
Your quoting the wrong person. Im happy with the stock android behavior. I cant remember who it was with an issue. Im sure if you read a few up, that sounds exactly what they asked for. Just not me.
[BetterBatteryStats] varunpilankar:
Thanks for the suggestion, but Naptime, greenify and ForceDoze - don't work as promising as system doze. All thanks to @DiamondJohn for helping me understand the true power of it - check out his TeMeFi App

I was able to fix the wakelocks AnyMotionDetector and DeviceidleController.sensing by fine tuning doze parameters.

Thank you for your support 😇 👍🏻 really appreciate it
[BetterBatteryStats] tze_vitamin:
I cant make this app work, I was root phone. Everything I try it's not working..
[BetterBatteryStats] skiely666:
Anybody know how to fix STATUS: failed in permissions?

Pixel6 12L
[BetterBatteryStats] asripath:
Which version are you using?

Error goes away after few hours of usage and a reboot
[BetterBatteryStats] skiely666:
xda edition

2.6-382
[BetterBatteryStats] asripath:
Am on the same ver on A12...

had similar issue.

Uninstalled.

Installed previous versions and uninstalled them.

Installed current latest and few hrs (8) later issue resolved after a reboot.
[BetterBatteryStats] skiely666:
That's crazy, I rebooted after ADB commands & maybe once more for different reasons & nothing. After reading your reply I tried once more & success.

Thanks for your help 👍🏻
[BetterBatteryStats] skiely666:
Spoke too soon.
[BetterBatteryStats] skiely666:
Logcat won't post?
[BetterBatteryStats] skiely666:
logcat-2022-02-18_104904539.txt

drive.google.com
[BetterBatteryStats] Damoedge:
Hi all, is there any way using app or magisk modules, lsposed, to block wakelocks and alarms on Android 12 ?

Thanks
[BetterBatteryStats] varunpilankar:
Does anyone know how to fix this?
[BetterBatteryStats] ShadowDeath:
Hello guys, just wanna share this, the phone is a Mi 9 SE with 26months of use A12 with a custom rom and it was amazing the first days but idk what is wrong now, the log its for 8h aprox with AoD, BBS, and GSam.
[BetterBatteryStats] TNSMANI:
Where is the idle dump file?
[BetterBatteryStats] ShadowDeath:
Man i dk why i cant attach the file i mean the file made all the motion of ¨uploading¨ but when i save the post wont upload, i saw it was AoD who was draining the battery (3.2/h) because today i did the test without AoD and get 0.9/h but today see some app idk why running in the background but i restrict it now... thanks anyway

EDIT: Done, ty Oswald. i attach the two files but i dk why the file of today fail at BATTERY_STATS status, still added the two.
[BetterBatteryStats] Oswald Boelcke:
This happened to me occasionally too. Mentioned it somewhere in the thread.

I suggest to zip the idle log and then to upload the zip. This will certainly work.
[BetterBatteryStats] TNSMANI:
Sorry for the delayed reply. Your mobile signal was only good, not great.

No kernel wakelocks registered.

I don't know why Doze itself sets off alarms:

Is Location/scanning on? Switch it off for the next dump.

Your watch caused a lot of Alarms:

Instagram also caused some drain:

FaceBook:

More than 25 MB background downloads/uploads. Will happen on some days and not on other days.

No sensor stats registered.

The maximum drain was because of mobile signal, watch, Instagram etc.
[BetterBatteryStats] DiamondJohn:
Purely a stab in the dark, but most parameters within doze, are driven by "time outs" Setting an alarm may be less taxing on the battery, than looping & waiting
[BetterBatteryStats] DiamondJohn:
One thing I forgot to mention which may have relevance.

The thing that got my looking into Doze started, was that my device was eating a little more battery than I wanted, but was told here its something I should expect for a device so old (new device now). After looking into my Doze history, I found that once it went into deep idle, it constantly had recurring maintenance periods. ie the time out for maintenance periods was too short. Once I change that, my battery drain dropped significantly.

@ShadowDeath So, maybe graphing of your doze history may visually give insight into if these alarms are actually excessive timeouts. Just an idea. You can use TeMeFI
[BetterBatteryStats] xn0live:
hi i have now 2.5-341 is that the newest? because on android 12 its not really working
[BetterBatteryStats] TNSMANI:
Please read the last few pages.
[BetterBatteryStats] cooleydoo22:
Na this is latest one 2.6.382 :)

https://apkcombo.com/betterbatterystats/com.asksven.betterbatterystats_xdaedition/download/apk
[BetterBatteryStats] Ravuri yaswanth:
This is the wakelocks making my device to not enter into deep sleep, can anyone help me to fix this
[BetterBatteryStats] TNSMANI:
This is no way to use BBS to find the culprit. Please read the first page of this thread on how to produce an idle dump and post it.
[BetterBatteryStats] xn0live:
does it work on android 12?