diff --git a/src/devices/tech/power.jd b/src/devices/tech/power.jd
index 0367f26..38e1e6a 100644
--- a/src/devices/tech/power.jd
+++ b/src/devices/tech/power.jd
@@ -2,7 +2,7 @@
 @jd:body
 
 <!--
-    Copyright 2013 The Android Open Source Project
+    Copyright 2014 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.
@@ -23,268 +23,203 @@
   </div>
 </div>
 
-<p>
-Battery usage information is derived from battery usage statistics and power profile
-values.
-</p>
+<p>Battery usage information is derived from battery usage statistics and power profile values.</p>
 
-<h2>
-Battery Usage Statistics
-</h2>
+<h2 id="usage-statistics">Battery Usage Statistics</h2>
 
-<p>
-Battery usage statistics are tracked by the framework. This involves keeping track of time
-spent by different device components in different states. This includes components such as
-WiFi chipset, Cellular Radio, Bluetooth, GPS, Display and CPU. When these components change
-state from off to on, or from idle to full power, low brightness to high brightness, etc.,
-their controlling service reports to the framework’s BatteryStats service, which collects
-such information over time and persists to storage so that it is available across reboots.
-</p>
+<p>The framework automatically determines battery usage statistics by tracking how long device
+components spend in different states. As components (WiFi 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, which 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.</p>
 
-<p>
-The service isn’t keeping track of battery current draw information directly. It’s collecting
-mostly timing information so that it can be used to approximate battery consumption by
-different components.
-</p>
+<p>The framework gathers statistics using the following methods:</p>
 
-<p>
-Consumption of these resources is also (where possible) attributed to the applications using
-the resources, sometimes sharing the blame across multiple applications using a resource
-simultaneously. For instance, multiple apps could be holding wakelocks, keeping the system
-from going into suspend state. Blame is shared across these apps (not necessarily equally).
-</p>
+<ul>
+<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 usage by apps, the framework automatically
+pulls the data at transition points (such as starting or stopping an activity) to take a
+snapshot.</li>
+</ul>
 
-<p>
-Statistics are persisted to flash periodically (approximately every half hour or so) to avoid
-losing the information on a shutdown (such as due to battery reaching zero remaining
-capacity, which may indicate a battery power consumption problem).
-</p>
+<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
+equally.</p>
 
-<p>
-Statistics gathering can happen in two ways - push or pull. When services are aware of
-changes happening to a component, they will push state changes to the BatteryStats service.
-With components such as the CPU usage by apps, we pull the data periodically (at certain
-transition points such as starting or stopping an activity, etc) to take a snapshot.
-</p>
+<p>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.</p>
 
-<p>
-All of the above is automatically done by the framework, and OEMs don’t need to do anything
-in addition to that.
-</p>
+<p>Battery usage statistics are handled entirely by the framework and do not require OEM
+modifications.</p>
 
-<h2>
-Power Profile Values
-</h2>
+<h2 id="profile-values">Power Profile Values</h2>
 
-<p>
-The power profile is where the device manufacturer needs to provide current consumption
-values for various components and their states in order to approximate the actual battery
-drain caused by these components over time. The power consumption of a component is specified
-in units of milliamps (mA) of current draw (at a nominal voltage) in the power profile, and
-can be a fractional value specifying microamps. The value specified 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>Device manufacturers must provide a component power profile that defines the current
+consumption value for the component and the approximate the actual battery drain caused by the
+component over time. 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 instance, to attribute the cost of keeping the display on for a duration of time, the
-framework gathers brightness levels and times spent at each level (quantized to some number
-of bins). The power profile values specify how many milliamps of current are required to keep
-the display on at minimum brightness and at maximum brightness. The time spent at each
-brightness level can then be multiplied by an interpolated display brightness cost to compute
-an approximation of how much battery was drained by the display component.
-</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
+cost.</p>
 
-<p>
-Similarly, CPU time for each application is multiplied by the mA to keep the CPU running at a
-certain speed to get a comparative ranking of how much battery each app is consuming due to
-executing CPU code (time as the foreground app and total time including background activity
-are reported separately).
-</p>
+<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>
 
-<h2>
-Computing power consumption for individual components
-</h2>
+<h2 id="component-power">Measuring Component Power</h2>
+
+<p>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).</p>
 
 <p class="note">
-<strong>Note:</strong> manufacturers usually supply information about how much current an
-individual component consumes. It may be possible to use these values if they are an accurate
-representation of the the current drawn from the device’s battery in practice. However, we
-encourage you validate manufacturer-provided values before entering them in your device’s
-power profile.
-</p>
+<strong>Note:</strong> 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.</p>
 
