yashsingh1/xdaforums huggingface dataset:
[BetterBatteryStats] jago25_98:
We need to trace wakelocks!

We really need to be able to trace a wakelock back to the process that started it!

Even if this was only possible with a certain ROM, or even only if emulated that would be enough to really start building a proper reference database or wiki
[BetterBatteryStats] Rob2222:
Can somebody give me a hint what ec at the kernel wakelock means? c is count, wc is wake count, right? So just the amount of how often a wake lock got aquired. Is the e standing for expiring? If yes, what does that mean?

Maybe a short hint what a deleted wakelock means would be very helpful, too.

Best Regards

Robert
[BetterBatteryStats] d3l1:
Thanks for your input. I'm in deed using the newest siyah with the feature turned off. This 'main' value started appearing with the newest version, I've never seen it before. Maybe it's really linked to the screen on state. I'll keep an eye on it.

Sent from here using Tapatalk
[BetterBatteryStats] drapper:
Attached are the files a few mins after the reboot and almost 10 screen wakeup loops

Thanks for the assistance
[BetterBatteryStats] nobnut:
Small ones are more juicy!!

Seriously, what DPI setting are you using? I use 200 and this reduces the size of my bars from the default 240DPI setting.
[BetterBatteryStats] peterbonge:
Where can I see this? I'm using the app System Panel and it reports the following data for "Exact DPI":

234.46153w x 236.27907h

But I don't know if this is correct.

Maybe you can add an option to change the height of the line?
[BetterBatteryStats] nobnut:
Chamonix will be able to adjust the line height, the problem is that we all use different devices with different set ups. It makes things more difficult.

To find out the DPI you have, view the contents of the file system/build.prop by using a root permission file explorer and clicking on the file. DO NOT EDIT ANY VALUES UNLESS YOU KNOW WHAT YOU ARE DOING.

Inside that file, scroll down until you see the line

ro.sf.lcd_density=xxx

The 'xxx' will probably show 240. I have changed mine to 200 as this makes everything on the screen smaller and enables me to fit more on the screen. But like I said... everything on the screen is now smaller, including those lines ;) I'm happy with it this way.

Screenshot...
[BetterBatteryStats] peterbonge:
Thanks for the info!

But you don't need root to view this file. I've just opened the file with ES File Explorer and it really shows 240.
[BetterBatteryStats] nobnut:
I use Root Explorer to view file contents, so I was just covering all the bases... you certainly need root to edit it ;)
[BetterBatteryStats] chamonix:
it

here you go, it is not forgotten about:

https://github.com/asksven/BetterBatteryStats/issues/21
[BetterBatteryStats] LondonGemini:
I uninstalled the free version and the version that was installed on Litening_Rom_v2. 1 (which I had to do with titanium) but I still couldn't install your version from the market
[BetterBatteryStats] chamonix:
BetterBatteryStats having been added to Litening ROM without my consent is a paint... first it's idiotic to add an app under development to a r

ROM as it just wastes memory, secondly I personally wouldn't trust a ROM containing apps signed with debug keys.....

Devs didn't show any interest talking to me about that neither....
[BetterBatteryStats] nobnut:
I've just left him a little post to contemplate in his thread.
[BetterBatteryStats] chamonix:
lol, sent a PM a while ago....

anyone here willing to write a CWM script to delete it from litening so that we can offer a proper upgrade path to litening users?
[BetterBatteryStats] LandUzu:
....

@ "developer" of litening...........cant believe the audacity of some people.....thats just downright takin the pish!! Cheeky Barsteward!!:mad:
[BetterBatteryStats] LondonGemini:
Indeed. I thought that you were aware that it was included with that rom.

Well I hope you don't get put off. your application is really useful and your work is appreciated.
[BetterBatteryStats] nobnut:
PM sent.

Sent from my Motorola StarTac using Voodoo
[BetterBatteryStats] chamonix:
The problem is Litening users can't buy from market because the app is signed with debug keys in that rom. That's why I want to find a way for them to get rid of the old package and have the freedom to either install the free xda version or buy from the market. Either way they are stuck because a dev did not think or didn't know. I'd been happy to explain that but no one asked me
[BetterBatteryStats] arch66:
Hi Chamonix,

I'm a Lite'ning rom v6.1 user, and this morning I read all the arguing about your app in the Lite'ning thread.

After only reading that thread, my view was that "why should Chamonix care? Its a free app, and LitePro is not taking credit for it."

But after reading this thread (the last 2 pages) and your comments on the debugs keys, I think you have a right to raise your concerns.

