yashsingh1/xdaforums huggingface dataset:
[BetterBatteryStats] IronTechmonkey:
In forum threads for very widely used and extremely popular apps like BBS, declarations that the app has caused a problem are often met with resistance, especially if the claim is not supported by details. Getting down to brass tacks. There really is little in the installation or removal of BBS that could cause a boot loop on it's own. It is even difficult to see how it could even be a factor. That said, and considering that many boot-loops probably occur due to things done in recovery, there is always the possibility that something went wrong in recovery when flashing the BBS removal zip from recovery (if you did that). Also to consider are broad ranging things such as: the history of the device, recoveries used, ROMs flashed, partitions formated, Root method used, SU used. If you want to isolate the cause of the problem and are in a position to do so I recommend creating a nandroid backup then doing a clean ROM only flash of the same ROM and install then remove BBS to see if the issue is between BBS and the ROM. Depending on the result you can take different directions from there. Sure, that is a lot of work and it's a drag but... something caused that boot-loop and whatever it was it might be worth chasing to prevent it from happening again. IMO that is reason enough to do a clean flash and rebuild. If you were to establish a connection to BBS people would probably try to help fix it or at least work around it.
[BetterBatteryStats] chamonix:
looking at the kernel wakelocks there is a lot of activity related to RILJ, network stats and fast dormancy. Looks like either your modem is not the right one for your service provider or they have implemented fast dormancy in such a way that it does not play well with Android. Turning fd may be an option (I have never been able to observe anything but negative effects in using fd on vodafone)
[BetterBatteryStats] chamonix:
Connecting your phone to usb and running adb to take a logcat may deliver more info about what is failing, including hints on how to fix it. As it was already said there are many things happening when booting. It is highly improbable that a bootloop is directly caused by removing the bbs apk from the system partition, but there are many things that can go wrong during kernel and userland init/start.
[BetterBatteryStats] chamonix:
when you are connected to wifi the cellular modem reports no or Unknown signal.
[BetterBatteryStats] gaich:
FD is turned off. Well, I will try to turn it on to see what will happen..
[BetterBatteryStats] GorJessSpazzer:
Thank you for your reply, i did not flash it i just uninstalled the apk, i did a clean install now but same result

Thanks for replying, I hope this logcat it's ok i don't have much experience doing it, please tell me if i did something wrong or what i've could done to make this happen , i had xposed framework and i unistalled it i thought that was maybe the problem but i still got bootloop. If i uninstall it from settings but it gets frozen and deactived and i can't uninstall it so i go to link2sd app and uninstall it from there, reboot and bootloop.

https://drive.google.com/file/d/0Bz-wuCUpEBq9dnoxQldWVVpLdWs/view?usp=sharing
[BetterBatteryStats] Gliuk_er:
Did someone answered to this question?

On my device both (wifi on and wifi running) have the same values... is this ok?
[BetterBatteryStats] lebidou:
Nevermind, made a mistake. Sorry.

Move along.

Envoyé de mon Nexus 4 en utilisant Tapatalk
[BetterBatteryStats] dchinu:
Battery Historian Graph

Sorry to quote from long past but just found this wonderful app on play store and reached here for some suggestion. Its a wonderful diagnostic app for erratic power consumption.

The current form the battery graph (Menu>Graph) is stale. Its not pannable and usability limited. But its very natural to present usage pattern in visualized graph just like stock battery graph of android but with more details. Which will make BBS more mainstream and user friendly. Battery Historian comes to mind. Which would serve both developer and end user as in device profiler.

[IMG="Profiler"]http://xdaforums.com/attachment.php?attachmentid=3545955&stc=1&d=1447788650[/IMG]
[BetterBatteryStats] IronTechmonkey:
I don't see anything obvious in the log. There are no references to BBS and there are a bunch of errors about system folder files being missing, but then I'm not a programmer and might not notice everything. That said, your description is informative and reveals external factors (Xposed and link2sd) which corrupt the testing. Link2sd may actually be culprit or contributing factor. By the time your are doing anything with link2sd your testing train has already derailed and any results have been rendered unreliable.

Pardon a bit of frustration but I cannot possibly stress this enough. Unaccounted external factors are the single greatest cause of false reports of ROM/app issues and it is frustrating to the people that provide help that you (and so many others) don't just get rid of those factors the first time it is suggested that such be done. As I mentioned in my previous reply. "a clean ROM only flash of the same ROM and install then remove BBS"

Anyhoo - here is a suggested work-flow for a productive test:

INSTALLATION

- Clean flash ROM and nothing else. No gapps. No apps (except Catlog unless you are logging via adb).

- Install BBS apk

- Run BBS then from within BBS install as system app

- Reboot

- Install BBS apk again then test BBS to make sure it is working.

REMOVAL

- Run BBS and through it's own settings un-install the system app component. If this fails then download the BBS removal zip from OP and flash it from recovery to remove BBS system component.

- Reboot device

- Un-install the BBS app.

If this fails then you may have a true issue between the ROM/Device-history and BBS and you might consider testing with different ROM for comparison.
[BetterBatteryStats] briankamkobe:
Anyone know how to reduce wakelock?I'm on cm12.1 and getting 0.3%/hr loss
[BetterBatteryStats] Perseus:
0.3 % / hr is pretty good. Install a Startup Manager app and remove dialer and contact from startup.

You have signal issues. Typically toggle airplane mode for a minute when you reach work/school and again when you reach home.
[BetterBatteryStats] mflajsek:
Can anyone give me some advice based on my current dump since my phone loses around 2% during night in deep sleep? And I have a feeling recently that it chunks a lot more than it should when I frequently wake him up from sleep during daytime while checking for notifications etc.
[BetterBatteryStats] Perseus:
When you are talking about screen unlock / Standby Screen On, makes me think, you have agressive governor setup. That could kill the battery faster than Crapbook.

From your log, I see that you had the phone in use. As mentioned in OP and others here, you should ideally get an IDLE Log. The whole intent of this exercise is to reduce the battery drain when idle so that, whatever drain happens when in use is attributed to that alone.

I can't very well deduce much from this log, however, I see that you are on a chatty wireless as presented by the wlan_wake and wlan_rx_wake wakelocks. Also the fact that you had DHCP Address being potentially renewed 35 times in 5 hours is troubling.

Everything else I am going to blame on Spotify and Youtube unless you can produce an Idle log.
[BetterBatteryStats] mflajsek:
EDIT: accidentally posted twice
[BetterBatteryStats] mflajsek:
Thank you the kind reply. I left the phone for 2 hours on idle and posted the BBS dump below. I hope it clears things up a bit more.

You mentioned the agressive governor setup. I set up the Unikernel of my S6 at the setup to the battery preset and since that haven't changed any setting concerning the krenel profile. I assume that anwsers your persumption if these two things are anyhow connected. The DHCP related alarm and GCM_reconnect were at the top of my alarms list until I limited GCM_reconnect (if that was the right thing to do) so only the first one remains.. Dunno why they are so high though. And Spotify only ran for a couple of minutes on my speakers so it should be such an issue I think.. Although I have a Spotify widget on my home screen, but it doesn't refresh automatically over time, only when I use the app.
[BetterBatteryStats] GorJessSpazzer:
Thank you so much!! I flash my original firmware I really don't know what was the problem, I have BBS in my tablet as I said before, I uninstalled from link2sd and I didn't have the problem but I don't have xposed in there so i guess maybe was xposed the problem or maybe even the ROM I had? What I did was as you said, install BBS, running it and uninstalled from the zip cause it failed from the settings, now i didn't have the bootloop thanks to you
[BetterBatteryStats] Primokorn:
[MENTION=1330150]chamonix[/MENTION]

How could we have negative alarms in a dump file? And we have 2 lines for the same alarm. Dump file here

The counters have been reset between Unplugged and Current?
[BetterBatteryStats] nick_white:
Any response to this, please? Thanks.
[BetterBatteryStats] chamonix:
if you encounter this issue again for it would be great if you could:

a) save the result of dumpsys alarm

b) check-in the raw stats show the same issue

