blob: 0876ae759fa49a07512a93c6c9138d3de402b30b [file] [log] [blame]
page.title=Power Profiles for Android
Copyright 2015 The Android Open Source Project
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
See the License for the specific language governing permissions and
limitations under the License.
<div id="qv-wrapper">
<div id="qv">
<h2>In this document</h2>
<ol id="auto-toc"></ol>
<p>Battery use information is derived from battery use statistics and power profile values.</p>
<h2 id="usage-statistics">Battery use statistics</h2>
<p>The framework automatically determines battery use 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 doesnt track battery current draw directly,
but instead collects timing information that can be used to approximate battery
consumption by different components.</p>
<p>The framework gathers statistics using the following methods:</p>
<li><strong>Push</strong>. Services aware of component changes push state changes to the
BatteryStats service.</li>
<li><strong>Pull</strong>. For components such as the CPU use by apps, the framework
automatically pulls the data at transition points (such as starting or stopping an activity) to
take a snapshot.</li>
<p>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
<p>To avoid losing use 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.</p>
<p>Battery use statistics are handled entirely by the framework and do not require OEM
<h2 id="profile-values">Power profile values</h2>
<p class="caution"><strong>Caution:</strong> 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
<a href="">platform/frameworks/base/core/res/res/xml/power_profile.xml</a>.
For guidance on these settings, see <a href="{@docRoot}devices/tech/power/values.html">Power Values</a>.</p>
<p>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.</p>
<p>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
<p>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).</p>