1page.title=Power Profiles for Android
2@jd:body
3
4<!--
5    Copyright 2015 The Android Open Source Project
6
7    Licensed under the Apache License, Version 2.0 (the "License");
8    you may not use this file except in compliance with the License.
9    You may obtain a copy of the License at
10
11        http://www.apache.org/licenses/LICENSE-2.0
12
13    Unless required by applicable law or agreed to in writing, software
14    distributed under the License is distributed on an "AS IS" BASIS,
15    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
16    See the License for the specific language governing permissions and
17    limitations under the License.
18-->
19<div id="qv-wrapper">
20  <div id="qv">
21    <h2>In this document</h2>
22    <ol id="auto-toc"></ol>
23  </div>
24</div>
25
26<p>Battery use information is derived from battery use statistics and power profile values.</p>
27
28<h2 id="usage-statistics">Battery use statistics</h2>
29
30<p>The framework automatically determines battery use statistics by tracking how long device
31components spend in different states. As components (Wi-Fi chipset, cellular radio, Bluetooth, GPS,
32display, CPU) change states (OFF/ON, idle/full power, low/high brightness, etc.), the controlling
33service reports to the framework BatteryStats service. BatteryStats collects information over time
34and stores it for use across reboots. The service doesn’t track battery current draw directly,
35but instead collects timing information that can be used to approximate battery
36consumption by different components.</p>
37
38<p>The framework gathers statistics using the following methods:</p>
39
40<ul>
41<li><strong>Push</strong>. Services aware of component changes push state changes to the
42BatteryStats service.</li>
43<li><strong>Pull</strong>. For components such as the CPU use by apps, the framework
44automatically pulls the data at transition points (such as starting or stopping an activity) to
45take a snapshot.</li>
46</ul>
47
48<p>Resource consumption is associated with the application using the resource. When multiple
49applications simultaneously use a resource (such as wakelocks that prevent the system from
50suspending), the framework spreads consumption across those applications, although not necessarily
51equally.</p>
52
53<p>To avoid losing use statistics for a shutdown event, which may indicate battery power
54consumption problems (i.e. shutdown occurs because the battery reached zero remaining capacity),
55the framework flashes statistics approximately every 30 minutes.</p>
56
57<p>Battery use statistics are handled entirely by the framework and do not require OEM
58modifications.</p>
59
60<h2 id="profile-values">Power profile values</h2>
61
62<p class="caution"><strong>Caution:</strong> Device manufacturers must provide a component power
63profile that defines the current consumption value for the component and the approximate battery
64drain caused by the component over time. This profile is defined in
65<a href="https://android.googlesource.com/platform/frameworks/base/+/master/core/res/res/xml/power_profile.xml">platform/frameworks/base/core/res/res/xml/power_profile.xml</a>.
66For guidance on these settings, see <a href="{@docRoot}devices/tech/power/values.html">Power Values</a>.</p>
67
68<p>Within a power profile, power consumption is specified in milliamps (mA) of current draw at a
69nominal voltage and can be a fractional value specified in microamps (uA). The value should be the
70mA consumed at the battery and not a value applicable to a power rail that does not correspond to
71current consumed from the battery.</p>
72
73<p>For example, a display power profile specifies the mA of current required to keep the display on
74at minimum brightness and at maximum brightness. To determine the power cost (i.e the battery
75drained by the display component) of keeping the display on, the framework tracks the time spent at
76each brightness level, then multiplies those time intervals by an interpolated display brightness
77cost.</p>
78
79<p>The framework also multiplies the CPU time for each application by the mA required to run the
80CPU at a specific speed. This calculation establishes a comparative ranking of how much battery an
81application consumes by executing CPU code (time as the foreground app and total time including
82background activity are reported separately).</p>
83