yashsingh1/xdaforums huggingface dataset:
[BetterBatteryStats] chamonix:
That is interesting stuff and I understand where it comes from: since charged...

Let me explain: as neither alarms nor kernel wakelocks are managed by android there is no references stored bye the battery info service. That's the job of the bbs service to store references for those events, in response tothe unplug and to the battery full event.

Now what you experience is android firing a battery full even every minute, leading to a dump of kernel wakelocks and alarms (with su access).

Refreshing the ref every minute once the battery has reached 100% is a bad design, I admit.

Let me think of alternatives loud:

- store the refs the first time the battery reaches 100%

- store the ref for "charged" upon unplug if the battery level is 100% at that time

Imo the second solution is better and I will look into that tonight. I guess I will skip releasing 1.6 to the market and deliver 1.6.1 instead
[BetterBatteryStats] chamonix:
In fact that is a feature and not a bug. Refreshes were fired on each 'on resume' means when recalling the main screen to the front and when an overlapping dialog. A refresh obviously causes a query to the batteryinfo service, reads and parses wakelocks and alarms, calculates the delta to the reference. While promoting the alarms to the main screen I did some profiling and as we don't all have dual core courses I used the opportunity to clean up. The views still refresh but they don't query the data.

As you noticed I guess I should have taken that more prominently to the reader and maybe add a pref if some users still prefer to have the auto refresh happening
[BetterBatteryStats] jeremysherriff:
Agreed, option 2 is better.

Is there a situation where the battery has reached 100%, and then backed off a little as it trickle-charges? Ie drops back to 99%? I've seen my phone drop instantly to as low as 98% when i unplug, but "instantly" is still within some refresh interval for the status bar..
[BetterBatteryStats] ybres:
A quick suggestion: Take into consideration the case when the service is stopped (lets say by a nosy user like me [remember], or other reasons) that doesn't care about kernel and alarms reference. Make sure the app will just ignore references and not manifest an unstable behavior as above...

Can't stress enough the good job you are doing. ;)
[BetterBatteryStats] chamonix:
The mentioned instability was as I said a bad idea / design.

I have fixed it now and with the new "clean" design we will even be able to get rid of the service (for now).

I will do some more testing but because "unplug/plug" events can be registered by the manifest I think it could work. The only reason for the service to exist is because battery events can be registered the easy way (by manifest).

I will test all that tomorrow morning and hope releasing by tomorow noon CET.
[BetterBatteryStats] dragunbayne:
Hey, been searching the internets without any luck. Anyone know what spi_tty_wakelock is? It's one of my highest wakelocks along with alarm manager because of Tasker and event log service.
[BetterBatteryStats] stuart0001:
Just a small suggestion to edit your thread title to include ICS.
[BetterBatteryStats] doctorow:
(My apologies if this had been noted before.) I love what this app does and it helped me discovering a few culprits. Only one suggestion. I noticed that BBS is regularly using CPU cycles, which makes sense as long as it's supposed to gather battery stats. But it would be nice if there was an ON/OFF switch so that BBS could be activated only when needed (like when analyzing newly installed apps, or a new ROM) and when turned off, it wouldn't use any CPU cycles.

Cheers

Doc
[BetterBatteryStats] pjadec:
Light flow keep your phone awake. Also google services.
[BetterBatteryStats] DB126:
Can't substantiate latter claims given high active (screen-on) time.
[BetterBatteryStats] pjadec:
Probably true, but light flow use much longer time than sot time.
[BetterBatteryStats] ranaxda200:
How that power manger service of kernel wakelock is null? Mine has always been 30~50% or above. Dunno what's causing this coz all partial wakelock data shows null points.
[BetterBatteryStats] bigknowz:
Dump 2

This dump is from overnight..
[BetterBatteryStats] DB126:
Device never entered deep sleep (awake for 8+ hours). Light Flow was the culprit as [MENTION=3851273]pjadec[/MENTION] speculated.
[BetterBatteryStats] fossils-n-dents:
For me, I use the Elementalx kernel, and a few tweaks. Since then, I haven't had a high powerservicemanagement wakelock count in months. All trial, and error.

However...

Your BBS is listed as only one hour...No good. You should do a 6+ hour BBS idle run for accuracy, then submit a proper idle dump to this forum. Save the dump first, then take screenshots of your 'Summary. Kernel Wakelocks, Partial Wakelocks, and Alarms, and post them all.

These dudes know their stuff, but you have to meet them half way. Follow the OP.

