Tag Archives: stats

Why Android sucks at managing battery drain and discharge

So here is my second rant about disliking Android.

I should mention now that I am a happy user of this OS on my HD2 since a while ago, after discovering that CalenGoo is a great substitute for Microsoft’s Pocket Outlook calendar, and that HanDBase in its Android version can be tricked into doing the same things of its Windows Mobile counterpart even if a key feature is missing.

So well, what I’m ranting about today is battery management, or should I say “Battery stats what the hell”?

Just a short anecdote: I went to sleep yesterday at 0:30am, battery percentage reading 58%, I woke up this morning at 8am (in the middle there was a scheduled Titanium Backup of modified data, followed by a reboot, and half an hour of scheduled WiFi with 15′ checks of 6 mailboxes, and obviously mobile network on). When I woke up, battery was at only 14%. Astonished, I deleted the battery stats and rebooted, after that it was reading 2% (!!!). To be noted, battery history, reported by Battery Monitor Widget, tells me that the battery voltage at the moment of getting in the bed was 3.85V, and when I woke up it was 3.79V. Also, the battery current output (which has an exact reading on this HD2, since HTC cares for stuff like this, unlike Samsung), is in a 4-7mA figure all night long, except only when Titanium Backup and mail checks kicked in.

All in all, considering the 2% charge reboot, my phone is telling me, or at least Android is, that it drained 56% of battery in a 7.5hrs period, without doing practically anything. Let’s shave off 10% due to the Titanium Backup and the WiFi checking (I’d say 3-4% is a more realistinc estimate, but oh well), it’s still almost 50% of the battery that disappeared for no reason.

Also to be noted that I put this battery in yesterday morning, it was 98%, and I used it all day long for some calls, a little web browsing in the morning, agenda activity, budget monitoring, and so on. It didn’t drain as much in a 16 hours span, than it did in 7.5hrs of inactivity during the night.
Now, obviously it DID drain more during the day, but Android tells me the other way around. My question is: WHY?

I have 4 batteries, I just swap them out when they are at 10% or so, and put in another charged one. This has led me to up to 4days uptime on Windows Mobile; sure these batteries have aged, but not so much to not even last a couple days with mild usage. Now I understand better what I wrote in this post, calibration does make sense, but only because of a HUGE Android shortcoming (and only if you, unlike me, ever use just one battery). Windows Mobile on this phone never failed reading proper battery, with no “stats” whatsoever.

Now, regarding mV: nominal voltage of a Li-Ion battery is 3.7V, but the charging voltage is 4.2V, so actually a 100% charged LiIon battery has a voltage of 4.2V (or rather 4199mV). That means, for the phone, that the battery was fully charged. As so, the discharged voltage is obviously not 3.7V, but lower than that. What the device (or software?) decides to be 0% is up to the manifacturer, a fact is that most LiIon batteries have a cutoff at 3.0V to prevent damage to the battery, some of them have a cut-off even lower, at 2.5V.

Let’s say it’s not safe to assume that 3000mV is our 0%, let’s say our “0% charge” voltage is 3400mV.

Now, please tell me, WHY is Android reporting 4% battery left (I just briefly attached it to the USB to sync calendar) when the voltage right now is greater than 3700mV? This would mean higher than 50% residual charge, which is just reasonable, since it was 58% before going to bed, and it did no more than 7% worth of stuff during the night, but Android will still insist for it to be 4%. This reminds me of something I read somewhere on XDA, about this user who had two batteries for his phone, a “vanilla” one with normal capacity, and an extended one with almost double capacity. Android would insist reporting 0% on that second extended battery based on the “statistics” of the first battery, thus forcedfully shutting down the device when the residual charge of the extended battery was at least 40%.
This is the stupidest thing I can conceive about a modern operating system.

And yes, I know the battery state of charge cannot be determined by voltage alone, because it is influenced also by temperature and kind of usage until that moment, but surely enough 3700mV is NOT 4% residual charge, it surely enough is more like 50%. We are not talking precise, 1% step-by-step measurement, but wide-range precision measurement. And there is a hell lot of difference between 50% and 4%, it’s called 46%.

The programmer at Google who coded these routines must be a guy affected by a severe form of OCD, and who throws away his gingerbread cookies 6 months before the expiration date, just to be on the safe side (pun intended). But you know, OCD guy, I like my batteries to last all they can instead of having your OS shut down my device a lot sooner than needed.

Which brings us back on track: “battery statistics”: what ARE they? Do they even make sense? How can a discharge cycle affect in any way the subsequent one? Maybe I was bored at work and read some manga keeping the screen on, maybe I was busy like hell and didn’t have time to play with the phone, maybe I was on a trip and out of boredome started watching an episode of Sex And The City after another. So what.
Again, Windows Mobile had no battery stats whatsoever, but never failed to read battery charge properly. Nor any 10-years-old Nokia phone had battery stats, but they still had LiIon batteries.

Yes, I also know what “battery lookup tables” are, and how they are useful in determining battery state of charge more precisely. But it’s clear they are not working at all on Android, and actually are anti-productive for those like me who swap out discharged batteries rather tan charge them inside the phone. I despise you, OCD google guy.