-<p>
-Current consumption for an individual component is calculated by:
-</p>
+<p>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.</p>
+
+<p>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:</p>
 
 <ul>
-<li>
-Measuring the current drawn by the device when the component is in the desired state (e.g.,
-on, active, or scanning)
-</li>
-<li>
-Measuring the current drawn by the device when the component is
-off
-</li>
-<li>subtracting (2) from (1).</li>
+<li><strong>Cellular, Wi-Fi, and Bluetooth receive, transmit, or scanning activity</strong>. When
+not measuring cell radio power, set the device to airplane mode and enable Wi-Fi or Bluetooth as
+appropriate.</li>
+<li><strong>Screen on/off</strong>. Colors displayed while the screen is on can affect power draw on
+some screen technologies. Turn the screen off when measuring values for non-screen components.</li>
+<li><strong>System suspend/resume</strong>. A screen off state can trigger a system suspension,
+placing parts of the device in a low-power or off state. This can affect power consumption of the
+component being measured and introduce large variances in power readings as the system periodically
+resumes to send alarms, etc. For details, see <a href="#control-suspend">Controlling System
+Suspend</a>.</li>
+<li><strong>CPUs changing speed and entering/exiting low-power scheduler idle state</strong>. During
+normal operation, the system makes frequent adjustments to CPU speeds, the number of online CPU
+cores, and other system core states such as memory bus speed and voltages of power rails associated
+with CPUs and memory. During testing, these adjustments affect power measurements:
 
-
-<img></img><p class="img-caption"></p>
-<p>
-We recommend that you measure the current (usually the average instantaneous current) drawn
-on the device at a nominal voltage. This can be accomplished using a bench power supply or
-using specialized battery-monitoring tools (such as Monsoon Solution Inc.’s Power Monitor and
-Power Tool software).
-</p>
-<p>
-Take the measurements with no external charger connected to the device, including no USB
-connection to a host (as used for connecting to development hosts via the adb Android Debug
-Bridge), which may draw current from the host and lower the measurements at the battery. If
-the device supports USB On The Go (OTG) then having an OTG device connected may draw
-additional power from the device being measured, so disconnect any such OTG device.
-</p>
-<p>
-While taking measurements, you’ll want to try to keep the rest of the system other than the
-component being measured running at a constant level of power consumption, to avoid
-introducing inaccuracies in the measurements due to changes in other components. System
-activities that may introduce unwanted changes to power measurements include:
-</p>
 <ul>
-<li>
-Cellular, Wi-Fi, and Bluetooth receive, transmit, or scanning activity. You may want to put
-the device into airplane mode when not measuring cell radio power, and individually enable
-Wi-Fi or Bluetooth when appropriate.
-</li>
-<li>
-Screen/backlight on or off. The colors displayed while screen is on can also affect power
-draw on certain screen technologies. Measurements for components other than the screen on
-values should be made with screen turned off. But see the next item for an important
-consideration when the screen is off.
-</p>
-<li>
-System suspended/resumed state. When the screen is off the system may enter a suspend state
-where much of the device may be powered off or placed in a low-power state, probably
-affecting power consumption of the component being measured and possibly introducing large
-variances in power readings as the system periodically resumes to service alarms and such.
-See Controlling and Measuring System Suspend State for more instructions.
-</li>
-<li>
-CPUs changing speed and entering/exiting low-power scheduler idle state. The system may make
-frequent adjustments to the speeds of CPUs, how many CPU cores are online, and other system
-core state such as memory bus speed and voltages of power rails associated with CPUs and
-memory. If these are changing during your measurements then you may want to prevent CPU speed
-scaling operations, which may also reduce the amount of clock and voltage scaling of memory
-busses and other system core components. Scheduling activity may also affect what percentage
-of the time the CPUs spend in low-power idle states. See Controlling and Measuring CPU Speeds
-for more instructions.
+<li>CPU speed scaling operations can reduce the amount of clock and voltage scaling of memory buses
+and other system core components.</li>
+<li>Scheduling activity can affect the percentage of the time CPUs spend in low-power idle states.
+For details on preventing these adjustments from occurring during testing, see
+<a href="#control-cpu">Controlling CPU Speeds</a>.</li>
+</ul>
+
 </li>
 </ul>
