[REF] Known identified battery drainers

Search This thread

geomax45

Senior Member
Oct 25, 2011
459
100
Oregon
Considering what it costs, you might see if the Sonos software would let you exclude the phone (i.e. whitelist or blacklist IPs to send to) - if it's truly broadcasting through the router, you could see if the router could be set to filter those from going to the phone - my current router firmware won't do that, but I'm thinking of going to dd-wrt which should let me pick which packets to allow through.

Thanks for the idea, but it's my understanding that Sonos uses it's own wireless network. I will, however, check their website for a possible solution.

Sent from my GT-I9100 using xda premium
 

johnf440

Senior Member
Dec 10, 2010
68
25
St. Louis, MO
I was getting less than 8 hours per charge, so I downloaded Juice defender to shut my wireless off when screen is off. I changed the wireless settings to not turn off when screen is off in phone settings. I started getting 30 hours a charge. Unfortunately, the stock email app started going rogue and eating battery. Also burned my 3 gig plan up in 2 days. Needless to say, not using stock email app anymore and not on a stock rom.
 

chamonix

Recognized Contributor
Nov 7, 2008
5,048
19,623
Berlin
Google Pixel 6 Pro
Thank you chamonix. It's ironic that the data reporter app I downloaded to monitor wakelocks is the cause of more wakelocks, LOL.

Does this explain all the kernel wakelocks as well? MdmDataReporter had 12 minutes, but "deleted_wake_locks" and all those events account for much more time.

"deleted_wake_locks" (): 3 h 47 m 38 s (13658 s) Cnt:(c/wc/ec)58202/0/8266 57.4%
"event3-1997" (): 1 h 4 m 22 s (3862 s) Cnt:(c/wc/ec)6980/0/0 16.2%
"event0-1997" (): 56 m 41 s (3401 s) Cnt:(c/wc/ec)6114/0/0 14.3%
"event1-1997" (): 56 m 40 s (3400 s) Cnt:(c/wc/ec)6120/0/0 14.3%
"event2-1997" (): 56 m 40 s (3400 s) Cnt:(c/wc/ec)7146/0/0 14.3%
"sec-battery-monitor" (): 56 m 12 s (3372 s) Cnt:(c/wc/ec)6126/60/0 14.2%
"event7-1997" (): 31 m 41 s (1901 s) Cnt:(c/wc/ec)6986/0/0 8.0%
"alarm_rtc" (): 27 m 51 s (1671 s) Cnt:(c/wc/ec)1941/0/655 7.0%
"l2_hsic" (): 23 m 25 s (1405 s) Cnt:(c/wc/ec)7044/0/0 5.9%

It's hard to tell as there is no real mapping but the first on is definitely a side effect of that, at least for one part. Please post a dump 'after' so we can see if anything else comes up that may have been masked. Protip: when it comes to any kind of performance tuning 3 rounds or monitoring/tuning is a good habits to resolve 90% of the problem
 

patsmike

Senior Member
Dec 27, 2011
263
48
Boston, MA
Thank you chamonix. It's ironic that the data reporter app I downloaded to monitor wakelocks is the cause of more wakelocks, LOL.

Does this explain all the kernel wakelocks as well? MdmDataReporter had 12 minutes, but "deleted_wake_locks" and all those events account for much more time.

"deleted_wake_locks" (): 3 h 47 m 38 s (13658 s) Cnt:(c/wc/ec)58202/0/8266 57.4%
"event3-1997" (): 1 h 4 m 22 s (3862 s) Cnt:(c/wc/ec)6980/0/0 16.2%
"event0-1997" (): 56 m 41 s (3401 s) Cnt:(c/wc/ec)6114/0/0 14.3%
"event1-1997" (): 56 m 40 s (3400 s) Cnt:(c/wc/ec)6120/0/0 14.3%
"event2-1997" (): 56 m 40 s (3400 s) Cnt:(c/wc/ec)7146/0/0 14.3%
"sec-battery-monitor" (): 56 m 12 s (3372 s) Cnt:(c/wc/ec)6126/60/0 14.2%
"event7-1997" (): 31 m 41 s (1901 s) Cnt:(c/wc/ec)6986/0/0 8.0%
"alarm_rtc" (): 27 m 51 s (1671 s) Cnt:(c/wc/ec)1941/0/655 7.0%
"l2_hsic" (): 23 m 25 s (1405 s) Cnt:(c/wc/ec)7044/0/0 5.9%


This drain is DEFINATELY caused by your wireless network. I have the same exact problem at work (see attached pics - this was with my phone sleeping all but a couple minutes).
But, when on my wireless network at home, I have never ever seen this problem - I get 95-98% Deep sleep when on my home network.

I have seen this problem with my work wifi on every single ICS rom, from touchwiz to cm9... but I never saw this on Gingerbread. mzaur - is this the case for you too - only on ICS?

Unfortunately, I have no idea how to fix it, other than shutting off wifi. Anyone have other suggestions?

EDIT: I will try and post a full bbs dump next time i'm at work
 

Attachments

  • Screenshot_2012-04-03-16-44-09.jpg
    Screenshot_2012-04-03-16-44-09.jpg
    24.5 KB · Views: 335
  • Screenshot_2012-04-03-16-44-26.jpg
    Screenshot_2012-04-03-16-44-26.jpg
    35.3 KB · Views: 310
  • Screenshot_2012-04-03-16-44-52.jpg
    Screenshot_2012-04-03-16-44-52.jpg
    30.6 KB · Views: 315
  • Screenshot_2012-04-03-16-45-01.jpg
    Screenshot_2012-04-03-16-45-01.jpg
    30.2 KB · Views: 305
  • Screenshot_2012-04-03-16-45-09.jpg
    Screenshot_2012-04-03-16-45-09.jpg
    30.3 KB · Views: 282
Last edited:

patsmike

Senior Member
Dec 27, 2011
263
48
Boston, MA
I was surprised too (especially by things like Windows Media constantly trying to broadcast when I don't use it) but I used Wireshark to get who was calling and then tracked them down.

Wow this is pretty amazing - so the only thing that was causing the problem was the computer on the network? I would have never thought that other devices on a network could cause so many problems.

So did you end up messing with your router to lower the activity going to your phone, or were all the optimizations directly on your computer? It's gonna be difficult for me to go on everyones computer at work and turn off network sharing haha... I guess that's what happens when a bunch of research scientists try and set up a wireless network :)
 

csetera

Senior Member
Feb 27, 2010
197
16
I just caught an interesting WLAN wake that was probably the cause of a huge battery drain I saw a couple of weeks ago that killed my phone over night. If you use a Macintosh and have ever used the ability with the Preview application to scan using a networked scanner, you may see this. I found that if I activate that function, it is sending out a huge number of multicast "discover" requests. I was seeing something less than 40% deep sleep numbers until I figured it out and killed Preview.

Preview itself is fine, but if you use a networked scanner make sure to quit Preview after you are done to shut down the multicast discovery.
 

gaui

Senior Member
Jan 9, 2011
752
183
Reykjavik
Great thread, thank you for it!

But lately I have been noticing this wakelock:

Alarms: 273, Intent: com.android.internal.telephony.gprs-data-stall

I have never enabled data connection. Only WiFi

Any ideas?
 

alacrify

Senior Member
Jan 12, 2009
3,437
1,903
Great thread, thank you for it!

But lately I have been noticing this wakelock:

Alarms: 273, Intent: com.android.internal.telephony.gprs-data-stall

I have never enabled data connection. Only WiFi

Any ideas?

It's being reported a lot (mine has it too) - apparently it's a CM9/AOKP bug at this point...

EDIT: actually, since loading Task's build 32 this afternoon, I haven't had this yet...I'm still getting RILJ, GTALK_CONN, and some other stuff I can't figure out that's probably connected.
 
Last edited:
  • Like
Reactions: gaui

squigge

Member
Mar 1, 2011
20
2
squigge.com
I've been seeing better battery results when I switched from CM9 to AOKP. However it still isn't as good as I was getting with CM7 or UnNamed. I'm seeing a lot of partial wakelocks from AudioOut_1. Does anyone know what that is? I'm not using headphones or anything like that, and only occasionally is the phone not on vibrate.
 