Good Luck.;)
[BetterBatteryStats] peterlee928:
my phone was charged 100%

left idle for abt 3 hrs

when i checked bbs

it was awake 100% of the time

though oddly enuf

phone was still at 100% charge

how would i go abt

finding the culprit?

much thx in advance :)
[BetterBatteryStats] h_maharaj:
Follow instructions in the OP for producing an idle log.
[BetterBatteryStats] orlans21:
Hi, this is my first time posting a dump file but I need to because I haven't been getting that good of battery life since updating to 7.0 on a Galaxy s7 edge. So I am hoping I could get help from the community as to reasons why I have battery drain. Also I want to know what is up with all those android alarms.

http://imgur.com/a/a3ZTj pictures of BBS

https://drive.google.com/open?id=0ByzhyGGdnR3mb1dZRFpILTNkMnM < dump file
[BetterBatteryStats] DB126:
Log contains 2+ hours of active (screen on) time making it useless for detailed analysis. See OP for guidance on creating a proper idle log or follow alternate procedure here.

Statistic Type: Charged to Current

Since 9 h 43 m 2 s

Level lost [%]: Bat.: -17%(100% to 83%) [1.8%/h]

Voltage lost [mV]: (4282-4110) [17.7%/h]

Deep Sleep (): 6 h 8 m 53 s 63.3%

Awake (Screen Off) (): 27 m 2 s 4.6%

Screen On (): 2 h 12 m 50 s 22.8%
[BetterBatteryStats] RiDEN_1:
What can be the cause of *job.deadline* and *job.delay* wakelocks?
[BetterBatteryStats] orlans21:
Alright followed the instructions in the link you posted. will do an idle run when i go to sleep. Question though, do I need to use it so it can run down to 95% or can i start the test right after i unplug it at 100?
[BetterBatteryStats] DB126:
Android system - they are of no concern.
[BetterBatteryStats] koekoek91:
No, the key here is to get an idea of what is keeping your device awake when you are not actually using it.

So:

- Charge to 100%

- Unplug and turn off the screen

- Don't touch your phone for at least 6-8 hours

- When you wake up, or 6-8 hours has passed, turn on your screen and immediately save a log and post it here so [MENTION=5488402]Davey126[/MENTION] can have a look at it ;)
[BetterBatteryStats] DB126:
You can start at any level. Results are slightly more accurate mid-range but nothing to be concerned with on a first run.
[BetterBatteryStats] orlans21:
I hate that i've already done 2 or 3 tests and I would have to fully charge. I hear its not good to charge up to 100 but ok like once a month
[BetterBatteryStats] DB126:
As previously stated you can start the test at any level provided BBS watchdog processing is enabled. Don't forget to set the range to 'screen off' / 'screen on' before capturing the log.

Your battery will not be harmed by regularly charging to full capacity given the typical usage pattern of a phone (frequent charge/drain cycles) and type of battery pack. The guidance you heard comes from a mis-adaptation of laptop charging guidelines. Those devices use batteries that are optimized for higher drain rates and often spend long periods of time in a fully charged state (eg: plugged in).

Heat has a far greater detremental effect on small Li-ion batteries than fully charging on a daily basis (assuming the pack does not remain in a fully charged state for prolonged periods).
[BetterBatteryStats] orlans21:
Sorry but how do you set it to screen off/on. I see an option to show stats from screen off and screen on
[BetterBatteryStats] DB126:
Set spinners to 'screen off' (left) and 'screen on' (right)
[BetterBatteryStats] orlans21:
If I do screen off left then I don't have an option to set screen on right but if I flip them I can.
[BetterBatteryStats] RiDEN_1:
Even if there are 220+65 alarms in the span of 16 hours? What do you mean by "no concern"? Is it that you can't do anything​ about it, or that it doesn't really matter in terms of battery life?
[BetterBatteryStats] olivercervera:
Unfortunately I can't perform that procedure since I need to use the phone. Is there any easier way?

Anyway, looks like other people is seeing the same problem.
[BetterBatteryStats] orlans21:
Here's my latest test.

https://drive.google.com/file/d/0ByzhyGGdnR3mRVBidUxTWDR6czA/view?usp=drivesdk
[BetterBatteryStats] DB126:
Both. Visability does not equate to a problem. If concern persists submit a BBS idle log as outlined in the OP and elsewhere in this thread.
[BetterBatteryStats] Oswald Boelcke:
I personally don't know about an easier way.