-<p>
-For instance, to compute the value for <code>screen.on</code>, you would run the device in a stable state,
-with CPU speed held constant, device in airplane mode, with a partial wakelock held to
-prevent system suspend. The current readings in this state should be stable. Take the reading
-- say 200mA. Now turn on the screen at minimum brightness. If the power monitor shows 300mA,
-then <code>screen.on</code> = (300 - 200) = 100mA.
-</p>
-<p>
-For components that don’t have a flat waveform of current consumption when active (such as
-the cellular radio or wifi), you may need to measure an average current over a period of
-time. Your power monitoring tool may be able to compute this average for you.
-</p>
-<p>
-Replacing the battery with an external power source may require working around problems that
-can occur due to not connecting battery thermistor or integrated fuel gauge pins. For
-example, the system might take an invalid battery temperature reading or remaining battery
-capacity reading that could cause the kernel or Android system to shut down. Sometimes these
-problems are avoided through the use of “fake batteries” that replace normal batteries for
-power measurement purposes, constructed to match the dimensions and electrical properties of
-the batteries for the product being measured. Fake batteries can provide signals on
-thermistor or fuel gauge pins that mimic temperature and state of charge readings for a
-normally running system, and may also provide convenient leads for connecting to external
-power supplies. In other cases it may be easier to modify the system to ignore the invalid
-data from the missing battery.
-</p>
-<h3>
-Controlling and Measuring System Suspend State
-</h3>
-<p>
-As mentioned above, system suspend can introduce unwanted variance in power measurements and
-place system components in low power states not appropriate for measuring active power use.
-But at some point you’ll also need to measure the power draw of system suspend state. 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.
-</p>
-<p>
-To avoid system suspend you can temporarily connect the device to a development host and
-issue the following command to hold a “partial wakelock”:
-</p>
+
+<p>For example, Joe Droid wants to compute the <code>screen.on</code> 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 <code>screen.on</code> value is 100mA (300 - 200).</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<a name="control-suspend"><h3 id="control-suspend">Controlling System Suspend</h3></a>
+
+<p>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.</p>
+
+<h4>Preventing System Suspend</h4>
+
+<p>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:</p>
+
 <pre>
 $ adb shell "echo temporary &gt; /sys/power/wake_lock"
 </pre>
-<p>
-which will prevent the system from suspending while the screen is off. Disconnect the USB
-cable before making measurements.
-</p>
-<p>
-You can undo the effect of this later with:
-</p>
+
+<p>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.)</p>
+
+<p>To remove the wakelock:</p>
+
 <pre>
 $ adb shell "echo temporary &gt; /sys/power/wake_unlock"
 </pre>
-<p>
-The power consumption of the system suspend state is measured for the value of cpu.idle in
-the power profile. For this measurement it may be best to place the device in airplane mode
-to avoid any concurrent activity by the cellular radio, which may run on a processor separate
-from the portions of the SoC controlled by the system suspend. To ensure the measurement is
-made while the system is in the correct state, it may be necessary to first confirm the
-current readings settle to a steady value within the expected range for the consumption of
-the suspend state of the SoC entered plus the consumption of additional system components
-that remain powered (such as the USB PHY). A system console or other external indication of
-system status (such as turning off an LED when not in suspend) may also be observed during
-the measurement.
-</p>
-<h3>
-Controlling and Measuring CPU Speeds
-</h3>
-<p>
-While active, CPUs can be brought online or put offline, change clock speeds and associated
-voltages (possibly also affecting memory bus speeds and other system core power state), and
-can enter lower power idle states while in the kernel idle loop. Not only are these different
-CPU power states measured for the power profile, it may be necessary to avoid the power draw
-variance when measuring other parameters.
-</p>
-<p>
-The power profile currently assumes all CPUs have the same available speeds and power
-characteristics.
-</p>
-<p>
-While measuring CPU power, or holding CPU power constant in order to make other measurements,
-it may be best to hold the number of CPUs brought online constant, such as to have one CPU
-online and the rest offline / hotplugged out. Keeping all CPUs but one in scheduling idle may
-deliver acceptable results. Stopping the Android framework with adb shell stop can help
-reduce system scheduling activity.
-</p>
-<p>
-You’ll specify the available CPU speeds for your device in the power profile cpu.speeds
-entry. You can get a list of these using
-</p>
+
+<h4>Measuring System Suspend</h4>
+
+<p>To measure the power draw during the system suspend state, measure the value of cpu.idle in the
+power profile. Before measuring:
+
+<ul>
+<li>Remove existing wakelocks (as described above).</li>
+<li>Place the device in airplane mode to avoid concurrent activity by the cellular radio, which
+might run on a processor separate from the SoC portions controlled by the system suspend.</li>
+<li>Ensure the system is in suspend state by:
+<ul>
+<li>Confirming current readings settle to a steady value. Readings should be within the expected
+range for the power consumption of the SoC suspend state plus the power consumption of system
+components that remain powered (such as the USB PHY).</li>
+<li>Checking the system console output.</li>
+<li>Watching for external indications of system status (such as an LED turning off when not in
+suspend).</li>
+</ul>
+</li>
+</ul>
+
+<a name="control-cpu"><h3 id="control-cpu">Controlling CPU Speeds</h3></a>
+
+<p>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.</p>
+
+<p>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 <code>adb shell stop</code> can reduce system
+scheduling activity.</p>
+
+<p>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:</p>
+
 <pre>
 adb shell cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
 </pre>
