yashsingh1/xdaforums huggingface dataset:
[BetterBatteryStats] Tungstwenty:
Strange, it should work exactly as you state - no individual KWL should exceed the total time of the discrete measurement :confused:

Did you double-check if you used the correct reference type both when starting the measurement and when taking these final BBS dumps? Mixing them up would be a possible explanation.

Another thing you could do is start the measurements (with different references also) after a reboot. That way the KWL counter at /proc/wakelocks should be near 0, or even 0 if you didn't let the screen turn off till you took the initial reference. Assuming BBS reference values are discarded (at least for KWLs) after a reboot, it would be safe to then take the 2 measurements in the end. Just a wild shot ...
[BetterBatteryStats] Stolper:
Thnx for your help! I did as you asked, fully charged it and maked a screenshot of it. I don't see anything suspicious, maby you do?
[BetterBatteryStats] Karpfenhai:
If your phone is awake and its not visible on the dump, check the Process tab in BBS , maybe its still active and only started once (held permanent Wakelock).

Please report back.
[BetterBatteryStats] Rob2222:
I don't think that I mixed it, but I will take some more comparisons to make sure. :)

After rebooting in exclusive mode, all stats (but main) in /proc/wakelocks are zero.

After rebooting in normal non-exclusive there is plenty data in /proc/wakelocks. Checked twice.

Should rebooting in non-exclusive mode reset /proc/wakelocks data also? If yes, thats maybe the problem (Siyah 1.3.8a).

Best Regards

Robert
[BetterBatteryStats] chamonix:
This bug (#200) was supposed to be fixed in 1.9RC5 (it's in post #2)

Are you using an earlier version or should I re-open the bug?
[BetterBatteryStats] Rob2222:
@Chamonix:

I just tried dumping dump-files with Tasker, first time.

It just creates 0-byte dump-files.

Am I doing something wrong or is this maybe a bug?

Best Regards

Robert
[BetterBatteryStats] IKnowIRock!:
Thanx alot for this :) :good:

Sent from my LG-P500 running Ginger Snap
[BetterBatteryStats] chamonix:
Any feedback on "discrete" report in dumpfile and on enable/disable of traces?

Once those are confirmed working I'll start the preparations for a release (doc, merge release notes), update posts and google play, rollout
[BetterBatteryStats] h20wakebum:
Hi there,

I believe I've done everything you've asked in your OP.

I just bought a brand new battery and noticed that life wasn't too good.

I've let it completely charge/discharge once... This bbs is from the unplug after the 2nd full charge.

Anything you see that's a "Red Flag"?

Thanks in advance.

-RR

