Shared publicly  - 
 
Today's myth debunking:

"The battery indicator in the status/notification bar is a reflection of the batterystats.bin file in the data/system/ directory."

No, it does not.

This file is used to maintain, across reboots, low-level data about the kinds of operations the device and your apps are doing between battery changes. That is, it is solely used to compute the blame for battery usage shown in the "Battery Use" UI in settings.

That is, it has deeply significant things like "app X held a wake lock for 2 minutes" and "the screen was on at 60% brightness for 10 minutes."

It has no impact on the current battery level shown to you.

It has no impact on your battery life.

Deleting it is not going to do anything to make your more device more fantastic and wonderful... well, unless you have some deep hatred for seeing anything shown in the battery usage UI. And anyway, it is reset every time you unplug from power with a relatively full charge (thus why the battery usage UI data resets at that point), so this would be a much easier way to make it go away.
625
217
Toby Jones's profile photoSven Sorrell's profile photoCraig Doremus's profile photoPetroniu Alexandru Pusca's profile photo
174 comments
Nate F
 
Can you tell me if there's a proper way to monitor this or is the whole battery stats thing a joke? I always assumed a hardware controlled component was outside a simple file's control but you would know. Thanks for giving some detail on it
 
I didn't know the Blameometer™ knew data across reboots.
 
The Android-related cargo cults are pretty depressing sometimes. I mean, you can go look in the source code to see what it's doing... and yet people post random superstitious twaddle like this anyway.
 
On todays episode of Myth Busters, +Dianne Hackborn debunks yet another Android myth (that plain didn't make sense from the start)


Keep up the interesting posts :)
Nate F
+
1
2
1
 
Dianne, you said that the stats file is basically useless to end users. I was just wondering if the entire idea of erasing that file was FUD or if devs simply missed the mark. I never put faith in wiping it to increase battery life but was wondering if there was a userland way of "refreshing" battery stats that affected a hardware level component like battery charge. I could probably word this better..
 
I know you must get a million ideas thrown at you by 1000s of idiots, but here is one more: To explore a folder on android, long press the folder which opens a rotary overlay of it's contents. You can then drag your finger to your target and release to open. Much like the idea of a rotary phone.

This follows the same idea as the browser quick menu which may be accessed by sliding from the left or right side which then opens a semi-circular menu of options.
 
+Enat Eandroid - The whole idea of erasing that file having any effect on battery life is pure superstition and wishful thinking. The battery usage UI describes what your device has been doing that has been consuming battery; it doesn't change how the device is using the battery.

You want to "refresh" your battery stats? Charge your phone. When you unplug it again, the device knows it's at full charge (because the battery firmware says so), so the stats tracking treats that as a known milestone for reporting purposes.
Nate F
+
4
5
4
 
Thanks +Christopher Tate, I know you Googlevillians know what you're doing but the definitive answer is appreciated. I've been hacking at your OS since .9 and it must've been 1.5 I saw that "lol wipe your stats bro" trend start. Now I have a solid reason against it.
 
