Battery usage information is derived from battery usage statistics and power profile values.
The framework automatically determines battery usage statistics by tracking how long device components spend in different states. As components (Wi-Fi chipset, cellular radio, Bluetooth, GPS, display, CPU) change states (OFF/ON, idle/full power, low/high brightness, etc.), the controlling service reports to the framework BatteryStats service. BatteryStats collects information over time and stores it for use across reboots. The service doesn’t track battery current draw directly, but instead collects timing information that can be used to approximate battery consumption by different components.
The framework gathers statistics using the following methods:
Resource consumption is associated with the application using the resource. When multiple applications simultaneously use a resource (such as wakelocks that prevent the system from suspending), the framework spreads consumption across those applications, although not necessarily equally.
To avoid losing usage statistics for a shutdown event, which may indicate battery power consumption problems (i.e. shutdown occurs because the battery reached zero remaining capacity), the framework flashes statistics approximately every 30 minutes.
Battery usage statistics are handled entirely by the framework and do not require OEM modifications.
Caution: Device manufacturers must provide a component power profile that defines the current consumption value for the component and the approximate battery drain caused by the component over time. This profile is defined in platform/frameworks/base/core/res/res/xml/power_profile.xml. See the Power Values table for guidance on these settings.
Within a power profile, power consumption is specified in milliamps (mA) of current draw at a nominal voltage and can be a fractional value specified in microamps (uA). The value should be the mA consumed at the battery and not a value applicable to a power rail that does not correspond to current consumed from the battery.
For example, a display power profile specifies the mA of current required to keep the display on at minimum brightness and at maximum brightness. To determine the power cost (i.e the battery drained by the display component) of keeping the display on, the framework tracks the time spent at each brightness level, then multiplies those time intervals by an interpolated display brightness cost.
The framework also multiplies the CPU time for each application by the mA required to run the CPU at a specific speed. This calculation establishes a comparative ranking of how much battery an application consumes by executing CPU code (time as the foreground app and total time including background activity are reported separately).
You can determine individual component power consumption by comparing the current drawn by the device when the component is in the desired state (on, active, scanning, etc.) and when the component is off. Measure the average instantaneous current drawn on the device at a nominal voltage using an external power monitor, such as a bench power supply or specialized battery-monitoring tools (such as Monsoon Solution Inc. Power Monitor and Power Tool software).
Note: Manufacturers often supply information about the current consumed by an individual component. Use this information if it accurately represents the current drawn from the device battery in practice. However, validate manufacturer-provided values before using those values in your device power profile.
When measuring, ensure the device does not have a connection to an external charge source, such as a USB connection to a development host used when running Android Debug Bridge (adb). The device under test might draw current from the host, thus lowering measurements at the battery. Avoid USB On-The-Go (OTG) connections, as the OTG device might draw current from the device under test.
Excluding the component being measured, the system should run at a constant level of power consumption to avoid inaccurate measurements caused by changes in other components. System activities that can introduce unwanted changes to power measurements include:
For example, Joe Droid wants to compute the screen.on value for a device. He enables
airplane mode on the device, runs the device at a stable current state, holds the CPU speed constant
, and uses a partial wakelock to prevent system suspend. Joe then turns the device screen off and
takes a measurement (200mA). Next, Joe turns the device screen on at minimum brightness and takes
another measurement (300mA). The screen.on value is 100mA (300 - 200).
For components that don’t have a flat waveform of current consumption when active (such as cellular radio or Wi-Fi), measure the average current over time using a power monitoring tool.
When using an external power source in place of the device battery, the system might experience problems due to an unconnected battery thermistor or integrated fuel gauge pins (i.e. an invalid reading for battery temperature or remaining battery capacity could shut down the kernel or Android system). Fake batteries can provide signals on thermistor or fuel gauge pins that mimic temperature and state of charge readings for a normal system, and may also provide convenient leads for connecting to external power supplies. Alternatively, you can modify the system to ignore the invalid data from the missing battery.
This section describes how to avoid system suspend state when you don’t want it to interfere with other measurements, and how to measure the power draw of system suspend state when you do want to measure it.
System suspend can introduce unwanted variance in power measurements and place system components in low-power states inappropriate for measuring active power use. To prevent the system from suspending while the screen is off, use a temporary partial wakelock. Using a USB cable, connect the device to a development host, then issue the following command:
$ adb shell "echo temporary > /sys/power/wake_lock"
While in wake_lock, the screen off state does not trigger a system suspend. (Remember to disconnect the USB cable from the device before measuring power consumption.)
To remove the wakelock:
$ adb shell "echo temporary > /sys/power/wake_unlock"
To measure the power draw during the system suspend state, measure the value of cpu.idle in the power profile. Before measuring:
Active CPUs can be brought online or put offline, have their clock speeds and associated voltages changed (possibly also affecting memory bus speeds and other system core power states), and can enter lower power idle states while in the kernel idle loop. When measuring different CPU power states for the power profile, avoid the power draw variance when measuring other parameters. The power profile assumes all CPUs have the same available speeds and power characteristics.
While measuring CPU power, or while holding CPU power constant to make other measurements, keep
the number of CPUs brought online constant (such as having one CPU online and the rest
offline/hotplugged out). Keeping all CPUs except one in scheduling idle may product acceptable
results. Stopping the Android framework with adb shell stop can reduce system
scheduling activity.
You must specify the available CPU speeds for your device in the power profile cpu.speeds entry. To get a list of available CPU speeds, run:
adb shell cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
These speeds match the corresponding power measurements in value cpu.active.
For platforms where number of cores brought online significantly affects power consumption, you might need to modify the cpufreq driver or governor for the platform. Most platforms support controlling CPU speed using the “userspace” cpufreq governor and using sysfs interfaces to set the speed. For example, to set speed for 200MHz on a system with only 1 CPU or all CPUs sharing a common cpufreq policy, use the system console or adb shell to run the following commands:
echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo 200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq echo 200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq echo 200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
Note: The exact commands differ depending on the platform cpufreq implementation.
These commands ensure the new speed is not outside the allowed bounds, set the new speed, then print the speed at which the CPU is actually running (for verification). If the current minimum speed prior to execution is higher than 200000, you might need to reverse the order of the first two lines, or execute the first line again to drop the minimum speed prior to setting the maximum speed.
To measure current consumed by a CPU running at various speeds, use the system console place the CPU in a CPU-bound loop using the command:
# while true; do true; done
Take the measurement while the loop executes.
Some devices can limit maximum CPU speed while performing thermal throttling due to a high temperature measurement (i.e. after running CPUs at high speeds for sustained periods). Watch for such limiting, either using the system console output when taking measurements or by checking the kernel log after measuring.
For the cpu.awake value, measure the power consumed when the system is not in
suspend and not executing tasks. The CPU should be in a low-power scheduler idle loop
, possibly executing an ARM Wait For Event instruction or in an SoC-specific low-power state
with a fast-exit latency suitable for idle use.
For the cpu.active value, power needs to be measured when the
system is not in suspend mode and not executing tasks. One of the CPU (usually
the primary CPU) should be running the task, and all the other CPUs should be in
an idle state.
When measuring screen on power, ensure that other devices normally turned on when the screen is enabled are also on. For example, if the touchscreen and display backlight would normally be on when the screen is on, ensure these devices are on when you measure to get a realistic example of screen on power usage.
Some display technologies vary in power consumption according to the colors displayed, causing power measurements to vary considerably depending on what is displayed on the screen at the time of measurement. When measuring, ensure the screen is displaying something that has power characteristics of a realistic screen. Aim between the extremes of an all-black screen (which consumes the lowest power for some technologies) and an all-white screen. A common choice is a view of a schedule in the calendar app, which has a mix of white background and non-white elements.
Measure screen on power at minimum and maximum display/backlight brightness. To set minimum brightness:
Additionally, if the platform sysfs file enables turning the LCD panel, backlight, and touchscreen on and off, use the file to take measurements with the screen on and off. Otherwise, set a partial wakelock so the system does not suspend, then turn on and off the screen with the power button.
Perform Wi-Fi measurements on a relatively quiet network. Avoid introducing additional work processing high volumes of broadcast traffic that is unrelated to the activity being measured.
The wifi.on value measures the power consumed when Wi-Fi is enabled but not actively
transmitting or receiving. This is often measured as the delta between the current draw in
system suspend (sleep) state with Wi-Fi enabled vs. disabled.
The wifi.scan value measures the power consumed during a Wi-Fi scan for access
points. Applications can trigger Wi-Fi scans using the WifiManager class
startScan()API. You can also open Settings > Wi-Fi, which performs access point
scans every few seconds with an apparent jump in power consumption, but you must subtract screen
power from these measurements.
Note: Use a controlled setup (such as iperf) to generate network receive and transmit traffic.
You can determine device power consumption for Android devices that include a battery fuel gauge such as a Summit SMB347 or Maxim MAX17050 (available on many Nexus devices). Use the in-system battery fuel gauge when external measurement equipment is not available or is inconvenient to connect to a device (such as in mobile usage).
Measurements can include instantaneous current, remaining charge, battery capacity at test start and end, and more depending on the supported properties of the device (see below). For best results, perform device power measurements during long-running A/B tests that use the same device type with the same fuel gauge and same current sense resistor. Ensure the starting battery charge is the same for each device to avoid differing fuel gauge behavior at different points in the battery discharge curve.
Even with identical test environments, measurements are not guaranteed to be of high absolute accuracy. However, most inaccuracies specific to the fuel gauge and sense resistor are consistent between test runs, making comparisons between identical devices useful. We recommend running multiple tests in different configurations to identify significant differences and relative power consumption between configurations.
To read power consumption data, insert calls to the API in your testing code.
import android.os.BatteryManager; import android.os.ServiceManager; import android.content.Context; BatteryManager mBatteryManager = (BatteryManager)Context.getSystemService(Context.BATTERY_SERVICE); Long energy = mBatteryManager.getLongProperty(BatteryManager.BATTERY_PROPERTY_ENERGY_COUNTER); Slog.i(TAG, "Remaining energy = " + energy + "nWh");
Android supports the following battery fuel gauge properties:
BATTERY_PROPERTY_CHARGE_COUNTER Remaining battery capacity in microampere-hours BATTERY_PROPERTY_CURRENT_NOW Instantaneous battery current in microamperes BATTERY_PROPERTY_CURRENT_AVERAGE Average battery current in microamperes BATTERY_PROPERTY_CAPACITY Remaining battery capacity as an integer percentage BATTERY_PROPERTY_ENERGY_COUNTER Remaining energy in nanowatt-hours
Most properties are read from kernel power_supply subsystem attributes of similar names. However, the exact properties, resolution of property values, and update frequency available for a specific device depend on:
For details, see the properties available for Nexus devices.
When determining battery state-of-charge over a long period of time, the Maxim fuel gauge (MAX17050, BC15) corrects for coulomb-counter offset measurements. For measurements made over a short period of time (such as power consumption metering tests), the fuel gauge does not make corrections, making the offset the primary source of error when current measurements are too small (although no amount of time can eliminate the offset error completely).
For a typical 10mOhm sense resistor design, the offset current should be better than 1.5mA, meaning any measurement is +/-1.5mA (PCBoard layout can also affect this variation). For example, when measuring a large current (200mA) you can expect the following:
The total error is 5.5mA (2.75%). Compare this to a medium current (50mA) where the same error percentages give a total error of 7% or to a small current (15mA) where +/-1.5mA gives a total error of 10%.
For best results, we recommend measuring greater than 20mA. Gain measurement errors are systematic and repeatable, enabling you to test a device in multiple modes and get clean relative measurements (with exceptions for the 1.5mA offset).
For +/-100uA relative measurements, required measurement time depends on:
| Model | Nexus 5 |
|---|---|
| Fuel Gauge | Maxim MAX17048 fuel gauge (ModelGauge™, no coulomb counter) |
| Properties | BATTERY_PROPERTY_CAPACITY |
| Measurements | The fuel gauge does not support any measurements other than battery State Of Charge to a resolution of %/256 (1/256th of a percent of full battery capacity). |
| Model | Nexus 6 |
|---|---|
| Fuel Gauge | Maxim MAX17050 fuel gauge (a coulomb counter with Maxim ModelGauge™ adjustments), and a 10mohm current sense resistor. |
| Properties | BATTERY_PROPERTY_CAPACITY BATTERY_PROPERTY_CURRENT_NOW BATTERY_PROPERTY_CURRENT_AVERAGE BATTERY_PROPERTY_CHARGE_COUNTER BATTERY_PROPERTY_ENERGY_COUNTER |
| Measurements | CURRENT_NOW resolution 156.25uA, update period is 175.8ms. CURRENT_AVERAGE resolution 156.25uA, update period configurable 0.7s - 6.4h, default 11.25 secs. CHARGE_COUNTER (accumulated current, non-extended precision) resolution is 500uAh (raw coulomb counter read, not adjusted by fuel gauge for coulomb counter offset, plus inputs from the ModelGauge m3 algorithm including empty compensation). CHARGE_COUNTER_EXT (extended precision in kernel) resolution 8nAh. ENERGY_COUNTER is CHARGE_COUNTER_EXT at nominal voltage of 3.7V. |
| Model | Nexus 9 |
|---|---|
| Fuel Gauge | Maxim MAX17050 fuel gauge (a coulomb counter with Maxim ModelGauge™ adjustments), and a 10mohm current sense resistor. |
| Properties | BATTERY_PROPERTY_CAPACITY BATTERY_PROPERTY_CURRENT_NOW BATTERY_PROPERTY_CURRENT_AVERAGE BATTERY_PROPERTY_CHARGE_COUNTER BATTERY_PROPERTY_ENERGY_COUNTER |
| Measurements | CURRENT_NOW resolution 156.25uA, update period is 175.8ms. CURRENT_AVERAGE resolution 156.25uA, update period configurable 0.7s - 6.4h, default 11.25 secs. CHARGE_COUNTER (accumulated current, non-extended precision) resolution is 500uAh. CHARGE_COUNTER_EXT (extended precision in kernel) resolution 8nAh. ENERGY_COUNTER is CHARGE_COUNTER_EXT at nominal voltage of 3.7V. Accumulated current update period 175.8ms. ADC sampled at 175ms quantization with a 4ms sample period. Can adjust duty cycle. |
| Model | Nexus 10 |
|---|---|
| Fuel Gauge | Dallas Semiconductor DS2784 fuel gauge (a coulomb counter), with a 10mohm current sense resistor. |
| Properties | BATTERY_PROPERTY_CAPACITY BATTERY_PROPERTY_CURRENT_NOW BATTERY_PROPERTY_CURRENT_AVERAGE BATTERY_PROPERTY_CHARGE_COUNTER BATTERY_PROPERTY_ENERGY_COUNTER |
| Measurements | Current measurement (instantaneous and average) resolution is 156.3uA. CURRENT_NOW instantaneous current update period is 3.5 seconds. CURRENT_AVERAGE update period is 28 seconds (not configurable). CHARGE_COUNTER (accumulated current, non-extended precision) resolution is 625uAh. CHARGE_COUNTER_EXT (extended precision in kernel) resolution is 144nAh. ENERGY_COUNTER is CHARGE_COUNTER_EXT at nominal voltage of 3.7V. Update period for all is 3.5 seconds. |
Device manufacturers must provide a component power profile defined in <device>/frameworks/base/core/res/res/xml/power_profile.xml. To determine these values, use hardware that measures the power being used by the device and perform the various operations for which information is needed. Measure the power use during those operations and compute the values (deriving differences from other base-line power uses as appropriate).
| Name | Description | Example Value | Notes |
|---|---|---|---|
| none | Nothing | 0 | |
| screen.on | Additional power used when screen is turned on at minimum brightness. | 200mA | Includes touch controller and display backlight. At 0 brightness, not the Android minimum which tends to be 10 or 20%. |
| screen.full | Additional power used when screen is at maximum brightness, compared to screen at minimum brightness. | 100mA-300mA | A fraction of this value (based on screen brightness) is added to the screen.on value to compute the power usage of the screen. |
| bluetooth.active | Additional power used when playing audio through bluetooth A2DP. | 14mA | |
| bluetooth.on | Additional power used when bluetooth is turned on but idle. | 1.4mA | |
| wifi.on | Additional power used when Wi-Fi is turned on but not receiving, transmitting, or scanning. | 2mA | |
| wifi.active | Additional power used when transmitting or receiving over Wi-Fi. | 31mA | |
| wifi.scan | Additional power used when Wi-Fi is scanning for access points. | 100mA | |
| dsp.audio | Additional power used when audio decoding/encoding via DSP. | 14.1mA | Reserved for future use. |
| dsp.video | Additional power used when video decoding via DSP. | 54mA | Reserved for future use. |
| gps.on | Additional power used when GPS is acquiring a signal. | 50mA | |
| radio.active | Additional power used when cellular radio is transmitting/receiving. | 100mA-300mA | |
| radio.scanning | Additional power used when cellular radio is paging the tower. | 1.2mA | |
| radio.on | Additional power used when the cellular radio is on. Multi-value entry, one per signal strength (no signal, weak, moderate, strong). | 1.2mA | Some radios boost power when they search for a cell tower and do not detect a signal. These numbers could all be the same or decreasing with increasing signal strength. If you provide only one value, the same value will be used for all strengths. If you provide 2 values, the first will be for no-signal and the second for all other strengths, and so on. |
| cpu.speeds | Multi-value entry that lists each possible CPU speed in KHz. | 125000KHz, 250000KHz, 500000KHz, 1000000KHz, 1500000KHz | The number and order of entries must correspond to the mA entries in cpu.active. |
| cpu.idle | Total power drawn by the system when CPUs (and the SoC) are in system suspend state. | 3mA | |
| cpu.awake | Additional power used when CPUs are in scheduling idle state (kernel idle loop); system is not in system suspend state. | 50mA | Your platform might have more than one idle state in use with differing levels of power consumption; choose a representative idle state for longer periods of scheduler idle (several milliseconds). Examine the power graph on your measurement equipment and choose samples where the CPU is at its lowest consumption, discarding higher samples where the CPU exited idle. |
| cpu.active | Additional power used by CPUs when running at different speeds. | 100mA, 120mA, 140mA, 160mA, 200mA | Set the max speed in the kernel to each of the allowed speeds and peg the CPU at that speed. The number of entries here correspond to the number of entries in cpu.speeds, in the same order. |
| battery.capacity | The total battery capacity in mAh. | 3000mAh |
<!-- Most values are the incremental current used by a feature, in mA (measured at nominal voltage). OEMs must measure and provide actual values before shipping a device. Example real-world values are given, but are dependent on the platform and can vary significantly, so should be measured on the shipping platform with a power meter. --> 0 200 160 10 <!-- Bluetooth stereo audio playback 10.0 mA --> 1.3 0.5 30 100 12 50 50 75 1.1 <!-- Strength 0 to BINS-1 (4) --> 1.1 <!-- Different CPU speeds as reported in /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state --> 250000 500000 750000 1000000 1200000 <!-- Power consumption when CPU is idle --> 3.0 50.1 <!-- Power consumption at different speeds --> 100 <!-- 250 MHz --> 120 <!-- 500 MHz --> 140 <!-- 750 MHz --> 155 <!-- 1 GHz --> 175 <!-- 1.2 GHz --> <!-- This is the battery capacity in mAh --> 3000 <!-- Battery capacity is 3000 mAH (at 3.6 Volts) -->