Not a shocker there. Great app on the iPhone but Android version has been shoddy. Keep wanting to have it installed (w/widget also) but can't take the battery hit that comes along with it everytime I try to go back to it.
Maybe one day they'll get it right.
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
Maybe a dumb question, but what you would say is a good awake ratio ?
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
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.
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.
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)
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.
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
adb shell cat /proc/wakelocks > wakelocks.txt
adb shell dmesg > dmesg.txt
-vv -s 0
-vv -s 68
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 )Did you try to search for it?
https://gitorious.org/0xlab-kernel/...2d3e20d120254435addcf/kernel/power/wakelock.c
Doesn't look like low service - you were on wifi, so data was going over wifi.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..