I would bet there is a problem in the parser (not having the error in raw would confirm that), leading bbs to not fold Alarms with the same name into the same value, causing negative values when substracting. The parser is based on regex and it may be an issue as simple as trailing spaces. With a dumpsys at hands I could analyse deeper
[BetterBatteryStats] chamonix:
this has already been answered. The service is responsible to keep a listener for events like plug, unplug, screen o the and off. It is not new to BBS and is required as the android development model does not offer to implement receivers for all events through manifest. Disabling g or killing that service would cripple the functionality of BBS by not saving references anymore
[BetterBatteryStats] Primokorn:
I only have this with Greenify (it wasn't my dump file):

In the raw stats, I have 7 wakeups (0.5 / h) for com.oasisfeng.greenify

Alarms: 7, Intent: com.oasisfeng.greenify.CLEAN_NOW

I have attached a screenshot of raw stats and a dump file showing the negative alarm.

Here is the dumpsys: https://db.tt/OiKZ7o4d
[BetterBatteryStats] kyo@:
where i can get download apk batterystats this?
[BetterBatteryStats] shaggyskunk:
It's Always in the OP - Did you look?

Sent From my SM-N910W8 Running SlimRemix V5.3
[BetterBatteryStats] nixie2121:
does anyone know what can cause this?
[BetterBatteryStats] TNSMANI:
The first one ie NLP Wakelock is related to Location.
[BetterBatteryStats] nixie2121:
thanks, this never happened before, not sure what could cause it now
[BetterBatteryStats] TNSMANI:
May be you have enabled Location now.
[BetterBatteryStats] Plonkplonk:
I had problems with PowerManagerService.WakeLocks months ago on my HTC HD2 (Cyanogenmod 11). I noticed battery drain up to 8 %/h and startet searching for the reason with BBS. This power consumption was seemingly caused by Google Play Store after an update and was gone after I disabled wakelocks for Google Play Service (what didn't effect Play Store at all).

Thomas
[BetterBatteryStats] black_bottom:
My Phone is a LG G4, bootloader unlocked and rooted, ROM V10d-EUR (stock). This morning I noticed that the phone didn't fall into deepsleep. When checking with BBS I found a kernel wakelock called "bluetooth_pm" (BT was enabled but without active BT-connections). So I disabled bluetooth and the phone falls into deepsleep.

So I deleted all data from BT, but everytime when I enable BT again then there is no deepsleep.

Searching Google I do not find any hints about "bluetooth_pm" resp. why it prevents deepsleep.

Does anybody know what to do with "bluetooth_pm" ?
[BetterBatteryStats] RASTAVIPER:
FIRST check if after a restart you have the same problem.

Then if it insists, installamplify and reduce the time of this wakelock.
[BetterBatteryStats] nixie2121:
it kept doing it after a restart. I did a full shutdown and it seems OK now. thanks for the help
[BetterBatteryStats] angwar90:
Hey I need to figure out why my battery drains while idle. I lose 30-40% over night.

My Device is a Samsung Galaxy S6 with Xestrolite and latest Vindicator Kernel.

I am also using Amplify and Greenify.

I made a short dumpfile for now. I can do another one this night if its needed. Any help is appreciated!
[BetterBatteryStats] dchinu:
Wake lock 'Charger_Monitor'

I find this qcom specific Charger_monitor wake lock on which there is very little information available on searching around. Though i did not start this cycle as a diagnostic season but if some one could read between.

[IMG="Unplugged"]http://xdaforums.com/attachment.php?attachmentid=3552788&stc=1&d=1448299218[/IMG][IMG="KWL"]http://xdaforums.com/attachment.php?attachmentid=3552787&stc=1&d=1448299218[/IMG]
[BetterBatteryStats] Perseus:
Go ahead and make another one. This time, leave the phone alone overnight.

Also in addition, have your Wireless Router, issue a static ip to this phone. You will have to configure the phone's wifi connection for that. Turn off IPV6 while you are there. Once done, reboot and leave it alone. Get the dump in the morning.

Charger Monitor kicks in when you are plugged in. Was that the case here ? If not, then reboot and observe if it reappears without you plugging in.
[BetterBatteryStats] angwar90:
Thanks for your help. I will make a new dumpfile tonight.

You meant disable ipv6 on the phone? I don't know how to do that but I will google it.

My router is unfortunately not capable of disabling ipv6.
[BetterBatteryStats] Perseus:
Don't try to disable on Router. That will cause other problems.

Some of the phone's firmware allows to disable IPV6. Others do not. If your's does not let you do it, then don't worry. Just focus on the rest of the instructions I had mentioned.
[BetterBatteryStats] dchinu:
Wake lock 'Charger_Monitor'

Hum i rebooted and left it overnight here is the log. After which i used it for 30 min and it same wake lock increased to 3 min. (not plugged in)

It might be a false positive as BBS counts wakelock explicitly. Any way any reference to this wakelock would be helpful. i would keep an eye on next cycle.
[BetterBatteryStats] angwar90:
Hey here is my file from last night.
[BetterBatteryStats] TNSMANI:
.

From your log: " com.google.android.gms (): Wakeups: 135 (14.7 / h)

Alarms: 0, Intent: com.google.android.gms/.lockbox.LockboxAlarmReceiver"

This may be your problem. This seems to be related to Device Administrator functions like anti-theft etc. Limit it with Amplify and see whether there are any issues and whether you have better battery.
[BetterBatteryStats] angwar90:
Thanks I will try it

Edit: I tried it a bit more than an hour and I still lost 5%. I will make another dumpfile tonight I guess.
[BetterBatteryStats] TNSMANI:
You seem to have lost only 0.2% per hour during sleep. That is very good. Charger_Monitor was also under control during sleep. If I were you, I wouldn't worry too much about what happens when the screen is on unless there is huge battery loss.
[BetterBatteryStats] Perseus:
Weird, I must admit to see

charger_monitor (CyanogenMod System):

Do me a Favor. Plugin, reboot, disconnect when you are on home screen. If that doesn't help, replace your launcher with something else.
[BetterBatteryStats] demonwind:
Every two weeks or so my phone will randomly screw up and eat through battery life, I try clearing memory but the only way to fix it is to reboot my phone. Anyone know what could be causing it? I check BBS but it's the same as always yet most days my phone doesn't drain battery life this fast.

Phone is Galaxy S2 skyrocket.
[BetterBatteryStats] chamonix:
Kik messenger and the fact that you have GPS turned on are the main causes from this run
[BetterBatteryStats] chamonix:
Without causing awakes (and by doing so drain) this is not possible. On the other hand the other I am working on a similar feature showing what happened in the latest sleep phase when you turn your phone on. As the processing would happen when you turn the phone on it is a way to avoid the overhead but still provide the kind of info you are requesting.

Another idea would be a monitor allowing to take samples every 30 minutes. I will implement it but can not promise to release it before I have tested it and convinced myself that the overhead is not too high
[BetterBatteryStats] chamonix:
Wakelocks maybe, wakeups using alams for sure and that's the reason I am really conservative about such ideas
[BetterBatteryStats] chamonix:
This in an impressing wakelock. As the count is pretty high (120) it doesn't look at that app being stuck but rather doing over and over again. Is there anything in that player indexing your mp3s that may cause this?

In any case this is either a buggy app or really poor design. If I were you I would look for an alternative player as this kind of overhead is inacceptable
[BetterBatteryStats] chamonix:
Without a log hard to say. If the problem happens on a regular basis you should check for recurring events like alarms with snooze, sceduled backups that may hang etc.

Anyway, without dumpfile no way to tell
[BetterBatteryStats] chamonix:
I have been busy on another project launching soon but will be back working on the next release starting this week.
[BetterBatteryStats] richua:
Interesting you say this as GPS was off the whole time. Does this mean some app is trying to poll for GPS? I can't think of any that would do that.

Looking forward to future releases, good stuff so far.
[BetterBatteryStats] Yarox:
It's the default MIUI player. The only thing I can think of is that it scans for music files (sound tracks are specified as files larger than 800K) over and over again. Regardless I found a simplistic relatively unknown player that suits me just fine. Thanks for your in depth analysis.
[BetterBatteryStats] Birba:
Hi all

On my Galaxy Nexus GSM i'm running AOKPb21. No mather what kernel i run i have high wake lock for "Checkin Service" by Google Services.

In 1h45min uptime you can see on the attachement that "Checkin Service" caused a really high wakelock:

1h18m15s (4695s)

What is Checkin Service for and ho do I find out why that happens?

Thanks
[BetterBatteryStats] Amaj7:
Hi!

My screen in time is more than 2 times lower than total awake time. What is the cause?

Here's the graph

Still I can't understand what do the stats shown in BBS mean. (( Here are several questions.

1.	What is "count"? Does this value show how many times the process caused wakelock? Are count values in thousands possible?

Example

"PowerManagerService" (): 46 m 47 s (2807 s) Cnt:(c/wc/ec)6864/0/0 2,8%

Does this string mean that process "PowerManagerService" has woken up my phone from deep sleep 6864 times since last charge (27 hours)? Guess it's too much. What do c/wc/ec count values mean?

2.	If I select "History" and then select "View Serie" I see a list of.... what? Wakelocks? Then how can this be that number of entries in this table is several times less than number of "counts" in the very same period caused by a single process "PowerManagerService"? How to read it? I can understand what "bat", "wifi", "gps" and "bt" columns mean. But what do "pow", "scr", "WL", "call" and "scan" columns mean?

3.	If I summarize partial and kernel wakelock's length I get a value much bigger than awake time minus screen on time. How can this be if as far as I understand wakelocks can only occur in deep sleep and not when the screen is on?

4.	What are “Alarms” for? What do this section mean?

5.	What is a normal statistic for minimal battery drain? I mean those who’s batteries discharge for 2-3% per night? How many wakelocks per night is normal? 1, 10, 100, 1000?

6.	What are “raw kernel wakelocks” for? How can they help?

7.	Why do statistics graphs in BBS and builtin gingerbread battery stats differ? Which one is more correct?

Any help will be greatly appreciated!
[BetterBatteryStats] chamonix:
Interesting and it's not the first time I hear that. My statement was based on:

GpsLocationProvider (Android System): 1 m 30 s (90 s) Count:18 0.2%

as opposed to NetworkLocationProvider or PassiveLocationProvider. Obviously the provider would be able to cause a wakelock even if the GPS device is not accessible.

I will be reading sources to see if I can find a reason for that: http://grepcode.com/search/?query=GpsLocationProvider

Anyway if GPS was off then the cause can be any app requesting fine location, my bets are on google maps
[BetterBatteryStats] steve austin:
no red percentage bar showing up

i have been searching for an app like this since spare parts fc's every time i try to pull up usage stats so thank you for this god send. however, i am experiencing a problem. before i get blasted, i used search, read the first 20 pages, skimmed through the thread AND even did a search on the word "blue". So if i missed the answer to this - i tried. Here it goes...

i have a rooted t-mo sensation. All the descriptions and stats are under the processes running, but all the bars are solid blue. There is no red indicator (like i see in all the pics) to show the actual percentage (graphically) being used. How can i get this to start working or is there i bug with my sensation? That feature being activated would be extremely helpful. Thanks in advance and thanks for this great app!

(btw, i installed the 1.5.1.0)

---------- Post added at 03:21 PM ---------- Previous post was at 03:13 PM ----------

do you know of any data counters/monitors that will list the app pulling in the data and graph/show the time it does it? thanks in advance.

NEVER MIND on my first question. I should have used "red" in the search - not blue. thanks.

http://xdaforums.com/showpost.php?p=17878288&postcount=1186
[BetterBatteryStats] ManUtd07:
I tried pulling my dump file again as last time someone mentioned it seeming too small to have gotten a full read. In order to get my file since I'm on MIUI, I turned off battery services, then turned it back on and charged during the night. While still plugged into the charger I pulled the dump file. Is that the correct way to pull it? Also, once I took it off the charger I was no longer able to get any stats but one of the things I noticed when I could still read it was Beautiful Widgets was at the top of my Partial Wake Locks. I found that interesting since I don't have a Widget in use besides Pure Calendar. Any thoughts on that and what else could be keeping it awake? TIA.
[BetterBatteryStats] jazzboyrules:
I also see this wakelock ( show keyguard ) when I am running a music app with the screen off. I have set my podcast player BeyondPod and PowerAMP to display their respective control screens when I turn the screen on while something is playing on one of these apps.

Those should be causing the show keyguard wakelock, right?
[BetterBatteryStats] Karpfenhai:
No, unfortunately i dont, maybe the apps are not reporting back how many data they consumed, or they all are using the same API for the modem and thats why its not measurable, if it would be possible, im pretty sure someone would have developed it.

i'm sorry!
[BetterBatteryStats] xuxuzao:
I am having a huge friendcastr sync wakelock and i dont know how to stop it

i stopped all syncs on friendcaster's app and it is still causing wakelocks

any tips?

tks guys!
[BetterBatteryStats] suku_patel_22:
What sync method do you use in Friendcaster? I use C2DM and don't have any wake locks

Swyped from my Desire S
[BetterBatteryStats] dingbat01:
What can I do about my wakelocks?

Hi.

I've been keeping an eye on my battery usage with BetterBatteryStats. The ratio of Awake/Screen On time is consistently in the region of 2:1.

Partial Wakelocks:

"sync" (Gmail) leads the pack, followed by GTALK_ASYNC_CONN and ActivityManagerLaunch

Kernel Wakelocks:

vbus_present has the highest figure followed by "svnet" and "svnet_dormancy"

What should I do to address these?
[BetterBatteryStats] suku_patel_22:
Reduce the frequency for google sync settings...

Swyped from my Desire S