yashsingh1/xdaforums huggingface dataset:
[BetterBatteryStats] Raymond Ebertt:
First time here and have only been using the Better Battery stats for a couple of days. I have been worried about my overnight drain with the phone awaking throughout the night. I have done the followings;

1. Removed all alarm clocks

2. Turned off wifi, data, sync, gps

3. Left the phone and checked in the morning (about 6 hours) and I'm getting 8 to 10% drain.

I've posted some screen shots hoping someone has an idea of my problem or even if I do have a problem

Thanks in advance
[BetterBatteryStats] kami2k:
please upload the dump of bbs
[BetterBatteryStats] chamonix:
Yes, it writes the reference 'since unplugged' and that contains 'dumpsys alarm' which requires root
[BetterBatteryStats] negrobembon:
Does anyone know whats the mipi_link service? And also the powermanagerservice?

Im trying to find culprits, but i dont know what most kernel wakelocks mean

Sent from my Galaxy Nexus
[BetterBatteryStats] ggclanlord:
Any insight on what might be causing this alarms?

Have removed Google Talk (talk.apk). But still the same number of alarms, before and after.

Log
[BetterBatteryStats] chamonix:
I believe the reason for the problem in the references is that their structure changed in 1.9 as network was added. Due to that change 'old' reference files are present but can not be read, potentially leading to the behavior some you you have had. I will try to reproduce by reinstalling 1.8 and then moving to 1.9 but I believe I will have to delete all references upon install, avoiding users to have to reboot before the references are all good again.
[BetterBatteryStats] chamonix:
So basically you are saying that 1.9 RC2 fixes the inaccessible service by adding that perm that shouldn't be required?

I just want to be sure because if it's the case I will search the Android sources for the explanation
[BetterBatteryStats] chamonix:
The screenshots are not enough. Please post a dumpfile
[BetterBatteryStats] bradwdx:
Yes, correct. Running side by side, where 1.8.1.0 (market) fails, 1.9 RC2 (xda) works without issue.
[BetterBatteryStats] chamonix:
Awesome!
[BetterBatteryStats] Karpfenhai:
Deleting the reference files (data/data/com.asksven.../files..) does not help (cached somewhere?) But finally a reboot did.

Sad b/c it destroyed my long term test after 912 hours without reboot.. :(

Rc2 runs without issues, i like the larger graphs.

Regards.

Tapatalked from my Samsung GT9100
[BetterBatteryStats] nocturnoz:
pastebinDOTcom/pVSGMxcx

Its already in my post. :)

Also a screenshot
[BetterBatteryStats] chamonix:
My bad, I forgot that I did split the 2x1 widget in upper and lower half :D
[BetterBatteryStats] chamonix:
yes they are cached..... in memory :)

RC3 deletes them and reloads (empty ones) so that should avoid the reboot..... may be tricky to test though
[BetterBatteryStats] chamonix:
Sorry but that dumpfile does not say the same as you are saying (12 hours since unplugged). But anyway I can tell you from that dump that the winner are:

- kernel wakelock deleted_Wakelock, probably caused by your wifi driver being loaded/unloaded every time your phone wakes up: disable wifi when you are not using it