And i think most Lite'ning rom users would agree with you, its just that the comments made on that thread did not convey you concerns.

Maybe its appropriate for you to personally comment on Lite'ning rom's thread.

(Personally I prefer to install my own apps, rather than let them be bundled in.)
[BetterBatteryStats] LondonGemini:
I see. I had a job of uninstalling the version supplied with the rom. I had to use titanium but even after that, i was still unable to buy the proper version from the market place as it failed to install.

Hopefully this will all get sorted out soon
[BetterBatteryStats] Plopz:
Just bought a copy on the market, fantastic app! :D

I'm having an issue though, maybe it's just me. Sometimes, when I set the custom reference and leave the app. I will come back later and change it to custom reference and it will tell me that there is not a custom reference set. Am I the only one with this issue?

Does it have to do with me using the back button or using the home key to exit bbs?
[BetterBatteryStats] chamonix:
Thank you for reporting that, it looks like a bug to me.

I will check if there is enough logging enables and give you some info about what to look at in logcat.

Have you noticed the error under certain conditions like eg plugging the phone to usb or charger between setting the ref and the error or is it random?
[BetterBatteryStats] chamonix:
Thank you for the feedback. I will read the thread and see if there is a point in laying down my views there. I'm not interested in a flame/blame war but care about users and about etiquette. If it was not perceived that way I will try to make a point in explaining my point of view. Interesting is I have only written one post in that thread, politely asking a dev to contact me. That didn't happen btw
[BetterBatteryStats] chamonix:
Did you freeze it or uninstall/delete it. Freezing won't work I think because the app doesn't get deleted
[BetterBatteryStats] xelra:
Wouldn't it make more sense to have a reference "While screen off" instead of "since screen off"?

I mean, when I look at the statistics I'm not really interested in what happened after I unlocked the phone. I'm only interested in what happened while the screen was off.

So shouldn't it be fozen?

Maybe it's even possible to accumulate multiple "while screen off"s?
[BetterBatteryStats] steve austin:
First time ever great stats!

On an awesome and great note, after reviewing BBS more closely it appeared that there were two instances of facebook being logged. i reinstalled my ROM and this time I had the option to not instal the Sense version Facebook. I am happy to report that for the first time e-v-e-r I have recorded a day and a half of use. Though it was moderate use it was more than I thought was possible with my poor track record. I still have a billion wakelocks, but I sill managed a freaking day and a half. Thanks for your app and quick responses to help everyone here. If you can help me eliminate the non responding errors I am getting I will definitely buy the finished version of the service to support you.
[BetterBatteryStats] Tungstwenty:
Count - number of times the lock was activated

Wake Count - number of times this lock was the first one activated after the device went to deep sleep (so this was probably the cause for a transition from sleep to wake up)

Expire Count - number of times the lock reached its timeout without being deactivated, i.e., automatically unlocked since it was activated with a certain time limit

Deleted wakelocks apply to parts of the kernel that initialize and destroy wakelocks while the system is running, not only on phone startup and shutdown. A good example is the Wifi driver, which is loaded when you activate Wifi (and initializes usually 2 WLs then), then those WLs are locked and unlocked as the driver does its thing, and if you later disconnect Wifi the driver is unloaded and therefore destroys (and unlocks if needed) the WLs. These are no longer tracked by the wakelock mechanism any longer and are therefore reported as "deleted wakelocks" just so you know that something (a group of things) that no longer exists was accountable for X times, X counts, etc.
[BetterBatteryStats] chamonix:
Wow.I see two things in your dumpfile:

- location is holding a wakelock almost the whole time

- kaiten is waking your phone up every 30 seconds

Now the problem is that it hard to say what is symptom and what is cause.

I suggest that you do following:

- turn Wifi off for the next reading

- check your kaiten settings to make sure that the depth of folders that are synced is what you want

- do your self a favor and deinstall/freeze JD

- check your maps caching settings and make sure caching is for wifi only

With these changes I can not assure that the problem will be solved but we should get a clerarer picture
[BetterBatteryStats] chamonix:
I don't understand your remark: are you talking about partial wakelocks or kernel wakelocks? Some of them can be attributed and some can not because they are caused by subscribers. Your remark sounds like without that "feature" there is no way to determine the cause and IMHO that is absolutely not the case...
[BetterBatteryStats] chamonix:
http://elinux.org/Android_Power_Management
[BetterBatteryStats] chamonix:
Weel I couldn't see any sign of userland restart but a healthy log looks not like that. I suggest that you select a clean ROM, wipe/format your device and start from scratch (no restore of any backups).
[BetterBatteryStats] chamonix:
You are right, that would feel more natural and there are feature requests for that. Implementing timeboxes as opposed to open intervals will require quite some redesign though but is definitely on my list
[BetterBatteryStats] jeffreii:
Was anyone able to glean anything from my logs? Sorry if this bump was rude or unnecessary! Thanks
[BetterBatteryStats] Rob2222:
Hello,

