yashsingh1/xdaforums huggingface dataset:
[BetterBatteryStats] truewt:
Disabled that crap alr now looking forward to tonight to see how the battery performs.

Previously was fine until I flashed blg8 and then wanam lite..
[BetterBatteryStats] Karpfenhai:
Why not using the browser, the mobile view is almost the same, i recommend maxthon. Or friendcaster..

Tapatalked from my Samsung GT9100
[BetterBatteryStats] g3ckospy:
Can some enlighten me why or what apps could be the culprit of having high Android OS when checking my battery usage?
[BetterBatteryStats] Karpfenhai:
Probably a system app but w/o dump, no way..

Tapatalked from my Samsung GT9100
[BetterBatteryStats] g3ckospy:
Okay will produce the dump later. Thanks
[BetterBatteryStats] salleq:
On I9100, at least on CM9 (can't tell if your rom is AOSP or based on Samsung), Android OS is mostly on the top. There are threads about it here on XDA. IIRC it's just a display bug. For me it's always 40-60%, and I'm on CM9.
[BetterBatteryStats] mastarifla:
Thank you for making this application, I went ahead and bought the play market version of the application to support you and your work :)
[BetterBatteryStats] yhrn:
Hi,

The dump you posted shows that the phone has been awake almost all the time which makes sense if you listened to music all the time. BBS is mainly a tool for analyzing what wakes your phone up and keeps it awake (and thereby uses battery) - it will not help that much if you want to improve your battery time when using the phone.

If you still want to improve your idle battery time study BBS after the phone has been left alone for a couple of hours and post an idle dump here if you need help (read the OP for instructions on creating a useful dump).

As for your question about the msm_serial_hs_* KWLs I cannot help you - maybe somebody more knowledgeable can shed some light there.
[BetterBatteryStats] eddy44:
how do i find the dump file on my galaxy nexus

i cant seem to find the dump file on my nexus how do i locate this file. i am running bugless beats, my battery life has been really good, but in the past few days i have noticed a increase of activity when my screen is off. I think my battery is draining a little too much when i am not using my phone at night. it keeps waking up my phone quite a bit. I think Google latitude might have something to do with it.
[BetterBatteryStats] Tungstwenty:
Menu button, "More", "Dump to File".

You'll get a file on /sdcard/ with a name in the format "BetterBatteryStats-yyyy-MM-dd_HHmmssSSS.txt"
[BetterBatteryStats] hyperbolic:
Thx for the replay.

Yea I had 1 restart, though I took screen shots of the app before I generated the dump file, take a look and tell me if I could freeze something (except the email app):

Thank you.
[BetterBatteryStats] Tylonhh:
Hi,

Is this heavy battery drain normal?

(It's a parody to one day charger who are flaming) ;)
[BetterBatteryStats] eddy44:
I have a verizon samsung galaxy nexus, there is not SD card. when i my access it with my computer i see no such file.
[BetterBatteryStats] g3ckospy:
Im on CM9..
[BetterBatteryStats] chamonix:
This dumpfile was taken for a too short period to make definitive statement but I can tell you that leaving Wifi on is certainly one cause of awake/wakeups that you want to avoid
[BetterBatteryStats] chamonix:
Without the dumpfile (please read the first posts about how to take an idle dump) it's hard to tell you if there is more potential. But the screenshot tells me that there is some potential. If you hadn't turned the screen on to lurk at the battery indicator it would have lasted longer ;)
[BetterBatteryStats] chamonix:
/sdcard is the mountpoint of the internal SD on gnex
[BetterBatteryStats] sewe:
-22% deepsleep:confused:
[BetterBatteryStats] BStinsonWhadup:
Better Battery Stats - Analyzing a dump file

Please assist me in determining my battery drain issue. I've lost 94% over the course of 12 - 13 hours on CM9, across multiple flashed ROMS. Im not sure if it was a bad flash, or an installed APP that got hungry, but i don't want to shotgun approach wipe, because if it's a bad APP then i might unknowingly reinstall it in the future.

Thank you.

Please note the top line of the file was manually added as note which i will also paste here (editing for a freakin typo lol)

GOING TO MORE -> RAW KERNEL WAKE LOCKS reveals "vbus_present

8h7m10s (29230 s) Cnt:(c/wc/ec) 4/0/3 26.0%
[BetterBatteryStats] salleq:
MAIL_SERVICE (com.android.exchange.Exchange Services): 30 m 3 s (1803 s) Count:747 6.7%

GTALK_ASYNC_CONN_MYNAME@gmail.com/android_talk5de531d35799 (Google Services): 26 m 5 s (1565 s) Count:207 5.8%

