Android Battery Management System

1. Overview

With the rapid display of mobile smart devices, battery life in a very large case induced the choice of mass consumers, Android system power management is reasonable or not directly affect the battery life, and battery system as part of it, mainly for battery status monitoring (battery power, Battery status and battery temperature, etc.). The following is a detailed analysis of Android's battery system architecture.

2. Android Battery system architecture

The management drive layer of the battery in the Android system inherits the power supply class under Linux, while in the user layer, the following battery-related properties are reported to the upper-level app in Batteryservice.java by means of broadcast. These properties are declared in Java and are invoked in the JNI update.

These properties are updated in the Com_android_server_batteryservice.cpp local code-JNI by calling the appropriate state of the battery in the SYS file system access driver layer.

3, Batteryservice

Code path:

Frameworks/base/services/java/com/android/server/batteryservice.java

Batteryservice as a battery and charging related services, mainly for the following several things: listen to uevent, read the status in Sysfs, broadcast intent.action_battery_changed.

3.1, monitoring uevent:

The Batteryservice implements two Uevenobserver Mueventobserver (as shown in the code above). Uevent is the mechanism used by the Linux kernel to proactively escalate events to user space, and for Java programs, only the virtual function Onuevent of Ueventobserver is implemented and then registered.

3.2. Read SYSFS battery status

Update reads the SYSFS file to obtain the battery information synchronously, then updates the Batteryservice member variable according to the read state, and broadcasts a intent to notify other components that are concerned about the power state. When kernel has power_supply event escalation, Mueventobserver calls the update () function, and then update calls Native_update reads the associated state from SYSFS (com_android_server_ BatteryService.cpp).

3.3. Broadcast intent.action_battery_changed

By broadcasting intent.action_battery_changed, the battery status, battery power, battery technology and other properties are packaged and sent to other users, that is, as long as the app is monitored Intent.action_battery_ Changed this broadcast, you can get the various state properties of the battery!

4. Local Code-JNI

Code path:

Frameworks/base/services/jni/com_android_server_batteryservice.cpp

This is the local code for the battery user space, calls the SYS file system access driver, and encapsulates the local method to the upper Batteryservice to isolate the platform differences.

The header of this file is defined as follows:

This is the SYS file system path generated by the underlying battery driver.

A local method is encapsulated in this file:

For upper Batteryservice use. Also, in this file, the battery attribute ID declared in the Batteryservice.java class is obtained by Getfieldid, as follows:

on The issue of the mutual tune between java and C + + , there is no more complaints, there is a lot of information on the Internet.

In this file by manipulating the appropriate SYS file system to get the various property values of the battery, take a look at the following code:

Power_supply_path has been defined in the header of the file, corresponding to the path:"/sys/class/power_supply", and then traverse the entire folder to find various properties of the various energy supply devices, The selected section is used to find the properties of the AC device.

The properties of each energy device are summarized as follows:

"/sys/class/power_supply/ac/online" AC Power Connection Status

"/sys/class/power_supply/usb/online" USB power Connection Status

"/sys/class/power_supply/battery/status" Charging status

"/sys/class/power_supply/battery/health" Battery status

"/sys/class/power_supply/battery/present" Usage status

"/sys/class/power_supply/battery/capacity" battery level

"/sys/class/power_supply/battery/batt_vol" battery voltage

"/sys/class/power_supply/battery/batt_temp" Battery temperature

"/sys/class/power_supply/battery/technology" Battery technology

When the state of the power supply device changes, driver updates the files and then sends the information to the Java layer through the local method android_server_batteryservice_update in the JNI.

5, drive 5.1, drive overview

The driver for the battery part of the Android system inherits the power supply driver architecture of the traditional Linux system, and the battery driver generates the appropriate SYS file system through the power supply driver, which provides the interface for the various properties of the battery to the user space. The Linux standard Power supply driver uses a file system path of:/sys/class/power_supply, where each subdirectory represents an energy supply device.

5.2. Drive head File

Power Supply Driver header file Kernel/include/linux/power_supply.h, the functions for registering and unregistering drivers are as follows:

Intpower_supply_register (struct device *parent,struct power_supply *psy);

Voidpower_supply_unregister (struct power_supply *psy);