I took my time to study and understand that new system and the two logs.

Does that mean in that case, that wlan_wake in that 56 time took over a wake unit and continues to hold it awake? So in that 56 time the wlan_wake wakelock was created while the device was already on caused by another wakelock and that other wakelock was unlocked/expired and wlan_wake took over holding the device wake?

BR

Robert
[BetterBatteryStats] chamonix:
Release 1.9RC4

1.9RC4 is up, check post #2 for the changelog.

This release should fix the problems that were reported about values for partial wakelocks being inconsistent or retrieved for another reference.

@Karpfenhai: the widget auto-refresh off is for you ;)
[BetterBatteryStats] chamonix:
That sounds like good new.

As per the the problem you had, and the impression that the application was stuck: this was solved in RC3 (is wrote a pretty long post about the reasons yesterday, feel free to browse back if you are interested in the reasons.
[BetterBatteryStats] chamonix:
Here we go. As you requested for it I will try to explain what I was looking for.

First log

First I am looking at the overall situation (total time, sleep, awake). I left the lines from the dumpfile that are relevant:

===================
General Information
===================
Since 1 h 38 m 29 s
===========
Other Usage
===========
Deep Sleep (): 1 h 26 m 25 s (5185 s) Ratio: 87.6%
Awake (): 12 m 4 s (724 s) Ratio: 12.3%
Screen On (): 2 m 5 s (125 s) Ratio: 2.1%

That means that your phone, in the first run of 1:38 was asleep 1:26, and that the awake time was 12 minutes, from that 2 minutes you were using the phone.

The potential we are looking at here are 10 minutes out of 98, almost 10%

Now we got the the kernel wakelocks:

"wlan_rx_wake" (): 7 m 5 s (425 s) Cnt:(c/wc/ec)203/0/203 7.2%
"PowerManagerService" (): 5 m 31 s (331 s) Cnt:(c/wc/ec)278/0/0 5.6%

#1 is due to incoming wlan packets waking up your phone

#2 is the sum of the partial wakelocks so we go look there:

*sync*_com.android.contacts_Account {name=EM, type=ro.weednet.contactssync} (ro.weednet.contactssync.Contact-sync): 2 m 55 s (175 s) Count:1 0.3%
AlarmManager (Android System): 1 m 14 s (74 s) Count:326 1.3%
SyncLoopWakeLock (Android System): 52 s (52 s) Count:417 0.9%

#1 is the sync for an account from ro.weednet.contactssync

#2 are wakeups (unfortunately you don't have root so we can't detail that further

#3 is cloud sync

To sum it up:

- you suffer a lot from leaving wifi on all the time. If it was in a controlled environment you could try finding out what packets were waking up the phone, if the env is not controlled you can only change that if you turn wifi off when you don't use it

- you should check the account for weednet: either there is something that you can (partly turn off) of change the data volume by adjusting the frequency (I don't know that app).

The second reading does not show more info, it has the same drainer in form of wifi
[BetterBatteryStats] Tungstwenty:
Exactly. There were 56 situations where the wlan_wake WL was blamed for being responsible for the device being on (even if there were later other WLs coming along as well). But either the device was previously off (and in that case wc increased also), or the others that were being blamed for the awake state have either expired or been explicitly unlocked, and therefore the blame ended up falling on this one since it was the oldest still locked.

Apart from these 56 situations, there could have been many more where it might have been locked and unlocked, but during that interval there was always some other WL already handing the power on, so for those this WL was not made responsible.
[BetterBatteryStats] cdmackay:
I regularly see this too; if it recurs with RC4 I shall try cleaning...

The user reporting is on PA, I see, which is CM9 based, and I'm on CM9, too, which is interesting.
[BetterBatteryStats] jeffreii:
Thank you kindly. I'm glad to see that most of what I had interpreted myself, based on your in-app tutorial, was correct. There's still a major problem here for me to diagnose which I'll try to iterate on. First, regarding your summary:

1) I have left wifi on 100% of the time since I got the SIII two weeks ago. Most of the time I am perfectly ok with my battery usage. I'd say it's around 2% per hour during non-use. The issue here is the 2 or 3 times (every few days) where it spikes up to 10-12% per hour. I think an important fact is that when I do a reboot, the standby consumption drops back down to ~2% and again I'm fine.

2) The weednet thing is an app called Contact-sync. It runs once a day to sync my Facebook contacts since the FB app is currently not doing that properly...I don't think this is an issue since it only ran once and was unfortunately during this log.