-<p>
-These speeds are matched with their corresponding power measurements in value <code>cpu.active</code>.
-</p>
-<p>
-If your platform’s power consumption is significantly affected by how many cores are brought
-online then you may need to modify the cpufreq driver or governor for your platform to
-control this. For many platforms, the easiest way to control CPU speed is to use the
-“userspace” cpufreq governor and use sysfs interfaces to set the speed. The exact commands
-differ depending on your platform’s cpufreq implementation. The following commands from the
-system console or adb shell could be used to set a speed for 200MHz on a system with only 1
-CPU, or all CPUs sharing a common cpufreq policy:
-</p>
+
+<p>These speeds match the corresponding power measurements in value <code>cpu.active</code>.</p>
+
+<p>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:</p>
+
 <pre>
 echo userspace &gt; /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
 echo 200000 &gt; /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
@@ -292,105 +227,347 @@
 echo 200000 &gt; /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
 </pre>
-<p>
-which makes sure the new speed is not outside the allowed bounds, sets the new speed, and
-then prints which speed the CPU is actually running at for verification. (If the current
-minimum speed prior to executing the above is above 200000, you may have 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.)
+
+<p class="note">
+<strong>Note</strong>: The exact commands differ depending on the platform cpufreq implementation.
 </p>
-<p>
-To measure current consumed by a CPU while running at various speeds, you may need to place a
-CPU in a CPU-bound loop such as:
-</p>
+
+<p>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.</p>
+
+<p>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:</p>
 <pre>
 # while true; do true; done
 </pre>
