Attend XDA's Second Annual Developer Conference, XDA:DevCon 2014!
5,742,742 Members 37,563 Now Online
XDA Developers Android and Mobile Development Forum

[REF] Known identified battery drainers

Tip us?
 
rhornig
Old
#491  
Junior Member
Thanks Meter 12
Posts: 16
Join Date: Oct 2007
Location: Budapest
Default 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
The Following 5 Users Say Thank You to rhornig For This Useful Post: [ Click to Expand ]
 
rav4kar
Old
#492  
rav4kar's Avatar
Senior Member
Thanks Meter 526
Posts: 1,455
Join Date: Oct 2011
Location: Edison, NJ
Entropy,

fyi. this is same shark dump what I posted in DD Kernel thread
Attached Files
File Type: zip shark_dump_1330527085.zip - [Click for QR Code] (117.0 KB, 3 views)
AT&T Samsung Galaxy S4
**Wasting Food is a crime against humanity, Buy less Eat more. **
 
Entropy512
Old
(Last edited by Entropy512; 29th February 2012 at 05:57 PM.)
#493  
Senior Recognized Developer - OP
Thanks Meter 24127
Posts: 13,144
Join Date: Aug 2007
Location: Owego, NY

 
DONATE TO ME
Quote:
Originally Posted by rhornig View Post
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.
*so much sig updating needed*

My Github profile - Some Android stuff, some AVR stuff

An excellent post on "noobs vs. developers"

A few opinions on kernel development "good practices"

Note: I have chosen not to use XDA's "friends" feature - I will reject all incoming "friend" requests.

Code:
<MikeyMike01> Smali is a spawn of hell
<shoman94> ^^^ +!
Code:
<Entropy512> gotta be careful not to step on each other's work.  :)
<Bumble-Bee> thats true
<jerdog> compeete for donations
 
rhornig
Old
#494  
Junior Member
Thanks Meter 12
Posts: 16
Join Date: Oct 2007
Location: Budapest
Quote:
Originally Posted by Entropy512 View Post
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.
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)
 
Entropy512
Old
#495  
Senior Recognized Developer - OP
Thanks Meter 24127
Posts: 13,144
Join Date: Aug 2007
Location: Owego, NY

 
DONATE TO ME
Quote:
Originally Posted by rhornig View Post
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.
*so much sig updating needed*

My Github profile - Some Android stuff, some AVR stuff

An excellent post on "noobs vs. developers"

A few opinions on kernel development "good practices"

Note: I have chosen not to use XDA's "friends" feature - I will reject all incoming "friend" requests.

Code:
<MikeyMike01> Smali is a spawn of hell
<shoman94> ^^^ +!
Code:
<Entropy512> gotta be careful not to step on each other's work.  :)
<Bumble-Bee> thats true
<jerdog> compeete for donations
 
jhermit
Old
#496  
Senior Member
Thanks Meter 36
Posts: 193
Join Date: Feb 2011
+1 on ESPN being a horrible battery drainer

Sent from my SAMSUNG-SGH-I777 using Tapatalk
The Following User Says Thank You to jhermit For This Useful Post: [ Click to Expand ]
 
JustinW3
Old
#497  
Senior Member
Thanks Meter 46
Posts: 171
Join Date: Feb 2012
Quote:
Originally Posted by Entropy512 View Post
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.
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.
 
F1reEng1neRed
Old
#498  
F1reEng1neRed's Avatar
Senior Member
Thanks Meter 173
Posts: 592
Join Date: Feb 2011
Location: Honolulu, HI
Quote:
Originally Posted by rhornig View Post
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 and thanks for the awesome app. As Entropy said, always one of the first to get installed.
 
Bieniu
Old
#499  
Bieniu's Avatar
Member
Thanks Meter 19
Posts: 87
Join Date: Mar 2010
Location: Łowicz
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.
Attached Files
File Type: zip traces.zip - [Click for QR Code] (125.9 KB, 3 views)
Sorry for my english.
 
JustinW3
Old
#500  
Senior Member
Thanks Meter 46
Posts: 171
Join Date: Feb 2012
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.

The Following User Says Thank You to JustinW3 For This Useful Post: [ Click to Expand ]
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes