[REF] Known identified battery drainers
- Thread starter Entropy512
- Start date
Yeah, I guess I don't need to know scores that bad... it would be nice if it didn't eat battery though.
Sent from my SGH-I777 using Tapatalk
It depends on how often you are using your phone...if you don't touch it for eight hours the deep sleep should be high 90's. If you use it constantly until the battery dies then obviously your deep sleep percentage would be way different
Sent from my SGH-I777 using XDA App
I searched this thread and didn't see anything about this... but Heywire seems to be annihilating my battery lately... It was the top thing on my battery usage list, about equal with display which had 1 hour of "time on." That seems extremely excessive to me. I would gladly run a "wire shark" if I knew what it was or how to do it, the only time I've ever heard of it was on the "horrible battery life" Entropy kept telling people do them.
I'm starting to use more bookmarks for things like sports scores, stock quotes, etc.
No battery drain whatsoever...
Searching is good
- https://market.android.com/details?...esult#?t=W251bGwsMSwxLDEsImx2Lm4zby5zaGFyayJd - there's also a version/viewer for the desktop at http://www.wireshark.org/The Wireshark techniques are primarily for those seeing excessively high Android OS percentages.
If an app is high on the list - that's pretty obvious and you don't need to do much more than nuke it and see if things improve.
If an app is high on the list - that's pretty obvious and you don't need to do much more than nuke it and see if things improve.
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
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
Thanks for the info - I must admit, I hadn't had time to investigate, but I had started noticing strange and inconsistent behavior. In one case I'm fairly certain the battery WAS draining and a wakelock was in play (deep sleep was being inhibited) - in other cases I think it was a red herring and it was an indirect relation (GPS usage sometimes caused another power management bug to trigger), and you've now confirmed that in many cases it's just a reporting bug. I'm moving this into a new "You think you've got drain but you don't" category.
Thanks for the great app by the way. It's always one of the first items I ever install.
Also, higher battery use doesn't always come with high CPU use - some notorious drainers (such as Facebook) hold wakelocks - very little CPU but still a significant contributor to drain. ICS makes some major improvements to wakelock accounting though.
Last edited:
Thanks for the thread. It's really useful. One more comment: The battery reporting bug related to sensors cannot survive a reboot. If you suspect that this bug is at play, just reboot the device and your reported usage will return to normal. (i.e. this is related to somehow to stale data in memory)
I think some of the bogus data will remain (e.g. the app will be mis-blamed for consumption prior to the reboot) - but continued accumulation of bogus data will stop.
Of course, charging to full will clear it.
I know but it seemed very odd to me because that's the only time it's ever been anywhere near the top of my usage list, and there were no updates done to it or anything... I uninstalled and reinstalled, problem seems to be gone now.
Thanks for the info and thanks for the awesome app. As Entropy said, always one of the first to get installed.
Hi,
Please help with my battery drains. I did like in the instruction: charging to full, restart and reset CPUSpy statistics. The phone was lying unused for 6.5 h.
Battery Drain from 100% to 65%
Deep Sleep 38%
200MHz 36%
500MHz 8%
800MHz 16%
I use stock XWLA4 rom with Siyah 2.6.7 kernel.
MODEM XXKI4
GPS off
BT off
Here are my BBS, wakelock, dmesg and Shark dump.
Thank you for any help.
Please help with my battery drains. I did like in the instruction: charging to full, restart and reset CPUSpy statistics. The phone was lying unused for 6.5 h.
Battery Drain from 100% to 65%
Deep Sleep 38%
200MHz 36%
500MHz 8%
800MHz 16%
I use stock XWLA4 rom with Siyah 2.6.7 kernel.
MODEM XXKI4
GPS off
BT off
Here are my BBS, wakelock, dmesg and Shark dump.
Thank you for any help.
Just thought about this... I'm not sure if it's still a problem on this phone like it was on my Infuse 4G. But samsung's bloatware has this service that runs called DRM Content on the I777. It was called OmaDRMconfig2.exe or something like that on my Infuse. It keeps the screen from every actually going into a sleep mode and it drains your battery really quickly, not as bad as the KK6 bug, but still pretty bad. Unrooted users can go to Settings>Applications>Running Services. Find the "service" I mentioned above and Stop it. Be aware that any time you reboot your phone it will restart itself again. Rooted users, you can use TiBu to freeze it.
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
73In 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:
- 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.
Configuration issues:
- Hotmail calendar sync
- 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
- A bad Exchange configuration - the client apparently goes nuts if it can't contact the server
- 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:
- Words with Friends (October 2011)
- 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.
- Any IM app that works similarly to Skype is likely to have the same issues.
- AP Mobile Widget on stock AT&T ROMs - this one also blows through your data allotment quickly if you don't have unlimited data
- AT&T Smart WiFi can sometimes hold excessive wakelocks - this is why AT&T bloat is bad for you.
The Obvious:
- 3D or animation/action-intensive games
The Rare:
Apps that occasionally go nuts, but not frequently
- 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
- StartingAlertService - some sort of Calendar notification related bug
The False Blame:
- 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:
- Install BetterBatteryStats. The XDA edition from the author's thread on these forums is free. (Market version is paid.)
- Also, having CPUSpy to see deep sleep percentages is VERY useful
- 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:
Zip em' up and post em' here for analysis.Code:adb shell cat /proc/wakelocks > wakelocks.txt adb shell dmesg > dmesg.txt
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:
toCode:-vv -s 0
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)Code:-vv -s 68
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!10I just confirmed - multipdp is the new name for svnet-dormancy - same 6000ms wakelock timer.6GPS 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 helps6
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?
Gary4
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
New posts
-
Question SAMSUNG S22 ULTRA NEED HELP PLZ!!!!!!!!!!!!!!!
- Latest: nguyenlucky
-
-
-
[OFFICIAL] LineageOS 21 for Amlogic GXL/GXM/G12*/SM1/NE Family Devices- Latest: Slimshady997