yashsingh1/xdaforums huggingface dataset:
[BetterBatteryStats] DB126:
Both dumps contain significant "screen on" (active / in use) time which does not conform to the desired format and makes them largely useless for idle diagnostics. Need Screen Off -> Screen On which is available if Watchdog is enabled in BBS settings.

Quick possible solution: locate Google Play Services under settings->apps (if necessary enable 'show system' from the 3-dot menu), clear all data under Storage (you'll need to drill down a bit) and then reboot. See if that fixes it.
[BetterBatteryStats] soilentgreen:
I'll try.

One question: If I use BK disabler it can cause this, if I disable somthing I shouldn't?

screen on/off appear just an hour ago.

thanks.
[BetterBatteryStats] DB126:
Yep - depends what you clobbered.
[BetterBatteryStats] soilentgreen:
this is what I disabled:
[BetterBatteryStats] TNSMANI:
Sorry, that is the limit of my knowledge as far as this wakelock is concerned.
[BetterBatteryStats] DB126:
Not going there. Follow the previous suggestion. If no joy reenable everything, reboot and see if problem persists. If all good you can disable a few items at a time until the culprit is identified. Problem determination 101.
[BetterBatteryStats] soilentgreen:
Thanks I'll try
[BetterBatteryStats] bland.life:
Why does HockeyApp need registration?

Is the XDA edition compiled on-the-fly with some unique individual HockeyApp account tracking ID?
[BetterBatteryStats] SeberNoid:
deleted
[BetterBatteryStats] mbapril14:
Hi, I'm having a strange issue with the latest xda version.

My initial unplugged charge percentage shown is different from the actual unplugged charged percentage forcing me to set custom ref point every time I charge fully.
[BetterBatteryStats] DB126:
Yeah that's weird. If you haven't already clear BBS storage to see if that offers a quick fix. Otherwise may reflect a permissions issue grabbing the initial charge percentage on your device. Make sure BBB is excluded from battery optimization while experimenting.
[BetterBatteryStats] chamonix:
Double post - deleted
[BetterBatteryStats] chamonix:
No individual tracking, I use hockey-app for distribution and basic analytics / Crash reports, that's all.

Of course you can opt-out of analytics
[BetterBatteryStats] soilentgreen:
The battery state in the first time was 0% sleep time and:

com.cmplay.tiles2 (): Wakeups: 364 (2.8 / h)

Alarms: 362, Intent: com.cmplay.tiles2/com.cmplay.tile2.ui.ReportService

Alarms: 2, Intent: tiles2_ccrash_delay_task_action

I uploded two dumpfiles after I restart my phone and disable Tiles 2.

"screen off Screen on" (8 h 38 m 49 s) awake (scren off) is 34 m ,6.7% , and "Unplugged Current"(1 d 16 h 30 m 48 s).

Thanks again for your help.
[BetterBatteryStats] DB126:
First dump (screen off -> screen on) is a proper idle dump and shows 0.5%/hr drain which is excellent. Nothing more needs to be done.

Second dump contains 5 hours of screen on time which is unsuitable for idle analysis.

Enjoy your device.
[BetterBatteryStats] Unreasonable_User:
I see that I was at -1.0% per hour, which I'm pleased with, especially considering I have a needless amount of crap installed. But is there any super low hanging fruit that could make a noticeable improvement?

I'm not trying to min-max optimize reach battery perfection nirvana but if preventing a couple of wakelocks or uninstalling something would net some decent returns, you know, why not?

*fingers crossed the dump is acceptable*
[BetterBatteryStats] Vordx:
10% per hour you mean?
[BetterBatteryStats] DB126:
Log is excellent; thanks for taking the time to do it right. :)

~1%/hr idle drain is reasonable given device and amount of background activity. Doze patterns look normal with no smoking guns among reported apps/services. The 2+ min run at max CPU is interesting but does not necessarily indicate a problem. Could simply be some routine reorganization taking place during one of the maintenance windows.

It appears the mobile network connection was a little dicey during the run. Might see if repositioning the phone yields a little better signal strength which *may* allow the mobile radio to dial back power level. Alternatively, flip on the WiFi radio which may or may not help.

Going to suggest something that I normally frown upon: try aggressive doze in Greenify. Since you are not pursing "battery perfection nirvana" (lol!) it *may* lower idle drain rates by a tenth or two at the expense of increased power consumption (plus potential lag) and possibly delayed notifications during/after long slumbers. Usually aggressive doze is counterproductive but your situation presents an ideal use case if any benefit is to be derived.