View attachment BetterBatteryStats-2012-07-20_072144755.txt
[BetterBatteryStats] chamonix:
I see that you use a pretty old version (RC) of 1.8 (current is 1.9RC9). I suggest that you take another reading with the current version and make sure that you plug/unplug and provide a "since unplugged" dumpfile (4-5 hours of idle is enough.

From that reading I see:

Since 7 h 29 m 42 s
Awake (): 48 m 45 s (2925 s) Ratio: 10.8%
Screen On (): 13 m 50 s (830 s) Ratio: 3.1%
Phone On (): 12 s (12 s) Ratio: 0.0%
=========

48 - 14 = 34 minutes awake in 7 hours 30 minutes.

More after next post as the dumpfile was incomplete (no kernel wakelocks, no alarms).
[BetterBatteryStats] chamonix:
Since 14 h 37 m 1 s
Deep Sleep (): 12 h 16 m 20 s (44180 s) Ratio: 84,0%
Awake (): 2 h 20 m 40 s (8440 s) Ratio: 16,0%
Screen On (): 1 h 14 m 21 s (4461 s) Ratio: 8,5%
Phone On (): 3 m 21 s (201 s) Ratio: 0,4%

2 h 20 - 1 h 14 - 3m = 1 h 3 minutes awake in 14 h 30.

Looking at the alarms most of the drain is due to Maps wakeups and those are due to wifi being on.
[BetterBatteryStats] yhrn:
Works for me. If (and only if) I enable discrete KWL i get (!!! discrete !!!) in the section title for KWLs in the dump file.
[BetterBatteryStats] Tungstwenty:
Rebooting always resets all. It might look like you have plenty of data in non-discrete mode (I need to submit a name change to GM :D), but if you look carefully at the sleep_time, you should find everything with 0 if you never let the screen go off. That means that no KWL activity exists (main is active, so the timers stop). "sleep_time" is what we see in BBS as the KWL time, when CPU is not being allowed to sleep.

Here's another thing that you can do. Instead of relying on the BBS refs, take directly the contents of /proc/wakelocks_total and wakelocks_exclusive, load them under excel or something else where you can easily split it by TABs, and do the math with the columns you need. From the last 4 columns, the relevant one is "sleep_time".

Those timers are in nanoseconds, so take out the last 9 digits to get seconds.

In summary:

- reboot

- let it idle for some time

- adb shell

cat /proc/wakelocks_total > /sdcard/dump_wakelocks_total_nnnn.txt
cat /proc/wakelocks_exclusive > /sdcard/dump_wakelocks_discrete_nnnn.txt

This is independent of the active setting in ExTweaks, which only controls which of those stats show up in the /proc/wakelocks entry.

Check the output files and/or post them in order to analyze if each of the regular times is below the sum of discrete times, as expected.

I did this test on my device and I had for an uptime of about 5h (daytime, so normal usage) a total of 1307s discrete KWL time, and all individual KWLs show up with less than that time even with regular stats. multipdp is also the biggest one I have, but with only 734s, then secril_fd-interface with 603 (total already exceeded due to overlap), PowerManager with 534, etc.
[BetterBatteryStats] analyst783:
No change with rc9.
[BetterBatteryStats] jeffreii:
Tungstwenty: any thoughts on "bam_dmux_wakelock" and "smdcntl0" as seen in this post?:

http://xdaforums.com/showpost.php?p=29036308&postcount=6739

Thanks in advance for your vast knowledge!
[BetterBatteryStats] wizard83:
Thanks a lot.

For those who have jelly Bean, I suggest to disabled Google now, it drains battery due to localization services.

Inviato dal mio Galaxy Nexus con Tapatalk 2
[BetterBatteryStats] Tungstwenty:
:laugh: I'm not that knowledgeable...

When I want to know something about a certain KWL I just browse the kernel sources and check on what situations is it used.

The 2 particular ones you mentioned don't appear in the kernel I use; I did search for them when you posted before but didn't reply because of that.

You'll need to check that info in a thread dedicated to discussion of the kernel being used to see if someone there can give any info. You don't have a signature but judging by your last posts you're using either an S3 (but not siyah kernel?) or an HTC One X, right? Either way, this pertains to the specific kernel you're using.
[BetterBatteryStats] superbobup:
Anyone have any insight on this? I've attached a dump file and Maps is clearly the culprit, probably due to the Location services (cell/wifi). But, does anyone know how to reduce these alarms using some method or another app while still using Location services? Would disabling Maps in autostarts help? Just looking for ideas :) :D
[BetterBatteryStats] riskaa:
I'm curious about this too, now that I have Locations enabled all the time.
[BetterBatteryStats] Karpfenhai:
Yes and Yes.

Disable maps completely with autostarts

Use Altitude (from Chamonix too) as latitude replacement instead.

Good luck!
[BetterBatteryStats] riskaa:
Karpfenhai,

Could you explain Autostarts to me please. As far as I understand, this disables apps from starting up when you boot...is that correct?

Ok...I'll look at Altituce...

Thanks for the insights and answers!:D
[BetterBatteryStats] Karpfenhai:
Not completely, you can fine tune it.

It only prevents apps from starting by itself, manual start will work anyway!

So Yes it can prevent start on boot too.

Just list the app by its name and disable what you think it might be usefull, for maps everything can be disabled w/o any issue.
[BetterBatteryStats] superbobup:
Thanks! I had a feeling auto starts would help...I'm guessing it will help get rid of the constant coarse location service update...however, I wonder if Google Now is somehow linked to the Maps location (thus causing it to wake up so many times and constantly run) rather than accessing the location by itself when necessary...anyways, I'll give it a go

also, I have been running ALTitude for some time. In fact, chamonix had just fixed a recent issue I was having after a few days of testing :D. ALTitude seems to help a lot since the Google Now traffic card uses Latitude places(I think) for Work, Home, etc.
[BetterBatteryStats] wizard83:
Thanks guys for your support, I love my Galaxy Nexus, but battery drain is huge... I will try autostartups and Altitude!

Many thanks!

Inviato dal mio Galaxy Nexus con Tapatalk 2
[BetterBatteryStats] chamonix:
Facebook....
[BetterBatteryStats] Karpfenhai:
Youre welcome mate! ;)
[BetterBatteryStats] chamonix:
#208: fixed in 1.9 final
[BetterBatteryStats] JoeSyr:
I've run a few of the 1.9 RC versions, and while the new CPU States feature worked when I first installed one, it hasn't worked for the last few versions. Unfortunately I don't have a record of which was the last version that worked, but it may have been around 4 or 5.

I think I also uninstalled CPU Spy when I saw it was working, which may be a coincidence, or that may have been when it stopped working.

When I go to CPU States, it only says 1kHz, for "---%".

This is on a 4.1.1 Rom. And I guess I can't say for certain, but I think this was working on JellyBean the last time it did work.

Attached a dumpfile, let me know if I can provide any more useful info.
[BetterBatteryStats] chamonix:
I will check on my JD phone tomorrow before releasing (1.9 is finished). CPU Spy being or present or not does not make any difference.

Could you please open a shell or adb and tell me if you see the file (and its content)?:

/sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
[BetterBatteryStats] chamonix:
I will look into the previous post about CPU states on JD and am holding back the release till that was checked. You will have to wait a few hours as I am off to bed now :P
[BetterBatteryStats] JoeSyr:
Here's a readout of that file:

230000 15463
350000 1537094
700000 248299
920000 28672
1200000 38375
1350000 0
1520000 0
1650000 0

Actually, I think i see what the error here is. My kernel has the 230 slot as an option, but it is not enabled under the current config, nor has it ever been enabled. 350, 700, 920 and 1200 are the only slots that are enabled. The upper ones are not, so it's normal for them to show 0.

So I'm guessing that what's currently being written to the 230 slot is really the deep sleep time. Unless deep sleep is a different stat stored elsewhere?

...but ouch, if that's true then it looks like my phone barely entered deep sleep at all today. But that's a different issue, still hammering things out like Google Now for myself.
[BetterBatteryStats] Paragon_X:
Thanks mate. Guess those notifications I receive are the reason which I figured. Hoped turning sync intervals off would help but guess not.
[BetterBatteryStats] jeffreii:
Thanks and yes it's the AT&T S III on the stock kernel.

As you can see in this thread, there are other users experiencing the same problem and seem to be seeing these two wakelocks at the top:

http://xdaforums.com/showthread.php?p=29042746#post29042746
[BetterBatteryStats] Tungstwenty:
If you're on stock, then check if the sources for your model are available and dig through those. In alternative, see if any of the custom kernels are suitable for your variant and if so have a go; it's more likely the active devs will be able to help you.
[BetterBatteryStats] chamonix:
I'm not sure about that.... not that I don't want to provide a "light" version but what limitations would it have and still be useful? For sure I could show e.g. the wakelocks minus the top5 but I feel that if someone does not get the need of this app it's too technical for someone to decide to buy it.

Your thoughts on this are welcome
[BetterBatteryStats] nobnut:
I think he said trial version... maybe expires after x days.

Sent from my Motorola StarTac using Voodoo
[BetterBatteryStats] ithehappy:
That's exactly what I meant.

All good apps should have this. I mean if there is a Trial of this app then more users will try to see what it does, and we all know they will like it, and eventually they will purchase ;)

But if there is only Paid option, some or many users will avoid it after seeing it as a Paid app.

I hope I made myself clear :)

Regards.
[BetterBatteryStats] chamonix:
Now I get your point, I was interpreting something else.

I think there is some preparation to be done before following that path and that's basically what I work on when I'm not fixing bugs and doing support:

BetterBatteryStats must become more self explaining:

- quick tutorial on how to proceed, following a simple decision tree

- more knowledge about what to do about hot-spots

I feel once someone had the opportunity to work following a simple workflow from analysing to making changes to seeing results he woule be more keen to "keep" the app for regular sanity checks. Right now I think the app is good because it provides all the information but there is still some knowledge and will required. The will must be thereand should be rewarded by the results but regrding the knowledge I'm working on lowering the entry "fee". I don't want to sell it as "simple" but it is not and will never be but I believe there is potential in the user experience.

I'm prototyping something in this regards but don't know when it will be ready to show to you people because unfortunately my time is limited because of my job and because I have a few other projects running.

I'm not complaining as I really love doing this and the way things are evolving, the way we interact here. I really enjoy working with you guys and wish things go on as they started, with this project and with more of those to come.
[BetterBatteryStats] peterbonge:
Yes, I'm already using 0.8.3. I sent you the logcat to the address I found on github.com.
[BetterBatteryStats] jr67:
I'm happy with the update as it fixed issue #20 for me. However, I do think there will be a lot of people who will have issues with the "back" button workaround especially if you implement it in the market version of the app. Like you said it's inconsistent with the behavior of other apps and now means the app persists in RAM until its either manually killed or eventually terminated by the system.
[BetterBatteryStats] chamonix:
It got here, I will have a look. It looks like a distortion due to the frames (botton) not downscaling below a certain limit. I don't want to spend too much time on this fix but at least the bars should show somehow properly. I'll keep you updated
[BetterBatteryStats] bu2askoor:
Just wanted to send quick thanks to the developer as I finally was able to fix my battery drain. It was ultimately latitude in maps, and back under privacy settings. I still see many counts from alarm manager but do not think it is causing a drain.

Thanks again :-)
[BetterBatteryStats] chamonix:
As I did not get enough votes yet I'll keep the fix till tomorrow and make a call on that workaround. I don't feel comfortable with the fix as as you said correctly the app will not get disposed as soon as it should be and is a break with the rules. I may add a dialog warning about state being lost instead (if custom ref was set) so that users can decide upon keeping or dumping the state. That would be more consistent but still user friendly in case someone really wants to keep the state.

I'll post 0.8.4 as soon as I get a minute to test
[BetterBatteryStats] chamonix:
Thanks for the feedback, it's always good to hear from happy users.

When it comes to AlarmManager you may want to search the thread ad there were some hints (sysdump is the keyword). Maybe not a big deal, it's your call.

If you are a sgs2 user I'd suggest that you try the latest modem in combination with latitude if you require that app. I have hacked a 'cheaper' updater for latitude but am testing the native app again as part of the wakelocks due to constant cell tower switches are gone with the latest modem, reducing the overhead dramatically
[BetterBatteryStats] thekayman:
I reckon if there is a custom ref set and someone hits back have a message to say your custom ref will be lost continue exit or leave open in background and have them select what option or even warn then have exit or back.

also it would be handy as well that once a custom ref is set to have it show what time the ref was made when the stat type is set to custom ref. either in hours or mins or exact time i.e. 9.03am 24/08/11

also just linked what my screen looks like on the Desire HD for your ref.
[BetterBatteryStats] ejstubbs:
I've just realised that Battery Monitor Widget does actually show screen-on periods on its graphs. It's not as easy to read as the way it is presented in Gingerbread but I have, for example, noticed something apparently going on at around 10:50 this morning when the screen is shown as being off. Every measure - voltage, current, power and temperature seems to take a kick at that time. I wonder what it was?

BetterBatteryStats is showing the biggest user of partial wake locks as being ProviderThread, with 3m 52s in the 4h 45m since the charger was unplugged. Is that to be expected or should I dig deeper?
[BetterBatteryStats] bu2askoor:
Thank you for the tip. i did go to terminal and :

su
dumpsys alarm > /sdcard/alarm.txt

I looked the file generated and found the following interesting stuff:

com.carl.tcpro
12787ms running, 98 wakeups

which is traffic control pro widget that helps me keep data trafic in check and pass my data allowance.

com.google.android.gsf
1924ms running, 88 wakeups
15 alarms: act=com.google.android.intent.action.GTALK_RECONNECT flg=0x4
32 alarms: flg=0x4
41 alarms: act=com.google.android.intent.action.GTALK_HEARTBEAT flg=0x4

This is google service framework. This is perhaps due to "automatically sign in" under GTALK setting.

neldar.bln.control.pro
10319ms running, 1472 wakeups
2 alarms: act=neldar.bln.control.pro.intent.BLINK_STOP flg=0x4 cmp=neldar.bln.control.pro/.services.LedService
733 alarms: act=neldar.bln.control.pro.intent.BLINK_ON flg=0x4 cmp=neldar.bln.control.pro/.services.LedService
735 alarms: act=neldar.bln.control.pro.intent.BLINK_OFF flg=0x4 cmp=neldar.bln.control.pro/.services.LedService
2 alarms: act=neldar.bln.control.pro.ON_OFF_EVENT flg=0x4

This BLN control. I had the setting to allow LED to blink on and off which obviously was a battery drain. I disabled it for the moment to measue impact. Perhaps i had to just have longer intervals or always on! not sure yet.

ccc71.bmw.pro
37878ms running, 972 wakeups
972 alarms: flg=0x4

This was the battery monitor widget. I went ahead and disabled it.

So to sum it: I had SGS2 for a while now and i was really shocked to see people have the battery last for more than a day. For me 18 Hrs is perfect because i will have to recharge at night anyways. So these are the steps that made a difference and finally can enjoy a full day with my super phone :)