-<p>
-on the system console and take the measurement while the above runs.
-</p>
-<p>
-If your device may limit maximum CPU speed while thermal throttling due to a high temperature
-measurement, possibly as a result of running CPUs at high speeds for sustained periods, then
-watch out for this while taking measurements. You may need to watch system console output, or
-check the kernel log after measuring.
-</p>
-<p>
-For the <code>cpu.active</code> value you can measure the power consumed when the system is not in suspend
-but 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. There may be more than one idle state in use on your
-platform with differing levels of power consumption; choose a representative idle state for
-longer periods of scheduler idle (several milliseconds). You may need to 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.
-</p>
-<h3>
-Measuring Screen Power
-</h3>
-<p>
-Screen on power is typically measured with all other devices that are turned on with the
-screen also enabled. For example, the touchscreen and any display backlight would normally
-also be turned on during the measurement, to get a more realistic example of screen on power
-usage.
-</p>
-<p>
-Some display technologies vary in power consumption according to the colors displayed, and so
-power measurements may vary considerably depending on what is on the screen at the time. It’s
-best to choose to display something that has power characteristics of a realistic screen,
-somewhere 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.
-</p>
-<p>
-The cost of having the screen on is measured at two points: at minimum display/backlight
-brightness, and at maximum brightness. Setting the display brightness to minimum using the
-Settings app Display Brightness slider might not produce accurate results. The Android UI
-will typically only allow you to set the brightness to a minimum of about 10-20% of the
-possible panel/backlight brightness -- it doesn't allow the user to set brightness so low
-that the screen might not be visible without great effort. If you have a sysfs file that
-controls panel brightness all the way down to the minimum brightness supported by the
-hardware then that's even better.
-</p>
-<p>
-If your platform provides sysfs files that turns the LCD panel, backlight, and touchscreen on
-and off then that’s a good way to take measurements with the screen on and off. Otherwise,
-holding a partial wakelock so the system doesn't go to suspend, and turning on and off the
-screen with the power button, should be fine.
-</p>
-<h3>
-Measuring Wi-Fi Power
-</h3>
-<p>
-It’s recommended to perform Wi-Fi measurements on a relatively quiet network, without
-introducing a lot of additional work processing high volumes of broadcast traffic unrelated
-to the activity being measured.
-</p>
-<p>
-The <code>wifi.on</code> value measures the power consumed when Wi-Fi is enabled but not actively
+
+<p>Take the measurement while the loop executes.</p>
+
+<p>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.</p>
+
+<p>For the <code>cpu.active</code> 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 <em>idle loop
+</em>, 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. 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.</p>
+
+<h3 id="screen-power">Measuring Screen Power</h3>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<p>Measure screen on power at <em>minimum</em> and <em>maximum</em> display/backlight brightness.
+To set minimum brightness:</p>
+
+<ul>
+<li><strong>Use the Android UI</strong> (not recommended). Set the Settings > Display Brightness
+slider to the minimum display brightness. However, the Android UI allows setting brightness only to
+a minimum of 10-20% of the possible panel/backlight brightness, and does not allow setting
+brightness so low that the screen might not be visible without great effort.</li>
+<li><strong>Use a sysfs file</strong> (recommended). If available, use a sysfs file to control panel
+brightness all the way down to the minimum brightness supported by the hardware.</li>
+</ul>
+
+<p>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.</p>
+
+<h3 id="wifi-power">Measuring Wi-Fi Power</h3>
+
+<p>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.</p>
+
+<p>The <code>wifi.on</code> 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.
-</p>
-<p>
-The <code>wifi.scan</code> value measures the power consumed during a Wi-Fi scan for access points. Wi-Fi
-scans can be triggered by an app using the WifiManager class <code>startScan()</code> API, which is
-documented at http://developer.android.com/reference/android/net/wifi/WifiManager.html . You
-can also open Settings &gt; Wi-Fi, which will perform scans for access points every few
-seconds with an apparent jump in power consumption, but the screen power must be subtracted
-from these measurements.
-</p>
-<p>
-Network receive and transmit traffic can be generated using controlled setup such as 
-<a href="http://en.wikipedia.org/wiki/Iperf">iperf</a> if desired.
-</p>
-<h2>
-List of values and their meaning
-</h2>
+system suspend (sleep) state with Wi-Fi enabled vs. disabled.</p>
+
+<p>The <code>wifi.scan</code> value measures the power consumed during a Wi-Fi scan for access
+points. Applications can trigger Wi-Fi scans using the WifiManager class
+<a href = "http://developer.android.com/reference/android/net/wifi/WifiManager.html">
+<code>startScan()</code>API</a>. You can also open Settings &gt; 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.</p>
+
+<p class="note">
+<strong>Note</strong>: Use a controlled setup (such as
+<a href="http://en.wikipedia.org/wiki/Iperf">iperf</a>) to generate network receive and transmit
+traffic.</p>
+
+<h2 id="device-power">Measuring Device Power</h2>
+
+<p>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).</p>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<h3 id="power-consumption">Reading Power Consumption</h3>
+
+<p>To read power consumption data, insert calls to the API in your testing code.</p>
+
+<pre>
+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");
+</pre>
+
+<h3 id="avail-props">Available Properties</h3>
+
+<p>Android supports the following battery fuel gauge properties:</p>
+
+<pre>
+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
+</pre>
+
+<p>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:</p>
+
+<ul>
+<li>Fuel gauge hardware, such as a Summit SMB347 or Maxim MAX17050.</li>
+<li>Fuel gauge-to-system connection, such as the value of external current sense resistors.</li>
+<li>Fuel gauge chip software configuration, such as values chosen for average current computation
+intervals in the kernel driver.</li>
+</ul>
+
+<p>For details, see the properties available for <a href="#nexus-devices">Nexus devices</a>.</p>
+
+<h3 id="maxim-fuel">Maxim Fuel Gauge</h3>
+
+<p>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).</p>
+
+<p>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:</p>
+
+<ul>
+<li>2mA (1% gain error of 200mA due to fuel gauge gain error)</li>
+<li>+2mA (1% gain error of 200mA due to sense resistor error)</li>
+<li>+1.5mA  (current sense offset error from fuel gauge)</li>
+</ul>
+
+<p>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%.</p>
+
+<p>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).</p>
+
+<p>For +/-100uA relative measurements, required measurement time depends on:</p>
+
+<ul>
+<li><b>ADC sampling noise</b>. The MAX17050 with its normal factory configuration produces +/-1.5mA
+sample-to-sample variation due to noise, with each sample delivered at 175.8ms. You can expect a
+rough +/-100uA for a 1 minute test window and a clean  3-sigma noise less than 100uA (or 1-sigma
+noise at 33uA) for a 6 minute test window.</li>
+<li><b>Sample Aliasing because of load variation</b>. Variation exaggerates errors, so for samples
+with variation inherent in the loading, consider using a longer test window.</li>
+</ul>
+
+<a name="nexus-devices"><h3>Supported Nexus Devices</h3></a>
+
+<h5><a name="nexus-5">Nexus 5</a></h5>
+
+<table>
+<tbody>
+<tr>
+<th>Model</th>
+<td>Nexus 5</td>
+</tr>
+<tr>
+<th>Fuel Gauge</th>
+<td>Maxim MAX17048 fuel gauge (ModelGauge™, no coulomb counter)</td>
+</tr>
+<tr>
+<th>Properties</th>
+<td>BATTERY_PROPERTY_CAPACITY</td>
+</tr>
+<tr>
+<th>Measurements</th>
+<td>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).</td>
+</tr>
+</tbody>
+</table>
+
+
+<h5><a name="nexus-6">Nexus 6</a></h5>
+
+<table>
+<tbody>
+<tr>
+<th>Model</th>
+<td>Nexus 6</td>
+</tr>
+<tr>
+<th>Fuel Gauge</th>
+<td>Maxim MAX17050 fuel gauge (a coulomb counter with Maxim ModelGauge™ adjustments), and a 10mohm
+current sense resistor.</td>
+</tr>
+<tr>
+<th>Properties</th>
+<td>BATTERY_PROPERTY_CAPACITY<br>
+BATTERY_PROPERTY_CURRENT_NOW<br>
+BATTERY_PROPERTY_CURRENT_AVERAGE<br>
+BATTERY_PROPERTY_CHARGE_COUNTER<br>
+BATTERY_PROPERTY_ENERGY_COUNTER</td>
+</tr>
+<tr>
+<th>Measurements</th>
+<td>CURRENT_NOW resolution 156.25uA, update period is 175.8ms.<br>
+CURRENT_AVERAGE resolution 156.25uA, update period configurable 0.7s - 6.4h, default 11.25 secs.<br>
+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).<br>
+CHARGE_COUNTER_EXT (extended precision in kernel) resolution 8nAh.<br>
+ENERGY_COUNTER is CHARGE_COUNTER_EXT at nominal voltage of 3.7V.</td>
+</tr>
+</tbody>
+</table>
+
+
+<h5><a name="nexus-9">Nexus 9</a></h5>
+
+<table>
+<tbody>
+<tr>
+<th>Model</th>
+<td>Nexus 9</td>
+</tr>
+<tr>
+<th>Fuel Gauge</th>
+<td>Maxim MAX17050 fuel gauge (a coulomb counter with Maxim ModelGauge™ adjustments), and a 10mohm
+current sense resistor.</td>
+</tr>
+<tr>
+<th>Properties</th>
+<td>BATTERY_PROPERTY_CAPACITY<br>
+BATTERY_PROPERTY_CURRENT_NOW<br>
+BATTERY_PROPERTY_CURRENT_AVERAGE<br>
+BATTERY_PROPERTY_CHARGE_COUNTER<br>
+BATTERY_PROPERTY_ENERGY_COUNTER</td>
+</tr>
+<tr>
+<th>Measurements</th>
+<td>CURRENT_NOW resolution 156.25uA, update period is 175.8ms.<br>
+CURRENT_AVERAGE resolution 156.25uA, update period configurable 0.7s - 6.4h, default 11.25 secs.<br>
+CHARGE_COUNTER (accumulated current, non-extended precision) resolution is 500uAh.<br>
+CHARGE_COUNTER_EXT (extended precision in kernel) resolution 8nAh.<br>
+ENERGY_COUNTER is CHARGE_COUNTER_EXT at nominal voltage of 3.7V.<br>
+Accumulated current update period 175.8ms.<br>
+ADC sampled at 175ms quantization with a 4ms sample period. Can adjust duty cycle.</td>
+</tr>
+</tbody>
+</table>
+
+
+<h5><a name="nexus-10">Nexus 10</a></h5>
+
+<table>
+<tbody>
+<tr>
+<th>Model</th>
+<td>Nexus 10</td>
+</tr>
+<tr>
+<th>Fuel Gauge</th>
+<td>Dallas Semiconductor DS2784 fuel gauge (a coulomb counter), with a 10mohm current sense
+resistor.</td>
+</tr>
+<tr>
+<th>Properties</th>
+<td>BATTERY_PROPERTY_CAPACITY<br>
+BATTERY_PROPERTY_CURRENT_NOW<br>
+BATTERY_PROPERTY_CURRENT_AVERAGE<br>
+BATTERY_PROPERTY_CHARGE_COUNTER<br>
+BATTERY_PROPERTY_ENERGY_COUNTER</td>
+</tr>
+<tr>
+<th>Measurements</th>
+<td>Current measurement (instantaneous and average) resolution is 156.3uA.<br>
+CURRENT_NOW instantaneous current update period is 3.5 seconds.<br>
+CURRENT_AVERAGE update period is 28 seconds (not configurable).<br>
+CHARGE_COUNTER (accumulated current, non-extended precision) resolution is 625uAh.<br>
+CHARGE_COUNTER_EXT (extended precision in kernel) resolution is 144nAh.<br>
+ENERGY_COUNTER is CHARGE_COUNTER_EXT at nominal voltage of 3.7V.<br>
+Update period for all is 3.5 seconds.</td>
+</tr>
+</tbody>
+</table>
+
+
+<h2 id="viewing-usage">Viewing Battery Usage Data</h2>
+
+<p>The <code>dumpsys</code> <code>batterystats</code> command generates interesting statistical data
+about battery usage on a device, organized by unique application ID. You can view a history of
+battery-related events such as mobile radio state, Wi-Fi and Bluetooth power states, and wakelock
+reasons.</p>
+
+<p>Statistics include:</p>
+
+<ul>
+<li>History of battery-related events</li>
+<li>Global statistics for the device</li>
+<li>Approximate power use per UID and system component</li>
+<li>System UID aggregated statistics</li>
+</ul>
+
+<p>Use the output of the dumpsys command with the
+<a href="https://github.com/google/battery-historian">Battery Historian</a> tool to generate HTML
+visualizations of power-related events from logs.</p>
+
+
+<h2 id="power-values">Power Values</h2>
 <table>
 <tr>
   <th>Name</th>