GTALK_ASYNC_CONN_com.google.android.gsf.gtalkservice.AndroidEndpoint (Google Services): 26 m (1560 s) Count:758 5.8%

Exchange and google talk are the biggest culprits. I'm using both, too, but don't have so big wakelocks in either! Are you using push? Do you receive a lot of mails? You could try removing the Exchange account and re-adding it. Also in alarms, Maps is right after Exchange. Using Latitude? I suggest setting location manually from there and using an alternative update application, either ALTitude from chamonix, or Backitude. Also, Facebook is not on the top of the lists, but is a known battery hog, so I suggest replacing that too if possible.

But, the log shows screen on time of 1h, so I suggest trying to get an idle dump. Best way to do this is to charge the phone before you go to sleep, and unplug it when it's fully charged - but leave connections on (Wifi, if you use that mostly) for the night.
[BetterBatteryStats] chamonix:
Your version is:

1.9.0.0RC8

Please make sure to update to the the current stable version
[BetterBatteryStats] chamonix:
Besides exchange (you next problem) I see "mmc2_detect" (): 4 h 37 m 4 s (16624 s) Cnt:(c/wc/ec)2047/0/2047 31.4%

As far as I remember that's the sd card stuff and may be a sign that your media scanner is stuck due to a bug or a faulty sd. I read something about buggy mediascanner and CM: does it apply for your ROM?
[BetterBatteryStats] sewe:
So this is a bug that has been fixed in 1.9.1?

Skickat från min GT-I9300 via Tapatalk 2
[BetterBatteryStats] sewe:
It happened again

Screen off the hole time,screenshot direct after

Cpu states in the log file says deepsleep 94%
[BetterBatteryStats] paranoid2007:
If BBS doesn't show a category "deep sleep" under "other", does this mean, my phone never goes into deep sleep?

Gesendet von meinem GT-I9300 mit Tapatalk 2
[BetterBatteryStats] Rozza C:
Thanks for your response.

I used it as normal, without playing music and discovered that those hs_ entries were gone. So I'm guessing that they have something to do with my music/bluetooth usage.

So that eases my soul a little bit. :laugh:

Thanks for the help.
[BetterBatteryStats] jshashwat93:
Hey.. New to android. And figured my phone has several wakelocks, I want someone to explain me the difference between kernel wakelock and partial wakelock. And does anyone know what 'multipdp' wakelock is? Getting it as a kernel wakelock on my galaxy s3. And seems to be one of the biggest culprits. Any help anyone? Thanks a lot...
[BetterBatteryStats] jimmyj352:
Help with BetterBatteryStats Dump

Hey everyone! I have a rooted Samsung Galaxy S III for Verizon and I love the battery life a lot more than the Droid Incredible that I had. However, I thought I would be getting better battery life than I am getting. I found my way to BetterBatteryStats and wanted to see if there is anything out of the ordinary, but I'm not entirely sure what I'm reading in the results. I've attached a dump in the hopes for a little help.

Any thoughts?

Thanks!

-- Jim
[BetterBatteryStats] suku_patel_22:
Do you have latitude turned on ?

Tapatalked from a Desire S waiting for Kernel 3 sources. WAKE UP HTC!!!!!!
[BetterBatteryStats] jimmyj352:
I do have Latitude turned on because I do use it... it's that bad, huh? Is that the bulk of things or is there anything else that jumps out at you?

Thanks for your help!

-- Jim
[BetterBatteryStats] suku_patel_22:
It's Latitude, disable latitude for 3-4 hours and see if the screen on vs awake ratio improves.

Post a dump of that test to confirm.
[BetterBatteryStats] hyperbolic:
Hi,

I generated a new dump file, hopefully this one isn't partial as you mentioned before.

I barely get 2 hours screen time since I moved to RR 2.6.1 I guess it is because of the partial/alarms I have.

Please do take a look a suggest me which app I should freeze.

Thank you.
[BetterBatteryStats] chamonix:
I was able to reproduce and hope to be able to provide 1.9.2 for that. I will not release 1.9.1 to Google play

Edit: issue is #224
[BetterBatteryStats] chamonix:
It would be really great if you could do the exercise again:

- install 1.9.1

- reboot

- plug / unplug

- take a logcat and dumpfile

I am hunting this bug since a while but can't reproduce. 1.9.1 contains some logging about the content of the references in the hope to understand what inconsistency brings the since unplugged ref to be discarded and so causing the "no ref found" error
[BetterBatteryStats] chamonix:
Partial Wakelocks are the mechanism a dev has to guarantee that a certain process will not get interrupted by the phone going to sleep while a routine runs.

