power.jd revision 35f2fda6aaeaf733ab68a3b7f7ccc67f009c09a9
1page.title=Power Profiles for Android 2@jd:body 3 4<!-- 5 Copyright 2010 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> 27Battery usage information is derived from battery usage statistics and power profile 28values. 29</p> 30 31<h2> 32Battery Usage Statistics 33</h2> 34 35<p> 36Battery usage statistics are tracked by the framework. This involves keeping track of time 37spent by different device components in different states. This includes components such as 38WiFi chipset, Cellular Radio, Bluetooth, GPS, Display and CPU. When these components change 39state from off to on, or from idle to full power, low brightness to high brightness, etc., 40their controlling service reports to the framework’s BatteryStats service, which collects 41such information over time and persists to storage so that it is available across reboots. 42</p> 43 44<p> 45The service isn’t keeping track of battery current draw information directly. It’s collecting 46mostly timing information so that it can be used to approximate battery consumption by 47different components. 48</p> 49 50<p> 51Consumption of these resources is also (where possible) attributed to the applications using 52the resources, sometimes sharing the blame across multiple applications using a resource 53simultaneously. For instance, multiple apps could be holding wakelocks, keeping the system 54from going into suspend state. Blame is shared across these apps (not necessarily equally). 55</p> 56 57<p> 58Statistics are persisted to flash periodically (approximately every half hour or so) to avoid 59losing the information on a shutdown (such as due to battery reaching zero remaining 60capacity, which may indicate a battery power consumption problem). 61</p> 62 63<p> 64Statistics gathering can happen in two ways - push or pull. When services are aware of 65changes happening to a component, they will push state changes to the BatteryStats service. 66With components such as the CPU usage by apps, we pull the data periodically (at certain 67transition points such as starting or stopping an activity, etc) to take a snapshot. 68</p> 69 70<p> 71All of the above is automatically done by the framework, and OEMs don’t need to do anything 72in addition to that. 73</p> 74 75<h2> 76Power Profile Values 77</h2> 78 79<p> 80The power profile is where the device manufacturer needs to provide current consumption 81values for various components and their states in order to approximate the actual battery 82drain caused by these components over time. The power consumption of a component is specified 83in units of milliamps (mA) of current draw (at a nominal voltage) in the power profile, and 84can be a fractional value specifying microamps. The value specified should be the mA consumed 85at the battery (and not a value applicable to a power rail that does not correspond to 86current consumed from the battery). 87</p> 88 89<p> 90For instance, to attribute the cost of keeping the display on for a duration of time, the 91framework gathers brightness levels and times spent at each level (quantized to some number 92of bins). The power profile values specify how many milliamps of current are required to keep 93the display on at minimum brightness and at maximum brightness. The time spent at each 94brightness level can then be multiplied by an interpolated display brightness cost to compute 95an approximation of how much battery was drained by the display component. 96</p> 97 98<p> 99Similarly, CPU time for each application is multiplied by the mA to keep the CPU running at a 100certain speed to get a comparative ranking of how much battery each app is consuming due to 101executing CPU code (time as the foreground app and total time including background activity 102are reported separately). 103</p> 104 105<h2> 106Computing power consumption for individual components 107</h2> 108 109<p class="note"> 110<strong>Note:</strong> manufacturers usually supply information about how much current an 111individual component consumes. It may be possible to use these values if they are an accurate 112representation of the the current drawn from the device’s battery in practice. However, we 113encourage you validate manufacturer-provided values before entering them in your device’s 114power profile. 115</p> 116 117<p> 118Current consumption for an individual component is calculated by: 119</p> 120 121<ul> 122<li> 123Measuring the current drawn by the device when the component is in the desired state (e.g., 124on, active, or scanning) 125</li> 126<li> 127Measuring the current drawn by the device when the component is 128off 129</li> 130<li>subtracting (2) from (1).</li> 131 132 133<img></img><p class="img-caption"></p> 134<p> 135We recommend that you measure the current (usually the average instantaneous current) drawn 136on the device at a nominal voltage. This can be accomplished using a bench power supply or 137using specialized battery-monitoring tools (such as Monsoon Solution Inc.’s Power Monitor and 138Power Tool software). 139</p> 140<p> 141Take the measurements with no external charger connected to the device, including no USB 142connection to a host (as used for connecting to development hosts via the adb Android Debug 143Bridge), which may draw current from the host and lower the measurements at the battery. If 144the device supports USB On The Go (OTG) then having an OTG device connected may draw 145additional power from the device being measured, so disconnect any such OTG device. 146</p> 147<p> 148While taking measurements, you’ll want to try to keep the rest of the system other than the 149component being measured running at a constant level of power consumption, to avoid 150introducing inaccuracies in the measurements due to changes in other components. System 151activities that may introduce unwanted changes to power measurements include: 152</p> 153<ul> 154<li> 155Cellular, Wi-Fi, and Bluetooth receive, transmit, or scanning activity. You may want to put 156the device into airplane mode when not measuring cell radio power, and individually enable 157Wi-Fi or Bluetooth when appropriate. 158</li> 159<li> 160Screen/backlight on or off. The colors displayed while screen is on can also affect power 161draw on certain screen technologies. Measurements for components other than the screen on 162values should be made with screen turned off. But see the next item for an important 163consideration when the screen is off. 164</p> 165<li> 166System suspended/resumed state. When the screen is off the system may enter a suspend state 167where much of the device may be powered off or placed in a low-power state, probably 168affecting power consumption of the component being measured and possibly introducing large 169variances in power readings as the system periodically resumes to service alarms and such. 170See Controlling and Measuring System Suspend State for more instructions. 171</li> 172<li> 173CPUs changing speed and entering/exiting low-power scheduler idle state. The system may make 174frequent adjustments to the speeds of CPUs, how many CPU cores are online, and other system 175core state such as memory bus speed and voltages of power rails associated with CPUs and 176memory. If these are changing during your measurements then you may want to prevent CPU speed 177scaling operations, which may also reduce the amount of clock and voltage scaling of memory 178busses and other system core components. Scheduling activity may also affect what percentage 179of the time the CPUs spend in low-power idle states. See Controlling and Measuring CPU Speeds 180for more instructions. 181</li> 182</ul> 183<p> 184For instance, to compute the value for <code>screen.on</code>, you would run the device in a stable state, 185with CPU speed held constant, device in airplane mode, with a partial wakelock held to 186prevent system suspend. The current readings in this state should be stable. Take the reading 187- say 200mA. Now turn on the screen at minimum brightness. If the power monitor shows 300mA, 188then <code>screen.on</code> = (300 - 200) = 100mA. 189</p> 190<p> 191For components that don’t have a flat waveform of current consumption when active (such as 192the cellular radio or wifi), you may need to measure an average current over a period of 193time. Your power monitoring tool may be able to compute this average for you. 194</p> 195<p> 196Replacing the battery with an external power source may require working around problems that 197can occur due to not connecting battery thermistor or integrated fuel gauge pins. For 198example, the system might take an invalid battery temperature reading or remaining battery 199capacity reading that could cause the kernel or Android system to shut down. Sometimes these 200problems are avoided through the use of “fake batteries” that replace normal batteries for 201power measurement purposes, constructed to match the dimensions and electrical properties of 202the batteries for the product being measured. Fake batteries can provide signals on 203thermistor or fuel gauge pins that mimic temperature and state of charge readings for a 204normally running system, and may also provide convenient leads for connecting to external 205power supplies. In other cases it may be easier to modify the system to ignore the invalid 206data from the missing battery. 207</p> 208<h3> 209Controlling and Measuring System Suspend State 210</h3> 211<p> 212As mentioned above, system suspend can introduce unwanted variance in power measurements and 213place system components in low power states not appropriate for measuring active power use. 214But at some point you’ll also need to measure the power draw of system suspend state. This 215section describes how to avoid system suspend state when you don’t want it to interfere with 216other measurements, and how to measure the power draw of system suspend state when you do 217want to measure it. 218</p> 219<p> 220To avoid system suspend you can temporarily connect the device to a development host and 221issue the following command to hold a “partial wakelock”: 222</p> 223<pre> 224$ adb shell "echo temporary > /sys/power/wake_lock" 225</pre> 226<p> 227which will prevent the system from suspending while the screen is off. Disconnect the USB 228cable before making measurements. 229</p> 230<p> 231You can undo the effect of this later with: 232</p> 233<pre> 234$ adb shell "echo temporary > /sys/power/wake_unlock" 235</pre> 236<p> 237The power consumption of the system suspend state is measured for the value of cpu.idle in 238the power profile. For this measurement it may be best to place the device in airplane mode 239to avoid any concurrent activity by the cellular radio, which may run on a processor separate 240from the portions of the SoC controlled by the system suspend. To ensure the measurement is 241made while the system is in the correct state, it may be necessary to first confirm the 242current readings settle to a steady value within the expected range for the consumption of 243the suspend state of the SoC entered plus the consumption of additional system components 244that remain powered (such as the USB PHY). A system console or other external indication of 245system status (such as turning off an LED when not in suspend) may also be observed during 246the measurement. 247</p> 248<h3> 249Controlling and Measuring CPU Speeds 250</h3> 251<p> 252While active, CPUs can be brought online or put offline, change clock speeds and associated 253voltages (possibly also affecting memory bus speeds and other system core power state), and 254can enter lower power idle states while in the kernel idle loop. Not only are these different 255CPU power states measured for the power profile, it may be necessary to avoid the power draw 256variance when measuring other parameters. 257</p> 258<p> 259The power profile currently assumes all CPUs have the same available speeds and power 260characteristics. 261</p> 262<p> 263While measuring CPU power, or holding CPU power constant in order to make other measurements, 264it may be best to hold the number of CPUs brought online constant, such as to have one CPU 265online and the rest offline / hotplugged out. Keeping all CPUs but one in scheduling idle may 266deliver acceptable results. Stopping the Android framework with adb shell stop can help 267reduce system scheduling activity. 268</p> 269<p> 270You’ll specify the available CPU speeds for your device in the power profile cpu.speeds 271entry. You can get a list of these using 272</p> 273<pre> 274adb shell cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state 275</pre> 276<p> 277These speeds are matched with their corresponding power measurements in value <code>cpu.active</code>. 278</p> 279<p> 280If your platform’s power consumption is significantly affected by how many cores are brought 281online then you may need to modify the cpufreq driver or governor for your platform to 282control this. For many platforms, the easiest way to control CPU speed is to use the 283“userspace” cpufreq governor and use sysfs interfaces to set the speed. The exact commands 284differ depending on your platform’s cpufreq implementation. The following commands from the 285system console or adb shell could be used to set a speed for 200MHz on a system with only 1 286CPU, or all CPUs sharing a common cpufreq policy: 287</p> 288<pre> 289echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor 290echo 200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 291echo 200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 292echo 200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed 293cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 294</pre> 295<p> 296which makes sure the new speed is not outside the allowed bounds, sets the new speed, and 297then prints which speed the CPU is actually running at for verification. (If the current 298minimum speed prior to executing the above is above 200000, you may have to reverse the order 299of the first two lines, or execute the first line again, to drop the minimum speed prior to 300setting the maximum speed.) 301</p> 302<p> 303To measure current consumed by a CPU while running at various speeds, you may need to place a 304CPU in a CPU-bound loop such as: 305</p> 306<pre> 307# while true; do true; done 308</pre> 309<p> 310on the system console and take the measurement while the above runs. 311</p> 312<p> 313If your device may limit maximum CPU speed while thermal throttling due to a high temperature 314measurement, possibly as a result of running CPUs at high speeds for sustained periods, then 315watch out for this while taking measurements. You may need to watch system console output, or 316check the kernel log after measuring. 317</p> 318<p> 319For the <code>cpu.active</code> value you can measure the power consumed when the system is not in suspend 320but not executing tasks. The CPU should be in a low-power scheduler “idle loop”, possibly 321executing an ARM Wait For Event instruction or in an SoC-specific low power state with a fast 322exit latency suitable for idle use. There may be more than one idle state in use on your 323platform with differing levels of power consumption; choose a representative idle state for 324longer periods of scheduler idle (several milliseconds). You may need to examine the power 325graph on your measurement equipment and choose samples where the CPU is at its lowest 326consumption, discarding higher samples where the CPU exited idle. 327</p> 328<h3> 329Measuring Screen Power 330</h3> 331<p> 332Screen on power is typically measured with all other devices that are turned on with the 333screen also enabled. For example, the touchscreen and any display backlight would normally 334also be turned on during the measurement, to get a more realistic example of screen on power 335usage. 336</p> 337<p> 338Some display technologies vary in power consumption according to the colors displayed, and so 339power measurements may vary considerably depending on what is on the screen at the time. It’s 340best to choose to display something that has power characteristics of a realistic screen, 341somewhere between the extremes of an all-black screen (which consumes the lowest power for 342some technologies) and an all-white screen. A common choice is a view of a schedule in the 343calendar app, which has a mix of white background and non-white elements. 344</p> 345<p> 346The cost of having the screen on is measured at two points: at minimum display/backlight 347brightness, and at maximum brightness. Setting the display brightness to minimum using the 348Settings app Display Brightness slider might not produce accurate results. The Android UI 349will typically only allow you to set the brightness to a minimum of about 10-20% of the 350possible panel/backlight brightness -- it doesn't allow the user to set brightness so low 351that the screen might not be visible without great effort. If you have a sysfs file that 352controls panel brightness all the way down to the minimum brightness supported by the 353hardware then that's even better. 354</p> 355<p> 356If your platform provides sysfs files that turns the LCD panel, backlight, and touchscreen on 357and off then that’s a good way to take measurements with the screen on and off. Otherwise, 358holding a partial wakelock so the system doesn't go to suspend, and turning on and off the 359screen with the power button, should be fine. 360</p> 361<h3> 362Measuring Wi-Fi Power 363</h3> 364<p> 365It’s recommended to perform Wi-Fi measurements on a relatively quiet network, without 366introducing a lot of additional work processing high volumes of broadcast traffic unrelated 367to the activity being measured. 368</p> 369<p> 370The <code>wifi.on</code> value measures the power consumed when Wi-Fi is enabled but not actively 371transmitting or receiving. This is often measured as the delta between the current draw in 372system suspend (sleep) state with Wi-Fi enabled vs. disabled. 373</p> 374<p> 375The <code>wifi.scan</code> value measures the power consumed during a Wi-Fi scan for access points. Wi-Fi 376scans can be triggered by an app using the WifiManager class <code>startScan()</code> API, which is 377documented at http://developer.android.com/reference/android/net/wifi/WifiManager.html . You 378can also open Settings > Wi-Fi, which will perform scans for access points every few 379seconds with an apparent jump in power consumption, but the screen power must be subtracted 380from these measurements. 381</p> 382<p> 383Network receive and transmit traffic can be generated using controlled setup such as 384<a href="http://en.wikipedia.org/wiki/Iperf">iperf</a> if desired. 385</p> 386<h2> 387List of values and their meaning 388</h2> 389<table> 390<tr> 391 <th>Name</th> 392 <th>Meaning</th> 393 <th>Example value</th> 394 <th>Notes</th> 395</tr> 396<tr> 397 <td>none</td> 398 <td>Nothing</td> 399 <td>0</td> 400 <td></td> 401</tr> 402 403<tr> 404 <td>screen.on</td> 405 <td>Additional power used when screen is turned on at minimum brightness </td> 406 <td>200mA</td> 407 <td>Includes touch controller and display backlight. At 0 brightness, not the Android minimum which tends to be 10 or 20%.</td> 408</tr> 409 410<tr> 411 <td>screen.full</td> 412 <td>Additional power used when screen is at maximum brightness, compared to screen at minimum brightness</td> 413 <td>100- 300mA</td> 414 <td>A fraction of this value (based on screen brightness) is added to the screen.on value to compute the power usage of the screen.</td> 415</tr> 416 417<tr> 418 <td>bluetooth.active </td> 419 <td>Additional power used when playing audio through bluetooth A2DP</td> 420 <td>14mA</td> 421 <td></td> 422</tr> 423 424<tr> 425 <td>bluetooth.on</td> 426 <td> Additional power used when bluetooth 427is turned on but idle </td> 428 <td>1.4mA</td> 429 <td></td> 430</tr> 431 432<tr> 433 <td>wifi.on </td> 434 <td>Additional power used when wifi is turned on but not 435receiving, transmitting, or scanning</td> 436 <td> 2mA </td> 437 <td></td> 438</tr> 439 440<tr> 441 <td>wifi.active </td> 442 <td>Additional power used when transmitting 443or receiving over Wifi </td> 444 <td>31mA</td> 445 <td></td> 446</tr> 447 448<tr> 449 <td>wifi.scan </td> 450 <td>Additional power used when wifi is scanning for access 451points </td> 452 <td>100mA</td> 453 <td></td> 454</tr> 455 456<tr> 457 <td>dsp.audio </td> 458 <td>Additional power used when audio decoding/encoding via DSP </td> 459 <td>14.1mA </td> 460 <td>Not 461currently used</td> 462</tr> 463 464 465<tr> 466 <td>dsp.video </td> 467 <td>Additional power used when video decoding via DSP</td> 468 <td> 54mA</td> 469 <td> Not currently 470used </td> 471</tr> 472 473<tr> 474 <td>gps.on </td> 475 <td>Additional power used when GPS is acquiring a signal </td> 476 <td>50mA</td> 477 <td></td> 478</tr> 479 480<tr> 481 <td>radio.active </td> 482 <td>Additional 483power used when cellular radio is transmitting/receiving </td> 484 <td>100- 300mA </td> 485 <td></td> 486</tr> 487 488<tr> 489 <td>radio.scanning </td> 490 <td>Additional 491power used when cellular radio is paging the tower </td> 492 <td>1.2mA</td> 493 <td></td> 494</tr> 495 496<tr> 497 <td>radio.on Additional power used when 498the cellular radio is on. </td> 499 <td>This is a multi-value entry, one per signal strength (no signal, 500weak, moderate, strong) </td> 501 <td>1.2mA </td> 502 <td>Some radios boost up their power when there’s no signal and 503they’re trying to find a cell tower. So these numbers could all be the same or decreasing 504with increasing signal strength. If you provide only one value, the same value will be used 505for all strengths. If you provide 2 values, the first will be for no-signal and the second 506for all other strengths, and so on.</td> 507</tr> 508 509<tr> 510 <td>cpu.speeds </td> 511 <td>Multi-value entry that lists each possible CPU 512speed in KHz </td> 513 <td>125000, 250000, 500000, 1000000, 1500000 </td> 514 <td>The number and order of entries need to 515correspond to the mA entries in cpu.active </td> 516</tr> 517 518<tr> 519 <td>cpu.idle </td> 520 <td>Total power drawn by the system when CPUs 521(and the SoC) are in system suspend state </td> 522 <td>3mA</td> 523 <td></td> 524</tr> 525 526<tr> 527 <td>cpu.awake 528</td> 529 <td>Additional power used when CPUs are 530in scheduling idle state (kernel idle loop); system is not in system suspend state </td> 531 <td>50mA</td> 532 <td></td> 533</tr> 534 535<tr> 536 <td>cpu.active </td> 537 <td>Additional power used by CPUs when running at different speeds </td> 538 <td>100, 120, 140, 160, 539200</td> 540 <td>Set the max speed in the kernel to each of the allowed speeds and peg the CPU at that 541speed. The number of entries here correspond to the number of entries in cpu.speeds, in the 542same order. </td> 543</tr> 544 545<tr> 546 <td>battery.capacity </td> 547 <td>The total battery capacity in mAh</td> 548 <td>3000mAh</td> 549 <td></td> 550</tr> 551 552</table> 553 554<p> 555The power_profile.xml file is placed in an overlay in 556device///frameworks/base/core/res/res/xml/power_profile.xml 557</p> 558<h3> 559Sample file 560</h3> 561<pre> 562<!-- Most values are the incremental current used by a feature, in mA (measured at 563nominal voltage). OEM's must measure and provide actual values before shipping a device. 564Example real-world values are given, but they are totally dependent on the platform 565and can vary significantly, so should be measured on the shipping platform with a power meter. 566--> 5670 568200 569160 57010 571<!-- Bluetooth stereo audio playback 10.0 mA --> 5721.3 5730.5 57430 575100 57612 57750 57850 57975 5801.1 581<!-- Strength 0 to BINS-1 (4) --> 5821.1 583 584<!-- Different CPU speeds as reported in 585/sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state --> 586 587250000 <!-- 250 MHz --> 588500000 <!-- 500 MHz --> 589750000 <!-- 750 MHz --> 5901000000 <!-- 1 GHz --> 5911200000 <!-- 1.2 GHz --> 592 593<!-- Power consumption when CPU is idle --> 5943.0 59550.1 596<!-- Power consumption at different speeds --> 597 598100 <!-- 250 MHz --> 599120 <!-- 500 MHz --> 600140 <!-- 750 MHz --> 601155 <!-- 1 GHz --> 602175 <!-- 1.2 GHz --> 603 604<!-- This is the battery capacity in mAh --> 6053000 606<!-- Battery capacity is 3000 mAH (at 3.6 Volts) --> 607 608</pre>