Android Battery Management system from the upper Java to the underlying driver call (reprint)

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 used for monitoring the battery status (battery level, 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 attributes are escalated to the upper-level app in the Batteryservice.java by means of a broadcast. use. 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:

About Java and c/C + + intermodulation problem, here is no longer redundant, there are 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 already been defined in the header of the file, corresponding to the path:/sys/class/power_supply, then traverse the entire folder to find various properties of each energy supply device, such as 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 portion of the Android system inherits the power supply driver architecture from the traditional Linux system, and the battery driver generates the appropriate SYS file system via the power supply driver. This provides the interface to the user space for various properties of the battery. 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 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 can be seen here, the AC, USB and battery three Power Supply devices are registered to 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 tell what device is charging the current system by judging the online status of AC and USB. While battery creates many properties related to battery , such as status, health, present, capacity, batt_vol, etc. The top-level app can monitor the battery's current operating 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 that, due to the battery characteristics, the switch on the time of the 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, Since the user may replace the battery, the difference between the two is controlled in the range of 20%, that is, the actual detected power value in the RTC saved in the UI battery value of 20% in the range of the UI battery saved in the RTC as the current battery power value If the actual detected battery value exceeds 20% of the UI power value in RTC, the user is considered to have replaced the battery, using the actual detected power value as the current battery's 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.

Android Battery Management system from the upper Java to the underlying driver call (reprint)