A kernel wakelock is a kernel mechanism for the same. All partial wakelocks are present as kernel wakelocks (discrete or as sum, depending on kernel). The sum is called PowerManagerService.

Multipdp is a kernel wakelock held while data traffic is going on (read the details by clicking on the orange exclamation mark in bbs). The causes of multipdp are the apps you can find in the network stats (cell)
[BetterBatteryStats] M.A.K:
Sure... how exactly would you like me to 'take a logcat'? I've only used logcat via adb.
[BetterBatteryStats] M.A.K:
Ok, I did as asked but plugged it back in to take the logcat... is that ok for you?
[BetterBatteryStats] Karpfenhai:
Man, this isn't an idle dump and therefore almost useless for us. Read the op /second post how to produce the right one.

But 2 hours only? You have a serious problem, how its you're carrier signal in your area?

Tapatalked from my Samsung GT9100
[BetterBatteryStats] yhrn:
Hi,

GTALK_ASYNC_CONN is actually not directly related to GTalk but rather the entire Google services framework so you probably won't get rid of that completely. However, disabling syncing you don't need or changing sync interval for various Google apps can probably reduce it.

Maps you can freeze if you don't need it at all. Otherwise you can make sure it only does "Automatic caching" of maps on wifi and also prevent it from waking up by disabling autostarts using an app like "Autostarts" or Gemini App Manager (both available on Play Store). I use the latter approach and get very little drain from Maps.

Oh, and the suspend_backoff KWL you can probably get rid of by unchecking "Developer tools->Enable tilt scrolling" in Chrome settings (assuming you have Chrome installed)
[BetterBatteryStats] nothingman1976:
Hi,

I'm trying this wonderfull app on my "exotic" ZTE U960 which is the only one Android dual sim full active on the market.

The phone is rooted and everythings works except the "Network Stats" which are empty: how can debug this problem ? Can I look a some log file ?

Thanx

--

Nothingman
[BetterBatteryStats] mzaur:
I also have the issue with KWL no reference set -- my logcat is attached.
[BetterBatteryStats] chamonix:
It would be useful if you could check if this file exists: /proc/net/xt_qtaguid/stats

If it does please post it's content (PM would be nice for future ref as we may discover that there are "alternate" formats. It that case I will need more info from you in order to implement that "alternate" recognition but first things first).
[BetterBatteryStats] chamonix:
I will spend more time analysing the log but there is one one thing that drew my attention

D/AndroidRuntime( 1005): Shutting down VM

in the middle of the log. With that info I wonder if you may suffer from userland restarts. This would explain a lot as this situation is known to be a big problem in the case of BBS: as I get info from both userland (batteryinfo) and the kernel and mix them I rely on both having a common reference (the boot) in order for all counters to start counting at the same event. Now those "micro-reboots" (if it's the case) obviously break that consistency.

Is there any sign from the user perspective that confirms that?

I will spend some time trying to find out if there is a way to document a userland restart so that we can confirm/rule out that theory.
[BetterBatteryStats] chamonix:
With what BBS version have you created that log?
[BetterBatteryStats] nothingman1976:
The file /proc/net/xt_qtaguid/stats does not exists: does it means than my kernel (2.3.5) does not supports network statistics ?
[BetterBatteryStats] Tungstwenty:
Process time - too low?

Sven,

I have seen several times in the Process view very short values but never thought too much about it.

However, today I happened to open the Settings / Battery screen (hadn't used that in ages after BBS) and noticed that an app was reported with about 5% power consumption and clicked for the details, curious about how that was measured. I don't know if running time is the only factor used for that view, but it reported about 26m30s total time and 17m foreground time (which I think is more or less coherent with the time I had the app open).

But in BBS, Process display, it only reports 44s sys + 114s user time (9 starts). It's way below my app usage time, even if I consider only the latest invocation. This is a game with opengl, so I'm guessing it should be constantly draining the cpu, even if not at 100% nor at full throttle.

Could it be that the Battery screen is displaying wall time while BBS is reporting actual clock ticks while the app was not preempted, and it indeed only consumed 44+114s of CPU? It seems pretty low, but could be.

And if that's the case, do you think adding the wall time would be useful to understand how long the app has been "active"?

As for the entry "Android system", which includes all those packages (Settings, System UI, PhoneUtil, etc.), the times are very strange - CPU total=17m10s; CPU foreground=36s (???)

Do you have any idea of what measurements make sense here? :)

BTW, I'm using the correct reference ("since charged", it wasn't at 100% at boot) - after I change from "since unplugged" to "since charged" I get the exact same time reported in BBS and on Battery related to "Phone usage".

