yashsingh1/xdaforums huggingface dataset:
[BetterBatteryStats] gpz1100:
^^Chamonix, from your reply to the above post (#5474), in examining the BBS dump file, what are you using to determine that latitude or maps was the cause of the excess Awake time?

Below is the log file that's referenced above

http://dl.xda-developers.com/attach...etterBatteryStats-2012-06-02_130215649_1_.txt
[BetterBatteryStats] chamonix:
The Alarms mostly and the fact that the caching settings of maps (causing the sniffing) can not be turned off for wifi. Latitude adds on additional overhead in the partial wakelocks but the alarms are caused by the core of maps
[BetterBatteryStats] o0boiboi0o:
Anyone has an idea what causes "Phonewindowmanager.mbroadcast wakelock"?
[BetterBatteryStats] chamonix:
Sure: http://grepcode.com/file/repository...pl/PhoneWindowManager.java#PhoneWindowManager

This wakelock is held when initializing the PhoneWindowManager (shouldn't happen that often) and also when pressing the volume keys. One known occurence: the key is constantly pressed, maybe stuck in a case
[BetterBatteryStats] gpz1100:
So not so much the actual time values, but more so the number of "wakeups" in alarms and "counts" in partial wakelocks (LocationReportingService counts 4421, CheckinsNotificationService counts 2786)? Really trying to get a grasp on interpreting the data so I can get a better understanding of how to diagnose high battery consumption. Thanks for your help.
[BetterBatteryStats] chamonix:
===========
Other Usage
===========
Wifi On (): 17 m 16 s (1036 s) Ratio: 1,2%
Wifi Running (): 17 m 15 s (1035 s) Ratio: 1,2%
=========
Wakelocks
=========
NetworkLocationLocator (com.google.android.apps.maps.Maps): 2 m 9 s (129 s) Count:999 0,2%
AlarmManager (Android-System): 1 m 47 s (107 s) Count:3302 0,1%
LocationReportingService (com.google.android.apps.maps.Maps): 1 m 46 s (106 s) Count:4421 0,1%
CheckinsNotificationService (com.google.android.apps.maps.Maps): 36 s (36 s) Count:2786 0,0%
LocationReceiverService (com.google.android.apps.maps.Maps): 21 s (21 s) Count:3593 0,0%
(com.google.android.apps.maps.Maps): 15 s (15 s) Count:4399 0,0%
NetworkLocationLocator (Google-Dienste): 5 s (5 s) Count:9 0,0%
NetworkLocationCallbackRunner (com.google.android.apps.maps.Maps): 5 s (5 s) Count:1981 0,0%
Checkin Service (Google-Dienste): 4 s (4 s) Count:1061 0,0%
NetworkLocationCacheUpdater (com.google.android.apps.maps.Maps): 4 s (4 s) Count:1982 0,0%
WifiStateMachine (Android-System): 1 s (1 s) Count:710 0,0%
======================
Alarms (requires root)
======================
com.google.android.apps.maps (): Wakeups: 1006
Alarms: 985, Intent: com.google.android.apps.maps.nlp.ALARM_WAKEUP_LOCATOR
Alarms: 1, Intent: com.google.android.apps.maps.nlp.ALARM_WAKEUP_CACHE_UPDATER

Here's the summary:

- your wifi was not on that long but as you can see in the partial wakelocks the "wifi state machine" has a really high count

- as wifi was on (and latitude as well if I got the first statement right) it is really difficult to tell what part is attributed to maps (only) and what part to latitude (only).

The only way to find out would be to compare: with latitude on and off (wifi off)

A try to attribute those (I have no proof):

NetworkLocationLocator (com.google.android.apps.maps.Maps): 2 m 9 s (129 s) Count:999 0,2%

LocationReportingService: should be latitude only

CheckinsNotificationService: I'd say maps not latitude related

LocationReceiverService: Maps

NetworkLocationLocator: not related to maps directly but to any app requesting location

NetworkLocationCallbackRunner: I believe that is maps

Checkin Service: same as checkin abobe

NetworkLocationCacheUpdater: maps, afaik related to sniffing so that one would be wifi related (except if your maps caching settings are wifi and 3g)

What I recommend:

- if using maps make sure to keep wifi off as much as possible

- if you don't want latitude log off, if you like it set it to manual and use ALTitude as an alternate updater

- make sure your maps caching settings are "wifi only"

If the cost is still too high at the end of the day freeze maps
[BetterBatteryStats] o0boiboi0o:
I checked all my buttons but none is been pressed. What other causes might there be? Perhaps assign certain function to Home Button?
[BetterBatteryStats] gpz1100:
Just to clarify, the bbs dump we've been looking at is not mine, just one I picked at random to try to do an analysis on and understand how to better track down roque apps/functions that consume battery. In the old days, with spare parts, it was just a look at partial wake lock stats. But I now see that's only part of the picture.

Also, you may want to look at an app called latify. It does what ALTitude does, but with a few more options - such as recording breadcrumbs and uploading them to google when a wifi connection is available - https://play.google.com/store/apps/details?id=com.ecs.latify&hl=en .
[BetterBatteryStats] mikeage:
I just upgraded my Galaxy S2 to ICS (using an official ROM; it's a leased phone, so while I did root it, I don't want to flash something that will increase the flash counter).

I noticed right off the bat that ICS seems to use a LOT more battery than GB. I ran a full factory reset, and re-installed those programs that I use frequently. I decided, though, before I investigate network usage, I'd make sure that idle is as low as possible.

I created the following two dumps with 3G and Wifi disabled, but everything else running as usual. The only difference between the two is that the first had Battery Monitor Widget (ccc71.bmw.pro) logging every 10 minutes; the second was every 1 minute. I wanted to ask four things:

Are these results "good"? I know I have a lot of wake ups from Facebook and Plume (touiteur), but I'm not going to disable either of these, so I'll have to live with it. Other than that, I'm trying to optimize everything else I can.

Is it reasonable for BMW to be causing such a dramatic change with 1 minute logging vs 10? The developer says that even frequent wakelocks should be quick, and shouldn't take very much CPU total (I know this is not a BMW support thread, but it seems like a popular app, and I'm hoping someone has some experience)

What are all the kernel wakelocks such as event0-1986, etc?

Can someone explain how to read the alarms information? In the first dump, for example, I have the following:

Wakelocks
AlarmManager (Android System): 4 m 6 s (246 s) Count:5127 1.2%
...
Kernel Wakelocks
"alarm" (): 15 m 47 s (947 s) Cnt: (c/wc/ec)7054/30/0 4.4%

And then under alarms, I have each app listed with a count of wakeups.

How come the time spent in the kernel alarm doesn't equal AlarmManager? Which is significant? And why are both counts much greater than the sum of what's listed in the Alarms section?

Thanks in advance.
[BetterBatteryStats] bsoplinger:
This and you post right before it lead me to believe that as much as I like maps for lookup and finding out where things are vs. driving directions if I'm on wifi more often than 3G I don't really have a choice if I want decent battery life I must freeze maps. Did I get that right?

I've already moved to ALTitude, which is great btw, but still see my battery dropping at an alarming rate.

Sent from my Kindle Fire using Xparent Purple Tapatalk 2
[BetterBatteryStats] burdman:
Looks like this thread is related to the github post

http://xdaforums.com/showthread.php?t=1646883
[BetterBatteryStats] chamonix:
BMW ist, as you said yourself, the main cause of awake. I must disagree with the fact that waking your phone every minute does not cause an overhead. Compare it to let the engine of a car run for 5 minutes compared to start and stop it every 10 seconds for 10 minutes. The time the engine would be on is in both cases the same for the consumption will not.

That's the cost of active monitoring and has nothing to do with cpu cycles.

Besides that I see twitter (as you also have) as well as facebook (bloatware).

Not to your question about the count of AlarmManager compared to the alarms: AlarmManager is a wakelock that is held every time an alarm is added or deleted. First wakeups are not caused by all alarms as some of them will only be fired when the phone is awake. Also some may be get added but finally deleted before they fire. If you look at 'dumpsys alarm' you will notice that some apps add dozens of alarms scheduled at almost the same time. It's hard to tell what is the goal of doing so without having the sources but I have noticed a dramatic increase of those since ICS.
[BetterBatteryStats] chamonix:
I don't like the evolution of maps in that area either and am not ready to pay for google collection wifi data at the costs of my battery life. But that is only my opinion, everybody should find out what is worth running by himself
[BetterBatteryStats] chamonix:
I know latify and am also working on a feature to optionally buffer locations and withhold them till wifi is available.
[BetterBatteryStats] Karpfenhai:
Hmmm, you can also play with maps :D

Means get autostarts from market and disable all maps related autostart activity.

This is my maps wakelock after 2 days including actual usage of maps!

So there is no need to get rid of maps, you only need to tell the app how to behave,:) good luck!