gaui

Senior Member
Jan 9, 2011
752
183
Reykjavik
Guys, please help me. I have been having trouble with drains for a very long time. I'm really exhausted, really thinking about uninstalling all apps, start from scratch and install only one app by one. But that would take a REALLY long time.

I'm running a custom ROM (HyDrOG3N-ICS) and Siyah kernel (latest). This has nothing/little to do with that, because I've tried several other ROMs/kernels. Always the same/similiar problem. Also other users are experiencing great battery life with these two.

No CPU/GPU undervolt going on. I use the ondemand governor.
I have a "Screen off" profile that sets the CPU max_freq to 200 MHz.
I have a "Screen on" profile that sets the CPU max_freq to 1000 MHz and min_freq to 200 MHz.

I have tried to turn off WiFi, it didn't change much.

I have only sync on Gmail, calendar and contacts.

I have seen gprs.data-stall wakelock a lot lately. Even though I have mobile data disabled at all times.

I have GTALK_ASYNC_CONN wakelocks even though I froze Talk app with TiBU.

I did a cat /proc/wakelocks > wakelocks.txt and put it into a PDF in the attachments.

In attachments are also my WireShark and dmesg and BBS dumps

BBS dump in attachment not working, here it is: http://pastebin.com/W3iAw5Ui

192.168.1.20 is my phone.
I filtered the WireShark dump with this:
ip.src == 192.168.1.20 || ip.dst == 192.168.1.20
Because I was getting a lot of other network data.

Here are some screenshots:
http://imgur.com/a/cyhSO

As you can probably see in wakelocks.pdf battery-sec-monitor is getting very high wake_count. Don't know what that is.

PLEASE help me get to the bottom of this. :)
 

Attachments

  • dmesg.txt
    256 KB · Views: 6
  • shark_dump_1334636429_filtered.pcap.txt
    4.9 KB · Views: 5
  • wakelocks.pdf
    55.1 KB · Views: 15
  • BetterBatteryStats-2012-04-17_001036372.txt
    4.5 KB · Views: 14
Last edited:

mzaur

Senior Member
Nov 13, 2011
575
58
NJ
The BBS log you posted isn't working. Says 404 page not found... Repost a working BBS log. The best ones are where you unplug at night and then leave your phone overnight untouched, and then save log in the morning before doing anything else.
 
Last edited:

Thor_BR

Senior Member
Aug 14, 2010
78
9
Calgary
WiFi battery drain

Hi Folks,
I've been facing a huge battery drain, caused by my wifi. I don't have a cheap-ass router (dlink dir-655) and my CPU-SPY looks like this:
500MHz - 28%
200MHz - 32%
DS - 25%

Checking the BBS, I don't see any problems with Kernel/Partial Wakelocks. But when I check "Other", it gives me 100% wifi on.
Based on that, I installed the shark file suggested, and after running it for quite some time, the only thing I got (besides NULL) was "RAW". I'm running the CM9 nightly 14/04, with XXLPS modem.

With wifi off, I have an excellent battery life.

Any suggestions?
 
Last edited:

alacrify

Senior Member
Jan 12, 2009
3,437
1,903
Hi Folks,
I've been facing a huge battery drain, caused by my wifi. I don't have a cheap-ass router (dlink dir-655) and my CPU-SPY looks like this:
500MHz - 28%
200MHz - 32%
DS - 25%

Checking the BBS, I don't see any problems with Kernel/Partial Wakelocks. But when I check "Other", it gives me 100% wifi on.
Based on that, I installed the shark file suggested, and after running it for quite some time, the only thing I got (besides NULL) was "RAW". I'm running the CM9 nightly 14/04, with XXLPS modem.

With wifi off, I have an excellent battery life.

Any suggestions?

Let shark run for 15-20 minutes, and post the Pcap log here (check the thread for options to set) - let someone who can read it better than I can chime in. You may be getting a lot of polling from your network that's keeping it awake.
 

selw0nk

Senior Member
Apr 13, 2012
1,337
357
You can turn off data and turn off sync to save battery life. Only turn it back only when you need it.
 

alacrify