---------- Post added at 11:46 PM ---------- Previous post was at 11:25 PM ----------

Can you try running this on the shell and posting the generated /sdcard/proc_entries file, to see what could be useful in the info your kernel provides?

cd /proc
find . -type f 2>/dev/null | grep -E -v '^./[0-9]+/.*' > /sdcard/proc_entries
[BetterBatteryStats] kilthro:
wrong thread sorry
[BetterBatteryStats] chamonix:
For those wondering where 1.9.2 stays. I have spend a great amount of my evening chasing the non explainable high values of "screen on" times in "since screen on". The more I look at the stats the more I find that those values seem to be correct but I'll take a break on that and sleep on it.

Then I started to do some monkey tests (switching stats and clicking) and ended up losing the since unplugged ref and getting the error "no ref since unplugged yet". A look at the log shows intersting stuff:

I/StatsActivity(29730): Since 45 s
I/BatteryStatsProxy(29730): invoking android.os.ServiceManager.getService("batteryinfo")
I/BatteryStatsProxy(29730): invoking android.os.ServiceManager.getService("batteryinfo")
I/BatteryStatsProxy(29730): android.os.ServiceManager.getService("batteryinfo") returned a service binder
I/BatteryStatsProxy(29730): android.os.ServiceManager.getService("batteryinfo") returned a service binder
I/BatteryStatsProxy(29730): invoking com.android.internal.app.IBatteryStats$Stub.asInterface
I/BatteryStatsProxy(29730): invoking com.android.internal.app.IBatteryStats$Stub.asInterface
I/BatteryStatsProxy(29730): invoking getStatistics
I/BatteryStatsProxy(29730): invoking getStatistics
E/JavaBinder(29730): !!! FAILED BINDER TRANSACTION !!!
I/BatteryStatsProxy(29730): retrieving parcel