Normally, I conduct my BBS logs while I'm sleeping - and my phone is hopefully at deep sleep, too.
[BetterBatteryStats] DB126:
A BBS idle log will answer a handful of questions that may help diagnose the issue with partial wakelocks; it can be obtained overnight when the phone is not in use. Or try a different tool such as GSAM.

---------- Post added at 01:45 PM ---------- Previous post was at 01:02 PM ----------

Overall your device is performing as expected given on unrooted Android 7.x. Phone was a awake for 18 min over 5+ hours, much if that due to Pulse SMS syncing. Overall loss was only 4% (0.8%/hr) which includes 2+ min of screen on time that likely drew down the battery and influenced final the stats. I also noted a significant​ voltage drop which suggests the device recently came off the charger. Nothing wrong with the pack but it may exhibit slightly different rates of decline in the 95-100% range than elsewhere.

Bottom line: no action required (assuming you like Pulse SMS & benefit from cross device message syncing).
[BetterBatteryStats] orlans21:
Thank you for the analysis, I don't use pulse on any other devices seeing I only have one device and I don't need it for my pc. I was also wondering what else I could do to drop the android system percentage that has been higher than my SOT almost most of the time. Example from this shot. I've seen people with the same device and unrooted with 6+ SOT and I could get 6 if I was on the very first security patch samsung used for the release of the s7 edge.
[BetterBatteryStats] DB126:
Nah - not going there:

- there is no significant correlation between "SOT" and Android System time

- SOT is an unreliable metric that is largely device/rom independent and not consistently reproducible except in a sterile lab environment

- how you configure & use your device along with environmental conditions and battery health largely determines usable run time

- panel backlight is the main power consumer on most devices; even small variations can make a big difference in SOT

Want more run time? Drop the screen brightness. Everything else is icing assuming no rogue processes/services and decent signal strength.
[BetterBatteryStats] orlans21:
Really even a little bit of brightness can make a difference? I was pretty much doing the same as last year while I got 6 hrs SOT. Actually I'm even doing less with a lot of stuff turned off
[BetterBatteryStats] orlans21:
Did another test last night. It seems like it was even better than the one before and sync was turned on this time and I deleted pulse SMS. PROPER LINK UPDATED.

https://drive.google.com/file/d/0ByzhyGGdnR3mU2h2dG90RE94T3M/view?usp=drivesdk
[BetterBatteryStats] DB126:
Appears link points to an older dump vs latest run. However, limited info from screen snips suggest an average 0.2%/hr drain with 6 min screen-off wake time over ~5 hours. It doesn't get much better than that on Nougat. Removal of Pulse likely contributed to most of the gains; sync typically doesn't run during doze.
[BetterBatteryStats] orlans21:
Sorry about that, posted the proper one now and thank you for the analysis. Waiting on your analysis for dump file.
[BetterBatteryStats] DB126:
Contains 13 min of screen-on time; consult previous posts for guidance on creating a proper log (screen off -> screen on)
[BetterBatteryStats] orlans21:
I swear sometimes it didn't give me option to select screen on (right) sometimes so I left it screen off and current but I'll do another one when I go to sleep. Also im curious why it drains a lot faster when it's in my pocket or while I'm at work. Signal does get bad at work so that could be why.

I would also like to thank fossils-n-dents for helping me out too.
[BetterBatteryStats] bryanjay420:
please check if my dumps are ok. tia
[BetterBatteryStats] DB126:
First log had 33+ min screen-on time; not useful. Second log appeared to have media (likely music) playing/streaming during screen off which contributed to a somewhat elevated drain rate.

Edit: no evidence of streaming based on network stats (overlooked that); likely local content.
[BetterBatteryStats] Limakos:
[MENTION=5488402]Davey126[/MENTION]

I would appreciate your opinion on attached log.

Thanks
[BetterBatteryStats] DB126:
Screen on to screen off (proper log) - thanks. :)

Unfortunately, stats are suspect as most wakelock durations are identical (5m 2s). This has been reported by others on Android 7 but there does not appear to be a generally accepted resolution. Other observations with above caveat in mind:

- device was awake for ~23 min over 6½ hours which is not exceptionally high for Nougat

- however, fall off was 10% (~1.5%/hr) which is excessive given relatively low CPU utilization during wake time

- older device suggests battery has enjoyed a long life cycles and probably has lost some capacity/endurance

- a 37+ MB Play Store download contributed to wake time; consider switching to manual updates

- appears location was set to 'High Accuracy' which generates activity (wakes) and periodic uploads; consider disabling location services when not in use or switch to 'Device Only'