Senior Member
Jan 12, 2009
3,437
1,903
You can turn off data and turn off sync to save battery life. Only turn it back only when you need it.

You really shouldn't have to - when my phone is tweaked properly on a stable ROM, I lost ~1% an hour idle. With normal use, I get a day and a half off the charger. It does take some effort to track down the issues, but it's worth it.
 

Entropy512

Senior Recognized Developer
Aug 31, 2007
14,088
25,086
Owego, NY
You really shouldn't have to - when my phone is tweaked properly on a stable ROM, I lost ~1% an hour idle. With normal use, I get a day and a half off the charger. It does take some effort to track down the issues, but it's worth it.

For me, 1%/hour idle is high except when on weak signal - and since ICS I've cracked the 1% threshold even at my desk.
 

alacrify

Senior Member
Jan 12, 2009
3,437
1,903
For me, 1%/hour idle is high except when on weak signal - and since ICS I've cracked the 1% threshold even at my desk.

You're an exceptional example though - I'm not running my own ROM, no tweaks at all, no SetCPU even right now. Just a solid ROM with your kernel input and debloating by not loading bad apps :)
 

Thor_BR

Senior Member
Aug 14, 2010
78
9
Calgary
Pcap attached

Hey Folks,
Here's the pcap. The app crashes if I leave it for 30 min.

Any help is appreciated!
 

Attachments

  • shark_dump_1334726336.zip
    2.2 KB · Views: 3