-  <th>Meaning</th>
-  <th>Example value</th>
+  <th>Description</th>
+  <th>Example Value</th>
   <th>Notes</th>
 </tr>
 <tr>
@@ -402,166 +579,148 @@
 
 <tr>
   <td>screen.on</td>
-  <td>Additional power used when screen is turned on at minimum brightness </td>
+  <td>Additional power used when screen is turned on at minimum brightness.</td>
   <td>200mA</td>
   <td>Includes touch controller and display backlight. At 0 brightness, not the Android minimum which tends to be 10 or 20%.</td>
 </tr>
 
 <tr>
   <td>screen.full</td>
-  <td>Additional power used when screen is at maximum brightness, compared to screen at minimum brightness</td>
-  <td>100- 300mA</td>
+  <td>Additional power used when screen is at maximum brightness, compared to screen at minimum brightness.</td>
+  <td>100mA-300mA</td>
   <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>
 </tr>
 
 <tr>
-  <td>bluetooth.active </td>
-  <td>Additional power used when playing audio through bluetooth A2DP</td>
+  <td>bluetooth.active</td>
+  <td>Additional power used when playing audio through bluetooth A2DP.</td>
   <td>14mA</td>
   <td></td>
 </tr>
 
 <tr>
   <td>bluetooth.on</td>