tl;dr - No action needed. Enjoy your device.
[BetterBatteryStats] SingularityHRT3:
Device was ideal for about 8 hours but lost 10%... There is not wakelock in the wakelock section and only Play Services seems to be using many alarms but still the graph is filled with wakelocks... Dump attached...
[BetterBatteryStats] DB126:
Screen-on (active) time > 1 min; not usable for idle analysis. You'll need to redo the dump.
[BetterBatteryStats] SingularityHRT3:
Ops... Ok I will redo it and report next morning (or may be in an hour)... Any guess what the reason could be??? Play Services Alarms???
[BetterBatteryStats] Unreasonable_User:
Thanks for the response. I'll give aggressive doze a try. As for the mobile/wifi data, that's a false indication. My bedroom is essentially the 3-dimensional center of a 105-ish year old apartment building meaning it's the signal equivalent of a bomb shelter and faraday cage lovechild. No issues elsewhere and I don't feel inclined to buy a wifi extender or upgrade to mesh atm, so I'll accept the minor hit.
[BetterBatteryStats] strongst:
If you use your device while screen on its not possible to say it's this or that cause when you use any mail or chats then play services are also triggered. It's also possible to set screen on/off references if you need to use your device. But better to do what [MENTION=5488402]Davey126[/MENTION] wrote: dump without screen on time
[BetterBatteryStats] DB126:
Procedure: https://xdaforums.com/showthread.php?t=1179809&p=72467976

---------- Post added at 12:57 PM ---------- Previous post was at 12:22 PM ----------

Re: mobile signal - agree it is probably not worth messing with (purists just blew a tire) but not a false indication. Might try going a few hours in airplane mode to understand the magnitude. Of course, not all of the delta can be attributed to the mobile radio but you will likely expose the lower (practical) boundary. Most apps/services will defer communication attempts when no path is available. Then again, a simple charge wire is a wonderful elixir. :)
[BetterBatteryStats] Unreasonable_User:
False indication was a bit of a misnomer on my part. The indication was real, obv, was more me trying to highlight that I understood the context of my particular situation. Everywhere that isn't where that test took place is better for signals. Aggressive doze got me ~.1%/h improvement. May try an airplane mode test to see where the floor is, but I think I'm generally good. No need to make battery savings my white whale. Thanks for your work here.
[BetterBatteryStats] RASTAVIPER:
Anyone has any idea what is causing this extreme use of sensor by Microsoft launcher??

Unleashed by my rooted OP3T on 8.0
[BetterBatteryStats] karkand:
Edited:

Idk what is going on with install directly from download notification. Always got error which ever version I downloaded. Maybe rom issue. Sorry for it. Fixed by install it thru filemanager.
[BetterBatteryStats] strongst:
Accelerometer is used by launcher most likely cause of orientation. Landscape/portrait.
[BetterBatteryStats] RASTAVIPER:
Hmm.

For testing, I used ONEPLUS launcher for a few hours and there is no more use of such sensor.

So definitely it's an issue only with that launcher. Too bad and I really enjoyed using it.

