Android-x86

Run Android on your PC

How to Configure Battery Service

Android battery service was developed with only one type of battery and power management in mind. When running Android on the different hardware platforms, the battery status often shows up incorrectly. To resolve this issue, we have developed an easier method of supporting different platforms and battery types. This document explains how to configure the android-x86 platform to support different type of batteries.

Battery Status sysfs Path Problem

In Linux, applications collect the battery status through sysfs, where the battery status is located in /sys/class/power_supply/. Different platforms, however, may give you a different directory layout under /sys/class/power_supply/, but Android hardcodes the directory layout to /sys/class/power_supply/. To resolve this issue, I have added new entries in vendor/asus/eeepc/system.prop, where the user can change the value of these entries to correctly configure the sysfs directory layout for different platforms.

These entries are:

                  ro.sys.fs.power_supply.ac=/AC0

                  ro.sys.fs.power_supply.bat=/BAT0

                  ro.sys.fs.power_supply.ac.feature.online=/online

                  ro.sys.fs.power_supply.bat.feature.status=/status

                  ro.sys.fs.power_supply.bat.feature.present=/present

                  ro.sys.fs.power_supply.bat.feature.capacity.now=/charge_now

                  ro.sys.fs.power_supply.bat.feature.capacity.full=/charge_full

                  ro.sys.fs.power_supply.bat.feature.voltage.now=/voltage_now

                  ro.sys.fs.power_supply.bat.feature.voltage.full=/voltage_full

                  ro.sys.fs.power_supply.bat.feature.tech=/technology

                  #ro.sys.fs.power_supply.bat.features.bat.health is not supported

                  #ro.sys.fs.power_supply.bat.features.bat.temperature is not supported

In essence, these entries tell the Android battery service code to look for the information in the correct place.

UEVENT Name Problem

There is another issue with vold. vold catches the uevent for power supplier type changing events. Unfortunately, on different platforms, the name of the uevent may be different, but Android vold hardcodes the uevent name. To resolve this issue, I have added an additional two entries in the system.prop to allow vold to use the uevent names based on the user configuration. These two new entries are:

                        ro.power_supply.uevent.name.capacity.now=POWER_SUPPLY_CHARGE_NOW

                        ro.power_supply.uevent.name.capacity.full=POWER_SUPPLY_CHARGE_FULL

After installation, the system.prop will be installed in /system/build.prop. The user can modify this file during run time and reboot the system, allowing the change to take effect.

Battery Status Value Calculation

The X86 platform often connects the battery through ACPI, therefore the exposure of the battery status follows the ACPI standard. Very important is how the battery energy level is calculated. Below is what I've copied from ACPI spec:

                      Remaining Battery Percentage[%] 

                      = (Battery Remaining Capacity [mAh/mWh]/Last Full Charged Capacity [mAh/mWh])* 100

The Android standard platform (G1) however does not follow this model. On the G1, the kernel will push the "Remaining Battery Percentage" to the sysfs entries directly.
Currently Android-x86 code tries to support both cases. If the user specifies ro.sys.fs.power_supply.bat.feature.capacity.full, then the "Remaining Battery Percentage" will be calculated following the Android model, otherwise, it will be calculated by Android's original way.

User Specific Implementation

To implement your own battery status handling code, simply re-implement the IBatteryServiceStatus class in frameworks/base/libs/utils/IBatteryServiceStatus.cpp, replacing frameworks/base/libs/utils/BatteryServiceStatus.cpp with your own implementation.