-  <td> Additional power used when bluetooth
-is turned on but idle </td>
+  <td>Additional power used when bluetooth is turned on but idle.</td>
   <td>1.4mA</td>
   <td></td>
 </tr>
 
 <tr>
-  <td>wifi.on </td>
-  <td>Additional power used when wifi is turned on but not
-receiving, transmitting, or scanning</td>
-  <td> 2mA </td>
+  <td>wifi.on</td>
+  <td>Additional power used when Wi-Fi is turned on but not receiving, transmitting, or scanning.</td>
+  <td>2mA</td>
   <td></td>
 </tr>
 
 <tr>
-  <td>wifi.active  </td>
-  <td>Additional power used when transmitting
-or receiving over Wifi </td>
+  <td>wifi.active</td>
+  <td>Additional power used when transmitting or receiving over Wi-Fi.</td>
   <td>31mA</td>
   <td></td>
 </tr>
 
 <tr>
-  <td>wifi.scan </td>
-  <td>Additional power used when wifi is scanning for access
-points  </td>
+  <td>wifi.scan</td>
+  <td>Additional power used when Wi-Fi is scanning for access points.</td>
   <td>100mA</td>
   <td></td>
 </tr>
 
 <tr>
-  <td>dsp.audio </td>
-  <td>Additional power used when audio decoding/encoding via DSP  </td>
-  <td>14.1mA </td>
-  <td>Not
-currently used</td>
+  <td>dsp.audio</td>
+  <td>Additional power used when audio decoding/encoding via DSP.</td>
+  <td>14.1mA</td>
+  <td>Reserved for future use.</td>
 </tr>
 
 
 <tr>