I also wonder if the Lineage build being used is optimized for kernel given age of device.
[BetterBatteryStats] Limakos:
Thanks for the analysis. I noticed that issue with wakelocks having the same time appears on Resurrection Remix roms. I have RR installed on two devices and on both situation is the same. I replaced battery couple of weeks ago and it was supposed to be original. Maybe it isn't after all. I have Play Store updates set to manual so maybe play services did its own upgrade. I will try again today with location switched off.
[BetterBatteryStats] Lughnasadh:
I was wondering if someone would be so kind to look at my dump? 10% loss overnight and 13.8% awake (screen off) seem to be high but can't quite figure out where the drain is really coming from and best steps to stop it.

Its from unplugged>current (done overnight without touching phone) with only 29s screen on time so hopefully its a good dump (apologies for not doing screen off>screen on. Simply forgot)

Thanks!
[BetterBatteryStats] DB126:
Pulse SMS is the likely culprit. Loose that and see where things stand. Nothing against Pulse; likely a fine cross-device/platform messaging client. However, it appears to be mighty aggressive with the syncing with unnecessary long wake locks. There may be some configuration options to limit syncing; haven't used it. Also verify it didn't exempt itself from battery optimization (a.k.a. doze white list).
[BetterBatteryStats] Lughnasadh:
Thanks. I'll try that. Much appreciated :good:
[BetterBatteryStats] thomasck:
Well, just find out whats draining my batterie. 4G on all night. Switch to off, sleep, when i woke up, 100% still!
[BetterBatteryStats] fossils-n-dents:
Your solution is really cute and all...but, that's like getting a flat tire, and turning the radio up to ignore the problem. Don't you wish to know why you have to disable the most important feature of your phone in order to obtain proper idle drain? Real power users want their devices to idle like a boss, with full functionality.

Turning away totally free, top notch advice/ instruction is never a solution. Follow the OP, put the phone down, submit your dumpfile, and let the pros here put you on the proper path to device enlightenment. Conversations with Davey126 put me on the path long ago.

Good Luck.
[BetterBatteryStats] Oswald Boelcke:
Superb advice. Excellent. And affirmative, let @Davey126 give a chance! ...but that only works after reading, reading, searching, searching, following the OP and posting of a PROPER idle dump!
[BetterBatteryStats] DB126:
Full network isolation can certainly lead to improved battery life! If that suits your needs or WiFi/3G connectivity is adequate while you (and your device) are sleeping then no further action is needed. I am a strong proponent of the '80/20' (preferably 95/5) and 'good-enough' rules. Yes, curiosity can lead to unjustifiable violations (guilty as charged!) but the opposite set of behaviors has its own set of detriments.

As noted by [MENTION=4138220]fossils-n-dents[/MENTION] if you want a deeper read submit an idle log for analysis. Otherwise, enjoy your device as it's there to serve

you

in whatever capacity you choose.
[BetterBatteryStats] thomasck:
Sure, I will do this. At this moment I'm in a process of moving again from Brazil to Europe, I'm already here, but basically all day setting the things up for my wife, that will arrive in 1 week! I will find the reason of that battery drain, just need time, and less worries in my mind :)
[BetterBatteryStats] fossils-n-dents:
Thanks noc.jfcbs!!! You rock! I totally left out the part of reading, searching, searching, and gaining a very basic, functional understanding of what's going on in the background when our devices are left to idle. Davey126 lit the fire explaining to me that my idle problems were likely self-induced.

I started researching on the XDA battery drain forums (I went back as far as 2013), picking up knowledge here, and there. Even searching XDA battery drain forums that were not for my device. Not letting the phone win became my new hobby. I've done more idle runs then I care to speak of. And I follow this thread faithfully.

In the end, Davey126 was correct, I invited 20+ apps, Gapps,, location, Wi-Fi scanning, and sync to assault my battery while I slept.

The sum of my research has been applied to my device. Thanks for pointing me in the right direction Davey126!!!
[BetterBatteryStats] adhammagdy:
So glad I found this thread after searching long for someone to help me with my never sleeping problem..

I have AOSP Extende nougat on my Vibe P1 and previously RR and they seem to be not sleeping at all even with greenify and aggressive doze..

I contacted the devs of these ROMs providing logs and dumps and everything but no one helped..

Tonight I will follow the instructions and collect the dumps and post them here hoping someone helps.

Just wanted to thank you for the great app and the good guys helping in this thread and also the knowledge base..