structpower_supply {

Constchar *name; /* Device Name */  

Enumpower_supply_type type; /* type */  

Enumpower_supply_property *properties; /* Property Pointer */

Size_tnum_properties; /* Number of attributes */

char**supplied_to;

size_tnum_supplicants;

Int (*get_property) (struct power_supply *psy,/ * Get Properties * /

Enumpower_supply_property PSP,

Unionpower_supply_propval *val);

void (*external_power_changed) (struct power_supply *psy);

/* ...... omit part of the content */  

};

5.3. Power supply Core

Corresponding driver: power_supply

Let's take a look at this power_supply_sysfs.c file. This is primarily to create uevent! for power device properties such as the following

These uevent nodes are not necessarily created, and node creation is also related to the num_properties and properties of specific power device drivers, which can be easily seen in creating uevent function Power_supply_uevent:

5.4, Battery driver

The current project (T808, T828) used in the battery detection and management method is the POC ADC mode, the corresponding driver file is:

Mediatek/kernel/drivers/power/battery_common.c

The probe function in this file has the following contents:

As you can see, the AC, USB, and battery three power supply devices are registered in the power supply core, and the corresponding global structure variables ac_main, Usb_main, and battery_main are defined as follows:

The uevent nodes that each power supply needs to create are determined by the incoming xx_props, which is defined as follows:

Discover: AC and USB create only one online property, the upper app can know what device is charging the current system by judging the online status of AC and USB, while battery creates such as: status, health, present, Capacity, Batt_vol, and many other battery-related properties, the top-level app can monitor the battery's current working state with these battery properties uevent.

Take a look at the status update for AC online, as an example of how the status of these properties is changed to send an update message to the system.

This function is called when the show property is in power supply SYSFS, and Ac_online's unique properties as AC power are updated in Ac_update:

Ac_update will eventually be round-robin in the Bat_thread_kthread, where there is a global bmt_status, as the entire power supply device of various properties conveyed! Also look at Charging_control battery_charging_control This global function pointer, the prototype is defined as follows:

The Chr_control_interface function is prototyped as follows:

corresponding file path:

Mediatek/platform/mt6572/kernel/drivers/power/charging_hw_pmic.c

The CHARGING_FUNC function pointer array is defined as follows:

It can be seen through the following call relationships:

Will eventually be called to by:

These enumeration types are one by one corresponding functions, such as the above call relationship Charging_cmd_get_charger_type, is to get CHARGER type, the function prototype is as follows:

This is where the hardware status of the pmic gets the appropriate information.

5.5, charging error correction

The ideal battery is free of internal resistance, and the battery voltage consumption is on the external load.

But this is not the case, due to the existence of the battery internal resistance, through the direct measurement of the battery voltage (ADC) of the battery will have a certain error, regardless of whether the battery is in the state of power or discharge, this error will exist, especially when the battery is full, This error is easily perceived by the user when the battery is empty and the power off is charged, resulting in a bad user experience.

The error caused by the internal resistance of the battery can be corrected mathematically.

By knowing the internal resistance of the battery, it is easy to correct this error. But the internal resistance of the battery is not constant, but with the change in battery power changes, different models of the battery, this feature is not the same, then to get more accurate battery power, it is necessary to let the battery factory to provide a complete set of battery voltage and battery resistance of the relationship table!

Correction code of the error in charge and discharge process:

Mediatek/kernel/drivers/power/battery_meter.c

The following code is in the Oam_run:

The function mtk_imp_tracking is a v correction for the voltage drop caused by the internal resistance of the battery during charging and discharging.

Another is, due to the battery characteristics, the switch on the time of the problem of power jump, in the system using the power off the UI to save to the RTC, in the next boot process with the actual detected battery value and saved to the RTC in the UI battery value to compare, because the user may replace the battery, The difference between the two is controlled in the range of 20%, that is, the actual detected battery value in the RTC saved in the UI Power value of the 20% the range is used to save the RTC in the UI the current battery value, if the actual detected power value exceeds the RTC in UI the value of the battery 20% , the user is considered to have replaced the battery, using the actual detected battery value as the current battery power value .

The corresponding judgment code is as follows:

In the header file:

Mediate/custiom/mt6572/kernel/battery/battery/cust_battery_meter.h

is defined in the following

6, written in the last

About the battery level detection algorithm process, here no longer repeat, in the MTK released customer_training_battery_charging.pdf this file has more detailed narration.