5

There are several posts on how to calibrate android batteries but none describe its working. How is it that the system can determine at what voltage the battery is considered to be charged (100% or say 4200mV) and what voltage is considered to be discharged (0% or 3400mV)?

"Android stops the battery from charging when reaching 100%" but if it is calibrated wrong, how come it wont stop charging at another voltage (say 4100mV) or even continue discharging at a voltage below its normal operation (say 3200mV)?

Expected answer:

  • The actual technical insight on how android determines the current battery level

Edit 1: I am stressing that my question has nothing to do with battery statistics and how much battery apps have used but solely on the procedure involved with determining the battery %

This is my first question please excuse any conventions I may have missed

  • I don't know if this answers your question but doesn't Android get battery voltage and level info from the kernel? – aureljared Jun 21 '14 at 13:54
  • @aureljared it would if you could say that definitively along with a reference. And if so, it would be great if you could point me to the actual process of determining the battery percentage level from the actual hardware readings. Thanks in advance! – reubenjohn Jun 21 '14 at 14:03
  • 1
    This is a very interesting question. For the nexus 5 (which I own), an algorithm for calibrating the battery readouts is given here: androidpit.com/… What mystifies me, though, is that this definitely seems like a hack of the OS/battery manager firmware code. Does anyone have specific references in the android code (or maybe a firmware snippet) that identifies why this works? (Ideally, the algorithm for how to determine when to trigger the "reset" of the battery statistics). – jwir3 Oct 9 '15 at 0:12
1

Looking through the android source code recently (I'm new to android building and am still getting used to what makes android tick), I came across a file somewhere that had all sorts of calibration statistics and figures.

All of the figures are set by the vendor of the device itself. From how many mAhs the battery holds, to what values different device features affect the battery (like WiFi scanning, screen brightness etc).

I would assume that it is these figures (from the vendor), that the kernel uses to help itself calculate battery level.

Also, batteries come with little chips in them these days, to provide overcharge protection etc. The chip quite possibly reports on it's health status to the device. But that is merely just a personal assumption based on the fact that I don't use a stock battery (I use a zero lemon in my i9300 which triples my life between charges), and my phone knows the difference (it doesn't drop the same percentage in a given time compared to stock).

I hope this helps!!

  • Very convincing and elegant! But just to confirm, technically you are saying that the OS combines its hardware reading of voltage with preset values set by the vendor (or read from the battery's chip) to determine the current battery percentage using some kind or formula? This definitely requires references or for starters where you found such a file! – reubenjohn Aug 31 '14 at 12:10
0

It has no effect on battery life, but it just resets the battery consumption statistics, that is It notes battery changes between different activities...

But this is what google engineer Diane Hackborn posted on his G+

"This file [batterystats.bin] 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."

  • 1
    Understood (I have read his post earlier) batterystats.bin is not responsible for determining the current battery % but what is and how does it work? -(clarification: my question has nothing to do with how the per app battery statistics are produced) – reubenjohn Jan 29 '14 at 8:52
  • Battery calibration deletes this file, forcing android to get these statistics again. Remember u will be asked to calibrate once reaches 100 percent, and u will be asked to drain it to 0%.. The statistics are collected from scratch.. In that way u will have proper battery indication (think updated apps may consume less battery) – user52093 Jan 29 '14 at 8:58
  • I do not understand! If the stats are deleted, then how can i trust that if I charge it to 100% that it is actually the upper limit of my battery (since the stats are deleted, android is showing a false indication of my battery!) Moreover, you still haven't said where it is storing the new information! Just that batterystats.bin does not! I was expecting a detailed explanation of its working! Please be more technical! – reubenjohn Jan 29 '14 at 9:10
  • "The BatteryManager broadcasts all battery and charging details in a sticky Intent that includes the charging status." Battery indication has nothing to do with the batterystats.bin, battery stats bin is used only for indicating the battery use... Refer here developer.android.com/training/monitoring-device-state/… – user52093 Jan 29 '14 at 9:33
  • I appreciate your research and I hate to be fussy but after reading the article I found that it is not related to battery calibration and doesn't exactly answer my question specifically it says "battery% = level / (float)scale" but how does an un calibrated device obtain the battery scale. However the article has proved to be very interesting and does answer few other questions. But nothing related to technical details behind battery calibration :( – reubenjohn Jan 29 '14 at 10:03
0

Stored in the kernel. Compiled using known values for specific hardware. Flashed to ROM. Reads the current value. Percentifies it.

  • 1
    Brilliant @jay ! Makes a lot of sense. This was the answer I was expecting! However again it lacks backup references and has an overall ambiguity in its wording. Please edit, this is potentially the accepted answer thanks in advance – reubenjohn Sep 2 '14 at 8:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.