So back to the wifi thing. I am ok with the battery drain from wifi. My question is what is causing the jump from ~2%/hour to ~10-12%/hour. Is the answer that I need root to further determine the cause? I'm assuming that whatever is going crazy on my phone (and solved by a reboot) is just using the wifi because it's on...if I turn off wifi it will still go crazy but use 4g instead which would be worse (unless the app causing it is set to only use wifi...). The question and mystery is which app/process is going bonkers?

Thanks again for your time and help - please advise how I should proceed to continue investigating the above.

EDIT: I'm guessing it's safe to say that whatever is draining the battery is going through the wifi...and so perhaps next time it happens I can watch the log on the router and try and see if there's one IP address that stands out with lots of activity? Still curious if there's a way to find that out internally on the device and whether or not root is the answer.
[BetterBatteryStats] AsianXL:
My vbus_present is at 31.2% right now and it's been off the charger for 2 hours. I was charging it on USB. My Partial Wakelocks look fine. Could that be the culprit that is draining my battery life?

I'm losing about 10% per hour right now and I'm barely touching my phone. Everything else is off WiFi, Bluetooth, Screen Auto, Auto Backup/Restore Off, AutoSync Off, HSPA+.
[BetterBatteryStats] Tungstwenty:
You're running the stock kernel (or at least you appear to be, since you're not rooted).

I happened to notice this commit by GM on his kernel, it might shed some light to this subject. This particular change is on the S2, so I'm not sure whether S3 stock suffers from the same effect or not. Or even if this is the particular case you're experiencing.

Still, I hope this is useful.
[BetterBatteryStats] xelra:
Do you know if the unicast patch is siyah exclusive or was this fixed in the cm9 base, too?

This could be huge. It will let me loosen the leash on my private network a bit.
[BetterBatteryStats] Karpfenhai:
Thx, for that, I'm sure i can squeeze at least 20 additional seconds out of my battery b/c of this :D

I'm impressed of the eventx solution so far, especially because you also identify the process behind the AOS!

But... did you merge them together? It feels only the last active is shown in bbs.

Normally they are visible 5-6 times, will study a dump now maybe I'm just to nervous.

Great job! As usual.

Edit: Jepp, the eventx is now appearing only once in the dump, and only the last active is listed, this may distort the result or?

Since in former editions the total count of eventx was always the same, out might not be a problem:

event1-1960" (): 7 m 54 s (474 s) Cnt:(c/wc/ec)1100/51/0 0.3%
"event0-1960" (): 7 m 40 s (460 s) Cnt:(c/wc/ec)843/0/0 0.3%
"event2-1960" (): 7 m 39 s (459 s) Cnt:(c/wc/ec)64213/0/0 0.3%
"event3-1960" (): 7 m 28 s (448 s) Cnt:(c/wc/ec)866/0/0 0.3%
"event7-1960" (): 3 m 56 s (236 s) Cnt:(c/wc/ec)1616/0/1 0.2%
"event4-1960" (): 3 s (3 s) Cnt:(c/wc/ec)20/5/0 0.0%
"event8-1960" (): (0 s) Cnt:(c/wc/ec)69695/0/0 0.0%

Maybe it should more look like:

event4-1964" (system, com.asksven.betterbatterystats_xdaedition,com.anddoes.launcher ) (): 3 s (3 s) Cnt:(c/wc/ec)13/5/0 0.0%

I see that is to confusing..

So, we are on the right track finally but there are still some rocks on our way.

Where are the others from the code section gone?

Thx in advance mate for your hard work!

Tapatalked from my Samsung GT9100
[BetterBatteryStats] asaf-g:
Hi,

After taking a few days to look at BBS logs, I've eliminated everything I could but I do need help with these:

"led_wake_lock" (): 22 m 12 s (1332 s) Cnt:(c/wc/ec)1/0/0 5.1%
"event3-1866" (): 13 m 14 s (794 s) Cnt:(c/wc/ec)1472/0/0 3.0%
"event1-1866" (): 12 m 57 s (777 s) Cnt:(c/wc/ec)1431/1/0 3.0%
"event0-1866" (): 12 m 57 s (777 s) Cnt:(c/wc/ec)1425/0/0 3.0%
"event2-1866" (): 12 m 57 s (777 s) Cnt:(c/wc/ec)1647/0/0 3.0%