Just have a few questions..

Partial wakelocks doesn't seem to provide real timing in BBS even though I gave it root permission and set it as a system app and gave all the requested runtime permissions. Is there a solution or a workaround for that?

And also should I disable greenify before doing the test or not?

And should I include the logcat and dmesg or just the dump as stated?

And also I always set airplane mode when I sleep, should I enable it for the test? (The no sleep issue happens anyway)

Thanks
[BetterBatteryStats] DB126:
- missing partial wakelock detail on Nougat appears to be a 'feature' with some devices/ROMs; no solution has been identified (yet)

- configure device as you normally would; no need to disable Greenify or change network connectivity
[BetterBatteryStats] justjr:
On my ROM partial wakelocks is there, but kernel wakelocks isn't. Go figure.
[BetterBatteryStats] Sam Nakamura:
See here:

https://xdaforums.com/showthread.php?t=1179809&p=71755478
[BetterBatteryStats] justjr:
What a hard answer to find, thank you.
[BetterBatteryStats] peterlee928:
would it be possible to provide feedback on my phone based on my bbs log?

i was unable to attach my log to this post. the log is here (apologies for the extra step): https://www.androidfilehost.com/?fid=817550096634780070

one thing in particular that stands out is that my phone was awake almost the entire time. i noticed this recently - somewhat of a new phenomenon. phone used to be in doze mode pretty much the entire time if untouched, but somewhere down the line, the phone was awake the entire time.

i just noticed that in my wifi settings, "network notification" was on. could this be the issue?

my phone details are as follows:

verizon pixel xl

stock rom running june security update

rooted via twrp/supersu

twrp rc2

supersu pixelfix version

much thanks in advance. :)
[BetterBatteryStats] DB126:
Here's your culprit:

CmaSystemUpdateService (Google Play services): 4 h 32 m 53 s Count:100 99.3%

Not sure what that is; could be an attempt to download 'updates'. As with all such incidents best practice is to clear ALL data from Google Play Services and reboot. Likely will not reoccur.
[BetterBatteryStats] peterlee928:
very much appreciate the quick response. i just followed your steps and will see if that does the trick. :)
[BetterBatteryStats] justjr:
Unfortunately the command does not seem to mount debug, it doesn't work.

The folder is on /sys, but no files inside (before and after mount it), and no kernel wakelocks :/
[BetterBatteryStats] Sam Nakamura:
You saw the original post and got the whole command typed correctly?

Cause it worked for me toll reboot before it was properly fixed rom sided..

https://xdaforums.com/oneplus-2/ori...ncokernel-r1-20th-march-t3576338/post71734617
[BetterBatteryStats] justjr:
Yes, I tried a lot of times. The command have no output though.
[BetterBatteryStats] githyanki:
Don't know why that command won't work for you but the end solution is to get rom developer to fix the mount of the debug filesystem. Anything you to is a workaround for a rom issue.
[BetterBatteryStats] Smac7:
Is it normal for Google now/search to be causing 35 wakeups/hour?
[BetterBatteryStats] DB126:
Wakelocks and wakeups are different things. The number of reported wakelocks (requests) is high but not abnormal. Submit a BBS log for analysis to see if further actions are needed.
[BetterBatteryStats] justjr:
Thank you for the info, I opened an issue on DU Jira.
[BetterBatteryStats] peterlee928:
just wanted to confirm that your guidance worked. ran another test (results in link below), and phone was in deep sleep for the majority of the time. thanks again :)

https://www.androidfilehost.com/?fid=745425885120742912
[BetterBatteryStats] virajkin:
Sir

I have a Moto G5 plus,running on Nougat Stock 7.0, rooted and Installed ElementX Kernel, I have been facing battery drain issues. Kindly check the attached log files and let me know what's eating my battery
[BetterBatteryStats] adhammagdy:
Hello, I have a lenovo vibe p1 with AOSP Extended 4.3 official nougat

My phone doesn't sleep at all.

I turn on airplane mode all night.

Doze should be working correctly.

I have no apps excluded in battery optimisation.

I test it as per instruction last night and attach the logcat, dump, dmesg.

Please help me with this problem.

Thanks.
[BetterBatteryStats] pjadec:
Kernel problems probably, android system internetspeedmonitor strange behaving. Something to test, different kernel, factory reset.

---------- Post added at 02:05 PM ---------- Previous post was at 02:02 PM ----------

Sorry, but your logs are faulty. Too much screentime. Please read OP again then do proper log