Is there a way to read this file or does it have a proprietary format. I`d like to keep track of battery wasting apps ov the long term.
 
+Craig Doremus Its format changes in pretty much every major platform release. You can look at the code for whatever platform you are running to see the format at that point.;
 
Thanks for your prompt response. Is there a device independant way to keep track of per app battery use?
 
Why is it readable? Seems like it could do with some 0660 treatment.
 
+Craig Doremus The file is device independent, +Dianne Hackborn only said that the format changes with every major PLATFORM release, this means a major Android version, not that it changes for every hardware configuration.
 
+Dianne Hackborn so what you're saying is that batteries are, in fact, dumb slabs that consist of lithium, electrolyte, and a cathode, and do not have the capability to know where they're "at" in terms of a charge?

How dare you? :P
Tinus U.
+
1
3
4
3
 
And how about this battery calibration method that was suggested by HTC support? Also myth?

To also help with Battery Life you can do these steps exactly: 1) Turn your device ON and Charge the device for 8 hours or more 2) Unplug the device and Turn the phone OFF and charge for 1 hour 3) Unplug the device Turn ON wait 2 minutes and Turn OFF and charge for another hour Your battery life should almost double, we have tested this on our devices and other agents have seen a major difference as well.

http://forum.xda-developers.com/showthread.php?t=712990
 
+Dianne Hackborn thanks for all those myth debunking. Since we are on the topic of the battery indicator, is the android OS ICS battery drain an actual wakelock problem or is it a bug displaying the batterystats.bin file in the battery use page?
 
You mean, I can't just recharge my battery by deleting a file? Where's my flying car?
 
+Agustinus Upojo I can't remember enough about it to elaborate a lot on it, but HTC devices used to make kernel modifications as well as other changes that affected the devices charging. The original incredible was an example.

Essentially the kernel controls charging to an extent when the device is on, and HTC used to let the battery kind of discharge down to 90% and back to 100% more aggressively than other phones (i suppose so it wouldnt wear the battery out as quickly, since batteries choke themselves off once they fully charge as to not overcharge) That's where the whole bump charge thing got started because the phone would say charged when it would really be anywhere from 90% up
 
+Craig Doremus There isn't an application API for this, you need to do this with your own build of the platform.

+Agustinus Upojo As far as I know the wake lock reporting is correct. Also, as far as that suggestion from HTC support, I have no idea what it does, but it would not have anything to do with any behavior in the Android platform software (which is the only thing I can address).

+Kenny Root It is not world readable.
 
Well there goes my bad OCD habit of wiping battery stats
 
+Jonathan Franklin yeah, different OEMs have used different approaches to battery charge management. Usually some combination of hardware "fuel gauge" on the PCB or in the battery, kernel driver, and sometimes a userspace daemon. The design of the specific phone may be friendly or unfriendly to charging.

For example, on the Nexus One, we could leave the charge circuit on (providing power to the phone) but disable charge flow into the battery (once it reached 100%), avoiding overcharging. The fuel gauge was integrated with the battery and provided 3s and 30s average current reporting, as well as voltage, temperature, and charge level, which was really nice.

On some designs there isn't a way to power the phone from the USB connector without charging the battery, which necessitates stopping charging when the battery reaches full and allowing it to discharge to a point before charging again -- how far you let it discharge impacts battery life and user perception of "is my phone charging all the way". Then debate ensues about how to report the charge level, if it's better to report the "true" level even though users will complain about their phone "not charging all the way", etc, etc.
 
So, when one wipes battery stats via CWM, does that only erase this file or does it do something else? The reason I ask is that wiping battery stats happens between ROM installations, but this batterystats.bin shouldn't survive a ROM installation.
 
Ok, but sometimes I have really strange problems with my battery. Normally it could last for 3 days if I am using my phone only for calls And it could last for a day when I am checking email,browsing, etc..
But there are days when I unplug my phone at 9 AM and at 13 PM it is almost dead. And my battery gets really hot while it is discharging. After I recharge it again then my phone is operating normally for some time and then again it drains the battery for several hours. In the usage statistics the problem appears to be the screen - but I am barely using my phone and it is in front of my all the time - I can see if my screen turns on - it never turns on by itself. I just hope it will not explode in my pocket some day.
 
I never bought this either. I just would do the discharge and fully recharge minus the battery stats wipe stage.
 
+Vladimir Todorov The battery stats is not able to measure everything -- it is watching fairly high-level information what what is going on (CPU usage per process, screen being on at a particular brightness level, phone signal strength, wake locks), and computing how much power each of these use based on configuration information included on the device by the manufacturer.

If something is going on that it doesn't see, it can be misleading what it shows as the top power consumer because that isn't really the issue. So, with screen being on, if you go and look at the details and the amount of time it was on for doesn't look unreasonable, it is probably something else.

The battery being hot does mean something is using a lot of power, and with it draining that quickly, if there is nothing really obvious jumping out on the battery usage than it is something that isn't being measured. It is hard for me to say much more than that -- the details of all this varies between devices (and each device has a lot of stuff going on that has nothing to do with Android such as completely separate CPUs running the radio), and the reporting of the battery usage has improved in every release so older versions of the platform will miss things (like wake locks) that are measured on the current platform.
 
I have been preaching this since 1.5 through 14 devices thanks for the proof !!
 
Thanks for this, +Dianne Hackborn! I've always wondered what wiping battery stats REALLY did. Now I know: nothing!
 
Wait, so this is a thing? People were actually seriously suggesting that deleting this file would improve battery life?

Really?

Like, seriously?

Jesus.
 
Thank God this was officially debunked. Now those stubborn people who think it IS useful and don't listen otherwise might realize they were wrong. Why people ever thought that a software file would have an effect on the battery life is beyond me..
 
Agustinus Upojo, the thread you quote on what HTC recommends on charging your phone is called bump charging. It's actually not very good practice as it overcharges your LiON battery and we all know LiON does not like to be overcharged. Charging your battery like that sort of circumvents the overcharging protection circuitry build into all LiON batteries. You may initially get more run time overcharging your battery like that but in the long run you are diminishing the life of the battery.
 
I have a pretty similar experience, On my HTC, the phone would take double the time to charge from 90 to 100, than say compared to 70 to 90%. However while discharging it has been consistent. This was with Stock HTC ROM. Any idea about this behavior?
 
I guess that's just due to how batteries work. As the battery fills up, the voltage inside raises, making the voltage difference between the charger and the battery smaller, thus slowing the process. Simple chemistry :)
 
Anticipated this situation but its not the same case with my CM7 rooted HTC device. It gets charged consistently at same pace be it 30 to 40 OR 90 to 100.

That increases my confusion. Is it that battery power meter displayed by HTC Stock ROM has totally different approach than CM7 ROM on same device.

Which one is a truthful depiction?
 
I have no idea then. It could be that CM7 somehow compensates for the different loading speeds and corrects the displayed percentage, but that's just wild speculation on my side ;)
 
My money is on HTC lying to make the battery life appear better than it is. I know that some manufacturers have their graphical icons wildly inconsistent with the numeric value. 20% charge shows a glass at half full.
 
Once you get above 90%, I would stop worrying about it. I think most if not all devices need to go through charge/discharge cycles while fully charged to keep the battery life good, so when it is "charged" it will actually be ramping up and down to do that. How this is shown to the user varies across manufacturers, and there is really no clearly right solution -- if you show them the actual changes in level they start complaining and getting concerned about their battery not being at 100%, so it is good to just show it at 100% at this point but then you are giving a little white lie about the actual level.
 
As an example, when you look at lead acid batteries, you determine state of charge by looking at the voltage. A 12 volt battery can range from 11 volts up to 15 volts. You would say that at 11.5 volts, the battery is discharged and any lower would be damaged. At 14.7 volts, the battery would be "100% charged" Knowing the average minimum and maximum, you can determine the percentage. But determining 100% and 0%, IMO, is really just an average.
 
What about Android OS showing rampant percentages like 30%( and I've seen 47%) on a dual core running (SGS2) GB? That's right, my battery stats are showing that AOS consumes as much battery as 1h52mins of calling time, WHICH IS NOT RIGHT...or is it that my battery stats are trolling me with the wakelock monitor to ruin each and every day?
 
+Petroniu Alexandru Pusca That is, in my experience, always some app that stays awake in the background and drives the usage up which shows as Android OS in the battery stats. This happened in Froyo too, but there wasn't an Android OS entry in battery stats in Froyo. But I could be wrong, but I've never seen it happen on a new stock firmware flash, only after i installed a few apps.
But let's see, the people here might know better. That Android OS bug sure is a pain in the neck though, specially on 2.3.3
 
Android OS is power usage of the core system, below the Android framework. This is the kernel (and its drivers) and many of the low-level non-Dalvik processes like init, ueventd, etc. (Prior to ICS the only thing that could impact this was CPU usage of those processes; as of ICS this is also any wake time that is not accounted for by Android framework wake locks.)

So, this is probably outside of what I can really address, since the part of Android I work on is system_server and the frameworks (Android System would typically be things I know about more). This is also where manufacturer-specific issues can appear, if they have their own native daemons (they very often do) with issues, or driver issues, etc.

At any rate, to dig into this more than just the user UI shows, you can hook up adb and use "adb shell dumpsys batteryinfo" to see the low-level data about what is going on to cause that power usage to be shown in battery stats. For example, for this ICS phone I've had sitting on my desk, here is the data under user 0, which is Android OS is measuring:


#0:
Proc irq/308-mxt224_:
CPU: 0ms usr + 210ms krn
Proc iscan_sysioc:
CPU: 0ms usr + 1s 100ms krn
Proc /init:
CPU: 730ms usr + 1s 290ms krn
Proc ksoftirqd/0:
CPU: 0ms usr + 60ms krn
Proc vold:
CPU: 70ms usr + 80ms krn
Proc file-storage:
CPU: 0ms usr + 10ms krn
Proc kworker/u:4:
CPU: 0ms usr + 1s 370ms krn
Proc kworker/u:3:
CPU: 0ms usr + 5s 10ms krn
Proc kthreadd:
CPU: 0ms usr + 4s 480ms krn
Proc loop0:
CPU: 0ms usr + 20ms krn
Proc loop1:
CPU: 0ms usr + 20ms krn
Proc jbd2/mmcblk0p2-:
CPU: 0ms usr + 2s 150ms krn
Proc netd:
CPU: 110ms usr + 450ms krn
Proc mmcqd/0:
CPU: 0ms usr + 11s 540ms krn
Proc kworker/0:0:
CPU: 0ms usr + 9s 50ms krn
Proc kworker/u:0:
CPU: 0ms usr + 4s 470ms krn
Proc kworker/0:1:
CPU: 0ms usr + 9s 490ms krn
Proc kworker/0:2:
CPU: 0ms usr + 3s 480ms krn
Proc kworker/u:2:
CPU: 0ms usr + 5s 30ms krn
Proc kworker/u:1:
CPU: 0ms usr + 7s 440ms krn
Proc bdi-default:
CPU: 0ms usr + 180ms krn
Proc zygote:
CPU: 180ms usr + 700ms krn
Proc debuggerd:
CPU: 0ms usr + 30ms krn
Proc flush-179:0:
CPU: 0ms usr + 670ms krn
Proc irq/334-cypress:
CPU: 0ms usr + 10ms krn
Proc yaffs-bg-1:
CPU: 0ms usr + 470ms krn
Proc khubd:
CPU: 0ms usr + 10ms krn
Proc ueventd:
CPU: 30ms usr + 40ms krn
Proc dhd_watchdog:
CPU: 0ms usr + 180ms krn
Proc mmcqd/0boot1:
CPU: 0ms usr + 10ms krn
Proc flush-31:4:
CPU: 20ms usr + 50ms krn
Proc flush-31:6:
CPU: 0ms usr + 50ms krn
Proc kswapd0:
CPU: 0ms usr + 3s 210ms krn
Proc sync_supers:
CPU: 0ms usr + 30ms krn
Proc dhd_dpc:
CPU: 0ms usr + 2s 640ms krn
Proc installd:
CPU: 20ms usr + 290ms krn
 
@Dianne
Sadly, you got it right AND touched the sensible spot also, that's why I said the batt stats are trolling me. The lauchers that are imbeded inside by certain mfgs are so badly integrated....so much for the Android experience, avail only for 3 devices and for select users-let aside those who can tinker the system. Rooting and logging, I've notice that Aos high perc comes from the ducking frameW horrible integrated( I strongly suspect negative IQ value is involved ).
Just as a personal view, I'd like to see Google enfocing its FW over mfg's, at least as an alternative.
 
I had a feeling it wasn't that important of a file, I've only wiped my stats once or twice on my phones because it felt fishy considering Li-Ion batteries usually have hardware voltage tracking chips built into them.
 
+Dianne Hackborn Although this is off topic, which is the best app for facebook? I tried friendscaster with push turned on. However it drains my battery quite a lot.
 
One time I fully charged my device and then proceeded to wiping battery stats to see what it was. After wipe my device said the battery was empty and I had to recharge it. Any thoughts? I thought that it was rather odd. 
 
+Dianne Hackborn I hear what you are saying about android os stats but I just find it strange that it logs 1hr 14m awake time but only 57m on battery. Surely there is some error somewhere. Also there is a rumour floating around about bugs in screen rotate causing battery drain. Any truth in it?
Edit: 39 secs on battery, 39 secs screen on time, 1min 6 secs awake time. just now.
error in android os battery stats logging??
 
(this is my first g+ commentary, so I am sorry if I do something wrong)

many android users have the problem with shutting down there device while it has e.g. 20% battery power. Short jump to 0% and device is off. (for me: then charging the battery it jumps from 80% to 100% at the end of the charging time)

Can you tell us which part is responsable for the %? Does android / the device calculates this value by reading voltage or so?

Or does the charging circuit in the battery gives this value to android?

So, is there any chance to "calibrate" the % gauge? Or is this a problem directly to an aged battery?

And BTW, there is another "tip" (besides deleting batterystats.bin :-)) I found some days ago:

1) Drain battery
2) Just as the battery hits "Shutting Down", plug in your charger
3) Let the phone power down
4) DO NOT TURN ON THE PHONE
5) Let it charge up overnight or something along the lines of 4-6 hours, which should ensure it will be fully charged
6) Power up, your phone should be calibrated and will now shut off at 1%

http://forum.xda-developers.com/showthread.php?t=702167

Tried this, for one time is solves my problem, but now my device shutting down at 18% again. :-(
 
Dianne - are you sure that this applies to ALL devices? I believe that most HTC phones have a coulomb counter fuel gauge, which does require recalibration cycles, and might need a heuristics file wiped. However, I concur that you are correct if you are referring to Samsung devices, which use a MAX17040 (or derivative/relative) fuel gauge chipset, which is fully standalone.

As to people asking about high Android OS battery usage - On the Galaxy S II, it is caused by the device frequently waking up for whatever reason. The most common causes of this are:
1) A misbehaving app that drives network traffic to the phone on wifi - Skype is notorious for this
2) Excessive broadcast traffic on your LAN that wakes the device frequently - Windows Client Backup, UPnP (DLNA) SSDP, and Dropbox LAN Sync are common examples of this.
3) A bug in the wifi chip that causes it to fire frequent unnecessary wakeup interrupts to the CPU - The UCKK6 build for the AT&T Galaxy S II (SGH-I777) is plagued with this problem, Broadcom's BT-AMP feature goes nuts and wakes up the CPU once per second. It also affects Infuse leaked builds from UCKJ2 onwards. It does not affect SGH-I777 UCKH7 or GT-I9100 XXKI3.
 
I'm not really In the position to argue your statement but after a while on my nexus one, my battery starts to die at 20% and will keep increasing until at most 25%. Once my battery reaches 25% it makes the 15% low battery noise and jumps directly to zero. I am still able to power the device on after, because clearly there is still charge left in the battery.Once I wipe the battery stats and leave my phone in bootloader mode until it completely dies, seems to reset it and my battery returns to dieing at zero and I get 20% more charge/use out of my phone. So in my experience, this extends my battery life to what it should be.
 
This is the opposite of what happened to me. I charged my phone to 100% and then deleted battery catch but when I booted up again it said the battery was dead and proceded to shut down.?.?.
 
CJ, when you make a report like that, you need to indicate what device and firmware you're using. As I stated above - fuel gauge implementations vary significantly between devices.
 
I'm sorry +Andrew Dodd I have an HTC inspire 4G, running cm7 nightly 260, another oddity is that I used to get 2 days of good use with the previously stated setup with a lordclocan kernel but now I get a little less than a day.. :-(
 
Okay everyone, let me say again: battery stats has NOTHING AT ALL to do with the battery level reported to you. Nothing. Zero. Nada. Zip. In fact, the code that is creating it, is actually filling in some information contained in it from the battery level that is being reported from lower-level parts of the system (to show the chart of battery level). It has NO impact on the battery level that is reported. It sits on top of what is being reported.
 
And what about excessive android os stats?? more time spent awake in the stats than is possible for the amount of time the phone has been on battery. say if i keep screen on for one minute on a fresh charge and screen on time is one minute then shouldn't android os awake time be the same??? because i got over a minute aos awake time for 39secs screen on and 39secs on battery.
 
Tim - at such short times, that's probably just rounding errors, or one stat being updated at a different time than another.

Edit: I've NEVER seen an AOS time usage report that was higher than the actual elapsed real time, but I don't look when I'm on battery for only 1 minute.
 
+Stephan Manske There are different ways that the battery level can be reported. Two major ones I know of are either an additional line with the battery allowing the battery itself to report its level (often called smart batteries), or where low-level code in a kernel driver and/or the radio processor monitors what is going on to approximate power use and thus battery level. Clearly the former is better, but there are definitely Android devices with the later. Neither of these are things anything in the Android platform itself are aware of; they come from lower-level hardware-specific parts.

Also, even with smart batteries, I believe they are not reporting the actual level but still approximating it -- they just have a power gauge on the battery to determine exactly how much power has been drawn from it, and knowing the total power of the battery can then compute how much power is left. These also may need to take into account degradation of the battery over time (as the amount of power it can hold goes down) and can misreport if something they aren't measuring happens.

At any rate, my first question for you would be have you replaced the battery with a new one? It could just be that your battery is getting old and/or going bad, and it can't hold a charge like it used to.
 
How long does it take for the battery to noticeably begin degrading general speaking?
 
+Andrew Dodd well check out XDA and you'll see that its not imaginary. i should have taken a screenshot but i forgot. i've noticed it a lot so thats why i tried it so soon after unplugging. it only happens with screen on, if i leave the screen off the stats look normal but with screen on the awake time increases faster than the screen on time does. that seems odd. and not just a few seconds, as time goes on its increases by a lot. tens of minutes.
 
+Tom Meaney Where on XDA? Which device? I've never seen someone report Android OS usage higher than actual elapsed time for any reasonable test (such as an overnight baseline drain test) on the following devices: Samsung Infuse 4G (SGH-I997), Samsung Galaxy S II International or AT&T (GT-I9100 or SGH-I777).

+Stephan Manske Estimating the battery state of charge is handled by a dedicated chip in the phone, and this chip varies by device. Some fuel gauges are known as "coulomb counter" devices, which have a current sensor and measure every mA going in or out of the battery. These are usually more accurate if calibrated properly, but they are prone to going out of calibration and drifting WAY off. Some, such as the MAX17040 used in the Nexus S and all first-generation Samsung Galaxy S devices, is fully standalone and will always converge towards truth and not diverge (the disadvantage of this being that in some situations, such as a reboot on low battery, they can get temporarily thrown off.) More on the MAX17040 at http://www.maxim-ic.com/datasheet/index.mvp/id/6621 - The Galaxy S II uses a newer MAX17042 which is not publically documented. It appears to have extra features (including a current sensor) not present in the '40, but also not used in the GSII. (However, apparently the Nook Color does use these extra features, and when enabled, that gauge can get thrown off.) The YP-G70 (Samsung Galaxy Player 5.0) doesn't even have a fuel gauge chip (or at least not one in use - surprising since I thought it was built into the MAX8998) - the estimate battery state of charge purely based on a voltage table (as a result, the Player 5.0 has fairly inaccurate battery SoC estimates.)
 
+Tom Meaney Maybe you are seeing this because you are on a dual core phone. For a given period of time, if the phone is using both cores, probably you are going to see more awake time than what is real... Just one thought.
 
i've always suspected as much... since the file is called batterySTATS.bin, not batteryMETER.bin... thanks for the confirmation. now if only reliable sites like cyanogenmod forums/wiki would get rid of this "battery calibration" myth...
CJ C
 
So basically every recovery that has a "wipe battery stats" option, all that's doing is deleting that one file? If I'd known that I wouldn't have been bothering. I had assumed the recovery had access to data a little lower level than that, e.g., the battery has more than two pins on it, because the extra is/are for data, so I figured there was a way to access data stored in a chip in the battery itself. But, if all they're doing is deleting batterystats.bin... is that all they're doing? Maybe +Koushik Dutta or +Amon RA can say what their recoveries do WRT this, because I really don't know.
Amon RA
 
+CJ Chitwood my recovery only wipes batterystats.bin , nothing more.
 
I was always under the impression you had to let your phone run itself flat and deliberately reset that file for accuracy. But I also thought it shouldn't be too far off - it must read the battery in some way, the only other way being to start at baseline and keep deducting what every little process and app uses - pretty impossible. I do flash new kernels/roms etc and that can throw it out sometimes.
CJ C
 
+Amon RA then I guess I only imagined my battery draining more slowly after wiping stats with your recovery on my G1. That, or, I was more conscientious about turning things off after wiping stats and it really did last longer but for a different reason. Still, I trust +Dianne Hackborn to know what she's talking about. I just always assumed there was more to wiping stats than a simple file delete. >shrug<
 
+Dianne Hackborn +Andrew Dodd
sorry for not mentioned it: I use a HTC Desire. so perhaps you know what kind of sensor this has?

+Dianne Hackborn this problem occurs with my 1+1/2 year old original battery. I bought a 3rd party battery 1 year ago. this has the problem not yet. But with same use of my desire it has a significant higher battery drain in mA. e.g. with wifi on and screen of in my office: 5mA with the orignal battery, up to 10mA with 3rd part one. Or in heavy use I get about 400mA / 700mA.

So, guessing that using the desire in a comparable way with two batteries, both should have the same mA (or at least comparable values). So I do not know which part is giving me the (supposed) wrong values?
 
Just accept the average smartphone will last all day, but need recharging each night. Things like games will greatly decrease this. No point obsessing over it really - there's lots of handy apps that will, for example, put your handset almost to sleep (underclock the cpu, kill unused background apps, etc) when it's off - I like both System Tuner Pro (pretty awesome, with a kill list so you can select what to keep running and settings for CPU "governers", SD cache tweaks, etc - needs root tho) and Mobo Task Killer - perhaps more easily used, it just runs in the taskbar and you can click "optimise" for simple cleanups. New versions of Android don't really need task killers, such as the popular Advanced Task Killer. The only other option is to carry a spare battery or one of those gadgets you can plug in for a boost. Remember Android base system excepted, there isn't really much that needs to be running non stop - including those wasteful system tasks, especially on games, that keep you connected to a server or re-launch apps you try to kill. Gps/WiFi takes it's toll, too.
 
+Stuart Reid I agree with you on system tuner pro it is amazing!!! But I disagree with your acceptance of a phone that lasts one day when playing games. I myself have a HTC inspire 4g and have gotten 3 days of moderate battery life, all I did was install a lordclockan kernel, with playing games. I was also used to getting a full 2 days worth of playing games, texting, and web browsing, but for some reason now I can only get a day.?. I wonder if my battery has started degrading, I have only had the battery (regular stock one) for a little less than 6 months.
 
+Stephan Manske Well, it depends on how your mA usage is being reported. On many devices, it's based on some very rough estimates calculated from changes in battery State of Charge and capacity - so, for example, on every Samsung device I've used, the Battery Monitor Widget current discharge estimates are complete wild-ass guesses. Looks like the Desire has a DS2784 fuel gauge - http://www.maxim-ic.com/datasheet/index.mvp/id/5385 - If the 32 bytes of nonvolatile parameters get corrupted somehow, it would report falsely. Note that cheap aftermarket batteries can often have capacities FAR lower than advertised (I had a 3500 mAh extended battery for my Infuse that was at best 2500 mAh based on some very limited testing), and any battery degrades over time. How fast depends on temperature and state of charge - a battery in a warm environment and always near 100% state of charge can lose 20-30% capacity or more per year. A battery held at lower states of charge and not warmed as much will retain capacity for much longer.

On the somewhat offtopic subject of Android OS usage, especially on Samsungs - Does anyone know how to get statistics for time spent in IRQ handlers on a per-interrupt basis? This patch to the Linux kernel hides "Android OS" usage from Android's battery usage monitoring functions, indicating that most of that usage is due to some interrupt handler eating CPU during the suspend/resume cycle - http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=a3fe22ee824895aafdc1b788e19c081a2e6dd9da - The problem is that I have yet to find a good way to get statistics for which interrupt handler is eating CPU. /proc/interrupts is useless, as it only displays interrupt count and not IRQ time.
 
I've always kinda figured batterystats didn't do much of anything, I mean if you open it in a text program you can see it shows what programs get used, etc. The sad part is that many/most android users have or are experiencing some sort of battery issues, and now, there is absolutely nothing anyone can do about it.
I will say this, I have an htc amaze, and the bump charging that was recommended about halfway up the comments made a big difference to me.. one person said it will overcharge your battery, but that can easily be checked(the problem is the overcharge protection circuit of the battery kicking in too soon).
+Dianne Hackborn as much as I appreciate the info, it is always more helpful to tell people what IS the solution, than telling them what isn't. I know you are saying that it depends on the carrier or manufacturer, but phones like the nexus this shouldn't be the case.. what are some things people can do when power cycling just isn't cutting it?
 
+Sean Thomas If you're actually suffering a miscalibrated fuel gauge - who knows. I've been using Samsung devices lately, which have a fuel gauge that trades off some accuracy in exchange for not becoming completely out-of-calibration. In many cases, if you have poor battery life, it's due to something actually draining the battery. I suggest looking into BetterBatteryStats, which lets you identify applications that are holding wakelocks. Gingerbread's battery stats screen does not provide any way to view wakelocks, and more importantly, it does not penalize apps that hold wakelocks. (The latter is a major deficiency, since wakelocks are often one of the largest sources of drain in an Android device. A Galaxy S II in normal operation can drain well below 1%/hour when idling with the screen off - if something holds a wakelock that goes up to 4.5-5%/hour. However an app that causes this, such as Facebook, will not get penalized for doing this in the battery usage screen.)

A much harder thing for Google to do would be to penalize whatever app handles a received network packet that was responsible for waking up the phone. As it is right now, if an app drives network traffic to the phone, the OS gets blamed and not the app. Skype is a classic example of this - it drains battery by using the network in a highly inefficient manner, causing the phone to wake up frequently to handle incoming network packets. Unfortunately, because nearly all of the CPU time to handle the packet was spent resuming from suspend, this often shows up as Android OS usage and doesn't get blamed on the root cause (Skype).
 
so.. when i rebooted manually yesterday with 8% battery left and booted up with 53% battery, you want me to believe that theres no reason to delete my batterystats.bin? well i deleted it and rebooted again, booted up at 8%. in a perfect world there might not be any reasons, but ever since my first android(g1 oct 2008) and every android device ive owned since, the batterystats.bin file has always lost accuracy with a short amount of time. and it seems that deleting the file and rebooting has been the only thing to make it accurate again.
 
Well it would depend on a number of factors... but actually the car analogy is a good one. Car computers that give you a "range", that's based on your average MPG (which can vary wildly), but it also knows roughly how much fuel is in the tank...

I just stick my phone in it's cradle whenever I'm home. When it's on standby (the screen goes off) System Tuner will drop it as low as 200mhz and even kill off tasks if you want to. Other tools like the famous SetCPU also uses root and governors but seems mainly focused on the overclocking crowd ;-) PS. If you've never used one, a governor is simply a profile of what speeds to use for what demand, e.g. I don't need my Galaxy S2 blazing along at 1.2ghz on 2-cores all the time if it's just showing a clock. I'm sure Android does a lot of this stuff itself now, but rooted phones and certain tools do help.

+CJ Barbot II I only said every night because I stick it on charge when in the house, never really deliberately let it die to test it. If it's just going to be for calls/emails then yeah, can see it lasting days. Maybe not the Samsung, multi-core with a low-ish power battery, but certainly in others. As for it degrading, par for the course I'm afraid. You're supposed to charge to full once empty. Goes for most things of this type, such as laptops, etc.

Never mind, one day these dreadful Lithium-Ion batteries will be gone and we'll have nice , safe, micro hydrogen power cells lol.
 
So there is no explanation. I'm not really complaining as much as I am just curious as to why my battery no longer lasts 2 days with good use. I am fine with having a full 28 hours, give or take, but I was also a bit worried. You see there were 2 major times where I showed off to my friends how much greater Android is than apple, I did this by flashing 2 different roms within a very short period of time to demonstrate how customizable Android is compared to apple. My freinds were wooed but do you thinm there could have been repercusions like my battery anomaly?
 
+semeon korsunsky Because deleting batterystats.bin doesn't do anything except act as placebo effect. (Unless HTC is "overloading" it by storing data in it - I wouldn't put it past a handset manufacturer to make a modification that Google considers to be stupid, such as adding battery fuel gauge calibration data to batterystats.bin. However, I'm sure there would be evidence of special processing of this for interoperability purposes in the Cyanogenmod source code, which there isn't. If you search the source code, there is no mention of batterystats.bin in any code which could possibly interface with the fuel gauge.) Which phone do you have now? Some devices' fuel gauges (such as the MAX17042 in the Galaxy S II) get confused by a heavy load immediately after a reset, which causes them to temporarily report low if they are reset in a low-battery condition. I can tell you that, without any doubt, batterystats.bin has no effect on any Samsung device with one of Samsung's own CPUs.

In the case of the Galaxy S and Galaxy S II series devices, there is no provision whatsoever for inputting history data into the fuel gauge chip - the only "input" there is in the kernel driver is a "reset" command.

+CJ Barbot II You might have thrown the fuel gauge a little off calibration - but it's more likely that something you flashed contained a bug that introduced a power management regression, or an app you installed is draining battery by holding wakelocks or driving network data to your phone.
 
+semeon korsunsky I'm 90% certain the Nexus S has the same fuel gauge (MAX17040) as the Galaxy S - reboots on low battery are a known corner case that can fake out the MAX17040/42 - good news is that after getting "thrown off", unlike some other gauges, that one will converge towards the truth as time goes by (a matter of hours at most, not days).
 
if the battery level is lower than it should be, it does converge. ive seen it happen myself. ive seen the battery level slowly rise, looks like its being charged magically without it being plugged in. its actually a weird sight to see, lol. but if its showing a higher charge than it actually has, it does not converge.
 
+Andrew Dodd Actually one of the improvements in Gingerbread was to take into account wake locks in battery stats. If you look at the details of any app shown to be using power, you will see the amount of time it has spent holding wake locks. There are two ways power from wake locks is computed:

1. On some chipsets, simply holding a wake lock needs to prevent the CPU from going to a full deep sleep. In the reported battery usage, this extra power use will be distributed across all apps holding wake locks.

2. Even if the wake lock itself doesn't cause power use, holding a wake lock in one app can allow other applications to run and CPU when they wouldn't otherwise. (For example, some app may have a { sleep(1); do something; } loop that wouldn't run if no wake locks are held.) To address this, half of the CPU usage of applications is distributed to be blamed on the ones holding wake locks.

This was added to Gingerbread, so from 2.3 and on it is very much the case that wake locks are being accounted for. Some of this does of course depend on the power profile being correct -- if your manufacturer hasn't correctly specified the power use of wake locks, then that part won't show up in the battery stats. There isn't really anything the platform can do about this; there is no way for it to know the actual power use of such things. (I do have some ideas for giving information about how inaccurate the data shown in the battery use UI is, which might encourage manufacturers to set these numbers correctly.)

As far as receiving packets waking up the phone, that is actually I think a lesser problem. More important is that there is a relatively large amount of power use required to bring up the radio when data transfer needs to happen, and the radio typically needs to stay up for 10 seconds or more when this happens to avoid continually going up and down. We do need to figure out how to measure this, but it will probably take getting some more information from the RIL and radio CPU than the platform has right now.

The other big area I think we need to dig in to is computing power usage of the GPU, which with Android 3.0 on has become increasingly important. This will require getting information from the GPU driver about the kind of work it is doing.
 
+semeon korsunsky You say "ever since my first android(g1 oct 2008) and every android device ive owned since, the batterystats.bin file has always lost accuracy with a short amount of time," but in fact there was NO batterystats.bin file in early Android. I think the first release this ever appeared in was Cupcake, and that was just some early experimental work I was doing to try to quantify application behavior by sticking in instrumentation of interesting potential power-related things they were doing.

I will say that I don't know for sure what all of the various devices are doing... however, I know exactly what the battery stats code on the G1, Nexus One, and Nexus S does. I wrote it. And I can assure you there is nothing it does that has any impact on battery level reporting or battery draining (aside from whatever work the code itself does that would use power).

Frankly, arguing that deleting the file is having any impact on the reported battery level on these devices is the same as arguing that the sun orbits the earth. It just isn't true, and you can go right into the code and see this for yourself.
 
+Dianne Hackborn lol, i like your argument :) im not arguing though. im just reporting what i see. i flash kernels/roms on a daily basis to test for a certain developer, and i frequently see that after a reboot/flash the battery levels can vary wildly. not every time though. i used the 8% to 53% as an example because it happened this morning. and i know that the 53% wasnt accurate, because with use, it dropped fast. after deleting the file and rebooting, it was back to normal. whether deleting the file helped i dont know, maybe just a reboot without deleting would have fixed it, its possible. but id have to say that i must have seen that behavior hundreds of times over the past 3.5 years. ive always assumed that the meter was inaccurate. i could be wrong, i dont know. but something is definitely going on with reporting the battery percentage.
 
+Dianne Hackborn oh, i missed something.. i got in the habit of deleting the batterystats.bin right around the time of cupcake, so youre probably right there.
 
Hmm, the power_profile.xml of the GSII must definitely be broken then - I've never seen an application get blamed for wakelocks on any device I've owned. Also, kernel wakelocks don't get reported easily, so users don't know when Samsung screwed up (such as https://github.com/Entropy512/linux_kernel_sgh-i777/commit/fc9eb85807302583259e27013ed184a43107bb67 ).

Receiving packets that wake the phone is a fairly big problem on the Galaxy S II - Some apps seem to think "oh, I'm on wifi, I can use whatever amount of data I want" - so they only drive network traffic to the phone when on wifi. Some of the worst battery drain situations on the GSII only occur on wifi, some of it app-driven, some of it environmental, some of it bugs:
1) Skype is just bad news - on wifi it causes frequent wakeup/resume cycles. On cell data, not so much, but that is partly because on the GSII, any data transfer over the cell radio incurs a 6 second fixed wakelock in the kernel.
2) Broadcast traffic on the local network can be quite annoying - I'm not sure what a good solution for this is, since a device can't just ignore all broadcast traffic. Obviously the answer is for machines on the WLAN to behave properly, but it's really tough for a user to diagnose this. (In fact, impossible without rooting to run tcpdump, which voids the warranty on most carriers.)
3) Broadcom's BCM4330 is a piece of crap chipset from a company which provides zero documentation of their chipsets and barely comments their horribly structured Linux kernel drivers - either something in their proprietary userland binaries or their firmware blobs is misbehaving on newer Samsung firmwares. It's the root cause of most if not all of the battery life complaints with the SGH-I777 (AT&T GSII) UCKK6 update, and is also plaguing all of Samsung's SGH-I997 (Infuse) leaks from UCKJ2 onwards (It may even affect the Rogers UXKG3 Gingerbread leak but I'm not sure, I no longer have the Infuse). It can be diagnosed by running Shark for Root (or manually running tcpdump) and observing Ethernet protocol 0x886c packets at a 1 Hz rate when the drain is occurring (The problem is intermittent). To the user, this just shows up as insanely high Android OS usage because of all of the suspend/resume cycles it drives.

It's frustrating, because modern wifi chipsets have such low standby drain that, in theory, the best power consumption occurs when all background data is routed over wifi (And this is my experience when everything is behaving) - but this advantage is negated by the issues above.
 
Here is a picture of the CPU use of a test application running on Gingerbread on a Nexus One. This application does nothing except sit in the background with a wake lock. The CPU use shown is basically all due to other applications.

https://picasaweb.google.com/105051985738280261832/Android#5698394687853216994

If you look at the details of this from battery stats, you'll see this:



#10048:
Wake lock BatteryWaster: 4h 20m 29s 324ms partial (1 times) realtime
Proc wakelock:
CPU: 2m 16s 870ms usr + 2m 41s 80ms krn
Proc com.android.batterywaster:
CPU: 510ms usr + 220ms krn
1 proc starts
So a wake lock was held for almost 4.5 hours; the app itself did only 1/2 second of CPU usage, but got over 2 minutes of CPU usage assigned to it due to holding the wake lock.

Re wake locks in the kernel being hidden -- this has been improved to some degree in Android 4.0 where we now account for these under Android OS. We still don't get good enough information from the kernel to be able to identify them well separately though -- to do this right something needs to be watching as each wake lock is acquired and released and performing weighted accounting across all held wake locks. The battery stats service is doing this for Android framework wake locks, but there is nothing in the kernel right now to do this.

The issue with applications causing power use due to inefficient networking (bringing networking up too frequently) is definitely on the list of things I want to improve this coming year.
 
+Dianne Hackborn okay, here is the question I am sure most of us want to know(since you mentioned ICS in your last comment).. are the many different issues you addressed and have been brought up here in some way taken care on in ICS? My amaze is supposed to get ICS, but that is only worthwhile if it works better than gingerbread.. Not just hardware acceleration and such, but things like battery efficiency.. many of your explanations seem like they blame the app developers, but the apps only do what the OS allows them to do.. and it feels kind of like a cop out if this continues to be the explanation over each generation of android.
Since it sounds like you've been working on this since the G1 was put out, I would think you could give us some technical details about what you and google have done to make things better(besides all of the bling that was widely publicized that we can find out for ourselves or we already know..)
 
+Dianne Hackborn Thanks for the details. One other thing - since I assume Linux 3.0 includes the IRQ time accounting patch that was in 2.6.35.12, does Android 4.0's battery usage statistics track IRQ time separately? Otherwise time spent in IRQ handlers will just disappear (like it does on Gingerbread if the IRQ time accounting patch from 2.6.35.12 that I linked above is applied to a Gingerbread kernel.)
 
Ok, I think I might now understand about this high Android OS Keep Awake time that we saw in ICS (Galaxy Nexus & Nexus S). As I learned from this discussion, they way Android calculated the Android OS battery consumption is pretty much different compared to the old Gingerbread.

As explained by Dianne on Jan 13, 2012 11:37:04 PM:

Android OS is power usage of the core system, below the Android framework. This is the kernel (and its drivers) and many of the low-level non-Dalvik processes like init, ueventd, etc. (Prior to ICS the only thing that could impact this was CPU usage of those processes; as of ICS this is also any wake time that is not accounted for by Android framework wake locks.)

Am I correct?

Because on Gingerbread (Nexus S), we don't have this high Android OS Keep Awake time. Mostly under 5% or so. In ICS, 15% considered normal (low).

This changes caused confusion to a lot of users:

http://code.google.com/p/android/issues/detail?id=22878

Because people always associate keep awake = not sleeping / doing something / consuming battery life

This changes make people ask "Why Android OS keep awake? Why Android OS using this a lot of battery while device is sleeping?" and variation of this kind of same questions.

Because past of their experience up to Gingerbread, the Android OS has rarely went up to 5%!

I don't know, I am not Android dev, but that's my general understanding ...
 
+Agustinus Upojo I think you're right - kernel wakelocks will now show up as Android OS, when they didn't before. On the Galaxy S II, that means the svnet-dormancy wakelock (6 second penalty any time you transfer radio data) will cause Android OS usage estimates to rise. In Gingerbread, only the suspend/resume IRQ time (on a stock .35.7 kernel) would get reported.
 
Prior to 4.0, there were no wake locks computed for Android OS. It is now just the dumping ground for all of the time the device was awake that wasn't otherwise blamed on someone. So it is (total awake time) - (total app/system wake lock time) - (total screen on time).

There was also a bug that was my fault in 4.0.0-4.0.3 where this was computed incorrectly and would add the screen on time instead of subtract it. :(
 
LOL, that's probably what had all the Galaxy S II users screaming "OMG THEY DIDN'T FIX THE ANDROID OS BUG!!!" with the ICS leaks for the Galaxy S II.

Which leads me to wonder - is it wise to dump all that into Android OS, as opposed to possibly separate categories that make it easier to distinguish? E.g. "Unidentified Wakelocks", "Interrupt Handler CPU Time", "Root User CPU Time". Obviously trained users can differentiate these via the details page, but too many people just say "OMG ANDROID OS BUG!!!!". :(
 
Unfortunately, there currently are no finer-grained categories that can be used. This is just all the time the device was awake that can't be accounted for by the stuff we can measure (system wake locks and screen on time). For example, "Interrupt Handler CPU Time" can't be used because there is no way to correlate this with the already measured time for individual wake locks.
 
Well, what I meant wasn't associating interrupt handler CPU time with a given app - just splitting the Android OS bucket into three separate categories (Obviously the categories of CPU time and wakelocks, ideally IRQ time as another one if IRQ time is tracked at all) - but some users are just plain lazy and just see ANDROID OS BUG OMG!!!). Of course, that leads to the question - does ICS even track IRQ handler time in battery usage, or is it now hidden in the void thanks to http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=a3fe22ee824895aafdc1b788e19c081a2e6dd9da (Which I assume is part of the 3.0 series kernels used in ICS)
 
Oh I see, yeah for just CPU one could do that. I would be hesitant to have this in the UI though -- there is already too much detail there for normal users, I'd actually like to simplify it. If you really want to see the details, do "adb shell dumpsys batteryinfo". If you can't do that, I don't think putting more details in the UI is going to help. :)

Good question about IRQ time being hidden. I didn't know about that change; I honestly don't know how this would impact accounting, but I would think that time would need to be accounted against something... right?
 
Well, sometimes you might be experiencing some odd unexplained drain event, but not near a PC (or at least, not near one that you can install ADB on). I've had that happen sometimes myself. Probably in this case there is no right answer once you're talking about user interfaces.

The time gets accounted against SOMETHING, but I'm not sure what and haven't figured out yet. Since I have an SGH-I777 and not a GT-I9100, I haven't had a chance to poke at the ICS leaks for the I9100 to see how they behave with some of the classic situations of high Android OS usage on those devices. (boo for the legal corner cases of leaked firmware...)

As an example, if you happen to know someone with an SGH-I777 or GT-I9100, try:
ping -i 5 <WLAN IP address of the device>
Watch Android OS usage skyrocket, and battery level start to drop rapidly (faster than holding a permanent wakelock)
Then install a custom kernel that includes the above patch, and do the same thing
Battery level drops rapidly, but no good way for a device user to figure out why.

Real-world non-synthetic non-device-bug examples of situations that might cause the above wakeup patterns/drain: Skype, Windows Client Backup broadcast traffic, Dropbox Lan Sync probes every 30 seconds, misbehaving UPnP AV (aka DLNA) systems with lots of SSDP broadcast traffic. Not sure what a good way to help the user diagnose such issues is - on Gingerbread the only way is root + tcpdump + send results to someone who knows how to read a pcap. Or turn off wifi - but since the BCM4330's standby drain is so low, a user SHOULD be able to leave it on all the time and get better battery life than routing background data over the cell radio.

Real-world bug example: The UCKK6 build for the SGH-I777 has a bug where Broadcom's BT-AMP function intermittently goes insane, causing the BCM4330 to wake up the CPU as often as once per second. As far as the user is concerned, "bad OTA, makes battery drain on wifi". No way to diagnose/confirm without tcpdump, no way to use tcpdump without root, no way to get root without technically voiding warranty. http://forum.xda-developers.com/showthread.php?t=1409513&page=4 includes a paste of some data from a tcpdump cap. (Apologies for the profanity - but it's just another thing that reinforced my hatred of Broadcom.)
 
I have here a counter example.
I recently bought an extra battery for my DHD.
Today battery 1 run down it it turned off, so I replaced with battery 2 (which was fully charged).
I booted the phone but once it got to the home desktop it would shoe zero battery and turn off.
Tried it two more times without any success.
Then, I booted into recovery (clock work mod), wiped battery stats, rebooted, and everything was fine, with battery showing 98%.
So ate least on this corner case of swapping batteries, those stats aren't erased and the OS reports the wrong value
 
I can't speak for what modifications they may have made to battery stats for that device, but again the battery stats in the core platform CANNOT POSSIBLE IMPACT the reported battery level, and it is very unlikely they made a changed that caused them to do this. Do you really know exactly everything that happened when you went through your reboot into recovery steps? Unless you actually know exactly what is being done -- which means that you manually stopped the system, deleted only that one file, and restarted it -- then your test is flawed.
 
I can't see any sysfs inputs in an HTC kernel to manipulate the DS2746 - most likely merely entering recovery reset the state machine. Or you initially swapped battery too fast and didn't properly trigger the poweron reset flags.
 
+Scott Doyland I've never seen such a dialer problem on any Samsung device. They've got their own unique problems (like the possibility of getting a permanent wakelock if the fuelgauge "glitches"..., and the fact that suspend/resume uses enough power that "Android OS" gets blamed for battery usage of apps like Skype that drive network data to the phone.) Definitely HTC-specific there. :(
 
+Dianne Hackborn I'm not ranting or anything, or even defending users should care about battery stats. i just stated an experience and a few steps i took that actually helped me make my device work.
+Andrew Dodd how fast can one change batteries that would keep records of it? it kinda reminds me of an old bug with this bootloader where pluging the usb/charger would boot the device. the fix for that was to pull the battery and wait a few hours :)
 
Glad to see this clearing up here. I think the battery usage stats should've been improved in 4.0. I would've liked also to see how much voltage is being used by what hardware in close to real-time.
 
There have been improvements made in nearly every release, including 4.0. Re "I would've liked also to see how much voltage is being used by what hardware" do you mean power? You don't really "use" voltage. And doing that would require having actual hardware to measure power draw across all the various components, which doesn't today exist on any of these devices that I know of.
 
I'm an overclocker. When trying to find the best custom kernel it'd be nice to have native access to monitor what voltages have been changed and for what, i.e. cpu, and ram. Although as you said, the hardware just isn't there for it. Just a wishful thought I guess. As an android hacker I really just want to see a more pc-like device.
 
Overclocking is really not something it is worth spending time with in the base platform -- the standard platform doesn't let you overclock. Whatever tools you are using to overclock should also have the responsibility if giving you whatever UI you want.
 
Sorry - I can't read all those zillions of posts (I read the first 40 or so?), but I just want to add (hope someone hasn't covered this)... a couple of weeks ago my (purchased used) Nexus One started using the battery like crazy. I'm not a developer/programmer. Since it was a used phone and the seller didn't replace the battery, I did. Nope. Something else... Darn. Today I figured out that it was Google Plus - running constantly in the background. Deleted it. Now my power is back to what it was before the vampire struck. I am saddened - I would like to have G+ on my phone, but not at that price. I am tempted to reload it to see if maybe something was just hung up, but I don't want to spend a lot of time tinkering.
 
if you get juice defender, you can manage all syncing apps, and maintain a schedule for when they sync so even google+ (probably one of the more battery consuming ones) syncs photo's once a day, and even force a sync on an app that doesn't sync on time or by itself. Its around 6 dollars for the ultiimate one, (the beta one comes hand in hand with it) but its one of the greatest apps i've ever had and i've never regretted it. https://market.android.com/details?id=com.latedroid.ultimatejuice&hl=en
 
Regarding .bin data, does the mobile data also get stored in a binary file ?

I'd like to make an app that saves/restores ICS mobile data counter, to have the same data after ROM flashing. The netstat* files in /data/system look like a good start, but plainly copying them back doesn't seem to work. Some info from first hand would be very helpful, if the task is even possible to do by current design of recording mobile data use.
 
/to jump in on the Android OS high percentage...

I am currently sitting on a very high usage for Android OS but in a twist of events I actually a low battery drain which leads me to suspect that a high Android OS does not equal high battery drain. I am using the latest LPB leak for the Galaxy S2.

https://lh5.googleusercontent.com/-fHDoIjD-5-Q/TzeS4Vg86DI/AAAAAAAAAgc/Kn0wiG73FKU/w335-h559-k/Screenshot_2012-02-12-09-17-00.png

https://plus.google.com/photos/101177072985014932410/albums/5708192551909131777
 
+Dianne Hackborn you (or someone at google) should create a g+ page like "android system explained"..and post at least every day some of this tricks/tips/news related to the android system..the page android developers talk about how to write code for android, but does not explain the android system in the same wonderfull way as you do :)
i really will like something like that..and will help a lot the "hacking android community" :)
 
+Rowen Nortje Your experiences with the Samsung I9100 LPx leaks are consistent with Dianne's comments above (see Jan. 17) - 4.0.0-4.0.3 have a reporting bug.
 
@james u can also turn off always on mobile data n keep g+.... Always on mobile data... Apps wont refreah but u can just turn it on whenever u want it 2 thats what i did...

Ps so am i to understand that flashing roms/kernels does not reak havok on batterystats.bin???? Because i was lead 2 believe that flashing put weird stuff into that file and that deleting it after a flash was good so it could generate a new 1 4 new rom/kernel
 
+Dianne Hackborn Are you aware that sometimes programs that heavily use sensors are reported as extremely high battery users while in fact they are not running at all (i.e. they were killed by task manager). I have examples where this state survived even the reset at the full charge. After removing the handset from the charger (fully charged), some data recorded when the app started to use the sensor still remains (this data was somehow not deleted when the app released the sensor). This creates an effect like the app would constantly drain the battery IF the phone is in sleep mode. (The accounted power use is (current time - sensor use start time)*sensorPowerDraw. This effect is mostly visible on Samsung phones (even on GNexus). I believe Samsung provides correct data in the power profile while other vendors just say that sensors do not drain. I was not able to reliably reproduce this, but I see happen it time to time with several apps that heavily use sensors. Any thought on it? My users are regularly complaining and I blame it on the firmware, but it would be great to solve this in the platform...
 
I'm hoping you can help me with a battery problem. I have a rooted Motorola Atrix 4G (MB860). The bottom line (I don't think that the "why", or "how", really matters) is that my phone no longer recognizes the battery (possible "cooked" A/D channel, I've heard). I'm sure that there are system files that control this. If you can help me locate the actual battery function files, I'd love to fix/ replace the damaged software. I've been @ this for quite a while, & have access to "stock" installation files. Unless, of course, the damage hardware related (it's fully functional, other than battery recognition issue), I'd love to @ least get some sort of answer to this ongoing mystery. Thank you greatly
 
Hi i'm modifying the kernel for galaxy ace S5830... I have realized that battery indicator refreshes when it comes back from sleep... and drop really... I checked the debug for the battery driver (cooper battery) and the service is running and reading... which driver controls the statusbar service so i can give it priority... i tried wake locks on the battery drivers but havent seen any difference
 
I feel the real question is going unanswered.  What is the cause and solution for Android battery dropping from 50% to 0% instantly?   It's not the battery.  My wife and I have the exact same phone (HTC Glacier)--if we swap batteries, hers still drops instantly, and her battery is fine in my phone.

Edit--She's also not running any more services, widgets, notifications, than me.
Tom Ta
 
If Battery Stats only gets erased when the phone charges the battery to 100%, then what happens when users use external battery chargers?

My phone is never tethered for power.  I simply rotate in a fresh battery when the phone dies and use an external A/C charger to charge the dead ones.

Will the Battery Stats file get "old, stale" and bloated?
 
+Tom Ta The specific behavior is that the stats are erased when you unplug from a power source and the battery level is high enough to be considered charged (which is around 90% full or higher).

Going for a long time without the stats being reset is not a problem because the stats are mostly aggregation, and the historical data has limits on how much it will collect.  Also stats are not collected while plugged in to a power source.
 
Hi Dianne,
it is told "I have only 5% remaining battery, the smartphone must be heruntgerfahren" when yet again physically actually wrong and the battery to 10%, then the smartphone but shut down too early and takes influence on the battery life , or it's different?
Sorry, my english isn't very good. =)
 
+Tim Förster Sorry I am having trouble understanding your question.  For what it's worth, battery stats has no impact on the reported level of the battery.  That comes either from the battery hardware or from very low-level firmware in the kernel that as far as the Android platform is concerned might as well be coming from the hardware.
Tom Ta
 
Hi Dianne, on the topic of battery life...is the Media Scanner a potential battery hog in Jelly Bean?  There have been numerous posts popping up from people with significant battery drain issues with Jelly Bean.  I've experienced this personally on two Samsung Epic 4G Touch phones and a Verizon Galaxy Nexus phone over the course of about 3wks of "normal use" (ie, no different than when we ran ICS on these phones).  The problem is that battery performance is suffering in Deep Sleep (ie, these phones used to consume 1% battery life in about an hour in Deep Sleep and now they consumer over 3% in the same state, as reported by CPU Spy).  I've tried everything I can find on the web to remedy this issue.  I've even done a factory wipe on one of the Epic 4G Touch phones and ran it for 2 days strictly "bare bones" to get a battery life measurement.  The results were the same, just over 3% drain in an hour in Deep Sleep.  Some people have suggested killing the service.  What do you think?
 
+Tom Ta Deep sleep should mean that the CPU isn't running, so there isn't really anything in user space that could impact the battery like that.  I don't know that I would trust something that claims it is measuring how much power was used during deep sleep, though. :)
Tom Ta
 
+Dianne Hackborn Oh, CPU Spy isn't actually reporting power use during Deep Sleep.  It just reports how much time was spent in Deep Sleep.  I charged the phone to 100% and let it sit for a few hours with the screen off.  Then, I turned it on and checked the % left and checked how much time it actually spent in Deep Sleep using CPU Spy.  That's how I determined how much battery was consumed during Deep Sleep.

IE:

3hrs DEEP SLEEP / 9% drain during that time = 3% per hour draining while in DEEP SLEEP.

I noticed that Media Scanner only becomes a battery hog after rebooting (or battery switch).
 
Hi Dianne,
My HTC G2 can't seem to read my battery level correctly. Is there a way for me to fix this? My phone will always read the battery at 10% even if i leave it on the charger the whole day. If i let the battery hit 0% it will shut off obviously and i wont be able to turn it back on. Now if i were to take out my battery and place it into my brothers phone(also a G2) and turn it on. It will turn on and read at 40-50% battery power left. Is there something on my phone that I can edit to fix my power reading issue? I have tried deleting that /data/system/batterystats.bin file you were talking about. but that doesn't do anything either. also if i take my brothers battery which reads 100% on his phone and place it into my phone. It will show 30% and quickly drain the battery as if it were over charged(phone also gets really hot really fast). power level will read 8% within an hour. 
 
+Neil Maglonso The reported battery level is generated by either the hardware or a very hardware-specific device driver in the kernel that estimates it.  If you are getting the same behavior, it is probably a hardware device estimating the battery wrong (so presumably that device doesn't use a smart battery).  The way this works is very hardware-dependent, so you'd need to talk with someone who knows that specific device or possibly class of devices from HTC.
 
so basically something is wrong with the phone's hardware wise, right? So no amount of flashing roms or different HBoots will save me  :(
 
+Neil Maglonso I don't know.  If it doesn't have a smart battery, then there is likely low-level firmware that is approximating the battery level.  It could have some state it saves around somewhere to help this approximation (keeping track of the number of charge cycles or whatever) that is causing the problem.  This is just outside of the areas I can address.
 
Hey, my battery stats according to multiple different apps on my phone seem very strange. When my the voltage readings of my battery seem to sugges the voltage readings of my battery seem to suggest differently. For instance when I have 5 percent left on my phone my milivolts are over 3000. A full charge on my phone reads approx. 4117 mv, but when my phone consistantly is at or around 10% the voltage still reads over 3000 mv. I can't figure this one out. Any suggestions are appriciated.
 
There's a link to here in a forum discussion on battery problems. Regarding Media Scanner, there are at least two different issues.

One is possibly trivial--Media Scanner seems to be showing up a lot more in checks of battery use under normal operation on Jelly Bean, but overall this may or may not be affecting performance. It often does continue for a long time, making me wonder if this is normal.

Then there is the more serious issue, which I encountered last week on a Galaxy Nexus. Media Scanner will start to run and never stop, draining the battery in a few hours. Checking battery usage shows very high numbers for Media, greatly surpassing even Screen.

There are lots of theories on various sites as to the problems and fixes. The most common belief is that Media Scanner gets stuck on a bad file and never stops trying to scan it.

Trouble shooting this is hard because Media Scanner comes on under normal circumstances and sometimes continues to run for a few hours. This makes it hard to tell if an attempted fix really is doing anything or if just reached the point where it is no longer running. As a consequence, there are many suggestions at various sites which do not help and which I suspect people did when Media Scanner would normally stop.

After trying a lot of other proposed fixes I deleted a large number of media files. Media Scanner continued running. Perhaps I didn't give it enough time, but as it still didn't seem fixed I tried going back to a Nandroid backup (which other people say did not help if done as sole attempt at fixing). Finally Media Scanner stopped running and I've been gradually putting files back on.

Since then I've had a couple of times in which it started up again and did not seem like it was going to stop. I wound up going to bed with the phone plugged in. In the morning Media Scanner was no longer running making me wonder if prolonged running is normal as long as it eventually stops, or if this is still abnormal.

From doing Google searches when I had the more serious problem (Media Scanner never stopping) I found that many people are having this problem. It would help if there was a fix short of deleting tons of files and possibly having to revert with a Nandroid backup (which not everyone has).
Tom Ta
 
@Ron Chusid, all things being equal (ie, same amount of media files on internal & external storage with different versions of Android), Media Scanner was never an issue before Jelly Bean.
 
I've never noticed any problems until Jelly Bean but doing searches on the issue I'm finding people complaining about it after going to ICS.

Again there are at least two issues. I've solved the problem of Media Scanner running without stop, killing the battery in a few hours.

Since then I find (as others report) than Media Scanner runs whenever rebooting. It doesn't go forever, but it does run for over an hour, quickly knocking the battery power down to around 80 percent. 

So far I haven't been in situation where this mattered, but often when traveling I'll run down the first battery over the course of the day and have to switch to a different one. That mean rebooting, leading to the second battery winding up with less power.
 
  I am one of the people who used to delete battery stats (once a week) and I feel like you are laughing to my face with last paragraph. You should instead fix battery calibration problem that no doubt exists on Android for many years, which causes phone to turn of at XX% and don't charge over XX%.
  And while I believe now deleting that file doesn't change anything, rest of the process certainly does.
 
+Lukáš Kliment Since you haven't said what device(s) you are using, there isn't much I can address.  As I have tried to indicate, the battery level shown and how it charges happens way down in the hardware-specific code, separate from Android.  Also manufacturers may decide some different percentage to turn off at, depending on how their battery works, or the way the battery determines its current percentage may result in it jumping from small percent to 0; again this is totally outside of the Android platform, we are just using what we get.

(You need to keep in mind, reported battery level is to a lesser or greater degree an approximation.  Worst case, the battery itself doesn't report any information about this at all, so very low-level code on the device looks at all of the things it is doing to estimate the current draw and compute what level the battery is at.  Smart batteries put this tracking into the battery itself, which is much more accurate, but still has a lot of approximation -- the battery can compute the actual current draw from it, but the actual total available power available in the battery will vary depending on the temperature, age of the battery, etc.)

As far as not charging over XX%, this is actually a basic part of how these batteries work.  They never charge up to 100%.  Correctly working hardware will generally have a pattern like changing up to some high 9x%, then stop charging to let it go down to some low 9x%, and charge back up again.  It is important to do this or else you will greatly reduce the battery life.  On some devices this behavior is shown in the UI, on some it isn't.  I know that some manufacturers fake the reported battery level when in this situation to hide what is going on.  For our Nexus devices, we have generally taken the position that we want to report the real value and not hide it.
 
  I think it is not true that android doesn't store battery level anywhere and just reads it from hardware. Because I am sure that after flashing custom rom or restoring nandroid backup battery indicator often goes crazy. 
  
  Not charging past 60%(or 30%,80%); jumping from 20% to shutdown; discharging at a rate of several percent per minute; staying at XX% for twenty minutes; showing significantly more or less charge after reboot. It happened on my G1, Desire and ZTE Blade. Convoluted guides that people came up with: http://goo.gl/BXl7b are solving this problem.

  There is a lot of people who experience this after flashing: http://goo.gl/tPd6P And to lesser extent it happens even with normal use, not just after flashing rom.

 edit: I am not sure whether it affects actual battery life or just battery percentage what is shown.
 
+Dianne Hackborn
I have an HTC Desire running CM7. Could you tell me please:
a) Is the hardware-specific code that determines battery level found in CM7 or does my phone still have HTC code on it somewhere?
b) My phone turns off at somewhere between 15-30% - is that HTC's choice? Can I change it?
Thanks
 
@Dianne Hackborn and others....
I use a micromax funbook p300. Ice Cream Sandwich (4.0.3). My tablet shuts down at 75%. So I calibrated it many times. Nothing happened. Then one day, my tab was going to shutdown and i deleted the batterystats.bin file and now, when the battery is around 2% in real, my tab shows a 100% battery.

1) Please tell me a solution to this.
2) Does this mean that batterystats.bin has something to do with the battery indicator 
 
Hmm, I'm not really sure this is true. I did battery stats wipe in CWR, and my phone started to misbehave, i.e. report full discharge in a few hours. Then I used "Battery Calibrate Pro" (but blocking the internet access for it in DroidWall!) - and my battery now lasts for a couple of days! So I tend to believe what I see, not what I read! 
 
Honestly.  batterystats.bin DOES NOTHING TO HOW THE BATTERY IS REPORTED.  If you don't believe me, you can look at the code yourself.

Here is the code that reads and writes the file: https://code.google.com/p/android-source-browsing/source/browse/core/java/com/android/internal/os/BatteryStatsImpl.java?repo=platform--frameworks--base

You will not find anything in there that impacts the current reported battery level -- this code is receiving the battery level from the lower-level system, and only using it to keep track of that is part of the battery history.  That battery history is only used to show the graph in the power usage chart.
 
Another way to look at this -- BatteryStatsImpl completely owns the batterystats.bin file.  However, it is just a class, it needs to run in something else.  That something else BatteryStatsService, here: https://code.google.com/p/android-source-browsing/source/browse/services/java/com/android/server/am/BatteryStatsService.java?repo=platform--frameworks--base

If you look at BatteryStatsService, it is almost entirely incoming calls -- telling it about things changing, since its purpose is to track them.  The only things that get data out of it are isOnBattery(), getAwakeTimeBattery(), getAwakeTimePlugged(), and getStatistics().  The first three will give you no information about the battery level.  The last one gives you a complete copy of all the stats (including history chart and everything), which does happen to include the last recorded battery level amongst everything else, but that would be a crazy way to find out the battery level.  You should find that it is only called in one place in the entire platform, in the settings app: https://code.google.com/p/android-source-browsing/source/browse/src/com/android/settings/fuelgauge/PowerUsageSummary.java?repo=platform--packages--apps--settings

The part of the system that is actually responsible for reporting the battery level is BatteryService: https://code.google.com/p/android-source-browsing/source/browse/services/java/com/android/server/BatteryService.java?repo=platform--frameworks--base

You'll see this is the code that reads the kernel level from the kernel, and turns it into the user-space public API (broadcasting the data and such).  The only interaction it has with BatteryStatsImpl is through its public IBatteryStatsService API which is what we saw that BatteryStatsService implements, consisting only of calls to report the current state: the call to setBatteryState().
Tom Ta
 
+Ron Chusid As is the case with me.  I'm totally untethered when charging, ie, a battery swapper type of user.  So, everytime I swap in a fresh battery, I always lose 15-20% as well thanks to Media Scanner in Jelly Bean.

Some folks at XDA have started to add .nomedia files to every folder they want skipped but that is just too much up keep and maintenance, and for users like my mom, you can forget about it.

Google needs to address this issue in the next update.
 
So what I got from all this is that the best way to "calibrate" your battery has nothing to do with batterystats.bin but instead (and it works for me) every time I flash new firmware I will need to run the phone until it gets to 0% and shuts off, then charge it all the way back up to 100%. at the point I unplug it, it runs for much longer that second time, and that's a kernelspace or hardware-specific limits that are being set here, and this is not batterystats.bin-related whatsoever.
 
It was a good idea to remove it. From my own experience, when i flash a new ROM and i use battery wipe, i notice when the phone is back on the battery depletes rapidly. Not sure why, but usually wait till it is completely drain and do a full charge before i get longer hours of battery life. So their choice to remove it is a +1 for me. 
 
+Dianne Hackborn ok so i get that the batterystat.bin does not do anything... but when flashing a new rom,, does having multiple battery cycles affect the battery drainage? Thank you :)
 
Not sure if i does. I have ORD and I haven't noticed drainage when i switch roms and I do switch alot. 
 
I notice issues within different roms or even when I add a new battery to my device.   The only way I have been able to get accurate measurements on battery life within Android is to cover the center two pins on my battery when booting my device (of course not the + or -) and it should boot with no reading on levels.    Then I wipe stats, reboot the device and the readings are correct.    This seems to "force" Android to generate correct info for the battery within the given scenario. 

 It really helped me out when I added a 3500mAh to my device as it was stuck on 1% for over a day and wiping battery stats made no difference, but the above technique helped solve my issue.
 
but ... to delete the battery stats makes me feel better LOL
 
My indicator shows 100% all the time regardless of the actual charge. It will stay this way until it shuts off. If I connect it to the charger and power it on it will rapidly drop to about 3 or 4% and slowly start to climb up again. If I shut it off and power it back on again it shows 100% again, no matter what the actual charge is.

Is there a way to solve this annoying glitch? I haven't figured out how to root my device yet...
 
Dear Dianne,
I'm trying to find out the percentage of battery used by each applications from the time it's opened and closed. According to the reviews it is not possible to that. is it so? 

Kindly reply to this comment and any sort of help would be highly appreciated.

Thanks in advance.

Regards,
Thenna.
 
+davin bonham That sounds like either a battery problem (if your device has a smart battery that reports its level) or a problem in the low-level firmware that estimates the battery level.

+thenn arasu First you need to define "opened" and "closed".  But generally, no, the battery stats just keeps track of operations performed per-uid (not even per-app) since the battery was charged while it was running on battery.
 
+Dianne Hackborn Thanks for your reply :) If I connect my tablet to the charger while it is powered on it corrects itself and the indicator functions normally but if I reboot the device while it is not connected to the charger it immediately returns to 100% regardless of how much juice the battery has. If it is a smart battery then it probably didn't finish school... I would guess it is the low-level firmware you mentioned. I guess replacing the battery would answer that question but since it is just a minor (albeit annoying) inconvenience and the battery is otherwise healthy, maybe I'll wait to see if a fix is found. I'm not the only one with this problem... Thanks again for your reply!
 
Guys, my galaxy nexus just charge until 82 percent since a month ago, I tried with the original chager and Nexus 7 charger and same results. Any idea?
 
Thanks +Manfred Hofbauer , the I tried with battery callibration (avaliable on playstore) but i think that nothing happened (my phone is rooted) or at least, the issue was not solved.
Do you know any custom recovery to wipe the stat? i tried with the recovery available with nexus root toolkit and i do not see the option, neither with clockwork recovery that should have this option on advance....
If you can send me the link to download the CR that contain this option i really appreciate it
 
Yes, i think that i got the idea what batterystats do. But... the issue that i have is that my phone detects 30 less percent of battery level, when battery is on 90%, it shows around 60%. (i checked with another gnex changing batteries)
Now.... if the battery is at 1%, it should remaing 30% and phone should not power off... but my gnex is powering off!!
I would need to know where android is taking the level of battery. The replacement of usb port with the charger panel and bla bla should help me?
 
+Jorge Sassone Interesting - I'm seeing something similar since a few days. Battery level is reported as 24% in my ROM, but as 92% in 4Ext recovery. The amount of mAh is also more close to 92% (e.g. 3800 mAh, where a full charge is 4200 mAh). HTC Sensation with stock battery. Changing battery does not help. Reset to factory defaults, reflash do not help either.
 
This needs rewriting. Sure, I understand it and its informative (though, common sense), but for example, your first statement after your quote is "no, it does not." It really should read "no it is not". Your 6th paragraph is not needed because you could rewrite your fifth paragraph: "it has no impact on your current battery level, or indeed your battery life." The word "well", after your ellipsis should be capitalised and you don't need to say "thus why" because "thus" on it's own will suffice.

Okay, so it was informative, I just don't like the way Google misuses grammar and then tries to make everyone else misuse grammar with their articles and search terms.
 
+Cody Henschel Great idea,ive had that on my mind but it need deep root development that costs hundrets to be done ;x 
 
Hi +Dianne Hackborn  I am having an issue with my Nexus 4. It dies at 36% battery and when I plug it back in and start it up it shows 0% battery. I've tried charging it to a 100% (left it over night for 3:30 hours) charging via usb but it again ran out around 36%.
Could you help me out here?
 
Hi +Dianne Hackborn  I bought a new 10.1' rockchip cortax A9 processor 1550ghz based tablet a month ago(Spice MI 1010). It is 4.1JB with a huge 7600Mah LI-Po battery.As i charge it to full 100% & turn it on the battery level always drops sharply to 97% in next 10 to 12 mnts & from here onwards it gets stable.The second problem is as i turn it off after a small use of 10/15 mnts after charge (batt. level around 97% as mentioned above) & switch off & on next restart the previous usage time of 10 or 12 mnts whatever gets reset to 0 mnts while it maintains same battery level of last time when it is switch off(97% or whatever it was remains) i wanna know why battery drops sharply to 97 % after full charge in just 12 mnts & why on next restart the previous usage of 10 mnts is deleted & resets it self to 0 mnts?? Do i need to reset tab or is it normal ??..or what is remedy ???
Add a comment...