Conclusion: my monkey test stresses batteryinfo, it ends up failing (that's not supposed to happen) and I lose the ref. Now looking at the code you may notice double entries. That's the sign of a race condition and I think that we have a concurrency problem here. The good news is Java has a method to avoid that: synchronized (for those who are old like me, let's call that the "modules" of modula2 reloaded).

Now I have an experimental 1.9.2 with mutex around the batteryinfo service and hope to at least prove that there are no negative side effects from that. Now it's 2am so I won't upload but go sleep, do some more testing, cleanup, and finally hopefully release a version with an attempt to fix that bug.

In the meantime I will think of the "screen on" figures: I believe that those values are "true", meaning hitting power doesn't switch off the screen as we believe it does.
[BetterBatteryStats] nyancatland:
Could someone take a look at my BBS dump? Sorry I'm on mobile xda and it's kinda inconvenient to attach a file, so I just pasted the log here.

I turned off mobile data all the time btw, that's why I had no data connection at 100%. My reception is fairly good.

Thanks in advance :) and also could someone tell me what app is the top partial wakelock (networkstats) related to?

Delivered using Nyan Cat's rainbow powers.
[BetterBatteryStats] mzaur:
Your phone is fine...whats the problem?
[BetterBatteryStats] mzaur:
It was 1.9.1
[BetterBatteryStats] mzaur:
Sorry i don't know. What should i look for?

BTW the issue went away, at least for now. I rebooted a bunch of times, and recharged.Not sure what did it. Attached another logcat
[BetterBatteryStats] daggerxXxsin:
So i flashed a new rom and decided to run a quick battery drain check. The values i got are weird. The ratios all say 100% and no indication of what the power loss was or the total minutes of wake time. Maybe i did something wrong. Here's the dump.

http://pastebin.com/T03emDjr
[BetterBatteryStats] nothingman1976:
Please find attached the output of the command you suggested to me

--

Nothingman
[BetterBatteryStats] Miche1asso:
Hi Chamonix,

I believe I have the same exact bug. I could finally dig it out and I discover that the kernel wakelocks and CPU states (the dumpfile will show it to you better) get lost after a reboot, while the partial wakelocks are fine. I attach a copy of dumpfile and logcat as well.
[BetterBatteryStats] Miche1asso:
On another side (sorry for the double posting, but I want to make the issue separated from the app bug), can anyone explain why after a reboot I can lose up to 11% (ELEVEN percent) of battery? This is driving me mad, I feel like throwing the phone in the garbage. It's not the battery, I've bought a new (Gold) one, same thing.
[BetterBatteryStats] MyGoul:
My phone is almost always awake

Hi,

I have bought this amazing soft in order to understand what happens with my phone which is quite often awake while the screen is off. Even by following the "How to" included in the soft, i can't really identify what's going on. Here is a dump i have produced after the night. As you can see on the graph generated by BBS, the phone is almost always awake while the screen is off (the view is quite different is the ICS battery graph ?).

Any help would be appreciated to help me to identify the process that could cause this.

Thanks in advance.
[BetterBatteryStats] Nos_20:
Got the software to see whats going on in my phone. Although CPU spy reports deep sleep. BBS says my phone is awake with the screen off. I have attached a dump file, if anyone would take a look who knows what to look for. My screen was on for just over an hour but the phone awake for over 4 hours?

What do I need to do to stop this from happening. My rom is Paranoid Android 1.9.2 and Siyah Kernel 3.5.2
[BetterBatteryStats] Karpfenhai:
Hey there,

Your have quite allot sync activity on your device, therefore network traffic (multidpd) has kept your phone awake.

Also maps has misbehaved (assuming you didn't actively used it) read some pages back how to reduce maps wakelocks.

So once you reduced the sync, take another reading but your current results are not to bad either.

Tapatalked from my Samsung GT9100
[BetterBatteryStats] Karpfenhai:
One word, Facebook! Its your main cause for the drain.

Second gps lock, disable gps and location based services.

You may try another modem, afaik lpq is not even known as battery friendly.

Try ki4 or kh3 instead.

Tapatalked from my Samsung GT9100
[BetterBatteryStats] Tungstwenty:
The race condition is on the battery service and not on your side, right?

That being the case, locking the mutex won't really help unless the service manager used the same stub for every single process accessing the service - which of course can't happen since they live in different java processes (1 for the service, n for the multiple clients).

Even on your side (say, if you'd have multiple threads asking stuff from the service), doing multiple ServiceManager.getService("batteryinfo") might return separate proxy objects, I'm not sure.

IMO the problem is likely occuring when the transaction is iterating internal BattSvc stuff to return (you're calling getStatistics, perhaps) while at the same time other processes are calling other entry points in BattSvc to report activity (noteStart/StopWakelock, noteScreenOn/Off, etc.).

This might not be the exact code running on the service's side but is good enough to illustrate:

BatteryStatsService.getStatistics

Notice the comment block (a lock must be held externally whenever calling stuff on mStats). Also, the methods after getStatistics all have syncrhonization around mStats manipulation.

When getStatistics calls mStats.writeToParcel, however, there's no synchronization. And if you follow that code you'll see it jumping to writeParcelLocked, which hints that is should be called only when the object is already locked. Going further to that method, you'll see lots of state reading without protection, and iterations such as this one are bound to throw ConcurrentModificationException, which isn't even the worst-case-scenario. I've seen situations where iterating a HashMap while other threads are adding stuff have lead to the reader entering an infinite loop while trying to read the next entry, if the writer triggered a rehash and the timings are unfortunate.

As you wrote, this is not supposed to happen and is therefore a bug in the android core service.

If all this is indeed the cause, I'd say wrapping your call around a lock won't fix anything (unless you're the one generating concurrent write+read on the service, which I'm pretty sure is not the case).

A possibility might be having a failover mechanism that would retry the transaction a couple of times before giving up, and even if it fails do not invalidate the reference data permanently and have some way to recover in a future successful transaction execution.

And if you're really paranoid :) and the infinite loop I mentioned is a real possibility (a stress test might be an option to test this theory), you could even create a separate thread on your side whenever invoking the transaction, just in case it never returns - I'm not sure if the IPC mechanism has some sort of timeout.
[BetterBatteryStats] sewe:
I don't believe so as it shows real value for the most of the time .

It doesn't happens all the time

As I'm not a developer i can't help you but it looks that it's something that's triggering it

Skickat från min GT-I9300 via Tapatalk 2
[BetterBatteryStats] Nos_20:
So should I just cancel Facebook notifications or uninstall it all together? The GPS was a one off I was lost!

I have downloaded ki4 modem will flash that and see if it helps.

Thanks for the reply

Sent from my Jelly Beaned Paranoid Android Galaxy SII
[BetterBatteryStats] salleq:
You should take a bigger dump, like after a night. 1 Hour isn't much, and 1% per hour isn't really bad. But your biggest problem according to this log is whatsapp, then maps is next.

Uninstall Facebook. I have noticed just disabling notifications doesn't really seem to help much.