Tapatalked from my Samsung GT9100
[BetterBatteryStats] chamonix:
No this is ironic. I finally installed MIUI on my Nexus S in order to start debugging the problem with not responding "batteryinfo" service and guess what?

I am not able to reproduce the problem.

I'd be very grateful if anyone could point to to a Nexus S ROM where BBS fails to communicate with that service
[BetterBatteryStats] Karpfenhai:
Lol, lucky you! Or in that case bad luck..

Enjoy your Sunday!

Tapatalked from my Samsung GT9100
[BetterBatteryStats] mikeage:
Fair enough. I didn't realize the time (or more importantly, energy) required to exit standby was particularly high, but as nothing else appears to be different, I guess it must be.

Got it. Thanks for the explanation.

In the first dump I posted, the phone was awake for 29 minutes out of just under six hours (screen on < 30s). That seems like an awful lot.

===========
Other Usage
===========
Deep Sleep (): 5 h 26 m 14 s (19574 s) Ratio: 91.8%
Awake (): 29 m 4 s (1744 s) Ratio: 8.2%
Screen On (): 27 s (27 s) Ratio: 0.1%

I figure facebook is probably to blame for a lot of this, but I'm not sure I see how. All of the partial wakelocks sum to less than five minutes

=========
Wakelocks
=========
AlarmManager (Android System): 4 m 6 s (246 s) Count:5127 1.2%
FacebookService (com.facebook.katana.Facebook): 5 s (5 s) Count:22 0.0%
AlarmReceiver (com.sec.android.app.clockpackage.Clock): 4 s (4 s) Count:2 0.0%
LockerService (com.teslacoilsw.widgetlocker.WidgetLocker): 3 s (3 s) Count:1 0.0%
ActivityManager-Launch (Android System): 2 s (2 s) Count:5131 0.0%
Event Log Service (Google Services): 1 s (1 s) Count:12 0.0%
sleep_broadcast (Android System): 1 s (1 s) Count:3 0.0%
RILJ (Phone): 1 s (1 s) Count:141 0.0%