Unleashed by my rooted OP3T on 8.0
[BetterBatteryStats] strongst:
You can monitor the behavior of both launchers to see if the impact on sensor poll makes a difference to the launcher without sensor poll. Maybe it's only minor and you don't care about the drain(when there's one) :good:
[BetterBatteryStats] T@z90:
Hi guys, that's my log overnight, with an average battery drain of around 1%/hr. Is there anything I could do to improve it?

Sensor: Significant Motion Detector(22), wakeup=true, Time: 5 h 49 m 39 s is this normal?
[BetterBatteryStats] RASTAVIPER:
How you cannot care when it's occupying the sensor for 8 hours at 98% of use?

Unleashed by my rooted OP3T on 8.0
[BetterBatteryStats] strongst:
Simply when it's not draining the battery more like the launcher without sensor usage:)
[BetterBatteryStats] TNSMANI:
You seem to have a mobile signal issue. Either locate phone at a different place where it has better signal or switch to 3G/2G during night.

Xiaomi push causing too many alarms to fire (12.1 per hour). Silence it or adjust frequency if possible.

Facebook is another one causing 3.6 alarms per hour.

Though your wifi was running the entire time, the phone was using mobile data only. Mobile data will usually cause more drain than wifi. Check why your phone was not using the wifi.

I think if these are taken care of, your drain will come down to 0.5% per hour or less which is alright.
[BetterBatteryStats] DB126:
Lol - visibility is not always a good thing. Many device subcomponents are continuously engaged. Thank goodness BBS doesn't expose them all.
[BetterBatteryStats] RASTAVIPER:
But the thing is that Microsoft launcher occupies massively the sensor, when ONEPLUS launcher doesn't.

So it's not like it's a standard thing.

Unleashed by my rooted OP3T on 8.0
[BetterBatteryStats] Vordx:
Wifi running was always there for 100% of the time , I usually do this when I get my phone but didn't know when I got Oreo I had to do it again.

Go to location , turn it on if it was off , find improve accuracy , turn "wifi scanning" off.

That option was leaving the WiFi on even when you turn it off and continues scanning in background.

I have note 8 , so you might find this option somewhere else.
[BetterBatteryStats] DB126:
Whatever realizes your personal zen. Again, much goes on behind the curtain that you do not see. I would go with whatever launcher suits your fancy in the absence of tangible side effects (lag, battery drain, thermonuclear war...). :p
[BetterBatteryStats] rocky459:
I have not read the whole conversation, but if its MS Launcher + sensor issue, remove sensor permission from launcher. Also, don't provide any admin privileges to this app.

Using the same launcher. Thanks.
[BetterBatteryStats] RASTAVIPER:
There is no such sensor permission to be selected for this app.

Unleashed by my rooted OP3T on 8.0
[BetterBatteryStats] rocky459:
Hi, Depends on custom ROM. Snapshot attached.

( Device : Lenovo Z2 plus, Custom ROM: Jaguar)
[BetterBatteryStats] AndroidWars:
I'm using N910c Nemesis Refined custom rom rooted. My betterbatterystats showing no or unknown signals %100. Any wakelock other help? :confused:
[BetterBatteryStats] nijihana:
Can someone tell me why other Google alarms /wakelocks / services don't appear on my amplify? 50 Percent of the stuff in the tutorial don't appear in search
[BetterBatteryStats] SingularityHRT3:
6% drain in 6 hrs... Even though the device is going into Deep Sleep very well, Play Services seems to be using to many alarms... I have attached a cleaner dump and also yesterday's Play Services screenshot which shows its extreme...
[BetterBatteryStats] DB126:
Drain rate was closer 0.8%/hr (7.33 hr / 6%) which is a little high but not outrageous. Google Play Service is not the culprit; location services, social media apps, utilities and Titanium backup are. Observations/suggestions:

- disable location services when not needed

- check titanium backup for scheduled activity

- facebook, instagram and whatsapp were all active syncing content

- airdroid, textra and hike messenger also enjoyed a seat at the table

- CPU was pegged for nearly 12 min; thinking Titanium was the bad boy

Given the amount and intensity of activity during the ~30 min of screen-off wake time I'd say your device did very well to stay under 1%/hr drain. You will need to do some pruning/tuning if you want to see better results. Personally I'd go after the first two and call it a day. Good luck.
[BetterBatteryStats] RASTAVIPER:
I have stock Oxygen.Os.5.0.1 (Oreo)

Unleashed by my rooted OP3T on 8.0
[BetterBatteryStats] chamonix:
No interference, betterbatterystats is a completely non intrusive tool
[BetterBatteryStats] chamonix:
Yes that's on the feature list already (see first posts)
[BetterBatteryStats] TheSmokingAndroid:
So i believe this app just helped me identify what is eating the crap out of my battery.

Alarm Manager.

What the hell, i can't even find it in Titanium Backup to freeze.

Cheers for the app...i know this is the wrong place to ask but would you by any chance know how to freeze and or stop this process from running?
[BetterBatteryStats] dmarden:
Hrm, just started using MIUI to see how it feels and this great app doesn't seem to work. Opens fine, but no data displays.

Tried with the MIUI battery monitor enabled and disabled.

I saw someone said they were using it on MIUI, so might not be an app issue completely...

Any info I could look at or provide to help figure it out?

Thanks in advance.

Nexus S 4G

MIUI 1.8.5
[BetterBatteryStats] Lownita:
I don't understand where to look that up in the Battery Monitor Widget? Could anyone tell me? :cool:
[BetterBatteryStats] dmarden:
It's some sort of display thing... Seemingly random combinations of flipping the hide time option and closing/re-opening and flipping the display menu will sometimes result in seeing the info.
[BetterBatteryStats] hyperbolic:
Hey there,

Wanted to say what a great app, and now after a long use of my SGS2 (Stock 2.3.3,CF-root), I would like your opinions about which apps should I remove/freeze that my phone won't wake up during the time screen is off.

Check the screen capture
[BetterBatteryStats] chamonix:
Version 0.7 is out with some cool features (check release notes)

Enjoy!
[BetterBatteryStats] carlos67:
Alarm Manager - count - 3738

That is a lot of wakelocks! I also have a large count on Alarm Manager even though I always use the back button when exiting apps. I just wish I could get to the bottom of why the count is sooooo high.

I know the % time used is relatively low compared to overall time, but, it looks to me like Alarm Manager is constantly waking the phone hence 3738.

Am I wrong about this??????????????????:confused:

Edit: @Chamonix - thank you for the latest version of this excellent app.
[BetterBatteryStats] nobnut:
Very much liking v0.7.0. Thank you!

Sent from my Motorola StarTac using Voodoo
[BetterBatteryStats] popy2006:
Nice application :D thx!!

Have found out that the location services (maps) is preventing my phone to enter deep sleep mode. Have freezed all apps which ill think using the google location services, but my phone doesnt enter deep sleep :mad:

Have now temporary disabled location services.

A nice feature will be to see which apps using location services. Maybe thers an api for that? This would be a nice feature to that ones who have problems with the loaction services.

cu

thx

pOpY
[BetterBatteryStats] TheSmokingAndroid:
Im getting the same thing. Massive AlarmManager counts...in fact my % is about 25-30% ...i have un-installed the apps that i believe may use this service and still it's AlarmManager is at the top doing the same thing...i am stumped and frustrated...especially since i don't know whats using alarmmanager..
[BetterBatteryStats] vivmar:
Same Here.....
[BetterBatteryStats] hyperbolic:
Looking forward for a solution.
[BetterBatteryStats] chamonix:
Just to re-iterate on hitting the back button to leave apps and why it helps reducing wakelocks. It is related to the lifecycle on activities (jargon for windows). The lifecycle is explained here: http://developer.android.com/reference/android/app/Activity.html

As you can see onPause is an important transition because it's the transition where the persistent state is to be saved (eg to a database). Pressing back on an activity calls onPause, meaning android can remove the app without the overhead of doing I/Os and the associated Garbe collection later as it does that straight away.

I will look into AlarmManager today. I don't believe there is a way to find out what apps have requested any but knowing some patterns will not harm.
[BetterBatteryStats] chamonix:
AlarmManager

Here we go: http://developer.android.com/reference/android/app/AlarmManager.html

Unfortunately there is no way of querying the AlarmManager to get a list of the PendingIntents waiting to be called.

Now to the potential of wakelocks:

- lots of PendingIntents (programmed alarms) will generate lots of wakelocks

- poorly designed Intents will keep long waklelocks if they do a lot of processing in the Intent that is called back.

So there's nothing we ca do about it? naah ;)

I have been looking into the kernel and found this:

That will list all the alarms sorted by type, show the PendingIntentRecords, the repetitions etc.

The causes we look for are there but now we need to look into interpreting this and/or bringing it into a readable form.

Once we have spent some time understanding this file and maybe formatting the output properly I would be happy to add that processing to BetterBatteryStats.
[BetterBatteryStats] carlos67:
Excellent, finally we may get to find out which apps/processes are using alarm manager. Looking forward to more news on this.

Would it be possible to explain why the alarm manager wakelock count is high (sometimes in the thousands), but the total time for alarm manager is quite small i.e. maybe as low as a few minutes. This implies a lot of successive rapid on-off wakelocks.
[BetterBatteryStats] hyperbolic:
Hi and thank you for your replay,

I would like to look at that file and try to realizing it, I have CF-root, can you tell me how to get to this file ?

thx.
[BetterBatteryStats] Kurre:
Use some shell terminal app from market if you don't have adb. Just navigate to sdcard with "cd /sdcard" and execute "dumpsys alarm > dump.txt" and it will make dump.txt file to the root of sdcard.
[BetterBatteryStats] chamonix:
The high number with low wakelock time in total just tells you that the intents called do their job right by not being long running processes. I have no clue about the reason of the quantity in a first place though but that should be answered when you look at the dump
[BetterBatteryStats] chamonix:
If retrying does not solve the problem please drop me the email you bought bbs with in pm or by mail so that I can check the order

Edit: typo
[BetterBatteryStats] glennkaonang:
Chamonix, could you take a look at my previous post here as I added new SS and dump file.

http://xdaforums.com/showpost.php?p=22673673&postcount=3370

I'm sorry I didn't have a long time to keep my phone idling.

I want to know if there's something wrong that drains my battery.

Thanks.
[BetterBatteryStats] hoopsbwc34:
My first time trying out BBS to get an idea of what is going on with my battery life. After reading here I did an overnight test.

My phone dropped to 64 overnight... it looks like from the raw alarms that Gtalk (454 wakeups) and Google Maps (289) are the biggest issues. "android" also had 347 but I'm guessing there isn't anything I can do about that? How do I keep Maps from waking?

Raw kernal wakelocks were dominated by vbus_present but I wasn't charging overnight. Does the raw wakelock count look back to last reboot or something maybe?

mmc_delayed_work was also high on my list, which from searching through this thread to seems notoriously difficult to track down.

Anything else obvious I am missing? Thanks
[BetterBatteryStats] eranyanay:
Im having severe issues with my phone..

AlarmManager counter is constantly growing, and I have alot of wakelocks without figuring out why.

Im running with stock 2.3.6 with nothing special, just pure calendar widget (without auto sync) and anyDo small widget.

If i dont have wifi signal i use 3g, and if i dont have BT its closed..

I also have a weird behavior - something that wakes the device for a second, and ever since it happens, till it reset the device, BBS says device is awake (like 100% since it happend), and battery info (built-in) doesnt show it (of course its true, I feel the fast wake-up when i turn screen on, and i see the drainage..)

I added the most recent dump, but I have additional info in here:http://xdaforums.com/showthread.php?p=22713624#post22713624 (photos and more dumps)
[BetterBatteryStats] k1bu:
Device: Samsung Galaxy S II I9100

ROM: HyperDroid Androidmeda v6.1.17

Kernel: RedPillKernel_Rev1.3

Hey chamonix,

The app is outstanding, bought the market version ;)