Top Liked Posts

  • There are no posts matching your filters.
  • 73
    In many cases, people who have battery drain issues have a tendency to end up being found to be using a known battery draining app or configuration. To help these people, I'm going to try to start a list here. I will, in the case of known rogue apps, include the reporting date so people can try updates to see if drain is fixed. (For example, Facebook is rarely a culprit any more, but it was the #1 most common battery eater in 2010.) The primary focus here will be things that shouldn't drain your battery but do.

    Firmware bugs:
    1. The UCKK6 OTA update contains a number of issues with wifi and bluetooth. Among these is that an oddball feature of our Wifi/Bluetooth chipset goes nuts and wakes up the phone once per second intermittently. Rebooting temporarily fixes it, turning off wifi temporarily fixes it, only permanent fix is to ditch UCKK6. http://xdaforums.com/showthread.php?t=1409513 for more details - Appears as a variant of the Android OS "bug" - this is the only one that is actually 100% a firmware bug. International XWKK5 is also affected.

    LAN Environment (WiFi):
    • Broadcast LAN traffic can wake your wifi chip often. This also manifests as the Android OS "bug", but it's a small problem with the firmware base (XXKI3 and UCKK6 are known to be affected) and mostly a network problem. Examples I've seen so far include:
      • Windows Client Backup
      • UPnP (DLNA) SSDP
      • Dropbox Lan Sync Discovery Protocol
      • Buggy piece-of-**** routers that spam lots of ARP requests continuously - The 2Wire routers that are required for UVerse access apparently fit in this category.
    You are more likely to have the above issue on some firmware bases than others. For example, XXKI3 disables all of the chip's packet filters, making it vulnerable to this sort of thing. UCKH7 and XWKL1 don't, leading to significantly improved life on "dirty" networks. UCKK6 almost surely also has the same problem.

    Configuration issues:
    1. Hotmail calendar sync
    2. Misconfigured Microsoft Exchange servers - 1) is a special case of this. At least one person has reported that calendar sync to a non-Hotmail account was problematic for them, but email sync was OK
    3. A bad Exchange configuration - the client apparently goes nuts if it can't contact the server
    4. BLN - On Galaxy S II devices, there is no stable BLN implementation that does not hold a wakelock when a notification is active. This means that an active BLN notification will drain about 4-5%/hour. I say this in bold letters in my kernel thread, but somehow people still don't realize it...

    Rogue apps:
    1. Words with Friends (October 2011)
    2. Skype (October 2011) - Particularly insidious, as it does not directly hold a wakelock. However, it causes lots of background network activity, and this activity keeps your phone awake. Since most of the time is spent wakelocked in the network stack, Skype drain shows as Android OS.
    3. Any IM app that works similarly to Skype is likely to have the same issues.
    4. AP Mobile Widget on stock AT&T ROMs - this one also blows through your data allotment quickly if you don't have unlimited data
    5. AT&T Smart WiFi can sometimes hold excessive wakelocks - this is why AT&T bloat is bad for you.

    The Obvious:
    1. 3D or animation/action-intensive games

    The Rare:
    Apps that occasionally go nuts, but not frequently
    1. Facebook - I've had it wakelock me once, and also, Facebook chat may have triggered my first obvious "AOS bug" episode once - so far, it's been responsible for drain once this month
    2. StartingAlertService - some sort of Calendar notification related bug

    The False Blame:
    1. GPS Status and Toolbox - may appear to be high-drain but is actually not draining - this is an Android battery reporting bug - see http://xdaforums.com/showpost.php?p=23106668&postcount=491 for more details. Thank you for the info and the great app rhornig.

    If you're having battery drain issues, I suggest the following:
    1. Install BetterBatteryStats. The XDA edition from the author's thread on these forums is free. (Market version is paid.)
    2. Also, having CPUSpy to see deep sleep percentages is VERY useful
    3. BBS now shows kernel wakelocks - make sure to check these. If you have an older version that doesn't show kernel wakelocks, use the instructions below.

    Get ADB up and running (Google it, and if you're on Windows, Googling Droid Explorer may help)
    Using ADB, do the following:
    Code:
    adb shell cat /proc/wakelocks > wakelocks.txt
    adb shell dmesg > dmesg.txt
    Zip em' up and post em' here for analysis.

    Edit: Specifically, to get a good baseline measurement of idle drain - make sure to have CPUSpy installed for this procedure:
    Charge phone to full
    Reboot
    Reset timers in CPUSpy, otherwise the percentages and bars will be wacky
    Let the phone sit for a while - Overnight is best. Then provide data:

    Deep sleep percentage
    Time the phone was sitting
    Percentage battery drained
    I don't need screenshots of the above, just the numbers. Screenshots use up massive amounts of thread space
    Grab /proc/wakelocks as mentioned above and post it, OR use BetterBatteryStats 1.4 or above to pull kernel wakelocks.

    Note: If you're at or below 1%/hour idle drain, not much point of posting your wakelocks.

    If you have high wlan_wake, wlan_rx_wake, or svnet-dormancy wakelock times, then you have an app eating data or one of the wifi wakeup bugs described above. Install Shark for Root - https://market.android.com/details?id=lv.n3o.shark

    Start it, and change parameters from:
    Code:
    -vv -s 0
    to
    Code:
    -vv -s 68
    This tells it to only capture the first 68 bytes of each packet, which is all we need for this purpose. This provides two benefits: A smaller capture, and privacy for you. (It captures packet headers but not contents)
    Then start a capture and let it sit for a bit.

    Note that your drain will be higher during the capture than normal - we're collecting data here, not directly nuking the drain.

    After a while where you are positive you are encountering drain, stop Shark and then pull the .pcap file - load it in Wireshark on your PC or post it here. If you post it here, MAKE SURE you have a truncated capture as instructed above!
    10
    I just confirmed - multipdp is the new name for svnet-dormancy - same 6000ms wakelock timer.
    6
    GPS Status and Toolbox - battery usage

    Hi all,

    I'm the author of GPS Status and Toolbox mentioned also on the first post.

    I'm receiving several complaints about the battery issue and investigated the reports, because GPS Status was designed explicitly NOT to run in background. It does not have services, alarms, does not start at boot. In fact once you close it, it cannot be activated without user interaction.

    Also it was strange people were reporting excessive use when they have not used the app at all. Here are my findings:

    It seems that the battery measurement routines are buggy in android (ICS still has this bug). The battery measurement service registers when an app starts using a sensor, but sometimes forgets to unregister this when the app releases it. (even if you kill the app's process). When the battery use is displayed the battery screen calculates the battery use by adding up the different ways a program can consume the battery (CPU, GPS, network radio use, and sensor use). The sensor use is basically calculated by subtracting the last sensor start value from the current time and the difference is multiplied by the sensors power requirement (per second). Because the system does not de-registers the sensor use correctly some programs are treated as using the sensors while in fact they are not even existing as a running process. As time passes this 'phantom' battery use grows even relative to the rest of the system's power use.

    In short this means that when the device is in sleep mode and consumes almost no battery, the calculation assumes that the sensors are still running. This results in increasing battery use reports for apps that use sensors.

    This does not happen always, but I was able to reproduce it with practically any app that uses several sensors. The effect is most visible on Samsung phones because I guess samsung assigns higher power requirement values for the ensors than other vendors.

    Long story short, DO NOT trust the battery usage display. It may give you an indication, but it is just a guess. (however seeing the code, the CPU usage statistics seems to come from the kernel so they are much more reliable).

    As a rule of thumb, higher battery use should come with higher CPU use. If you see high battery use for a task that hast consumed only low amount of CPU then chances are that the battery use is not correctly displayed.

    Hope this helps
    6
    I'm one of those people that really encourages people to search and try to help themselves. I'm probably even more sarcastic about it than most (though not in a mean way... just in a sarcastic way ;))

    However, the link you just posted was WORSE than useless. Unless a person is familiar with both the linux kernel AND the modifications android makes to the kernel, a link to a source file from the kernel does what? It will only create more questions.

    Even someone that is familiar with the kernel and android, and even an expert in C, would get questions from that link...

    Here's what I got from that source file: There's a symbol exported from the kernel (available to modules, etc) that allows both kernel and non-kernel code to call "destroy_wake_lock()" and if that happens, the stats on the destroyed wake lock are added in to some global "deleted_wake_locks" structure.

    This doesn't make clear if the kernel deleted_wake_locks structure is the same thing as displayed in BBS. It also, perhaps misleadingly, implies that every single wakelock in the system is eventually destroyed and all the time for those old wakelocks is added to the deleted_wake_locks. That would, in turn, lead logically to the question of "so if GPS is causing a wakelock, then I turn off the GPS, does the time for that wakelock show up as a GPS wakelock, in deleted wakelocks, both or neither?" We might even get people assuming that BBS wakelock stats are useless, as all the wakelocks have to eventually get destroyed, and if they do, their stats will just get dumped into this huge meaningless "deleted" pool.

    (Of course, I have the ability to dig deeper into this and find the answers - but most people don't. Even most of the people who develop for android are NOT proficient in C and kernel issues.)

    So... was that link supposed to be some kind of answer, or something to encourage more questions?

    :)

    Gary
    4
    ok, so I did try this to an extent, i would disable 4 apps at a time for the most part, only apps, none of the red items like wifi manager and stuff like that (even though i did try that at a different date)

    I had no success.. I went back to stock, uninstalled all bloatware, at&t live TV, my account, bar scanner, all that bs, right now I have BBS, Cpu Spy and titanium, only apps that are not stock and are in the list of installed apps. I am still getting this issue!! could it be that I have poor service (though this never affected the iphone this badly) I lose 40% overnight though and it seems odd to me that would be because of low service..
    Doesn't look like low service - you were on wifi, so data was going over wifi.

    Top three wakelocks were wlan_rx_wake, svnet, and mmc_delayed_work

    wlan_rx_wake is a dead ringer for network traffic. This wakelock happens when your phone receives a network packet addressed to it and it's asleep. So incoming network traffic is waking your phone often.
    svnet is unusually high - usually this is fairly low, as it's basic radio management stuff (Edit: low service MIGHT have driven this one up)
    svnet-dormancy is almost nonexistent - this is what you will usually see when an app is driving network traffic via cell data
    mmc_delayed_work is new to me, but I'm 90% certain that it is due to some app reading/writing to storage

    Nailing your culprit might need a network capture - I'm going to work on a tutorial for using Shark for Root ( https://market.android.com/details?id=lv.n3o.shark ) in a day or two.

    BTW, to analyze the /proc/wakelocks dumps:
    Open in Excel or OpenOffice/LibreOffice Calc
    Import as tab-delimited text
    Add a new column called sleep_time_minutes
    Set this column to equal sleep_time divided by 60e9 - this converts nanoseconds to minutes
    Sort by sleep_time_minutes