And the kernel wakelocks are way more than 30 minutes. Am I correct in assuming that it is possible for two or more kernel wakelocks to be active at the same time, and the time shown is wall time, not CPU time?

================
Kernel Wakelocks
================
"alarm" (): 15 m 47 s (947 s) Cnt:(c/wc/ec)7054/30/0 4.4%
"event3-1986" (): 8 m 54 s (534 s) Cnt:(c/wc/ec)978/0/0 2.5%
"event1-1986" (): 8 m 34 s (514 s) Cnt:(c/wc/ec)929/1/0 2.4%
"event0-1986" (): 8 m 34 s (514 s) Cnt:(c/wc/ec)927/0/0 2.4%
"event2-1986" (): 8 m 34 s (514 s) Cnt:(c/wc/ec)969/0/0 2.4%
...

How can I determinte what these event*-1986's are?

And lastly, what is "Cnt:(c/wc/ec)"?
[BetterBatteryStats] xelra:
That would be your second greatest achievement. After creating BBS, of course! :D
[BetterBatteryStats] Karpfenhai:
hmm, that's an easy one, i bet if you disable Bluetooth, your device will sleep like a baby!

The problem is, as soon as a Bluetooth connection is established, the phone will stay awake and running at lowest CPU level.

So, it seems , whether known our unknown, your device holds a permanent Bluetooth connection active.

