Merge "CDD: Require NEON support for armeabi-v7a" into mnc-dev
diff --git a/src/compatibility/android-cdd.html b/src/compatibility/android-cdd.html
index 96a8599..4a03962 100644
--- a/src/compatibility/android-cdd.html
+++ b/src/compatibility/android-cdd.html
@@ -142,6 +142,8 @@
<p class="toc_h2"><a href="#5_9_midi">5.9. Musical Instrument Digital Interface (MIDI)</a></p>
+<p class="toc_h2"><a href="#5_10_pro_audio">5.10. Professional Audio</a></p>
+
<p class="toc_h1"><a href="#6_developer_tools_and_options_compatibility">6. Developer Tools and Options Compatibility</a></p>
<p class="toc_h2"><a href="#6_1_developer_tools">6.1. Developer Tools</a></p>
@@ -2293,8 +2295,11 @@
<li><strong>continuous input latency</strong>. The input latency for subsequent frames, while the device is capturing audio.</li>
<li><strong>cold output jitter</strong>. The variance among separate measurements of cold output latency values.</li>
<li><strong>cold input jitter</strong>. The variance among separate measurements of cold input latency values.</li>
- <li><strong>continuous round-trip latency</strong>. The sum of continuous input latency plus continuous output latency plus 5
-milliseconds.</li>
+ <li><strong>continuous round-trip latency</strong>. The sum of continuous input latency plus continuous output latency plus
+ one buffer period.
+ The buffer period term allows processing time for the app and for the app to
+ mitigate phase difference between input and output streams.
+ </li>
<li><strong>OpenSL ES PCM buffer queue API</strong>. The set of PCM-related OpenSL ES APIs within Android NDK; see
NDK_root/docs/opensles/index.html.</li>
</ul>
@@ -2384,6 +2389,60 @@
over Bluetooth LE, SHOULD support MIDI over Bluetooth LE.
</p>
+<h2 id="5_10_pro_audio">5.10. Professional Audio</h2>
+
+<p>
+If a device implementation meets <em>all</em> of the following requirements,
+it MAY report support for feature android.hardware.audio.pro via the
+android.content.pm.PackageManager class
+[<a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">Resources, 53</a>].
+</p>
+
+<ul>
+
+<li>
+The device implementation MUST support android.hardware.audio.low_latency
+</li>
+
+<li> The continuous round-trip audio latency, as defined in section 5.6 Audio Latency,
+MUST be 20 milliseconds or less and SHOULD be 10 milliseconds or less over at least one
+supported path.
+</li>
+
+<li>
+If the device implementation includes a 4 conductor 3.5mm audio jack,
+the continuous round-trip audio latency MUST be 20 milliseconds or less over the audio jack path,
+and SHOULD be 10 milliseconds or less over at the audio jack path.
+</li>
+
+<li>
+The device implementation MUST include a USB port(s) supporting USB host mode and
+USB peripheral mode.
+</li>
+
+<li>
+The USB host mode MUST implement the USB audio class and handle concurrent input/output with
+a USB audio class-compliant peripheral having the following minimum capabilities:
+<ul>
+<li>4-channel input</li>
+<li>4-channel output</li>
+<li>24-bit depth PCM</li>
+<li>96 kHz sample rate</li>
+</ul>
+</li>
+
+<li>
+If the device includes an HDMI port, the device implementation
+MUST support output in stereo and 8 channels
+at 20-bit or 24-bit depth and 192 kHz without bit-depth loss or resampling.
+</li>
+
+<li>
+The device implementation MUST report support for feature android.software.midi.
+</li>
+
+</ul>
+
<h1 id="6_developer_tools_and_options_compatibility">6. Developer Tools and Options Compatibility</h1>
<h2 id="6_1_developer_tools">6.1. Developer Tools</h2>
@@ -3438,23 +3497,24 @@
<ul>
<li>NfcA (ISO14443-3A)</li>
<li>NfcB (ISO14443-3B)</li>
- <li>NfcF (JIS 6319-4)</li>
+ <li>NfcF (JIS X 6319-4)</li>
<li>IsoDep (ISO 14443-4)</li>
<li>NFC Forum Tag Types 1, 2, 3, 4 (defined by the NFC Forum)</li>
</ul>
- <li>SHOULD be capable of reading and writing NDEF messages via the following NFC
-standards. Note that while the NFC standards below are stated as SHOULD, the
-Compatibility Definition for a future version is planned to change these to
-MUST. These standards are optional in this version but will be required in
-future versions. Existing and new devices that run this version of Android are <strong>very strongly encouraged</strong> to meet these requirements now so they will be able to upgrade to the future platform releases.</li>
+ <li>MUST be capable of reading and writing NDEF messages as well as raw
+ data via the following NFC standards:</li>
<ul>
<li>NfcV (ISO 15693)</li>
</ul></li>
+ <li>SHOULD be capable of reading the barcode and URL (if encoded) of
+ Thinfilm NFC Barcode
+ [<a href="http://developer.android.com/reference/android/nfc/tech/NfcBarcode.html">Resources, XX</a>] products.
+ </li>
<li>MUST be capable of transmitting and receiving data via the following
peer-to-peer standards and protocols:
<ul>
<li>ISO 18092</li>
- <li>LLCP 1.0 (defined by the NFC Forum)</li>
+ <li>LLCP 1.2 (defined by the NFC Forum)</li>
<li>SDP 1.0 (defined by the NFC Forum)</li>
<li>NDEF Push Protocol [<a href="http://static.googleusercontent.com/media/source.android.com/en/us/compatibility/ndef-push-protocol.pdf">Resources, 84</a>]</li>
<li>SNEP 1.0 (defined by the NFC Forum)</li>
@@ -3525,8 +3585,8 @@
<ul>
<li>MUST implement the corresponding Android APIs as documented by the Android SDK.</li>
<li>MUST report the feature com.nxp.mifare from the
-android.content.pm.PackageManager.hasSystemFeature() meth<a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">od [Resources, 53]</a>. Note that this is not a standard Android feature and as such does not appear
-as a constant on the PackageManager class.</li>
+android.content.pm.PackageManager.hasSystemFeature() method <a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">[Resources, 53]</a>. Note that this is not a standard Android feature and as such does not appear
+as a constant in the android.content.pm.PackageManager class.</li>
<li>MUST NOT implement the corresponding Android APIs nor report the com.nxp.mifare
feature unless it also implements general NFC support as described in this
section.</li>
@@ -3996,7 +4056,7 @@
the audio plug:
<ul>
<li><strong>70 ohm or less</strong>: KEYCODE_HEADSETHOOK</li>
- <li><strong>210-290 Ohm</strong>:<strong> </strong>KEYCODE_VOLUME_UP</li>
+ <li><strong>210-290 Ohm</strong>: KEYCODE_VOLUME_UP</li>
<li><strong>360-680 Ohm</strong>: KEYCODE_VOLUME_DOWN</li>
</ul></li>
<li>SHOULD support the detection and mapping to the keycode for the following range
@@ -4074,6 +4134,13 @@
ignored. Implementations MAY add additional permissions, provided the new
permission ID strings are not in the android.* namespace.</p>
+<p>Permissions with a protection level of dangerous are runtime permissions. Applications
+with targetSdkVersion > 22 request them at runtime. The system MUST show a dedicated UI for the
+user to decide whether to grant the requested runtime permissions and also provide a UI for the
+user to manage runtime permissions. On the system there MUST be one and only one
+implementation of both the UI for the user to accept runtime permissions and the UI for
+the user to manage runtime permissions.</p>
+
<h2 id="9_2_uid_and_process_isolation">9.2. UID and Process Isolation</h2>
@@ -4168,7 +4235,7 @@
platform feature flag android.software.managed_users.
<li>Device implementations that declare the feature flag
android.software.managed_users MUST use the upstream AOSP icon badge to
-represent the managed applications and other badge UI elements like Recents &
+represent the managed applications and other badge UI elements like Recents &
Notifications.</li>
<li>Each user instance on an Android device MUST have separate and isolated
external storage directories. Device implementations MAY store multiple users'
@@ -4289,6 +4356,7 @@
<p>
Verified boot is a feature that guarantees the integrity of the device software.
If a device implementation supports the feature, it MUST:
+</p>
<ul>
<li>Declare the platform feature flag android.software.verified_boot</li>
<li>Perform verification on every boot sequence</li>
@@ -4299,7 +4367,6 @@
<li>Use verification algorithms as strong as current recommendations
from NIST for hashing algorithms (SHA-256) and public key sizes (RSA-2048)</li>
</ul>
-</p>
<p>Device implementations SHOULD support verified boot for device integrity.
While this requirement is SHOULD for this version of the Android platform,
diff --git a/src/devices/devices_toc.cs b/src/devices/devices_toc.cs
index 2f9c4e2..8a730cb 100644
--- a/src/devices/devices_toc.cs
+++ b/src/devices/devices_toc.cs
@@ -77,17 +77,6 @@
<li><a href="<?cs var:toroot ?>devices/drm.html">DRM</a></li>
<li class="nav-section">
<div class="nav-section-header">
- <a href="<?cs var:toroot ?>devices/storage/index.html">
- <span class="en">External Storage</span>
- </a>
- </div>
- <ul>
- <li><a href="<?cs var:toroot ?>devices/storage/config.html">Device Specific Configuration</a></li>
- <li><a href="<?cs var:toroot ?>devices/storage/config-example.html">Typical Configuration Examples</a></li>
- </ul>
- </li>
- <li class="nav-section">
- <div class="nav-section-header">
<a href="<?cs var:toroot ?>devices/graphics/index.html">
<span class="en">Graphics</span>
</a>
@@ -151,6 +140,17 @@
</li>
<li class="nav-section">
<div class="nav-section-header">
+ <a href="<?cs var:toroot ?>devices/storage/index.html">
+ <span class="en">Storage</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>devices/storage/config.html">Device Specific Configuration</a></li>
+ <li><a href="<?cs var:toroot ?>devices/storage/config-example.html">Typical Configuration Examples</a></li>
+ </ul>
+ </li>
+ <li class="nav-section">
+ <div class="nav-section-header">
<a href="<?cs var:toroot ?>devices/tv/index.html">
<span class="en">TV</span>
</a>
@@ -187,6 +187,22 @@
<li class="nav-section">
<div class="nav-section-header">
+ <a href="<?cs var:toroot ?>devices/tech/config/index.html">
+ <span class="en">Configuration</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>devices/tech/config/filesystem.html">File System</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/config/kernel.html">Kernel</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/config/low-ram.html">Low RAM</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/config/renderer.html">OpenGLRenderer</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/config/runtime_perms.html">Runtime Permissions</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/config/uicc.html">UICC</a></li>
+ </ul>
+ </li>
+
+ <li class="nav-section">
+ <div class="nav-section-header">
<a href="<?cs var:toroot ?>devices/tech/datausage/index.html">
<span class="en">Data Usage</span>
</a>
@@ -201,16 +217,18 @@
<li><a href="<?cs var:toroot ?>devices/tech/datausage/kernel-changes.html">Kernel Changes</a></li>
</ul>
</li>
+
<li class="nav-section">
<div class="nav-section-header">
<a href="<?cs var:toroot ?>devices/tech/debug/index.html">
- <span class="en">Debugging and Tuning</span>
+ <span class="en">Debugging</span>
</a>
</div>
<ul>
- <li><a href="<?cs var:toroot ?>devices/tech/debug/tuning.html">Performance Tuning</a></li>
- <li><a href="<?cs var:toroot ?>devices/tech/debug/native-memory.html">Native Memory Usage</a></li>
<li><a href="<?cs var:toroot ?>devices/tech/debug/dumpsys.html">Dumpsys</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/debug/native-memory.html">Native Memory Use</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/debug/netstats.html">Network Use</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/debug/procstats.html">RAM Use</a></li>
</ul>
</li>
@@ -241,7 +259,12 @@
<a href="<?cs var:toroot ?>devices/tech/power/index.html"><span class="en">Power</span></a>
</div>
<ul>
- <li><a href="<?cs var:toroot ?>devices/tech/power/batterystats.html">Battery Usage Data</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/power/component.html">Component Power</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/power/device.html">Device Power</a>
+ </li>
+ <li><a href="<?cs var:toroot ?>devices/tech/power/values.html">Power Values</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/power/batterystats.html">Battery Use</a>
+ </li>
</ul>
</li>
@@ -286,7 +309,21 @@
</a>
</div>
<ul>
- <li><a href="<?cs var:toroot ?>devices/tech/security/encryption/index.html">Encryption</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/security/authentication/index.html">Authentication</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/security/encryption/index.html">Full Disk Encryption</a></li>
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>devices/tech/security/selinux/index.html">
+ <span class="en">SELinux</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>devices/tech/security/selinux/concepts.html">Concepts</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/security/selinux/implement.html">Implementation</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/security/selinux/customize.html">Customization</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/security/selinux/validate.html">Validation</a></li>
+ </ul>
+ </li>
<li class="nav-section">
<div class="nav-section-header">
<a href="<?cs var:toroot ?>devices/tech/security/verifiedboot/index.html">
@@ -298,48 +335,13 @@
<li><a href="<?cs var:toroot ?>devices/tech/security/verifiedboot/dm-verity.html">Implementing dm-verity</a></li>
</ul>
</li>
- <li class="nav-section">
- <div class="nav-section-header">
- <a href="<?cs var:toroot ?>devices/tech/security/selinux/index.html">
- <span class="en">Security-Enhanced Linux</span>
- </a>
- </div>
- <ul>
- <li><a href="<?cs var:toroot ?>devices/tech/security/selinux/concepts.html">Concepts</a></li>
- <li><a href="<?cs var:toroot ?>devices/tech/security/selinux/implement.html">Implementation</a></li>
- <li><a href="<?cs var:toroot ?>devices/tech/security/selinux/customize.html">Customization</a></li>
- <li><a href="<?cs var:toroot ?>devices/tech/security/selinux/validate.html">Validation</a></li>
- </ul>
- </li>
+
</ul>
</li>
</ul>
<li class="nav-section">
<div class="nav-section-header">
- <a href="<?cs var:toroot ?>devices/tech/resources.html">
- <span class="en">System Resources</span>
- </a>
- </div>
- <ul>
- <li><a href="<?cs var:toroot ?>devices/tech/filesystem-config.html">File System Configuration</a></li>
- <li><a href="<?cs var:toroot ?>devices/tech/kernel.html">Kernel Configuration</a></li>
- <li><a href="<?cs var:toroot ?>devices/tech/netstats.html">Network Usage Data</a></li>
- <li class="nav-section">
- <div class="nav-section-header">
- <a href="<?cs var:toroot ?>devices/tech/ram/index.html">
- <span class="en">RAM</span>
- </a>
- </div>
- <ul>
- <li><a href="<?cs var:toroot ?>devices/tech/ram/low-ram.html">Low RAM Configuration</a></li>
- <li><a href="<?cs var:toroot ?>devices/tech/ram/procstats.html">RAM Usage Data</a></li>
- </ul>
- </li>
- </ul>
-
- <li class="nav-section">
- <div class="nav-section-header">
<a href="<?cs var:toroot ?>devices/tech/test_infra/tradefed/index.html">
<span class="en">Testing Infrastructure</span>
</a>
diff --git a/src/devices/storage/index.jd b/src/devices/storage/index.jd
index e8786ec..177e945 100644
--- a/src/devices/storage/index.jd
+++ b/src/devices/storage/index.jd
@@ -1,4 +1,4 @@
-page.title=External Storage
+page.title=Storage
@jd:body
<!--
diff --git a/src/devices/tech/filesystem-config.jd b/src/devices/tech/config/filesystem.jd
similarity index 100%
rename from src/devices/tech/filesystem-config.jd
rename to src/devices/tech/config/filesystem.jd
diff --git a/src/devices/tech/resources.jd b/src/devices/tech/config/index.jd
similarity index 89%
rename from src/devices/tech/resources.jd
rename to src/devices/tech/config/index.jd
index dade1a7..ef58cb9 100644
--- a/src/devices/tech/resources.jd
+++ b/src/devices/tech/config/index.jd
@@ -1,4 +1,4 @@
-page.title=System Resources
+page.title=Configuration
@jd:body
<!--
@@ -17,4 +17,4 @@
limitations under the License.
-->
-<p> The following sections contain information, documentation, tips and tricks about Android system resources.</p>
+<p> The following sections contain information, documentation, tips and tricks for configuring Android components.</p>
diff --git a/src/devices/tech/kernel.jd b/src/devices/tech/config/kernel.jd
similarity index 99%
rename from src/devices/tech/kernel.jd
rename to src/devices/tech/config/kernel.jd
index 637c5c4..8d5cf43 100644
--- a/src/devices/tech/kernel.jd
+++ b/src/devices/tech/config/kernel.jd
@@ -1,4 +1,4 @@
-page.title=Android Kernel Configuration
+page.title=Kernel Configuration
@jd:body
<!--
diff --git a/src/devices/tech/ram/low-ram.jd b/src/devices/tech/config/low-ram.jd
similarity index 99%
rename from src/devices/tech/ram/low-ram.jd
rename to src/devices/tech/config/low-ram.jd
index f0892a7..d08692a 100644
--- a/src/devices/tech/ram/low-ram.jd
+++ b/src/devices/tech/config/low-ram.jd
@@ -1,4 +1,4 @@
-page.title=Low RAM
+page.title=Low RAM Configuration
@jd:body
<!--
diff --git a/src/devices/tech/debug/tuning.jd b/src/devices/tech/config/renderer.jd
similarity index 98%
rename from src/devices/tech/debug/tuning.jd
rename to src/devices/tech/config/renderer.jd
index 96cac22..f19b185 100644
--- a/src/devices/tech/debug/tuning.jd
+++ b/src/devices/tech/config/renderer.jd
@@ -1,4 +1,4 @@
-page.title=Performance tuning
+page.title=OpenGLRenderer Configuration
@jd:body
<!--
diff --git a/src/devices/tech/config/runtime_perms.jd b/src/devices/tech/config/runtime_perms.jd
new file mode 100644
index 0000000..ef54b78
--- /dev/null
+++ b/src/devices/tech/config/runtime_perms.jd
@@ -0,0 +1,107 @@
+page.title=Runtime Permissions
+@jd:body
+
+<!--
+ 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
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ 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>
+ </div>
+</div>
+
+<p>The Android 6.0 release presents a new application permission model aimed at making permissions more understandable, useful, and secure for users. The model moves Android applications that require dangerous permissions (see <a href="#affected-permissions">Affected permissions</a>) from an <i>install</i> time permission model to <i>runtime</i> permission model:</p>
+
+<ul>
+<li><strong>Install Time Permissions</strong> (<i>Android 5.1 and earlier</i>). Users grant dangerous permissions to an app when installing or updating the app. OEMs/carriers can pre-install apps with pre-granted permissions without notifying the user. </li>
+<li><strong>Runtime Permissions</strong> (Android <i>6.0 and later</i>). Users grant dangerous permissions to an app when the app is running. Applications decide when to request permissions (such as when the app launches or the user accesses a specific feature), but must allow the user to grant/deny application access to specific permission groups. OEMs/carriers can pre-install apps but cannot pre-grant permissions (see <a href="#creating-exceptions">Creating exceptions</a>). </li>
+</ul>
+
+<p>The move to runtime permissions provides users additional context and visibility into the permissions that applications are seeking or have been granted. The new model also encourages developers to help users understand why applications require the requested permissions and to provide greater transparency about the benefits and hazards of granting or denying permissions. Users can revoke application permissions using the Apps menu in Settings.</p>
+
+<h2 id="affected-permissions">Affected permissions</h2>
+
+<p>The Android 6.0 release requires only dangerous permissions to use a runtime permissions model. Dangerous permissions are higher-risk permissions (such as <code>READ_CALENDAR</code>) that grant requesting applications access to private user data or control over the device that can negatively impact the user. To view a list of dangerous permissions, run the command: <code>adb shell pm list permissions -g -d</code> .</p>
+
+<p>This release does not change the behavior of normal permissions (all non-dangerous permissions including normal, system, and signature permissions). Normal permissions are lower-risk permissions (such as <code>SET_WALLPAPER</code>) that grant requesting applications access to isolated application-level features with minimal risk to other applications, the system, or the user. As in Android 5.1 and earlier releases, the system automatically grants normal permissions to a requesting application at installation and does not prompt the user for approval. For details on permissions, refer to <a href="http://developer.android.com/guide/topics/manifest/permission-element.html"><permission> element documentation</a>.</p>
+
+<h2 id="requirements">Requirements</h2>
+
+<p>The runtime permission model applies to all applications, including pre-installed apps and apps delivered to the device as part of the setup process. Application software requirements include: </p>
+<ul>
+<li>Runtime permission model must be consistent across all devices running Android 6.0. Enforced by Android Compatibility Test Suite (CTS) tests.</li>
+<li>Apps must prompt users to grant application permissions at runtime. For details, see Updating Applications.Limited exceptions may be granted to default applications and handlers that provide basic device functionality determined to be fundamental to the expected operation of the device (i.e. the device's default Dialer app for handling ACTION_CALL may have Phone permission access). For details, see <a href="#creating-exceptions">Creating exceptions</a>.</li>
+<li>Pre-loaded apps with "dangerous permission" MUST target API level 23 and the AOSP permission model of Android 6.0 should be maintained (i.e. the UI flow during an app installation should not deviate from the AOSP implementation of PackageInstaller, users can even revoke the dangerous permissions of pre-installed apps etc.).</li>
+<li>Headless applications must use an activity to request permissions or share a UID with another application that has the necessary permissions. For details, see <a href="#headless-apps">Headless applications</a>.</li>
+</ul>
+
+<h2 id="permissions-migration">Permissions migration</h2>
+
+<p>Permissions granted to applications on Android 5.x remain granted after updating to Android 6.0, but users can revoke those permissions at any time.</p>
+
+<h2 id="integration">Integration</h2>
+
+<p>When integrating the Android 6.0 application runtime permissions model, you must update pre-installed applications to work with the new model. You can also define exceptions for apps that are the default handlers/providers for core functionality, define custom permissions, and customize the theme used in the PackageInstaller.</p>
+
+<h3 id="updating-apps">Updating applications</h3>
+
+<p>Applications on the system image and pre-installed applications are not automatically pre-granted permissions. We encourage you to work with pre-installed app developers (OEM, Carrier, and third party) to make the required app modifications using the <a href="https://developer.android.com/preview/features/runtime-permissions.html">guidelines</a> posted on the developer portal. Specifically, you must ensure that pre-installed applications are modified to avoid crashes and other issues when users revoke permissions.</p>
+
+<h4 id="preloaded-apps">Pre-loaded applications</h4>
+<p>Pre-loaded apps that use dangerous permissions MUST target API level 23 and maintain the Android 6.0 AOSP permission model (i.e. the UI flow during an app installation should not deviate from the AOSP implementation of PackageInstaller, users can even revoke the dangerous permissions of pre-installed apps etc.).</p>
+
+<h4 id="headless-apps">Headless applications</h4>
+<p>Only activities can request permissions; services cannot directly request permissions. </p>
+<ul>
+<li>In Android 5.1 and earlier releases, headless applications can request permissions when installed or pre-installed without the use of an activity.</li>
+<li>In Android 6.0, headless applications must use one of the following methods to request permissions:<ul>
+<li>Add an activity to request permissions (preferred method).</li>
+<li>Share a UID with another application that has the necessary permissions. Use this method only when you need the platform to handle multiple APKs as a single application.</li>
+</ul></li>
+</ul>
+<p>The goal is to avoid confusing users with permission requests that appear out of context.</p>
+
+<h3 id="customizing-package-install">Customizing PackageInstaller</h3>
+<p>If desired, you can customize the Permissions UI <b>theme</b> by updating the default device themes (<code>Theme.DeviceDefault.Settings</code> and <code>Theme.DeviceDefault.Light.Dialog.NoActionBar</code>) used by PackageInstaller. However, because consistency is critical for app developers, you cannot customize the placement, position, and rules of when the Permissions UI appears.</p>
+<p>To include <b>strings</b> for additional languages, contribute the strings to AOSP.</p>
+
+<h3 id="creating-exceptions">Creating exceptions</h3>
+<p>You can pre-grant permissions to applications that are default handlers or providers for core OS functionality using the <code>DefaultPermissionGrantPolicy.java</code> in PackageManager. Examples:</p>
+
+<code>
+<p>ACTION_CALL (Dialer) Default</p>
+<ul>
+<li>Phone, Contacts, SMS, Microphone</li>
+</ul>
+<p>SMS_DELIVER_ACTION (SMS/MMS) Default</p>
+<ul>
+<li>Phone, Contacts, SMS</li>
+</ul>
+</code>
+
+<h3 id="defining-custom-perms">Defining custom permissions</h3>
+<p>You can define custom permissions and groups as <i>normal</i> or <i>dangerous</i> and add OEM/Carrier-specific permissions to existing permissions groups, just as you could in Android 5.x and earlier releases.</p>
+
+<p>In the Android 6.0 release, if you add a new dangerous permission, it must be handled in the same way as other dangerous permissions (requested during app runtime and revocable by users). Specifically: </p>
+
+<ul>
+<li>You can add new permissions to a current group, but you cannot modify the AOSP mapping of dangerous permissions and dangerous permissions group (e.g. you cannot remove a permission from a group and assign to other group).</li>
+<li>You can add new permission groups in applications installed on the device, but you cannot add new permissions groups in the platform manifest.</li>
+</ul>
+
+<h2 id="testing-perms">Testing permissions</h2>
+<p>The Android 6.0 release includes new Compatibility Test Suite (CTS) tests that verify individual permissions are mapped to the correct Groups. Passing these tests is a requirement for Android 6.0 CTS compatibility.</p>
\ No newline at end of file
diff --git a/src/devices/tech/config/uicc.jd b/src/devices/tech/config/uicc.jd
new file mode 100644
index 0000000..762e25d
--- /dev/null
+++ b/src/devices/tech/config/uicc.jd
@@ -0,0 +1,310 @@
+page.title=UICC Carrier Privileges
+@jd:body
+
+<!--
+ 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
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ 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>
+ </div>
+</div>
+
+<p>Android 5.1 introduced a new mechanism to grant special privileges for APIs relevant
+to the Universal Integrated Circuit Card (UICC) owner’s apps. The Android platform will load
+certificates stored on a UICC and grant
+permission to apps signed by these certificates to make calls to a handful of
+special APIs. Since carriers have full control of the UICC, this mechanism
+provides a secure and flexible way to manage apps from the Mobile Network
+Operator (MNO) hosted on generic application distribution channels such as
+Google Play but still have special privileges on devices without the need for
+the apps to be signed by the per-device platform certificate or be
+pre-installed as a system app.</p>
+
+<h2 id=rules_on_uicc>Rules on UICC</h2>
+
+<p>Storage on the UICC is compatible with the <a
+href="http://www.globalplatform.org/specificationsdevice.asp">GlobalPlatform
+Secure Element Access Control specification</a>. The application identifier
+(AID) on card is A00000015141434C00, and the standard GET DATA command is used
+to fetch rules stored on the card. You may update these rules via card
+over-the-air (OTA) update. Data hierarchy is as follows (noting the
+two-character letter and number combination in parentheses is the object tag).
+(An extension to spec is under review.)</p>
+
+<p>Each rule is a REF-AR-DO (E2) and consists of a concatenation of a REF-DO and
+an AR-DO:</p>
+
+<ul>
+ <li>REF-DO (E1) contains a DeviceAppID-REF-DO or a concatenation of a
+DeviceAppID-REF-DO and a PKG-REF-DO.
+ <ul>
+ <li>DeviceAppID-REF-DO (C1) stores the SHA1 (20 bytes) or SHA256 (32 bytes)
+signature of the certificate.
+ <li>PKG-REF-DO (CA) is the full package name string defined in manifest, ASCII
+encoded, max length 127 bytes.
+ </ul>
+ <li>AR-DO (E3) is extended to include PERM-AR-DO (DB), which is an 8-byte bit mask
+representing 64 separate permissions.
+</ul>
+
+<p>If PKG-REF-DO is not present, any app signed by the certificate will be granted
+access; otherwise both certificate and package name need to match.</p>
+
+<h3 id=example>Example</h3>
+
+<p>App name: com.google.android.apps.myapp<br>
+Sha1 of certificate in hex string:</p>
+<pre>
+AB:CD:92:CB:B1:56:B2:80:FA:4E:14:29:A6:EC:EE:B6:E5:C1:BF:E4</pre>
+
+<p>Rule on UICC in hex string:</p>
+<pre>
+E243 <= 43 is value length in hex
+ E135
+ C114 ABCD92CBB156B280FA4E1429A6ECEEB6E5C1BFE4
+ CA1D 636F6D2E676F6F676C652E616E64726F69642E617070732E6D79617070
+ E30A
+ DB08 0000000000000001
+</pre>
+
+<h2 id=enabled_apis>Enabled APIs</h2>
+
+<p>Currently we support the following APIs, listed below (refer to
+developer.android.com for more details).</p>
+
+<h3 id=telephonymanager>TelephonyManager</h3>
+
+<p>API to check whether calling application has been granted carrier privileges:</p>
+
+<pre>
+<a
+href="http://developer.android.com/reference/android/telephony/TelephonyManager.html#hasCarrierPrivileges()">hasCarrierPrivileges</a>
+</pre>
+
+<p>APIs for brand and number override:</p>
+
+<pre>
+setOperatorBrandOverride
+setLine1NumberForDisplay
+setVoiceMailNumber
+</pre>
+
+<p>APIs for direct UICC communication:</p>
+
+<pre>
+iccOpenLogicalChannel
+iccCloseLogicalChannel
+iccExchangeSimIO
+iccTransmitApduLogicalChannel
+iccTransmitApduBasicChannel
+sendEnvelopeWithStatus
+</pre>
+
+<p>API to set device mode to global:</p>
+
+<pre>
+setPreferredNetworkTypeToGlobal
+</pre>
+
+<h3 id=smsmanager>SmsManager</h3>
+
+<p>API allows caller to create new incoming SMS messages:</p>
+
+<pre>
+injectSmsPdu
+</pre>
+
+<h4 id=carriermessagingservice>CarrierMessagingService</h4>
+
+<p>A service that receives calls from the system when new SMS and MMS are
+sent or
+received. To extend this class, you must declare the service in your manifest
+file with the android.Manifest.permission#BIND_CARRIER_MESSAGING_SERVICE
+permission and include an intent filter with the #SERVICE_INTERFACE action.</p>
+
+<pre>
+onFilterSms
+onSendTextSms
+onSendDataSms
+onSendMultipartTextSms
+onSendMms
+onDownloadMms
+</pre>
+
+<h4 id=telephonyprovider>TelephonyProvider</h4>
+
+<p>Content provider APIs that allow modification to the telephony database, value
+fields are defined at Telephony.Carriers:</p>
+
+<pre>
+insert, delete, update, query
+</pre>
+
+<p>See the <a
+href="https://developer.android.com/reference/android/provider/Telephony.html">Telephony
+reference on developer.android.com</a> for additional information.</p>
+
+<h2 id=android_platform>Android platform</h2>
+
+<p>On a detected UICC, the platform will construct internal UICC objects that
+include carrier privilege rules as part of the UICC. <a
+href="https://android.googlesource.com/platform/frameworks/opt/telephony/+/master/src/java/com/android/internal/telephony/uicc/UiccCarrierPrivilegeRules.java">UiccCarrierPrivilegeRules.java</a>
+will load rules, parse them from the UICC card, and cache them in memory. When
+a privilege check is needed, UiccCarrierPrivilegeRules will compare the caller
+certificate with its own rules one by one. If the UICC is removed, rules will
+be destroyed along with the UICC object.</p>
+
+<h2 id=faq>FAQ</h2>
+
+<p><strong>How can certificates be updated on the UICC?
+</strong></p>
+
+<p><em>A: Use existing card OTA update mechanism.
+</em></p>
+
+<p><strong>Can it co-exist with other rules?
+</strong></p>
+
+<p><em>A: It’s fine to have other security rules on the UICC under same AID; the
+platform will filter them out automatically.
+</em></p>
+
+<p><strong>What happens when the UICC is removed for an app that relies on the
+certificates on it?
+</strong></p>
+
+<p><em>A: The app will lose its privileges because the rules associated with the UICC
+are destroyed on UICC removal.
+</em></p>
+
+<p><strong>Is there a limit on the number of certificates on the UICC?
+</strong></p>
+
+<p><em>A: The platform doesn’t limit the number of certificates; but because the check
+is linear, too many rules may incur a latency for check.
+</em></p>
+
+<p><strong>Is there a limit to number of APIs we can support via this method?
+</strong></p>
+
+<p><em>A: No, but we limit the scope of APIs to carrier related.
+</em></p>
+
+<p><strong>Are there some APIs prohibited from using this method? If so, how do you
+enforce them? (ie. Will you have tests to validate which APIs are supported via
+this method?)
+</strong></p>
+
+<p><em>A: Please refer to the "API Behavioral Compatibility" section of the <a
+href="{@docRoot}compatibility/android-cdd.pdf">Android Compatibility Definition
+Document CDD)</a>. We have some CTS tests to make sure the permission model of
+the APIs is not changed.
+</em></p>
+
+<p><strong>How does this work with the multi-SIM feature?
+</strong></p>
+
+<p><em>A: The default SIM that gets set by the user will be used.</em></p>
+
+<p><strong>Does this in any way interact or overlap with other SE access technologies e.g.
+SEEK?
+<em>A: As an example, SEEK uses the same AID as on the UICC. So the rules co-exist
+and are filtered by either SEEK or UiccCarrierPrivileges.</em>
+</strong></p>
+
+<p><strong>When is it a good time to check carrier privileges?
+<em>A: After the SIM state loaded broadcast.</em>
+</strong></p>
+
+<p><strong>Can OEMs disable part of carrier APIs?
+</strong></p>
+
+<p><em>A: No. We believe current APIs are the minimal set, and we plan to use the bit
+mask for finer granularity control in the future.
+</em></p>
+
+<p><strong>Does setOperatorBrandOverride override ALL other forms of operator name
+strings? For example, SE13, UICC SPN, network based NITZ, etc.?
+</strong></p>
+
+<p><em>A: See the SPN entry within TelephonyManager:
+<a
+href="http://developer.android.com/reference/android/telephony/TelephonyManager.html">http://developer.android.com/reference/android/telephony/TelephonyManager.html</a>
+</em></p>
+
+<p><strong>What does the injectSmsPdu method call do?
+</strong></p>
+
+<p><em>A: This facilitates SMS backup/restore in the cloud. The injectSmsPdu call
+enables the restore function.
+</em></p>
+
+<p><strong>For SMS filtering, is the onFilterSms call based on SMS UDH port filtering? Or
+would carrier apps have access to ALL incoming SMS?
+</strong></p>
+
+<p><em>A: Carriers have access to all SMS data.</em></p>
+
+<p><strong>Since the extension of DeviceAppID-REF-DO to support 32 bytes appears
+incompatible with the current GP spec (which allows 0 or 20 bytes only) why are
+you introducing this change? Do you not consider SHA-1 to be good enough to
+avoid collisions? Have you proposed this change to GP already, as this could
+be backwards incompatible with existing ARA-M / ARF?
+</strong></p>
+
+<p><em>A: For providing future proof security this extension introduces SHA-256 for
+DeviceAppID-REF-DO in addition to SHA-1 which is currently the only option in
+the GP SEAC standard. It is highly recommended to use SHA-256.</em></p>
+
+<p><strong>If DeviceAppID is 0 (empty), would you really apply the rule to all device
+applications not covered by a specific rule?
+</strong></p>
+
+<p><em>A: Carrier apis require deviceappid-ref-do be non-empty. Being empty is
+intended for test purpose and is not recommended for operational deployments.</em></p>
+
+<p><strong>According to your spec, PKG-REF-DO used just by itself, without
+DeviceAppID-REF-DO, should not be accepted. But it is still described in Table
+6-4 as extending the definition of REF-DO. Is this on purpose? What will be the
+behavior of the code when only a PKG-REF-DO is used in a REF-DO?
+</strong></p>
+
+<p><em>A: The option of having PKG-REF-DO as a single value item in REF-DO was removed
+in the latest version. PKG-REF-DO should only occur in combination with
+DeviceAppID-REF-DO.
+</em></p>
+
+<p><strong>We assume we can grant access to all carrier-based permissions or have a
+finer-grained control. What will define the mapping between the bit mask and
+the actual permissions then? One permission per class? One permission per
+method specifically? Will 64 separate permissions be enough in the long run?
+</strong></p>
+
+<p><em>A: This is reserved for the future, and we welcome suggestions.</em></p>
+
+<p><strong>Can you further define the DeviceAppID for Android specifically? Since this is
+the SHA-1 (20 bytes) hash value of the Publisher certificate used to signed the
+given app, shouldn't the name reflect that purpose? (The name could be
+confusing to many readers as the rule will be applicable then to all apps
+signed with that same Publisher certificate.)
+</strong></p>
+
+<p><em>A: See the <a
+href="#rules_on_uicc">Rules on UICC</a> section for details. The deviceAppID storing
+certificates is already supported by the existing spec. We tried to minimize
+spec changes to lower barrier for adoption. </em></p>
diff --git a/src/devices/tech/netstats.jd b/src/devices/tech/debug/netstats.jd
similarity index 100%
rename from src/devices/tech/netstats.jd
rename to src/devices/tech/debug/netstats.jd
diff --git a/src/devices/tech/ram/procstats.jd b/src/devices/tech/debug/procstats.jd
similarity index 100%
rename from src/devices/tech/ram/procstats.jd
rename to src/devices/tech/debug/procstats.jd
diff --git a/src/devices/tech/power/batterystats.jd b/src/devices/tech/power/batterystats.jd
index 92aeb04..11b0b48 100644
--- a/src/devices/tech/power/batterystats.jd
+++ b/src/devices/tech/power/batterystats.jd
@@ -1,4 +1,4 @@
-page.title=Viewing Battery Usage Data
+page.title=Viewing Battery Use Data
@jd:body
<!--
diff --git a/src/devices/tech/power/component.jd b/src/devices/tech/power/component.jd
new file mode 100644
index 0000000..cb38615
--- /dev/null
+++ b/src/devices/tech/power/component.jd
@@ -0,0 +1,259 @@
+page.title=Measuring Component Power
+@jd:body
+
+<!--
+ 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
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ 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>
+ </div>
+</div>
+
+
+<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>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>
+
+<h2 id="control-consumption">Controlling power consumption</h2>
+
+<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><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:
+<ul>
+<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 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 class="note">
+<strong>Note</strong>: 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>
+
+<h2 id="control-suspend">Controlling system suspend</h2>
+
+<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>
+
+<h3 id="prevent-suspend">Preventing system suspend</h3>
+
+<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 > /sys/power/wake_lock"
+</pre>
+
+<p>While in <code>wake_lock</code>, 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 > /sys/power/wake_unlock"
+</pre>
+
+<h3 id="measure-suspend">Measuring system suspend</h3>
+
+<p>To measure the power draw during the system suspend state, measure the value of
+<code>cpu.idle</code> 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>
+
+<h2 id="control-cpu">Controlling CPU speeds</h2>
+
+<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 <code>cpu.speeds</code> 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 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 > /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
+</pre>
+
+<p class="note">
+<strong>Note</strong>: The exact commands differ depending on the platform cpufreq implementation.
+</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 to place
+the CPU in a CPU-bound loop using the command:</p>
+<pre>
+# while true; do true; done
+</pre>
+
+<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.awake</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.</p>
+
+<p>For the <code>cpu.active</code> value, measure power when the system is not in suspend mode and not executing tasks. One CPU (usually the primary CPU) should run the task while all other CPUs
+should be in an idle state.</p>
+
+<h2 id="screen-power">Measuring screen power</h2>
+
+<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>
+
+<h2 id="wifi-power">Measuring Wi-Fi power</h2>
+
+<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. 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 > 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>
\ No newline at end of file
diff --git a/src/devices/tech/power/device.jd b/src/devices/tech/power/device.jd
new file mode 100644
index 0000000..985b9c0
--- /dev/null
+++ b/src/devices/tech/power/device.jd
@@ -0,0 +1,250 @@
+page.title=Measuring Device Power
+@jd:body
+
+<!--
+ 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
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ 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>
+ </div>
+</div>
+
+<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
+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>
+
+<h2 id="power-consumption">Reading power consumption</h2>
+
+<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>
+
+<h2 id="avail-props">Available properties</h2>
+
+<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>
+
+<h2 id="maxim-fuel">Maxim fuel gauge</h2>
+
+<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>
+
+<h2 id="nexus-devices">Supported Nexus devices</h2>
+
+<h5 id="nexus-5">Nexus 5</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 id="nexus-6">Nexus 6</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 id="nexus-9">Nexus 9</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 id="nexus-10">Nexus 10</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>
\ No newline at end of file
diff --git a/src/devices/tech/power/index.jd b/src/devices/tech/power/index.jd
index c3a6a9a..0876ae7 100644
--- a/src/devices/tech/power/index.jd
+++ b/src/devices/tech/power/index.jd
@@ -23,15 +23,15 @@
</div>
</div>
-<p>Battery usage information is derived from battery usage statistics and power profile values.</p>
+<p>Battery use information is derived from battery use statistics and power profile values.</p>
-<h2 id="usage-statistics">Battery Usage Statistics</h2>
+<h2 id="usage-statistics">Battery use statistics</h2>
-<p>The framework automatically determines battery usage statistics by tracking how long device
+<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 doesn’t track battery current draw directly,
+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.</p>
@@ -40,9 +40,9 @@
<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>
+<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>
</ul>
<p>Resource consumption is associated with the application using the resource. When multiple
@@ -50,27 +50,25 @@
suspending), the framework spreads consumption across those applications, although not necessarily
equally.</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>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 usage statistics are handled entirely by the framework and do not require OEM
+<p>Battery use statistics are handled entirely by the framework and do not require OEM
modifications.</p>
-<h2 id="profile-values">Power Profile Values</h2>
+<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="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>.
-See the <a href="#power-values">Power Values</a> table for guidance on these
-settings.</p>
+<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="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>.
+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>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
@@ -78,689 +76,7 @@
each brightness level, then multiplies those time intervals by an interpolated display brightness
cost.</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
+<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 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 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>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><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:
-
-<ul>
-<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 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>
-
-<h3 id="control-suspend">Controlling System Suspend</h3>
-
-<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 > /sys/power/wake_lock"
-</pre>
-
-<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 > /sys/power/wake_unlock"
-</pre>
-
-<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>
-
-<h3 id="control-cpu">Controlling CPU Speeds</h3>
-
-<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 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 > /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
-</pre>
-
-<p class="note">
-<strong>Note</strong>: The exact commands differ depending on the platform cpufreq implementation.
-</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>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.awake</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.</p>
-
-<p>For the <code>cpu.active</code> 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.</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. 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 > 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>
-
-<h3 id="nexus-devices">Supported Nexus Devices</h3>
-
-<h5 id="nexus-5">Nexus 5</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 id="nexus-6">Nexus 6</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 id="nexus-9">Nexus 9</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 id="nexus-10">Nexus 10</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>
-
-See <a href="{@docRoot}devices/tech/power/batterystats.html">Viewing Battery Usage Data</a>.
-
-<h2 id="power-values">Power Values</h2>
-
-<p>Device manufacturers must provide a component power profile defined in
-<em><device></em>/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).</p>
-
-<table>
-<tr>
- <th>Name</th>
- <th>Description</th>
- <th>Example Value</th>
- <th>Notes</th>
-</tr>
-<tr>
- <td>none</td>
- <td>Nothing</td>
- <td>0</td>
- <td></td>
-</tr>
-
-<tr>
- <td>screen.on</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>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>14mA</td>
- <td></td>
-</tr>
-
-<tr>
- <td>bluetooth.on</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 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 Wi-Fi.</td>
- <td>31mA</td>
- <td></td>
-</tr>
-
-<tr>
- <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>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>Reserved for future use.</td>
-</tr>
-
-<tr>
- <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>100mA-300mA</td>
- <td></td>
-</tr>
-
-<tr>
- <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</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>125000KHz, 250000KHz, 500000KHz, 1000000KHz, 1500000KHz</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>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>50mA</td>
- <td>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.</td>
-</tr>
-
-<tr>
- <td>cpu.active</td>
- <td>Additional power used by CPUs when running at different speeds.</td>
- <td>100mA, 120mA, 140mA, 160mA, 200mA</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>
-</tr>
-
-<tr>
- <td>battery.capacity</td>
- <td>The total battery capacity in mAh.</td>
- <td>3000mAh</td>
- <td></td>
-</tr>
-
-</table>
-
-<h3 id="sample">Sample file</h3>
-
-<pre>
-<!-- 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 <!-- 250 MHz -->
-500000 <!-- 500 MHz -->
-750000 <!-- 750 MHz -->
-1000000 <!-- 1 GHz -->
-1200000 <!-- 1.2 GHz -->
-
-<!-- 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) -->
-
-</pre>
diff --git a/src/devices/tech/power/values.jd b/src/devices/tech/power/values.jd
new file mode 100644
index 0000000..e88900a
--- /dev/null
+++ b/src/devices/tech/power/values.jd
@@ -0,0 +1,264 @@
+page.title=Measuring Power Values
+@jd:body
+
+<!--
+ 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
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ 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>
+ </div>
+</div>
+
+
+<p>Device manufacturers must provide a component power profile in
+<code>/frameworks/base/core/res/res/xml/power_profile.xml</code>.</p>
+
+<p>To determine values for power profiles, 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 baseline power uses as appropriate).
+</p>
+
+<h2 id="values">Power values</h2>
+
+<table>
+<tr>
+ <th>Name</th>
+ <th>Description</th>
+ <th>Example Value</th>
+ <th>Notes</th>
+</tr>
+<tr>
+ <td>none</td>
+ <td>Nothing</td>
+ <td>0</td>
+ <td></td>
+</tr>
+
+<tr>
+ <td>screen.on</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>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>14mA</td>
+ <td></td>
+</tr>
+
+<tr>
+ <td>bluetooth.on</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 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 Wi-Fi.</td>
+ <td>31mA</td>
+ <td></td>
+</tr>
+
+<tr>
+ <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>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>Reserved for future use.</td>
+</tr>
+
+<tr>
+ <td>camera.avg</td>
+ <td>Average power use by the camera subsystem for a typical camera
+ application.</td>
+ <td>600mA</td>
+ <td>Intended as a rough estimate for an application running a preview
+ and capturing approximately 10 full-resolution pictures per minute.</td>
+</tr>
+
+<tr>
+ <td>camera.flashlight</td>
+ <td>Average power used by the camera flash module when on.</td>
+ <td>200mA</td>
+ <td></td>
+</tr>
+
+
+<tr>
+ <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>100mA-300mA</td>
+ <td></td>
+</tr>
+
+<tr>
+ <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</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. Values can be the same or decrease with increasing signal
+ strength. If you provide only one value, the same value is used for all
+ strengths. If you provide two values, the first is used for no-signal, the
+ second value is used 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>125000KHz, 250000KHz, 500000KHz, 1000000KHz, 1500000KHz</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>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>50mA</td>
+ <td>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.</td>
+</tr>
+
+<tr>
+ <td>cpu.active</td>
+ <td>Additional power used by CPUs when running at different speeds.</td>
+ <td>100mA, 120mA, 140mA, 160mA, 200mA</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>
+</tr>
+
+<tr>
+ <td>battery.capacity</td>
+ <td>Total battery capacity in mAh.</td>
+ <td>3000mAh</td>
+ <td></td>
+</tr>
+</table>
+
+<h2 id="sample">Sample file</h2>
+
+<pre>
+<!-- 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 <!-- 250 MHz -->
+500000 <!-- 500 MHz -->
+750000 <!-- 750 MHz -->
+1000000 <!-- 1 GHz -->
+1200000 <!-- 1.2 GHz -->
+
+<!-- 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) -->
+
+</pre>
\ No newline at end of file
diff --git a/src/devices/tech/ram/index.jd b/src/devices/tech/ram/index.jd
deleted file mode 100644
index 2bb2717..0000000
--- a/src/devices/tech/ram/index.jd
+++ /dev/null
@@ -1,21 +0,0 @@
-page.title=RAM
-@jd:body
-
-<!--
- 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
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing, software
- distributed under the License is distributed on an "AS IS" BASIS,
- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
- See the License for the specific language governing permissions and
- limitations under the License.
--->
-
-<p> The following sections contain information, documentation, tips and tricks about Android memory managment and RAM diagnostics.</p>
-
diff --git a/src/devices/tech/security/authentication/index.jd b/src/devices/tech/security/authentication/index.jd
new file mode 100644
index 0000000..66560a7
--- /dev/null
+++ b/src/devices/tech/security/authentication/index.jd
@@ -0,0 +1,250 @@
+page.title=Authentication
+@jd:body
+
+<!--
+ 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
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ 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>
+ </div>
+</div>
+
+<h2 id=overview>Overview</h2>
+
+<p>Android 6.0 introduces the concept of user-authentication-gated cryptographic
+keys. To achieve this, two key components need to work together.
+First is the cryptographic key storage and service provider, which stores
+cryptographic keys and provides standard crypto routines on top of them. Second
+is any number of user authenticators that may attest to the user's presence
+and/or successful authentication.</p>
+
+<p>The cryptographic key storage in Android is provided by the keystore service and Keymaster.
+(Also see information about
+the <a href="https://developer.android.com/training/articles/keystore.html">Android Keystore system</a>,
+at the framework level, which is backed by the keystore service.) For Android 6.0,
+the two supported authentication components are Gatekeeper (for
+PIN/pattern/password authentication) and Fingerprint (for fingerprint
+authentication). These components communicate their authentication
+state with the keystore service via an authenticated channel.</p>
+
+<ul>
+ <li><strong>The keystore service and Keymaster.</strong> Cryptographic services,
+ including hardware-backed cryptography for key storage,
+ which might include a Trusted Execution Environment (TEE).</li>
+ <li><strong>Gatekeeper</strong>. Components for PIN, pattern, and password authentication.</li>
+ <li><strong>Fingerprint.</strong> Components for fingerprint authentication.</li>
+</ul>
+
+<h2 id=architecture>Architecture</h2>
+
+<p>The Gatekeeper and Fingerprint components work with Keymaster and other
+components to support the use of hardware-backed <a href="#authentication_token_format">authentication tokens</a> (referred to below as "AuthTokens").</p>
+
+<h3 id=enrollment>Enrollment</h3>
+
+<p>Upon first boot of the device after a factory reset, all authenticators are prepared to receive
+credential enrollments from the user.</p>
+
+<p>The user must initially enroll a PIN/pattern/password with Gatekeeper. This
+initial enrollment creates a randomly generated, 64-bit User SID (user secure
+identifier, described further below) that serves as an identifier for the user
+and as a binding token for the user's cryptographic material.
+This User SID is cryptographically bound to the user's password.
+As detailed below, successful authentications to Gatekeeper result in AuthTokens that contain the User SID
+for that password.</p>
+
+<p>When a user wants to change their credential, they must present their existing
+credential. If the existing credential is verified successfully, the User SID
+associated with the existing credential is transferred to the new credential.
+This allows the user to keep accessing their keys after changing their
+credential. If a user does not present their existing credential, the new one
+is enrolled with a fully random User SID. The user can access the device but
+keys created under the old User SID are permanently lost. This is known as an
+"untrusted enroll."</p>
+
+<p>Note that an untrusted enroll will not be allowed under normal circumstances by
+the Android framework, so most users won't ever see this functionality.
+However, forcible password resets either by a device administrator or an
+attacker may cause this to occur.</p>
+
+<h3 id=authentication>Authentication</h3>
+
+<p>Now that the user has set up a credential and received a User SID, they may
+proceed to start authentication.</p>
+
+<p>In the diagram below, authentication starts when a user provides a PIN,
+pattern, password, or fingerprint. All TEE components share a secret key which
+they use to authenticate each other's messages.</p>
+
+<img src="../images/authentication-flow.png" alt="Authentication flow" id="figure1" />
+<p class="img-caption"><strong>Figure 1.</strong> Authentication flow</p>
+
+<p>The numbers in the following steps correspond to the numbers in the diagram
+above, and include reference to both the Android OS and the TEE OS: </p>
+
+<ol>
+ <li>A user provides a PIN, pattern, password, or fingerprint. The
+<code>LockSettingsService</code> or <code>FingerprintService</code> make a request via Binder to the
+Gatekeeperd or fingerprintd daemon in the Android OS. Note that fingerprint
+authentication occurs asynchronously after the fingerprint request is sent.
+ <li>This step involves <strong>either</strong> Gatekeeperd (option 1 below)
+ <strong>or</strong> fingerprintd (option 2 below),
+ depending on whether a pin/pattern/password, or fingerprint, is provided.
+ <ul>
+ <li>The Gatekeeperd daemon sends a pin, pattern, or password hash (received in step
+1) to its counterpart (Gatekeeper) in the TEE. If authentication in the TEE is
+successful, Gatekeeper in the TEE sends an AuthToken containing the
+corresponding User SID, signed with the AuthToken HMAC key, to its
+counterpart in the Android OS.
+ <li>Alternatively, the fingerprintd daemon, which listens for fingerprint events,
+sends the data (received in step 1) to its counterpart (Fingerprint) in the
+TEE. If authentication in the TEE is successful, Fingerprint in the TEE sends
+an AuthToken, signed with the AuthToken HMAC key, to its counterpart in the Android OS.
+ </ul>
+ <li>The Gatekeeperd or fingerprintd daemon receives a signed AuthToken and passes
+the AuthToken to the keystore service via an extension to
+the keystore service's Binder interface. Additionally, Gatekeeperd notifies the keystore service when
+the device is re-locked and when the device password changes.
+ <li>The keystore service passes to Keymaster the AuthTokens received from Gatekeeperd and
+fingerprintd, verifying the AuthTokens with the key shared with the Gatekeeper
+and Fingerprint trustlets. Keymaster trusts the timestamp in the token as the
+last authentication time and bases a key release decision (to allow an app to
+use the key) on the timestamp.
+</ol>
+
+<p class="note"><strong>Note:</strong> AuthTokens are invalidated whenever a device reboots.</p>
+
+<h2 id=authentication_token_format>Authentication token format</h2>
+
+<p>The AuthToken format described in the
+<a href="https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/hw_auth_token.h"><code>hw_auth_token.h</code></a> file is
+necessary for token sharing and compatibility across languages and
+components. See the following file:</p>
+<pre>
+hardware/libhardware/include/hardware/hw_auth_token.h
+</pre>
+
+<p>A simple serialization protocol with the required fields is defined in the
+table below. The fields are fixed size.</p>
+
+<p>Field descriptions are below the table.</p>
+<table>
+ <tr>
+ <th><strong>Field</strong></th>
+ <th><strong>Type</strong></th>
+ <th><strong>Required or Optional</strong></th>
+ </tr>
+ <tr>
+ <td>AuthToken Version</td>
+ <td>1 byte</td>
+ <td>Required</td>
+ </tr>
+ <tr>
+ <td>Challenge</td>
+ <td>64-bit unsigned integer</td>
+ <td>Optional</td>
+ </tr>
+ <tr>
+ <td>User SID</td>
+ <td>64-bit unsigned integer</td>
+ <td>Required</td>
+ </tr>
+ <tr>
+ <td>Authenticator ID</td>
+ <td>64-bit unsigned integer in network order</td>
+ <td>Optional</td>
+ </tr>
+ <tr>
+ <td>Authenticator type</td>
+ <td>32-bit unsigned integer in network order</td>
+ <td>Required</td>
+ </tr>
+ <tr>
+ <td>Timestamp</td>
+ <td>64-bit unsigned integer in network order</td>
+ <td>Required</td>
+ </tr>
+ <tr>
+ <td>AuthToken HMAC key (SHA-256)</td>
+ <td>256-bit blob</td>
+ <td>Required</td>
+ </tr>
+</table>
+
+<h3 id=field_descriptions>Field descriptions </h3>
+
+<p>This section describes the fields of the AuthToken table above.</p>
+
+<p><strong>AuthToken Version:</strong> Group tag for all fields below.</p>
+
+<p><strong>Challenge:</strong> A random integer to prevent replay attacks. Usually the ID of a requested
+crypto operation. Currently used by transactional fingerprint authorizations.
+If present, the AuthToken is valid only for crypto operations containing the
+same challenge.</p>
+
+<p><strong>User SID</strong>: Non-repeating user identifier tied cryptographically to all keys associated
+with device authentication. For more information, see the Gatekeeper page.</p>
+
+<p><strong>Authenticator ID (ASID)</strong>: Identifier used to bind to a specific authenticator policy. All
+authenticators have their own value of ASID that they can change according to
+their own requirements.</p>
+
+<p><strong>Authenticator Type</strong>: Either Gatekeeper or Fingerprint, as follows:</p>
+<table>
+ <tr>
+ <th><strong>Authenticator Type</strong></th>
+ <th><strong>Authenticator Name</strong></th>
+ </tr>
+ <tr>
+ <td>0x00</td>
+ <td>Gatekeeper</td>
+ </tr>
+ <tr>
+ <td>0x01</td>
+ <td>Fingerprint</td>
+ </tr>
+</table>
+
+<p><strong>Timestamp</strong>: Time (in milliseconds) since the most recent system boot.</p>
+
+<p><strong>AuthToken HMAC key</strong>: Keyed SHA-256 MAC of all fields except the HMAC field.</p>
+
+<h2 id=device_boot_flow>Device boot flow</h2>
+
+<p>On every boot of a device, the AuthToken HMAC key must be generated and shared
+with all TEE components (Gatekeeper, Fingerprint, and Keymaster). Thus, the HMAC key
+must be randomly generated every time the device reboots, for added protection against replay attacks.</p>
+
+<p>The protocol for sharing this HMAC key with all components is a
+platform-dependent implementation feature. The key must <strong>never</strong>
+be made available outside the TEE. Thus, if a TEE OS lacks an
+internal inter-process communication (IPC) mechanism,
+and the TEE needs to transfer the data through the untrusted OS, the transfer
+must be done via a secure key exchange protocol.</p>
+
+<p>The Trusty operating system, which runs next to Android, is an example of a
+TEE, but other TEEs can be used instead. Trusty uses an internal IPC system to
+communicate directly between Keymaster and Fingerprint or Gatekeeper. The HMAC
+key is kept solely in Keymaster. Fingerprint and Gatekeeper request the key
+from Keymaster for each use, and do not persist or cache the value.</p>
+
+<p>Note that no communication happens between applets in the TEE because some TEEs
+are lacking in IPC infrastructure. This also
+permits the keystore service to quickly deny requests that are bound to fail as it has
+knowledge of the authentication table in the system, saving a potentially
+costly IPC into the TEE.</p>
diff --git a/src/devices/tech/security/images/authentication-flow.png b/src/devices/tech/security/images/authentication-flow.png
new file mode 100644
index 0000000..1c136e4
--- /dev/null
+++ b/src/devices/tech/security/images/authentication-flow.png
Binary files differ