1.

led_wake_lock

- which is likely to be caused by BLN in my fluxi kernel, only I have it configured to timeout after 60 sec. Tonight I only had one notification, so I thought I should expect a led_wake_lock of 1 min, not 22 minutes...

2.

event#-pid

- using ps | grep 1866 I see that this is the System_server process. Is this something to be worried about? And is this a kernel/ROM issue?

Thanks.
[BetterBatteryStats] Karpfenhai:
Congrats, you have read the op with care and did your homework, well done but there is no complete dump..

:)

1.its the cost of bln.. Afaik only siyah supports bln w/o wakelock..

2. There is work in progress, these events will be de-masked soon!

If these 12 mins are out of several hours (no dump attached) then its okay, if the period was one hour, then it could be an issue.

Good luck

Tapatalked from my Samsung GT9100
[BetterBatteryStats] asaf-g:
Yeah you're right I have the full dump but didn't think it was relevant. But this was an 8 hour dump so according to what you're saying I'm good.

About the bln - I was under the assumption that when BLN times-out the wakelock is gone. Meaning it's there for the time the LEDs are on, and releases otherwise. But this can't explain the 22 minutes wake lock, so I'm guessing either the timeout doesn't work (bug?), or the wake_lock stays regardless (bug?)

About siyah - I think he removed the blnww for now, because it did more damage than good.
[BetterBatteryStats] Tungstwenty:
I don't have a clue, I don't follow CM development.

Perhaps you could ask in the appropriate section if they have it also or if they plan on including it.
[BetterBatteryStats] JB-C:
great app, tks !
[BetterBatteryStats] camspy:
I turned WIFI OFF

I froze JD (did you mean to make a favor for myself and not use it at all?)

Maps caching settings - I don't use google maps, or what did you mean?

Kaiten Email - I have checked everything on there, I have polling/pushing just 1st class folders. I attached 2 screenshots: one is settings that I used for mailboxes and other is settings i used for folders that i don't want to be synced. Are these good to use?

What do I need to do now, before making another BBS dump file? My battery is now at 32%, do i need to charge it to full and wait a few hours before making a dump file or what do you say?
[BetterBatteryStats] jeffreii:
Ty for the input Tungstwenty. I wasn't able to glean much from that commit note other than the general idea that ICS has brought along with it more wifi activity - > less battery life. That may be a general problem but seeing as mine is an intermittent issue, I think it's something minor and probably not something I can fix on stock ROM?

I will wait for the next "flare up" and then watch my router's logs to see if I can catch something but I'd be interested to know if rooting (and exposing the alarms?) would net me any further information to help me discover the culprit here.

Thanks again.
[BetterBatteryStats] budi5555:
hi guys...if i have multipdp, secril_fd-interface, pms, and l2_hsic big percentase, what should i do? i don't know what is that meaning? can give me advice?
[BetterBatteryStats] jeffsf:
Had some "issues" trying to move from RC3 to RC4 over adb with adb install claiming it was already installed. Pushing the APK to the phone and then from device shell:

# pm install -r /sdcard/path/to/BetterBatteryStats_xdaedition_1.9.0.0RC4.apk

allowed the install.
[BetterBatteryStats] Karpfenhai:
Read the OP and post a valid dump...

multidpd = Traffic over mobile network

secril_fd = Your radio is trying to sleep + Fast dormancy

L2_hsic = Network Traffic, mostly wlan related

No Dump, No Support !!!!
[BetterBatteryStats] cdmackay:
It's device-specific, so you need to check the CM9 changelogs for your device.

e.g. Exynos 42xx devices (e.g. SII, Note) got this change in 20120710:

http://review.cyanogenmod.com/#/c/18475/

Sadly it seems to have done nothing for my wlan wakelocks, so I need to look further.

---------- Post added at 05:25 PM ---------- Previous post was at 05:20 PM ----------

feature request, please:

In KWL, we can order by count; any chance to also order by wake count, please?

thanks much indeed.
[BetterBatteryStats] mahercs:
You guys have been a great help in the past, and rather than have you waste time reading a whole dump, I have what I think to be a quick and easy question: When the phone is idle and the LED is blinking from email, text or whatever, is that reflected in BBS as AudioOut_1 Partial WL, or is this dependant on the phone/OS version? I am on a stock rooted Droid Razr Maxx with ICS 4.0.4.

Thanks!