-  <td>dsp.video </td>
-  <td>Additional power used when video decoding via DSP</td>
-  <td> 54mA</td>
-  <td> Not currently
-used </td>
+  <td>dsp.video</td>
+  <td>Additional power used when video decoding via DSP.</td>
+  <td>54mA</td>
+  <td>Reserved for future use.</td>
 </tr>
 
 <tr>
-  <td>gps.on </td>
-  <td>Additional power used when GPS is acquiring a signal  </td>
+  <td>gps.on</td>
+  <td>Additional power used when GPS is acquiring a signal.</td>
   <td>50mA</td>
   <td></td>
 </tr>
 
 <tr>
-  <td>radio.active </td>
-  <td>Additional
-power used when cellular radio is transmitting/receiving </td>
-  <td>100- 300mA </td>
+  <td>radio.active</td>
+  <td>Additional power used when cellular radio is transmitting/receiving.</td>
+  <td>100mA-300mA</td>
   <td></td>
 </tr>
 
 <tr>
-  <td>radio.scanning </td>
-  <td>Additional
-power used when cellular radio is paging the tower  </td>
+  <td>radio.scanning</td>
+  <td>Additional power used when cellular radio is paging the tower.</td>
   <td>1.2mA</td>
   <td></td>
 </tr>
 
 <tr>
-  <td>radio.on Additional power used when
-the cellular radio is on. </td>
-  <td>This is a multi-value entry, one per signal strength (no signal,
-weak, moderate, strong)  </td>
-  <td>1.2mA </td>
-  <td>Some radios boost up their power when there’s no signal and
-they’re trying to find a cell tower. So 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.</td>
+  <td>radio.on</td>
+  <td>Additional power used when the cellular radio is on. Multi-value entry, one per signal strength (no signal, weak, moderate, strong).</td>
+  <td>1.2mA</td>
+  <td>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.</td>
 </tr>
 
 <tr>
-  <td>cpu.speeds </td>
-  <td>Multi-value entry that lists each possible CPU
-speed in KHz </td>
-  <td>125000, 250000, 500000, 1000000, 1500000 </td>
-  <td>The number and order of entries need to
-correspond to the mA entries in cpu.active </td>
+  <td>cpu.speeds</td>
+  <td>Multi-value entry that lists each possible CPU speed in KHz.</td>
+  <td>125000, 250000, 500000, 1000000, 1500000</td>
+  <td>The number and order of entries must correspond to the mA entries in cpu.active.</td>
 </tr>
 
 <tr>
-  <td>cpu.idle  </td>
-  <td>Total power drawn by the system when CPUs
-(and the SoC) are in system suspend state </td>
+  <td>cpu.idle</td>
+  <td>Total power drawn by the system when CPUs (and the SoC) are in system suspend state.</td>
   <td>3mA</td>
   <td></td>
 </tr>
 
 <tr>
-  <td>cpu.awake 
-</td>
-  <td>Additional power used when CPUs are
-in scheduling idle state (kernel idle loop); system is not in system suspend state </td>
+  <td>cpu.awake</td>
+  <td>Additional power used when CPUs are in scheduling idle state (kernel idle loop); system is not
+  in system suspend state.</td>
   <td>50mA</td>
   <td></td>
 </tr>
 
 <tr>
-  <td>cpu.active  </td>
-  <td>Additional power used by CPUs when running at different speeds </td>
-  <td>100, 120, 140, 160,
-200</td>
+  <td>cpu.active</td>
+  <td>Additional power used by CPUs when running at different speeds.</td>
+  <td>100, 120, 140, 160, 200</td>
   <td>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. </td>
+same order.</td>
 </tr>
 
 <tr>
-  <td>battery.capacity  </td>
-  <td>The total battery capacity in mAh</td>
+  <td>battery.capacity</td>
+  <td>The total battery capacity in mAh.</td>
   <td>3000mAh</td>
   <td></td>
 </tr>
 
 </table>
  
-<p>
-The power_profile.xml file is placed in an overlay in
-device///frameworks/base/core/res/res/xml/power_profile.xml
-</p>
-<h3>
-Sample file
-</h3>
+<p>The power_profile.xml file is placed in an overlay in
+device///frameworks/base/core/res/res/xml/power_profile.xml</p>
+
+<h3 id="sample">Sample file</h3>
+
 <pre>
 &lt;!-- Most values are the incremental current used by a feature, in mA (measured at
-nominal voltage). OEM's must measure and provide actual values before shipping a device.
-Example real-world values are given, but they are totally dependent on the platform
+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.
 --&gt;
 0
@@ -605,4 +764,4 @@
 3000
 &lt;!-- Battery capacity is 3000 mAH (at 3.6 Volts) --&gt;
 
-</pre>
+</pre>
\ No newline at end of file