I've uploaded a dump file for you to run your eye over, I guess it looks good from where i stand, but i wanted to see if you thought it was all good.

100%>98% after 9hrs or so
[BetterBatteryStats] Hrithan2020:
Hi all,

Am facing quite a few kernel wakelocks. The phone went from 100 to 92 in seven hours of no use. :(

Any idea what secril_fd-interface, multipdp and event2-2047 stand for?

Here is the link for the dump:

http://db.tt/tHdFJELT
[BetterBatteryStats] jeremysherriff:
Holy crap Batman :eek:

Dude, I would be celebrating: 17.5m of unexpected awake time (awake less screen-on) over 7+ hours?

Granted, it's not quite as flash as k1bu's but this is pretty damn good.

Edit: Sorry, I would like to help but i can't see anything obviously "wrong" but I'm no expert.
[BetterBatteryStats] pikachu01:
What kernel are you using? :)
[BetterBatteryStats] Hrithan2020:
Keep in mind that entire mobile data as well as auto-sync was off for the major part of the time, and this becomes much worse!!

[ when I was sleeping, I have scheduled tasker to keep my phone in silent mode and also switch off net, not sure whether I manually enabled it afterwards though].

Not able to understand, why I am getting needless kernel wakelocsk :(

[ secril_fd-interface,alarm_rtc,event3-2047,multipdp,l2_hsic etc. ]
[BetterBatteryStats] KMAngelo:
Okay, I fixed the things you said and made a new dump and observations covering a night. It's still the same with a battery drain at about 20% during the 8 hours. As i can see I have got some weird wakeups during the night, but what caused it I have no idea.. :confused: And I have fast dormancy turned off..

I have tried several other different kernel-modem combinations, but it's still the same..

Some extra info if needed:

Device: Samsung Galaxy S II I9100

ROM: The-GingerMOD v0.8

Kernel: RedPillKernel_Rev1.3

Modem: XXKH3
[BetterBatteryStats] Hrithan2020:
Wow!! if the dump you have attached is correct, you have just a little below 3 mins wakelock in almost 9 hours!!!

Maybe the battery needs to be calibrated? Next time , try with 100% battery, I am sure with those kind of wakelocks it would be below 5% :)
[BetterBatteryStats] Pfeffernuss:
Device: Samsung Galaxy S II I9100

ROM: HyperDroid Androidmeda v6.1.17

Kernel: RedPillKernel_Rev1.3

:confused:
[BetterBatteryStats] Karpfenhai:
@kmangelo, since your stats are pretty clean and the dialer (cell standby) seems to be your top consumer i would suggest to try different modems, start with ki3 which is known as battery saving. Does the drain occur in flight mode too?

Swyped from my GT-I9100 using XDA App.
[BetterBatteryStats] aashgaur:
this is my dump file .... plz help !!
[BetterBatteryStats] Settembrini:
Galaxy Tab 7.7

Hi Chamonix,

there is no result (Galaxy Tab 7.7) when I use "More" "raw alarm". It computes for a while, but nothing is shown?

When I do the same on my Galaxy Tab 7.0 plus, there is an immediate result.

Any ideas?

Thanks!

S.