Problem should be solved by disabling Bluetooth.

Good luck and please report back, thx.

Tapatalked from my Samsung GT9100
[BetterBatteryStats] bsoplinger:
Did you turn off everything maps does in terms of auto starts or only select items?

Sent from my Kindle Fire using Xparent Purple Tapatalk 2
[BetterBatteryStats] o0boiboi0o:
Does anyone know how to disable C2DM service? The reason why i asked this is bcos I think I accidentally did sth wrong and C2DM service stop working. Hence my whatsapp is having problem pushing messages thru. :(
[BetterBatteryStats] diamondpillow:
my l2_hsic findings

hey guys,

I found out smth else this morning, maybe some others have already found out too. Nevertheless I will share with you first, before confirming my result

1. Go to settings

2. go to Wi-fi

3. press your menu button (lower left capacitive button)

4. press advanced (thats the only choice that pops up)

5. under "Keep Wi-Fi on during sleep" -> choose

never

6. Restart your phone.

as before, it was kept as "

always

" and I am thinking it caused the l2_hsic issue that prevents my phone from sleeping.

As of now, after 30 mins, l2_hsic is only 2m awake. The change might be due to the reboot, I am not sure. I will report back in 2 days.

Previously, I reseted back to factory setting, it didnt appear before the first charge, so I shld see what happens after the first charge

I've also tried using juice defender to narrow down the app (disabling app for connectivity when slp), but it seems to me its not an app, but rather the settings, or the modem or router or possibly hardware issue

It shldnt be an app because i monitor my data usage, i didnt seem that there is an increasing data usage which suggest that with or without the wakelock the data usage is largely based on my own usage.

heres the link where I read further for layer 2 hsic

http://en.wikipedia.org/wiki/LAN_switching

please feel free to correct me and contribute to a plausible solution!
[BetterBatteryStats] Karpfenhai:
Yes i did!

Tapatalked from my Samsung GT9100
[BetterBatteryStats] ShannonAUT:
Thanks! Disabling Latitude helped quite a lot already and since I disabled the cloud backup it is even better. Thanks again.:-)
[BetterBatteryStats] grlagman:
Hello, is there anything that i can do to improve the battery life of the sii ?

Sii not rooted running the latest official ICS 4.0.3

Thank you.
[BetterBatteryStats] KJ98653:
Hey guys what's "DATA5" kernel wakelock? How do I go about reducing its impact? Thanks for advice in advance. ;P
[BetterBatteryStats] logrej:
After changing lot of roms and kernels battery drain stil here. It is draining 10%/h and deep sleep is only 6-7%. After using BBS I have noticed kernel wakelock sec-battery-monitor. That one goes to 5000-10000 wakelocks... What is that process? How to kill it? Tried all combinations with wifi on-off, data on-off, airplane mode, fresh rom without apps, GB roms, ICS roms, stock kernels, custom kernels...

So, what is that sec-battery-monitor?
[BetterBatteryStats] xelra:
It's battery monitor widget. Go into its settings and set the refresh interval to 10 minutes.
[BetterBatteryStats] logrej:
Thanks for answer, but I didn't installed batt widget. I have WanamLite ROM with no widgets (only lock screen widget ). Maybe that is from batt percent next to clock (that is installed with rom)? Can't find settings for that... And, I looked lot of BBS dump files from other users, and no one have that wakeloc. I have that even with stock ICS without any app installed (or widget).
[BetterBatteryStats] Karpfenhai:
Hey there, after some research i have 2 news for you, 1. you are not alon ewith this issue ;)

2. its not rom related, its kernel related, so you dont need to switch roms, switch kernel until its solved, some stock kernel are showing this behavior.