1- Disabled data backup under privacy settings

2- Disabled latitude under google maps

3- Stopped BLN app from going on and off (notifications)

4- Removed Battery monitor widget

I am sure if i analyse the sysdump alarm, i would come up with more things to disable. But the current setup is practical for me. No need to disable "everything".

Hope this helps.
[BetterBatteryStats] RampageRR:
Wanted to check in and give thanks for making this app, it works very well.

Does anyone have any suggestions to stop my MMS from causing wakelock? I have 30.6% registered to com.android.mms.messaging and over 1.5 hrs running under wakelock. I cleared cache, and even went as far as using smsPro with the same results. I also tried wiping cache, dalvik cache, and flashing a newer nightly. Same high count from mms...
[BetterBatteryStats] jawz101:
Dude, I think you're doing your app a huge disservice by calling it this. There are so many apps that are named Battery Saver/widget/juicer/graph and this app is totally a game changer.

Something like WakeLock Wonder or something shouts to me what this app is really capable of.

I don't know how I stumbled onto this app. Completely by chance. If it wasn't for luck or that I actually opened this thread I would have passed it over.
[BetterBatteryStats] chamonix:
Very well done and explained, thanks for posting this.
[BetterBatteryStats] chamonix:
Interesting... have you received any mms during that time?

Google brought me to the sources (http://hi-android.info/src/com/android/mms/transaction/TransactionService.java.html) and studying that plus scanning the problems people have with this app brought up the following (that may apply to your case):

- the TransactionServices sets a wakelock while downloading a message and logs "beginMmsConnectivity: result"

- I have seen quite some feedback about the mms app FCing multiple times a day

Now adding these two facts I would say that there is a possibility that the app crashes while a wakelock is held resulting in those high times. You may want to check your logcat for the tag "TransactionService".

If you use sms pro but have not frozen the messaging app you may have the same bahaviour as the app listens for message received broadcasts and for sure will try to download any MMS even if another messenger is used. Have you tried freezing it?
[BetterBatteryStats] chamonix:
Thanks for the feedback and for the encouragements. I may start a panel for a new name when we reach the iteration for version 1.0.
[BetterBatteryStats] mzaur:
cham, I forgot to update. Nevermind :/
[BetterBatteryStats] JoeSyr:
Update on that bug report for CPU state: After rebooting my phone, BBS reports correctly. Someone else on the same kernel, different rom is seeing similar behavior in CPU Spy. Haven't been rebooting my phone too much or keeping such a close eye on these monitoring apps recently, so not much I can assert on if it's something like first reboot after flashing a kernel fixes it.

So not clear if it's a bug in the kernel or a bug in the roms, but unless it looks fixable on this end, it's probably not loosing much sleep over.
[BetterBatteryStats] kaushikd:
I have been seeing a lot of battery drain nowadays. My sync is always disabled. I'm sharing this dump so that if you can help me with the issue. Thanks..

I'm running stock 4.0.4 on Galaxy Nexus.
[BetterBatteryStats] Rob2222:
Hey Tungstwenty,

I have reproduced the (strange?) behaviour once again. Rebooted, plugged/unplugged in nondiscrete mode, switched to discrete mode, made custom reference, 7h idle, dumped BBS since custom, switched to discrete mode, dumped BBS since unplugged and dumped wakelocks_total and wakelocks_exclusive.

Once again multipdp nondiscrete with 430s is bigger than all discrete wakelocks in addition (265s).

I've checked the sleep_time row, and it shows the same.

I attach the files, so you can check it, if you want.

Maybe we have a bug in the kernel counting here? (still Siyah 1.3.8.a)

Best Regards und thx for your help.

Robert
[BetterBatteryStats] Tungstwenty:
You're right, the problem shows here when looking at the raw data. Total discrete time is 271s but multipdp has a regular time of 430s.

I'll check the sources on the S3 kernel and see if GM has made any changes (of if some might be needed and weren't done).
[BetterBatteryStats] melvinaury:
Where do I found the two reference utilities I check in market ( Ooppss Google Play Store) and don't see it.:(
[BetterBatteryStats] wizard83:
http://xdaforums.com/showthread.php?p=963906

https://play.google.com/store/apps/details?id=com.elsdoerfer.android.autostarts

Inviato dal mio Galaxy Nexus con Tapatalk 2
[BetterBatteryStats] chamonix:
Deep sleep is not part of that file, it is the difference of the sum of those and the elapsed time