- greenpower is causing quite some awakes (every 3.5 mintes, that's insane). Get rid of it

- facebook is known to be heavy in battery
[BetterBatteryStats] chamonix:
As you said it should be like pwl: https://github.com/asksven/BetterBatteryStats/issues/190

As I said when releasing I couldn't test that so please send me a logcat after having refreshed the screen with the KWLs where eventX-YYYY appears.

How it is supposed to work in a nutshell:

- before going through the list of processes I load a list of the running tasks (it's like doing a ps aux)

- while looping though the processes I look for any 'eventX-XXXX' pattern and try to locate the number after the '-', fetch that as pid from the tasks and retrieve the package name

All those actions are logged so we should easily find out where it fails with a logcat (all this happens in the log-tag "BatteryStatsProxy" so you can grep on that to reduce the logcat if you want to try looking for what I described.

https://github.com/asksven/BetterBatteryStats/issues/191
[BetterBatteryStats] chamonix:
As you said yourself:

Since 5 h 41 m 49 s
Deep Sleep (): 5 h 36 m 55 s (20215 s) Ratio: 98,5%
Awake (): 4 m 53 s (293 s) Ratio: 1,4%
Screen On (): 3 m 30 s (210 s) Ratio: 1,0%

There is nothing wrong here as your phone does nothing. If you feel that behavior (lab) is draining too much battery my question would be: do you use your phone often like that.

If yes I have a solution: turn it off, it will have the same non existent features but drain less.

No seriously: if your battery drains itself if may be faulty
[BetterBatteryStats] chamonix:
mipi_link is AFAIK the interface to the camera, powermanagerservice: click on the icon on the right and you can read the full description
[BetterBatteryStats] chamonix:
Avoid copying the dumps into the posts please.

GSF is not gtalk but the google service framework used for cloud to device messaging, payment etc.

On the other hand I am wondering:

Awake (): 2 h 54 m 19 s (10459 s) Ratio: 29.2%
Screen On (): 2 h 2 m 7 s (7327 s) Ratio: 20.5%
Phone On (): 7 m 26 s (446 s) Ratio: 1.2%
=========
Wakelocks
=========
AudioOut_1 (1013): 27 m 3 s (1623 s) Count:561 4.5%

That reading shows clearly that all the awake time was caused by you using the phone so it basically contains no information. Please read the first posts to see how to prepare and perform a representative reading
[BetterBatteryStats] chamonix:
Pardon me of quoting myself ;)

I have looked closer at the code and the problem mentioned here (the kernel wakelocks do not take the preference to express times as percent of X) was introduced while moving to parsing the kernel wakelocks from /proc instead of relying on the (incomplete) Android API.

This is no exuse for this non-orthogonal behavior but I have decided to leave that bug out of the release candidates as it would require a refactoring of the whole kernel wakelock code with the risk of breaking something else. I just don't want to risk the great features included in 1.9 and I hope you agree on that.
[BetterBatteryStats] chamonix:
RC3 is ready based on the feedback I got till now but I'm really dying to get more feedback on:

- network stats

- eventX-YYYY (and logcat if it doesn't work)

- the watchdog feature (functionally and about the whole idea)

I will at least wait till I get more info on eventX-YYYY (sorry but I can't reproduce as I don't have those) and add a fix to that to RC3.

I the meantime be not worried, I do more support and work on ALTitude in parallel so it's not like I am out of work ;)
[BetterBatteryStats] yhrn:
Ok, here's the filtered logcat. Does it contain anything useful? Otherwise I could post a larger part of the logcat.
[BetterBatteryStats] chamonix:
Unfortunately not. What we are looking after are those (TAG = BatteryStatsProxy)

Log.d(TAG, "Process name = " + ent.getKey());
...
Log.d(TAG, "UserTime = " + userTime);
Log.d(TAG, "SystemTime = " + systemTime);
Log.d(TAG, "Starts = " + starts);
...
Log.d(TAG, "Pattern 'event' found in " + ent.getKey());
...
Log.d(TAG, "Resolving proc name for 'event' " + proc);
or
Log.e(TAG, "Cound not split process name " + ent.getKey());
...
Log.d(TAG, "Pattern 'event' resolved to " + details);
or
Log.e(TAG, "Cound not find any process for 'event' process id " + proc);
...
Log.d(TAG, "Pattern 'event' resolved to " + details);

I noticed your logcat only contains "Info" entries. Are you maybe filtering?
[BetterBatteryStats] nocturnoz:
Thanks! Then I'm either paranoid or my battery is eating itself. :)

But whats wrong with my connection?

No Data Connection (): 5 h 41 m 49 s (20509 s) Ratio: 100,0%

No or Unknown Signal (): 5 h 41 m 49 s (20509 s) Ratio: 100,0%
[BetterBatteryStats] Karpfenhai:
Hey Sven, the Android system server is still masqueraded as event-xxxx.

The network stats are really awesome!

Watchdog seems to work perfect too but i need further tests since i just activated this feature :)

CPU stats are great too, especially during screen of periods, quite helpful!

More tests to be done.

Tapatalked from my Samsung GT9100
[BetterBatteryStats] s2dh:
the dump was after i recharged.

will do what you suggested.

thanks
[BetterBatteryStats] stuart0001:
Something that would also be useful is a record of screen brightness level states.
[BetterBatteryStats] yhrn:
Hmm, can't find anything like that i the logcat I have. Do I need to do anything special (like enable logging on a more detailed level somewhere) to get those logs?

I've taken a new logcat and still the same. Can't even find the string "Process name =" in the entire file.

EDIT: Just saw your last question and the answer is: no, not on purpose at least. I don't have any filter expression in the logcat command I'm executing. Maybe the ROM/kernel I use is tweaking this. Can I control the log level being output to the buffer logcat is accessing somehow?
[BetterBatteryStats] stuart0001:
Would it be possible to include number of cores active in the CPU stats somehow
[BetterBatteryStats] chamonix:
Those are experimental features, for some they work for some not (for me they do and it's pretty useful to have info about the sigla quality.

Starting from 1.9 you will have the possibility to turn those values of in preferences
[BetterBatteryStats] chamonix:
https://github.com/asksven/BetterBatteryStats/issues/192
[BetterBatteryStats] chamonix:
Weird. This is what I get from by PC when doing 'adb logcat | grep "Proxy":

D/BatteryStatsProxy(14266): Process name = com.google.android.stardroid
D/BatteryStatsProxy(14266): UserTime = 12300
D/BatteryStatsProxy(14266): SystemTime = 1690
D/BatteryStatsProxy(14266): Starts = 1

Unfortunately I never go into any detection as eventX-YYYY is not appearing here.

@Karpfehai: maybe you could have a look at your logcat
[BetterBatteryStats] chamonix:
https://github.com/asksven/BetterBatteryStats/issues/193

Even if I feel that is at the limit of what BBS addresses (as it handles awake and not sleep) I added the feature request.
[BetterBatteryStats] yhrn:
Weird indeed! I looked in the logcats and I can see a lot of debug level records but none from BatteryStatsProxy so the edit I made my previous post about it having to do something with my ROM/Kernel does not seem very likely.

I get the logcat using terminal emulator directly on my phone. Would that make a difference? At the moment I don't have access to a PC with adb installed.
[BetterBatteryStats] Karpfenhai:
Sure i will, but i need to re enable logging first ..

And reboot.. :(

Done, will post one soon..

Edit: 1961 is my Android system server and here is my logcat (system + events

Update, it seems, the screen off reference has a problem, it does not show anything (no ref found) but, it sets a custom ref, means under custom ref i can see values for the timeline my screen was off.

Maybe and simple issue with the namespace?

Or its a wrong array called in the code, seems to be something easy to fix, good luck!

Tapatalked from my Samsung GT9100
[BetterBatteryStats] bradld:
any ideas/advice on the wakelocks below?
[BetterBatteryStats] negrobembon:
Mipi-link is keeping my phone awake for some reason, do you have any idea why?

Sent from my Galaxy Nexus
[BetterBatteryStats] #illidan:
Well the stupid thing is back even with both of those apps disabled. It was fine for a day & then it just came back. Waited for 2 days after that just to make sure it was back. Know you are working on another release of bbs so take your time on this.
[BetterBatteryStats] TheStigger1:
Battery drain

Who can help me with my battery drain?

My phone spent 40% of battery for the night! ;(

There is my BBS dump:
[BetterBatteryStats] Rob2222:
Its a bug in google chrome that prevents your phone from standby (suspend-backoff wakelock).

Close Chrome via taskmanager after use or uninstall it until this bug is fixed.

BR

Robert
[BetterBatteryStats] chamonix:
What is this: com.zomut.watchdoglite.Watchdog
[BetterBatteryStats] chamonix:
Please post a dumpfile, screenshots do not deliver all the info needed for an analysis
[BetterBatteryStats] chamonix:
It depends on the tool used for reading. I don't know of any tools limiting the writing to the buffer (except some kernels disabling it) See but most tools like the logcat console in eclipse have filters on the level. 'adb logcat' shows all levels at my end
[BetterBatteryStats] Raymond Ebertt:
Need some help

I don't understand the drain I am getting at night with everything turned off such as wifi, gps, data, and sync. My phone seems to be away most of the night. I have all alarm clocks removed.

Anyone have any ideas?
[BetterBatteryStats] bradwdx:
how can deep sleep and kwl be greater than since unplugged when i think I've set every thing to ´since unplugged'?

this is with rc2

edit: i should probably note i'm using the androidsu 3.2 rc1 and it doesn't appear to remember that i've allowed bbs to be remembered to give root and prompts frequently for me to allow root. too many changes at once, sorry.
[BetterBatteryStats] ouzowtf:
I wondered about that too :P
[BetterBatteryStats] Rob2222:
@RC2 Test...

Sometimes "Since screen off" shows 0s and "no custom reference set", but I can't say why/how to reproduce.

BR

Rob
[BetterBatteryStats] yhrn:
Since I was using plain logcat from the phone terminal emulator and didn't add any filter expressions to the command I don't think my reading was filtered. Especially since I could see a lot of other debug level logs from other sources. Are you sure the BBS version published in this thread still has all the debug logging statements enabled?
[BetterBatteryStats] itm:
I'm trying to work out why my phone is losing 5% of its charge each hour while sitting mostly idle. This line is at the top of my log. Is it possible tell exactly what type of sync it is referring to - e.g. is it the "Sync Internet" option?

*sync*_com.android.browser_Account {name=EM, type=com.google} (Google Services): 1 h 35 m 31 s (5731 s) Count:21 39.4%
[BetterBatteryStats] xelra:
Go to your sync settings and check if there is an entry with an exclamation mark.

If there isn't, you need to do a proper reading and a proper dumpfile.
[BetterBatteryStats] itm:
No, there are no exclamation marks in the Sync settings. Attached is the full dump file.
[BetterBatteryStats] Tungstwenty:
Hi,

Here are 2 dump files I took this morning after 7.5 hours idle, only a few seconds apart.

Why 2 dumps? Because they show different stats and I'd like your opinion on their usefulness, more than a dump analysis itself. I left the wifi turned on the whole time on purpose.

The difference is that in one of the dumps you have the usual stuff for kernel locks, but on the other one the stats do not suffer from overlapped counting.

I implemented some changes in the kernel wakelock code to be able to count not only with the existing logic, but also keep a second set of counters where at each moment only one of the WLs is being accounted for the fact that the CPU is awake.

Whenever the "culprit" WL is unlocked or expires, the next best candidate (only 1) is selected and starts its timer, counts, expiration, etc:

- if there are active, non-expiring WLs, the one that was activated first will be the next culprit

- if all of them are auto-expiring, the one with that will expire the latest will be selected

Can you notice the big differences in the kernel wakelocks section?

E.g. in the full dump we have the 4 eventX-7048 entries with ~210s each and a big count, but in the second dump we see that all that time occurred while the CPU was already awake due to something else. The only exception was a <0s period of one of those 4, which was even the cause of the power coming up (wc=1).

"gps-lock" is another example - 149s active, but all that time was when the device was already awake due to something else.

"wlan_wake" woke up the CPU 244 times in both measurements (wc should always match), but the "c" value is way different. There wasn't that big of an impact on having it lock/unlock because the device was already awake. c=300 means that it was assigned as the power culprit that many times - some of them because it was the single WL aquired and that indeed woke up the CPU, with all its overhead (244x), while the other 56 times it was due to other WLs unlocking or expiring, but where no power transition occured.

BTW, the set of stats that show up on /proc/wakelocks is controlled by a dynamic parameter, that's what those seconds between the stats were for.

Well, I'd appreciate your feedback on how useful this might be for this topic, knowing beforehand that it will always depend on the kernel providing this or not.

Even if not that useful, it's implemented already (on Siyah for S2) and the challenge was fun :)
[BetterBatteryStats] CRXed:
@Drapper, attach the logs , ffs!!!
[BetterBatteryStats] chamonix:
What you describe looks like either a bootloop or userland restarts to me. In that case this is not the right place to seek for help
[BetterBatteryStats] xweveo:
Hello, here is my dump file. Any advice to reduce wakelocks?

Thanks in advance
[BetterBatteryStats] chamonix:
Yes, the extract I posted yesterday was taken with the xda edition
[BetterBatteryStats] Karpfenhai:
Are you sure the problem is not caused by an active app?

Could you check the process section of bbs for that?

Furthermore please update to the most recent version or use the rc2 from second post since it contains some new helpful features!

Tapatalked from my Samsung GT9100
[BetterBatteryStats] yhrn:
To me this sounds *very* useful and the KW section looks much less noisy. Not an expert though so I don't want to make any comments on whether the logic is correct or flawed in some way.

As for having this feature in BBS I guess it's up to Chamonix to decide if he wants to introduce features that will only work for some users (of course, some things already require root so it's not a completely new concept).

On the other hand, I think a lot of people using BBS are using custom kernels. If the required change to the kernel is easy enough to implement I would expect almost every kernel developer on XDA to include it eventually as BBS is the de facto standard app for battery drain analysis in these hoods.
[BetterBatteryStats] chamonix:
This is driving me crazy, I am not able to reproduce. I have checked all the mappings and all the functions.... nothing... you are not on froyo are you? ;)

could you please test the following:

1. kill bbs

2. delete all files from /data/data/com.asksven.betterbatterystats/files

3. start bbs

4. turn screen off, then on again

5. check what file was written (should be 'since_screen_off')

Are you opening BBS directly or from a widget? is "since screen off" the one that is selected y default or do you switch from another stat type?
[BetterBatteryStats] Tungstwenty:
Actually, this is completely transparent to BBS; no changes are required at all.

It's the mechanism that's providing the KWL stats that changes, inside the kernel. BBS still loads /proc/wakelocks as if nothing happened.

But, although this doesn't impact BBS, it *does* impact the analysis people do on dumps. If you look at the 2 dumps for essentially the same history, they show very different data on that part and hence can influence an analysis that is done.

---------- Post added at 10:31 PM ---------- Previous post was at 10:20 PM ----------

I'm also having problems with the Screen Off reference.

I killed bbs, removed the files (folder has _xdaedition), started (no widget), set screen off as the default, turn screen off and on.

No files are created on that dir; the app displays "custom reference not set".

I think I remember previously not seing this warning, but the values were the same as since unplugged (?). Also, the file was there before I deleted it.
[BetterBatteryStats] chamonix:
Have you enabled the watchdog? The error message may be the wrong one (I'll have to check) but the file not being created seems to mean that the screen off handler does not run and this corresponds to the pref "Saves a reference when screen goes off" not being active
[BetterBatteryStats] Tungstwenty:
Doh! :o

I didn't know about the watchdog. It's now working as it should.
[BetterBatteryStats] yhrn:
Got it. In that case it would be nice if there was some way for applications (like BBS :)) to determine if this feature is enabled. If this is can be done then a possible new feature for BBS would be to include this info in the KWL view/dump file section to avoid some confusion when analyzing.
[BetterBatteryStats] Karpfenhai:
File is there, seems killing bbs after enabling the watchdog did the trick!

But not all stats are refreshed (see 2nd screenshot)

I jump from widget to other / since charged, no issue with that.

Opening bbs to early after turning screen back on causes stuck message, i guess the file from 1st screenshot is written /accessed to slow?

1st:

2nd Alarmmanager:

Not froyo, I'm running windows XP:

:D:p:cool:

Tapatalked from my Samsung GT9100
[BetterBatteryStats] #illidan:
Its an app which tells me if other apps are excessively using the processor. I can set percentage limits for system & user apps separately. When they cross those limits & if those app are in the background then it alerts me. Should I disable that as well?

Edit: typo
[BetterBatteryStats] s2dh:
Thanks, I have removed Greenpower and disabled wi-fi when not used and I can already see a great difference.
[BetterBatteryStats] Jeremy:
Sorry but is anyone able to help with my log above?
[BetterBatteryStats] californicated:
Could someone please take a short look at my BBS log? Battery drain in idle sucks :crying: Do I have to freeze google maps? Thanks ;)
[BetterBatteryStats] Geo2160:
I've been having some weird deep sleep issues starting from last week. People have advised me to report my issues here and to change the modem version as a first solution. Can anybody look over my logs and tell me what's going on?
[BetterBatteryStats] bradld:
dumpfile attached
[BetterBatteryStats] chamonix:
I may have discovered something about the problem some of you guys have with inconsistent deep sleep times in 'since unplugged'. I have installed cm9 today and have had that problem since then. After a little research it turns out the 'since unplugged' reference is not written. I assume that is the same reason why some of you have empty 'since screen off'.

How many of you (having that problem) use superuser and how many supersu?
[BetterBatteryStats] Karpfenhai:
SuperSU right now but Superuser installed too, i think i got this on both apps.
[BetterBatteryStats] chamonix:
Then my theory is dead ;(

But anyway I will try to thread all actions related to 'su' and see if it changes something. The other possibility would be that BBS gets killed by a too agressive management algorithm, causing the activity (in that case broadcast handler) to stop prematurely. What I noticed in my current setup is that even after deleting all ref files, turning the screen off/on, plugging/unplugging and creating a custom ref is that only the custom ref file got created.

Edit: I have found a possible cause: the broadcast handler being terminated by ActivityManager (maybe different ROMs have different settings). That would explain why some of you guys have the problem ans some not: that is great news.

I don't want to fill the thread with all the details, the one who are interested can follow the progress in the issue: https://github.com/asksven/BetterBatteryStats/issues/194

Next RC is coming closer :)
[BetterBatteryStats] chamonix:
Well it's a shot in the dark but that app is waking up your phone quite frequently so it has high costs anyway. I saw it in the list and thought it may be yet another app accessing the network status as JD/greenpower do.
[BetterBatteryStats] Jeremy:
Anyone?
[BetterBatteryStats] Jeremy:
Sorry was supposed to quote this