Go for speedmod / phenomenal kernel, simple and efficient, give it a try!
[BetterBatteryStats] sgtpepper12:
ICS Battery Drain

hi,

I posted in this thread a few weeks ago but since I got no reply I'm trying it again: could someone please have a look at my batterystats, ever since upgrading to ICS I got a really bad battery life, with (imo) the same settings compared to GB. BetterBatteryStats says lists that I have "no or unkown signal" most of the time even though I've got a very good signal most of the time.

thanks
[BetterBatteryStats] logrej:
I have tried lot of kernels. Will try speedmod again... And some other kernels...
[BetterBatteryStats] Karpfenhai:
...and, dont forget to post an idle dump (4-6 hours or overnight) to analyze the real drain, maybe you are just to obsessed ;)

Switch to a battery friendly baseband (K13 / Ki4), reduce screen brightness (needless for idle dump).

Good luck!

---------- Post added at 01:20 PM ---------- Previous post was at 01:17 PM ----------

Mate, 1. thats not an idle dump its impossible to see the overhead in it!

2. No or unknown signal is a small bug in BBS, the developer is aware of this and will fix it in a timely manner.

3. read the thread with care, probably all known questions have been answered several times already ;)

Come back with an fresh IDLE dump, good luck!
[BetterBatteryStats] logrej:
Thanks for answer. Will give dump file with new kernel in few hours. Here is my old dump file, just to see that there is problem...
[BetterBatteryStats] Karpfenhai:
Yes, i have seen this dump before but im not experienced enough to give you an reliable statement on this, the only thing i wonder is the multidpd wakelock, could you switch to 2g only or flightmode for a while?

The sec battery thing is really odd, since it is the inbuilt android battery monitor, maybe you are suffering on the classic "Android OS" Bug?

I heard, taking out a fully charged battery for 10 mins should work wonders, i normally dont believe in such voodoo but it costs you nothing to have a try..;)
[BetterBatteryStats] logrej:
Newest info is: After 10 min on Speedmod kernel and KI3 baseband there is 8% of deep sleep. I always use only GSM network. I enable 3G only when surfing without WiFi coverage.

And there is always Android OS as top batt consumer.

Will try that "10 min battery out" voodoo...
[BetterBatteryStats] ditya:
After the latest busybox update, the battery has started draining a lot. And somehow BBS is also not working after that. Keeps 'computing' for a very long time..

Anyone experiencing similar problems?
[BetterBatteryStats] bsoplinger:
I know there are issues with some 20.1 versions of busybox. Try dropping back to a 19.4 version or using a different source if you must have 20.1.

Sent from my Sprint Evo View 4G (PG41200) using Xparent Purple Tapatalk 2
[BetterBatteryStats] chamonix:
That's a sign of bad data connection preventing the retrieval of the kb cache in a timely manner
[BetterBatteryStats] chamonix:
That is an absurd conclusion. Busybox is neither a daemon not a service so there is now way in he'll it could drain or be a cause of drain.

Be objective: take readings and analyze logs
[BetterBatteryStats] ditya:
I am not concluding.. That was the only change in my previously known good state and the draining state so i thought to quickly check if anyone else is experiencing same problems. Moreover i couldnt get BBS working to know the cause of the drain. Now that i am back from work I can get the logs. I will post them here if i cant figure out the issue.
[BetterBatteryStats] gpz1100:
Finally had a chance to get a somewhat lengthy sample of data.

60% battery remaining at this point.

http://db.tt/KYHA75z5 BBS dump log

From what I can tell, about 23 minutes of actual partial wakelock time.

For ease of readability, i've embedded the wakelock sorted by counts.

All of these have relatively high counts, but appear to be system services. I have 1 email account set up with imap push, google calendar & contact sync.

Anything in particular jumps out in the attached log?
[BetterBatteryStats] durangatang:
Has anyone seen these kernel wakelocks before:

event0-1934

event1-1934

event2-1934

event3-1934

I did a search on this thread and found nothing, also did a Google search and nothing.

I am on NEAT ROM LPF, SpeedMOD K3-20, ICS Domination 4.4, no UV, no OC, no other tweaks.

Any information anyone has would be great.
[BetterBatteryStats] p107r0:
it may be fault on the ICS itself - similar to situation with ICS for Note - first official versions used to have terrible and unstable battery consumption compared to GB, the latest one seems to behave properly
[BetterBatteryStats] logrej:
So, here it is. I wiped cache, dalvik, factory reset, cleaned kernel with cleaning tool,.. Then installed stock ROM for my country, then cf-kernel, and then Ki4 modem and Abyss kernel. Installed BBS, and then entered my google account (so there is also sync in dump file)... None widget on the screen. Had few phonecalls and SMS.

I think it started logging with about 90% battery.

Anything fixable?
[BetterBatteryStats] Karpfenhai:
Man, you aren't really a lucky guy :(

The reason for the drain is clear, your phone runs at 500 all the time, unfortunately the dump does not show the cause, maybe chamonix is able to improve it in future version of bbs.

So let's digg deeper into your OS:

If you do a ps |grep 1986

You will figure out that it is the Android system server process.

I will do some research later on this.

Do a ps | grep battery on a console (terminal emulator) and note the pid of the sec-battery process (the 4 digit right after root)

Then kill it --> kill -9 "pid"

This should stop the drain, and maybe the battery display too:p

I'm pretty sure the process will respawn anyway butt maybe it will behave then.

Please report if your phone enters deepsleep after this measure.

Now researching system server drain causes.

Good luck mate!

Update: all traces so fat are pointing to carrier iq as the main reason but youare from Serbia so i would exclude this...

Can you try another carriers Sim on this particular device? Also, take out your sd-card for a while.

...still investigating...

Tapatalked from my Samsung GT9100
[BetterBatteryStats] gaui:
I would recommend you to try a different ROM.

Try this one:

http://xdaforums.com/showthread.php?t=1403044

Keep kernel that comes with the ROM + the modem that comes with the ROM.

Then report in. Good luck mate. ;)
[BetterBatteryStats] Karpfenhai:
Okay we go further, let's do the following:

Open a terminal (switch to root)

Enter this command:

top >process.txt

Wait approx 20 seconds

Interrupt command with control + c (Vol down + c)

open the new file (process.txt) and paste the upper 30 lines here, should look like this:

User 4%, System 3%, IOW 0%, IRQ 0%
User 14 + Nice 0 + Sys 11 + Idle 285 + IOW 1 + IRQ 0 + SIRQ 0 = 311

PID PR CPU% S #THR VSS RSS PCY UID Name
13712 0 7% R 1 1020K 420K fg root top
6949 0 3% R 19 304956K 65744K bg app_252 com.quoord.tapatalkpro.activity
1960 0 1% S 94 412432K 66268K fg system system_server
12904 0 0% S 11 280760K 28160K bg app_152 com.sp.protector.free
13533 0 0% S 11 281188K 30728K bg app_197 com.kebab.Llama
13192 0 0% S 1 0K 0K fg root kworker/0:1
13699 0 0% S 1 0K 0K fg root kworker/0:2
363 0 0% S 1 0K 0K fg root bdi-default
365 1 0% S 1 0K 0K fg root kblockd
378 0 0% S 1 0K 0K fg root khubd
414 0 0% S 1 0K 0K fg root irq/359-max8997
465 0 0% S 1 0K 0K fg root cfg80211
548 0 0% S 28 311192K 40524K bg app_19 android.process.media
569 0 0% S 1 0K 0K fg root kswapd0
571 0 0% S 1 0K 0K fg root fsnotify_mark
572 0 0% S 1 0K 0K fg root ecryptfs-kthrea
575 1 0% S 1 0K 0K fg root crypto
607 0 0% S 34 361512K 58916K bg app_276 com.anddoes.launcher
819 1 0% S 1 0K 0K fg root sec_jack_wq

This way you can see which process consumes your cpu.

For the geeks :D

Tapatalked from my Samsung GT9100