Merge "Add Michael Peck to Security Acknowledgements page."
diff --git a/src/accessories/accessories_toc.cs b/src/accessories/accessories_toc.cs
index 616cc5e..f4954a0 100644
--- a/src/accessories/accessories_toc.cs
+++ b/src/accessories/accessories_toc.cs
@@ -52,7 +52,7 @@
</div>
<ul>
<li class="nav-section">
- <div class="nav-section-header"><a href="<?cs var:toroot ?>accessories/protocol.html"><span class="en">Open Accessory Protocol</span>
+ <div class="nav-section-header"><a href="<?cs var:toroot ?>accessories/protocol.html"><span class="en">AOA</span>
</a>
</div>
<ul>
@@ -60,8 +60,11 @@
<li><a href="<?cs var:toroot ?>accessories/aoa.html">AOA 1.0</a></li>
</ul>
</li>
+ <div class="nav-section-header"><a href="<?cs var:toroot ?>accessories/stylus.html"><span class="en">Stylus</span>
+ </a>
+ </div>
</ul>
</li>
</li>
<!-- End Accessories -->
-</ul>
+</ul>
\ No newline at end of file
diff --git a/src/accessories/stylus.jd b/src/accessories/stylus.jd
new file mode 100644
index 0000000..03c2e14
--- /dev/null
+++ b/src/accessories/stylus.jd
@@ -0,0 +1,121 @@
+page.title=Stylus
+@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 6.0 and higher supports a standard data format for Bluetooth stylus
+connections over Bluetooth (BT), Bluetooth Low Energy (BTLE), or USB. The
+platform correlates timing between touch input and stylus data then provides
+stylus data to render MotionEvents to the active application. The following
+sections provide guidelines for OEM partners, stylus accessory creators, and
+stylus application developers.</p>
+
+<h2 id="guide-partners">Guidelines for OEM partners</h2>
+<p>To enable Bluetooth stylus support, OEM partners must support Bluetooth
+(and should support BTLE for wider compatibility). The platform handles data
+collection, timing correlation, and rendering to the application for supported
+stylus events.</p>
+
+<p>At this time, the Android CTS <strong>does not</strong> include tests to
+ensure existing APIs for touch events support default behavior. As a
+workaround, we recommend creating a stylus accessory or emulator that can
+simulate stylus events.</p>
+
+<h2 id="guide-creators">Guidelines for stylus accessory creators</h2>
+<p>To implement support on a stylus device, partners must use the Stylus
+Human Interface Device (HID) Descriptor shown below to describe how stylus data
+(pressure sensitivity, eraser, side buttons, device ID, etc.) is represented.
+The stylus device sends the HID information to the Android mobile device,
+enabling the platform to correlate HID data with touch data from the touchscreen
+to produce stylus events via MotionEvent. Data can be sent over Bluetooth (BT),
+Bluetooth Low Energy (BTLE), or USB.</p>
+
+<h3 id="hid-descriptor">HID descriptor</h3>
+
+<p><pre>
+UsagePage(Digitizer)
+Usage(Pen)
+Collection(Application)
+ Usage(Stylus)
+ Collection(Logical)
+ Usage(Tip Pressure)
+ Logical Minimum(0)
+ Logical Maximum(1023)
+ Report Count(1)
+ Report Size(10)
+ Input(Data, Variable, Absolute, No Null)
+
+ Usage(Barrel Switch)
+ Usage(Secondary Barrel Switch)
+ Usage(Tip Switch)
+ Usage(Invert)
+ Logical Maximum(1)
+ Report Count(4)
+ Report Size(1)
+ Input(Data, Variable, Absolute, No Null)
+
+ Usage(Transducer Serial Number)
+ Report Count(1)
+ Report Size(128)
+ Feature(Constant, Variable)
+ EndCollection
+EndCollection
+
+unsigned char HID_DESC[] = {
+ 0x05, 0x0D, // UsagePage(Digitizer)
+ 0x09, 0x02, // Usage(Pen)
+ 0xA1, 0x01, // Collection(Application)
+ 0x09, 0x20, // Usage(Stylus)
+ 0xA1, 0x02, // Collection(Logical)
+ 0x09, 0x30, // Usage(Tip Pressure)
+ 0x15, 0x00, // Logical Minimum(0)
+ 0x26, 0xFF, 0x03, // Logical Maximum(1023)
+ 0x95, 0x01, // Report Count(1)
+ 0x75, 0x0A, // Report Size(10)
+ 0x81, 0x02, // Input(Data, Variable, Absolute, No Null)
+
+ 0x09, 0x44, // Usage(Barrel Switch)
+ 0x09, 0x5A, // Usage(Secondary Barrel Switch)
+ 0x09, 0x42, // Usage(Tip Switch)
+ 0x09, 0x3C, // Usage(Invert)
+ 0x25, 0x01, // Logical Maximum(1)
+ 0x95, 0x04, // Report Count(4)
+ 0x75, 0x01, // Report Size(1)
+ 0x81, 0x02, // Input(Data, Variable, Absolute, No Null)
+
+ 0x09, 0x5B, // Usage(Transducer Serial Number)
+ 0x95, 0x01, // Report Count(1)
+ 0x75, 0x80, // Report Size(128)
+ 0xB1, 0x03, // Feature(Constant, Variable)
+ 0xC0, // End Collection
+ 0xC0, // End Collection
+}
+</pre></p>
+
+<h2 id="guidelines-devs">Guidelines for stylus application developers</h2>
+<p>The Android 6.0 platform automatically handles pairing and event correlation,
+so both existing and new applications running on Android 6.0 support Bluetooth
+stylus by default. For details on Bluetooth stylus APIs, refer to
+<a href="http://developer.android.com/about/versions/marshmallow/android-6.0.html#bluetooth-stylus">developer.android.com</a>.
\ No newline at end of file
diff --git a/src/compatibility/6.0/android-6.0-cdd.html b/src/compatibility/6.0/android-6.0-cdd.html
new file mode 100644
index 0000000..2b9f32e
--- /dev/null
+++ b/src/compatibility/6.0/android-6.0-cdd.html
@@ -0,0 +1,5677 @@
+<!DOCTYPE html>
+<head>
+<title>Android 6.0 Compatibility Definition</title>
+<link rel="stylesheet" type="text/css" href="source/android-cdd.css"/>
+</head>
+
+<body>
+
+<h6>Table of Contents</h6>
+
+<div id="toc">
+
+<div id="toc_left">
+
+<p class="toc_h1"><a href="#1_introduction">1. Introduction</a></p>
+
+<p class="toc_h1"><a href="#2_device_types">2. Device Types</a></p>
+
+<p class="toc_h2"><a href="#2_1_device_configurations">2.1 Device Configurations</a></p>
+
+<p class="toc_h1"><a href="#3_software">3. Software</a></p>
+
+<p class="toc_h2"><a href="#3_1_managed_api_compatibility">3.1. Managed API Compatibility</a></p>
+
+<p class="toc_h2"><a href="#3_2_soft_api_compatibility">3.2. Soft API Compatibility</a></p>
+
+<p class="toc_h3"><a href="#3_2_1_permissions">3.2.1. Permissions</a></p>
+
+<p class="toc_h3"><a href="#3_2_2_build_parameters">3.2.2. Build Parameters</a></p>
+
+<p class="toc_h3"><a href="#3_2_3_intent_compatibility">3.2.3. Intent Compatibility</a></p>
+
+<p class="toc_h4"><a href="#3_2_3_1_core_application_intents">3.2.3.1. Core Application Intents</a></p>
+
+<p class="toc_h4"><a href="#3_2_3_2_intent_resolution">3.2.3.2. Intent Resolution</a></p>
+
+<p class="toc_h4"><a href="#3_2_3_3_intent_namespaces">3.2.3.3. Intent Namespaces</a></p>
+
+<p class="toc_h4"><a href="#3_2_3_4_broadcast_intents">3.2.3.4. Broadcast Intents</a></p>
+
+<p class="toc_h4"><a href="#3_2_3_5_default_app_settings">3.2.3.5. Default App Settings</a></p>
+
+<p class="toc_h2"><a href="#3_3_native_api_compatibility">3.3. Native API Compatibility</a></p>
+
+<p class="toc_h3"><a href="#3_3_1_application_binary_interfaces">3.3.1. Application Binary Interfaces</a></p>
+
+<p class="toc_h3"><a href="#3_3_2_32-bit_arm_native_code_compatibility">3.3.2. 32-bit ARM Native Code Compatibility</a></p>
+
+<p class="toc_h2"><a href="#3_4_web_compatibility">3.4. Web Compatibility</a></p>
+
+<p class="toc_h3"><a href="#3_4_1_webview_compatibility">3.4.1. WebView Compatibility</a></p>
+
+<p class="toc_h3"><a href="#3_4_2_browser_compatibility">3.4.2. Browser Compatibility</a></p>
+
+<p class="toc_h2"><a href="#3_5_api_behavioral_compatibility">3.5. API Behavioral Compatibility</a></p>
+
+<p class="toc_h2"><a href="#3_6_api_namespaces">3.6. API Namespaces</a></p>
+
+<p class="toc_h2"><a href="#3_7_runtime_compatibility">3.7. Runtime Compatibility</a></p>
+
+<p class="toc_h2"><a href="#3_8_user_interface_compatibility">3.8. User Interface Compatibility</a></p>
+
+<p class="toc_h3"><a href="#3_8_1_launcher_home_screen">3.8.1. Launcher (Home Screen)</a></p>
+
+<p class="toc_h3"><a href="#3_8_2_widgets">3.8.2. Widgets</a></p>
+
+<p class="toc_h3"><a href="#3_8_3_notifications">3.8.3. Notifications</a></p>
+
+<p class="toc_h3"><a href="#3_8_4_search">3.8.4. Search</a></p>
+
+<p class="toc_h3"><a href="#3_8_5_toasts">3.8.5. Toasts</a></p>
+
+<p class="toc_h3"><a href="#3_8_6_themes">3.8.6. Themes</a></p>
+
+<p class="toc_h3"><a href="#3_8_7_live_wallpapers">3.8.7. Live Wallpapers</a></p>
+
+<p class="toc_h3"><a href="#3_8_8_activity_switching">3.8.8. Activity Switching</a></p>
+
+<p class="toc_h3"><a href="#3_8_9_input_management">3.8.9. Input Management</a></p>
+
+<p class="toc_h3"><a href="#3_8_10_lock_screen_media_control">3.8.10. Lock Screen Media Control</a></p>
+
+<p class="toc_h3"><a href="#3_8_11_dreams">3.8.11. Dreams</a></p>
+
+<p class="toc_h3"><a href="#3_8_12_location">3.8.12. Location</a></p>
+
+</div>
+
+<div id="toc_right">
+
+
+<p class="toc_h3"><a href="#3_8_13_unicode_and_font">3.8.13. Unicode and Font</a></p>
+
+<p class="toc_h2"><a href="#3_9_device_administration">3.9. Device Administration</a></p>
+
+<p class="toc_h3"><a href="#3_9_1_device_provisioning">3.9.1 Device Provisioning</a></p>
+
+<p class="toc_h4"><a href="#3_9_1_2_device_owner_provisioning">3.9.1.1 Device Owner provisioning</a></p>
+
+<p class="toc_h4"><a href="#3_9_1_2_managed_profile_provisioning">3.9.1.2 Managed profile provisioning</a></p>
+
+<p class="toc_h3"><a href="#3_9_2_managed_profile_support">3.9.2. Managed Profile Support</a></p>
+
+
+<p class="toc_h2"><a href="#3_10_accessibility">3.10. Accessibility</a></p>
+
+<p class="toc_h2"><a href="#3_11_text-to-speech">3.11. Text-to-Speech</a></p>
+
+<p class="toc_h2"><a href="#3_12_tv_input_framework">3.12. TV Input Framework</a></p>
+
+<p class="toc_h3"><a href="#3_12_1_tv_app">3.12.1. TV App</a></p>
+
+<p class="toc_h4"><a href="#3_12_1_1_electronic_program_guide">3.12.1.1. Electronic Program Guide</a></p>
+
+<p class="toc_h4"><a href="#3_12_1_2_navigation">3.12.1.2. Navigation</a></p>
+
+<p class="toc_h4"><a href="#3_12_1_3_tv_input_app_linking">3.12.1.3. TV input app linking</a></p>
+
+<p class="toc_h1"><a href="#4_application_packaging_compatibility">4. Application Packaging Compatibility</a></p>
+
+<p class="toc_h1"><a href="#5_multimedia_compatibility">5. Multimedia Compatibility</a></p>
+
+<p class="toc_h2"><a href="#5_1_media_codecs">5.1. Media Codecs</a></p>
+
+<p class="toc_h3"><a href="#5_1_1_audio_codecs">5.1.1. Audio Codecs</a></p>
+
+<p class="toc_h3"><a href="#5_1_2_image_codecs">5.1.2. Image Codecs</a></p>
+
+<p class="toc_h3"><a href="#5_1_3_video_codecs">5.1.3. Video Codecs</a></p>
+
+<p class="toc_h2"><a href="#5_2_video_encoding">5.2. Video Encoding</a></p>
+
+<p class="toc_h2"><a href="#5_3_video_decoding">5.3. Video Decoding</a></p>
+
+<p class="toc_h2"><a href="#5_4_audio_recording">5.4. Audio Recording</a></p>
+
+<p class="toc_h3"><a href="#5_4_1_raw_audio_capture">5.4.1. Raw Audio Capture</a></p>
+
+<p class="toc_h3"><a href="#5_4_2_capture_for_voice_recognition">5.4.2. Capture for Voice Recognition</a></p>
+
+<p class="toc_h3"><a href="#5_4_3_capture_for_rerouting_of_playback">5.4.3. Capture for Rerouting of Playback</a></p>
+
+<p class="toc_h2"><a href="#5_5_audio_playback">5.5. Audio Playback</a></p>
+
+<p class="toc_h3"><a href="#5_5_1_raw_audio_playback">5.5.1. Raw Audio Playback</a></p>
+
+<p class="toc_h3"><a href="#5_5_2_audio_effects">5.5.2. Audio Effects</a></p>
+
+<p class="toc_h3"><a href="#5_5_3_audio_output_volume">5.5.3. Audio Output Volume</a></p>
+
+<p class="toc_h2"><a href="#5_6_audio_latency">5.6. Audio Latency</a></p>
+
+<p class="toc_h2"><a href="#5_7_network_protocols">5.7. Network Protocols</a></p>
+
+<p class="toc_h2"><a href="#5_8_secure_media">5.8. Secure Media</a></p>
+
+<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>
+
+</div>
+
+<div style="clear: both; page-break-after:always; height:1px"></div>
+
+<div id="toc_left">
+
+<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>
+
+<p class="toc_h2"><a href="#6_2_developer_options">6.2. Developer Options</a></p>
+
+<p class="toc_h1"><a href="#7_hardware_compatibility">7. Hardware Compatibility</a></p>
+
+<p class="toc_h2"><a href="#7_1_display_and_graphics">7.1. Display and Graphics</a></p>
+
+<p class="toc_h3"><a href="#7_1_1_screen_configuration">7.1.1. Screen Configuration</a></p>
+
+<p class="toc_h4"><a href="#7_1_1_1_screen_size">7.1.1.1. Screen Size</a></p>
+
+<p class="toc_h4"><a href="#7_1_1_2_screen_aspect_ratio">7.1.1.2. Screen Aspect Ratio</a></p>
+
+<p class="toc_h4"><a href="#7_1_1_3_screen_density">7.1.1.3. Screen Density</a></p>
+
+<p class="toc_h3"><a href="#7_1_2_display_metrics">7.1.2. Display Metrics</a></p>
+
+<p class="toc_h3"><a href="#7_1_3_screen_orientation">7.1.3. Screen Orientation</a></p>
+
+<p class="toc_h3"><a href="#7_1_4_2d_and_3d_graphics_acceleration">7.1.4. 2D and 3D Graphics Acceleration</a></p>
+
+<p class="toc_h3"><a href="#7_1_5_legacy_application_compatibility_mode">7.1.5. Legacy Application Compatibility Mode</a></p>
+
+<p class="toc_h3"><a href="#7_1_6_screen_technology">7.1.6. Screen Technology</a></p>
+
+<p class="toc_h3"><a href="#7_1_7_external_displays">7.1.7. Secondary Displays</a></p>
+
+<p class="toc_h2"><a href="#7_2_input_devices">7.2. Input Devices</a></p>
+
+<p class="toc_h3"><a href="#7_2_1_keyboard">7.2.1. Keyboard</a></p>
+
+<p class="toc_h3"><a href="#7_2_2_non-touch_navigation">7.2.2. Non-touch Navigation</a></p>
+
+<p class="toc_h3"><a href="#7_2_3_navigation_keys">7.2.3. Navigation Keys</a></p>
+
+<p class="toc_h3"><a href="#7_2_4_touchscreen_input">7.2.4. Touchscreen Input</a></p>
+
+<p class="toc_h3"><a href="#7_2_5_fake_touch_input">7.2.5. Fake Touch Input</a></p>
+
+<p class="toc_h3"><a href="#7_2_6_game_controller_support">7.2.6. Game Controller Support</a></p>
+
+<p class="toc_h4"><a href="#7_2_6_1_button_mapping">7.2.6.1. Button Mappings</a></p>
+
+<p class="toc_h3"><a href="#7_2_7_remote_control">7.2.7. Remote Control</a></p>
+
+<p class="toc_h2"><a href="#7_3_sensors">7.3. Sensors</a></p>
+
+<p class="toc_h3"><a href="#7_3_1_accelerometer">7.3.1. Accelerometer</a></p>
+
+<p class="toc_h3"><a href="#7_3_2_magnetometer">7.3.2. Magnetometer</a></p>
+
+<p class="toc_h3"><a href="#7_3_3_gps">7.3.3. GPS</a></p>
+
+</div>
+
+<div id="toc_right">
+
+<p class="toc_h3"><a href="#7_3_4_gyroscope">7.3.4. Gyroscope</a></p>
+
+<p class="toc_h3"><a href="#7_3_5_barometer">7.3.5. Barometer</a></p>
+
+<p class="toc_h3"><a href="#7_3_6_thermometer">7.3.6. Thermometer</a></p>
+
+<p class="toc_h3"><a href="#7_3_7_photometer">7.3.7. Photometer</a></p>
+
+<p class="toc_h3"><a href="#7_3_8_proximity_sensor">7.3.8. Proximity Sensor</a></p>
+
+<p class="toc_h3"><a href="#7_3_9_hifi_sensors">7.3.9. High Fidelity Sensors</a></p>
+
+<p class="toc_h3"><a href="#7_3_10_fingerprint">7.3.10. Fingerprint Sensor</a></p>
+
+<p class="toc_h2"><a href="#7_4_data_connectivity">7.4. Data Connectivity</a></p>
+
+<p class="toc_h3"><a href="#7_4_1_telephony">7.4.1. Telephony</a></p>
+
+<p class="toc_h3"><a href="#7_4_2_ieee_80211_wi-fi">7.4.2. IEEE 802.11 (Wi-Fi)</a></p>
+
+<p class="toc_h4"><a href="#7_4_2_1_wi-fi_direct">7.4.2.1. Wi-Fi Direct</a></p>
+
+<p class="toc_h4"><a href="#7_4_2_2_wi-fi-tunneled-direct-link-setup">7.4.2.2. Wi-Fi Tunneled Direct Link Setup</a></p>
+
+<p class="toc_h3"><a href="#7_4_3_bluetooth">7.4.3. Bluetooth</a></p>
+
+<p class="toc_h3"><a href="#7_4_4_near-field_communications">7.4.4. Near-Field Communications</a></p>
+
+<p class="toc_h3"><a href="#7_4_5_minimum_network_capability">7.4.5. Minimum Network Capability</a></p>
+
+<p class="toc_h3"><a href="#7_4_6_sync_settings">7.4.6. Sync Settings</a></p>
+
+<p class="toc_h2"><a href="#7_5_cameras">7.5. Cameras</a></p>
+
+<p class="toc_h3"><a href="#7_5_1_rear-facing_camera">7.5.1. Rear-Facing Camera</a></p>
+
+<p class="toc_h3"><a href="#7_5_2_front-facing_camera">7.5.2. Front-Facing Camera</a></p>
+
+<p class="toc_h3"><a href="#7_5_3_external_camera">7.5.3. External Camera</a></p>
+
+<p class="toc_h3"><a href="#7_5_4_camera_api_behavior">7.5.4. Camera API Behavior</a></p>
+
+<p class="toc_h3"><a href="#7_5_5_camera_orientation">7.5.5. Camera Orientation</a></p>
+
+<p class="toc_h2"><a href="#7_6_memory_and_storage">7.6. Memory and Storage</a></p>
+
+<p class="toc_h3"><a href="#7_6_1_minimum_memory_and_storage">7.6.1. Minimum Memory and Storage</a></p>
+
+<p class="toc_h3"><a href="#7_6_2_application_shared_storage">7.6.2. Application Shared Storage</a></p>
+
+<p class="toc_h3"><a href="#7_6_3_adoptable_storage">7.6.3. Adoptable Storage</a></p>
+
+<p class="toc_h2"><a href="#7_7_usb">7.7. USB</a></p>
+
+<p class="toc_h2"><a href="#7_8_audio">7.8. Audio</a></p>
+
+<p class="toc_h3"><a href="#7_8_1_microphone">7.8.1. Microphone</a></p>
+
+<p class="toc_h3"><a href="#7_8_2_audio_output">7.8.2. Audio Output</a></p>
+
+<p class="toc_h4"><a href="#7_8_2_1_analog_audio_ports">7.8.2.1. Analog Audio Ports</a></p>
+
+<p class="toc_h3"><a href="#7_8_3_near_ultrasound">7.8.3. Near-Ultrasound</a></p>
+
+<p class="toc_h1"><a href="#8_performance_power">8. Performance and Power</a></p>
+
+<p class="toc_h2"><a href="#8_1_user_experience_consistency">8.1. User Experience Consistency</a></p>
+
+<p class="toc_h2"><a href="#8_2_file_i_o_access_performance">8.2. File I/O Access Performance</a></p>
+
+<p class="toc_h2"><a href="#8_3_power_saving_modes">8.3. Power-Saving Modes</a></p>
+
+<p class="toc_h2"><a href="#8_4_power_consumption_accounting">8.4. Power Consumption Accounting</a></p>
+
+</div>
+
+<div style="clear: both; page-break-after:always; height:1px"></div>
+
+<div id="toc_left">
+
+<p class="toc_h1"><a href="#9_security_model_compatibility">9. Security Model Compatibility</a></p>
+
+<p class="toc_h2"><a href="#9_1_permissions">9.1. Permissions</a></p>
+
+<p class="toc_h2"><a href="#9_2_uid_and_process_isolation">9.2. UID and Process Isolation</a></p>
+
+<p class="toc_h2"><a href="#9_3_filesystem_permissions">9.3. Filesystem Permissions</a></p>
+
+<p class="toc_h2"><a href="#9_4_alternate_execution_environments">9.4. Alternate Execution Environments</a></p>
+
+<p class="toc_h2"><a href="#9_5_multi-user_support">9.5. Multi-User Support</a></p>
+
+<p class="toc_h2"><a href="#9_6_premium_sms_warning">9.6. Premium SMS Warning</a></p>
+
+<p class="toc_h2"><a href="#9_7_kernel_security_features">9.7. Kernel Security Features</a></p>
+
+<p class="toc_h2"><a href="#9_8_privacy">9.8. Privacy</a></p>
+
+<p class="toc_h2"><a href="#9_9_full-disk-encryption">9.9. Full-Disk Encryption</a></p>
+
+<p class="toc_h2"><a href="#9_10_verified_boot">9.10. Verified Boot</a></p>
+
+<p class="toc_h2"><a href="#9_11_keys_and_credentials">9.11. Keys and Credentials</a></p>
+
+<p class="toc_h2"><a href="#9_12_data_deletion">9.12. Data Deletion</a></p>
+
+<p class="toc_h1"><a href="#10_software_compatibility_testing">10. Software Compatibility Testing</a></p>
+
+<p class="toc_h2"><a href="#10_1_compatibility_test_suite">10.1. Compatibility Test Suite</a></p>
+
+<p class="toc_h2"><a href="#10_2_cts_verifier">10.2. CTS Verifier</a></p>
+
+<p class="toc_h1"><a href="#11_updatable_software">11. Updatable Software</a></p>
+
+<p class="toc_h1"><a href="#12_document_changelog">12. Document Changelog</a></p>
+
+<p class="toc_h1"><a href="#13_contact_us">13. Contact Us</a></p>
+
+<p class="toc_h1"><a href="#14_resources">14. Resources</a></p>
+
+</div>
+
+</div>
+
+<div style="clear: both"></div>
+
+<div id="main">
+
+<h1 id="1_introduction">1. Introduction</h1>
+
+
+<p>This document enumerates the requirements that must be met in order for devices
+to be compatible with Android 6.0.</p>
+
+<p>The use of “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” is per the IETF standard
+defined in RFC2119 [<a href="http://www.ietf.org/rfc/rfc2119.txt">Resources, 1</a>].</p>
+
+<p>As used in this document, a “device implementer” or “implementer” is a person
+or organization developing a hardware/software solution running Android 6.0. A
+“device implementation” or “implementation is the hardware/software solution
+so developed.</p>
+
+<p>To be considered compatible with Android 6.0, device implementations MUST meet
+the requirements presented in this Compatibility Definition, including any
+documents incorporated via reference.</p>
+
+<p>Where this definition or the software tests described in <a href="#10_software_compatibility_testing">section 10</a> is silent, ambiguous, or incomplete, it is the responsibility of the device
+implementer to ensure compatibility with existing implementations.</p>
+
+<p>For this reason, the Android Open Source Project [<a href="http://source.android.com/">Resources, 2</a>] is both the reference and preferred implementation of Android. Device
+implementers are STRONGLY RECOMMENDED to base their implementations to the
+greatest extent possible on the “upstream” source code available from the
+Android Open Source Project. While some components can hypothetically be
+replaced with alternate implementations, it is STRONGLY RECOMMENDED to not follow this practice,
+as passing the software tests will become substantially more difficult. It is
+the implementer’s responsibility to ensure full behavioral compatibility with
+the standard Android implementation, including and beyond the Compatibility
+Test Suite. Finally, note that certain component substitutions and
+modifications are explicitly forbidden by this document.</p>
+
+<p>Many of the resources listed in <a href="#14_resources">section 14</a> are derived directly or indirectly from the Android SDK, and will be
+functionally identical to the information in that SDK’s documentation. For any
+case where this Compatibility Definition or the Compatibility Test Suite
+disagrees with the SDK documentation, the SDK documentation is considered
+authoritative. Any technical details provided in the references included in <a href="#14_resources">section 14</a> are considered by inclusion to be part of this Compatibility Definition. </p>
+
+<h1 id="2_device_types">2. Device Types</h1>
+
+
+<p>While the Android Open Source Project has been used in the implementation of a
+variety of device types and form factors, many aspects of the architecture and
+compatibility requirements were optimized for handheld devices. Starting from
+Android 5.0, the Android Open Source Project aims to embrace a wider variety of
+device types as described in this section.</p>
+
+<p><strong>Android Handheld device</strong> refers to an Android device implementation that is typically used by holding
+it in the hand, such as mp3 players, phones, and tablets. Android Handheld
+device implementations:</p>
+
+<ul>
+ <li>MUST have a touchscreen embedded in the device.</li>
+ <li>MUST have a power source that provides mobility, such as a battery.</li>
+</ul>
+
+<p><strong>Android Television device</strong> refers to an Android device implementation that is an entertainment interface
+for consuming digital media, movies, games, apps, and/or live TV for users
+sitting about ten feet away (a “lean back” or “10-foot user interface”).
+Android Television devices:</p>
+
+<ul>
+ <li>MUST have an embedded screen OR include a video output port, such as VGA, HDMI,
+or a wireless port for display.</li>
+ <li>MUST declare the features android.software.leanback and
+android.hardware.type.television [<a href="http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK">Resources, 3</a>].</li>
+</ul>
+
+<p><strong>Android Watch device</strong> refers to an Android device implementation intended to be worn on the body,
+perhaps on the wrist, and:</p>
+
+<ul>
+ <li>MUST have a screen with the physical diagonal length in the range from 1.1 to
+2.5 inches.</li>
+ <li>MUST declare the feature android.hardware.type.watch.</li>
+ <li>MUST support uiMode = UI_MODE_TYPE_WATCH [<a href="http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_WATCH">Resources, 4</a>].</li>
+</ul>
+
+<p><strong>Android Automotive implementation</strong> refers to a vehicle head
+unit running Android as an operating system for part or all of the system and/or
+infotainment functionality. Android Automotive implementations:</p>
+
+<ul>
+ <li>MUST declare the feature android.hardware.type.automotive.</li>
+ <li>MUST support
+uiMode = UI_MODE_TYPE_CAR [<a
+href="http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR">Resources,
+ 5</a>].</li>
+</ul>
+
+<p>All Android device implementations that do not fit into any of the above device
+types still MUST meet all requirements in this document to be Android 6.0
+compatible, unless the requirement is explicitly described to be only
+applicable to a specific Android device type from above.</p>
+
+<h2 id="2_1_device_configurations">2.1 Device Configurations</h2>
+
+
+<p>This is a summary of major differences in hardware configuration by device
+type. (Empty cells denote a “MAY”). Not all configurations are covered in this
+table; see relevant hardware sections for more detail.</p>
+<table>
+ <tr>
+ <th>Category</th>
+ <th>Feature</th>
+ <th>Section</th>
+ <th>Handheld</th>
+ <th>Television</th>
+ <th>Watch</th>
+ <th>Automotive</th>
+ <th>Other</th>
+ </tr>
+ <tr>
+ <td rowspan="3">Input</td>
+ <td>D-pad</td>
+ <td><a href="#7_2_2_non-touch-navigation">7.2.2. Non-touch Navigation</a></td>
+ <td></td>
+ <td>MUST</td>
+ <td></td>
+ <td></td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>Touchscreen </td>
+ <td><a href="#7_2_4_touchscreen_input">7.2.4. Touchscreen input</a></td>
+ <td>MUST</td>
+ <td></td>
+ <td>MUST</td>
+ <td></td>
+ <td>SHOULD</td>
+ </tr>
+ <tr>
+ <td>Microphone </td>
+ <td><a href="#7_8_1_microphone">7.8.1. Microphone</a></td>
+ <td>MUST</td>
+ <td>SHOULD </td>
+ <td>MUST</td>
+ <td>MUST</td>
+ <td>SHOULD</td>
+ </tr>
+ <tr>
+ <td rowspan="2">Sensors</td>
+ <td>Accelerometer </td>
+ <td><a href="#7_3_1_accelerometer">7.3.1 Accelerometer</a></td>
+ <td>SHOULD</td>
+ <td></td>
+ <td>SHOULD</td>
+ <td></td>
+ <td>SHOULD</td>
+ </tr>
+ <tr>
+ <td>GPS</td>
+ <td><a href="#7_3_3_gps">7.3.3. GPS</a></td>
+ <td>SHOULD</td>
+ <td></td>
+ <td></td>
+ <td>SHOULD</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td rowspan="5">Connectivity</td>
+ <td>Wi-Fi</td>
+ <td><a href="#7_4_2_ieee_802.11">7.4.2. IEEE 802.11</a></td>
+ <td>SHOULD</td>
+ <td> MUST</td>
+ <td></td>
+ <td>SHOULD</td>
+ <td>SHOULD</td>
+ </tr>
+ <tr>
+ <td>Wi-Fi Direct</td>
+ <td><a href="#7_4_2_1_wi-fi-direct">7.4.2.1. Wi-Fi Direct</a></td>
+ <td>SHOULD</td>
+ <td>SHOULD</td>
+ <td></td>
+ <td></td>
+ <td>SHOULD</td>
+ </tr>
+ <tr>
+ <td>Bluetooth</td>
+ <td><a href="#7_4_3_bluetooth">7.4.3. Bluetooth</a></td>
+ <td>SHOULD</td>
+ <td>MUST</td>
+ <td>MUST</td>
+ <td>MUST</td>
+ <td>SHOULD</td>
+ </tr>
+ <tr>
+ <td>Bluetooth Low Energy</td>
+ <td><a href="#7_4_3_bluetooth">7.4.3. Bluetooth</a></td>
+ <td>SHOULD</td>
+ <td>MUST</td>
+ <td>SHOULD</td>
+ <td>SHOULD</td>
+ <td>SHOULD</td>
+ </tr>
+ <tr>
+ <td>USB peripheral/host mode</td>
+ <td><a href="#7_7_usb">7.7. USB</a></td>
+ <td>SHOULD</td>
+ <td></td>
+ <td></td>
+ <td>SHOULD</td>
+ <td>SHOULD</td>
+ </tr>
+ <tr>
+ <td>Output</td>
+ <td>Speaker and/or Audio output ports</td>
+ <td><a href="#7_8_2_audio_output">7.8.2. Audio Output</a></td>
+ <td>MUST</td>
+ <td>MUST</td>
+ <td></td>
+ <td>MUST</td>
+ <td>MUST</td>
+ </tr>
+</table>
+
+
+<h1 id="3_software">3. Software</h1>
+
+
+<h2 id="3_1_managed_api_compatibility">3.1. Managed API Compatibility</h2>
+
+
+<p>The managed Dalvik bytecode execution environment is the primary vehicle for
+Android applications. The Android application programming interface (API) is
+the set of Android platform interfaces exposed to applications running in the
+managed runtime environment. Device implementations MUST provide complete
+implementations, including all documented behaviors, of any documented API
+exposed by the Android SDK [<a href="http://developer.android.com/reference/packages.html">Resources, 6</a>] or any API decorated with the “@SystemApi” marker in the upstream Android
+source code. </p>
+
+<p>Device implementations MUST NOT omit any managed APIs, alter API interfaces or
+signatures, deviate from the documented behavior, or include no-ops, except
+where specifically allowed by this Compatibility Definition.</p>
+
+<p>This Compatibility Definition permits some types of hardware for which Android
+includes APIs to be omitted by device implementations. In such cases, the APIs
+MUST still be present and behave in a reasonable way. See <a href="#7_hardware_compatibility">section 7</a> for specific requirements for this scenario.</p>
+
+<h2 id="3_2_soft_api_compatibility">3.2. Soft API Compatibility</h2>
+
+
+<p>In addition to the managed APIs from <a href="#3_1_managed_api_compatibility">section 3.1</a>, Android also includes a significant runtime-only “soft” API, in the form of
+such things as intents, permissions, and similar aspects of Android
+applications that cannot be enforced at application compile time.</p>
+
+<h3 id="3_2_1_permissions">3.2.1. Permissions</h3>
+
+
+<p>Device implementers MUST support and enforce all permission constants as
+documented by the Permission reference page [<a href="http://developer.android.com/reference/android/Manifest.permission.html">Resources, 7</a>]. Note that <a href="#9_security_model_compatibility">section 9</a> lists additional requirements related to the Android security model.</p>
+
+<h3 id="3_2_2_build_parameters">3.2.2. Build Parameters</h3>
+
+
+<p>The Android APIs include a number of constants on the android.os.Build class [<a href="http://developer.android.com/reference/android/os/Build.html">Resources, 8</a>] that are intended to describe the current device. To provide consistent,
+meaningful values across device implementations, the table below includes
+additional restrictions on the formats of these values to which device
+implementations MUST conform.</p>
+<table>
+ <tr>
+ <th>Parameter</th>
+ <th>Details</th>
+ </tr>
+ <tr>
+ <td>VERSION.RELEASE</td>
+ <td>The version of the currently-executing Android system, in human-readable
+format. This field MUST have one of the string values defined in [<a href="http://source.android.com/compatibility/6.0/versions.html">Resources, 9</a>].</td>
+ </tr>
+ <tr>
+ <td>VERSION.SDK</td>
+ <td>The version of the currently-executing Android system, in a format accessible
+to third-party application code. For Android 6.0, this field MUST have the
+integer value 23.</td>
+ </tr>
+ <tr>
+ <td>VERSION.SDK_INT</td>
+ <td>The version of the currently-executing Android system, in a format accessible
+to third-party application code. For Android 6.0, this field MUST have the
+integer value 23.</td>
+ </tr>
+ <tr>
+ <td>VERSION.INCREMENTAL</td>
+ <td>A value chosen by the device implementer designating the specific build of the
+currently-executing Android system, in human-readable format. This value MUST
+NOT be reused for different builds made available to end users. A typical use
+of this field is to indicate which build number or source-control change
+identifier was used to generate the build. There are no requirements on the
+specific format of this field, except that it MUST NOT be null or the empty
+string ("").</td>
+ </tr>
+ <tr>
+ <td>BOARD</td>
+ <td>A value chosen by the device implementer identifying the specific internal
+hardware used by the device, in human-readable format. A possible use of this
+field is to indicate the specific revision of the board powering the device.
+The value of this field MUST be encodable as 7-bit ASCII and match the regular
+expression “^[a-zA-Z0-9_-]+$”.</td>
+ </tr>
+ <tr>
+ <td>BRAND</td>
+ <td>A value reflecting the brand name associated with the device as known to the
+end users. MUST be in human-readable format and SHOULD represent the
+manufacturer of the device or the company brand under which the device is
+marketed. The value of this field MUST be encodable as 7-bit ASCII and match
+the regular expression “^[a-zA-Z0-9_-]+$”.</td>
+ </tr>
+ <tr>
+ <td>SUPPORTED_ABIS</td>
+ <td>The name of the instruction set (CPU type + ABI convention) of native code. See <a href="#3_3_native_api_compatibility">section 3.3. Native API Compatibility</a>.</td>
+ </tr>
+ <tr>
+ <td>SUPPORTED_32_BIT_ABIS</td>
+ <td>The name of the instruction set (CPU type + ABI convention) of native code. See <a href="#3_3_native_api_compatibility">section 3.3. Native API Compatibility</a>.</td>
+ </tr>
+ <tr>
+ <td>SUPPORTED_64_BIT_ABIS</td>
+ <td>The name of the second instruction set (CPU type + ABI convention) of native
+code. See <a href="#3_3_native_api_compatibility">section 3.3. Native API Compatibility</a>.</td>
+ </tr>
+ <tr>
+ <td>CPU_ABI</td>
+ <td>The name of the instruction set (CPU type + ABI convention) of native code. See <a href="#3_3_native_api_compatibility">section 3.3. Native API Compatibility</a>.</td>
+ </tr>
+ <tr>
+ <td>CPU_ABI2</td>
+ <td>The name of the second instruction set (CPU type + ABI convention) of native
+code. See <a href="#3_3_native_api_compatibility">section 3.3. Native API Compatibility</a>.</td>
+ </tr>
+ <tr>
+ <td>DEVICE</td>
+ <td>A value chosen by the device implementer containing the development name or
+code name identifying the configuration of the hardware features and industrial
+design of the device. The value of this field MUST be encodable as 7-bit ASCII
+and match the regular expression “^[a-zA-Z0-9_-]+$”.</td>
+ </tr>
+ <tr>
+ <td>FINGERPRINT</td>
+ <td>A string that uniquely identifies this build. It SHOULD be reasonably
+human-readable. It MUST follow this template:
+<p class="small">$(BRAND)/$(PRODUCT)/<br>
+ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)</p>
+<p>For example:</p>
+<p class="small">acme/myproduct/<br>
+ mydevice:6.0/LMYXX/3359:userdebug/test-keys</p>
+<p>The fingerprint MUST NOT include whitespace characters. If other fields
+included in the template above have whitespace characters, they MUST be
+replaced in the build fingerprint with another character, such as the
+underscore ("_") character. The value of this field MUST be encodable as 7-bit
+ASCII.</p></td>
+ </tr>
+ <tr>
+ <td>HARDWARE</td>
+ <td>The name of the hardware (from the kernel command line or /proc). It SHOULD be
+reasonably human-readable. The value of this field MUST be encodable as 7-bit
+ASCII and match the regular expression “^[a-zA-Z0-9_-]+$”. </td>
+ </tr>
+ <tr>
+ <td>HOST</td>
+ <td>A string that uniquely identifies the host the build was built on, in
+human-readable format. There are no requirements on the specific format of this
+field, except that it MUST NOT be null or the empty string ("").</td>
+ </tr>
+ <tr>
+ <td>ID</td>
+ <td>An identifier chosen by the device implementer to refer to a specific release,
+in human-readable format. This field can be the same as
+android.os.Build.VERSION.INCREMENTAL, but SHOULD be a value sufficiently
+meaningful for end users to distinguish between software builds. The value of
+this field MUST be encodable as 7-bit ASCII and match the regular expression “^[a-zA-Z0-9._-]+$”.</td>
+ </tr>
+ <tr>
+ <td>MANUFACTURER</td>
+ <td>The trade name of the Original Equipment Manufacturer (OEM) of the product.
+There are no requirements on the specific format of this field, except that it
+MUST NOT be null or the empty string ("").</td>
+ </tr>
+ <tr>
+ <td>MODEL</td>
+ <td>A value chosen by the device implementer containing the name of the device as
+known to the end user. This SHOULD be the same name under which the device is
+marketed and sold to end users. There are no requirements on the specific
+format of this field, except that it MUST NOT be null or the empty string ("").</td>
+ </tr>
+ <tr>
+ <td>PRODUCT</td>
+ <td>A value chosen by the device implementer containing the development name or
+code name of the specific product (SKU) that MUST be unique within the same
+brand. MUST be human-readable, but is not necessarily intended for view by end
+users. The value of this field MUST be encodable as 7-bit ASCII and match the
+regular expression “^[a-zA-Z0-9_-]+$”.</td>
+ </tr>
+ <tr>
+ <td>SERIAL</td>
+ <td>A hardware serial number, which MUST be available and unique across
+devices with the same MODEL and MANUFACTURER. The value of this field MUST
+be encodable as 7-bit ASCII and match the regular expression “^([a-zA-Z0-9]{6,20})$”.</td>
+ </tr>
+ <tr>
+ <td>TAGS</td>
+ <td>A comma-separated list of tags chosen by the device implementer that further
+distinguishes the build. This field MUST have one of the values corresponding
+to the three typical Android platform signing configurations: release-keys,
+dev-keys, test-keys. </td>
+ </tr>
+ <tr>
+ <td>TIME</td>
+ <td>A value representing the timestamp of when the build occurred.</td>
+ </tr>
+ <tr>
+ <td>TYPE</td>
+ <td>A value chosen by the device implementer specifying the runtime configuration
+of the build. This field MUST have one of the values corresponding to the three
+typical Android runtime configurations: user, userdebug, or eng.</td>
+ </tr>
+ <tr>
+ <td>USER</td>
+ <td>A name or user ID of the user (or automated user) that generated the build.
+There are no requirements on the specific format of this field, except that it
+MUST NOT be null or the empty string ("").</td>
+ </tr>
+ <tr>
+ <td>SECURITY_PATCH</td>
+ <td>An value indicating the security patch level of a build. It MUST signify that the
+build includes all security patches issued up through the designated Android Public
+Security Bulletin. It MUST be in the format, [YYYY-MM-DD], matching the Public Security
+Bulletin's broadcast date, for example [2015-10-01].</td>
+ </tr>
+ <tr>
+ <td>BASE_OS</td>
+ <td>An value representing the FINGERPRINT parameter of the build that is otherwise
+ identical to this build except for the patches provided in the Android Public
+ Security Bulletin. It MUST report the correct value and if such a build does not
+ exist, report an emtpy string ("").</td>
+ </tr>
+</table>
+
+
+<h3 id="3_2_3_intent_compatibility">3.2.3. Intent Compatibility</h3>
+
+
+<p>Device implementations MUST honor Android’s loose-coupling intent system, as
+described in the sections below. By“honored ” it is meant that the device
+implementer MUST provide an Android Activity or Service that specifies a
+matching intent filter that binds to and implements correct behavior for each
+specified intent pattern.</p>
+
+<h4 id="3_2_3_1_core_application_intents">3.2.3.1. Core Application Intents</h4>
+
+
+<p>Android intents allow application components to request functionality from
+other Android components. The Android upstream project includes a list of
+applications considered core Android applications, which implements several
+intent patterns to perform common actions. The core Android applications are:</p>
+
+<ul>
+ <li>Desk Clock</li>
+ <li>Browser</li>
+ <li>Calendar</li>
+ <li>Contacts</li>
+ <li>Gallery</li>
+ <li>GlobalSearch</li>
+ <li>Launcher</li>
+ <li>Music</li>
+ <li>Settings</li>
+</ul>
+
+<p>Device implementations SHOULD include the core Android applications as
+appropriate but MUST include a component implementing the same intent patterns
+defined by all the “public” Activity or Service components of these core
+Android applications. Note that Activity or Service components are considered
+“public” when the attribute android:exported is absent or has the value true.</p>
+
+<h4 id="3_2_3_2_intent_resolution">3.2.3.2. Intent Resolution</h4>
+
+
+<p>As Android is an extensible platform, device implementations MUST allow each
+intent pattern referenced in <a href="#3_2_3_1_core_application_intents">section 3.2.3.1</a>
+to be overridden by third-party applications. The upstream Android open source
+implementation allows this by default; device implementers MUST NOT attach
+special privileges to system applications' use of these intent patterns, or
+prevent third-party applications from binding to and assuming control of these
+patterns. This prohibition specifically includes but is not limited to
+disabling the“Chooser” user interface that allows the user to select between
+multiple applications that all handle the same intent pattern.</p>
+
+<p>Device implementations MUST provide a user interface for users to modify the default
+activity for intents.</p>
+
+<p>However, device implementations MAY provide default activities for specific URI
+patterns (eg. http://play.google.com) when the default activity provides a more
+specific attribute for the data URI. For example, an intent filter pattern specifying
+the data URI “http://www.android.com” is more specific than the browser's
+core intent pattern for “http://”.</p>
+
+<p>Android also includes a mechanism for third-party apps to declare an authoritative
+default app linking behavior for certain types of web URI intents [<a
+href="https://developer.android.com/training/app-links">Resources, 140</a>]. When such
+authoritative declarations are defined in an app's intent filter patterns, device
+implementations:</p>
+
+<ul>
+<li>MUST attempt to validate any intent filters by performing the validation steps
+defined in the Digital Asset Links specification [<a
+href="https://developers.google.com/digital-asset-links">Resources, 141</a>] as implemented
+by the Package Manager in the upstream Android Open Source Project.</li>
+<li>MUST attempt validation of the intent filters during the installation of the
+application and set all successfully validated UIR intent filters as default app handlers
+for their UIRs.</li>
+<li>MAY set specific URI intent filters as default app handlers for their URIs, if they
+are successfully verified but other candidate URI filters fail verification. If a device
+implementation does this, it MUST provide the user appropriate per-URI pattern overrides
+in the settings menu.</li>
+<li>MUST provide the user with per-app App Links controls in Settings as follows:
+ <ul>
+ <li>The user MUST be able to override holistically the default app links behavior for
+ an app to be: always open, always ask, or never open, which must apply to all candidate
+ URI intent filters equally.</li>
+ <li>The user MUST be able to see a list of the candidate URI intent filters.</li>
+ <li>The device implementation MAY provide the user with the ability to override specific
+ candidate URI intent filters that were successfully verified, on a per-intent filter basis.
+ </li>
+ <li>The device implementation MUST provide users with the ability to view and override
+ specific candidate URI intent filters if the device implementation lets some candidate
+ URI intent filters succeed verification while some others can fail.</li>
+ </ul>
+</li>
+</ul>
+
+<h4 id="3_2_3_3_intent_namespaces">3.2.3.3. Intent Namespaces</h4>
+
+
+<p>Device implementations MUST NOT include any Android component that honors any
+new intent or broadcast intent patterns using an ACTION, CATEGORY, or other key
+string in the android.* or com.android.* namespace. Device implementers MUST
+NOT include any Android components that honor any new intent or broadcast
+intent patterns using an ACTION, CATEGORY, or other key string in a package
+space belonging to another organization. Device implementers MUST NOT alter or
+extend any of the intent patterns used by the core apps listed in <a href="#3_2_3_1_core_application_intents">section 3.2.3.1</a>. Device implementations MAY include intent patterns using namespaces clearly
+and obviously associated with their own organization. This prohibition is
+analogous to that specified for Java language classes in <a href="#3_6_api_namespaces">section 3.6</a>.</p>
+
+<h4 id="3_2_3_4_broadcast_intents">3.2.3.4. Broadcast Intents</h4>
+
+
+<p>Third-party applications rely on the platform to broadcast certain intents to
+notify them of changes in the hardware or software environment.
+Android-compatible devices MUST broadcast the public broadcast intents in
+response to appropriate system events. Broadcast intents are described in the
+SDK documentation.</p>
+
+<h4 id="3_2_3_5_default_app_settings">3.2.3.5. Default App Settings</h4>
+
+
+<p>Android includes settings that provide users an easy way to select their
+default applications, for example for Home screen or SMS. Where it makes sense,
+device implementations MUST provide a similar settings menu and be compatible
+with the intent filter pattern and API methods described in the SDK
+documentation as below.</p>
+
+<p>Device implementations:</p>
+
+<ul>
+ <li>MUST honor the android.settings.HOME_SETTINGS intent to show a default app
+settings menu for Home Screen, if the device implementation reports
+android.software.home_screen [<a href="http://developer.android.com/reference/android/provider/Settings.html">Resources, 10</a>]</li>
+ <li>MUST provide a settings menu that will call the
+android.provider.Telephony.ACTION_CHANGE_DEFAULT intent to show a dialog to
+change the default SMS application, if the device implementation reports
+android.hardware.telephony [<a href="http://developer.android.com/reference/android/provider/Telephony.Sms.Intents.html">Resources, 11</a>]</li>
+ <li>MUST honor the android.settings.NFC_PAYMENT_SETTINGS intent to show a default
+app settings menu for Tap and Pay, if the device implementation reports
+android.hardware.nfc.hce [<a href="http://developer.android.com/reference/android/provider/Settings.html">Resources, 10</a>]</li>
+</ul>
+
+<h2 id="3_3_native_api_compatibility">3.3. Native API Compatibility</h2>
+
+
+<h3 id="3_3_1_application_binary_interfaces">3.3.1. Application Binary Interfaces</h3>
+
+
+<p>Managed Dalvik bytecode can call into native code provided in the application
+.apk file as an ELF .so file compiled for the appropriate device hardware
+architecture. As native code is highly dependent on the underlying processor
+technology, Android defines a number of Application Binary Interfaces (ABIs) in
+the Android NDK. Device implementations MUST be compatible with one or more
+defined ABIs, and MUST implement compatibility with the Android NDK, as below.</p>
+
+<p>If a device implementation includes support for an Android ABI, it:</p>
+
+<ul>
+ <li>MUST include support for code running in the managed environment to call into
+native code, using the standard Java Native Interface (JNI) semantics</li>
+ <li>MUST be source-compatible (i.e. header compatible) and binary-compatible (for
+the ABI) with each required library in the list below</li>
+ <li>MUST support the equivalent 32-bit ABI if any 64-bit ABI is supported</li>
+ <li>MUST accurately report the native Application Binary Interface (ABI) supported
+by the device, via the android.os.Build.SUPPORTED_ABIS,
+android.os.Build.SUPPORTED_32_BIT_ABIS, and
+android.os.Build.SUPPORTED_64_BIT_ABIS parameters, each a comma separated list
+of ABIs ordered from the most to the least preferred one</li>
+ <li>MUST report, via the above parameters, only those ABIs documented and
+described in the latest version of the Android NDK ABI Management documentation
+[<a href="https://developer.android.com/ndk/guides/abis.html">Resources, 12</a>],
+and MUST include support for the Advanced SIMD (a.k.a. NEON)
+[<a href="http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/Beijfcja.html">Resources, 13</a>]
+extension
+ </li>
+ <li>SHOULD be built using the source code and header files available in the
+upstream Android Open Source Project</li>
+</ul>
+
+<p>The following native code APIs MUST be available to apps that include native
+code:</p>
+
+<ul>
+ <li>libc (C library)</li>
+ <li>libm (math library)</li>
+ <li>Minimal support for C++</li>
+ <li>JNI interface</li>
+ <li>liblog (Android logging)</li>
+ <li>libz (Zlib compression)</li>
+ <li>libdl (dynamic linker)</li>
+ <li>libGLESv1_CM.so (OpenGL ES 1.x)</li>
+ <li>libGLESv2.so (OpenGL ES 2.0)</li>
+ <li>libGLESv3.so (OpenGL ES 3.x)</li>
+ <li>libEGL.so (native OpenGL surface management)</li>
+ <li>libjnigraphics.so</li>
+ <li>libOpenSLES.so (OpenSL ES 1.0.1 audio support)</li>
+ <li>libOpenMAXAL.so (OpenMAX AL 1.0.1 support)</li>
+ <li>libandroid.so (native Android activity support)</li>
+ <li>libmediandk.so (native media APIs support)</li>
+ <li>Support for OpenGL, as described below</li>
+</ul>
+
+<p>Note that future releases of the Android NDK may introduce support for
+additional ABIs. If a device implementation is not compatible with an existing
+predefined ABI, it MUST NOT report support for any ABIs at all.</p>
+
+<p>Note that device implementations MUST include libGLESv3.so and it MUST symlink
+(symbolic link) to libGLESv2.so. in turn, MUST export all the OpenGL ES 3.1 and
+Android Extension Pack [<a href="http://developer.android.com/guide/topics/graphics/opengl.html#aep">Resources, 14</a>] function symbols as defined in the NDK release android-21. Although all the
+symbols must be present, only the corresponding functions for OpenGL ES
+versions and extensions actually supported by the device must be fully
+implemented.</p>
+
+<p>Device implementations MUST NOT include a native library with the
+name libvulkan.so.</p>
+
+<p>Native code compatibility is challenging. For this reason, device implementers
+are <strong>STRONGLY RECOMMENDED</strong> to use the implementations of the libraries listed above from the upstream
+Android Open Source Project. </p>
+
+<h3 id="3_3_2_32-bit_arm_native_code_compatibility">
+3.3.2. 32-bit ARM Native Code Compatibility
+</h3>
+
+<p>The ARMv8 architecture deprecates several CPU operations, including some
+operations used in existing native code. On 64-bit ARM devices, the following
+deprecated operations MUST remain available to 32-bit native ARM code, either
+through native CPU support or through software emulation:</p>
+
+<ul>
+<li>SWP and SWPB instructions</li>
+<li>SETEND instruction</li>
+<li>CP15ISB, CP15DSB, and CP15DMB barrier operations</li>
+</ul>
+
+<p>Legacy versions of the Android NDK used /proc/cpuinfo to discover CPU features
+from 32-bit ARM native code. For compatibility with applications built using this
+NDK, devices MUST include the following lines in /proc/cpuinfo when it is read
+by 32-bit ARM applications:</p>
+
+<ul>
+<li>"Features: ", followed by a list of any optional ARMv7 CPU features
+supported by the device</li>
+<li>"CPU architecture: ", followed by an integer describing the device's
+highest supported ARM architecture (e.g., "8" for ARMv8 devices)</li>
+</ul>
+
+<p>These requirements only apply when /proc/cpuinfo is read by 32-bit ARM
+applications. Devices SHOULD not alter /proc/cpuinfo when read by 64-bit ARM or
+non-ARM applications.</p>
+
+<h2 id="3_4_web_compatibility">3.4. Web Compatibility</h2>
+
+
+<h3 id="3_4_1_webview_compatibility">3.4.1. WebView Compatibility</h3>
+
+<div class="note">
+<p>Android Watch devices MAY, but all other device implementations MUST provide
+a complete implementation of the android.webkit.Webview API.</p>
+</div>
+
+
+<p>The platform feature android.software.webview MUST be reported on any device
+that provides a complete implementation of the android.webkit.WebView API, and
+MUST NOT be reported on devices without a complete implementation of the API.
+The Android Open Source implementation uses code from the Chromium Project to
+implement the android.webkit.WebView [<a href="http://developer.android.com/reference/android/webkit/WebView.html">Resources, 15</a>]. Because it is not feasible to develop a comprehensive test suite for a web
+rendering system, device implementers MUST use the specific upstream build of
+Chromium in the WebView implementation. Specifically:</p>
+
+<ul>
+ <li>Device android.webkit.WebView implementations MUST be based on the Chromium
+build from the upstream Android Open Source Project for Android 6.0. This build
+includes a specific set of functionality and security fixes for the WebView [<a href="http://www.chromium.org/">Resources, 16</a>].</li>
+ <li>The user agent string reported by the WebView MUST be in this format:
+<p>Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv)
+AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile
+Safari/537.36</p>
+ <ul>
+ <li>The value of the $(VERSION) string MUST be the same as the value for
+android.os.Build.VERSION.RELEASE.</li>
+ <li>The value of the $(MODEL) string MUST be the same as the value for
+android.os.Build.MODEL.</li>
+ <li>The value of the $(BUILD) string MUST be the same as the value for
+android.os.Build.ID.</li>
+ <li>The value of the $(CHROMIUM_VER) string MUST be the version of Chromium in the
+upstream Android Open Source Project.</li>
+ <li>Device implementations MAY omit Mobile in the user agent string.</li>
+ </ul></li></ul>
+
+<p>The WebView component SHOULD include support for as many HTML5 features as
+possible and if it supports the feature SHOULD conform to the HTML5
+specification [<a href="http://html.spec.whatwg.org/multipage/">Resources, 17</a>].</p>
+
+<h3 id="3_4_2_browser_compatibility">3.4.2. Browser Compatibility</h3>
+
+<div class="note">
+<p>Android Television, Watch, and Android Automotive implementations MAY omit a
+browser application, but MUST support the public intent patterns as described in
+<a href="#3_2_3_1_core_application_intents">section 3.2.3.1</a>. All other types
+of device implementations MUST include a standalone Browser application for
+general user web browsing.</p>
+</div>
+
+<p>The standalone Browser MAY be based on a browser technology other than WebKit.
+However, even if an alternate Browser application is used, the
+android.webkit.WebView component provided to third-party applications MUST be
+based on WebKit, as described in <a href="#3_4_1_webview_compatibility">section 3.4.1</a>.</p>
+
+<p>Implementations MAY ship a custom user agent string in the standalone Browser
+application.</p>
+
+<p>The standalone Browser application (whether based on the upstream WebKit
+Browser application or a third-party replacement) SHOULD include support for as
+much of HTML5 [<a href="http://html.spec.whatwg.org/multipage/">Resources, 17</a>] as possible. Minimally, device implementations MUST support each of these
+APIs associated with HTML5:</p>
+
+<ul>
+ <li>application cache/offline operation [<a href="http://www.w3.org/html/wg/drafts/html/master/browsers.html#offline">Resources, 18</a>]</li>
+ <li>the <video> tag [<a href="http://www.w3.org/html/wg/drafts/html/master/semantics.html#video">Resources, 19</a>]</li>
+ <li>geolocation [<a href="http://www.w3.org/TR/geolocation-API/">Resources, 20</a>]</li>
+</ul>
+
+<p>Additionally, device implementations MUST support the HTML5/W3C webstorage API
+[<a href="http://www.w3.org/TR/webstorage/">Resources, 21</a>], and SHOULD support the HTML5/W3C IndexedDB API [<a href="http://www.w3.org/TR/IndexedDB/">Resources, 22</a>]. Note that as the web development standards bodies are transitioning to favor
+IndexedDB over webstorage, IndexedDB is expected to become a required component
+in a future version of Android.</p>
+
+<h2 id="3_5_api_behavioral_compatibility">3.5. API Behavioral Compatibility</h2>
+
+
+<p>The behaviors of each of the API types (managed, soft, native, and web) must be
+consistent with the preferred implementation of the upstream Android Open
+Source Project [<a href="http://source.android.com/">Resources, 2</a>]. Some specific areas of compatibility are:</p>
+
+<ul>
+ <li>Devices MUST NOT change the behavior or semantics of a standard intent.</li>
+ <li>Devices MUST NOT alter the lifecycle or lifecycle semantics of a particular
+type of system component (such as Service, Activity, ContentProvider, etc.).</li>
+ <li>Devices MUST NOT change the semantics of a standard permission.</li>
+</ul>
+
+<p>The above list is not comprehensive. The Compatibility Test Suite (CTS) tests
+significant portions of the platform for behavioral compatibility, but not all.
+It is the responsibility of the implementer to ensure behavioral compatibility
+with the Android Open Source Project. For this reason, device implementers
+SHOULD use the source code available via the Android Open Source Project where
+possible, rather than re-implement significant parts of the system.</p>
+
+<h2 id="3_6_api_namespaces">3.6. API Namespaces</h2>
+
+
+<p>Android follows the package and class namespace conventions defined by the Java
+programming language. To ensure compatibility with third-party applications,
+device implementers MUST NOT make any prohibited modifications (see below) to
+these package namespaces:</p>
+
+<ul>
+ <li>java.*</li>
+ <li>javax.*</li>
+ <li>sun.*</li>
+ <li>android.*</li>
+ <li>com.android.*</li>
+</ul>
+
+<p><strong>Prohibited modifications include</strong>:</p>
+
+<ul>
+ <li>Device implementations MUST NOT modify the publicly exposed APIs on the Android
+platform by changing any method or class signatures, or by removing classes or
+class fields.</li>
+ <li>Device implementers MAY modify the underlying implementation of the APIs, but
+such modifications MUST NOT impact the stated behavior and Java-language
+signature of any publicly exposed APIs.</li>
+ <li>Device implementers MUST NOT add any publicly exposed elements (such as classes
+or interfaces, or fields or methods to existing classes or interfaces) to the
+APIs above.</li>
+</ul>
+
+<p>A “publicly exposed element” is any construct which is not decorated with the“@hide” marker as used in the upstream Android source code. In other words,
+device implementers MUST NOT expose new APIs or alter existing APIs in the
+namespaces noted above. Device implementers MAY make internal-only
+modifications, but those modifications MUST NOT be advertised or otherwise
+exposed to developers.</p>
+
+<p>Device implementers MAY add custom APIs, but any such APIs MUST NOT be in a
+namespace owned by or referring to another organization. For instance, device
+implementers MUST NOT add APIs to the com.google.* or similar namespace: only
+Google may do so. Similarly, Google MUST NOT add APIs to other companies'
+namespaces. Additionally, if a device implementation includes custom APIs
+outside the standard Android namespace, those APIs MUST be packaged in an
+Android shared library so that only apps that explicitly use them (via the
+lt;uses-librarygt; mechanism) are affected by the increased memory usage of such
+APIs.</p>
+
+<p>If a device implementer proposes to improve one of the package namespaces above
+(such as by adding useful new functionality to an existing API, or adding a new
+API), the implementer SHOULD visit <a href="http://source.android.com/">source.android.com</a> and begin the process for contributing changes and code, according to the
+information on that site.</p>
+
+<p>Note that the restrictions above correspond to standard conventions for naming
+APIs in the Java programming language; this section simply aims to reinforce
+those conventions and make them binding through inclusion in this Compatibility
+Definition.</p>
+
+<h2 id="3_7_runtime_compatibility">3.7. Runtime Compatibility</h2>
+
+
+<p>Device implementations MUST support the full Dalvik Executable (DEX) format and
+Dalvik bytecode specification and semantics [<a href="https://android.googlesource.com/platform/dalvik/">Resources, 23</a>]. Device implementers SHOULD use ART, the reference upstream implementation of
+the Dalvik Executable Format, and the reference implementation’s package
+management system.</p>
+
+<p>Device implementations MUST configure Dalvik runtimes to allocate memory in
+accordance with the upstream Android platform, and as specified by the
+following table. (See <a href="#7_1_1_screen_configuration">section 7.1.1</a> for screen size and screen density definitions.)</p>
+
+<p>Note that memory values specified below are considered minimum values and
+device implementations MAY allocate more memory per application.</p>
+
+<table>
+ <tr>
+ <th>Screen Layout</th>
+ <th>Screen Density</th>
+ <th>Minimum Application Memory</th>
+ </tr>
+ <tr>
+ <td rowspan="12">Android Watch</td>
+ <td>120 dpi (ldpi)</td>
+ <td rowspan="3">32MB</td>
+ </tr>
+ <tr>
+ <td>160 dpi (mdpi)</td>
+ </tr>
+ <tr>
+ <td>213 dpi (tvdpi)</td>
+ </tr>
+ <tr>
+ <td>240 dpi (hdpi)</td>
+ <td rowspan="2">36MB</td>
+ </tr>
+ <tr>
+ <td>280 dpi (280dpi)</td>
+ </tr>
+ <tr>
+ <td>320 dpi (xhdpi)</td>
+ <td rowspan="2">48MB</td>
+ </tr>
+ <tr>
+ <td>360 dpi (360dpi)</td>
+ </tr>
+ <tr>
+ <td>400 dpi (400dpi)</td>
+ <td>56MB</td>
+ </tr>
+ <tr>
+ <td>420 dpi (420dpi)</td>
+ <td>64MB</td>
+ </tr>
+ <tr>
+ <td>480 dpi (xxhdpi)</td>
+ <td>88MB</td>
+ </tr>
+ <tr>
+ <td>560 dpi (560dpi)</td>
+ <td>112MB</td>
+ </tr>
+ <tr>
+ <td>640 dpi (xxxhdpi)</td>
+ <td>154MB</td>
+ </tr>
+ <tr>
+ <td rowspan="12">small/normal</td>
+ <td>120 dpi (ldpi)</td>
+ <td rowspan="2">32MB</td>
+ </tr>
+ <tr>
+ <td>160 dpi (mdpi)</td>
+ </tr>
+ <tr>
+ <td>213 dpi (tvdpi)</td>
+ <td rowspan="3">48MB</td>
+ </tr>
+ <tr>
+ <td>240 dpi (hdpi)</td>
+ </tr>
+ <tr>
+ <td>280 dpi (280dpi)</td>
+ </tr>
+ <tr>
+ <td>320 dpi (xhdpi)</td>
+ <td rowspan="2">80MB</td>
+ </tr>
+ <tr>
+ <td>360 dpi (360dpi)</td>
+ </tr>
+ <tr>
+ <td>400 dpi (400dpi)</td>
+ <td>96MB</td>
+ </tr>
+ <tr>
+ <td>420 dpi (420dpi)</td>
+ <td>112MB</td>
+ </tr>
+ <tr>
+ <td>480 dpi (xxhdpi)</td>
+ <td>128MB</td>
+ </tr>
+ <tr>
+ <td>560 dpi (560dpi)</td>
+ <td>192MB</td>
+ </tr>
+ <tr>
+ <td>640 dpi (xxxhdpi)</td>
+ <td>256MB</td>
+ </tr>
+ <tr>
+ <td rowspan="12">large</td>
+ <td>120 dpi (ldpi)</td>
+ <td>32MB</td>
+ </tr>
+ <tr>
+ <td>160 dpi (mdpi)</td>
+ <td>48MB</td>
+ </tr>
+ <tr>
+ <td>213 dpi (tvdpi)</td>
+ <td rowspan="2">80MB</td>
+ </tr>
+ <tr>
+ <td>240 dpi (hdpi)</td>
+ </tr>
+ <tr>
+ <td>280 dpi (280dpi)</td>
+ <td>96MB</td>
+ </tr>
+ <tr>
+ <td>320 dpi (xhdpi)</td>
+ <td>128MB</td>
+ </tr>
+ <tr>
+ <td>360 dpi (360dpi)</td>
+ <td>160MB</td>
+ </tr>
+ <tr>
+ <td>400 dpi (400dpi)</td>
+ <td>192MB</td>
+ </tr>
+ <tr>
+ <td>420 dpi (420dpi)</td>
+ <td>228MB</td>
+ </tr>
+ <tr>
+ <td>480 dpi (xxhdpi)</td>
+ <td>256MB</td>
+ </tr>
+ <tr>
+ <td>560 dpi (560dpi)</td>
+ <td>384MB</td>
+ </tr>
+ <tr>
+ <td>640 dpi (xxxhdpi)</td>
+ <td>512MB</td>
+ </tr>
+ <tr>
+ <td rowspan="12">xlarge</td>
+ <td>120 dpi (ldpi)</td>
+ <td>48MB</td>
+ </tr>
+ <tr>
+ <td>160 dpi (mdpi)</td>
+ <td>80MB</td>
+ </tr>
+ <tr>
+ <td>213 dpi (tvdpi)</td>
+ <td rowspan="2">96MB</td>
+ </tr>
+ <tr>
+ <td>240 dpi (hdpi)</td>
+ </tr>
+ <tr>
+ <td>280 dpi (280dpi)</td>
+ <td>144MB</td>
+ </tr>
+ <tr>
+ <td>320 dpi (xhdpi)</td>
+ <td>192MB</td>
+ </tr>
+ <tr>
+ <td>360 dpi (360dpi)</td>
+ <td>240MB</td>
+ </tr>
+ <tr>
+ <td>400 dpi (400dpi)</td>
+ <td>288MB</td>
+ </tr>
+ <tr>
+ <td>420 dpi (420dpi)</td>
+ <td>336MB</td>
+ </tr>
+ <tr>
+ <td>480 dpi (xxhdpi)</td>
+ <td>384MB</td>
+ </tr>
+ <tr>
+ <td>560 dpi (560dpi)</td>
+ <td>576MB</td>
+ </tr>
+ <tr>
+ <td>640 dpi (xxxhdpi)</td>
+ <td>768MB</td>
+ </tr>
+</table>
+
+
+<h2 id="3_8_user_interface_compatibility">3.8. User Interface Compatibility</h2>
+
+
+<h3 id="3_8_1_launcher_home_screen">3.8.1. Launcher (Home Screen)</h3>
+
+
+<p>Android includes a launcher application (home screen) and support for
+third-party applications to replace the device launcher (home screen). Device
+implementations that allow third-party applications to replace the device home
+screen MUST declare the platform feature android.software.home_screen.</p>
+
+<h3 id="3_8_2_widgets">3.8.2. Widgets</h3>
+
+<div class="note">
+<p>Widgets are optional for all Android device implementations, but SHOULD be
+supported on Android Handheld devices.</p>
+</div>
+
+
+<p>Android defines a component type and corresponding API and lifecycle that
+allows applications to expose an “AppWidget” to the end user [<a href="http://developer.android.com/guide/practices/ui_guidelines/widget_design.html">Resources, 24</a>] a feature that is STRONGLY RECOMMENDED to be supported on Handheld Device
+implementations. Device implementations that support embedding widgets on the
+home screen MUST meet the following requirements and declare support for
+platform feature android.software.app_widgets.</p>
+
+<ul>
+ <li>Device launchers MUST include built-in support for AppWidgets, and expose user
+interface affordances to add, configure, view, and remove AppWidgets directly
+within the Launcher.</li>
+ <li>Device implementations MUST be capable of rendering widgets that are 4 x 4 in
+the standard grid size. See the App Widget Design Guidelines in the Android SDK
+documentation [<a href="http://developer.android.com/guide/practices/ui_guidelines/widget_design.html">Resources, 24</a>] for details.</li>
+ <li>Device implementations that include support for lock screen MAY support
+application widgets on the lock screen.</li>
+</ul>
+
+<h3 id="3_8_3_notifications">3.8.3. Notifications</h3>
+
+
+<p>Android includes APIs that allow developers to notify users of notable events [<a href="http://developer.android.com/guide/topics/ui/notifiers/notifications.html">Resources, 25</a>], using hardware and software features of the device.</p>
+
+<p>Some APIs allow applications to perform notifications or attract attention
+using hardware—specifically sound, vibration, and light. Device implementations
+MUST support notifications that use hardware features, as described in the SDK
+documentation, and to the extent possible with the device implementation
+hardware. For instance, if a device implementation includes a vibrator, it MUST
+correctly implement the vibration APIs. If a device implementation lacks
+hardware, the corresponding APIs MUST be implemented as no-ops. This behavior
+is further detailed in <a href="#7_hardware_compatibility">section 7</a>.</p>
+
+<p>Additionally, the implementation MUST correctly render all resources (icons, animation files
+etc.) provided for in the APIs
+[<a href="https://developer.android.com/guide/topics/resources/available-resources.html">Resources, 26</a>],
+or in the Status/System Bar icon style guide
+[<a href="http://developer.android.com/design/style/iconography.html">Resources, 27</a>],
+which in the case of an Android Television device includes the possibility to not display the
+notifications. Device implementers MAY provide an alternative user experience for
+notifications than that provided by the reference Android Open Source
+implementation; however, such alternative notification systems MUST support
+existing notification resources, as above. </p>
+
+<p>Android includes support for various notifications, such as:</p>
+
+<ul>
+ <li><strong>Rich notifications</strong>. Interactive Views for ongoing notifications.</li>
+ <li><strong>Heads-up notifications</strong>. Interactive Views users can act on or dismiss without leaving the current app.</li>
+ <li><strong>Lockscreen notifications</strong>. Notifications shown over a lock screen with granular control on visibility.</li>
+</ul>
+
+<p>Android device implementations, when such notifications are made visible, MUST properly execute
+Rich and Heads-up notifications and include the title/name, icon, text as documented in the Android
+APIs [<a href="https://developer.android.com/design/patterns/notifications.html">Resources, 28</a>].
+</p>
+
+<p>Android includes Notification Listener Service APIs that allow apps (once
+explicitly enabled by the user) to receive a copy of all notifications as they
+are posted or updated. Device implementations MUST correctly and promptly send
+notifications in their entirety to all such installed and user-enabled listener
+services, including any and all metadata attached to the Notification object.</p>
+
+<h3 id="3_8_4_search">3.8.4. Search</h3>
+
+
+<p>Android includes APIs [<a href="http://developer.android.com/reference/android/app/SearchManager.html">Resources, 29</a>] that allow developers to incorporate search into their applications, and
+expose their application’s data into the global system search. Generally
+speaking, this functionality consists of a single, system-wide user interface
+that allows users to enter queries, displays suggestions as users type, and
+displays results. The Android APIs allow developers to reuse this interface to
+provide search within their own apps, and allow developers to supply results to
+the common global search user interface.</p>
+
+<p>Android device implementations SHOULD include global search, a single, shared,
+system-wide search user interface capable of real-time suggestions in response
+to user input. Device implementations SHOULD implement the APIs that allow
+developers to reuse this user interface to provide search within their own
+applications. Device implementations that implement the global search interface
+MUST implement the APIs that allow third-party applications to add suggestions
+to the search box when it is run in global search mode. If no third-party
+applications are installed that make use of this functionality, the default
+behavior SHOULD be to display web search engine results and suggestions.</p>
+
+<p>Android device implementations SHOULD implement an assistant on the device
+to handle the Assist action [<a
+href="http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST">Resources,
+30</a>].</p>
+
+<p>Android also includes the Assist APIs to allow applications to elect how much
+information of the current context is shared with the assistant on the device [<a
+href="https://developer.android.com/reference/android/app/assist/package-summary.html">Resources,
+31</a>]. Device implementations supporting the Assist action MUST indicate clearly to
+the end user when the the context is shared by displaying a white light around
+the edges of the screen. To ensure clear visibility to the end user, the indication MUST
+meet or exceed the duration and brightness of the Android Open Source Project
+implementation.</p>
+
+<h3 id="3_8_5_toasts">3.8.5. Toasts</h3>
+
+
+<p>Applications can use the “Toast” API to display short non-modal strings to the
+end user, that disappear after a brief period of time [<a href="http://developer.android.com/reference/android/widget/Toast.html">Resources, 32</a>]. Device implementations MUST display Toasts from applications to end users in
+some high-visibility manner.</p>
+
+<h3 id="3_8_6_themes">3.8.6. Themes</h3>
+
+
+<p>Android provides “themes” as a mechanism for applications to apply styles
+across an entire Activity or application.</p>
+
+<p>Android includes a “Holo” theme family as a set of defined styles for
+application developers to use if they want to match the Holo theme look and
+feel as defined by the Android SDK [<a href="http://developer.android.com/guide/topics/ui/themes.html">Resources, 33</a>]. Device implementations MUST NOT alter any of the Holo theme attributes
+exposed to applications [<a href="http://developer.android.com/reference/android/R.style.html">Resources, 34</a>].</p>
+
+<p>Android includes a “Material” theme family as a set of defined styles for
+application developers to use if they want to match the design theme’s look and
+feel across the wide variety of different Android device types. Device
+implementations MUST support the “Material” theme family and MUST NOT alter any
+of the Material theme attributes or their assets exposed to applications [<a href="http://developer.android.com/reference/android/R.style.html#Theme_Material">Resources, 35</a>].</p>
+
+<p>Android also includes a “Device Default” theme family as a set of defined
+styles for application developers to use if they want to match the look and
+feel of the device theme as defined by the device implementer. Device
+implementations MAY modify the Device Default theme attributes exposed to
+applications [<a href="http://developer.android.com/reference/android/R.style.html">Resources, 34</a>].</p>
+
+<p>Android supports a variant theme with translucent system bars, which allows
+application developers to fill the area behind the status and navigation bar
+with their app content. To enable a consistent developer experience in this
+configuration, it is important the status bar icon style is maintained across
+different device implementations. Therefore, Android device implementations
+MUST use white for system status icons (such as signal strength and battery
+level) and notifications issued by the system, unless the icon is indicating a
+problematic status or an app requests a light status bar using the
+SYSTEM_UI_FLAG_LIGHT_STATUS_BAR flag. When an app requests a light status bar,
+Android device implementations MUST change the color of the system status icons
+to black [<a href="http://developer.android.com/reference/android/R.style.html">Resources, 34</a>].</p>
+
+<h3 id="3_8_7_live_wallpapers">3.8.7. Live Wallpapers</h3>
+
+
+<p>Android defines a component type and corresponding API and lifecycle that
+allows applications to expose one or more “Live Wallpapers” to the end user [<a href="http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html">Resources, 36</a>]. Live wallpapers are animations, patterns, or similar images with limited
+input capabilities that display as a wallpaper, behind other applications.</p>
+
+<p>Hardware is considered capable of reliably running live wallpapers if it can
+run all live wallpapers, with no limitations on functionality, at a reasonable
+frame rate with no adverse effects on other applications. If limitations in the
+hardware cause wallpapers and/or applications to crash, malfunction, consume
+excessive CPU or battery power, or run at unacceptably low frame rates, the
+hardware is considered incapable of running live wallpaper. As an example, some
+live wallpapers may use an OpenGL 2.0 or 3.x context to render their content.
+Live wallpaper will not run reliably on hardware that does not support multiple
+OpenGL contexts because the live wallpaper use of an OpenGL context may
+conflict with other applications that also use an OpenGL context.</p>
+
+<p>Device implementations capable of running live wallpapers reliably as described
+above SHOULD implement live wallpapers, and when implemented MUST report the
+platform feature flag android.software.live_wallpaper.</p>
+
+<h3 id="3_8_8_activity_switching">3.8.8. Activity Switching</h3>
+
+<div class="note">
+<p>As the Recent function navigation key is OPTIONAL, the requirements to
+implement the overview screen is OPTIONAL for Android Television devices and
+Android Watch devices.</p>
+</div>
+
+
+<p>The upstream Android source code includes the overview screen [<a href="http://developer.android.com/guide/components/recents.html">Resources, 37</a>], a system-level user interface for task switching and displaying recently
+accessed activities and tasks using a thumbnail image of the application’s
+graphical state at the moment the user last left the application. Device
+implementations including the recents function navigation key as detailed in <a href="#7_2_3_navigation_keys">section 7.2.3</a>, MAY alter the interface but MUST meet the following requirements:</p>
+
+<ul>
+ <li>MUST display affiliated recents as a group that moves together.</li>
+ <li>MUST support at least up to 20 displayed activities.</li>
+ <li>MUST at least display the title of 4 activities at a time.</li>
+ <li>SHOULD display highlight color, icon, screen title in recents.</li>
+ <li>MUST implement the screen pinning behavior [<a href="http://developer.android.com/about/versions/android-5.0.html#ScreenPinning">Resources, 38</a>] and provide the user with a settings menu to toggle the feature.</li>
+ <li>SHOULD display a closing affordance ("x") but MAY delay this until user
+interacts with screens.</li>
+</ul>
+
+<p>Device implementations are STRONGLY RECOMMENDED to use the upstream Android user
+interface (or a similar thumbnail-based interface) for the overview screen.</p>
+
+<h3 id="3_8_9_input_management">3.8.9. Input Management</h3>
+
+
+<p>Android includes support for Input Management and support for third-party input
+method editors [<a href="http://developer.android.com/guide/topics/text/creating-input-method.html">Resources, 39</a>]. Device implementations that allow users to use third-party input methods on
+the device MUST declare the platform feature android.software.input_methods and
+support IME APIs as defined in the Android SDK documentation.</p>
+
+<p>Device implementations that declare the android.software.input_methods feature
+MUST provide a user-accessible mechanism to add and configure third-party input
+methods. Device implementations MUST display the settings interface in response
+to the android.settings.INPUT_METHOD_SETTINGS intent.</p>
+
+<h3 id="3_8_10_lock_screen_media_control">3.8.10. Lock Screen Media Control</h3>
+
+
+<p>The Remote Control Client API is deprecated from Android 5.0 in favor of the
+Media Notification Template that allows media applications to integrate with
+playback controls that are displayed on the lock screen [<a href="http://developer.android.com/reference/android/app/Notification.MediaStyle.html">Resources, 40</a>].
+Device implementations that support a lock screen, unless an Android Automotive or Watch
+implementation, MUST display the Lockscreen Notifications including the Media Notification
+Template.</p>
+
+<h3 id="3_8_11_dreams">3.8.11. Dreams</h3>
+
+
+<p>Android includes support for interactive screensavers called Dreams [<a href="http://developer.android.com/reference/android/service/dreams/DreamService.html">Resources, 41</a>]. Dreams allows users to interact with applications when a device connected to
+a power source is idle or docked in a desk dock. Android Watch devices MAY
+implement Dreams, but other types of device implementations SHOULD include
+support for Dreams and provide a settings option for users to configure Dreams
+in response to the android.settings.DREAM_SETTINGS intent.</p>
+
+<h3 id="3_8_12_location">3.8.12. Location</h3>
+
+
+<p>When a device has a hardware sensor (e.g. GPS) that is capable of providing the
+location coordinates, location modes MUST be displayed in the Location menu
+within Settings [<a href="http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE">Resources, 42</a>].</p>
+
+<h3 id="3_8_13_unicode_and_font">3.8.13. Unicode and Font</h3>
+
+
+<p>Android includes support for color emoji characters. When Android device
+implementations include an IME, devices SHOULD provide an input method to the
+user for the Emoji characters defined in Unicode 6.1 [<a href="http://www.unicode.org/versions/Unicode6.1.0/">Resources, 43</a>]. All devices MUST be capable of rendering these emoji characters in color glyph.</p>
+
+<p>Android includes support for Roboto 2 font with different
+weights—sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black,
+sans-serif-condensed, sans-serif-condensed-light—which MUST all be included for
+the languages available on the device and full Unicode 7.0 coverage of Latin,
+Greek, and Cyrillic, including the Latin Extended A, B, C, and D ranges, and
+all glyphs in the currency symbols block of Unicode 7.0.</p>
+
+<h2 id="3_9_device_administration">3.9. Device Administration</h2>
+
+<p>Android includes features that allow security-aware applications to perform
+device administration functions at the system level, such as enforcing password
+policies or performing remote wipe, through the Android Device Administration
+API [<a href="http://developer.android.com/guide/topics/admin/device-admin.html">Resources, 44</a>].
+Device implementations MUST provide an implementation of the DevicePolicyManager class
+[<a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html">Resources, 45</a>].
+Device implementations that include support for PIN (numeric) or PASSWORD
+(alphanumeric) based lock screens MUST support the full range of device
+administration policies defined in the Android SDK documentation
+[<a href="http://developer.android.com/guide/topics/admin/device-admin.html">Resources, 44</a>]
+and report the platform feature android.software.device_admin.</p>
+
+<h3 id="3_9_1_device_provisioning">3.9.1 Device Provisioning</h3>
+<h4 id="3_9_1_1_device_owner_provisioning">3.9.1.1 Device owner provisioning</h4>
+<p>If a device implementation declares the android.software.device_admin feature,
+the out of box setup flow MUST make it possible to enroll a Device Policy
+Controller (DPC) application as the Device Owner app
+[<a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)">
+Resources, 46</a>]. Device implementations MAY have a preinstalled application
+performing device administration functions but this application MUST NOT be set
+as the Device Owner app without explicit consent or action from the user or the
+administrator of the device.</p>
+
+<p>The device owner provisioning process (the flow initiated by
+android.app.action.PROVISION_MANAGED_DEVICE
+[<a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_DEVICE">
+Resources, 47</a>]) user experience MUST align with the AOSP implementation</p>
+
+<p>If the device implementation reports android.hardware.nfc, it MUST have NFC
+enabled, even during the out-of-box setup flow, in order to allow for NFC
+provisioning of Device owners
+[<a href="https://source.android.com/devices/tech/admin/provision.html#device_owner_provisioning_via_nfc">Resources, 48</a>].
+</p>
+
+<h4 id="3_9_1_2_managed_profile_provisioning">3.9.1.2 Managed profile provisioning</h4>
+<p>If a device implementation declares the android.software.managed_users,
+it MUST be possible to enroll a Device Policy Controller (DPC) application
+as the owner of a new Managed Profile
+[<a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isProfileOwnerApp(java.lang.String)">
+Resources, 49</a>]</p>
+
+<p>The managed profile provisioning process (the flow initiated by
+android.app.action.PROVISION_MANAGED_PROFILE
+[<a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_PROFILE">
+Resources, 50</a>]) user experience MUST align with the AOSP implementation
+</p>
+
+
+<h2 id="3_9_2_managed_profile_support">3.9.2 Managed Profile Support</h2>
+
+<p>Managed profile capable devices are those devices that:</p>
+<ul>
+ <li>Declare android.software.device_admin (see <a href="#3_9_device_administration">section 3.9 Device Administration)</a></li>
+ <li>Are not low RAM devices (see <a href="#7_6_1_minimum_memory_and_storage">section 7.6.1</a></li>
+ <li>Allocate internal (non-removable) storage as shared storage (see
+ <a href="#7_6_2_application_shared_storage">section 7.6.2</a>)</li>
+</ul>
+<p>Managed profile capable devices MUST:</p>
+<ul>
+ <li>Declare the platform feature flag android.software.managed_users.</li>
+ <li>Support managed profiles via the android.app.admin.DevicePolicyManager APIs</li>
+ <li>Allow one and only one managed profile to be created [<a
+href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_PROFILE">Resources,
+50</a>]</li>
+ <li>Use an icon badge (similar to the AOSP upstream work badge) to represent
+the managed applications and widgets and other badged UI elements like Recents
+& Notifications</li>
+ <li>Display a notification icon (similar to the AOSP upstream work badge) to
+indicate when user is within a managed profile application</li>
+ <li>Display a toast indicating that the user is in the managed profile if and when the
+device wakes up (ACTION_USER_PRESENT) and the foreground application is within
+the managed profile</li>
+ <li>Where a managed profile exists, show a visual affordance in the Intent
+'Chooser' to allow the user to forward the intent from the managed profile to
+the primary user or vice versa, if enabled by the Device Policy Controller</li>
+ <li>Where a managed profile exists, expose the following user affordances for both
+the primary user and the managed profile:
+ <ul>
+ <li>Separate accounting for battery, location, mobile data and storage usage
+ for the primary user and managed profile.</li>
+ <li>Independent management of VPN Applications installed within the primary
+ user or managed profile.</li>
+ <li>Independent management of applications installed within the primary user
+ user or managed profile.</li>
+ <li>Independent management of accounts within the primary user or managed
+ profile.</li>
+ </ul>
+ </li>
+ <li>Ensure the default dialer can look up caller information from the managed
+profile (if one exists) alongside those from the primary profile, if the Device
+Policy Controller permits it.</li>
+ <li>MUST ensure that it satisfies all the security requirements applicable for a device
+ with multiple users enabled (see <a href="#9_5_multi-user_support">section 9.5</a>),
+ even though the managed profile is not counted as another user in addition to the
+ primary user.</li>
+</ul>
+
+<h2 id="3_10_accessibility">3.10. Accessibility</h2>
+
+
+<p>Android provides an accessibility layer that helps users with disabilities to
+navigate their devices more easily. In addition, Android provides platform APIs
+that enable accessibility service implementations to receive callbacks for user
+and system events and generate alternate feedback mechanisms, such as
+text-to-speech, haptic feedback, and trackball/d-pad navigation [<a href="http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html">Resources, 51</a>].</p>
+
+<p>Device implementations include the following requirements:</p>
+
+<ul>
+<li>Android Automotive implementations SHOULD provide an implementation of the
+Android accessibility framework consistent with the default Android
+implementation.</li>
+<li>Device implementations (Android Automotive excluded) MUST provide an
+implementation of the Android accessibility framework consistent with the
+default Android implementation.</li>
+<li>Device implementations (Android Automotive excluded) MUST support
+third-party accessibility service implementations through the
+android.accessibilityservice APIs
+[<a href="http://developer.android.com/reference/android/view/accessibility/package-summary.html">Resources, 52</a>]</li>
+<li>Device implementations (Android Automotive excluded) MUST generate
+AccessibilityEvents and deliver these events to all registered
+AccessibilityService implementations in a manner consistent with the default
+Android implementation</li>
+<li> Device implementations (Android Automotive and Android Watch devices with
+no audio output excluded), MUST provide a user-accessible mechanism to enable
+and disable accessibility services, and MUST display this interface in response
+to the android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS intent.</li>
+</ul>
+
+<p>Additionally, device implementations SHOULD provide an implementation of an
+accessibility service on the device, and SHOULD provide a mechanism for users
+to enable the accessibility service during device setup. An open source
+implementation of an accessibility service is available from the Eyes Free
+project [<a href="http://code.google.com/p/eyes-free/">Resources, 53</a>].</p>
+
+<h2 id="3_11_text-to-speech">3.11. Text-to-Speech</h2>
+
+
+<p>Android includes APIs that allow applications to make use of text-to-speech
+(TTS) services and allows service providers to provide implementations of TTS
+services [<a href="http://developer.android.com/reference/android/speech/tts/package-summary.html">Resources, 54</a>]. Device implementations reporting the feature android.hardware.audio.output
+MUST meet these requirements related to the Android TTS framework. </p>
+
+<p>Android Automotive implementations:</p>
+<ul>
+<li>MUST support the Android TTS framework APIs.</li>
+<li>MAY support installation of third-party TTS engines. If supported, partners
+MUST provide a user-accessible interface that allows the user to select a TTS
+engine for use at system level.</li>
+</ul>
+
+<p>All other device implementations:</p>
+
+<ul>
+ <li> MUST support the Android TTS framework APIs and SHOULD include a TTS engine
+supporting the languages available on the device. Note that the upstream
+Android open source software includes a full-featured TTS engine
+implementation.
+ <li> MUST support installation of third-party TTS engines
+ <li> MUST provide a user-accessible interface that allows users to select a TTS
+engine for use at the system level
+</ul>
+
+<h2 id="3_12_tv_input_framework">3.12. TV Input Framework</h2>
+
+
+<p>The Android Television Input Framework (TIF) simplifies the delivery of live
+content to Android Television devices. TIF provides a standard API to create
+input modules that control Android Television devices. Android Television
+device implementations MUST support TV Input Framework
+[<a href="http://source.android.com/devices/tv/index.html">Resources, 55</a>].</p>
+
+<p>Device implementations that support TIF MUST declare the platform feature
+android.software.live_tv.</p>
+
+<h3 id="3_12_1_tv_app">3.12.1. TV App</h3>
+
+<p>Any device implementation that declares support for Live TV MUST have an
+installed TV application (TV App). The Android Open Source Project provides an implementation of the TV
+App.</p>
+
+<p>The TV App MUST provide facilities to install and use TV Channels
+[<a href="http://developer.android.com/reference/android/media/tv/TvContract.Channels.html">Resources, 56</a>]
+ and meet the following requirements:</p>
+
+<ul>
+ <li>Device implementations MUST allow third-party TIF-based inputs (third-party inputs)
+[<a href="https://source.android.com/devices/tv/index.html#third-party_input_example">Resources, 57</a>]
+ to be installed and managed.
+ <li>Device implementations MAY provide visual separation between pre-installed
+ TIF-based inputs (installed inputs)
+[<a href="https://source.android.com/devices/tv/index.html#tv_inputs">Resources, 58</a>]
+ and third-party inputs.
+ <li>The device implementations MUST NOT display the third-party inputs more than a
+single navigation action away from the TV App (i.e. expanding a list of
+third-party inputs from the TV App).
+</ul>
+
+<h4 id="3_12_1_1_electronic_program_guide">3.12.1.1. Electronic Program Guide</h4>
+
+<p>Android Television device implementations MUST show an informational and
+interactive overlay, which MUST include an electronic program guide (EPG)
+generated from the values in the TvContract.Programs fields
+[<a href="https://developer.android.com/reference/android/media/tv/TvContract.Programs.html">Resources, 59</a>].
+ The EPG MUST meet the following requirements:</p>
+
+<ul>
+ <li>The EPG MUST display information from all installed inputs and third-party
+inputs.
+ <li>The EPG MAY provide visual separation between the installed inputs and
+third-party inputs.
+ <li>The EPG is STRONGLY RECOMMENDED to display installed inputs and third-party
+inputs with equal prominence. The EPG MUST NOT display the third-party inputs
+more than a single navigation action away from the installed inputs on the EPG.
+ <li>On channel change, device implementations MUST display EPG data for the
+currently playing program.
+</ul>
+
+<h4 id="3_12_1_2_navigation">3.12.1.2. Navigation</h4>
+
+<p>Android Television device input devices (i.e. remote control, remote control
+application, or game controller) MUST allow navigation to all actionable
+sections of the screen via the D-pad. D-pad up and down MUST be used to change
+live TV channels when there is no actionable section on the screen.</p>
+
+<p>The TV App SHOULD pass key events to HDMI inputs through CEC.</p>
+
+<h4 id="3_12_1_3_tv_input_app_linking">3.12.1.3. TV input app linking</h4>
+
+<p>Android Television device implementations MUST support TV input app linking,
+which allows all inputs to provide activity links from the current activity to
+another activity (i.e. a link from live programming to related content)
+[<a href="http://developer.android.com/reference/android/media/tv/TvContract.Channels.html#COLUMN_APP_LINK_INTENT_URI">Resources, 60</a>].
+ The TV App MUST show TV input app linking when it is provided.</p>
+
+<h1 id="4_application_packaging_compatibility">4. Application Packaging Compatibility</h1>
+
+
+<p>Device implementations MUST install and run Android “.apk” files as generated
+by the “aapt” tool included in the official Android SDK [<a href="http://developer.android.com/tools/help/index.html">Resources, 61</a>].</p>
+
+<p>Devices implementations MUST NOT extend either the .apk [<a href="http://developer.android.com/guide/components/fundamentals.html">Resources, 62</a>], Android Manifest [<a href="http://developer.android.com/guide/topics/manifest/manifest-intro.html">Resources, 49</a>], Dalvik bytecode [<a href="https://android.googlesource.com/platform/dalvik/">Resources, 23</a>], or RenderScript bytecode formats in such a way that would prevent those
+files from installing and running correctly on other compatible devices.</p>
+
+<h1 id="5_multimedia_compatibility">5. Multimedia Compatibility</h1>
+
+
+<h2 id="5_1_media_codecs">5.1. Media Codecs</h2>
+
+
+<p>Device implementations MUST support the core media formats specified in the
+Android SDK documentation [<a href="http://developer.android.com/guide/appendix/media-formats.html">Resources, 64</a>]
+except where explicitly permitted in this document. Specifically, device
+implementations MUST support the media formats, encoders, decoders, file types,
+and container formats defined in the tables below and reported via MediaCodecList
+[<a href="http://developer.android.com/reference/android/media/MediaCodecList.html">Resources, 65</a>].
+Device implementations MUST also be able to decode all profiles reported in its CamcorderProfile
+[<a href="http://developer.android.com/reference/android/media/CamcorderProfile.html">Resources,
+66</a>] and MUST be able to decode all formats it can encode.
+
+All of these codecs are
+provided as software implementations in the preferred Android implementation
+from the Android Open Source Project.</p>
+
+<p>Please note that neither Google nor the Open Handset Alliance make any
+representation that these codecs are free from third-party patents. Those
+intending to use this source code in hardware or software products are advised
+that implementations of this code, including in open source software or
+shareware, may require patent licenses from the relevant patent holders.</p>
+
+<h3 id="5_1_1_audio_codecs">5.1.1. Audio Codecs</h3>
+
+<table>
+ <tr>
+ <th>Format/Codec</th>
+ <th>Encoder</th>
+ <th>Decoder</th>
+ <th>Details</th>
+ <th>Supported File Types/Container Formats</th>
+ </tr>
+ <tr>
+ <td>MPEG-4 AAC Profile<br />
+
+(AAC LC)</td>
+ <td>REQUIRED<sup>1</sup></td>
+ <td>REQUIRED</td>
+ <td>Support for mono/stereo/5.0/5.1<sup>2</sup> content with standard sampling rates from 8 to
+48 kHz.</td>
+ <td>
+ <ul>
+ <li class="table_list">3GPP (.3gp)</li>
+ <li class="table_list">MPEG-4 (.mp4, .m4a)</li>
+ <li class="table_list">ADTS raw AAC (.aac, decode in Android 3.1+, encode in Android 4.0+, ADIF not
+supported)</li>
+ <li class="table_list">MPEG-TS (.ts, not seekable, Android 3.0+)</li></ul></td>
+ </tr>
+ <tr>
+ <td>MPEG-4 HE AAC Profile (AAC+)</td>
+ <td>REQUIRED<sup>1</sup><br>(Android 4.1+)</td>
+ <td>REQUIRED</td>
+ <td>Support for mono/stereo/5.0/5.1<sup>2</sup> content with standard sampling rates from 16
+to 48 kHz.</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>MPEG-4 HE AACv2<br />
+
+Profile (enhanced AAC+)</td>
+ <td> </td>
+ <td>REQUIRED</td>
+ <td>Support for mono/stereo/5.0/5.1<sup>2</sup> content with standard sampling rates from 16
+to 48 kHz.</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>AAC ELD (enhanced low delay AAC)</td>
+ <td>REQUIRED<sup>1</sup> <br />
+
+(Android 4.1+)</td>
+ <td>REQUIRED<br />
+
+(Android 4.1+)</td>
+ <td>Support for mono/stereo content with standard sampling rates from 16 to 48 kHz.</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>AMR-NB</td>
+ <td>REQUIRED<sup>3</sup></td>
+ <td>REQUIRED<sup>3</sup></td>
+ <td>4.75 to 12.2 kbps sampled @ 8 kHz</td>
+ <td>3GPP (.3gp)</td>
+ </tr>
+ <tr>
+ <td>AMR-WB</td>
+ <td>REQUIRED<sup>3</sup></td>
+ <td>REQUIRED<sup>3</sup></td>
+ <td>9 rates from 6.60 kbit/s to 23.85 kbit/s sampled @ 16 kHz</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>FLAC</td>
+ <td></td>
+ <td>REQUIRED <br>(Android 3.1+)</td>
+ <td>Mono/Stereo (no multichannel). Sample rates up to 48 kHz (but up to 44.1 kHz is
+RECOMMENDED on devices with 44.1 kHz output, as the 48 to 44.1 kHz downsampler
+does not include a low-pass filter). 16-bit RECOMMENDED; no dither applied for
+24-bit.</td>
+ <td>FLAC (.flac) only</td>
+ </tr>
+ <tr>
+ <td>MP3</td>
+ <td></td>
+ <td>REQUIRED</td>
+ <td>Mono/Stereo 8-320Kbps constant (CBR) or variable bitrate (VBR)</td>
+ <td>MP3 (.mp3)</td>
+ </tr>
+ <tr>
+ <td>MIDI</td>
+ <td></td>
+ <td>REQUIRED</td>
+ <td>MIDI Type 0 and 1. DLS Version 1 and 2. XMF and Mobile XMF. Support for
+ringtone formats RTTTL/RTX, OTA, and iMelody</td>
+ <td><ul>
+ <li class="table_list">Type 0 and 1 (.mid, .xmf, .mxmf)</li>
+ <li class="table_list">RTTTL/RTX (.rtttl, .rtx)</li>
+ <li class="table_list">OTA (.ota)</li>
+ <li class="table_list">iMelody (.imy)</li></ul></td>
+ </tr>
+ <tr>
+ <td>Vorbis</td>
+ <td></td>
+ <td>REQUIRED</td>
+ <td></td>
+ <td><ul>
+ <li class="table_list">Ogg (.ogg)</li>
+ <li class="table_list">Matroska (.mkv, Android 4.0+)</li></ul></td>
+ </tr>
+ <tr>
+ <td>PCM/WAVE</td>
+ <td>REQUIRED<sup>4</sup><br> (Android 4.1+)</td>
+ <td>REQUIRED</td>
+ <td>16-bit linear PCM (rates up to limit of hardware). Devices MUST support
+sampling rates for raw PCM recording at 8000, 11025, 16000, and 44100 Hz
+frequencies.</td>
+ <td>WAVE (.wav)</td>
+ </tr>
+ <tr>
+ <td>Opus</td>
+ <td></td>
+ <td>REQUIRED<br> (Android 5.0+)</td>
+ <td></td>
+ <td>Matroska (.mkv)</td>
+ </tr>
+</table>
+
+
+<p class="table_footnote"> 1 Required for device implementations that define android.hardware.microphone
+but optional for Android Watch device implementations.</p>
+
+<p class="table_footnote">2 Only downmix of 5.0/5.1 content is required; recording or rendering more than
+2 channels is optional.</p>
+
+<p class="table_footnote">3 Required for Android Handheld device implementations. </p>
+
+<p class="table_footnote">4 Required for device implementations that define android.hardware.microphone,
+including Android Watch device implementations.</p>
+
+<h3 id="5_1_2_image_codecs">5.1.2. Image Codecs</h3>
+
+<table>
+ <tr>
+ <th>Format/Codec</th>
+ <th>Encoder</th>
+ <th>Decoder</th>
+ <th>Details</th>
+ <th>Supported File Types/Container Formats</th>
+ </tr>
+ <tr>
+ <td>JPEG</td>
+ <td>REQUIRED</td>
+ <td>REQUIRED</td>
+ <td>Base+progressive</td>
+ <td>JPEG (.jpg)</td>
+ </tr>
+ <tr>
+ <td>GIF</td>
+ <td></td>
+ <td>REQUIRED</td>
+ <td></td>
+ <td>GIF (.gif)</td>
+ </tr>
+ <tr>
+ <td>PNG</td>
+ <td>REQUIRED</td>
+ <td>REQUIRED</td>
+ <td></td>
+ <td>PNG (.png)</td>
+ </tr>
+ <tr>
+ <td>BMP</td>
+ <td></td>
+ <td>REQUIRED</td>
+ <td></td>
+ <td>BMP (.bmp)</td>
+ </tr>
+ <tr>
+ <td>WebP</td>
+ <td>REQUIRED</td>
+ <td>REQUIRED</td>
+ <td></td>
+ <td>WebP (.webp)</td>
+ </tr>
+</table>
+
+
+<h3 id="5_1_3_video_codecs">5.1.3. Video Codecs</h3>
+
+<table>
+ <tr>
+ <th>Format/Codec</th>
+ <th>Encoder</th>
+ <th>Decoder</th>
+ <th>Details</th>
+ <th>Supported File Types/<br>Container Formats</th>
+ </tr>
+ <tr>
+ <td>H.263</td>
+ <td>REQUIRED<sup>1</sup></td>
+ <td>REQUIRED<sup>2</sup></td>
+ <td></td>
+ <td><ul>
+ <li class="table_list">3GPP (.3gp)</li>
+ <li class="table_list">MPEG-4 (.mp4)</li></ul></td>
+ </tr>
+ <tr>
+ <td>H.264 AVC</td>
+ <td>REQUIRED<sup>2</sup></td>
+ <td>REQUIRED<sup>2</sup></td>
+ <td>See <a href="#5_2_video_encoding">section 5.2 </a>and <a href="#5_3_video_decoding">5.3</a> for details</td>
+ <td><ul>
+ <li class="table_list">3GPP (.3gp)</li>
+ <li class="table_list">MPEG-4 (.mp4)</li>
+ <li class="table_list">MPEG-2 TS (.ts, AAC audio only, not seekable, Android 3.0+)</li></ul></td>
+ </tr>
+ <tr>
+ <td>H.265 HEVC</td>
+ <td></td>
+ <td>REQUIRED<sup>5</sup></td>
+ <td>See <a href="#5_3_video_decoding">section 5.3</a> for details</td>
+ <td>MPEG-4 (.mp4)</td>
+ </tr>
+<tr>
+ <td>MPEG-2</td>
+ <td></td>
+ <td>STRONGLY RECOMMENDED<sup>6</sup></td>
+ <td>Main Profile</td>
+ <td>MPEG2-TS</td>
+</tr>
+ <tr>
+ <td>MPEG-4 SP</td>
+ <td></td>
+ <td>REQUIRED<sup>2</sup></td>
+ <td></td>
+ <td>3GPP (.3gp)</td>
+ </tr>
+ <tr>
+ <td>VP8<sup>3</sup></td>
+ <td>REQUIRED<sup>2</sup><br />
+
+(Android 4.3+)</td>
+ <td>REQUIRED<sup>2</sup><br />
+
+(Android 2.3.3+)</td>
+ <td>See <a href="#5_2_video_encoding">section 5.2</a> and <a href="#5_3_video_decoding">5.3</a> for details</td>
+ <td><ul>
+ <li class="table_list">WebM (.webm) [<a href="http://www.webmproject.org/">Resources, 67</a></li>
+ <li class="table_list">Matroska (.mkv, Android 4.0+)<sup>4</sup></li></ul></td>
+ </tr>
+ <tr>
+ <td>VP9</td>
+ <td></td>
+ <td>REQUIRED<sup>2</sup><br> (Android 4.4+)</td>
+ <td>See <a href="#5_3_video_decoding">section 5.3</a> for details</td>
+ <td><ul>
+ <li class="table_list">WebM (.webm) [<a href="http://www.webmproject.org/">Resources, 67</a>]</li>
+ <li class="table_list">Matroska (.mkv, Android 4.0+)<sup>4</sup></li></ul></td>
+ </tr>
+</table>
+
+
+<p class="table_footnote">1 Required for device implementations that include camera hardware and define
+android.hardware.camera or android.hardware.camera.front.</p>
+
+<p class="table_footnote">2 Required for device implementations except Android Watch devices. </p>
+
+<p class="table_footnote">3 For acceptable quality of web video streaming and video-conference services,
+device implementations SHOULD use a hardware VP8 codec that meets the
+requirements in [<a href="http://www.webmproject.org/hardware/rtc-coding-requirements/">Resources, 68</a>].</p>
+
+<p class="table_footnote">4 Device implementations SHOULD support writing Matroska WebM files.</p>
+
+<p class="table_footnote">5 STRONGLY RECOMMENDED for Android Automotive, optional for Android Watch, and required for all other device types.</p>
+
+<p class="table_footnote">6 Applies only to Android Television device implementations.</p>
+
+<h2 id="5_2_video_encoding">5.2. Video Encoding</h2>
+
+<div class="note">
+<p>Video codecs are optional for Android Watch device implementations.</p>
+</div>
+
+<p>Android device implementations with H.263 encoders, MUST support Baseline Profile Level 45.</p>
+
+<p>Android device implementations with H.264 codec support, MUST support Baseline
+Profile Level 3 and the following SD (Standard Definition) video encoding
+profiles and SHOULD support Main Profile Level 4 and the following HD (High
+Definition) video encoding profiles. Android Television devices are STRONGLY RECOMMENDED
+to encode HD 1080p video at 30 fps.</p>
+<table>
+ <tr>
+ <th></th>
+ <th>SD (Low quality)</th>
+ <th>SD (High quality)</th>
+ <th>HD 720p<sup>1</sup></th>
+ <th>HD 1080p<sup>1</sup></th>
+ </tr>
+ <tr>
+ <th>Video resolution</th>
+ <td>320 x 240 px</td>
+ <td>720 x 480 px</td>
+ <td>1280 x 720 px</td>
+ <td>1920 x 1080 px</td>
+ </tr>
+ <tr>
+ <th>Video frame rate</th>
+ <td>20 fps</td>
+ <td>30 fps</td>
+ <td>30 fps</td>
+ <td>30 fps</td>
+ </tr>
+ <tr>
+ <th>Video bitrate</th>
+ <td>384 Kbps</td>
+ <td>2 Mbps</td>
+ <td>4 Mbps</td>
+ <td>10 Mbps</td>
+ </tr>
+</table>
+
+
+<p class="table_footnote">1 When supported by hardware, but STRONGLY RECOMMENDED for Android Television
+devices.</p>
+
+<p>Android device implementations with VP8 codec support MUST support the SD video
+encoding profiles and SHOULD support the following HD (High Definition) video
+encoding profiles.</p>
+<table>
+ <tr>
+ <th></th>
+ <th>SD (Low quality)</th>
+ <th>SD (High quality)</th>
+ <th>HD 720p<sup>1</sup></th>
+ <th>HD 1080p<sup>1</sup></th>
+ </tr>
+ <tr>
+ <th>Video resolution</th>
+ <td>320 x 180 px</td>
+ <td>640 x 360 px</td>
+ <td>1280 x 720 px</td>
+ <td>1920 x 1080 px</td>
+ </tr>
+ <tr>
+ <th>Video frame rate</th>
+ <td>30 fps</td>
+ <td>30 fps</td>
+ <td>30 fps</td>
+ <td>30 fps</td>
+ </tr>
+ <tr>
+ <th>Video bitrate</th>
+ <td>800 Kbps </td>
+ <td>2 Mbps</td>
+ <td>4 Mbps</td>
+ <td>10 Mbps</td>
+ </tr>
+</table>
+
+<p class="table_footnote">1 When supported by hardware.</p>
+
+<h2 id="5_3_video_decoding">5.3. Video Decoding</h2>
+
+<div class="note">
+<p>Video codecs are optional for Android Watch device implementations.</p>
+</div>
+
+<p>Device implementations MUST support dynamic video resolution and frame rate
+switching through the standard Android APIs within the same stream for all VP8,
+VP9, H.264, and H.265 codecs in real time and up to the maximum resolution
+supported on the device.</p>
+
+<p>Android device implementations with H.263 decoders, MUST support Baseline
+Profile Level 30.</p>
+
+<p>Android device implementations with MPEG-4 decoders, MUST support Simple
+Profile Level 3.</p>
+
+<p>Android device implementations with H.264 decoders, MUST support Main Profile
+Level 3.1 and the following SD video decoding profiles and SHOULD support the
+HD decoding profiles. Android Television devices MUST support High Profile
+Level 4.2 and the HD 1080p decoding profile.</p>
+<table>
+ <tr>
+ <th></th>
+ <th>SD (Low quality)</th>
+ <th>SD (High quality)</th>
+ <th>HD 720p<sup>1</sup></th>
+ <th>HD 1080p<sup>1</sup></th>
+ </tr>
+ <tr>
+ <th>Video resolution</th>
+ <td>320 x 240 px</td>
+ <td>720 x 480 px</td>
+ <td>1280 x 720 px</td>
+ <td>1920 x 1080 px</td>
+ </tr>
+ <tr>
+ <th>Video frame rate</th>
+ <td>30 fps</td>
+ <td>30 fps</td>
+ <td>60 fps</td>
+ <td>30 fps / 60 fps<sup>2</sup></td>
+ </tr>
+ <tr>
+ <th>Video bitrate</th>
+ <td>800 Kbps </td>
+ <td>2 Mbps</td>
+ <td>8 Mbps</td>
+ <td>20 Mbps</td>
+ </tr>
+</table>
+
+
+<p class="table_footnote">1 REQUIRED for when the height as reported by the
+Display.getSupportedModes() method is not smaller than the video resolution.</p>
+
+<p class="table_footnote">2 REQUIRED for Android Television device implementations.</p>
+
+<p>Android device implementations when supporting VP8 codec as described in <a href="#5_1_3_video_codecs">section 5.1.3</a>, MUST support the following SD decoding profiles and SHOULD support the HD
+decoding profiles. Android Television devices MUST support the HD 1080p
+decoding profile. </p>
+<table>
+ <tr>
+ <th></th>
+ <th>SD (Low quality)</th>
+ <th>SD (High quality)</th>
+ <th>HD 720p<sup>1</sup></th>
+ <th>HD 1080p<sup>1</sup></th>
+ </tr>
+ <tr>
+ <th>Video resolution</th>
+ <td>320 x 180 px</td>
+ <td>640 x 360 px</td>
+ <td>1280 x 720 px</td>
+ <td>1920 x 1080 px</td>
+ </tr>
+ <tr>
+ <th>Video frame rate</th>
+ <td>30 fps</td>
+ <td>30 fps</td>
+ <td>30 fps / 60 fps<sup>2</sup></td>
+ <td>30 / 60 fps<sup>2</sup></td>
+ </tr>
+ <tr>
+ <th>Video bitrate</th>
+ <td>800 Kbps </td>
+ <td>2 Mbps</td>
+ <td>8 Mbps</td>
+ <td>20 Mbps</td>
+ </tr>
+</table>
+
+<p class="table_footnote">1 REQUIRED for when the height as reported by the
+Display.getSupportedModes() method is not smaller than the video resolution.</p>
+
+<p class="table_footnote">2 REQUIRED for Android Television device implementations.</p>
+
+<p>Android device implementations, when supporting VP9 codec as described in <a href="#5_1_3_video_codecs">section 5.1.3</a>, MUST support the following SD video decoding profiles and SHOULD support the
+HD decoding profiles. Android Television devices are STRONGLY RECOMMENDED to
+support the HD 1080p decoding profile and SHOULD support the UHD decoding
+profile. When the UHD video decoding profile is supported, it MUST support 8-bit
+color depth and SHOULD support VP9 Profile 2 (10-bit).</p>
+<table>
+ <tr>
+ <th></th>
+ <th>SD (Low quality)</th>
+ <th>SD (High quality)</th>
+ <th>HD 720p<sup>1</sup></th>
+ <th>HD 1080p<sup>2</sup></th>
+ <th>UHD<sup>2</sup></th>
+ </tr>
+ <tr>
+ <th>Video resolution</th>
+ <td>320 x 180 px</td>
+ <td>640 x 360 px</td>
+ <td>1280 x 720 px</td>
+ <td>1920 x 1080 px</td>
+ <td>3840 x 2160 px</td>
+ </tr>
+ <tr>
+ <th>Video frame rate</th>
+ <td>30 fps</td>
+ <td>30 fps</td>
+ <td>30 fps</td>
+ <td>60 fps</td>
+ <td>60 fps</td>
+ </tr>
+ <tr>
+ <th>Video bitrate</th>
+ <td>600 Kbps</td>
+ <td>1.6 Mbps</td>
+ <td>4 Mbps</td>
+ <td>10 Mbps</td>
+ <td>20 Mbps</td>
+ </tr>
+</table>
+
+
+<p class="table_footnote">1 Required for Android Television device implementations, but for other type of
+devices only when supported by hardware.</p>
+
+<p class="table_footnote">2 STRONGLY RECOMMENDED for existing Android Television device implementations when
+supported by hardware.</p>
+
+<p>Android device implementations, when supporting H.265 codec as described in <a href="#5_1_3_video_codecs">section 5.1.3</a>, MUST support the Main Profile Level 3 Main tier and the following SD video
+decoding profiles and SHOULD support the HD decoding profiles. Android
+Television devices MUST support the Main Profile Level 4.1 Main tier and the HD
+1080p decoding profile and SHOULD support Main10 Level 5 Main Tier profile and
+the UHD decoding profile.</p>
+<table>
+ <tr>
+ <th></th>
+ <th>SD (Low quality)</th>
+ <th>SD (High quality)</th>
+ <th>HD 720p<sup>1</sup></th>
+ <th>HD 1080p<sup>1</sup></th>
+ <th>UHD<sup>2</sup></th>
+ </tr>
+ <tr>
+ <th>Video resolution</th>
+ <td>352 x 288 px</td>
+ <td>640 x 360 px</td>
+ <td>1280 x 720 px</td>
+ <td>1920 x 1080 px</td>
+ <td>3840 x 2160 px</td>
+ </tr>
+ <tr>
+ <th>Video frame rate</th>
+ <td>30 fps</td>
+ <td>30 fps</td>
+ <td>30 fps</td>
+ <td>60 fps<sup>2</sup></td>
+ <td>60 fps</td>
+ </tr>
+ <tr>
+ <th>Video bitrate</th>
+ <td>600 Kbps </td>
+ <td>1.6 Mbps</td>
+ <td>4 Mbps</td>
+ <td>10 Mbps</td>
+ <td>20 Mbps</td>
+ </tr>
+</table>
+
+
+<p class="table_footnote">1 Required for Android Television device implementations, but for other type of
+devices only when supported by hardware.</p>
+
+<p class="table_footnote">2 STRONGLY RECOMMENDED
+for existing Android Television device implementations when supported by hardware.</p>
+
+<h2 id="5_4_audio_recording">5.4. Audio Recording</h2>
+
+
+<p>While some of the requirements outlined in this section are stated as SHOULD
+since Android 4.3, the Compatibility Definition for a future version is planned
+to change these to MUST. Existing and new Android devices are <strong>STRONGLY RECOMMENDED</strong>
+to meet these requirements, or they will not be able to attain Android compatibility when upgraded
+to the future version.</p>
+
+<h3 id="5_4_1_raw_audio_capture">5.4.1. Raw Audio Capture</h3>
+
+
+<p>Device implementations that declare android.hardware.microphone MUST allow
+capture of raw audio content with the following characteristics:</p>
+
+<ul>
+ <li><strong>Format</strong>: Linear PCM, 16-bit
+ <li><strong>Sampling rates</strong>: 8000, 11025, 16000, 44100
+ <li><strong>Channels</strong>: Mono
+</ul>
+
+<p>The capture for the above sample rates MUST be done without up-sampling, and
+any down-sampling MUST include an appropriate anti-aliasing filter.</p>
+
+<p>Device implementations that declare android.hardware.microphone SHOULD allow
+capture of raw audio content with the following characteristics:</p>
+
+<ul>
+ <li><strong>Format</strong>: Linear PCM, 16-bit
+ <li><strong>Sampling rates</strong>: 22050, 48000
+ <li><strong>Channels</strong>: Stereo
+</ul>
+
+<p>If capture for the above sample rates is supported,
+then the capture MUST be done without up-sampling at any ratio higher than 16000:22050
+or 44100:48000.
+Any up-sampling or down-sampling MUST include an appropriate anti-aliasing filter.</p>
+
+<h3 id="5_4_2_capture_for_voice_recognition">5.4.2. Capture for Voice Recognition</h3>
+
+
+<p>In addition to the above recording specifications, when an application has
+started recording an audio stream using the
+android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION audio source:</p>
+
+<ul>
+ <li>The device SHOULD exhibit approximately flat amplitude versus frequency
+characteristics: specifically, ±3 dB, from 100 Hz to 4000 Hz.
+ <li>Audio input sensitivity SHOULD be set such that a 90 dB sound power level (SPL)
+source at 1000 Hz yields RMS of 2500 for 16-bit samples.
+ <li>PCM amplitude levels SHOULD linearly track input SPL changes over at least a 30
+dB range from -18 dB to +12 dB re 90 dB SPL at the microphone.
+ <li>Total harmonic distortion SHOULD be less than 1% for 1 kHz at 90 dB SPL input
+level at the microphone.
+ <li>Noise reduction processing, if present, MUST be disabled.
+ <li>Automatic gain control, if present, MUST be disabled
+</ul>
+
+<p>If the platform supports noise suppression technologies tuned for speech
+recognition, the effect MUST be controllable from the
+android.media.audiofx.NoiseSuppressor API. Moreover, the UUID field for the
+noise suppressor’s effect descriptor MUST uniquely identify each implementation
+of the noise suppression technology.</p>
+
+<h3 id="5_4_3_capture_for_rerouting_of_playback">5.4.3. Capture for Rerouting of Playback</h3>
+
+
+<p>The android.media.MediaRecorder.AudioSource class includes the REMOTE_SUBMIX
+audio source. Devices that declare android.hardware.audio.output MUST properly
+implement the REMOTE_SUBMIX audio source so that when an application uses the
+android.media.AudioRecord API to record from this audio source, it can capture
+a mix of all audio streams except for the following:</p>
+
+<ul>
+ <li>STREAM_RING
+ <li>STREAM_ALARM
+ <li>STREAM_NOTIFICATION
+</ul>
+
+<h2 id="5_5_audio_playback">5.5. Audio Playback</h2>
+
+
+<p>Device implementations that declare android.hardware.audio.output MUST conform
+to the requirements in this section.</p>
+
+<h3 id="5_5_1_raw_audio_playback">5.5.1. Raw Audio Playback</h3>
+
+
+<p>The device MUST allow playback of raw audio content with the following
+characteristics:</p>
+
+<ul>
+ <li><strong>Format</strong>: Linear PCM, 16-bit</li>
+ <li><strong>Sampling rates</strong>: 8000, 11025, 16000, 22050, 32000, 44100</li>
+ <li><strong>Channels</strong>: Mono, Stereo</li>
+</ul>
+
+<p>The device SHOULD allow playback of raw audio content with the following
+characteristics:</p>
+
+<ul>
+ <li><strong>Sampling rates</strong>: 24000, 48000</li>
+</ul>
+
+<h3 id="5_5_2_audio_effects">5.5.2. Audio Effects</h3>
+
+
+<p>Android provides an API for audio effects for device implementations [<a href="http://developer.android.com/reference/android/media/audiofx/AudioEffect.html">Resources, 69</a>]. Device implementations that declare the feature
+android.hardware.audio.output:</p>
+
+<ul>
+ <li>MUST support the EFFECT_TYPE_EQUALIZER and EFFECT_TYPE_LOUDNESS_ENHANCER
+implementations controllable through the AudioEffect subclasses Equalizer,
+LoudnessEnhancer.</li>
+ <li>MUST support the visualizer API implementation, controllable through the
+Visualizer class.</li>
+ <li>SHOULD support the EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB,
+EFFECT_TYPE_PRESET_REVERB, and EFFECT_TYPE_VIRTUALIZER implementations
+controllable through the AudioEffect sub-classes BassBoost,
+EnvironmentalReverb, PresetReverb, and Virtualizer.</li>
+</ul>
+
+<h3 id="5_5_3_audio_output_volume">5.5.3. Audio Output Volume</h3>
+
+
+<p>Android Television device implementations MUST include support for system
+Master Volume and digital audio output volume attenuation on supported outputs,
+except for compressed audio passthrough output (where no audio decoding is done
+on the device).</p>
+
+<h2 id="5_6_audio_latency">5.6. Audio Latency</h2>
+
+
+<p>Audio latency is the time delay as an audio signal passes through a system.
+Many classes of applications rely on short latencies, to achieve real-time
+sound effects.</p>
+
+<p>For the purposes of this section, use the following definitions:</p>
+
+<ul>
+ <li><strong>output latency</strong>. The interval between when an application writes a frame of PCM-coded data and
+when the corresponding sound can be heard by an external listener or observed
+by a transducer.</li>
+ <li><strong>cold output latency</strong>. The output latency for the first frame, when the audio output system has been
+idle and powered down prior to the request.</li>
+ <li><strong>continuous output latency</strong>. The output latency for subsequent frames, after the device is playing audio.</li>
+ <li><strong>input latency</strong>. The interval between when an external sound is presented to the device and
+when an application reads the corresponding frame of PCM-coded data.</li>
+ <li><strong>cold input latency</strong>. The sum of lost input time and the input latency for the first frame, when the
+audio input system has been idle and powered down prior to the request.</li>
+ <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
+ 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>
+
+<p>Device implementations that declare android.hardware.audio.output are STRONGLY RECOMMENDED to meet
+or exceed these audio output requirements:</p>
+
+<ul>
+ <li>cold output latency of 100 milliseconds or less</li>
+ <li>continuous output latency of 45 milliseconds or less</li>
+ <li>minimize the cold output jitter</li>
+</ul>
+
+<p>If a device implementation meets the requirements of this section after any
+initial calibration when using the OpenSL ES PCM buffer queue API, for
+continuous output latency and cold output latency over at least one supported
+audio output device, it is STRONGLY RECOMMENDED to report support for low-latency audio, by reporting
+the feature android.hardware.audio.low_latency via the
+android.content.pm.PackageManager class [<a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">Resources, 70</a>]. Conversely, if the device implementation does not meet these requirements it
+MUST NOT report support for low-latency audio.</p>
+
+<p>Device implementations that include android.hardware.microphone are STRONGLY RECOMMENDED to meet
+these input audio requirements:</p>
+
+<ul>
+ <li>cold input latency of 100 milliseconds or less</li>
+ <li>continuous input latency of 30 milliseconds or less</li>
+ <li>continuous round-trip latency of 50 milliseconds or less</li>
+ <li>minimize the cold input jitter</li>
+</ul>
+
+<h2 id="5_7_network_protocols">5.7. Network Protocols</h2>
+
+
+<p>Devices MUST support the media network protocols for audio and video playback
+as specified in the Android SDK documentation [<a href="http://developer.android.com/guide/appendix/media-formats.html">Resources, 64</a>]. Specifically, devices MUST support the following media network protocols:</p>
+
+<ul>
+ <li>RTSP (RTP, SDP)</li>
+ <li>HTTP(S) progressive streaming</li>
+ <li>HTTP(S) Live Streaming draft protocol, Version 3 [<a href="http://tools.ietf.org/html/draft-pantos-http-live-streaming-03">Resources, 71</a>]</li>
+</ul>
+
+<h2 id="5_8_secure_media">5.8. Secure Media</h2>
+
+
+<p>Device implementations that support secure video output and are capable of
+supporting secure surfaces MUST declare support for Display.FLAG_SECURE. Device
+implementations that declare support for Display.FLAG_SECURE, if they support a
+wireless display protocol, MUST secure the link with a cryptographically strong
+mechanism such as HDCP 2.x or higher for Miracast wireless displays. Similarly
+if they support a wired external display, the device implementations MUST
+support HDCP 1.2 or higher. Android Television device implementations MUST
+support HDCP 2.2 for devices supporting 4K resolution and HDCP 1.4 or above for
+lower resolutions. The upstream Android open source implementation includes
+support for wireless (Miracast) and wired (HDMI) displays that satisfies this
+requirement.</p>
+
+<h2 id="5_9_midi">5.9. Musical Instrument Digital Interface (MIDI)</h2>
+
+<p>
+If a device implementation supports the inter-app MIDI software transport
+(virtual MIDI devices), and it supports MIDI over
+<em>all</em> of the following MIDI-capable hardware transports
+for which it provides generic non-MIDI connectivity, it is STRONGLY RECOMMENDED to report
+support for feature android.software.midi via the
+android.content.pm.PackageManager class
+[<a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">Resources, 70</a>].
+</p>
+
+<p>The MIDI-capable hardware transports are:</p>
+<ul>
+ <li>USB host mode (section 7.7 USB)</li>
+ <li>USB peripheral mode (section 7.7 USB)</li>
+</ul>
+
+<p>
+Conversely, if the device implementation provides generic non-MIDI connectivity over a particular
+MIDI-capable hardware transport listed above, but does not support MIDI over that hardware transport,
+it MUST NOT report support for feature android.software.midi.
+</p>
+
+<p>
+MIDI over Bluetooth LE acting in central role (section 7.4.3 Bluetooth)
+is in trial use status. A device implementation that reports
+feature android.software.midi, and which provides generic non-MIDI connectivity
+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 is STRONGLY RECOMMENDED to 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, 70</a>].
+</p>
+
+<ul>
+
+<li>
+The device implementation MUST report support for feature 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 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.
+</li>
+
+<li>
+If the device includes an HDMI port, the device implementation
+MUST support output in stereo and eight 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>
+
+<li>
+If the device includes a 4 conductor 3.5mm audio jack,
+the device implementation is STRONGLY RECOMMENDED to comply with section
+<a href="https://source.android.com/accessories/headset/specification.html#mobile_device_jack_specifications">Mobile device (jack) specifications</a>
+of the
+<a href="https://source.android.com/accessories/headset/specification.html">Wired Audio Headset Specification (v1.1)</a>.
+</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>
+
+<p>Device implementations MUST support the Android Developer Tools provided in the
+Android SDK. Android compatible devices MUST be compatible with:</p>
+
+<ul>
+ <li><strong>Android Debug Bridge (adb)</strong> [<a href="http://developer.android.com/tools/help/adb.html">Resources, 72</a>]</li>
+</ul>
+
+<p>Device implementations MUST support all adb functions as documented in the
+Android SDK including dumpsys [<a href="https://source.android.com/devices/input/diagnostics.html">Resources, 73</a>]. The device-side adb daemon MUST be inactive by default and there MUST be a
+user-accessible mechanism to turn on the Android Debug Bridge. If a device
+implementation omits USB peripheral mode, it MUST implement the Android Debug
+Bridge via local-area network (such as Ethernet or 802.11). </p>
+
+<p>Android includes support for secure adb. Secure adb enables adb on known
+authenticated hosts. Device implementations MUST support secure adb.</p>
+
+<ul>
+ <li><strong>Dalvik Debug Monitor Service (ddms)</strong> [<a href="http://developer.android.com/tools/debugging/ddms.html">Resources, 74</a>]</li>
+</ul>
+
+<p>Device implementations MUST support all ddms features as documented in the
+Android SDK. As ddms uses adb, support for ddms SHOULD be inactive by default,
+but MUST be supported whenever the user has activated the Android Debug Bridge,
+as above.</p>
+
+<ul>
+ <li><strong>Monkey</strong> [<a href="http://developer.android.com/tools/help/monkey.html">Resources, 75</a>]</li>
+</ul>
+
+<p>Device implementations MUST include the Monkey framework, and make it available
+for applications to use.</p>
+
+<ul>
+ <li><strong>SysTrace</strong> [<a href="http://developer.android.com/tools/help/systrace.html">Resources, 76</a>]</li>
+</ul>
+
+<p>Device implementations MUST support systrace tool as documented in the Android
+SDK. Systrace must be inactive by default, and there MUST be a user-accessible
+mechanism to turn on Systrace.</p>
+
+<p>Most Linux-based systems and Apple Macintosh systems recognize Android devices
+using the standard Android SDK tools, without additional support; however
+Microsoft Windows systems typically require a driver for new Android devices.
+(For instance, new vendor IDs and sometimes new device IDs require custom USB
+drivers for Windows systems.) If a device implementation is unrecognized by the
+adb tool as provided in the standard Android SDK, device implementers MUST
+provide Windows drivers allowing developers to connect to the device using the
+adb protocol. These drivers MUST be provided for Windows XP, Windows Vista,
+Windows 7, Windows 8 and Windows 10 in both 32-bit and 64-bit versions.
+</p>
+
+<h2 id="6_2_developer_options">6.2. Developer Options</h2>
+
+
+<p>Android includes support for developers to configure application
+development-related settings. Device implementations MUST honor the
+android.settings.APPLICATION_DEVELOPMENT_SETTINGS intent to show application
+development-related settings [<a href="http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS">Resources, 77</a>]. The upstream Android implementation hides the Developer Options menu by
+default and enables users to launch Developer Options after pressing seven (7)
+times on the <strong>Settings</strong> > <strong>About Device</strong> > <strong>Build Number</strong> menu item. Device implementations MUST provide a consistent experience for
+Developer Options. Specifically, device implementations MUST hide Developer
+Options by default and MUST provide a mechanism to enable Developer Options
+that is consistent with the upstream Android implementation.</p>
+
+<h1 id="7_hardware_compatibility">7. Hardware Compatibility</h1>
+
+
+<p>If a device includes a particular hardware component that has a corresponding
+API for third-party developers, the device implementation MUST implement that
+API as described in the Android SDK documentation. If an API in the SDK
+interacts with a hardware component that is stated to be optional and the
+device implementation does not possess that component:</p>
+
+<ul>
+ <li>Complete class definitions (as documented by the SDK) for the component APIs
+MUST still be presented.
+ <li>The API’s behaviors MUST be implemented as no-ops in some reasonable fashion.
+ <li>API methods MUST return null values where permitted by the SDK documentation.
+ <li>API methods MUST return no-op implementations of classes where null values are
+not permitted by the SDK documentation.
+ <li>API methods MUST NOT throw exceptions not documented by the SDK documentation.
+</ul>
+
+<p>A typical example of a scenario where these requirements apply is the telephony
+API: even on non-phone devices, these APIs must be implemented as reasonable
+no-ops.</p>
+
+<p>Device implementations MUST consistently report accurate hardware configuration
+information via the getSystemAvailableFeatures() and hasSystemFeature(String)
+methods on the android.content.pm.PackageManager class for the same build
+fingerprint. [<a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">Resources, 70</a>]</p>
+
+<h2 id="7_1_display_and_graphics">7.1. Display and Graphics</h2>
+
+
+<p>Android includes facilities that automatically adjust application assets and UI
+layouts appropriately for the device, to ensure that third-party applications
+run well on a variety of hardware configurations [<a href="http://developer.android.com/guide/practices/screens_support.html">Resources, 78</a>]. Devices MUST properly implement these APIs and behaviors, as detailed in
+this section.</p>
+
+<p>The units referenced by the requirements in this section are defined as
+follows:</p>
+
+<ul>
+ <li><strong>physical diagonal size</strong>. The distance in inches between two opposing corners of the illuminated portion
+of the display.</li>
+ <li><strong>dots per inch (dpi)</strong>. The number of pixels encompassed by a linear horizontal or vertical span of
+1”. Where dpi values are listed, both horizontal and vertical dpi must fall
+within the range.</li>
+ <li><strong>aspect ratio</strong>. The ratio of the pixels of the longer dimension
+ to the shorter dimension of the screen. For example, a display of 480x854 pixels
+ would be 854/480 = 1.779, or roughly “16:9”.</li>
+ <li><strong>density-independent pixel (dp)</strong> The virtual pixel unit normalized to a 160 dpi screen, calculated as: pixels =
+dps * (density/160).</li>
+</ul>
+
+<h3 id="7_1_1_screen_configuration">7.1.1. Screen Configuration</h3>
+
+
+<h4 id="7_1_1_1_screen_size">7.1.1.1. Screen Size</h4>
+
+<div class="note">
+<p>Android Watch devices (detailed in <a href="#2_device_types">section 2</a>) MAY have smaller screen sizes as described in this section.</p>
+</div>
+
+<p>The Android UI framework supports a variety of different screen sizes, and
+allows applications to query the device screen size (aka “screen layout") via
+android.content.res.Configuration.screenLayout with the SCREENLAYOUT_SIZE_MASK.
+Device implementations MUST report the correct screen size as defined in the
+Android SDK documentation [<a href="http://developer.android.com/guide/practices/screens_support.html">Resources, 78</a>] and determined by the upstream Android platform. Specifically, device
+implementations MUST report the correct screen size according to the following
+logical density-independent pixel (dp) screen dimensions.</p>
+
+<ul>
+ <li>Devices MUST have screen sizes of at least 426 dp x 320 dp (‘small’), unless it
+is an Android Watch device.</li>
+ <li>Devices that report screen size ‘normal’ MUST have screen sizes of at least 480
+dp x 320 dp.</li>
+ <li>Devices that report screen size ‘large’ MUST have screen sizes of at least 640
+dp x 480 dp.</li>
+ <li>Devices that report screen size ‘xlarge’ MUST have screen sizes of at least 960
+dp x 720 dp.</li>
+</ul>
+
+<p>In addition, </p>
+
+<ul>
+ <li>Android Watch devices MUST have a screen with the physical diagonal size in the
+range from 1.1 to 2.5 inches.</li>
+ <li>Other types of Android device implementations, with a physically integrated
+screen, MUST have a screen at least 2.5 inches in physical diagonal size.</li>
+</ul>
+
+<p>Devices MUST NOT change their reported screen size at any time.</p>
+
+<p>Applications optionally indicate which screen sizes they support via the
+<supports-screens> attribute in the AndroidManifest.xml file. Device
+implementations MUST correctly honor applications' stated support for small,
+normal, large, and xlarge screens, as described in the Android SDK
+documentation.</p>
+
+<h4 id="7_1_1_2_screen_aspect_ratio">7.1.1.2. Screen Aspect Ratio</h4>
+
+<div class="note">
+<p>Android Watch devices MAY have an aspect ratio of 1.0 (1:1).</p>
+</div>
+
+
+<p>The screen aspect ratio MUST be a value from 1.3333 (4:3) to 1.86 (roughly
+16:9), but Android Watch devices MAY have an aspect ratio of 1.0 (1:1) because
+such a device implementation will use a UI_MODE_TYPE_WATCH as the
+android.content.res.Configuration.uiMode.</p>
+
+<h4 id="7_1_1_3_screen_density">7.1.1.3. Screen Density</h4>
+
+
+<p>The Android UI framework defines a set of standard logical densities to help
+application developers target application resources. Device implementations
+MUST report only one of the following logical Android framework densities
+through the android.util.DisplayMetrics APIs, and MUST execute applications at
+this standard density and MUST NOT change the value at at any time for the
+default display.</p>
+
+<ul>
+ <li>120 dpi (ldpi)</li>
+ <li>160 dpi (mdpi)</li>
+ <li>213 dpi (tvdpi)</li>
+ <li>240 dpi (hdpi)</li>
+ <li>280 dpi (280dpi)</li>
+ <li>320 dpi (xhdpi)</li>
+ <li>360 dpi (360dpi)</li>
+ <li>400 dpi (400dpi)</li>
+ <li>420 dpi (420dpi)</li>
+ <li>480 dpi (xxhdpi)</li>
+ <li>560 dpi (560dpi)</li>
+ <li>640 dpi (xxxhdpi)</li>
+</ul>
+
+<p>Device implementations SHOULD define the standard Android framework density
+that is numerically closest to the physical density of the screen, unless that
+logical density pushes the reported screen size below the minimum supported. If
+the standard Android framework density that is numerically closest to the
+physical density results in a screen size that is smaller than the smallest
+supported compatible screen size (320 dp width), device implementations SHOULD
+report the next lowest standard Android framework density.</p>
+
+<h3 id="7_1_2_display_metrics">7.1.2. Display Metrics</h3>
+
+
+<p>Device implementations MUST report correct values for all display metrics
+defined in android.util.DisplayMetrics [<a href="http://developer.android.com/reference/android/util/DisplayMetrics.html">Resources, 79</a>] and MUST report the same values regardless of whether the embedded or
+external screen is used as the default display.</p>
+
+<h3 id="7_1_3_screen_orientation">7.1.3. Screen Orientation</h3>
+
+
+<p>Devices MUST report which screen orientations they support
+(android.hardware.screen.portrait and/or android.hardware.screen.landscape) and
+MUST report at least one supported orientation. For example, a device with a
+fixed orientation landscape screen, such as a television or laptop, SHOULD only
+report android.hardware.screen.landscape.</p>
+
+<p>Devices that report both screen orientations MUST support dynamic orientation
+by applications to either portrait or landscape screen orientation. That is,
+the device must respect the application’s request for a specific screen
+orientation. Device implementations MAY select either portrait or landscape
+orientation as the default.</p>
+
+<p>Devices MUST report the correct value for the device’s current orientation,
+whenever queried via the android.content.res.Configuration.orientation,
+android.view.Display.getOrientation(), or other APIs.</p>
+
+<p>Devices MUST NOT change the reported screen size or density when changing
+orientation.</p>
+
+<h3 id="7_1_4_2d_and_3d_graphics_acceleration">7.1.4. 2D and 3D Graphics Acceleration</h3>
+
+
+<p>Device implementations MUST support both OpenGL ES 1.0 and 2.0, as embodied and
+detailed in the Android SDK documentations. Device implementations SHOULD
+support OpenGL ES 3.0 or 3.1 on devices capable of supporting it. Device
+implementations MUST also support Android RenderScript, as detailed in the
+Android SDK documentation [<a href="http://developer.android.com/guide/topics/renderscript/">Resources, 80</a>].</p>
+
+<p>Device implementations MUST also correctly identify themselves as supporting
+OpenGL ES 1.0, OpenGL ES 2.0, OpenGL ES 3.0 or OpenGL 3.1. That is:</p>
+
+<ul>
+ <li>The managed APIs (such as via the GLES10.getString() method) MUST report support
+for OpenGL ES 1.0 and OpenGL ES 2.0.</li>
+ <li>The native C/C++ OpenGL APIs (APIs available to apps via libGLES_v1CM.so,
+libGLES_v2.so, or libEGL.so) MUST report support for OpenGL ES 1.0 and OpenGL
+ES 2.0.</li>
+ <li>Device implementations that declare support for OpenGL ES 3.0 or 3.1 MUST
+support the corresponding managed APIs and include support for native C/C++
+APIs. On device implementations that declare support for OpenGL ES 3.0 or 3.1,
+libGLESv2.so MUST export the corresponding function symbols in addition to the
+OpenGL ES 2.0 function symbols.</li>
+</ul>
+
+<p>In addition to OpenGL ES 3.1, Android provides an extension pack with Java
+interfaces [<a href="https://developer.android.com/reference/android/opengl/GLES31Ext.html">Resources, 81</a>] and native support for advanced graphics functionality such as tessellation
+and the ASTC texture compression format. Android device implementations MAY
+support this extension pack, and—only if fully implemented—MUST identify the
+support through the android.hardware.opengles.aep feature flag.</p>
+
+<p>Also, device implementations MAY implement any desired OpenGL ES extensions.
+However, device implementations MUST report via the OpenGL ES managed and
+native APIs all extension strings that they do support, and conversely MUST NOT
+report extension strings that they do not support.</p>
+
+<p>Note that Android includes support for applications to optionally specify that
+they require specific OpenGL texture compression formats. These formats are
+typically vendor-specific. Device implementations are not required by Android
+to implement any specific texture compression format. However, they SHOULD
+accurately report any texture compression formats that they do support, via the
+getString() method in the OpenGL API.</p>
+
+<p>Android includes a mechanism for applications to declare that they want to
+enable hardware acceleration for 2D graphics at the Application, Activity,
+Window, or View level through the use of a manifest tag
+android:hardwareAccelerated or direct API calls [<a href="http://developer.android.com/guide/topics/graphics/hardware-accel.html">Resources, 82</a>].</p>
+
+<p>Device implementations MUST enable hardware acceleration by default, and MUST
+disable hardware acceleration if the developer so requests by setting
+android:hardwareAccelerated="false” or disabling hardware acceleration directly
+through the Android View APIs.</p>
+
+<p>In addition, device implementations MUST exhibit behavior consistent with the
+Android SDK documentation on hardware acceleration [<a href="http://developer.android.com/guide/topics/graphics/hardware-accel.html">Resources, 82</a>].</p>
+
+<p>Android includes a TextureView object that lets developers directly integrate
+hardware-accelerated OpenGL ES textures as rendering targets in a UI hierarchy.
+Device implementations MUST support the TextureView API, and MUST exhibit
+consistent behavior with the upstream Android implementation.</p>
+
+<p>Android includes support for EGL_ANDROID_RECORDABLE, an EGLConfig attribute
+that indicates whether the EGLConfig supports rendering to an ANativeWindow
+that records images to a video. Device implementations MUST support
+EGL_ANDROID_RECORDABLE extension [<a href="https://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt">Resources, 83</a>].</p>
+
+<h3 id="7_1_5_legacy_application_compatibility_mode">7.1.5. Legacy Application Compatibility Mode</h3>
+
+
+<p>Android specifies a “compatibility mode” in which the framework operates in a
+'normal' screen size equivalent (320dp width) mode for the benefit of legacy
+applications not developed for old versions of Android that pre-date
+screen-size independence.</p>
+
+<ul>
+<li>Android Automotive does not support legacy compatibility mode.</li>
+<li>All other device implementations MUST include support for legacy application
+compatibility mode as implemented by the upstream Android open source code. That
+is, device implementations MUST NOT alter the triggers or thresholds at which
+compatibility mode is activated, and MUST NOT alter the behavior of the
+compatibility mode itself.</li>
+</ul>
+
+<h3 id="7_1_6_screen_technology">7.1.6. Screen Technology</h3>
+
+
+<p>The Android platform includes APIs that allow applications to render rich
+graphics to the display. Devices MUST support all of these APIs as defined by
+the Android SDK unless specifically allowed in this document. </p>
+
+<ul>
+ <li>Devices MUST support displays capable of rendering 16-bit color graphics and
+SHOULD support displays capable of 24-bit color graphics.</li>
+ <li>Devices MUST support displays capable of rendering animations.</li>
+ <li>The display technology used MUST have a pixel aspect ratio (PAR) between 0.9
+and 1.15. That is, the pixel aspect ratio MUST be near square (1.0) with a 10 ~
+15% tolerance.</li>
+</ul>
+
+<h3 id="7_1_7_external_displays">7.1.7. Secondary Displays</h3>
+
+
+<p>Android includes support for secondary display to enable media sharing
+capabilities and developer APIs for accessing external displays. If a device
+supports an external display either via a wired, wireless, or an embedded
+additional display connection then the device implementation MUST implement the
+display manager API as described in the Android SDK documentation [<a href="http://developer.android.com/reference/android/hardware/display/DisplayManager.html">Resources, 84</a>].</p>
+
+<h2 id="7_2_input_devices">7.2. Input Devices</h2>
+
+<p>Devices MUST support a touchscreen or meet the requirements listed in 7.2.2
+for non-touch navigation.</p>
+
+<h3 id="7_2_1_keyboard">7.2.1. Keyboard</h3>
+
+<div class="note">
+<p>Android Watch and Android Automotive implementations MAY implement a soft
+keyboard. All other device implementations MUST implement a soft keyboard and:</p>
+</div>
+
+
+<p>Device implementations:</p>
+
+<ul>
+ <li>MUST include support for the Input Management Framework (which allows
+third-party developers to create Input Method Editors—i.e. soft keyboard) as
+detailed at <a href="http://developer.android.com">http://developer.android.com</a>.</li>
+ <li>MUST provide at least one soft keyboard implementation (regardless of whether a
+hard keyboard is present) except for Android Watch devices where the screen
+size makes it less reasonable to have a soft keyboard.</li>
+ <li>MAY include additional soft keyboard implementations.</li>
+ <li>MAY include a hardware keyboard.</li>
+ <li>MUST NOT include a hardware keyboard that does not match one of the formats
+specified in android.content.res.Configuration.keyboard [<a href="http://developer.android.com/reference/android/content/res/Configuration.html">Resources, 85</a>] (QWERTY or 12-key).</li>
+</ul>
+
+<h3 id="7_2_2_non-touch_navigation">7.2.2. Non-touch Navigation</h3>
+
+<div class="note">
+<p>Android Television devices MUST support D-pad.</p>
+</div>
+
+<p>Device implementations:</p>
+
+<ul>
+ <li>MAY omit a non-touch navigation option (trackball, d-pad, or wheel) if the
+device implementation is not an Android Television device.</li>
+ <li>MUST report the correct value for android.content.res.Configuration.navigation
+[<a href="http://developer.android.com/reference/android/content/res/Configuration.html">Resources, 85</a>].</li>
+ <li>MUST provide a reasonable alternative user interface mechanism for the
+selection and editing of text, compatible with Input Management Engines. The
+upstream Android open source implementation includes a selection mechanism
+suitable for use with devices that lack non-touch navigation inputs.</li>
+</ul>
+
+<h3 id="7_2_3_navigation_keys">7.2.3. Navigation Keys</h3>
+
+<div class="note">
+<p>The availability and visibility requirement of the Home, Recents, and Back
+functions differ between device types as described in this section.</p>
+</div>
+
+<p>The Home, Recents, and Back functions (mapped to the key events KEYCODE_HOME,
+KEYCODE_APP_SWITCH, KEYCODE_BACK, respectively) are essential to the Android
+navigation paradigm and therefore:</p>
+
+<ul>
+ <li>Android Handheld device implementations MUST provide the Home, Recents, and
+Back functions.</li>
+ <li>Android Television device implementations MUST provide the Home and Back
+functions.</li>
+ <li>Android Watch device implementations MUST have the Home function available to
+the user, and the Back function except for when it is in UI_MODE_TYPE_WATCH.</li>
+ <li>Android Automotive implementations MUST provide the Home function and MAY
+provide Back and Recent functions.</li>
+ <li>All other types of device implementations MUST provide the Home and Back
+functions.</li>
+</ul>
+
+<p>These functions MAY be implemented via dedicated physical buttons (such as
+mechanical or capacitive touch buttons), or MAY be implemented using dedicated
+software keys on a distinct portion of the screen, gestures, touch panel, etc.
+Android supports both implementations. All of these functions MUST be
+accessible with a single action (e.g. tap, double-click or gesture) when
+visible.</p>
+
+<p>Recents function, if provided, MUST have a visible button or icon unless hidden
+together with other navigation functions in full-screen mode. This does not
+apply to devices upgrading from earlier Android versions that have physical
+buttons for navigation and no recents key.</p>
+
+<p> The Home and Back functions, if provided, MUST each have a visible button or
+icon unless hidden together with other navigation functions in full-screen mode
+or when the uiMode UI_MODE_TYPE_MASK is set to UI_MODE_TYPE_WATCH.</p>
+
+<p>The Menu function is deprecated in favor of action bar since Android 4.0.
+Therefore the new device implementations shipping with Android 6.0 and later MUST NOT
+implement a dedicated physical button for the Menu function. Older device
+implementations SHOULD NOT implement a dedicated physical button for the Menu
+function, but if the physical Menu button is implemented and the device is
+running applications with targetSdkVersion > 10, the device implementation:</p>
+
+<ul>
+ <li>MUST display the action overflow button on the action bar when it is visible
+and the resulting action overflow menu popup is not empty. For a device
+implementation launched before Android 4.4 but upgrading to Android 6.0, this
+is RECOMMENDED.</li>
+ <li>MUST NOT modify the position of the action overflow popup displayed by
+selecting the overflow button in the action bar.</li>
+ <li>MAY render the action overflow popup at a modified position on the screen when
+it is displayed by selecting the physical menu button.</li>
+</ul>
+
+<p>For backwards compatibility, device implementations MUST make the Menu function
+available to applications when targetSdkVersion is less than 10, either by a physical
+button, a software key, or gestures. This Menu function should be presented
+unless hidden together with other navigation functions.</p>
+
+<p>Android device implementations with the support of the Assist action [<a
+href="http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST">Resources,
+30</a>] MUST make this accessisble with a single action (e.g. tap, double-click,
+or gesture) when other navigation keys are visible, and are STRONGLY RECOMMENDED to
+use the long-press on the Home button or software key as the single action.</p>
+
+<p>Device implementations MAY use a distinct portion of the screen to display the
+navigation keys, but if so, MUST meet these requirements:</p>
+
+<ul>
+ <li>Device implementation navigation keys MUST use a distinct portion of the
+screen, not available to applications, and MUST NOT obscure or otherwise
+interfere with the portion of the screen available to applications.</li>
+ <li>Device implementations MUST make available a portion of the display to
+applications that meets the requirements defined in <a href="#7_1_1_screen_configuration">section 7.1.1</a>.</li>
+ <li>Device implementations MUST display the navigation keys when applications do
+not specify a system UI mode, or specify SYSTEM_UI_FLAG_VISIBLE.</li>
+ <li>Device implementations MUST present the navigation keys in an unobtrusive “low
+profile” (eg. dimmed) mode when applications specify
+SYSTEM_UI_FLAG_LOW_PROFILE.</li>
+ <li>Device implementations MUST hide the navigation keys when applications specify
+SYSTEM_UI_FLAG_HIDE_NAVIGATION.</li>
+</ul>
+
+<h3 id="7_2_4_touchscreen_input">7.2.4. Touchscreen Input</h3>
+
+<div class="note">
+<p>Android Handhelds and Watch Devices MUST support touchscreen input.</p>
+</div>
+
+
+<p>Device implementations SHOULD have a pointer input system of some kind (either
+mouse-like or touch). However, if a device implementation does not support a
+pointer input system, it MUST NOT report the android.hardware.touchscreen or
+android.hardware.faketouch feature constant. Device implementations that do
+include a pointer input system:</p>
+
+<ul>
+ <li>SHOULD support fully independently tracked pointers, if the device input system
+supports multiple pointers.</li>
+ <li>MUST report the value of android.content.res.Configuration.touchscreen [<a href="http://developer.android.com/reference/android/content/res/Configuration.html">Resources, 85</a>] corresponding to the type of the specific touchscreen on the device.</li>
+</ul>
+
+<p>Android includes support for a variety of touchscreens, touch pads, and fake
+touch input devices. Touchscreen based device implementations are associated
+with a display [<a href="http://source.android.com/devices/tech/input/touch-devices.html">Resources, 86</a>] such that the user has the impression of directly manipulating items on
+screen. Since the user is directly touching the screen, the system does not
+require any additional affordances to indicate the objects being manipulated.
+In contrast, a fake touch interface provides a user input system that
+approximates a subset of touchscreen capabilities. For example, a mouse or
+remote control that drives an on-screen cursor approximates touch, but requires
+the user to first point or focus then click. Numerous input devices like the
+mouse, trackpad, gyro-based air mouse, gyro-pointer, joystick, and multi-touch
+trackpad can support fake touch interactions. Android includes the feature
+constant android.hardware.faketouch, which corresponds to a high-fidelity
+non-touch (pointer-based) input device such as a mouse or trackpad that can
+adequately emulate touch-based input (including basic gesture support), and
+indicates that the device supports an emulated subset of touchscreen
+functionality. Device implementations that declare the fake touch feature MUST
+meet the fake touch requirements in <a href="#7_2_5_fake_touch_input">section 7.2.5</a>.</p>
+
+<p>Device implementations MUST report the correct feature corresponding to the
+type of input used. Device implementations that include a touchscreen
+(single-touch or better) MUST report the platform feature constant
+android.hardware.touchscreen. Device implementations that report the platform
+feature constant android.hardware.touchscreen MUST also report the platform
+feature constant android.hardware.faketouch. Device implementations that do not
+include a touchscreen (and rely on a pointer device only) MUST NOT report any
+touchscreen feature, and MUST report only android.hardware.faketouch if they
+meet the fake touch requirements in <a href="#7_2_5_fake_touch_input">section 7.2.5</a>.</p>
+
+<h3 id="7_2_5_fake_touch_input">7.2.5. Fake Touch Input</h3>
+
+
+<p>Device implementations that declare support for android.hardware.faketouch:</p>
+
+<ul>
+ <li>MUST report the absolute X and Y screen positions of the pointer location and
+display a visual pointer on the screen [<a href="http://developer.android.com/reference/android/view/MotionEvent.html">Resources, 87</a>].</li>
+ <li>MUST report touch event with the action code that specifies the state change
+that occurs on the pointer going down or up on the screen [<a href="http://developer.android.com/reference/android/view/MotionEvent.html">Resources, 87</a>].</li>
+ <li>MUST support pointer down and up on an object on the screen, which allows users
+to emulate tap on an object on the screen.</li>
+ <li>MUST support pointer down, pointer up, pointer down then pointer up in the same
+place on an object on the screen within a time threshold, which allows users to
+emulate double tap on an object on the screen [<a href="http://developer.android.com/reference/android/view/MotionEvent.html">Resources, 87</a>].</li>
+ <li>MUST support pointer down on an arbitrary point on the screen, pointer move to
+any other arbitrary point on the screen, followed by a pointer up, which allows
+users to emulate a touch drag.</li>
+ <li>MUST support pointer down then allow users to quickly move the object to a
+different position on the screen and then pointer up on the screen, which
+allows users to fling an object on the screen.</li>
+</ul>
+
+<p>Devices that declare support for android.hardware.faketouch.multitouch.distinct
+MUST meet the requirements for faketouch above, and MUST also support distinct
+tracking of two or more independent pointer inputs.</p>
+
+<h3 id="7_2_6_game_controller_support">7.2.6. Game Controller Support</h3>
+
+
+<p>Android Television device implementations MUST support button mappings for game
+controllers as listed below. The upstream Android implementation includes
+implementation for game controllers that satisfies this requirement. </p>
+
+<h4 id="7_2_6_1_button_mappings">7.2.6.1. Button Mappings</h4>
+
+
+<p>Android Television device implementations MUST support the following key
+mappings:</p>
+<table>
+ <tr>
+ <th>Button</th>
+ <th>HID Usage<sup>2</sup></th>
+ <th>Android Button</th>
+ </tr>
+ <tr>
+ <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_A">A</a><sup>1</sup></td>
+ <td>0x09 0x0001</td>
+ <td>KEYCODE_BUTTON_A (96)</td>
+ </tr>
+ <tr>
+ <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_B">B</a><sup>1</sup></td>
+ <td>0x09 0x0002</td>
+ <td>KEYCODE_BUTTON_B (97)</td>
+ </tr>
+ <tr>
+ <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_X">X</a><sup>1</sup></td>
+ <td>0x09 0x0004</td>
+ <td>KEYCODE_BUTTON_X (99)</td>
+ </tr>
+ <tr>
+ <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_Y">Y</a><sup>1</sup></td>
+ <td>0x09 0x0005</td>
+ <td>KEYCODE_BUTTON_Y (100)</td>
+ </tr>
+ <tr>
+ <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_DPAD_UP">D-pad up</a><sup>1</sup><br />
+
+<a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_DPAD_DOWN">D-pad down</a><sup>1</sup></td>
+ <td>0x01 0x0039<sup>3</sup></td>
+ <td><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_HAT_Y">AXIS_HAT_Y</a><sup>4</sup></td>
+ </tr>
+ <tr>
+ <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_DPAD_LEFT">D-pad left</a>1<br />
+
+<a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_DPAD_RIGHT">D-pad right</a><sup>1</sup></td>
+ <td>0x01 0x0039<sup>3</sup></td>
+ <td><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_HAT_X">AXIS_HAT_X</a><sup>4</sup></td>
+ </tr>
+ <tr>
+ <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_L1">Left shoulder button</a><sup>1</sup></td>
+ <td>0x09 0x0007</td>
+ <td>KEYCODE_BUTTON_L1 (102)</td>
+ </tr>
+ <tr>
+ <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_R1">Right shoulder button</a><sup>1</sup></td>
+ <td>0x09 0x0008</td>
+ <td>KEYCODE_BUTTON_R1 (103)</td>
+ </tr>
+ <tr>
+ <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_THUMBL">Left stick click</a><sup>1</sup></td>
+ <td>0x09 0x000E</td>
+ <td>KEYCODE_BUTTON_THUMBL (106)</td>
+ </tr>
+ <tr>
+ <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_THUMBR">Right stick click</a><sup>1</sup></td>
+ <td>0x09 0x000F</td>
+ <td>KEYCODE_BUTTON_THUMBR (107)</td>
+ </tr>
+ <tr>
+ <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_HOME">Home</a><sup>1</sup></td>
+ <td>0x0c 0x0223</td>
+ <td>KEYCODE_HOME (3)</td>
+ </tr>
+ <tr>
+ <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK">Back</a><sup>1</sup></td>
+ <td>0x0c 0x0224</td>
+ <td>KEYCODE_BACK (4)</td>
+ </tr>
+</table>
+
+
+<p class="table_footnote">1 [<a href="http://developer.android.com/reference/android/view/KeyEvent.html">Resources, 88</a>]</p>
+
+<p class="table_footnote">2 The above HID usages must be declared within a Game pad CA (0x01 0x0005).</p>
+
+<p class="table_footnote">3 This usage must have a Logical Minimum of 0, a Logical Maximum of 7, a
+Physical Minimum of 0, a Physical Maximum of 315, Units in Degrees, and a
+Report Size of 4. The logical value is defined to be the clockwise rotation
+away from the vertical axis; for example, a logical value of 0 represents no
+rotation and the up button being pressed, while a logical value of 1 represents
+a rotation of 45 degrees and both the up and left keys being pressed.</p>
+
+<p class="table_footnote">4 [<a href="http://developer.android.com/reference/android/view/MotionEvent.html">Resources, 87</a>]</p>
+
+<table>
+ <tr>
+ <th>Analog Controls<sup>1</sup></th>
+ <th>HID Usage</th>
+ <th>Android Button</th>
+ </tr>
+ <tr>
+ <td><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_LTRIGGER">Left Trigger</a></td>
+ <td>0x02 0x00C5</td>
+ <td>AXIS_LTRIGGER </td>
+ </tr>
+ <tr>
+ <td><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_THROTTLE">Right Trigger</a></td>
+ <td>0x02 0x00C4</td>
+ <td>AXIS_RTRIGGER </td>
+ </tr>
+ <tr>
+ <td><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_Y">Left Joystick</a></td>
+ <td>0x01 0x0030<br />
+
+0x01 0x0031</td>
+ <td>AXIS_X<br />
+
+AXIS_Y</td>
+ </tr>
+ <tr>
+ <td><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_Z">Right Joystick</a></td>
+ <td>0x01 0x0032<br />
+
+0x01 0x0035</td>
+ <td>AXIS_Z<br />
+
+AXIS_RZ</td>
+ </tr>
+</table>
+
+
+<p class="table_footnote">1 [<a href="http://developer.android.com/reference/android/view/MotionEvent.html">Resources, 87</a>]</p>
+
+<h3 id="7_2_7_remote_control">7.2.7. Remote Control</h3>
+
+
+<p>Android Television device implementations SHOULD provide a remote control to
+allow users to access the TV interface. The remote control MAY be a physical
+remote or can be a software-based remote that is accessible from a mobile phone
+or tablet. The remote control MUST meet the requirements defined below.</p>
+
+<ul>
+ <li><strong>Search affordance</strong>. Device implementations MUST fire KEYCODE_SEARCH when the user invokes voice search either on the physical or software-based remote.</li>
+ <li><strong>Navigation</strong>. All Android Television remotes MUST include Back, Home, and Select buttons and
+support for D-pad events [<a href="http://developer.android.com/reference/android/view/KeyEvent.html">Resources, 88</a>].</li>
+</ul>
+
+<h2 id="7_3_sensors">7.3. Sensors</h2>
+
+
+<p>Android includes APIs for accessing a variety of sensor types. Devices
+implementations generally MAY omit these sensors, as provided for in the
+following subsections. If a device includes a particular sensor type that has a
+corresponding API for third-party developers, the device implementation MUST
+implement that API as described in the Android SDK documentation and the
+Android Open Source documentation on sensors [<a href="http://source.android.com/devices/sensors/">Resources, 89</a>]. For example, device implementations:</p>
+
+<ul>
+ <li>MUST accurately report the presence or absence of sensors per the
+android.content.pm.PackageManager class [<a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">Resources, 70]</a>.</li>
+ <li>MUST return an accurate list of supported sensors via the
+SensorManager.getSensorList() and similar methods.</li>
+ <li>MUST behave reasonably for all other sensor APIs (for example, by returning
+true or false as appropriate when applications attempt to register listeners,
+not calling sensor listeners when the corresponding sensors are not present;
+etc.).</li>
+ <li>MUST report all sensor measurements using the relevant International System of
+Units (metric) values for each sensor type as defined in the Android SDK
+documentation [<a href="http://developer.android.com/reference/android/hardware/SensorEvent.html">Resources, 90</a>].</li>
+ <li>SHOULD report the event time in nanoseconds as defined in the Android SDK
+documentation, representing the time the event happened and synchronized with
+the SystemClock.elapsedRealtimeNano() clock. Existing and new Android devices
+are <strong>STRONGLY RECOMMENDED</strong> to meet these requirement so they will be able to upgrade to the future
+platform releases where this might become a REQUIRED component. The
+synchronization error SHOULD be below 100 milliseconds [<a href="http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp">Resources, 91</a>].</li>
+ <li>MUST report sensor data with a maximum latency of 100 milliseconds + 2 * sample_time for the case of a sensor streamed
+ with a minimum required latency of 5 ms + 2 * sample_time when the application processor is active. This delay does not include any filtering delays.</li>
+ <li>MUST report the first sensor sample within 400 milliseconds + 2 * sample_time of the sensor being activated. It is acceptable for this sample to have an accuracy of 0.</li>
+</ul>
+
+<p>The list above is not comprehensive; the documented behavior of the Android SDK
+and the Android Open Source Documentations on Sensors [<a href="http://source.android.com/devices/sensors/">Resources, 89</a>] is to be considered authoritative.</p>
+
+<p>Some sensor types are composite, meaning they can be derived from data provided
+by one or more other sensors. (Examples include the orientation sensor, and the
+linear acceleration sensor.) Device implementations SHOULD implement these
+sensor types, when they include the prerequisite physical sensors as described
+in [<a href="https://source.android.com/devices/sensors/sensor-types.html">Resources, 92</a>].
+If a device implementation includes a composite sensor it MUST implement the
+sensor as described in the Android Open Source documentation on composite
+sensors [<a href="https://source.android.com/devices/sensors/sensor-types.html#composite_sensor_type_summary">Resources, 92</a>].</p>
+
+<p>Some Android sensors support a “continuous” trigger mode, which returns data
+continuously [<a href="https://source.android.com/devices/sensors/report-modes.html#continuous">Resources, 93</a>]. For any API indicated by the Android SDK documentation to be a continuous
+sensor, device implementations MUST continuously provide periodic data samples
+that SHOULD have a jitter below 3%, where jitter is defined as the standard
+deviation of the difference of the reported timestamp values between
+consecutive events.</p>
+
+<p>Note that the device implementations MUST ensure that the sensor event stream
+MUST NOT prevent the device CPU from entering a suspend state or waking up from
+a suspend state.</p>
+
+<p>Finally, when several sensors are activated, the power consumption SHOULD NOT
+exceed the sum of the individual sensor’s reported power consumption.</p>
+
+<h3 id="7_3_1_accelerometer">7.3.1. Accelerometer</h3>
+
+
+<p>Device implementations SHOULD include a 3-axis accelerometer. Android Handheld
+devices and Android Watch devices are STRONGLY RECOMMENDED to include this
+sensor. If a device implementation does include a 3-axis accelerometer, it:</p>
+
+<ul>
+ <li>MUST implement and report TYPE_ACCELEROMETER sensor [<a href="http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER">Resources, 94</a>].</li>
+ <li>MUST be able to report events up to a frequency of at least 50 Hz for
+ Android Watch devices as such devices have a stricter power constraint and
+ 100 Hz for all other device types.</li>
+ <li>SHOULD report events up to at least 200 Hz.</li>
+ <li>MUST comply with the Android sensor coordinate system as detailed in the
+Android APIs [<a href="http://developer.android.com/reference/android/hardware/SensorEvent.html">Resources, 90</a>].</li>
+ <li>MUST be capable of measuring from freefall up to four times the gravity (4g) or
+more on any axis.</li>
+ <li>MUST have a resolution of at least 12-bits and SHOULD have a resolution of at
+least 16-bits.</li>
+ <li>SHOULD be calibrated while in use if the characteristics changes over the life
+cycle and compensated, and preserve the compensation parameters between device
+reboots.</li>
+ <li>SHOULD be temperature compensated.</li>
+ <li>MUST have a standard deviation no greater than 0.05 m/s^, where the standard
+deviation should be calculated on a per axis basis on samples collected over a
+period of at least 3 seconds at the fastest sampling rate.</li>
+ <li>SHOULD implement the TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR,
+TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER composite sensors as described in the
+Android SDK document. Existing and new Android devices are <strong>STRONGLY RECOMMENDED</strong> to implement the TYPE_SIGNIFICANT_MOTION composite sensor. If any of these
+sensors are implemented, the sum of their power consumption MUST always be less
+than 4 mW and SHOULD each be below 2 mW and 0.5 mW for when the device is in a
+dynamic or static condition.</li>
+ <li>If a gyroscope sensor is included, MUST implement the TYPE_GRAVITY and
+TYPE_LINEAR_ACCELERATION composite sensors and SHOULD implement the
+TYPE_GAME_ROTATION_VECTOR composite sensor. Existing and new Android devices
+are STRONGLY RECOMMENDED to implement the TYPE_GAME_ROTATION_VECTOR sensor.</li>
+ <li>MUST implement a TYPE_ROTATION_VECTOR composite sensor, if a gyroscope sensor
+and a magnetometer sensor is also included.</li>
+</ul>
+
+<h3 id="7_3_2_magnetometer">7.3.2. Magnetometer</h3>
+
+
+<p>Device implementations SHOULD include a 3-axis magnetometer (compass). If a
+device does include a 3-axis magnetometer, it:</p>
+
+<ul>
+ <li>MUST implement the TYPE_MAGNETIC_FIELD sensor and SHOULD also implement
+TYPE_MAGNETIC_FIELD_UNCALIBRATED sensor. Existing and new Android devices are
+STRONGLY RECOMMENDED to implement the TYPE_MAGNETIC_FIELD_UNCALIBRATED sensor.</li>
+ <li>MUST be able to report events up to a frequency of at least 10 Hz and SHOULD
+report events up to at least 50 Hz.</li>
+ <li>MUST comply with the Android sensor coordinate system as detailed in the
+Android APIs [<a href="http://developer.android.com/reference/android/hardware/SensorEvent.html">Resources, 90</a>].</li>
+ <li>MUST be capable of measuring between -900 µT and +900 µT on each axis before
+saturating.</li>
+ <li>MUST have a hard iron offset value less than 700 µT and SHOULD have a value
+below 200 µT, by placing the magnetometer far from dynamic (current-induced)
+and static (magnet-induced) magnetic fields.</li>
+ <li>MUST have a resolution equal or denser than 0.6 µT and SHOULD have a resolution
+equal or denser than 0.2 µ.</li>
+ <li>SHOULD be temperature compensated.</li>
+ <li>MUST support online calibration and compensation of the hard iron bias, and
+preserve the compensation parameters between device reboots.</li>
+ <li>MUST have the soft iron compensation applied—the calibration can be done either
+while in use or during the production of the device.</li>
+ <li>SHOULD have a standard deviation, calculated on a per axis basis on samples
+collected over a period of at least 3 seconds at the fastest sampling rate, no
+greater than 0.5 µT.</li>
+ <li>MUST implement a TYPE_ROTATION_VECTOR composite sensor, if an accelerometer
+sensor and a gyroscope sensor is also included.</li>
+ <li>MAY implement the TYPE_GEOMAGNETIC_ROTATION_VECTOR sensor if an accelerometer
+sensor is also implemented. However if implemented, it MUST consume less than
+10 mW and SHOULD consume less than 3 mW when the sensor is registered for batch
+mode at 10 Hz.</li>
+</ul>
+
+<h3 id="7_3_3_gps">7.3.3. GPS</h3>
+
+
+<p>Device implementations SHOULD include a GPS receiver. If a device
+implementation does include a GPS receiver, it SHOULD include some form of“assisted GPS” technique to minimize GPS lock-on time.</p>
+
+<h3 id="7_3_4_gyroscope">7.3.4. Gyroscope</h3>
+
+
+<p>Device implementations SHOULD include a gyroscope (angular change sensor).
+Devices SHOULD NOT include a gyroscope sensor unless a 3-axis accelerometer is
+also included. If a device implementation includes a gyroscope, it:</p>
+
+<ul>
+ <li>MUST implement the TYPE_GYROSCOPE sensor and SHOULD also implement
+TYPE_GYROSCOPE_UNCALIBRATED sensor. Existing and new Android devices are
+STRONGLY RECOMMENDED to implement the SENSOR_TYPE_GYROSCOPE_UNCALIBRATED sensor.</li>
+ <li>MUST be capable of measuring orientation changes up to 1,000 degrees per second.</li>
+ <li>MUST be able to report events up to a frequency of at least 50 Hz for
+ Android Watch devices as such devices have a stricter power constraint and
+ 100 Hz for all other device types.</li>
+ <li>SHOULD report events up to at least 200 Hz.</li>
+ <li>MUST have a resolution of 12-bits or more and SHOULD have a resolution of
+16-bits or more.</li>
+ <li>MUST be temperature compensated.</li>
+ <li>MUST be calibrated and compensated while in use, and preserve the compensation
+parameters between device reboots.</li>
+ <li>MUST have a variance no greater than 1e-7 rad^2 / s^2 per Hz (variance per Hz,
+or rad^2 / s). The variance is allowed to vary with the sampling rate, but must
+be constrained by this value. In other words, if you measure the variance of
+the gyro at 1 Hz sampling rate it should be no greater than 1e-7 rad^2/s^2.</li>
+ <li>MUST implement a TYPE_ROTATION_VECTOR composite sensor, if an accelerometer
+sensor and a magnetometer sensor is also included.</li>
+ <li>If an accelerometer sensor is included, MUST implement the TYPE_GRAVITY and
+TYPE_LINEAR_ACCELERATION composite sensors and SHOULD implement the
+TYPE_GAME_ROTATION_VECTOR composite sensor. Existing and new Android devices
+are STRONGLY RECOMMENDED to implement the TYPE_GAME_ROTATION_VECTOR sensor.</li>
+</ul>
+
+<h3 id="7_3_5_barometer">7.3.5. Barometer</h3>
+
+
+<p>Device implementations SHOULD include a barometer (ambient air pressure
+sensor). If a device implementation includes a barometer, it:</p>
+
+<ul>
+ <li>MUST implement and report TYPE_PRESSURE sensor.</li>
+ <li>MUST be able to deliver events at 5 Hz or greater.</li>
+ <li>MUST have adequate precision to enable estimating altitude.</li>
+ <li>MUST be temperature compensated.</li>
+</ul>
+
+<h3 id="7_3_6_thermometer">7.3.6. Thermometer</h3>
+
+
+<p>Device implementations MAY include an ambient thermometer (temperature sensor).
+If present, it MUST be defined as SENSOR_TYPE_AMBIENT_TEMPERATURE and it MUST
+measure the ambient (room) temperature in degrees Celsius.</p>
+
+<p>Device implementations MAY but SHOULD NOT include a CPU temperature sensor. If
+present, it MUST be defined as SENSOR_TYPE_TEMPERATURE, it MUST measure the
+temperature of the device CPU, and it MUST NOT measure any other temperature.
+Note the SENSOR_TYPE_TEMPERATURE sensor type was deprecated in Android 4.0.</p>
+
+<h3 id="7_3_7_photometer">7.3.7. Photometer</h3>
+
+
+<p>Device implementations MAY include a photometer (ambient light sensor).</p>
+
+<h3 id="7_3_8_proximity_sensor">7.3.8. Proximity Sensor</h3>
+
+
+<p>Device implementations MAY include a proximity sensor. Devices that can make a
+voice call and indicate any value other than PHONE_TYPE_NONE in getPhoneType
+SHOULD include a proximity sensor. If a device implementation does include a
+proximity sensor, it:</p>
+
+<ul>
+ <li>MUST measure the proximity of an object in the same direction as the screen.
+That is, the proximity sensor MUST be oriented to detect objects close to the
+screen, as the primary intent of this sensor type is to detect a phone in use
+by the user. If a device implementation includes a proximity sensor with any
+other orientation, it MUST NOT be accessible through this API.</li>
+ <li>MUST have 1-bit of accuracy or more.</li>
+</ul>
+
+
+<h3 id="7_3_9_hifi_sensors">7.3.9. High Fidelity Sensors</h3>
+
+<p>Device implementations supporting a set of higher quality sensors that can meet all
+the requirements listed in this section MUST identify the support through the
+<code>android.hardware.sensor.hifi_sensors</code> feature flag.</p>
+
+<p>A device declaring android.hardware.sensor.hifi_sensors MUST support all of the following
+sensor types meeting the quality requirements as below:</p>
+
+<ul>
+ <li>SENSOR_TYPE_ACCELEROMETER
+ <ul>
+ <li>MUST have a measurement range between at least -8g and +8g</li>
+ <li>MUST have a measurement resolution of at least 1024 LSB/G</li>
+ <li>MUST have a minimum measurement frequency of 12.5 Hz or lower</li>
+ <li>MUST have a maxmium measurement frequency of 200 Hz or higher</li>
+ <li>MUST have a measurement noise not above 400uG/√Hz</li>
+ <li>MUST implement a non-wake-up form of this sensor with a buffering capability of at least 3000 sensor events</li>
+ <li>MUST have a batching power consumption not worse than 3 mW</li>
+ </ul>
+ </li>
+ <li>SENSOR_TYPE_GYROSCOPE
+ <ul>
+ <li>MUST have a measurement range between at least -1000 and +1000 dps</li>
+ <li>MUST have a measurement resolution of at least 16 LSB/dps</li>
+ <li>MUST have a minimum measurement frequency of 12.5 Hz or lower</li>
+ <li>MUST have a maxmium measurement frequency of 200 Hz or higher</li>
+ <li>MUST have a measurement noise not above 0.014°/s/√Hz</li>
+ </ul>
+ </li>
+ <li>SENSOR_TYPE_GYROSCOPE_UNCALIBRATED with the same quality requirements as
+ SENSOR_TYPE_GYROSCOPE</li>
+ <li>SENSOR_TYPE_GEOMAGNETIC_FIELD
+ <ul>
+ <li>MUST have a measurement range between at least -900 and +900 uT</li>
+ <li>MUST have a measurement resolution of at least 5 LSB/uT</li>
+ <li>MUST have a minimum measurement frequency of 5 Hz or lower</li>
+ <li>MUST have a maxmium measurement frequency of 50 Hz or higher</li>
+ <li>MUST have a measurement noise not above 0.5 uT</li>
+ </ul>
+ </li>
+ <li>SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED with the same quality requirements as
+ SENSOR_TYPE_GEOMAGNETIC_FIELD and in addition:
+ <ul>
+ <li>MUST implement a non-wake-up form of this sensor with a buffering capability of at least 600 sensor events</li>
+ </ul>
+ </li>
+ <li>SENSOR_TYPE_PRESSURE
+ <ul>
+ <li>MUST have a measurement range between at least 300 and 1100 hPa</li>
+ <li>MUST have a measurement resolution of at least 80 LSB/hPa</li>
+ <li>MUST have a minimum measurement frequency of 1 Hz or lower</li>
+ <li>MUST have a maximum measurement frequency of 10 Hz or higher</li>
+ <li>MUST have a measurement noise not above 2 Pa/√Hz</li>
+ <li>MUST implement a non-wake-up form of this sensor with a buffering capability of at least 300 sensor events</li>
+ <li>MUST have a batching power consumption not worse than 2 mW</li>
+ </ul>
+ </li>
+ <li>SENSOR_TYPE_ROTATION_VECTOR
+ <ul>
+ <li>MUST have a batching power consumption not worse than 4 mW</li>
+ </ul>
+ </li>
+ <li>SENSOR_TYPE_GAME_ROTATION_VECTOR MUST implement a non-wake-up form of this sensor with a buffering capability of at least 300 sensor events</li>
+ <li>SENSOR_TYPE_SIGNIFICANT_MOTION
+ <ul>
+ <li>MUST have a power consumption not worse than 0.5 mW when device is static
+ and 1.5 mW when device is moving</li>
+ </ul>
+ </li>
+ <li>SENSOR_TYPE_STEP_DETECTOR
+ <ul>
+ <li>MUST implement a non-wake-up form of this sensor with a buffering capability of at least 100 sensor events</li>
+ <li>MUST have a power consumption not worse than 0.5 mW when device is static
+ and 1.5 mW when device is moving</li>
+ <li>MUST have a batching power consumption not worse than 4 mW</li>
+ </ul>
+ </li>
+ <li>SENSOR_TYPE_STEP_COUNTER
+ <ul>
+ <li>MUST have a power consumption not worse than 0.5 mW when device is static
+ and 1.5 mW when device is moving</li>
+ </ul>
+ </li>
+ <li>SENSOR_TILT_DETECTOR
+ <ul>
+ <li>MUST have a power consumption not worse than 0.5 mW when device is static
+ and 1.5 mW when device is moving</li>
+ </ul>
+ </li>
+</ul>
+
+<p>Also such a device MUST meet the following sensor subsystem requirements:</p>
+
+<ul>
+ <li>The event timestamp of the same physical event reported by the Accelerometer, Gyroscope
+ sensor and Magnetometer MUST be within 2.5 milliseconds of each other.</li>
+ <li>The Gyroscope sensor event timestamps MUST be on the same time base as the camera
+ subsystem and within 1 millisconds of error.</li>
+ <li>The latency of delivery of samples to the HAL SHOULD be below 5 milliseconds from
+ the instant the data is available on the physical sensor hardware.</li>
+ <li>The power consumption MUST not be higher than 0.5 mW when device is static and 2.0 mW
+ when device is moving when any combination of the following sensors are enabled:
+ <ul>
+ <li>SENSOR_TYPE_SIGNIFICANT_MOTION</li>
+ <li>SENSOR_TYPE_STEP_DETECTOR</li>
+ <li>SENSOR_TYPE_STEP_COUNTER</li>
+ <li>SENSOR_TILT_DETECTORS</li>
+ </ul>
+ </li>
+</ul>
+
+<p>Note that all power consumption requirements in this section do not include the power
+ consumption of the Application Processor. It is inclusive of the power drawn by the entire
+ sensor chain - the sensor, any supporting circuitry, any dedicated sensor processing system,
+ etc.</p>
+
+<p>The following sensor types MAY also be supported on a device implementation declaring
+ android.hardware.sensor.hifi_sensors, but if these sensor types are present they MUST meet the
+ following minimum buffering capability requirement:</p>
+
+<ul>
+ <li>SENSOR_TYPE_PROXIMITY: 100 sensor events</li>
+</ul>
+
+<h3 id="7_3_10_fingeprint">7.3.10. Fingerprint Sensor</h3>
+
+<p>Device implementations with a secure lock screen SHOULD include a fingerprint sensor.
+If a device implementation includes a fingerprint sensor and has a corresponding API for
+third-party developers, it:</p>
+
+<ul>
+ <li>MUST declare support for the android.hardware.fingerprint feature.</li>
+ <li>MUST fully implement the corresponding API as described in the Android SDK documentation
+[<a href="https://developer.android.com/reference/android/hardware/fingerprint/package-summary.html">Resources, 95</a>].
+ </li>
+ <li>MUST have a false acceptance rate not higher than 0.002%.</li>
+ <li>Is STRONGLY RECOMMENDED to have a false rejection rate not higher than 10%, and a
+ latency from when the fingerprint sensor is touched until the screen is unlocked below
+ 1 second, for 1 enrolled finger.</li>
+ <li>MUST rate limit attempts for at least 30 seconds after 5 false trials for fingerprint
+ verification.</li>
+ <li>MUST have a hardware-backed keystore implementation, and perform the fingerprint matching
+ in a Trusted Execution Environment (TEE) or on a chip with a secure channel to the TEE.
+ </li>
+ <li>MUST have all identifiable fingerprint data encrypted and cryptographically
+ authenticated such that they cannot be acquired, read or altered outside of the
+ Trusted Execution Environment (TEE) as documented in the implementation guidelines
+ on the Android Open Source Project site
+ [<a href="https://source.android.com/devices/tech/security/authentication/fingerprint-hal.html">Resources, 96</a>].
+ </li>
+ <li>MUST prevent adding a fingerprint without first establishing a chain of trust by
+ having the user confirm existing or add a new device credential (PIN/pattern/password)
+ using the TEE as implemented in the Android Open Source project.</li>
+ <li>MUST NOT enable 3rd-party applications to distinguish between individual fingerprints.
+ </li>
+ <li>MUST honor the DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT flag.</li>
+ <li>MUST, when upgraded from a version earlier than Android 6.0, have the fingerprint
+ data securely migrated to meet the above requirements or removed.</li>
+ <li>SHOULD use the Android Fingerprint icon provided in the Android Open Source Project.</li>
+</ul>
+
+<h2 id="7_4_data_connectivity">7.4. Data Connectivity</h2>
+
+
+<h3 id="7_4_1_telephony">7.4.1. Telephony</h3>
+
+
+<p>“Telephony” as used by the Android APIs and this document refers specifically
+to hardware related to placing voice calls and sending SMS messages via a GSM
+or CDMA network. While these voice calls may or may not be packet-switched,
+they are for the purposes of Android considered independent of any data
+connectivity that may be implemented using the same network. In other words,
+the Android “telephony” functionality and APIs refer specifically to voice
+calls and SMS. For instance, device implementations that cannot place calls or
+send/receive SMS messages MUST NOT report the android.hardware.telephony
+feature or any subfeatures, regardless of whether they use a cellular network
+for data connectivity.</p>
+
+<p>Android MAY be used on devices that do not include telephony hardware. That is,
+Android is compatible with devices that are not phones. However, if a device
+implementation does include GSM or CDMA telephony, it MUST implement full
+support for the API for that technology. Device implementations that do not
+include telephony hardware MUST implement the full APIs as no-ops.</p>
+
+<h3 id="7_4_2_ieee_802_11_wi-fi">7.4.2. IEEE 802.11 (Wi-Fi)</h3>
+
+<div class="note">
+<p>Android Television device implementations MUST include Wi-Fi support.</p>
+</div>
+
+
+<p>Android Television device implementations MUST include support for one or more
+forms of 802.11 (b/g/a/n, etc.) and other types of Android device
+implementation SHOULD include support for one or more forms of 802.11. If a
+device implementation does include support for 802.11 and exposes the
+functionality to a third-party application, it MUST implement the corresponding
+Android API and:</p>
+
+<ul>
+ <li>MUST report the hardware feature flag android.hardware.wifi.</li>
+ <li>MUST implement the multicast API as described in the SDK documentation [<a href="http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html">Resources, 97</a>].</li>
+ <li>MUST support multicast DNS (mDNS) and MUST NOT filter mDNS packets
+(224.0.0.251) at any time of operation including:
+ <ul>
+ <li>Even when the screen is not in an active state.</li>
+ <li>For Android Television device implementations, even when in standby power states.</li>
+ </ul>
+</ul>
+
+<h4 id="7_4_2_1_wi-fi_direct">7.4.2.1. Wi-Fi Direct</h4>
+
+
+<p>Device implementations SHOULD include support for Wi-Fi Direct (Wi-Fi
+peer-to-peer). If a device implementation does include support for Wi-Fi
+Direct, it MUST implement the corresponding Android API as described in the SDK
+documentation [<a href="http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html">Resources, 98</a>]. If a device implementation includes support for Wi-Fi Direct, then it:</p>
+
+<ul>
+ <li>MUST report the hardware feature android.hardware.wifi.direct.</li>
+ <li>MUST support regular Wi-Fi operation.</li>
+ <li>SHOULD support concurrent Wi-Fi and Wi-Fi Direct operation.</li>
+</ul>
+
+<h4 id="7_4_2_2_wi-fi_tunneled_direct_link_setup">7.4.2.2. Wi-Fi Tunneled Direct Link Setup</h4>
+
+<div class="note">
+<p>Android Television device implementations MUST include support for Wi-Fi
+Tunneled Direct Link Setup (TDLS).</p>
+</div>
+
+
+<p>Android Television device implementations MUST include support for Wi-Fi
+Tunneled Direct Link Setup (TDLS) and other types of Android device
+implementations SHOULD include support for Wi-Fi TDLS as described in the
+Android SDK Documentation [<a href="http://developer.android.com/reference/android/net/wifi/WifiManager.html">Resources, 99</a>]. If a device implementation does include support for TDLS and TDLS is enabled
+by the WiFiManager API, the device:</p>
+
+<ul>
+ <li>SHOULD use TDLS only when it is possible AND beneficial.</li>
+ <li>SHOULD have some heuristic and NOT use TDLS when its performance might be worse
+than going through the Wi-Fi access point.</li>
+</ul>
+
+<h3 id="7_4_3_bluetooth">7.4.3. Bluetooth</h3>
+
+<div class="note">
+<p>Android Watch and Automotive implementations MUST support Bluetooth. Android
+Television implementations MUST support Bluetooth and Bluetooth LE.</p>
+</div>
+
+
+<p>Android includes support for Bluetooth and Bluetooth Low Energy [<a href="http://developer.android.com/reference/android/bluetooth/package-summary.html">Resources, 100</a>]. Device implementations that include support for Bluetooth and Bluetooth Low
+Energy MUST declare the relevant platform features (android.hardware.bluetooth
+and android.hardware.bluetooth_le respectively) and implement the platform
+APIs. Device implementations SHOULD implement relevant Bluetooth profiles such
+as A2DP, AVCP, OBEX, etc. as appropriate for the device. Android Television
+device implementations MUST support Bluetooth and Bluetooth LE. </p>
+
+<p>Device implementations including support for Bluetooth Low Energy:</p>
+
+<ul>
+ <li>MUST declare the hardware feature android.hardware.bluetooth_le.</li>
+ <li>MUST enable the GATT (generic attribute profile) based Bluetooth APIs as
+described in the SDK documentation and [<a href="http://developer.android.com/reference/android/bluetooth/package-summary.html">Resources, 100</a>].</li>
+ <li>MUST implement a Resolvable Private Address (RPA) timeout no longer than
+15 minutes, and rotate the address at timeout to protect user privacy.</li>
+ <li>SHOULD support offloading of the filtering logic to the bluetooth chipset when
+implementing the ScanFilter API [<a href="https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html">Resources, 101</a>], and MUST report the correct value of where the filtering logic is implemented whenever queried via the
+android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported() method.</li>
+ <li>SHOULD support offloading of the batched scanning to the bluetooth chipset, but
+if not supported, MUST report ‘false’ whenever queried via the
+android.bluetooth.BluetoothAdapater.isOffloadedScanBatchingSupported() method.</li>
+ <li>SHOULD support multi advertisement with at least 4 slots, but if not supported,
+MUST report ‘false’ whenever queried via the
+android.bluetooth.BluetoothAdapter.isMultipleAdvertisementSupported() method.</li>
+</ul>
+
+<h3 id="7_4_4_near-field_communications">7.4.4. Near-Field Communications</h3>
+
+
+<p>Device implementations SHOULD include a transceiver and related hardware for
+Near-Field Communications (NFC). If a device implementation does include NFC
+hardware and plans to make it available to third-party apps, then it:</p>
+
+<ul>
+ <li>MUST report the android.hardware.nfc feature from the
+android.content.pm.PackageManager.hasSystemFeature() method [<a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">Resources, 70</a>].</li>
+ <li>MUST be capable of reading and writing NDEF messages via the following NFC
+standards:
+ <ul>
+ <li>MUST be capable of acting as an NFC Forum reader/writer (as defined by the NFC
+Forum technical specification NFCForum-TS-DigitalProtocol-1.0) via the
+following NFC standards:
+ <ul>
+ <li>NfcA (ISO14443-3A)</li>
+ <li>NfcB (ISO14443-3B)</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>STRONGLY RECOMMENDED to be capable of reading and writing NDEF messages as well
+ as raw data via the following NFC standards. Note that while the NFC standards
+ below are stated as STRONGLY RECOMMENDED, 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 very strongly encouraged to meet these
+ requirements now so they will be able to upgrade to the future platform releases.
+ <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, 102</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.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, 103</a>]</li>
+ <li>SNEP 1.0 (defined by the NFC Forum)</li>
+ </ul></li>
+ <li>MUST include support for Android Beam [<a href="http://developer.android.com/guide/topics/connectivity/nfc/nfc.html">Resources, 104</a>]:
+ <ul>
+ <li>MUST implement the SNEP default server. Valid NDEF messages received by the
+default SNEP server MUST be dispatched to applications using the
+android.nfc.ACTION_NDEF_DISCOVERED intent. Disabling Android Beam in settings
+MUST NOT disable dispatch of incoming NDEF message.</li>
+ <li>MUST honor the android.settings.NFCSHARING_SETTINGS intent to show NFC sharing
+settings [<a href="http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS">Resources, 105</a>].</li>
+ <li>MUST implement the NPP server. Messages received by the NPP server MUST be
+processed the same way as the SNEP default server.</li>
+ <li>MUST implement a SNEP client and attempt to send outbound P2P NDEF to the
+default SNEP server when Android Beam is enabled. If no default SNEP server is
+found then the client MUST attempt to send to an NPP server.</li>
+ <li>MUST allow foreground activities to set the outbound P2P NDEF message using
+android.nfc.NfcAdapter.setNdefPushMessage, and
+android.nfc.NfcAdapter.setNdefPushMessageCallback, and
+android.nfc.NfcAdapter.enableForegroundNdefPush.</li>
+ <li>SHOULD use a gesture or on-screen confirmation, such as 'Touch to Beam', before
+sending outbound P2P NDEF messages.</li>
+ <li>SHOULD enable Android Beam by default and MUST be able to send and receive
+using Android Beam, even when another proprietary NFC P2p mode is turned on.</li>
+ <li>MUST support NFC Connection handover to Bluetooth when the device supports
+Bluetooth Object Push Profile. Device implementations MUST support connection
+handover to Bluetooth when using android.nfc.NfcAdapter.setBeamPushUris, by
+implementing the “Connection Handover version 1.2” [<a href="http://members.nfc-forum.org/specs/spec_list/#conn_handover">Resources, 106</a>] and “Bluetooth Secure Simple Pairing Using NFC version 1.0” [<a href="http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf">Resources, 107</a>] specs from the NFC Forum. Such an implementation MUST implement the handover
+LLCP service with service name “urn:nfc:sn:handover” for exchanging the
+handover request/select records over NFC, and it MUST use the Bluetooth Object
+Push Profile for the actual Bluetooth data transfer. For legacy reasons (to
+remain compatible with Android 4.1 devices), the implementation SHOULD still
+accept SNEP GET requests for exchanging the handover request/select records
+over NFC. However an implementation itself SHOULD NOT send SNEP GET requests
+for performing connection handover.</li>
+ </ul></li>
+ <li>MUST poll for all supported technologies while in NFC discovery mode.</li>
+ <li>SHOULD be in NFC discovery mode while the device is awake with the screen
+active and the lock-screen unlocked.</li>
+</ul>
+</ul>
+
+<p>(Note that publicly available links are not available for the JIS, ISO, and NFC
+Forum specifications cited above.)</p>
+
+<p>Android includes support for NFC Host Card Emulation (HCE) mode. If a
+device implementation does include an NFC controller chipset capable of HCE and
+Application ID (AID) routing, then it:</p>
+
+<ul>
+ <li>MUST report the android.hardware.nfc.hce feature constant.</li>
+ <li>MUST support NFC HCE APIs as defined in the Android SDK [<a href="http://developer.android.com/guide/topics/connectivity/nfc/hce.html">Resources, 108</a>].</li>
+</ul>
+
+<p>Additionally, device implementations MAY include reader/writer support for the
+following MIFARE technologies.</p>
+
+<ul>
+ <li>MIFARE Classic</li>
+ <li>MIFARE Ultralight</li>
+ <li>NDEF on MIFARE Classic</li>
+</ul>
+
+<p>Note that Android includes APIs for these MIFARE types. If a device
+implementation supports MIFARE in the reader/writer role, it:</p>
+
+<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() method [<a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">Resources, 70</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>
+</ul>
+
+<p>If a device implementation does not include NFC hardware, it MUST NOT declare
+the android.hardware.nfc feature from the
+android.content.pm.PackageManager.hasSystemFeature() method [<a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">Resources, 70</a>], and MUST implement the Android NFC API as a no-op.</p>
+
+<p>As the classes android.nfc.NdefMessage and android.nfc.NdefRecord represent a
+protocol-independent data representation format, device implementations MUST
+implement these APIs even if they do not include support for NFC or declare the
+android.hardware.nfc feature.</p>
+
+<h3 id="7_4_5_minimum_network_capability">7.4.5. Minimum Network Capability</h3>
+
+
+<p>Device implementations MUST include support for one or more forms of data
+networking. Specifically, device implementations MUST include support for at
+least one data standard capable of 200Kbit/sec or greater. Examples of
+technologies that satisfy this requirement include EDGE, HSPA, EV-DO, 802.11g,
+Ethernet, Bluetooth PAN, etc.</p>
+
+<p>Device implementations where a physical networking standard (such as Ethernet)
+is the primary data connection SHOULD also include support for at least one
+common wireless data standard, such as 802.11 (Wi-Fi).</p>
+
+<p>Devices MAY implement more than one form of data connectivity.</p>
+
+<p>Devices MUST include an IPv6 networking stack and support IPv6 communication
+using the managed APIs, such as <code>java.net.Socket</code> and
+<code>java.net.URLConnection</code>, as well as the native APIs, such as
+<code>AF_INET6</code> sockets. The required level of IPv6 support depends on
+the network type, as follows:</p>
+<ul>
+ <li>Devices that support Wi-Fi networks MUST support dual-stack and IPv6-only
+ operation on Wi-Fi.</li>
+ <li>Devices that support Ethernet networks MUST support dual-stack operation
+ on Ethernet.</li>
+ <li>Devices that support cellular data SHOULD support IPv6 operation
+ (IPv6-only and possibly dual-stack) on cellular data.</li>
+ <li>When a device is simultaneously connected to more than one network (e.g.,
+ Wi-Fi and cellular data), it MUST simultaneously meet these requirements on
+ each network to which it is connected.</li>
+</ul>
+
+<p>IPv6 MUST be enabled by default.</p>
+
+<p>In order to ensure that IPv6 communication is as reliable as IPv4, unicast
+IPv6 packets sent to the device MUST NOT be dropped, even when the screen is
+not in an active state. Redundant multicast IPv6 packets, such as repeated
+identical Router Advertisements, MAY be rate-limited in hardware or firmware
+if doing so is necessary to save power. In such cases, rate-limiting MUST NOT
+cause the device to lose IPv6 connectivity on any IPv6-compliant network that
+uses RA lifetimes of at least 180 seconds.</p>
+
+<p>IPv6 connectivity MUST be maintained in doze mode.</p>
+
+<h3 id="7_4_6_sync_settings">7.4.6. Sync Settings</h3>
+
+
+<p>Device implementations MUST have the master auto-sync setting on by default so
+that the method getMasterSyncAutomatically() returns “true” [<a href="http://developer.android.com/reference/android/content/ContentResolver.html">Resources, 109</a>].</p>
+
+<h2 id="7_5_cameras">7.5. Cameras</h2>
+
+
+<p>Device implementations SHOULD include a rear-facing camera and MAY include a
+front-facing camera. A rear-facing camera is a camera located on the side of
+the device opposite the display; that is, it images scenes on the far side of
+the device, like a traditional camera. A front-facing camera is a camera
+located on the same side of the device as the display; that is, a camera
+typically used to image the user, such as for video conferencing and similar
+applications.</p>
+
+<p>If a device implementation includes at least one camera, it SHOULD be possible
+for an application to simultaneously allocate 3 bitmaps equal to the size of
+the images produced by the largest-resolution camera sensor on the device.</p>
+
+<h3 id="7_5_1_rear-facing_camera">7.5.1. Rear-Facing Camera</h3>
+
+
+<p>Device implementations SHOULD include a rear-facing camera. If a device
+implementation includes at least one rear-facing camera, it:</p>
+
+<ul>
+ <li>MUST report the feature flag android.hardware.camera and
+android.hardware.camera.any.</li>
+ <li>MUST have a resolution of at least 2 megapixels.</li>
+ <li>SHOULD have either hardware auto-focus or software auto-focus implemented in
+the camera driver (transparent to application software).</li>
+ <li>MAY have fixed-focus or EDOF (extended depth of field) hardware.</li>
+ <li>MAY include a flash. If the Camera includes a flash, the flash lamp MUST NOT be
+lit while an android.hardware.Camera.PreviewCallback instance has been
+registered on a Camera preview surface, unless the application has explicitly
+enabled the flash by enabling the FLASH_MODE_AUTO or FLASH_MODE_ON attributes
+of a Camera.Parameters object. Note that this constraint does not apply to the
+device’s built-in system camera application, but only to third-party
+applications using Camera.PreviewCallback.</li>
+</ul>
+
+<h3 id="7_5_2_front-facing_camera">7.5.2. Front-Facing Camera</h3>
+
+
+<p>Device implementations MAY include a front-facing camera. If a device
+implementation includes at least one front-facing camera, it:</p>
+
+<ul>
+ <li>MUST report the feature flag android.hardware.camera.any and
+android.hardware.camera.front.</li>
+ <li>MUST have a resolution of at least VGA (640x480 pixels).</li>
+ <li>MUST NOT use a front-facing camera as the default for the Camera API. The
+camera API in Android has specific support for front-facing cameras and device
+implementations MUST NOT configure the API to to treat a front-facing camera as
+the default rear-facing camera, even if it is the only camera on the device.</li>
+ <li>MAY include features (such as auto-focus, flash, etc.) available to rear-facing
+cameras as described in <a href="#7_5_1_rear-facing_camera">section 7.5.1</a>.</li>
+ <li>MUST horizontally reflect (i.e. mirror) the stream displayed by an app in a
+CameraPreview, as follows:
+ <ul>
+ <li>If the device implementation is capable of being rotated by user (such as
+automatically via an accelerometer or manually via user input), the camera
+preview MUST be mirrored horizontally relative to the device’s current
+orientation.</li>
+ <li>If the current application has explicitly requested that the Camera display be
+rotated via a call to the android.hardware.Camera.setDisplayOrientation()[<a href="http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)">Resources, 110</a>] method, the camera preview MUST be mirrored horizontally relative to the
+orientation specified by the application.</li>
+ <li>Otherwise, the preview MUST be mirrored along the device’s default horizontal
+axis.</li>
+ </ul></li>
+ <li>MUST mirror the image displayed by the postview in the same manner as the
+camera preview image stream. If the device implementation does not support
+postview, this requirement obviously does not apply.</li>
+ <li>MUST NOT mirror the final captured still image or video streams returned to
+application callbacks or committed to media storage.</li>
+</ul>
+
+<h3 id="7_5_3_external_camera">7.5.3. External Camera</h3>
+
+
+<p>Device implementations with USB host mode MAY include support for an external
+camera that connects to the USB port. If a device includes support for an
+external camera, it:</p>
+
+<ul>
+ <li>MUST declare the platform feature android.hardware.camera.external and
+android.hardware camera.any.</li>
+ <li>MUST support USB Video Class (UVC 1.0 or higher).</li>
+ <li>MAY support multiple cameras.</li>
+</ul>
+
+<p>Video compression (such as MJPEG) support is RECOMMENDED to enable transfer of
+high-quality unencoded streams (i.e. raw or independently compressed picture
+streams). Camera-based video encoding MAY be supported. If so, a simultaneous
+unencoded/ MJPEG stream (QVGA or greater resolution) MUST be accessible to the
+device implementation.</p>
+
+<h3 id="7_5_4_camera_api_behavior">7.5.4. Camera API Behavior</h3>
+
+
+<p>Android includes two API packages to access the camera, the newer
+android.hardware.camera2 API expose lower-level camera control to the app,
+including efficient zero-copy burst/streaming flows and per-frame controls of
+exposure, gain, white balance gains, color conversion, denoising, sharpening,
+and more.</p>
+
+<p>The older API package, android.hardware.Camera, is marked as deprecated in
+Android 5.0 but as it should still be available for apps to use Android device
+implementations MUST ensure the continued support of the API as described in
+this section and in the Android SDK.</p>
+
+<p>Device implementations MUST implement the following behaviors for the
+camera-related APIs, for all available cameras:</p>
+
+<ul>
+ <li>If an application has never called
+android.hardware.Camera.Parameters.setPreviewFormat(int), then the device MUST
+use android.hardware.PixelFormat.YCbCr_420_SP for preview data provided to
+application callbacks.</li>
+ <li>If an application registers an android.hardware.Camera.PreviewCallback instance
+and the system calls the onPreviewFrame() method when the preview format is
+YCbCr_420_SP, the data in the byte[] passed into onPreviewFrame() must further
+be in the NV21 encoding format. That is, NV21 MUST be the default.</li>
+ <li>For android.hardware.Camera, device implementations MUST support the YV12
+format (as denoted by the android.graphics.ImageFormat.YV12 constant) for
+camera previews for both front- and rear-facing cameras. (The hardware video
+encoder and camera may use any native pixel format, but the device
+implementation MUST support conversion to YV12.)</li>
+ <li>For android.hardware.camera2, device implementations must support the
+android.hardware.ImageFormat.YUV_420_888 and android.hardware.ImageFormat.JPEG
+formats as outputs through the android.media.ImageReader API.</li>
+</ul>
+
+<p>Device implementations MUST still implement the full Camera API included in the
+Android SDK documentation [<a href="http://developer.android.com/reference/android/hardware/Camera.html">Resources, 111</a>],
+regardless of whether the device includes hardware autofocus or other
+capabilities. For instance, cameras that lack autofocus MUST still call any
+registered android.hardware.Camera.AutoFocusCallback instances (even though
+this has no relevance to a non-autofocus camera.) Note that this does apply to
+front-facing cameras; for instance, even though most front-facing cameras do
+not support autofocus, the API callbacks must still be “faked” as described.</p>
+
+<p>Device implementations MUST recognize and honor each parameter name defined as
+a constant on the android.hardware.Camera.Parameters class, if the underlying
+hardware supports the feature. If the device hardware does not support a
+feature, the API must behave as documented. Conversely, device implementations
+MUST NOT honor or recognize string constants passed to the
+android.hardware.Camera.setParameters() method other than those documented as
+constants on the android.hardware.Camera.Parameters. That is, device
+implementations MUST support all standard Camera parameters if the hardware
+allows, and MUST NOT support custom Camera parameter types. For instance,
+device implementations that support image capture using high dynamic range
+(HDR) imaging techniques MUST support camera parameter Camera.SCENE_MODE_HDR [<a href="http://developer.android.com/reference/android/hardware/Camera.Parameters.html">Resources, 112</a>].</p>
+
+<p>Because not all device implementations can fully support all the features of
+the android.hardware.camera2 API, device implementations MUST report the proper
+level of support with the android.info.supportedHardwareLevel property as
+described in the Android SDK [<a href="https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL">Resources, 113</a>] and report the appropriate framework feature flags [<a href="http://source.android.com/devices/camera/versioning.html">Resources, 114</a>].</p>
+
+<p>Device implementations MUST also declare its Individual camera capabilities of
+android.hardware.camera2 via the android.request.availableCapabilities property
+and declare the appropriate feature flags [<a href="http://source.android.com/devices/camera/versioning.html">Resources, 114</a>]; a device must define the feature flag if any of its attached camera devices supports the feature.</p>
+
+<p>Device implementations MUST broadcast the Camera.ACTION_NEW_PICTURE intent
+whenever a new picture is taken by the camera and the entry of the picture has
+been added to the media store.</p>
+
+<p>Device implementations MUST broadcast the Camera.ACTION_NEW_VIDEO intent
+whenever a new video is recorded by the camera and the entry of the picture has
+been added to the media store.</p>
+
+<h3 id="7_5_5_camera_orientation">7.5.5. Camera Orientation</h3>
+
+
+<p>Both front- and rear-facing cameras, if present, MUST be oriented so that the
+long dimension of the camera aligns with the screen’s long dimension. That is,
+when the device is held in the landscape orientation, cameras MUST capture
+images in the landscape orientation. This applies regardless of the device’s
+natural orientation; that is, it applies to landscape-primary devices as well
+as portrait-primary devices.</p>
+
+<h2 id="7_6_memory_and_storage">7.6. Memory and Storage</h2>
+
+
+<h3 id="7_6_1_minimum_memory_and_storage">7.6.1. Minimum Memory and Storage</h3>
+
+<div class="note">
+<p>Android Television devices MUST have at least 5GB of non-volatile storage
+available for application private data.</p>
+</div>
+
+
+<p>The memory available to the kernel and userspace on device implementations MUST
+be at least equal or larger than the minimum values specified by the following
+table. (See <a href="#7_1_1_screen_configuration">section 7.1.1</a> for screen size and density definitions.)</p>
+<table>
+ <tr>
+ <th>Density and screen size</th>
+ <th>32-bit device</th>
+ <th>64-bit device</th>
+ </tr>
+ <tr>
+ <td>Android Watch devices (due to smaller screens)</td>
+ <td>416MB</td>
+ <td>Not applicable</td>
+ </tr>
+ <tr>
+ <td><ul>
+ <li class="table_list">280dpi or lower on small/normal screens</li>
+ <li class="table_list">mdpi or lower on large screens</li>
+ <li class="table_list">ldpi or lower on extra large screens</li>
+ </ul></td>
+ <td>424MB</td>
+ <td>704MB</td>
+ </tr>
+ <tr>
+ <td><ul>
+ <li class="table_list">xhdpi or higher on small/normal screens</li>
+ <li class="table_list">hdpi or higher on large screens</li>
+ <li class="table_list">mdpi or higher on extra large screens</li></ul></td>
+ <td>512MB</td>
+ <td>832MB</td>
+ </tr>
+ <tr>
+ <td><ul>
+ <li class="table_list">400dpi or higher on small/normal screens</li>
+ <li class="table_list">xhdpi or higher on large screens</li>
+ <li class="table_list">tvdpi or higher on extra large screens</li></ul></td>
+ <td>896MB</td>
+ <td>1280MB</td>
+ </tr>
+ <tr>
+ <td><ul>
+ <li class="table_list">560dpi or higher on small/normal screens</li>
+ <li class="table_list">400dpi or higher on large screens</li>
+ <li class="table_list">xhdpi or higher on extra large screens</li></ul></td>
+ <td>1344MB</td>
+ <td>1824MB</td>
+ </tr>
+</table>
+
+
+<p>The minimum memory values MUST be in addition to any memory space already
+dedicated to hardware components such as radio, video, and so on that is not
+under the kernel’s control.</p>
+
+<p>Device implementations with less than 512MB of memory available to the kernel
+and userspace, unless an Android Watch, MUST return the value "true" for
+ActivityManager.isLowRamDevice().</p>
+
+<p>Android Television devices MUST have at least 5GB and other device
+implementations MUST have at least 1.5GB of non-volatile storage available for
+application private data. That is, the /data partition MUST be at least 5GB for
+Android Television devices and at least 1.5GB for other device implementations.
+Device implementations that run Android are <strong>STRONGLY RECOMMENDED</strong> to have at least 3GB of non-volatile storage for application private data so
+they will be able to upgrade to the future platform releases.</p>
+
+<p>The Android APIs include a Download Manager that applications MAY use to
+download data files [<a href="http://developer.android.com/reference/android/app/DownloadManager.html">Resources, 115</a>]. The device implementation of the Download Manager MUST be capable of
+downloading individual files of at least 100MB in size to the default “cache"
+location.</p>
+
+<h3 id="7_6_2_application_shared_storage">7.6.2. Application Shared Storage</h3>
+
+
+<p>Device implementations MUST offer shared storage for applications also often
+referred as “shared external storage”. </p>
+
+<p>Device implementations MUST be configured with shared storage mounted by
+default, “out of the box”. If the shared storage is not mounted on the Linux
+path /sdcard, then the device MUST include a Linux symbolic link from /sdcard
+to the actual mount point.</p>
+
+<p>Device implementations MAY have hardware for user-accessible removable storage,
+such as a Secure Digital (SD) card slot. If this slot is used to satisfy the
+shared storage requirement, the device implementation:</p>
+
+<ul>
+ <li>MUST implement a toast or pop-up user interface warning the user when there is
+no SD card.</li>
+ <li>MUST include a FAT-formatted SD card 1GB in size or larger OR show on the box
+and other material available at time of purchase that the SD card has to be
+separately purchased.</li>
+ <li>MUST mount the SD card by default.</li>
+</ul>
+
+<p>Alternatively, device implementations MAY allocate internal (non-removable)
+storage as shared storage for apps as included in the upstream Android Open
+Source Project; device implementations SHOULD use this configuration and
+software implementation. If a device implementation uses internal
+(non-removable) storage to satisfy the shared storage requirement, that storage
+MUST be 1GB in size or larger and mounted on /sdcard (or /sdcard MUST be a
+symbolic link to the physical location if it is mounted elsewhere).</p>
+
+<p>Device implementations MUST enforce as documented the
+android.permission.WRITE_EXTERNAL_STORAGE permission on this shared storage.
+Shared storage MUST otherwise be writable by any application that obtains that
+permission.</p>
+
+<p>Device implementations that include multiple shared storage paths (such as both
+an SD card slot and shared internal storage) MUST NOT allow Android
+applications to write to the secondary external storage, except for their
+package-specific directories on the secondary external storage, but SHOULD
+expose content from both storage paths transparently through Android’s media
+scanner service and android.provider.MediaStore.</p>
+
+<p>Regardless of the form of shared storage used, if the device implementation
+has a USB port with USB peripheral mode support, it MUST provide some mechanism
+to access the contents of shared storage from a host computer. Device
+implementations MAY use USB mass storage, but SHOULD use Media Transfer Protocol
+to satisfy this requirement. If the device implementation supports Media
+Transfer Protocol, it:</p>
+
+<ul>
+ <li>SHOULD be compatible with the reference Android MTP host, Android File Transfer
+[<a href="http://www.android.com/filetransfer">Resources, 116</a>].</li>
+ <li>SHOULD report a USB device class of 0x00.</li>
+ <li>SHOULD report a USB interface name of 'MTP'.</li>
+</ul>
+
+<h3 id="7_6_3_adoptable_storage">7.6.3. Adoptable Storage</h3>
+
+<p>Device implementations are STRONGLY RECOMMENDED to implement adoptable
+storage if the removable storage device port is in a long-term stable location,
+such as within the battery compartment or other protective cover
+[<a
+href="http://source.android.com/devices/storage/adoptable.html">Resources,
+117</a>].</p>
+
+<p>Device implementations such as a television, MAY enable adoption through USB
+ports as the device is expected to be static and not mobile. But for other
+device implementations that are mobile in nature, it is STRONGLY RECOMMENDED to
+implement the adoptable storage in a long-term stable location, since accidentally
+disconnecting them can cause data loss/corruption.</p>
+
+<h2 id="7_7_usb">7.7. USB</h2>
+
+
+<p>Device implementations SHOULD support USB peripheral mode and SHOULD support
+USB host mode.</p>
+
+<p>If a device implementation includes a USB port supporting peripheral mode:</p>
+
+<ul>
+ <li>The port MUST be connectable to a USB host that has a standard type-A or type
+-C USB port.</li>
+ <li>The port SHOULD use micro-A, micro-AB or type-C USB form factor. Existing and
+new Android devices are <strong>STRONGLY RECOMMENDED to meet these requirements</strong> so they will be able to upgrade to the future platform releases.</li>
+ <li>The port SHOULD be centered in the middle of an edge. Device implementations
+SHOULD either locate the port on the bottom of the device (according to natural
+orientation) or enable software screen rotation for all apps (including home
+screen), so that the display draws correctly when the device is oriented with
+the port at bottom. Existing and new Android devices are <strong>STRONGLY RECOMMENDED to meet these requirements</strong> so they will be able to upgrade to future platform releases.</li>
+ <li>It MUST allow a USB host connected with the Android device to access the
+contents of the shared storage volume using either USB mass storage or Media
+Transfer Protocol.</li>
+ <li>It SHOULD implement the Android Open Accessory (AOA) API and specification as
+documented in the Android SDK documentation, and if it is an Android Handheld
+device it MUST implement the AOA API. Device implementations implementing the
+AOA specification:
+ <ul>
+ <li>MUST declare support for the hardware feature android.hardware.usb.accessory [<a href="http://developer.android.com/guide/topics/connectivity/usb/accessory.html">Resources, 118</a>].</li>
+ <li>MUST implement the USB audio class as documented in the Android SDK
+documentation [<a href="http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO">Resources, 119</a>].</li>
+ <li>And also the USB mass storage class, MUST include the string "android"
+at the end of the interface description <code>iInterface</code> string of the
+USB mass storage</li>
+ </ul>
+ </li>
+ <li>It SHOULD implement support to draw 1.5 A current during HS chirp and traffic
+as specified in the USB battery charging specification [<a href="http://www.usb.org/developers/docs/devclass_docs/USB_Battery_Charging_1.2.pdf">Resources, 120</a>]. Existing and new Android devices are <strong>STRONGLY RECOMMENDED to meet these requirements</strong> so they will be able to upgrade to the future platform releases.</li>
+ <li>The value of iSerialNumber in USB standard device descriptor MUST be equal to
+the value of android.os.Build.SERIAL.</li>
+</ul>
+
+<p>If a device implementation includes a USB port supporting host mode, it:</p>
+
+<ul>
+ <li>SHOULD use a type-C USB port, if the device implementation supports USB 3.1.</li>
+ <li>MAY use a non-standard port form factor, but if so MUST ship with a cable or
+cables adapting the port to a standard type-A or type-C USB port.</li>
+ <li>MAY use a micro-AB USB port, but if so SHOULD ship with a cable or cables
+adapting the port to a standard type-A or type-C USB port.</li>
+ <li>is <strong>STRONGLY RECOMMENDED</strong> to implement the USB audio class as documented in the Android SDK
+documentation [<a href="http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO">Resources, 119</a>].</li>
+ <li>MUST implement the Android USB host API as documented in the Android SDK, and
+MUST declare support for the hardware feature android.hardware.usb.host [<a href="http://developer.android.com/guide/topics/connectivity/usb/host.html">Resources, 121</a>].</li>
+ <li>SHOULD support the Charging Downstream Port output current range of 1.5 A ~ 5 A
+as specified in the USB Battery Charging Specifications [<a href="http://www.usb.org/developers/docs/devclass_docs/USB_Battery_Charging_1.2.pdf">Resources, 120</a>].</li>
+</ul>
+
+<h2 id="7_8_audio">7.8. Audio</h2>
+
+
+<h3 id="7_8_1_microphone">7.8.1. Microphone</h3>
+
+<div class="note">
+<p>Android Handheld, Watch, and Automotive implementations MUST include a
+microphone.</p>
+</div>
+
+
+<p>Device implementations MAY omit a microphone. However, if a device
+implementation omits a microphone, it MUST NOT report the
+android.hardware.microphone feature constant, and MUST implement the audio
+recording API at least as no-ops, per <a href="#7_hardware_compatibility">section 7</a>.
+Conversely, device implementations that do possess a microphone:</p>
+
+<ul>
+ <li>MUST report the android.hardware.microphone feature constant</li>
+ <li>MUST meet the audio recording requirements in <a href="#5_4_audio_recording">section 5.4</a></li>
+ <li>MUST meet the audio latency requirements in <a href="#5_6_audio_latency">section 5.6</a></li>
+ <li>STRONGLY RECOMMENDED to support near-ultrasound recording as described in
+ <a href="#7_8_3_near_ultrasound">section 7.8.3</a></li>
+</ul>
+
+<h3 id="7_8_2_audio_output">7.8.2. Audio Output</h3>
+
+<div class="note">
+<p>Android Watch devices MAY include an audio output.</p>
+</div>
+
+<p>Device implementations including a speaker or with an audio/multimedia output
+port for an audio output peripheral as a headset or an external speaker:</p>
+
+<ul>
+ <li>MUST report the android.hardware.audio.output feature constant.</li>
+ <li>MUST meet the audio playback requirements in <a href="#5_5_audio_playback">section 5.5</a>.</li>
+ <li>MUST meet the audio latency requirements in <a href="#5_6_audio_latency">section 5.6</a>.</li>
+ <li>STRONGLY RECOMMENDED to support near-ultrasound playback as described in
+ <a href="#7_8_3_near_ultrasound">section 7.8.3</a></li>
+</ul>
+
+<p>Conversely, if a device implementation does not include a speaker or audio
+output port, it MUST NOT report the android.hardware.audio output feature, and
+MUST implement the Audio Output related APIs as no-ops at least. </p>
+
+<p>Android Watch device implementation MAY but SHOULD NOT have audio output, but
+other types of Android device implementations MUST have an audio output and
+declare android.hardware.audio.output.</p>
+
+<h4 id="7_8_2_1_analog_audio_ports">7.8.2.1. Analog Audio Ports</h4>
+
+
+<p>In order to be compatible with the headsets and other audio accessories using
+the 3.5mm audio plug across the Android ecosystem [<a href="http://source.android.com/accessories/headset-spec.html">Resources, 122</a>], if a device implementation includes one or more analog audio ports, at least
+one of the audio port(s) SHOULD be a 4 conductor 3.5mm audio jack. If a device
+implementation has a 4 conductor 3.5mm audio jack, it:</p>
+
+<ul>
+ <li>MUST support audio playback to stereo headphones and stereo headsets with a
+microphone, and SHOULD support audio recording from stereo headsets with a
+microphone.</li>
+ <li>MUST support TRRS audio plugs with the CTIA pin-out order, and SHOULD support
+audio plugs with the OMTP pin-out order.</li>
+ <li>MUST support the detection of microphone on the plugged in audio accessory, if
+the device implementation supports a microphone, and broadcast the
+android.intent.action.HEADSET_PLUG with the extra value microphone set as 1.</li>
+ <li>SHOULD support the detection and mapping to the keycodes for the following 3
+ranges of equivalent impedance between the microphone and ground conductors on
+the audio plug:
+ <ul>
+ <li><strong>70 ohm or less</strong>: KEYCODE_HEADSETHOOK</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
+of equivalent impedance between the microphone and ground conductors on the
+audio plug:
+ <ul>
+ <li><strong>110-180 Ohm: </strong>KEYCODE_VOICE_ASSIST</li>
+ </ul></li>
+ <li>MUST trigger ACTION_HEADSET_PLUG upon a plug insert, but only after all
+contacts on plug are touching their relevant segments on the jack.</li>
+ <li>MUST be capable of driving at least 150mV ± 10% of output voltage on a 32 Ohm
+speaker impedance.</li>
+ <li>MUST have a microphone bias voltage between 1.8V ~ 2.9V.</li>
+</ul>
+
+<h3 id="7_8_3_near_ultrasound">7.8.3. Near-Ultrasound </h3>
+
+<p>Near-Ultrasound audio is the 18.5 kHz to 20 kHz band.
+Device implementations MUST correctly report the support
+of near-ultrasound audio capability via the
+<a href="http://developer.android.com/reference/android/media/AudioManager.html#getProperty(java.lang.String)">AudioManager.getProperty</a>
+API as follows:
+</p>
+
+<ul>
+ <li>If
+ <a href="http://developer.android.com/reference/android/media/AudioManager.html#PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND">PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND</a>
+ is "true", then
+ <ul>
+ <li>The microphone's mean power response in the 18.5 kHz to 20 kHz band MUST be no more than
+ 15 dB below the response at 2 kHz.</li>
+ <li>The signal to noise ratio of the microphone MUST be no lower than 80 dB.</li>
+ </ul>
+ </li>
+ <li>If
+ <a href="http://developer.android.com/reference/android/media/AudioManager.html#PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND">PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND</a>
+ is "true", then the speaker's mean response in 18.5 kHz - 20 kHz MUST be no lower than 40 dB
+ below the response at 2 kHz.
+ </li>
+</ul>
+
+<h1 id="8_performance_power">8. Performance and Power</h1>
+
+
+<p>Some minimum performance and power criteria are critical to the user experience
+and impact the baseline assumptions developers would have when developing an app.
+Android Watch devices SHOULD and other type of device implementations MUST meet
+the following criteria:</p>
+
+<h2 id="8_1_user_experience_consistency">8.1. User Experience Consistency</h2>
+
+
+<p>Device implementations MUST provide a smooth user interface by ensuring a
+consistent frame rate and response times for applications and games. Device
+implementations MUST meet the following requirements: </p>
+
+<ul>
+ <li><strong>Consistent frame latency</strong>. Inconsistent frame latency or a delay to render frames MUST NOT happen more
+often than 5 frames in a second, and SHOULD be below 1 frames in a second.</li>
+ <li><strong>User interface latency</strong>. Device implementations MUST ensure low latency user experience by scrolling a
+list of 10K list entries as defined by the Android Compatibility Test Suite
+(CTS) in less than 36 secs.</li>
+ <li><strong>Task switching</strong>. When multiple applications have been launched, re-launching an already-running
+application after it has been launched MUST take less than 1 second.</li>
+</ul>
+
+<h2 id="8_2_file_i_o_access_performance">8.2. File I/O Access Performance</h2>
+
+
+<p>Device implementations MUST ensure internal storage file access performance consistency for read
+and write operations. </p>
+
+<ul>
+ <li><strong>Sequential write</strong>. Device implementations MUST ensure a sequential write performance of at least 5MB/s
+for a 256MB file using 10MB write buffer.</li>
+ <li><strong>Random write</strong>. Device implementations MUST ensure a random write performance of at least 0.5MB/s for a
+256MB file using 4KB write buffer.</li>
+ <li><strong>Sequential read</strong>. Device implementations MUST ensure a sequential read performance of at least 15MB/s for
+a 256MB file using 10MB write buffer.</li>
+ <li><strong>Random read</strong>. Device implementations MUST ensure a random read performance of at least 3.5MB/s for a
+256MB file using 4KB write buffer.</li>
+</ul>
+
+<h2 id="8_3_power_saving_modes">8.3. Power-Saving Modes</h2>
+
+<p>All apps exempted from App Standby and/or Doze mode MUST be made visible to
+the end user. Further, the triggering, maintenance, wakeup algorithms and
+the use of Global system settings of these power-saving modes MUST not deviate
+from the Android Open Source Project.</p>
+
+<h2 id="8_4_power_consumption_accounting">8.4. Power Consumption Accounting</h2>
+
+<p>A more accurate accounting and reporting of the power consumption provides the
+app developer both the incentives and the tools to optimize the power usage pattern
+of the application. Therefore, device implementations:</p>
+
+<ul>
+ <li>MUST be able to track hardware component power usage and attribute that power
+ usage to specific applications. Specifically, implementations:
+ <ul>
+ <li>MUST provide a per-component power profile that defines the current consumption
+ value for each hardware component and the approximate battery drain caused by the
+ components over time as documented in the Android Open Source Project site [<a
+href="http://source.android.com/devices/tech/power/values.html">Resources, 123</a>].</li>
+ <li>MUST report all power consumption values in milliampere hours (mAh)</li>
+ <li>SHOULD be attributed to the hardware component itself if unable to
+ attribute hardware component power usage to an application.</li>
+ <li>MUST report CPU power consumption per each process's UID. The Android Open
+ Source Project meets the requirement through the <code>uid_cputime</code>
+ kernel module implementation.</li>
+ </ul>
+ </li>
+ <li>MUST make this power usage available via the <code>adb shell dumpsys
+ batterystats</code> shell command to the app developer [<a
+href="http://source.android.com/devices/tech/power/batterystats.html">Resources, 124</a>].</li>
+ <li>MUST honor the android.intent.action.POWER_USAGE_SUMMARY intent and display
+ a settings menu that shows this power usage [<a
+href="http://developer.android.com/reference/android/content/Intent.html#ACTION_POWER_USAGE_SUMMARY">Resources,
+125</a>].</li>
+</ul>
+
+<h1 id="9_security_model_compatibility">9. Security Model Compatibility</h1>
+
+
+<p>Device implementations MUST implement a security model consistent with the
+Android platform security model as defined in Security and Permissions
+reference document in the APIs [<a href="http://developer.android.com/guide/topics/security/permissions.html">Resources, 126</a>] in the Android developer documentation. Device implementations MUST support
+installation of self-signed applications without requiring any additional
+permissions/certificates from any third parties/authorities. Specifically,
+compatible devices MUST support the security mechanisms described in the follow
+subsections.</p>
+
+<h2 id="9_1_permissions">9.1. Permissions</h2>
+
+
+<p>Device implementations MUST support the Android permissions model as defined in
+the Android developer documentation [<a href="http://developer.android.com/guide/topics/security/permissions.html">Resources, 126</a>]. Specifically, implementations MUST enforce each permission defined as
+described in the SDK documentation; no permissions may be omitted, altered, or
+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. Device implementations:</p>
+
+<ul>
+<li>MUST show a dedicated interface for the user to decide whether to grant the
+requested runtime permissions and also provide an interface for the user to manage
+runtime permissions.</li>
+<li>MUST have one and only one implementation of both user interfaces.</li>
+<li>MUST NOT grant any runtime permissions to preinstalled apps unless:
+ <ul>
+ <li>the user's consent can be obtained before the application uses it</li>
+ <li>the runtime permissions are associated with an intent pattern for which the preinstalled
+ application is set as the default handler</li>
+ </ul>
+</li>
+</ul>
+
+<h2 id="9_2_uid_and_process_isolation">9.2. UID and Process Isolation</h2>
+
+
+<p>Device implementations MUST support the Android application sandbox model, in
+which each application runs as a unique Unixstyle UID and in a separate
+process. Device implementations MUST support running multiple applications as
+the same Linux user ID, provided that the applications are properly signed and
+constructed, as defined in the Security and Permissions reference [<a href="http://developer.android.com/guide/topics/security/permissions.html">Resources, 126</a>].</p>
+
+<h2 id="9_3_filesystem_permissions">9.3. Filesystem Permissions</h2>
+
+
+<p>Device implementations MUST support the Android file access permissions model
+as defined in the Security and Permissions reference [<a href="http://developer.android.com/guide/topics/security/permissions.html">Resources, 126</a>].</p>
+
+<h2 id="9_4_alternate_execution_environments">9.4. Alternate Execution Environments</h2>
+
+
+<p>Device implementations MAY include runtime environments that execute
+applications using some other software or technology than the Dalvik Executable
+Format or native code. However, such alternate execution environments MUST NOT
+compromise the Android security model or the security of installed Android
+applications, as described in this section.</p>
+
+<p>Alternate runtimes MUST themselves be Android applications, and abide by the
+standard Android security model, as described elsewhere in <a href="#9_security_model_compatibility">section 9</a>.</p>
+
+<p>Alternate runtimes MUST NOT be granted access to resources protected by
+permissions not requested in the runtime’s AndroidManifest.xml file via the
+<uses-permission> mechanism.</p>
+
+<p>Alternate runtimes MUST NOT permit applications to make use of features
+protected by Android permissions restricted to system applications.</p>
+
+<p>Alternate runtimes MUST abide by the Android sandbox model. Specifically,
+alternate runtimes:</p>
+
+<ul>
+ <li>SHOULD install apps via the PackageManager into separate Android sandboxes (
+Linux user IDs, etc.).</li>
+ <li>MAY provide a single Android sandbox shared by all applications using the
+alternate runtime.</li>
+ <li>and installed applications using an alternate runtime, MUST NOT reuse the
+sandbox of any other app installed on the device, except through the standard
+Android mechanisms of shared user ID and signing certificate.</li>
+ <li>MUST NOT launch with, grant, or be granted access to the sandboxes
+corresponding to other Android applications.</li>
+ <li>MUST NOT be launched with, be granted, or grant to other applications any
+privileges of the superuser (root), or of any other user ID.</li>
+</ul>
+
+<p>The .apk files of alternate runtimes MAY be included in the system image of a
+device implementation, but MUST be signed with a key distinct from the key used
+to sign other applications included with the device implementation.</p>
+
+<p>When installing applications, alternate runtimes MUST obtain user consent for
+the Android permissions used by the application. If an application needs to
+make use of a device resource for which there is a corresponding Android
+permission (such as Camera, GPS, etc.), the alternate runtime MUST inform the
+user that the application will be able to access that resource. If the runtime
+environment does not record application capabilities in this manner, the
+runtime environment MUST list all permissions held by the runtime itself when
+installing any application using that runtime.</p>
+
+<h2 id="9_5_multi-user_support">9.5. Multi-User Support</h2>
+
+<div class="note">
+<p>This feature is optional for all device types.</p>
+</div>
+
+
+<p>Android includes support for multiple users and provides support for full user
+isolation [<a href="http://developer.android.com/reference/android/os/UserManager.html">Resources, 127</a>]. Device implementations MAY enable multiple users, but when enabled MUST meet
+the following requirements related to multi-user support [<a href="http://source.android.com/devices/storage/traditional.html">Resources, 128</a>]:</p>
+
+<ul>
+ <li>Device implementations that do not declare the android.hardware.telephony
+feature flag MUST support restricted profiles, a feature that allows device
+owners to manage additional users and their capabilities on the device. With
+restricted profiles, device owners can quickly set up separate environments for
+additional users to work in, with the ability to manage finer-grained
+restrictions in the apps that are available in those environments.</li>
+ <li>Conversely device implementations that declare the android.hardware.telephony
+feature flag MUST NOT support restricted profiles but MUST align with the AOSP
+implementation of controls to enable /disable other users from accessing the
+voice calls and SMS.</li>
+ <li>Device implementations MUST, for each user, implement a security model
+consistent with the Android platform security model as defined in Security and
+Permissions reference document in the APIs [<a href="http://developer.android.com/guide/topics/security/permissions.html">Resources, 126</a>].</li>
+ <li>Each user instance on an Android device MUST have separate and isolated
+external storage directories. Device implementations MAY store multiple users'
+data on the same volume or filesystem. However, the device implementation MUST
+ensure that applications owned by and running on behalf a given user cannot
+list, read, or write to data owned by any other user. Note that removable
+media, such as SD card slots, can allow one user to access another’s data by
+means of a host PC. For this reason, device implementations that use removable
+media for the external storage APIs MUST encrypt the contents of the SD card if
+multiuser is enabled using a key stored only on non-removable media accessible
+only to the system. As this will make the media unreadable by a host PC, device
+implementations will be required to switch to MTP or a similar system to
+provide host PCs with access to the current user’s data. Accordingly, device
+implementations MAY but SHOULD NOT enable multi-user if they use removable
+media [<a href="http://developer.android.com/reference/android/os/Environment.html">Resources, 129</a>] for primary external storage.</li>
+</ul>
+
+<h2 id="9_6_premium_sms_warning">9.6. Premium SMS Warning</h2>
+
+
+<p>Android includes support for warning users of any outgoing premium SMS message
+[<a href="http://en.wikipedia.org/wiki/Short_code">Resources, 130</a>]. Premium SMS messages are text messages sent to a service registered with a
+carrier that may incur a charge to the user. Device implementations that
+declare support for android.hardware.telephony MUST warn users before sending a
+SMS message to numbers identified by regular expressions defined in
+/data/misc/sms/codes.xml file in the device. The upstream Android Open Source
+Project provides an implementation that satisfies this requirement.</p>
+
+<h2 id="9_7_kernel_security_features">9.7. Kernel Security Features</h2>
+
+
+<p>The Android Sandbox includes features that use the Security-Enhanced Linux
+(SELinux) mandatory access control (MAC) system and other security features in
+the Linux kernel. SELinux or any other security features implemented below
+the Android framework:</p>
+
+<ul>
+ <li>MUST maintain compatibility with existing applications.</li>
+ <li>MUST NOT have a visible user interface when a security violation is detected
+and successfully blocked, but MAY have a visible user interface when an
+unblocked security violation occurs resulting in a successful exploit.</li>
+ <li>SHOULD NOT be user or developer configurable.</li>
+</ul>
+
+<p>If any API for configuration of policy is exposed to an application that can
+affect another application (such as a Device Administration API), the API MUST
+NOT allow configurations that break compatibility.</p>
+
+<p>Devices MUST implement SELinux or, if using a kernel other than Linux, an
+equivalent mandatory access control system. Devices MUST also meet the
+following requirements, which are satisfied by the reference implementation
+in the upstream Android Open Source Project.</p>
+
+<p>Device implementations:</p>
+
+<ul>
+ <li>MUST set SELinux to global enforcing mode.</li>
+ <li>MUST configure all domains in enforcing mode. No permissive mode domains
+are allowed, including domains specific to a device/vendor.</li>
+ <li>MUST NOT modify, omit, or replace the neverallow rules present within the
+external/sepolicy folder provided in the upstream Android Open Source Project (AOSP) and
+the policy MUST compile with all neverallow rules present, for both AOSP SELinux
+domains as well as device/vendor specific domains.</li>
+</ul>
+
+<p>Device implementations SHOULD retain the default SELinux policy provided in the
+external/sepolicy folder of the upstream Android Open Source Project and only
+further add to this policy for their own device-specific configuration. Device
+implementations MUST be compatible with the upstream Android Open Source Project.
+</p>
+
+<h2 id="9_8_privacy">9.8. Privacy</h2>
+
+<p>If the device implements functionality in the system that captures the contents
+displayed on the screen and/or records the audio stream played on the device,
+it MUST continuously notify the user whenever this functionality is enabled and
+actively capturing/recording.</p>
+
+<p>If a device implementation has a mechanism that routes network data traffic
+through a proxy server or VPN gateway by default (for example, preloading a VPN
+service with android.permission.CONTROL_VPN granted), the device implementation
+MUST ask for the user's consent before enabling that mechanism.</p>
+
+<p>If a device implementation has a USB port with USB peripheral mode support,
+it MUST present a user interface asking for the user's consent before allowing
+access to the contents of the shared storage over the USB port.</p>
+
+<h2 id="9_9_full-disk_encryption">9.9. Full-Disk Encryption</h2>
+
+<div class="note">
+<p>Optional for Android device implementations without a lock screen.</p>
+</div>
+
+<p>If the device implementation supports a secure lock screen reporting "<code>true</code>"
+for KeyguardManager.isDeviceSecure()
+[<a href="http://developer.android.com/reference/android/app/KeyguardManager.html#isDeviceSecure()">Resources, 131</a>],
+and is not a device with restricted memory as reported through the
+ActivityManager.isLowRamDevice() method, then the device MUST support full-disk encryption
+[<a href="http://source.android.com/devices/tech/security/encryption/index.html">Resources, 132</a>]
+of the application private data (/data partition), as well as the application
+shared storage partition (/sdcard partition) if it is a permanent, non-removable
+part of the device.</p>
+
+<p>For device implementations supporting full-disk encryption and with Advanced
+Encryption Standard (AES) crypto performance above 50MiB/sec, the full-disk
+encryption MUST be enabled by default at the time the user has completed the out-of-box
+setup experience. If a device implementation is already launched on an earlier Android
+version with full-disk encryption disabled by default, such a device cannot
+meet the requirement through a system software update and thus MAY be exempted.</p>
+
+<p>Encryption MUST use AES with a key of 128-bits (or greater) and a mode designed
+for storage (for example, AES-XTS, AES-CBC-ESSIV). The encryption key MUST NOT
+be written to storage at any time without being encrypted. Other than when in
+active use, the encryption key SHOULD be AES encrypted with the lockscreen
+passcode stretched using a slow stretching algorithm (e.g. PBKDF2 or scrypt).
+If the user has not specified a lockscreen passcode or has disabled use of the
+passcode for encryption, the system SHOULD use a default passcode to wrap the
+encryption key. If the device provides a hardware-backed keystore, the password
+stretching algorithm MUST be cryptographically bound to that keystore. The
+encryption key MUST NOT be sent off the device (even when wrapped with the user
+passcode and/or hardware bound key). The upstream Android Open Source project
+provides a preferred implementation of this feature based on the Linux kernel
+feature dm-crypt.</p>
+
+<h2 id="9_10_verified_boot">9.10. Verified Boot</h2>
+
+<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>
+<li>Start verification from an immutable hardware key that is the root of trust,
+and go all the way up to the system partition</li>
+<li>Implement each stage of verification to check the integrity and authenticity
+of all the bytes in the next stage before executing the code in the next stage</li>
+<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>The upstream Android Open Source Project provides a preferred implementation of this
+feature based on the Linux kernel feature dm-verity.</p>
+
+<p>Starting from Android 6.0, device implementations with Advanced Encryption Standard (AES)
+crypto perfomance above 50MiB/seconds MUST support verified boot for device integrity.
+If a device implementation is already launched without supporting verified boot on an earlier
+version of Android, such a device can not add support for this feature with a system software
+update and thus are exempted from the requirement.</p>
+
+<h2 id="9_11_keys_and_credentials">9.11. Keys and Credentials</h2>
+
+<p>The Android Keystore System
+[<a href="https://developer.android.com/training/articles/keystore.html">Resources, 133</a>]
+allows app developers to store cryptographic keys in a container and use them in cryptographic
+operations through the KeyChain API
+[<a href="https://developer.android.com/reference/android/security/KeyChain.html">Resources, 134</a>]
+or the Keystore API
+ [<a href="https://developer.android.com/reference/java/security/KeyStore.html">Resources, 135</a>].
+</p>
+
+<p>All Android device implementations MUST meet the following requirements:</p>
+
+<ul>
+<li>SHOULD not limit the number of keys that can be generated, and MUST at least allow more
+than 8,192 keys to be imported.</li>
+<li>The lock screen authentication MUST rate limit attempts and SHOULD have an exponential
+ backoff algorithm as implemented in the Android Open Source Project.</li>
+<li>When the device implementation supports a secure lock screen and has a secure hardware
+ such as a Secure Element (SE) where a Trusted Execution Environment (TEE) can be implemented,
+ then it:
+ <ul>
+ <li>Is STRONGLY RECOMMENDED to back up the keystore implementation with the secure hardware.
+ The upstream Android Open Source Project provides the Keymaster Hardware Abstraction Layer
+ (HAL) implementation that can be used to satisfy this requirement.</li>
+ <li>MUST perform the lock screen authentication in the secure hardware if the device has a
+ hardware-backed keystore implementation and only when successful allow the authentication-bound
+ keys to be used. The upstream Android Open Source Project provides the Gatekeeper Hardware
+ Abstraction Layer (HAL) that can be used to satisfy this requirement
+ [<a href="http://source.android.com/devices/tech/security/authentication/gatekeeper.html">Resources, 136</a>].</li>
+ </ul>
+</li>
+</ul>
+
+<p>Note that while the above TEE-related requirements are stated as STRONGLY RECOMMENDED, the
+ Compatibility Definition for the next API version is planned to changed these to REQIUIRED. If a
+ device implementation is already launched on an earlier Android version and has not implemented a
+ trusted operating system on the secure hardware, such a device might not be able to meet the
+ requirements through a system software update and thus is STRONGLY RECOMMENDED to implement a
+ TEE.</p>
+
+<h2 id="9_12_data_deletion">9.12. Data Deletion</h2>
+
+<p>Devices MUST provide users with a mechanism to perform a "Factory Data Reset"
+that allows logical and physical deletion of all data. This MUST satisfy relevant
+industry standards for data deletion such as NIST SP800-88. This MUST be used for
+the implementation of the wipeData() API (part of the Android Device Administration API)
+described in <a href="#3_9_device_administration">section 3.9 Device Administration</a>.</p>
+
+<p>Devices MAY provide a fast data wipe that conducts a logical data erase.</p>
+
+<h1 id="10_software_compatibility_testing">10. Software Compatibility Testing</h1>
+
+
+<p>Device implementations MUST pass all tests described in this section.</p>
+
+<p>However, note that no software test package is fully comprehensive. For this
+reason, device implementers are <strong>STRONGLY RECOMMENDED</strong> to make the minimum number of changes as possible to the reference and
+preferred implementation of Android available from the Android Open Source
+Project. This will minimize the risk of introducing bugs that create
+incompatibilities requiring rework and potential device updates.</p>
+
+<h2 id="10_1_compatibility_test_suite">10.1. Compatibility Test Suite</h2>
+
+
+<p>Device implementations MUST pass the Android Compatibility Test Suite (CTS) [<a href="http://source.android.com/compatibility/index.html">Resources, 137</a>] available from the Android Open Source Project, using the final shipping
+software on the device. Additionally, device implementers SHOULD use the
+reference implementation in the Android Open Source tree as much as possible,
+and MUST ensure compatibility in cases of ambiguity in CTS and for any
+reimplementations of parts of the reference source code.</p>
+
+<p>The CTS is designed to be run on an actual device. Like any software, the CTS
+may itself contain bugs. The CTS will be versioned independently of this
+Compatibility Definition, and multiple revisions of the CTS may be released for
+Android 6.0. Device implementations MUST pass the latest CTS version available
+at the time the device software is completed.</p>
+
+<h2 id="10_2_cts_verifier">10.2. CTS Verifier</h2>
+
+
+<p>Device implementations MUST correctly execute all applicable cases in the CTS
+Verifier. The CTS Verifier is included with the Compatibility Test Suite, and
+is intended to be run by a human operator to test functionality that cannot be
+tested by an automated system, such as correct functioning of a camera and
+sensors.</p>
+
+<p>The CTS Verifier has tests for many kinds of hardware, including some hardware
+that is optional. Device implementations MUST pass all tests for hardware that
+they possess; for instance, if a device possesses an accelerometer, it MUST
+correctly execute the Accelerometer test case in the CTS Verifier. Test cases
+for features noted as optional by this Compatibility Definition Document MAY be
+skipped or omitted.</p>
+
+<p>Every device and every build MUST correctly run the CTS Verifier, as noted
+above. However, since many builds are very similar, device implementers are not
+expected to explicitly run the CTS Verifier on builds that differ only in
+trivial ways. Specifically, device implementations that differ from an
+implementation that has passed the CTS Verifier only by the set of included
+locales, branding, etc. MAY omit the CTS Verifier test.</p>
+
+<h1 id="11_updatable_software">11. Updatable Software</h1>
+
+
+<p>Device implementations MUST include a mechanism to replace the entirety of the
+system software. The mechanism need not perform “live” upgrades—that is, a
+device restart MAY be required.</p>
+
+<p>Any method can be used, provided that it can replace the entirety of the
+software preinstalled on the device. For instance, any of the following
+approaches will satisfy this requirement:</p>
+
+<ul>
+ <li>“Over-the-air (OTA)” downloads with offline update via reboot</li>
+ <li>“Tethered” updates over USB from a host PC</li>
+ <li>“Offline” updates via a reboot and update from a file on removable storage</li>
+</ul>
+
+<p>However, if the device implementation includes support for an unmetered data
+connection such as 802.11 or Bluetooth PAN (Personal Area Network) profile:</p>
+
+<ul>
+<li>Android Automotive implementations SHOULD support OTA downloads with offline
+update via reboot.</li>
+<li>All other device implementations MUST support OTA downloads with offline
+update via reboot.</li>
+</ul>
+
+<p>The update mechanism used MUST support updates without wiping user data. That
+is, the update mechanism MUST preserve application private data and application
+shared data. Note that the upstream Android software includes an update
+mechanism that satisfies this requirement.</p>
+
+<p>For device implementations that are launching with Android 6.0 and later, the
+update mechanism SHOULD support verifying that the system image is binary
+identical to expected result following an OTA. The block-based OTA
+implementation in the upstream Android Open Source Project, added since Android
+5.1, satisfies this requirement.</p>
+
+<p>If an error is found in a device implementation after it has been released but
+within its reasonable product lifetime that is determined in consultation with
+the Android Compatibility Team to affect the compatibility of third-party
+applications, the device implementer MUST correct the error via a software
+update available that can be applied per the mechanism just described.</p>
+
+<p>Android includes features that allow the Device Owner app (if present) to control the
+installation of system updates. To facilitate this, the system update subsystem
+for devices that report android.software.device_admin MUST implement the behavior
+described in the SystemUpdatePolicy class
+[<a href="http://developer.android.com/reference/android/app/admin/SystemUpdatePolicy.html">
+Resources, 138</a>].</p>
+
+<h1 id="12_document_changelog">12. Document Changelog</h1>
+
+<p>The following table contains a summary of the changes to the Compatibility
+Definition in this release.</p>
+<table>
+ <tr>
+ <th>Section</th>
+ <th>Summary of changes</th>
+ </tr>
+ <tr>
+ <td>Various</td>
+ <td>Replaced instances of the "encouraged" term with "RECOMMENDED"</td>
+ </tr>
+ <tr>
+ <td>2. Device Types</td>
+ <td>Update for Android Automotive implementations</td>
+ </tr>
+ <tr>
+ <td>3.2.2. Build Parameters</td>
+ <td>Additions for the hardware serial number and for the security patch level of a build</td>
+ </tr>
+ <tr>
+ <td>3.2.3.2. Intent Resolution</td>
+ <td>Section renamed from "Intent Overrides" to "Intent Resolution," with new requirements related to authoritative default app linking</td>
+ </tr>
+ <tr>
+ <td>3.3.1. Application Binary Interfaces</td>
+ <td>Additions for Android ABI support; change related to Vulkan library name</td>
+ </tr>
+ <tr>
+ <td>3.4.1. WebView Compatibility</td>
+ <td>Change for the user agent string reported by the WebView</td>
+ </tr>
+ <tr>
+ <td>3.7. Runtime Compatibility</td>
+ <td>Updates to memory allocation table</td>
+ </tr>
+ <tr>
+ <td>3.8.4. Search</td>
+ <td>Updates regarding Assistant requirements</td>
+ </tr>
+ <tr>
+ <td>3.8.6. Themes</td>
+ <td>Added requirement to support black system icons when requested by the SYSTEM_UI_FLAG_LIGHT_STATUS_BAR flag</td>
+ </tr>
+ <tr>
+ <td>3.9.1. Device Provisioning</td>
+ <td>Contains new sections for device owner provisioning and managed profile provisioning</td>
+ </tr>
+ <tr>
+ <td>3.9.2. Managed Profile Support</td>
+ <td>New section with requirements for device support of managed profile functionality</td>
+ </tr>
+<tr>
+ <td>3.12.1. TV App</td>
+ <td>Added section to clarify TV App requirements for Android Television devices</td>
+ </tr>
+ <tr>
+ <td>3.12.1.1. Electronic Program Guide</td>
+ <td>Added section to clarify EPG requirements for Android Television devices</td>
+ </tr>
+ <tr>
+ <td>3.12.1.2. Navigation</td>
+ <td>Added section to clarify TV App navigation requirements for Android Television devices</td>
+ </tr>
+ <td>3.12.1.3. TV input app linking</td>
+ <td>Added section to clarify TV input app linking support requirements for Android Television devices</td>
+ </tr>
+ <tr>
+ <td>5.1. Media Codecs</td>
+ <td>Updates regarding support for core media formats and decoding.</td>
+ </tr>
+ <tr>
+ <td>5.1.3. Video Codecs</td>
+ <td>Changes and additions related to Android Televisions</td>
+ </tr>
+ <tr>
+ <td>5.2. Video Encoding</td>
+ <td>Changes for encoders</td>
+ </tr>
+ <tr>
+ <td>5.3. Video Decoding</td>
+ <td>Changes for decoders, including regarding support for dynamic video resolution, frame rate
+switching, and more</td>
+ </tr>
+ <tr>
+ <td>5.4. Audio Recording</td>
+ <td>Additions related to audio capture</td>
+ </tr>
+ <tr>
+ <td>5.6. Audio Latency</td>
+ <td>Update regarding reporting of support for low-latency audio</td>
+ </tr>
+ <tr>
+ <td>5.10. Professional Audio</td>
+ <td>General updates for professional audio support; updates for mobile device (jack) specifications, USB audio host mode, and other updates</td>
+ </tr>
+ <tr>
+ <td>5.9. Musical Instrument Digital Interface (MIDI)</td>
+ <td>Added new section on optional Musical Instrument Digital Interface (MIDI) support</td>
+ </tr>
+<tr>
+ <td>6.1. Developer Tools</td>
+ <td>Update for drivers supporting Windows 10</td>
+ </tr>
+ <tr>
+ <td>7.1.1.3. Screen Density</td>
+ <td>Updates for screen density, for example related to an Android watch</td>
+ </tr>
+ <tr>
+ <td>7.2.3. Navigation Keys</td>
+ <td>Updated requirements for device implementations that include the Assist action</td>
+ </tr>
+ <tr>
+ <td>7.3. Sensors (and subsections)</td>
+ <td>New requirements for some sensor types</td>
+ </tr>
+ <tr>
+ <td>7.3.9. High Fidelity Sensors</td>
+ <td>New section with requirements for devices supporting high fidelity sensors</td>
+ </tr>
+ <tr>
+ <td>7.3.10. Fingerprint Sensor</td>
+ <td>New section on requirements related to fingerprint sensors</td>
+ </tr>
+ <tr>
+ <td>7.4.2. IEEE 802.11 (Wi-Fi)</td>
+ <td>Updates regarding support for multicast DNS (mDNS)</td>
+ </tr>
+ <tr>
+ <td>7.4.3. Bluetooth</td>
+ <td>Addition related to Resolvable Private Address (RPA) for Bluetooth Low Energy (BLE)</td>
+ </tr>
+ <tr>
+ <td>7.4.4. Near-Field Communications</td>
+ <td>Additions to requirements for Near-Field Communications (NFC)</td>
+ </tr>
+ <tr>
+ <td>7.4.5. Minimum Network Capability</td>
+ <td>Added requirements for IPv6 support</td>
+ </tr>
+ <tr>
+ <td>7.6.3. Adoptable Storage</td>
+ <td>New section for implementation of adoptable storage</td>
+ </tr>
+ <tr>
+ <td>7.7. USB</td>
+ <td>Requirement related to implementing the AOA specification</td>
+ </tr>
+ <tr>
+ <td>7.8.3. Near-Ultrasound</td>
+ <td>Additions related to near-ultrasound recording, playback, and audio</td>
+ </tr>
+ <tr>
+ <td>8.3. Power-Saving Modes</td>
+ <td>New section with requirements regarding the App Standby and Doze modes</td>
+ </tr>
+<tr>
+ <td>8.4. Power Consumption Accounting</td>
+ <td>New section with requirements for tracking hardware component power usage and attributing that power usage to specific applications</td>
+ </tr>
+ <tr>
+ <td>9.1. Permissions</td>
+ <td>Addition to Permissions requirements</td>
+ </tr>
+<tr>
+ <td>9.7. Kernel Security Features</td>
+ <td>SE Linux updates</td>
+ </tr>
+<tr>
+ <td>9.8. Privacy</td>
+ <td>Addition regarding user's consent for access to shared storage over a USB port</td>
+ </tr>
+ <tr>
+ <td>9.9. Full-Disk Encryption</td>
+ <td>Requirements related to full disk encryption</td>
+ </tr>
+ <tr>
+ <td>9.10. Verified Boot</td>
+ <td>Additional requirement for verified boot</td>
+ </tr>
+ <tr>
+ <td>9.11. Keys and Credentials</td>
+ <td>New section of requirements related to keys and credentials</td>
+ </tr>
+ <tr>
+ <td>9.12. Data Deletion</td>
+ <td>New section for "Factory Data Reset"</td>
+ </tr>
+ <tr>
+ <td>11. Updatable Software</td>
+ <td>Requirement related to the system update policy set by the device owner</td>
+ </tr>
+ </table>
+
+
+<h1 id="13_contact_us">13. Contact Us</h1>
+
+
+<p>You can join the android-compatibility forum <a href="https://groups.google.com/forum/#!forum/android-compatibility">[Resources, 139</a>] and ask for clarifications or bring up any issues that you think the document
+does not cover.</p>
+
+<h1 id="14_resources">14. Resources</h1>
+
+<p>1. IETF RFC2119 Requirement Levels: <a href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a></p>
+
+<p>2. Android Open Source Project: <a href="http://source.android.com/">http://source.android.com/</a></p>
+
+<p>3. Android Television features: <a href="http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK">http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK</a></p>
+
+<p>4. Android Watch feature: <a href="http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_WATCH">http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_WATCH</a></p>
+
+<p>5. Android UI_MODE_TYPE_CAR API: <a href="http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR">http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR</a></p>
+
+<p>6. API definitions and documentation: <a href="http://developer.android.com/reference/packages.html">http://developer.android.com/reference/packages.html</a></p>
+
+<p>7. Android Permissions reference: <a href="http://developer.android.com/reference/android/Manifest.permission.html">http://developer.android.com/reference/android/Manifest.permission.html</a></p>
+
+<p>8. android.os.Build reference: <a href="http://developer.android.com/reference/android/os/Build.html">http://developer.android.com/reference/android/os/Build.html</a></p>
+
+<p>9. Android 6.0 allowed version strings: <a href="http://source.android.com/compatibility/6.0/versions.html">http://source.android.com/compatibility/6.0/versions.html</a></p>
+
+<p>10. Android Developer Settings: <a href="http://developer.android.com/reference/android/provider/Settings.html">http://developer.android.com/reference/android/provider/Settings.html</a></p>
+
+<p>11. Telephony Provider: <a href="http://developer.android.com/reference/android/provider/Telephony.html">http://developer.android.com/reference/android/provider/Telephony.html</a></p>
+
+<p>12. Android NDK ABI Management: <a href="https://developer.android.com/ndk/guides/abis.html">https://developer.android.com/ndk/guides/abis.html</a></p>
+
+<p>13. Advanced SIMD architecture: <a href="http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/Beijfcja.html">http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/Beijfcja.html</a></p>
+
+<p>14. Android Extension Pack: <a href="http://developer.android.com/guide/topics/graphics/opengl.html#aep">http://developer.android.com/guide/topics/graphics/opengl.html#aep</a></p>
+
+<p>15. android.webkit.WebView class: <a href="http://developer.android.com/reference/android/webkit/WebView.html">http://developer.android.com/reference/android/webkit/WebView.html</a></p>
+
+<p>16. WebView compatibility: <a href="http://www.chromium.org/">http://www.chromium.org/</a></p>
+
+<p>17. HTML5: <a href="http://html.spec.whatwg.org/multipage/">http://html.spec.whatwg.org/multipage/</a></p>
+
+<p>18. HTML5 offline capabilities:<a href="http://dev.w3.org/html5/spec/Overview.html#offline"> http://dev.w3.org/html5/spec/Overview.html#offline</a></p>
+
+<p>19. HTML5 video tag: <a href="http://dev.w3.org/html5/spec/Overview.html#video">http://dev.w3.org/html5/spec/Overview.html#video</a></p>
+
+<p>20. HTML5/W3C geolocation API: <a href="http://www.w3.org/TR/geolocation-API/">http://www.w3.org/TR/geolocation-API/</a></p>
+
+<p>21. HTML5/W3C webstorage API: <a href="http://www.w3.org/TR/webstorage/">http://www.w3.org/TR/webstorage/</a></p>
+
+<p>22. HTML5/W3C IndexedDB API: <a href="http://www.w3.org/TR/IndexedDB/">http://www.w3.org/TR/IndexedDB/</a></p>
+
+<p>23. Dalvik Executable Format and bytecode specification: available in the
+Android source code, at dalvik/docs</p>
+
+<p>24. AppWidgets: <a href="http://developer.android.com/guide/practices/ui_guidelines/widget_design.html">http://developer.android.com/guide/practices/ui_guidelines/widget_design.html</a></p>
+
+<p>25. Notifications: <a href="http://developer.android.com/guide/topics/ui/notifiers/notifications.html">http://developer.android.com/guide/topics/ui/notifiers/notifications.html</a></p>
+
+<p>26. Application Resources: <a href="https://developer.android.com/guide/topics/resources/available-resources.html">https://developer.android.com/guide/topics/resources/available-resources.html</a></p>
+
+<p>27. Status Bar icon style guide: <a href="http://developer.android.com/design/style/iconography.html">http://developer.android.com/design/style/iconography.html</a></p>
+
+<p>28. Notifications Resources: <a href="https://developer.android.com/design/patterns/notifications.html">https://developer.android.com/design/patterns/notifications.html</a></p>
+
+<p>29. Search Manager: <a href="http://developer.android.com/reference/android/app/SearchManager.html">http://developer.android.com/reference/android/app/SearchManager.html</a></p>
+
+<p>30. Action Assist: <a href="http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST">http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST</a></p>
+
+<p>31. Android Assist APIs: <a href="https://developer.android.com/reference/android/app/assist/package-summary.html">https://developer.android.com/reference/android/app/assist/package-summary.html</a></p>
+
+<p>32. Toasts: <a href="http://developer.android.com/reference/android/widget/Toast.html">http://developer.android.com/reference/android/widget/Toast.html</a></p>
+
+<p>33. Themes: <a href="http://developer.android.com/guide/topics/ui/themes.html">http://developer.android.com/guide/topics/ui/themes.html</a></p>
+
+<p>34. R.style class: <a href="http://developer.android.com/reference/android/R.style.html">http://developer.android.com/reference/android/R.style.html</a></p>
+
+<p>35. Material design: <a href="http://developer.android.com/reference/android/R.style.html#Theme_Material">http://developer.android.com/reference/android/R.style.html#Theme_Material</a></p>
+
+<p>36. Live Wallpapers: <a href="http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html">http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html</a></p>
+
+<p>37. Overview screen resources: <a href="http://developer.android.com/guide/components/recents.html">http://developer.android.com/guide/components/recents.html</a></p>
+
+<p>38. Screen pinning: <a href="https://developer.android.com/about/versions/android-5.0.html#ScreenPinning">https://developer.android.com/about/versions/android-5.0.html#ScreenPinning</a></p>
+
+<p>39. Input methods: <a href="http://developer.android.com/guide/topics/text/creating-input-method.html">http://developer.android.com/guide/topics/text/creating-input-method.html</a></p>
+
+<p>40. Media Notification: <a href="https://developer.android.com/reference/android/app/Notification.MediaStyle.html">https://developer.android.com/reference/android/app/Notification.MediaStyle.html</a></p>
+
+<p>41. Dreams: <a href="http://developer.android.com/reference/android/service/dreams/DreamService.html">http://developer.android.com/reference/android/service/dreams/DreamService.html</a></p>
+
+<p>42. Settings.Secure LOCATION_MODE: <a href="http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE">http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE</a></p>
+
+<p>43. Unicode 6.1.0: <a href="http://www.unicode.org/versions/Unicode6.1.0/">http://www.unicode.org/versions/Unicode6.1.0/</a></p>
+
+<p>44. Android Device Administration: <a href="http://developer.android.com/guide/topics/admin/device-admin.html">http://developer.android.com/guide/topics/admin/device-admin.html</a></p>
+
+<p>45. DevicePolicyManager reference: <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html">http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html</a></p>
+
+<p>46. Device Owner App: <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)">http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)</a></p>
+
+
+<p>47. Android Device Owner Provisioning Flow: <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_DEVICE">http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_DEVICE</a></p>
+
+<p>48. Device Owner Provisioning via NFC: <a href="https://source.android.com/devices/tech/admin/provision.html#device_owner_provisioning_via_nfc">https://source.android.com/devices/tech/admin/provision.html#device_owner_provisioning_via_nfc</a></p>
+
+<p>49. Android Profile Owner App:<a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isProfileOwnerApp(java.lang.String)">http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isProfileOwnerApp(java.lang.String)</a></p>
+
+<p>50. Android Managed Profile Provisioning flow: <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_PROFILE">http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_PROFILE</a></p>
+
+<p>51. Android Accessibility Service APIs: <a href="http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html">http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html</a></p>
+
+<p>52. Android Accessibility APIs: <a href="http://developer.android.com/reference/android/view/accessibility/package-summary.html">http://developer.android.com/reference/android/view/accessibility/package-summary.html</a></p>
+
+<p>53. Eyes Free project: <a href="http://code.google.com/p/eyes-free/">http://code.google.com/p/eyes-free</a></p>
+
+<p>54. Text-To-Speech APIs: <a href="http://developer.android.com/reference/android/speech/tts/package-summary.html">http://developer.android.com/reference/android/speech/tts/package-summary.html</a></p>
+
+<p>55. Television Input Framework: <a href="https://source.android.com/devices/tv/index.html">https://source.android.com/devices/tv/index.html</a></p>
+
+<p>56. TV App channels: <a href="http://developer.android.com/reference/android/media/tv/TvContract.Channels.html">http://developer.android.com/reference/android/media/tv/TvContract.Channels.html</a></p>
+
+<p>57. Third-party TV inputs: <a href="https://source.android.com/devices/tv/index.html#third-party_input_example">https://source.android.com/devices/tv/index.html#third-party_input_example</a></p>
+
+<p>58. TV inputs: <a href="https://source.android.com/devices/tv/index.html#tv_inputs">https://source.android.com/devices/tv/index.html#tv_inputs</a></p>
+
+<p>59. TV channel EPG fields: <a href="https://developer.android.com/reference/android/media/tv/TvContract.Programs.html">https://developer.android.com/reference/android/media/tv/TvContract.Programs.html</a></p>
+
+<p>60. TV input app linking: <a href="http://developer.android.com/reference/android/media/tv/TvContract.Channels.html#COLUMN_APP_LINK_INTENT_URI">http://developer.android.com/reference/android/media/tv/TvContract.Channels.html#COLUMN_APP_LINK_INTENT_URI</a></p>
+
+<p>61. Reference tool documentation (for adb, aapt, ddms, systrace): <a href="http://developer.android.com/tools/help/index.html">http://developer.android.com/tools/help/index.html</a></p>
+
+<p>62. Android apk file description: <a href="http://developer.android.com/guide/components/fundamentals.html">http://developer.android.com/guide/components/fundamentals.html</a></p>
+
+<p>63. Manifest files: <a href="http://developer.android.com/guide/topics/manifest/manifest-intro.html">http://developer.android.com/guide/topics/manifest/manifest-intro.html</a></p>
+
+<p>64. Android Media Formats: <a href="http://developer.android.com/guide/appendix/media-formats.html">http://developer.android.com/guide/appendix/media-formats.html</a></p>
+
+<p>65. Android MediaCodecList API: <a href="http://developer.android.com/reference/android/media/MediaCodecList.html">http://developer.android.com/reference/android/media/MediaCodecList.html</a></p>
+
+<p>66. Android CamcorderProfile API: <a href="http://developer.android.com/reference/android/media/CamcorderProfile.html">http://developer.android.com/reference/android/media/CamcorderProfile.html</a></p>
+
+<p>67. WebM project: <a href="http://www.webmproject.org/">http://www.webmproject.org/</a></p>
+
+<p>68. RTC Hardware Coding Requirements: <a href="http://www.webmproject.org/hardware/rtc-coding-requirements/">http://www.webmproject.org/hardware/rtc-coding-requirements/</a></p>
+
+<p>69. AudioEffect API: <a href="http://developer.android.com/reference/android/media/audiofx/AudioEffect.html">http://developer.android.com/reference/android/media/audiofx/AudioEffect.html</a></p>
+
+<p>70. Android android.content.pm.PackageManager class and Hardware Features List: <a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">http://developer.android.com/reference/android/content/pm/PackageManager.html</a></p>
+
+<p>71. HTTP Live Streaming Draft Protocol: <a href="http://tools.ietf.org/html/draft-pantos-http-live-streaming-03">http://tools.ietf.org/html/draft-pantos-http-live-streaming-03</a></p>
+
+<p>72. ADB: <a href="http://developer.android.com/tools/help/adb.html">http://developer.android.com/tools/help/adb.html</a></p>
+
+<p>73. Dumpsys: <a href="https://source.android.com/devices/input/diagnostics.html">https://source.android.com/devices/input/diagnostics.html</a></p>
+
+<p>74. DDMS: <a href="http://developer.android.com/tools/debugging/ddms.html">http://developer.android.com/tools/debugging/ddms.html</a></p>
+
+<p>75. Monkey testing tool: <a href="http://developer.android.com/tools/help/monkey.html">http://developer.android.com/tools/help/monkey.html</a></p>
+
+<p>76. SysyTrace tool: <a href="http://developer.android.com/tools/help/systrace.html">http://developer.android.com/tools/help/systrace.html</a></p>
+
+<p>77. Android Application Development-Related Settings: <a href="http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS">http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS</a></p>
+
+<p>78. Supporting Multiple Screens: <a href="http://developer.android.com/guide/practices/screens_support.html">http://developer.android.com/guide/practices/screens_support.html</a></p>
+
+<p>79. android.util.DisplayMetrics: <a href="http://developer.android.com/reference/android/util/DisplayMetrics.html">http://developer.android.com/reference/android/util/DisplayMetrics.html</a></p>
+
+<p>80. RenderScript: <a href="http://developer.android.com/guide/topics/renderscript/">http://developer.android.com/guide/topics/renderscript/</a></p>
+
+<p>81. Android extension pack for OpenGL ES: <a href="https://developer.android.com/reference/android/opengl/GLES31Ext.html">https://developer.android.com/reference/android/opengl/GLES31Ext.html</a></p>
+
+<p>82. Hardware Acceleration: <a href="http://developer.android.com/guide/topics/graphics/hardware-accel.html">http://developer.android.com/guide/topics/graphics/hardware-accel.html</a></p>
+
+<p>83. EGL Extension-EGL_ANDROID_RECORDABLE: <a href="http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt">http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt</a></p>
+
+<p>84. Display Manager: <a href="http://developer.android.com/reference/android/hardware/display/DisplayManager.html">http://developer.android.com/reference/android/hardware/display/DisplayManager.html</a></p>
+
+<p>85. android.content.res.Configuration: <a href="http://developer.android.com/reference/android/content/res/Configuration.html">http://developer.android.com/reference/android/content/res/Configuration.html</a></p>
+
+<p>86. Touch Input Configuration: <a href="http://source.android.com/devices/tech/input/touch-devices.html">http://source.android.com/devices/tech/input/touch-devices.html</a></p>
+
+<p>87. Motion Event API: <a href="http://developer.android.com/reference/android/view/MotionEvent.html">http://developer.android.com/reference/android/view/MotionEvent.html</a></p>
+
+<p>88. Key Event API: <a href="http://developer.android.com/reference/android/view/KeyEvent.html">http://developer.android.com/reference/android/view/KeyEvent.html</a></p>
+
+<p>89. Android Open Source sensors: <a href="http://source.android.com/devices/sensors/">http://source.android.com/devices/sensors</a></p>
+
+<p>90. android.hardware.SensorEvent: <a href="http://developer.android.com/reference/android/hardware/SensorEvent.html">http://developer.android.com/reference/android/hardware/SensorEvent.html</a></p>
+
+<p>91. Timestamp sensor event: <a href="http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp">http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp</a></p>
+
+<p>92. Android Open Source composite sensors: <a href="http://source.android.com/devices/sensors/sensor-types.html#composite_sensor_type_summary">https://source.android.com/devices/sensors/sensor-types.html#composite_sensor_type_summary</a></p>
+
+<p>93. Continuous trigger mode: <a href="http://source.android.com/devices/sensors/report-modes.html#continuous">https://source.android.com/devices/sensors/report-modes.html#continuous</a></p>
+
+<p>94. Accelerometer sensor: <a href="http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER">http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER</a></p>
+
+<p>95. Android Fingerprint API: <a href="https://developer.android.com/reference/android/hardware/fingerprint/package-summary.html">https://developer.android.com/reference/android/hardware/fingerprint/package-summary.html</a></p>
+
+<p>96. Android Fingerprint HAL: <a href="https://source.android.com/devices/tech/security/authentication/fingerprint-hal.html">https://source.android.com/devices/tech/security/authentication/fingerprint-hal.html</a></p>
+
+<p>97. Wi-Fi Multicast API: <a href="http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html">http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html</a></p>
+
+<p>98. Wi-Fi Direct (Wi-Fi P2P): <a href="http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html">http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html</a></p>
+
+<p>99. WifiManager API: <a href="http://developer.android.com/reference/android/net/wifi/WifiManager.html">http://developer.android.com/reference/android/net/wifi/WifiManager.html</a></p>
+
+<p>100. Bluetooth API: <a href="http://developer.android.com/reference/android/bluetooth/package-summary.html">http://developer.android.com/reference/android/bluetooth/package-summary.html</a></p>
+
+<p>101. Bluetooth ScanFilter API: <a href="https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html">https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html</a></p>
+
+<p>102. NFC Barcode: <a href="http://developer.android.com/reference/android/nfc/tech/NfcBarcode.html">http://developer.android.com/reference/android/nfc/tech/NfcBarcode.html</a></p>
+
+<p>103. NDEF Push Protocol: <a href="http://source.android.com/compatibility/ndef-push-protocol.pdf">http://source.android.com/compatibility/ndef-push-protocol.pdf</a></p>
+
+<p>104. Android Beam: <a href="http://developer.android.com/guide/topics/connectivity/nfc/nfc.html">http://developer.android.com/guide/topics/connectivity/nfc/nfc.html</a></p>
+
+<p>105. Android NFC Sharing Settings: <a href="http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS">http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS</a></p>
+
+<p>106. NFC Connection Handover: <a href="http://members.nfc-forum.org/specs/spec_list/#conn_handover">http://members.nfc-forum.org/specs/spec_list/#conn_handover</a></p>
+
+<p>107. Bluetooth Secure Simple Pairing Using NFC: <a href="http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf">http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf</a></p>
+
+<p>108. Host-based Card Emulation: <a href="http://developer.android.com/guide/topics/connectivity/nfc/hce.html">http://developer.android.com/guide/topics/connectivity/nfc/hce.html</a></p>
+
+<p>109. Content Resolver: <a href="http://developer.android.com/reference/android/content/ContentResolver.html">http://developer.android.com/reference/android/content/ContentResolver.html</a></p>
+
+<p>110. Camera orientation API: <a href="http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)">http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)</a></p>
+
+<p>111. Camera: <a href="http://developer.android.com/reference/android/hardware/Camera.html">http://developer.android.com/reference/android/hardware/Camera.html</a></p>
+
+<p>112. Camera: <a href="http://developer.android.com/reference/android/hardware/Camera.Parameters.html">http://developer.android.com/reference/android/hardware/Camera.Parameters.html</a></p>
+
+<p>113. Camera hardware level: <a href="https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL">https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL</a></p>
+
+<p>114. Camera version support: <a href="http://source.android.com/devices/camera/versioning.html">http://source.android.com/devices/camera/versioning.html</a></p>
+
+<p>115. Android DownloadManager: <a href="http://developer.android.com/reference/android/app/DownloadManager.html">http://developer.android.com/reference/android/app/DownloadManager.html</a></p>
+
+<p>116. Android File Transfer: <a href="http://www.android.com/filetransfer">http://www.android.com/filetransfer</a></p>
+
+<p>117. Adoptable storage: <a href="http://source.android.com/devices/storage/adoptable.html">http://source.android.com/devices/storage/adoptable.html</a></p>
+
+<p>118. Android Open Accessories: <a href="http://developer.android.com/guide/topics/connectivity/usb/accessory.html">http://developer.android.com/guide/topics/connectivity/usb/accessory.html</a></p>
+
+<p>119. Android USB Audio: <a href="http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO">http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO</a></p>
+
+<p>120. USB Charging Specification: <a href="http://www.usb.org/developers/docs/devclass_docs/USB_Battery_Charging_1.2.pdf">http://www.usb.org/developers/docs/devclass_docs/USB_Battery_Charging_1.2.pdf</a></p>
+
+<p>121. USB Host API:<a href="http://developer.android.com/guide/topics/connectivity/usb/host.html"> http://developer.android.com/guide/topics/connectivity/usb/host.html</a></p>
+
+<p>122. Wired audio headset: <a href="http://source.android.com/accessories/headset-spec.html">http://source.android.com/accessories/headset-spec.html</a></p>
+
+<p>123. Power profile components: <a href="http://source.android.com/devices/tech/power/values.html">http://source.android.com/devices/tech/power/values.html</a></p>
+
+<p>124. Batterystats: <a href="http://source.android.com/devices/tech/power/batterystats.html">http://source.android.com/devices/tech/power/batterystats.html</a></p>
+
+<p>125. Power usage summary: <a href="http://developer.android.com/reference/android/content/Intent.html#ACTION_POWER_USAGE_SUMMARY">http://developer.android.com/reference/android/content/Intent.html#ACTION_POWER_USAGE_SUMMARY</a></p>
+
+<p>126. Android Security and Permissions reference: <a href="http://developer.android.com/guide/topics/security/permissions.html">http://developer.android.com/guide/topics/security/permissions.html</a></p>
+
+<p>127. UserManager reference: <a href="http://developer.android.com/reference/android/os/UserManager.html">http://developer.android.com/reference/android/os/UserManager.html</a></p>
+
+<p>128. External Storage reference: <a href="http://source.android.com/devices/storage/traditional.html">http://source.android.com/devices/storage</a></p>
+
+<p>129. External Storage APIs: <a href="http://developer.android.com/reference/android/os/Environment.html">http://developer.android.com/reference/android/os/Environment.html</a></p>
+
+<p>130. SMS Short Code: <a href="http://en.wikipedia.org/wiki/Short_code">http://en.wikipedia.org/wiki/Short_code</a></p>
+
+<p>131. Secure lock screen reporting: <a href="http://developer.android.com/reference/android/app/KeyguardManager.html#isDeviceSecure()">http://developer.android.com/reference/android/app/KeyguardManager.html#isDeviceSecure()</a></p>
+
+<p>132. Android Open Source Encryption: <a href="http://source.android.com/devices/tech/security/encryption/index.html">http://source.android.com/devices/tech/security/encryption/index.html</a></p>
+
+<p>133. Android Keystore System: <a href="https://developer.android.com/training/articles/keystore.html">https://developer.android.com/training/articles/keystore.html</a></p>
+
+<p>134. KeyChain API: <a href="https://developer.android.com/reference/android/security/KeyChain.html">https://developer.android.com/reference/android/security/KeyChain.html</a></p>
+
+<p>135. Keystore API: <a href="https://developer.android.com/reference/java/security/KeyStore.html">https://developer.android.com/reference/java/security/KeyStore.html</a></p>
+
+<p>136. Gatekeeper HAL: <a href="http://source.android.com/devices/tech/security/authentication/gatekeeper.html">http://source.android.com/devices/tech/security/authentication/gatekeeper.html</a></p>
+
+<p>137. Android Compatibility Program Overview: <a href="http://source.android.com/compatibility/index.html">http://source.android.com/compatibility/index.html</a></p>
+
+<p>138. SystemUpdatePolicy class: <a href="http://developer.android.com/reference/android/app/admin/SystemUpdatePolicy.html">http://developer.android.com/reference/android/app/admin/SystemUpdatePolicy.html</a></p>
+
+<p>139. Android Compatibility forum: <a href="https://groups.google.com/forum/#!forum/android-compatibility">https://groups.google.com/forum/#!forum/android-compatibility</a></p>
+
+<p>140. Handling app links: <a href="https://developer.android.com/training/app-links">https://developer.android.com/training/app-links/index.html</a></p>
+
+<p>141. Google Digital Asset Links: <a href="https://developers.google.com/digital-asset-links">https://developers.google.com/digital-asset-links</a></p>
+
+<p>Many of these resources are derived directly or indirectly from the Android
+SDK, and will be functionally identical to the information in that SDK’s
+documentation. In any cases where this Compatibility Definition or the
+Compatibility Test Suite disagrees with the SDK documentation, the SDK
+documentation is considered authoritative. Any technical details provided in
+the references included above are considered by inclusion to be part of this
+Compatibility Definition.</p>
+
+</div>
+</body>
+</html>
diff --git a/src/compatibility/6.0/android-6.0-cdd.pdf b/src/compatibility/6.0/android-6.0-cdd.pdf
new file mode 100644
index 0000000..a0ca71d
--- /dev/null
+++ b/src/compatibility/6.0/android-6.0-cdd.pdf
Binary files differ
diff --git a/src/compatibility/6.0/versions.jd b/src/compatibility/6.0/versions.jd
new file mode 100644
index 0000000..d0c9eca
--- /dev/null
+++ b/src/compatibility/6.0/versions.jd
@@ -0,0 +1,18 @@
+page.title=Permitted Version Strings for Android 6.0
+@jd:body
+
+<p>As described in Section 3.2.2 of the <a
+href="/compatibility/android-6.0-cdd.pdf">Android 6.0 Compatibility Definition</a>,
+only certain strings are allowable for the system property
+<code>android.os.Build.VERSION.RELEASE</code>. The reason for this is that
+applications and web sites may rely on predictable values for this string, and
+so that end users can easily and reliably identify the version of Android
+running on their devices.</p>
+<p>Because subsequent releases of the Android software may revise this string,
+but not change any API behavior, such releases may not be accompanied by a new
+Compatibility Definition Document. This page lists the versions that are
+allowable by an Android 6.0-based system. The only permitted values for
+<code>android.os.Build.VERSION.RELEASE</code> for Android 6.0 are:</p>
+<ul>
+<li>6.0</li>
+</ul>
diff --git a/src/compatibility/android-6.0-cdd.pdf b/src/compatibility/android-6.0-cdd.pdf
new file mode 100644
index 0000000..a0ca71d
--- /dev/null
+++ b/src/compatibility/android-6.0-cdd.pdf
Binary files differ
diff --git a/src/compatibility/android-cdd.html b/src/compatibility/android-cdd.html
index ac1867b..51970c9 100644
--- a/src/compatibility/android-cdd.html
+++ b/src/compatibility/android-cdd.html
@@ -1,7 +1,7 @@
<!DOCTYPE html>
<head>
<title>Android ANDROID_VERSION Compatibility Definition</title>
-<link rel="stylesheet" type="text/css" href="source/android-cdd.css"/>
+<link rel="stylesheet" type="text/css" href="android-cdd.css"/>
</head>
<body>
@@ -32,7 +32,7 @@
<p class="toc_h4"><a href="#3_2_3_1_core_application_intents">3.2.3.1. Core Application Intents</a></p>
-<p class="toc_h4"><a href="#3_2_3_2_intent_overrides">3.2.3.2. Intent Overrides</a></p>
+<p class="toc_h4"><a href="#3_2_3_2_intent_resolution">3.2.3.2. Intent Resolution</a></p>
<p class="toc_h4"><a href="#3_2_3_3_intent_namespaces">3.2.3.3. Intent Namespaces</a></p>
@@ -84,24 +84,38 @@
<p class="toc_h3"><a href="#3_8_12_location">3.8.12. Location</a></p>
-<p class="toc_h3"><a href="#3_8_13_unicode_and_font">3.8.13. Unicode and Font</a></p>
-
-
-
</div>
-<div id="toc_right"><br>
+<div id="toc_right">
+<p class="toc_h3"><a href="#3_8_13_unicode_and_font">3.8.13. Unicode and Font</a></p>
<p class="toc_h2"><a href="#3_9_device_administration">3.9. Device Administration</a></p>
+<p class="toc_h3"><a href="#3_9_1_device_provisioning">3.9.1 Device Provisioning</a></p>
+
+<p class="toc_h4"><a href="#3_9_1_2_device_owner_provisioning">3.9.1.1 Device Owner provisioning</a></p>
+
+<p class="toc_h4"><a href="#3_9_1_2_managed_profile_provisioning">3.9.1.2 Managed profile provisioning</a></p>
+
+<p class="toc_h3"><a href="#3_9_2_managed_profile_support">3.9.2. Managed Profile Support</a></p>
+
+
<p class="toc_h2"><a href="#3_10_accessibility">3.10. Accessibility</a></p>
<p class="toc_h2"><a href="#3_11_text-to-speech">3.11. Text-to-Speech</a></p>
<p class="toc_h2"><a href="#3_12_tv_input_framework">3.12. TV Input Framework</a></p>
+<p class="toc_h3"><a href="#3_12_1_tv_app">3.12.1. TV App</a></p>
+
+<p class="toc_h4"><a href="#3_12_1_1_electronic_program_guide">3.12.1.1. Electronic Program Guide</a></p>
+
+<p class="toc_h4"><a href="#3_12_1_2_navigation">3.12.1.2. Navigation</a></p>
+
+<p class="toc_h4"><a href="#3_12_1_3_tv_input_app_linking">3.12.1.3. TV input app linking</a></p>
+
<p class="toc_h1"><a href="#4_application_packaging_compatibility">4. Application Packaging Compatibility</a></p>
<p class="toc_h1"><a href="#5_multimedia_compatibility">5. Multimedia Compatibility</a></p>
@@ -142,6 +156,14 @@
<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>
+
+</div>
+
+<div style="clear: both; page-break-after:always; height:1px"></div>
+
+<div id="toc_left">
+
<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>
@@ -160,14 +182,6 @@
<p class="toc_h4"><a href="#7_1_1_3_screen_density">7.1.1.3. Screen Density</a></p>
-
-</div>
-
-<div style="clear: both; page-break-after:always; height:1px"></div>
-
-
-<div id="toc_left_2">
-
<p class="toc_h3"><a href="#7_1_2_display_metrics">7.1.2. Display Metrics</a></p>
<p class="toc_h3"><a href="#7_1_3_screen_orientation">7.1.3. Screen Orientation</a></p>
@@ -206,6 +220,10 @@
<p class="toc_h3"><a href="#7_3_3_gps">7.3.3. GPS</a></p>
+</div>
+
+<div id="toc_right">
+
<p class="toc_h3"><a href="#7_3_4_gyroscope">7.3.4. Gyroscope</a></p>
<p class="toc_h3"><a href="#7_3_5_barometer">7.3.5. Barometer</a></p>
@@ -216,6 +234,10 @@
<p class="toc_h3"><a href="#7_3_8_proximity_sensor">7.3.8. Proximity Sensor</a></p>
+<p class="toc_h3"><a href="#7_3_9_hifi_sensors">7.3.9. High Fidelity Sensors</a></p>
+
+<p class="toc_h3"><a href="#7_3_10_fingerprint">7.3.10. Fingerprint Sensor</a></p>
+
<p class="toc_h2"><a href="#7_4_data_connectivity">7.4. Data Connectivity</a></p>
<p class="toc_h3"><a href="#7_4_1_telephony">7.4.1. Telephony</a></p>
@@ -244,14 +266,6 @@
<p class="toc_h3"><a href="#7_5_4_camera_api_behavior">7.5.4. Camera API Behavior</a></p>
-
-
-
-
-</div>
-
-<div id="toc_right_2">
-
<p class="toc_h3"><a href="#7_5_5_camera_orientation">7.5.5. Camera Orientation</a></p>
<p class="toc_h2"><a href="#7_6_memory_and_storage">7.6. Memory and Storage</a></p>
@@ -260,6 +274,8 @@
<p class="toc_h3"><a href="#7_6_2_application_shared_storage">7.6.2. Application Shared Storage</a></p>
+<p class="toc_h3"><a href="#7_6_3_adoptable_storage">7.6.3. Adoptable Storage</a></p>
+
<p class="toc_h2"><a href="#7_7_usb">7.7. USB</a></p>
<p class="toc_h2"><a href="#7_8_audio">7.8. Audio</a></p>
@@ -270,11 +286,23 @@
<p class="toc_h4"><a href="#7_8_2_1_analog_audio_ports">7.8.2.1. Analog Audio Ports</a></p>
-<p class="toc_h1"><a href="#8_performance_compatibility">8. Performance Compatibility</a></p>
+<p class="toc_h3"><a href="#7_8_3_near_ultrasound">7.8.3. Near-Ultrasound</a></p>
+
+<p class="toc_h1"><a href="#8_performance_power">8. Performance and Power</a></p>
<p class="toc_h2"><a href="#8_1_user_experience_consistency">8.1. User Experience Consistency</a></p>
-<p class="toc_h2"><a href="#8_2_memory_performance">8.2. Memory Performance</a></p>
+<p class="toc_h2"><a href="#8_2_file_i_o_access_performance">8.2. File I/O Access Performance</a></p>
+
+<p class="toc_h2"><a href="#8_3_power_saving_modes">8.3. Power-Saving Modes</a></p>
+
+<p class="toc_h2"><a href="#8_4_power_consumption_accounting">8.4. Power Consumption Accounting</a></p>
+
+</div>
+
+<div style="clear: both; page-break-after:always; height:1px"></div>
+
+<div id="toc_left">
<p class="toc_h1"><a href="#9_security_model_compatibility">9. Security Model Compatibility</a></p>
@@ -298,6 +326,10 @@
<p class="toc_h2"><a href="#9_10_verified_boot">9.10. Verified Boot</a></p>
+<p class="toc_h2"><a href="#9_11_keys_and_credentials">9.11. Keys and Credentials</a></p>
+
+<p class="toc_h2"><a href="#9_12_data_deletion">9.12. Data Deletion</a></p>
+
<p class="toc_h1"><a href="#10_software_compatibility_testing">10. Software Compatibility Testing</a></p>
<p class="toc_h2"><a href="#10_1_compatibility_test_suite">10.1. Compatibility Test Suite</a></p>
@@ -326,7 +358,7 @@
<p>This document enumerates the requirements that must be met in order for devices
to be compatible with Android ANDROID_VERSION.</p>
-<p>The use of “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,“SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” is per the IETF standard
+<p>The use of “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” is per the IETF standard
defined in RFC2119 [<a href="http://www.ietf.org/rfc/rfc2119.txt">Resources, 1</a>].</p>
<p>As used in this document, a “device implementer” or “implementer” is a person
@@ -342,10 +374,10 @@
implementer to ensure compatibility with existing implementations.</p>
<p>For this reason, the Android Open Source Project [<a href="http://source.android.com/">Resources, 2</a>] is both the reference and preferred implementation of Android. Device
-implementers are strongly encouraged to base their implementations to the
+implementers are STRONGLY RECOMMENDED to base their implementations to the
greatest extent possible on the “upstream” source code available from the
Android Open Source Project. While some components can hypothetically be
-replaced with alternate implementations this practice is strongly discouraged,
+replaced with alternate implementations, it is STRONGLY RECOMMENDED to not follow this practice,
as passing the software tests will become substantially more difficult. It is
the implementer’s responsibility to ensure full behavioral compatibility with
the standard Android implementation, including and beyond the Compatibility
@@ -400,8 +432,15 @@
<p><strong>Android Automotive implementation</strong> refers to a vehicle head
unit running Android as an operating system for part or all of the system and/or
-infotainment functionality. Android Automotive implementations MUST support
-uiMode = UI_MODE_TYPE_CAR [<a href="http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR">Resources, 111</a>].</p>
+infotainment functionality. Android Automotive implementations:</p>
+
+<ul>
+ <li>MUST declare the feature android.hardware.type.automotive.</li>
+ <li>MUST support
+uiMode = UI_MODE_TYPE_CAR [<a
+href="http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR">Resources,
+ 5</a>].</li>
+</ul>
<p>All Android device implementations that do not fit into any of the above device
types still MUST meet all requirements in this document to be Android ANDROID_VERSION
@@ -542,7 +581,7 @@
the set of Android platform interfaces exposed to applications running in the
managed runtime environment. Device implementations MUST provide complete
implementations, including all documented behaviors, of any documented API
-exposed by the Android SDK [<a href="http://developer.android.com/reference/packages.html">Resources, 5</a>] or any API decorated with the “@SystemApi” marker in the upstream Android
+exposed by the Android SDK [<a href="http://developer.android.com/reference/packages.html">Resources, 6</a>] or any API decorated with the “@SystemApi” marker in the upstream Android
source code. </p>
<p>Device implementations MUST NOT omit any managed APIs, alter API interfaces or
@@ -564,12 +603,12 @@
<p>Device implementers MUST support and enforce all permission constants as
-documented by the Permission reference page [<a href="http://developer.android.com/reference/android/Manifest.permission.html">Resources, 6]</a>. Note that <a href="#9_security_model_compatibility">section 9</a> lists additional requirements related to the Android security model.</p>
+documented by the Permission reference page [<a href="http://developer.android.com/reference/android/Manifest.permission.html">Resources, 7</a>]. Note that <a href="#9_security_model_compatibility">section 9</a> lists additional requirements related to the Android security model.</p>
<h3 id="3_2_2_build_parameters">3.2.2. Build Parameters</h3>
-<p>The Android APIs include a number of constants on the android.os.Build class [<a href="http://developer.android.com/reference/android/os/Build.html">Resources, 7</a>] that are intended to describe the current device. To provide consistent,
+<p>The Android APIs include a number of constants on the android.os.Build class [<a href="http://developer.android.com/reference/android/os/Build.html">Resources, 8</a>] that are intended to describe the current device. To provide consistent,
meaningful values across device implementations, the table below includes
additional restrictions on the formats of these values to which device
implementations MUST conform.</p>
@@ -581,19 +620,19 @@
<tr>
<td>VERSION.RELEASE</td>
<td>The version of the currently-executing Android system, in human-readable
-format. This field MUST have one of the string values defined in [<a href="http://source.android.com/compatibility/ANDROID_VERSION/versions.html">Resources, 8]</a>.</td>
+format. This field MUST have one of the string values defined in [<a href="http://source.android.com/compatibility/ANDROID_VERSION/versions.html">Resources, 9</a>].</td>
</tr>
<tr>
<td>VERSION.SDK</td>
<td>The version of the currently-executing Android system, in a format accessible
to third-party application code. For Android ANDROID_VERSION, this field MUST have the
-integer value 22.</td>
+integer value ANDROID_VERSION_INT.</td>
</tr>
<tr>
<td>VERSION.SDK_INT</td>
<td>The version of the currently-executing Android system, in a format accessible
to third-party application code. For Android ANDROID_VERSION, this field MUST have the
-integer value 22.</td>
+integer value ANDROID_VERSION_INT.</td>
</tr>
<tr>
<td>VERSION.INCREMENTAL</td>
@@ -653,17 +692,17 @@
<tr>
<td>FINGERPRINT</td>
<td>A string that uniquely identifies this build. It SHOULD be reasonably
-human-readable. It MUST follow this template:</p>
-
-<p class="small">$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)</p>
-
-<p>For example: acme/myproduct/mydevice:ANDROID_VERSION/LMYXX/3359:userdebug/test-keys</p>
-
+human-readable. It MUST follow this template:
+<p class="small">$(BRAND)/$(PRODUCT)/<br>
+ $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)</p>
+<p>For example:</p>
+<p class="small">acme/myproduct/<br>
+ mydevice:ANDROID_VERSION/LMYXX/3359:userdebug/test-keys</p>
<p>The fingerprint MUST NOT include whitespace characters. If other fields
included in the template above have whitespace characters, they MUST be
replaced in the build fingerprint with another character, such as the
underscore ("_") character. The value of this field MUST be encodable as 7-bit
-ASCII.</td>
+ASCII.</p></td>
</tr>
<tr>
<td>HARDWARE</td>
@@ -708,7 +747,8 @@
</tr>
<tr>
<td>SERIAL</td>
- <td>A hardware serial number, which MUST be available. The value of this field MUST
+ <td>A hardware serial number, which MUST be available and unique across
+devices with the same MODEL and MANUFACTURER. The value of this field MUST
be encodable as 7-bit ASCII and match the regular expression “^([a-zA-Z0-9]{6,20})$”.</td>
</tr>
<tr>
@@ -734,6 +774,20 @@
There are no requirements on the specific format of this field, except that it
MUST NOT be null or the empty string ("").</td>
</tr>
+ <tr>
+ <td>SECURITY_PATCH</td>
+ <td>An value indicating the security patch level of a build. It MUST signify that the
+build includes all security patches issued up through the designated Android Public
+Security Bulletin. It MUST be in the format, [YYYY-MM-DD], matching the Public Security
+Bulletin's broadcast date, for example [2015-10-01].</td>
+ </tr>
+ <tr>
+ <td>BASE_OS</td>
+ <td>An value representing the FINGERPRINT parameter of the build that is otherwise
+ identical to this build except for the patches provided in the Android Public
+ Security Bulletin. It MUST report the correct value and if such a build does not
+ exist, report an emtpy string ("").</td>
+ </tr>
</table>
@@ -772,11 +826,12 @@
Android applications. Note that Activity or Service components are considered
“public” when the attribute android:exported is absent or has the value true.</p>
-<h4 id="3_2_3_2_intent_overrides">3.2.3.2. Intent Overrides</h4>
+<h4 id="3_2_3_2_intent_resolution">3.2.3.2. Intent Resolution</h4>
<p>As Android is an extensible platform, device implementations MUST allow each
-intent pattern referenced in <a href="#3_2_3_1_core_application_intents">section 3.2.3.1</a> to be overridden by third-party applications. The upstream Android open source
+intent pattern referenced in <a href="#3_2_3_1_core_application_intents">section 3.2.3.1</a>
+to be overridden by third-party applications. The upstream Android open source
implementation allows this by default; device implementers MUST NOT attach
special privileges to system applications' use of these intent patterns, or
prevent third-party applications from binding to and assuming control of these
@@ -784,11 +839,48 @@
disabling the“Chooser” user interface that allows the user to select between
multiple applications that all handle the same intent pattern.</p>
+<p>Device implementations MUST provide a user interface for users to modify the default
+activity for intents.</p>
+
<p>However, device implementations MAY provide default activities for specific URI
-patterns (eg. http://play.google.com) if the default activity provides a more
-specific filter for the data URI. For example, an intent filter specifying the
-data URI “http://www.android.com” is more specific than the browser filter for“http://”. Device implementations MUST provide a user interface for users to
-modify the default activity for intents.</p>
+patterns (eg. http://play.google.com) when the default activity provides a more
+specific attribute for the data URI. For example, an intent filter pattern specifying
+the data URI “http://www.android.com” is more specific than the browser's
+core intent pattern for “http://”.</p>
+
+<p>Android also includes a mechanism for third-party apps to declare an authoritative
+default app linking behavior for certain types of web URI intents [<a
+href="https://developer.android.com/training/app-links">Resources, 140</a>]. When such
+authoritative declarations are defined in an app's intent filter patterns, device
+implementations:</p>
+
+<ul>
+<li>MUST attempt to validate any intent filters by performing the validation steps
+defined in the Digital Asset Links specification [<a
+href="https://developers.google.com/digital-asset-links">Resources, 141</a>] as implemented
+by the Package Manager in the upstream Android Open Source Project.</li>
+<li>MUST attempt validation of the intent filters during the installation of the
+application and set all successfully validated UIR intent filters as default app handlers
+for their UIRs.</li>
+<li>MAY set specific URI intent filters as default app handlers for their URIs, if they
+are successfully verified but other candidate URI filters fail verification. If a device
+implementation does this, it MUST provide the user appropriate per-URI pattern overrides
+in the settings menu.</li>
+<li>MUST provide the user with per-app App Links controls in Settings as follows:
+ <ul>
+ <li>The user MUST be able to override holistically the default app links behavior for
+ an app to be: always open, always ask, or never open, which must apply to all candidate
+ URI intent filters equally.</li>
+ <li>The user MUST be able to see a list of the candidate URI intent filters.</li>
+ <li>The device implementation MAY provide the user with the ability to override specific
+ candidate URI intent filters that were successfully verified, on a per-intent filter basis.
+ </li>
+ <li>The device implementation MUST provide users with the ability to view and override
+ specific candidate URI intent filters if the device implementation lets some candidate
+ URI intent filters succeed verification while some others can fail.</li>
+ </ul>
+</li>
+</ul>
<h4 id="3_2_3_3_intent_namespaces">3.2.3.3. Intent Namespaces</h4>
@@ -826,14 +918,14 @@
<ul>
<li>MUST honor the android.settings.HOME_SETTINGS intent to show a default app
settings menu for Home Screen, if the device implementation reports
-android.software.home_screen [<a href="http://developer.android.com/reference/android/provider/Settings.html">Resources, 10]</a></li>
+android.software.home_screen [<a href="http://developer.android.com/reference/android/provider/Settings.html">Resources, 10</a>]</li>
<li>MUST provide a settings menu that will call the
android.provider.Telephony.ACTION_CHANGE_DEFAULT intent to show a dialog to
change the default SMS application, if the device implementation reports
-android.hardware.telephony [<a href="http://developer.android.com/reference/android/provider/Telephony.Sms.Intents.html">Resources, 9</a>]</li>
+android.hardware.telephony [<a href="http://developer.android.com/reference/android/provider/Telephony.Sms.Intents.html">Resources, 11</a>]</li>
<li>MUST honor the android.settings.NFC_PAYMENT_SETTINGS intent to show a default
app settings menu for Tap and Pay, if the device implementation reports
-android.hardware.nfc.hce [<a href="http://developer.android.com/reference/android/provider/Settings.html">Resources, 10]</a></li>
+android.hardware.nfc.hce [<a href="http://developer.android.com/reference/android/provider/Settings.html">Resources, 10</a>]</li>
</ul>
<h2 id="3_3_native_api_compatibility">3.3. Native API Compatibility</h2>
@@ -862,9 +954,13 @@
android.os.Build.SUPPORTED_32_BIT_ABIS, and
android.os.Build.SUPPORTED_64_BIT_ABIS parameters, each a comma separated list
of ABIs ordered from the most to the least preferred one</li>
- <li>MUST report, via the above parameters, only those ABIs documented in the latest
-version of the Android NDK, “NDK Programmer’s Guide | ABI Management” in docs/
-directory</li>
+ <li>MUST report, via the above parameters, only those ABIs documented and
+described in the latest version of the Android NDK ABI Management documentation
+[<a href="https://developer.android.com/ndk/guides/abis.html">Resources, 12</a>],
+and MUST include support for the Advanced SIMD (a.k.a. NEON)
+[<a href="http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/Beijfcja.html">Resources, 13</a>]
+extension
+ </li>
<li>SHOULD be built using the source code and header files available in the
upstream Android Open Source Project</li>
</ul>
@@ -898,13 +994,16 @@
<p>Note that device implementations MUST include libGLESv3.so and it MUST symlink
(symbolic link) to libGLESv2.so. in turn, MUST export all the OpenGL ES 3.1 and
-Android Extension Pack [<a href="http://developer.android.com/guide/topics/graphics/opengl.html#aep">Resources, 11</a>] function symbols as defined in the NDK release android-21. Although all the
+Android Extension Pack [<a href="http://developer.android.com/guide/topics/graphics/opengl.html#aep">Resources, 14</a>] function symbols as defined in the NDK release android-21. Although all the
symbols must be present, only the corresponding functions for OpenGL ES
versions and extensions actually supported by the device must be fully
implemented.</p>
+<p>Device implementations MUST NOT include a native library with the
+name libvulkan.so.</p>
+
<p>Native code compatibility is challenging. For this reason, device implementers
-are <strong>very strongly encouraged</strong> to use the implementations of the libraries listed above from the upstream
+are <strong>STRONGLY RECOMMENDED</strong> to use the implementations of the libraries listed above from the upstream
Android Open Source Project. </p>
<h3 id="3_3_2_32-bit_arm_native_code_compatibility">
@@ -953,23 +1052,21 @@
that provides a complete implementation of the android.webkit.WebView API, and
MUST NOT be reported on devices without a complete implementation of the API.
The Android Open Source implementation uses code from the Chromium Project to
-implement the android.webkit.WebView [<a href="http://developer.android.com/reference/android/webkit/WebView.html">Resources, 12</a>]. Because it is not feasible to develop a comprehensive test suite for a web
+implement the android.webkit.WebView [<a href="http://developer.android.com/reference/android/webkit/WebView.html">Resources, 15</a>]. Because it is not feasible to develop a comprehensive test suite for a web
rendering system, device implementers MUST use the specific upstream build of
Chromium in the WebView implementation. Specifically:</p>
<ul>
<li>Device android.webkit.WebView implementations MUST be based on the Chromium
build from the upstream Android Open Source Project for Android ANDROID_VERSION. This build
-includes a specific set of functionality and security fixes for the WebView [<a href="http://www.chromium.org/">Resources, 13</a>].</li>
+includes a specific set of functionality and security fixes for the WebView [<a href="http://www.chromium.org/">Resources, 16</a>].</li>
<li>The user agent string reported by the WebView MUST be in this format:
-<p>Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD)$(WEBVIEW))
+<p>Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv)
AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile
Safari/537.36</p>
<ul>
<li>The value of the $(VERSION) string MUST be the same as the value for
android.os.Build.VERSION.RELEASE.</li>
- <li>The $(WEBVIEW) string MAY be omitted, but if included MUST be "; wv" to
- note that this is a webview</li>
<li>The value of the $(MODEL) string MUST be the same as the value for
android.os.Build.MODEL.</li>
<li>The value of the $(BUILD) string MUST be the same as the value for
@@ -981,7 +1078,7 @@
<p>The WebView component SHOULD include support for as many HTML5 features as
possible and if it supports the feature SHOULD conform to the HTML5
-specification [<a href="http://html.spec.whatwg.org/multipage/">Resources, 14</a>].</p>
+specification [<a href="http://html.spec.whatwg.org/multipage/">Resources, 17</a>].</p>
<h3 id="3_4_2_browser_compatibility">3.4.2. Browser Compatibility</h3>
@@ -1003,17 +1100,17 @@
<p>The standalone Browser application (whether based on the upstream WebKit
Browser application or a third-party replacement) SHOULD include support for as
-much of HTML5 [<a href="http://html.spec.whatwg.org/multipage/">Resources, 14</a>] as possible. Minimally, device implementations MUST support each of these
+much of HTML5 [<a href="http://html.spec.whatwg.org/multipage/">Resources, 17</a>] as possible. Minimally, device implementations MUST support each of these
APIs associated with HTML5:</p>
<ul>
- <li>application cache/offline operation [<a href="http://www.w3.org/html/wg/drafts/html/master/browsers.html#offline">Resources, 15</a>]</li>
- <li>the <video> tag [<a href="http://www.w3.org/html/wg/drafts/html/master/semantics.html#video">Resources, 16</a>]</li>
- <li>geolocation [<a href="http://www.w3.org/TR/geolocation-API/">Resources, 17</a>]</li>
+ <li>application cache/offline operation [<a href="http://www.w3.org/html/wg/drafts/html/master/browsers.html#offline">Resources, 18</a>]</li>
+ <li>the <video> tag [<a href="http://www.w3.org/html/wg/drafts/html/master/semantics.html#video">Resources, 19</a>]</li>
+ <li>geolocation [<a href="http://www.w3.org/TR/geolocation-API/">Resources, 20</a>]</li>
</ul>
<p>Additionally, device implementations MUST support the HTML5/W3C webstorage API
-[<a href="http://www.w3.org/TR/webstorage/">Resources, 18</a>], and SHOULD support the HTML5/W3C IndexedDB API [<a href="http://www.w3.org/TR/IndexedDB/">Resources, 19</a>]. Note that as the web development standards bodies are transitioning to favor
+[<a href="http://www.w3.org/TR/webstorage/">Resources, 21</a>], and SHOULD support the HTML5/W3C IndexedDB API [<a href="http://www.w3.org/TR/IndexedDB/">Resources, 22</a>]. Note that as the web development standards bodies are transitioning to favor
IndexedDB over webstorage, IndexedDB is expected to become a required component
in a future version of Android.</p>
@@ -1098,7 +1195,7 @@
<p>Device implementations MUST support the full Dalvik Executable (DEX) format and
-Dalvik bytecode specification and semantics [<a href="https://android.googlesource.com/platform/dalvik/+/lollipop-release/docs/">Resources, 20</a>]. Device implementers SHOULD use ART, the reference upstream implementation of
+Dalvik bytecode specification and semantics [<a href="https://android.googlesource.com/platform/dalvik/">Resources, 23</a>]. Device implementers SHOULD use ART, the reference upstream implementation of
the Dalvik Executable Format, and the reference implementation’s package
management system.</p>
@@ -1116,7 +1213,52 @@
<th>Minimum Application Memory</th>
</tr>
<tr>
- <td rowspan="10">small/normal</td>
+ <td rowspan="12">Android Watch</td>
+ <td>120 dpi (ldpi)</td>
+ <td rowspan="3">32MB</td>
+ </tr>
+ <tr>
+ <td>160 dpi (mdpi)</td>
+ </tr>
+ <tr>
+ <td>213 dpi (tvdpi)</td>
+ </tr>
+ <tr>
+ <td>240 dpi (hdpi)</td>
+ <td rowspan="2">36MB</td>
+ </tr>
+ <tr>
+ <td>280 dpi (280dpi)</td>
+ </tr>
+ <tr>
+ <td>320 dpi (xhdpi)</td>
+ <td rowspan="2">48MB</td>
+ </tr>
+ <tr>
+ <td>360 dpi (360dpi)</td>
+ </tr>
+ <tr>
+ <td>400 dpi (400dpi)</td>
+ <td>56MB</td>
+ </tr>
+ <tr>
+ <td>420 dpi (420dpi)</td>
+ <td>64MB</td>
+ </tr>
+ <tr>
+ <td>480 dpi (xxhdpi)</td>
+ <td>88MB</td>
+ </tr>
+ <tr>
+ <td>560 dpi (560dpi)</td>
+ <td>112MB</td>
+ </tr>
+ <tr>
+ <td>640 dpi (xxxhdpi)</td>
+ <td>154MB</td>
+ </tr>
+ <tr>
+ <td rowspan="12">small/normal</td>
<td>120 dpi (ldpi)</td>
<td rowspan="2">32MB</td>
</tr>
@@ -1135,13 +1277,20 @@
</tr>
<tr>
<td>320 dpi (xhdpi)</td>
- <td>80MB</td>
+ <td rowspan="2">80MB</td>
+ </tr>
+ <tr>
+ <td>360 dpi (360dpi)</td>
</tr>
<tr>
<td>400 dpi (400dpi)</td>
<td>96MB</td>
</tr>
<tr>
+ <td>420 dpi (420dpi)</td>
+ <td>112MB</td>
+ </tr>
+ <tr>
<td>480 dpi (xxhdpi)</td>
<td>128MB</td>
</tr>
@@ -1154,7 +1303,7 @@
<td>256MB</td>
</tr>
<tr>
- <td rowspan="10">large</td>
+ <td rowspan="12">large</td>
<td>120 dpi (ldpi)</td>
<td>32MB</td>
</tr>
@@ -1178,10 +1327,18 @@
<td>128MB</td>
</tr>
<tr>
+ <td>360 dpi (360dpi)</td>
+ <td>160MB</td>
+ </tr>
+ <tr>
<td>400 dpi (400dpi)</td>
<td>192MB</td>
</tr>
<tr>
+ <td>420 dpi (420dpi)</td>
+ <td>228MB</td>
+ </tr>
+ <tr>
<td>480 dpi (xxhdpi)</td>
<td>256MB</td>
</tr>
@@ -1194,7 +1351,7 @@
<td>512MB</td>
</tr>
<tr>
- <td rowspan="10">xlarge</td>
+ <td rowspan="12">xlarge</td>
<td>120 dpi (ldpi)</td>
<td>48MB</td>
</tr>
@@ -1218,10 +1375,18 @@
<td>192MB</td>
</tr>
<tr>
+ <td>360 dpi (360dpi)</td>
+ <td>240MB</td>
+ </tr>
+ <tr>
<td>400 dpi (400dpi)</td>
<td>288MB</td>
</tr>
<tr>
+ <td>420 dpi (420dpi)</td>
+ <td>336MB</td>
+ </tr>
+ <tr>
<td>480 dpi (xxhdpi)</td>
<td>384MB</td>
</tr>
@@ -1256,7 +1421,7 @@
<p>Android defines a component type and corresponding API and lifecycle that
-allows applications to expose an “AppWidget” to the end user [<a href="http://developer.android.com/guide/practices/ui_guidelines/widget_design.html">Resources, 21</a>] a feature that is strongly RECOMMENDED to be supported on Handheld Device
+allows applications to expose an “AppWidget” to the end user [<a href="http://developer.android.com/guide/practices/ui_guidelines/widget_design.html">Resources, 24</a>] a feature that is STRONGLY RECOMMENDED to be supported on Handheld Device
implementations. Device implementations that support embedding widgets on the
home screen MUST meet the following requirements and declare support for
platform feature android.software.app_widgets.</p>
@@ -1267,7 +1432,7 @@
within the Launcher.</li>
<li>Device implementations MUST be capable of rendering widgets that are 4 x 4 in
the standard grid size. See the App Widget Design Guidelines in the Android SDK
-documentation [<a href="http://developer.android.com/guide/practices/ui_guidelines/widget_design.html">Resources, 21</a>] for details.</li>
+documentation [<a href="http://developer.android.com/guide/practices/ui_guidelines/widget_design.html">Resources, 24</a>] for details.</li>
<li>Device implementations that include support for lock screen MAY support
application widgets on the lock screen.</li>
</ul>
@@ -1275,7 +1440,7 @@
<h3 id="3_8_3_notifications">3.8.3. Notifications</h3>
-<p>Android includes APIs that allow developers to notify users of notable events [<a href="http://developer.android.com/guide/topics/ui/notifiers/notifications.html">Resources, 22</a>], using hardware and software features of the device.</p>
+<p>Android includes APIs that allow developers to notify users of notable events [<a href="http://developer.android.com/guide/topics/ui/notifiers/notifications.html">Resources, 25</a>], using hardware and software features of the device.</p>
<p>Some APIs allow applications to perform notifications or attract attention
using hardware—specifically sound, vibration, and light. Device implementations
@@ -1288,9 +1453,9 @@
<p>Additionally, the implementation MUST correctly render all resources (icons, animation files
etc.) provided for in the APIs
-[<a href="https://developer.android.com/guide/topics/resources/available-resources.html">Resources, 23</a>],
+[<a href="https://developer.android.com/guide/topics/resources/available-resources.html">Resources, 26</a>],
or in the Status/System Bar icon style guide
-[<a href="http://developer.android.com/design/style/iconography.html">Resources, 24</a>],
+[<a href="http://developer.android.com/design/style/iconography.html">Resources, 27</a>],
which in the case of an Android Television device includes the possibility to not display the
notifications. Device implementers MAY provide an alternative user experience for
notifications than that provided by the reference Android Open Source
@@ -1307,7 +1472,7 @@
<p>Android device implementations, when such notifications are made visible, MUST properly execute
Rich and Heads-up notifications and include the title/name, icon, text as documented in the Android
-APIs <a href="https://developer.android.com/design/patterns/notifications.html">[Resources, 25]</a>.
+APIs [<a href="https://developer.android.com/design/patterns/notifications.html">Resources, 28</a>].
</p>
<p>Android includes Notification Listener Service APIs that allow apps (once
@@ -1319,7 +1484,7 @@
<h3 id="3_8_4_search">3.8.4. Search</h3>
-<p>Android includes APIs [<a href="http://developer.android.com/reference/android/app/SearchManager.html">Resources, 26</a>] that allow developers to incorporate search into their applications, and
+<p>Android includes APIs [<a href="http://developer.android.com/reference/android/app/SearchManager.html">Resources, 29</a>] that allow developers to incorporate search into their applications, and
expose their application’s data into the global system search. Generally
speaking, this functionality consists of a single, system-wide user interface
that allows users to enter queries, displays suggestions as users type, and
@@ -1337,11 +1502,25 @@
applications are installed that make use of this functionality, the default
behavior SHOULD be to display web search engine results and suggestions.</p>
+<p>Android device implementations SHOULD implement an assistant on the device
+to handle the Assist action [<a
+href="http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST">Resources,
+30</a>].</p>
+
+<p>Android also includes the Assist APIs to allow applications to elect how much
+information of the current context is shared with the assistant on the device [<a
+href="https://developer.android.com/reference/android/app/assist/package-summary.html">Resources,
+31</a>]. Device implementations supporting the Assist action MUST indicate clearly to
+the end user when the the context is shared by displaying a white light around
+the edges of the screen. To ensure clear visibility to the end user, the indication MUST
+meet or exceed the duration and brightness of the Android Open Source Project
+implementation.</p>
+
<h3 id="3_8_5_toasts">3.8.5. Toasts</h3>
<p>Applications can use the “Toast” API to display short non-modal strings to the
-end user, that disappear after a brief period of time [<a href="http://developer.android.com/reference/android/widget/Toast.html">Resources, 27</a>]. Device implementations MUST display Toasts from applications to end users in
+end user, that disappear after a brief period of time [<a href="http://developer.android.com/reference/android/widget/Toast.html">Resources, 32</a>]. Device implementations MUST display Toasts from applications to end users in
some high-visibility manner.</p>
<h3 id="3_8_6_themes">3.8.6. Themes</h3>
@@ -1352,35 +1531,38 @@
<p>Android includes a “Holo” theme family as a set of defined styles for
application developers to use if they want to match the Holo theme look and
-feel as defined by the Android SDK [<a href="http://developer.android.com/guide/topics/ui/themes.html">Resources, 28</a>]. Device implementations MUST NOT alter any of the Holo theme attributes
-exposed to applications [<a href="http://developer.android.com/reference/android/R.style.html">Resources, 29</a>].</p>
+feel as defined by the Android SDK [<a href="http://developer.android.com/guide/topics/ui/themes.html">Resources, 33</a>]. Device implementations MUST NOT alter any of the Holo theme attributes
+exposed to applications [<a href="http://developer.android.com/reference/android/R.style.html">Resources, 34</a>].</p>
<p>Android includes a “Material” theme family as a set of defined styles for
application developers to use if they want to match the design theme’s look and
feel across the wide variety of different Android device types. Device
implementations MUST support the “Material” theme family and MUST NOT alter any
-of the Material theme attributes or their assets exposed to applications [<a href="http://developer.android.com/reference/android/R.style.html#Theme_Material">Resources, 30</a>].</p>
+of the Material theme attributes or their assets exposed to applications [<a href="http://developer.android.com/reference/android/R.style.html#Theme_Material">Resources, 35</a>].</p>
<p>Android also includes a “Device Default” theme family as a set of defined
styles for application developers to use if they want to match the look and
feel of the device theme as defined by the device implementer. Device
implementations MAY modify the Device Default theme attributes exposed to
-applications [<a href="http://developer.android.com/reference/android/R.style.html">Resources, 29</a>].</p>
+applications [<a href="http://developer.android.com/reference/android/R.style.html">Resources, 34</a>].</p>
-<p>Android supports a new variant theme with translucent system bars, which allows
+<p>Android supports a variant theme with translucent system bars, which allows
application developers to fill the area behind the status and navigation bar
with their app content. To enable a consistent developer experience in this
configuration, it is important the status bar icon style is maintained across
different device implementations. Therefore, Android device implementations
MUST use white for system status icons (such as signal strength and battery
level) and notifications issued by the system, unless the icon is indicating a
-problematic status [<a href="http://developer.android.com/reference/android/R.style.html">Resources, 29</a>].</p>
+problematic status or an app requests a light status bar using the
+SYSTEM_UI_FLAG_LIGHT_STATUS_BAR flag. When an app requests a light status bar,
+Android device implementations MUST change the color of the system status icons
+to black [<a href="http://developer.android.com/reference/android/R.style.html">Resources, 34</a>].</p>
<h3 id="3_8_7_live_wallpapers">3.8.7. Live Wallpapers</h3>
<p>Android defines a component type and corresponding API and lifecycle that
-allows applications to expose one or more “Live Wallpapers” to the end user [<a href="http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html">Resources, 31</a>]. Live wallpapers are animations, patterns, or similar images with limited
+allows applications to expose one or more “Live Wallpapers” to the end user [<a href="http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html">Resources, 36</a>]. Live wallpapers are animations, patterns, or similar images with limited
input capabilities that display as a wallpaper, behind other applications.</p>
<p>Hardware is considered capable of reliably running live wallpapers if it can
@@ -1407,7 +1589,7 @@
</div>
-<p>The upstream Android source code includes the overview screen [<a href="http://developer.android.com/guide/components/recents.html">Resources, 32</a>], a system-level user interface for task switching and displaying recently
+<p>The upstream Android source code includes the overview screen [<a href="http://developer.android.com/guide/components/recents.html">Resources, 37</a>], a system-level user interface for task switching and displaying recently
accessed activities and tasks using a thumbnail image of the application’s
graphical state at the moment the user last left the application. Device
implementations including the recents function navigation key as detailed in <a href="#7_2_3_navigation_keys">section 7.2.3</a>, MAY alter the interface but MUST meet the following requirements:</p>
@@ -1417,19 +1599,19 @@
<li>MUST support at least up to 20 displayed activities.</li>
<li>MUST at least display the title of 4 activities at a time.</li>
<li>SHOULD display highlight color, icon, screen title in recents.</li>
- <li>MUST implement the screen pinning behavior [<a href="http://developer.android.com/about/versions/android-5.0.html#ScreenPinning">Resources, 33</a>] and provide the user with a settings menu to toggle the feature.</li>
+ <li>MUST implement the screen pinning behavior [<a href="http://developer.android.com/about/versions/android-5.0.html#ScreenPinning">Resources, 38</a>] and provide the user with a settings menu to toggle the feature.</li>
<li>SHOULD display a closing affordance ("x") but MAY delay this until user
interacts with screens.</li>
</ul>
-<p>Device implementations are STRONGLY ENCOURAGED to use the upstream Android user
+<p>Device implementations are STRONGLY RECOMMENDED to use the upstream Android user
interface (or a similar thumbnail-based interface) for the overview screen.</p>
<h3 id="3_8_9_input_management">3.8.9. Input Management</h3>
<p>Android includes support for Input Management and support for third-party input
-method editors [<a href="http://developer.android.com/guide/topics/text/creating-input-method.html">Resources, 34</a>]. Device implementations that allow users to use third-party input methods on
+method editors [<a href="http://developer.android.com/guide/topics/text/creating-input-method.html">Resources, 39</a>]. Device implementations that allow users to use third-party input methods on
the device MUST declare the platform feature android.software.input_methods and
support IME APIs as defined in the Android SDK documentation.</p>
@@ -1443,7 +1625,7 @@
<p>The Remote Control Client API is deprecated from Android 5.0 in favor of the
Media Notification Template that allows media applications to integrate with
-playback controls that are displayed on the lock screen [<a href="http://developer.android.com/reference/android/app/Notification.MediaStyle.html">Resources, 35</a>].
+playback controls that are displayed on the lock screen [<a href="http://developer.android.com/reference/android/app/Notification.MediaStyle.html">Resources, 40</a>].
Device implementations that support a lock screen, unless an Android Automotive or Watch
implementation, MUST display the Lockscreen Notifications including the Media Notification
Template.</p>
@@ -1451,7 +1633,7 @@
<h3 id="3_8_11_dreams">3.8.11. Dreams</h3>
-<p>Android includes support for interactive screensavers called Dreams [<a href="http://developer.android.com/reference/android/service/dreams/DreamService.html">Resources, 36</a>]. Dreams allows users to interact with applications when a device connected to
+<p>Android includes support for interactive screensavers called Dreams [<a href="http://developer.android.com/reference/android/service/dreams/DreamService.html">Resources, 41</a>]. Dreams allows users to interact with applications when a device connected to
a power source is idle or docked in a desk dock. Android Watch devices MAY
implement Dreams, but other types of device implementations SHOULD include
support for Dreams and provide a settings option for users to configure Dreams
@@ -1462,14 +1644,14 @@
<p>When a device has a hardware sensor (e.g. GPS) that is capable of providing the
location coordinates, location modes MUST be displayed in the Location menu
-within Settings [<a href="http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE">Resources, 37</a>].</p>
+within Settings [<a href="http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE">Resources, 42</a>].</p>
<h3 id="3_8_13_unicode_and_font">3.8.13. Unicode and Font</h3>
<p>Android includes support for color emoji characters. When Android device
implementations include an IME, devices SHOULD provide an input method to the
-user for the Emoji characters defined in Unicode 6.1 [<a href="http://www.unicode.org/versions/Unicode6.1.0/">Resources, 38</a>]. All devices MUST be capable of rendering these emoji characters in color glyph.</p>
+user for the Emoji characters defined in Unicode 6.1 [<a href="http://www.unicode.org/versions/Unicode6.1.0/">Resources, 43</a>]. All devices MUST be capable of rendering these emoji characters in color glyph.</p>
<p>Android includes support for Roboto 2 font with different
weights—sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black,
@@ -1480,22 +1662,102 @@
<h2 id="3_9_device_administration">3.9. Device Administration</h2>
-
<p>Android includes features that allow security-aware applications to perform
device administration functions at the system level, such as enforcing password
policies or performing remote wipe, through the Android Device Administration
-API [<a href="http://developer.android.com/guide/topics/admin/device-admin.html">Resources, 39</a>].
+API [<a href="http://developer.android.com/guide/topics/admin/device-admin.html">Resources, 44</a>].
Device implementations MUST provide an implementation of the DevicePolicyManager class
-[<a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html">Resources, 40</a>].
+[<a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html">Resources, 45</a>].
Device implementations that include support for PIN (numeric) or PASSWORD
(alphanumeric) based lock screens MUST support the full range of device
administration policies defined in the Android SDK documentation
-[<a href="http://developer.android.com/guide/topics/admin/device-admin.html">Resources, 39</a>]
+[<a href="http://developer.android.com/guide/topics/admin/device-admin.html">Resources, 44</a>]
and report the platform feature android.software.device_admin.</p>
-<p>Device implementations MAY have a preinstalled application performing device
-administration functions but this application MUST NOT be set out-of-the box as
-the default Device Owner app [<a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)">Resources, 41</a>].</p>
+<h3 id="3_9_1_device_provisioning">3.9.1 Device Provisioning</h3>
+<h4 id="3_9_1_1_device_owner_provisioning">3.9.1.1 Device owner provisioning</h4>
+<p>If a device implementation declares the android.software.device_admin feature,
+the out of box setup flow MUST make it possible to enroll a Device Policy
+Controller (DPC) application as the Device Owner app
+[<a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)">
+Resources, 46</a>]. Device implementations MAY have a preinstalled application
+performing device administration functions but this application MUST NOT be set
+as the Device Owner app without explicit consent or action from the user or the
+administrator of the device.</p>
+
+<p>The device owner provisioning process (the flow initiated by
+android.app.action.PROVISION_MANAGED_DEVICE
+[<a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_DEVICE">
+Resources, 47</a>]) user experience MUST align with the AOSP implementation</p>
+
+<p>If the device implementation reports android.hardware.nfc, it MUST have NFC
+enabled, even during the out-of-box setup flow, in order to allow for NFC
+provisioning of Device owners
+[<a href="https://source.android.com/devices/tech/admin/provision.html#device_owner_provisioning_via_nfc">Resources, 48</a>].
+</p>
+
+<h4 id="3_9_1_2_managed_profile_provisioning">3.9.1.2 Managed profile provisioning</h4>
+<p>If a device implementation declares the android.software.managed_users,
+it MUST be possible to enroll a Device Policy Controller (DPC) application
+as the owner of a new Managed Profile
+[<a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isProfileOwnerApp(java.lang.String)">
+Resources, 49</a>]</p>
+
+<p>The managed profile provisioning process (the flow initiated by
+android.app.action.PROVISION_MANAGED_PROFILE
+[<a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_PROFILE">
+Resources, 50</a>]) user experience MUST align with the AOSP implementation
+</p>
+
+
+<h2 id="3_9_2_managed_profile_support">3.9.2 Managed Profile Support</h2>
+
+<p>Managed profile capable devices are those devices that:</p>
+<ul>
+ <li>Declare android.software.device_admin (see <a href="#3_9_device_administration">section 3.9 Device Administration)</a></li>
+ <li>Are not low RAM devices (see <a href="#7_6_1_minimum_memory_and_storage">section 7.6.1</a></li>
+ <li>Allocate internal (non-removable) storage as shared storage (see
+ <a href="#7_6_2_application_shared_storage">section 7.6.2</a>)</li>
+</ul>
+<p>Managed profile capable devices MUST:</p>
+<ul>
+ <li>Declare the platform feature flag android.software.managed_users.</li>
+ <li>Support managed profiles via the android.app.admin.DevicePolicyManager APIs</li>
+ <li>Allow one and only one managed profile to be created [<a
+href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_PROFILE">Resources,
+50</a>]</li>
+ <li>Use an icon badge (similar to the AOSP upstream work badge) to represent
+the managed applications and widgets and other badged UI elements like Recents
+& Notifications</li>
+ <li>Display a notification icon (similar to the AOSP upstream work badge) to
+indicate when user is within a managed profile application</li>
+ <li>Display a toast indicating that the user is in the managed profile if and when the
+device wakes up (ACTION_USER_PRESENT) and the foreground application is within
+the managed profile</li>
+ <li>Where a managed profile exists, show a visual affordance in the Intent
+'Chooser' to allow the user to forward the intent from the managed profile to
+the primary user or vice versa, if enabled by the Device Policy Controller</li>
+ <li>Where a managed profile exists, expose the following user affordances for both
+the primary user and the managed profile:
+ <ul>
+ <li>Separate accounting for battery, location, mobile data and storage usage
+ for the primary user and managed profile.</li>
+ <li>Independent management of VPN Applications installed within the primary
+ user or managed profile.</li>
+ <li>Independent management of applications installed within the primary user
+ user or managed profile.</li>
+ <li>Independent management of accounts within the primary user or managed
+ profile.</li>
+ </ul>
+ </li>
+ <li>Ensure the default dialer can look up caller information from the managed
+profile (if one exists) alongside those from the primary profile, if the Device
+Policy Controller permits it.</li>
+ <li>MUST ensure that it satisfies all the security requirements applicable for a device
+ with multiple users enabled (see <a href="#9_5_multi-user_support">section 9.5</a>),
+ even though the managed profile is not counted as another user in addition to the
+ primary user.</li>
+</ul>
<h2 id="3_10_accessibility">3.10. Accessibility</h2>
@@ -1504,7 +1766,7 @@
navigate their devices more easily. In addition, Android provides platform APIs
that enable accessibility service implementations to receive callbacks for user
and system events and generate alternate feedback mechanisms, such as
-text-to-speech, haptic feedback, and trackball/d-pad navigation [<a href="http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html">Resources, 42</a>].</p>
+text-to-speech, haptic feedback, and trackball/d-pad navigation [<a href="http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html">Resources, 51</a>].</p>
<p>Device implementations include the following requirements:</p>
@@ -1518,7 +1780,7 @@
<li>Device implementations (Android Automotive excluded) MUST support
third-party accessibility service implementations through the
android.accessibilityservice APIs
-[<a href="http://developer.android.com/reference/android/view/accessibility/package-summary.html">Resources, 43</a>]</li>
+[<a href="http://developer.android.com/reference/android/view/accessibility/package-summary.html">Resources, 52</a>]</li>
<li>Device implementations (Android Automotive excluded) MUST generate
AccessibilityEvents and deliver these events to all registered
AccessibilityService implementations in a manner consistent with the default
@@ -1533,14 +1795,14 @@
accessibility service on the device, and SHOULD provide a mechanism for users
to enable the accessibility service during device setup. An open source
implementation of an accessibility service is available from the Eyes Free
-project [<a href="http://code.google.com/p/eyes-free/">Resources, 44</a>].</p>
+project [<a href="http://code.google.com/p/eyes-free/">Resources, 53</a>].</p>
<h2 id="3_11_text-to-speech">3.11. Text-to-Speech</h2>
<p>Android includes APIs that allow applications to make use of text-to-speech
(TTS) services and allows service providers to provide implementations of TTS
-services [<a href="http://developer.android.com/reference/android/speech/tts/package-summary.html">Resources, 45</a>]. Device implementations reporting the feature android.hardware.audio.output
+services [<a href="http://developer.android.com/reference/android/speech/tts/package-summary.html">Resources, 54</a>]. Device implementations reporting the feature android.hardware.audio.output
MUST meet these requirements related to the Android TTS framework. </p>
<p>Android Automotive implementations:</p>
@@ -1569,18 +1831,79 @@
<p>The Android Television Input Framework (TIF) simplifies the delivery of live
content to Android Television devices. TIF provides a standard API to create
input modules that control Android Television devices. Android Television
-device implementations MUST support Television Input Framework [<a href="http://source.android.com/devices/tv/index.html">Resources, 46</a>].</p>
+device implementations MUST support TV Input Framework
+[<a href="http://source.android.com/devices/tv/index.html">Resources, 55</a>].</p>
<p>Device implementations that support TIF MUST declare the platform feature
android.software.live_tv.</p>
+<h3 id="3_12_1_tv_app">3.12.1. TV App</h3>
+
+<p>Any device implementation that declares support for Live TV MUST have an
+installed TV application (TV App). The Android Open Source Project provides an implementation of the TV
+App.</p>
+
+<p>The TV App MUST provide facilities to install and use TV Channels
+[<a href="http://developer.android.com/reference/android/media/tv/TvContract.Channels.html">Resources, 56</a>]
+ and meet the following requirements:</p>
+
+<ul>
+ <li>Device implementations MUST allow third-party TIF-based inputs (third-party inputs)
+[<a href="https://source.android.com/devices/tv/index.html#third-party_input_example">Resources, 57</a>]
+ to be installed and managed.
+ <li>Device implementations MAY provide visual separation between pre-installed
+ TIF-based inputs (installed inputs)
+[<a href="https://source.android.com/devices/tv/index.html#tv_inputs">Resources, 58</a>]
+ and third-party inputs.
+ <li>The device implementations MUST NOT display the third-party inputs more than a
+single navigation action away from the TV App (i.e. expanding a list of
+third-party inputs from the TV App).
+</ul>
+
+<h4 id="3_12_1_1_electronic_program_guide">3.12.1.1. Electronic Program Guide</h4>
+
+<p>Android Television device implementations MUST show an informational and
+interactive overlay, which MUST include an electronic program guide (EPG)
+generated from the values in the TvContract.Programs fields
+[<a href="https://developer.android.com/reference/android/media/tv/TvContract.Programs.html">Resources, 59</a>].
+ The EPG MUST meet the following requirements:</p>
+
+<ul>
+ <li>The EPG MUST display information from all installed inputs and third-party
+inputs.
+ <li>The EPG MAY provide visual separation between the installed inputs and
+third-party inputs.
+ <li>The EPG is STRONGLY RECOMMENDED to display installed inputs and third-party
+inputs with equal prominence. The EPG MUST NOT display the third-party inputs
+more than a single navigation action away from the installed inputs on the EPG.
+ <li>On channel change, device implementations MUST display EPG data for the
+currently playing program.
+</ul>
+
+<h4 id="3_12_1_2_navigation">3.12.1.2. Navigation</h4>
+
+<p>Android Television device input devices (i.e. remote control, remote control
+application, or game controller) MUST allow navigation to all actionable
+sections of the screen via the D-pad. D-pad up and down MUST be used to change
+live TV channels when there is no actionable section on the screen.</p>
+
+<p>The TV App SHOULD pass key events to HDMI inputs through CEC.</p>
+
+<h4 id="3_12_1_3_tv_input_app_linking">3.12.1.3. TV input app linking</h4>
+
+<p>Android Television device implementations MUST support TV input app linking,
+which allows all inputs to provide activity links from the current activity to
+another activity (i.e. a link from live programming to related content)
+[<a href="http://developer.android.com/reference/android/media/tv/TvContract.Channels.html#COLUMN_APP_LINK_INTENT_URI">Resources, 60</a>].
+ The TV App MUST show TV input app linking when it is provided.</p>
+
<h1 id="4_application_packaging_compatibility">4. Application Packaging Compatibility</h1>
<p>Device implementations MUST install and run Android “.apk” files as generated
-by the “aapt” tool included in the official Android SDK [<a href="http://developer.android.com/tools/help/index.html">Resources, 47</a>].</p>
+by the “aapt” tool included in the official Android SDK [<a href="http://developer.android.com/tools/help/index.html">Resources, 61</a>].</p>
-<p>Devices implementations MUST NOT extend either the .apk [<a href="http://developer.android.com/guide/components/fundamentals.html">Resources, 48</a>], Android Manifest [<a href="http://developer.android.com/guide/topics/manifest/manifest-intro.html">Resources, 49</a>], Dalvik bytecode [<a href="https://android.googlesource.com/platform/dalvik/+/lollipop-release/docs/">Resources, 20</a>], or RenderScript bytecode formats in such a way that would prevent those
+<p>Devices implementations MUST NOT extend either the .apk [<a href="http://developer.android.com/guide/components/fundamentals.html">Resources, 62</a>], Android Manifest [<a href="http://developer.android.com/guide/topics/manifest/manifest-intro.html">Resources, 49</a>], Dalvik bytecode [<a href="https://android.googlesource.com/platform/dalvik/">Resources, 23</a>], or RenderScript bytecode formats in such a way that would prevent those
files from installing and running correctly on other compatible devices.</p>
<h1 id="5_multimedia_compatibility">5. Multimedia Compatibility</h1>
@@ -1590,13 +1913,14 @@
<p>Device implementations MUST support the core media formats specified in the
-Android SDK documentation [<a href="http://developer.android.com/guide/appendix/media-formats.html">Resources, 50</a>] except where explicitly permitted in this document. Specifically, device
+Android SDK documentation [<a href="http://developer.android.com/guide/appendix/media-formats.html">Resources, 64</a>]
+except where explicitly permitted in this document. Specifically, device
implementations MUST support the media formats, encoders, decoders, file types,
and container formats defined in the tables below and reported via MediaCodecList
-[<a href="http://developer.android.com/reference/android/media/MediaCodecList.html">Resources,112</a>].
+[<a href="http://developer.android.com/reference/android/media/MediaCodecList.html">Resources, 65</a>].
Device implementations MUST also be able to decode all profiles reported in its CamcorderProfile
[<a href="http://developer.android.com/reference/android/media/CamcorderProfile.html">Resources,
-113</a>].
+66</a>] and MUST be able to decode all formats it can encode.
All of these codecs are
provided as software implementations in the preferred Android implementation
@@ -1619,9 +1943,9 @@
<th>Supported File Types/Container Formats</th>
</tr>
<tr>
- <td>MPEG-4 AAC Profile</p>
+ <td>MPEG-4 AAC Profile<br />
-<p>(AAC LC)</td>
+(AAC LC)</td>
<td>REQUIRED<sup>1</sup></td>
<td>REQUIRED</td>
<td>Support for mono/stereo/5.0/5.1<sup>2</sup> content with standard sampling rates from 8 to
@@ -1643,9 +1967,9 @@
<td></td>
</tr>
<tr>
- <td>MPEG-4 HE AACv2</p>
+ <td>MPEG-4 HE AACv2<br />
-<p>Profile (enhanced AAC+)</td>
+Profile (enhanced AAC+)</td>
<td> </td>
<td>REQUIRED</td>
<td>Support for mono/stereo/5.0/5.1<sup>2</sup> content with standard sampling rates from 16
@@ -1654,12 +1978,12 @@
</tr>
<tr>
<td>AAC ELD (enhanced low delay AAC)</td>
- <td>REQUIRED<sup>1</sup> </p>
+ <td>REQUIRED<sup>1</sup> <br />
-<p>(Android 4.1+)</td>
- <td>REQUIRED</p>
+(Android 4.1+)</td>
+ <td>REQUIRED<br />
-<p>(Android 4.1+)</td>
+(Android 4.1+)</td>
<td>Support for mono/stereo content with standard sampling rates from 16 to 48 kHz.</td>
<td></td>
</tr>
@@ -1667,14 +1991,14 @@
<td>AMR-NB</td>
<td>REQUIRED<sup>3</sup></td>
<td>REQUIRED<sup>3</sup></td>
- <td>4.75 to 12.2 kbps sampled @ 8kHz</td>
+ <td>4.75 to 12.2 kbps sampled @ 8 kHz</td>
<td>3GPP (.3gp)</td>
</tr>
<tr>
<td>AMR-WB</td>
<td>REQUIRED<sup>3</sup></td>
<td>REQUIRED<sup>3</sup></td>
- <td>9 rates from 6.60 kbit/s to 23.85 kbit/s sampled @ 16kHz</td>
+ <td>9 rates from 6.60 kbit/s to 23.85 kbit/s sampled @ 16 kHz</td>
<td></td>
</tr>
<tr>
@@ -1682,8 +2006,8 @@
<td></td>
<td>REQUIRED <br>(Android 3.1+)</td>
<td>Mono/Stereo (no multichannel). Sample rates up to 48 kHz (but up to 44.1 kHz is
-recommended on devices with 44.1 kHz output, as the 48 to 44.1 kHz downsampler
-does not include a low-pass filter). 16-bit recommended; no dither applied for
+RECOMMENDED on devices with 44.1 kHz output, as the 48 to 44.1 kHz downsampler
+does not include a low-pass filter). 16-bit RECOMMENDED; no dither applied for
24-bit.</td>
<td>FLAC (.flac) only</td>
</tr>
@@ -1795,8 +2119,6 @@
<h3 id="5_1_3_video_codecs">5.1.3. Video Codecs</h3>
-<p>Video codecs are optional for Android Watch device implementations.</p>
-
<table>
<tr>
<th>Format/Codec</th>
@@ -1822,7 +2144,7 @@
<td><ul>
<li class="table_list">3GPP (.3gp)</li>
<li class="table_list">MPEG-4 (.mp4)</li>
- <li class="table_list">MPEG-TS (.ts, AAC audio only, not seekable, Android 3.0+)</li></ul></td>
+ <li class="table_list">MPEG-2 TS (.ts, AAC audio only, not seekable, Android 3.0+)</li></ul></td>
</tr>
<tr>
<td>H.265 HEVC</td>
@@ -1831,6 +2153,13 @@
<td>See <a href="#5_3_video_decoding">section 5.3</a> for details</td>
<td>MPEG-4 (.mp4)</td>
</tr>
+<tr>
+ <td>MPEG-2</td>
+ <td></td>
+ <td>STRONGLY RECOMMENDED<sup>6</sup></td>
+ <td>Main Profile</td>
+ <td>MPEG2-TS</td>
+</tr>
<tr>
<td>MPEG-4 SP</td>
<td></td>
@@ -1840,15 +2169,15 @@
</tr>
<tr>
<td>VP8<sup>3</sup></td>
- <td>REQUIRED<sup>2</sup></p>
+ <td>REQUIRED<sup>2</sup><br />
-<p>(Android 4.3+)</td>
- <td>REQUIRED<sup>2</sup></p>
+(Android 4.3+)</td>
+ <td>REQUIRED<sup>2</sup><br />
-<p>(Android 2.3.3+)</td>
+(Android 2.3.3+)</td>
<td>See <a href="#5_2_video_encoding">section 5.2</a> and <a href="#5_3_video_decoding">5.3</a> for details</td>
<td><ul>
- <li class="table_list">WebM (.webm) [<a href="http://www.webmproject.org/">Resources, 110</a></li>
+ <li class="table_list">WebM (.webm) [<a href="http://www.webmproject.org/">Resources, 67</a></li>
<li class="table_list">Matroska (.mkv, Android 4.0+)<sup>4</sup></li></ul></td>
</tr>
<tr>
@@ -1857,7 +2186,7 @@
<td>REQUIRED<sup>2</sup><br> (Android 4.4+)</td>
<td>See <a href="#5_3_video_decoding">section 5.3</a> for details</td>
<td><ul>
- <li class="table_list">WebM (.webm) [<a href="http://www.webmproject.org/">Resources, 110</a>]</li>
+ <li class="table_list">WebM (.webm) [<a href="http://www.webmproject.org/">Resources, 67</a>]</li>
<li class="table_list">Matroska (.mkv, Android 4.0+)<sup>4</sup></li></ul></td>
</tr>
</table>
@@ -1870,11 +2199,13 @@
<p class="table_footnote">3 For acceptable quality of web video streaming and video-conference services,
device implementations SHOULD use a hardware VP8 codec that meets the
-requirements in [<a href="http://www.webmproject.org/hardware/rtc-coding-requirements/">Resources, 51</a>].</p>
+requirements in [<a href="http://www.webmproject.org/hardware/rtc-coding-requirements/">Resources, 68</a>].</p>
<p class="table_footnote">4 Device implementations SHOULD support writing Matroska WebM files.</p>
-<p class="table_footnote">5 Strongly recommended for Android Automotive, optional for Android Watch, and required for all other device types.</p>
+<p class="table_footnote">5 STRONGLY RECOMMENDED for Android Automotive, optional for Android Watch, and required for all other device types.</p>
+
+<p class="table_footnote">6 Applies only to Android Television device implementations.</p>
<h2 id="5_2_video_encoding">5.2. Video Encoding</h2>
@@ -1882,19 +2213,20 @@
<p>Video codecs are optional for Android Watch device implementations.</p>
</div>
+<p>Android device implementations with H.263 encoders, MUST support Baseline Profile Level 45.</p>
<p>Android device implementations with H.264 codec support, MUST support Baseline
Profile Level 3 and the following SD (Standard Definition) video encoding
profiles and SHOULD support Main Profile Level 4 and the following HD (High
-Definition) video encoding profiles. Android Television devices are STRONGLY
-RECOMMENDED to encode HD 1080p video at 30 fps.</p>
+Definition) video encoding profiles. Android Television devices are STRONGLY RECOMMENDED
+to encode HD 1080p video at 30 fps.</p>
<table>
<tr>
<th></th>
<th>SD (Low quality)</th>
<th>SD (High quality)</th>
- <th>HD 720p1</th>
- <th>HD 1080p1</th>
+ <th>HD 720p<sup>1</sup></th>
+ <th>HD 1080p<sup>1</sup></th>
</tr>
<tr>
<th>Video resolution</th>
@@ -1931,8 +2263,8 @@
<th></th>
<th>SD (Low quality)</th>
<th>SD (High quality)</th>
- <th>HD 720p1</th>
- <th>HD 1080p1</th>
+ <th>HD 720p<sup>1</sup></th>
+ <th>HD 1080p<sup>1</sup></th>
</tr>
<tr>
<th>Video resolution</th>
@@ -1965,22 +2297,28 @@
<p>Video codecs are optional for Android Watch device implementations.</p>
</div>
+<p>Device implementations MUST support dynamic video resolution and frame rate
+switching through the standard Android APIs within the same stream for all VP8,
+VP9, H.264, and H.265 codecs in real time and up to the maximum resolution
+supported on the device.</p>
-<p>Device implementations MUST support dynamic video resolution switching within
-the same stream for all VP8, VP9, H.264, and H.265 codecs exposed through the
-standard Android APIs.</p>
+<p>Android device implementations with H.263 decoders, MUST support Baseline
+Profile Level 30.</p>
-<p>Android device implementations with H.264 decoders, MUST support Baseline
-Profile Level 3 and the following SD video decoding profiles and SHOULD support
-the HD decoding profiles. Android Television devices MUST support High Profile
+<p>Android device implementations with MPEG-4 decoders, MUST support Simple
+Profile Level 3.</p>
+
+<p>Android device implementations with H.264 decoders, MUST support Main Profile
+Level 3.1 and the following SD video decoding profiles and SHOULD support the
+HD decoding profiles. Android Television devices MUST support High Profile
Level 4.2 and the HD 1080p decoding profile.</p>
<table>
<tr>
<th></th>
<th>SD (Low quality)</th>
<th>SD (High quality)</th>
- <th>HD 720p1</th>
- <th>HD 1080p1</th>
+ <th>HD 720p<sup>1</sup></th>
+ <th>HD 1080p<sup>1</sup></th>
</tr>
<tr>
<th>Video resolution</th>
@@ -1993,8 +2331,8 @@
<th>Video frame rate</th>
<td>30 fps</td>
<td>30 fps</td>
- <td>30 fps / 60 fps2</td>
- <td>30 fps / 60 fps2</td>
+ <td>60 fps</td>
+ <td>30 fps / 60 fps<sup>2</sup></td>
</tr>
<tr>
<th>Video bitrate</th>
@@ -2006,10 +2344,10 @@
</table>
-<p class="table_footnote">1 Required for Android Television device implementations, but for other device
-types only when supported by hardware.</p>
+<p class="table_footnote">1 REQUIRED for when the height as reported by the
+Display.getSupportedModes() method is not smaller than the video resolution.</p>
-<p class="table_footnote">2 Required for Android Television device implementations.</p>
+<p class="table_footnote">2 REQUIRED for Android Television device implementations.</p>
<p>Android device implementations when supporting VP8 codec as described in <a href="#5_1_3_video_codecs">section 5.1.3</a>, MUST support the following SD decoding profiles and SHOULD support the HD
decoding profiles. Android Television devices MUST support the HD 1080p
@@ -2019,8 +2357,8 @@
<th></th>
<th>SD (Low quality)</th>
<th>SD (High quality)</th>
- <th>HD 720p1</th>
- <th>HD 1080p1</th>
+ <th>HD 720p<sup>1</sup></th>
+ <th>HD 1080p<sup>1</sup></th>
</tr>
<tr>
<th>Video resolution</th>
@@ -2033,8 +2371,8 @@
<th>Video frame rate</th>
<td>30 fps</td>
<td>30 fps</td>
- <td>30 fps / 60 fps2</td>
- <td>30 / 60 fps2</td>
+ <td>30 fps / 60 fps<sup>2</sup></td>
+ <td>30 / 60 fps<sup>2</sup></td>
</tr>
<tr>
<th>Video bitrate</th>
@@ -2045,25 +2383,24 @@
</tr>
</table>
+<p class="table_footnote">1 REQUIRED for when the height as reported by the
+Display.getSupportedModes() method is not smaller than the video resolution.</p>
-<p class="table_footnote">1 Required for Android Television device implementations, but for other type of
-devices only when supported by hardware.</p>
-
-<p class="table_footnote">2 Required for Android Television device implementations.</p>
+<p class="table_footnote">2 REQUIRED for Android Television device implementations.</p>
<p>Android device implementations, when supporting VP9 codec as described in <a href="#5_1_3_video_codecs">section 5.1.3</a>, MUST support the following SD video decoding profiles and SHOULD support the
HD decoding profiles. Android Television devices are STRONGLY RECOMMENDED to
support the HD 1080p decoding profile and SHOULD support the UHD decoding
-profile. When the UHD video decoding profile is supported, it MUST support 8
-bit color depth.</p>
+profile. When the UHD video decoding profile is supported, it MUST support 8-bit
+color depth and SHOULD support VP9 Profile 2 (10-bit).</p>
<table>
<tr>
<th></th>
<th>SD (Low quality)</th>
<th>SD (High quality)</th>
- <th>HD 720p 1</th>
- <th>HD 1080p 2</th>
- <th>UHD 2</th>
+ <th>HD 720p<sup>1</sup></th>
+ <th>HD 1080p<sup>2</sup></th>
+ <th>UHD<sup>2</sup></th>
</tr>
<tr>
<th>Video resolution</th>
@@ -2078,12 +2415,12 @@
<td>30 fps</td>
<td>30 fps</td>
<td>30 fps</td>
- <td>30 fps</td>
- <td>30 fps</td>
+ <td>60 fps</td>
+ <td>60 fps</td>
</tr>
<tr>
<th>Video bitrate</th>
- <td>600 Kbps </td>
+ <td>600 Kbps</td>
<td>1.6 Mbps</td>
<td>4 Mbps</td>
<td>10 Mbps</td>
@@ -2095,7 +2432,7 @@
<p class="table_footnote">1 Required for Android Television device implementations, but for other type of
devices only when supported by hardware.</p>
-<p class="table_footnote">2 STRONGLY RECOMMENDED for Android Television device implementations when
+<p class="table_footnote">2 STRONGLY RECOMMENDED for existing Android Television device implementations when
supported by hardware.</p>
<p>Android device implementations, when supporting H.265 codec as described in <a href="#5_1_3_video_codecs">section 5.1.3</a>, MUST support the Main Profile Level 3 Main tier and the following SD video
@@ -2108,9 +2445,9 @@
<th></th>
<th>SD (Low quality)</th>
<th>SD (High quality)</th>
- <th>HD 720p </strong>1 </td>
- <th>HD 1080p </strong>1 </td>
- <th>UHD </strong>2</td>
+ <th>HD 720p<sup>1</sup></th>
+ <th>HD 1080p<sup>1</sup></th>
+ <th>UHD<sup>2</sup></th>
</tr>
<tr>
<th>Video resolution</th>
@@ -2125,8 +2462,8 @@
<td>30 fps</td>
<td>30 fps</td>
<td>30 fps</td>
- <td>30 fps</td>
- <td>30 fps</td>
+ <td>60 fps<sup>2</sup></td>
+ <td>60 fps</td>
</tr>
<tr>
<th>Video bitrate</th>
@@ -2139,19 +2476,20 @@
</table>
-<p class="table_footnote">1 Required for Android Television device implementation, but for other type of
+<p class="table_footnote">1 Required for Android Television device implementations, but for other type of
devices only when supported by hardware.</p>
-<p class="table_footnote">2 Required for Android Television device implementations when supported by
-hardware.</p>
+<p class="table_footnote">2 STRONGLY RECOMMENDED
+for existing Android Television device implementations when supported by hardware.</p>
<h2 id="5_4_audio_recording">5.4. Audio Recording</h2>
<p>While some of the requirements outlined in this section are stated as SHOULD
since Android 4.3, the Compatibility Definition for a future version is planned
-to change these to MUST. Existing and new Android devices are <strong>very strongly encouraged</strong> to meet these requirements, or they will not be able to attain Android
-compatibility when upgraded to the future version.</p>
+to change these to MUST. Existing and new Android devices are <strong>STRONGLY RECOMMENDED</strong>
+to meet these requirements, or they will not be able to attain Android compatibility when upgraded
+to the future version.</p>
<h3 id="5_4_1_raw_audio_capture">5.4.1. Raw Audio Capture</h3>
@@ -2165,6 +2503,9 @@
<li><strong>Channels</strong>: Mono
</ul>
+<p>The capture for the above sample rates MUST be done without up-sampling, and
+any down-sampling MUST include an appropriate anti-aliasing filter.</p>
+
<p>Device implementations that declare android.hardware.microphone SHOULD allow
capture of raw audio content with the following characteristics:</p>
@@ -2174,6 +2515,11 @@
<li><strong>Channels</strong>: Stereo
</ul>
+<p>If capture for the above sample rates is supported,
+then the capture MUST be done without up-sampling at any ratio higher than 16000:22050
+or 44100:48000.
+Any up-sampling or down-sampling MUST include an appropriate anti-aliasing filter.</p>
+
<h3 id="5_4_2_capture_for_voice_recognition">5.4.2. Capture for Voice Recognition</h3>
@@ -2183,12 +2529,12 @@
<ul>
<li>The device SHOULD exhibit approximately flat amplitude versus frequency
-characteristics: specifically, ±3 dB, from 100 Hz to 4000 Hz.
+characteristics: specifically, ±3 dB, from 100 Hz to 4000 Hz.
<li>Audio input sensitivity SHOULD be set such that a 90 dB sound power level (SPL)
source at 1000 Hz yields RMS of 2500 for 16-bit samples.
<li>PCM amplitude levels SHOULD linearly track input SPL changes over at least a 30
dB range from -18 dB to +12 dB re 90 dB SPL at the microphone.
- <li>Total harmonic distortion SHOULD be less than 1% for 1Khz at 90 dB SPL input
+ <li>Total harmonic distortion SHOULD be less than 1% for 1 kHz at 90 dB SPL input
level at the microphone.
<li>Noise reduction processing, if present, MUST be disabled.
<li>Automatic gain control, if present, MUST be disabled
@@ -2243,7 +2589,7 @@
<h3 id="5_5_2_audio_effects">5.5.2. Audio Effects</h3>
-<p>Android provides an API for audio effects for device implementations [<a href="http://developer.android.com/reference/android/media/audiofx/AudioEffect.html">Resources, 52</a>]. Device implementations that declare the feature
+<p>Android provides an API for audio effects for device implementations [<a href="http://developer.android.com/reference/android/media/audiofx/AudioEffect.html">Resources, 69</a>]. Device implementations that declare the feature
android.hardware.audio.output:</p>
<ul>
@@ -2289,13 +2635,16 @@
<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>
-<p>Device implementations that declare android.hardware.audio.output SHOULD meet
+<p>Device implementations that declare android.hardware.audio.output are STRONGLY RECOMMENDED to meet
or exceed these audio output requirements:</p>
<ul>
@@ -2307,12 +2656,12 @@
<p>If a device implementation meets the requirements of this section after any
initial calibration when using the OpenSL ES PCM buffer queue API, for
continuous output latency and cold output latency over at least one supported
-audio output device, it MAY report support for low-latency audio, by reporting
+audio output device, it is STRONGLY RECOMMENDED to report support for low-latency audio, by reporting
the feature android.hardware.audio.low_latency via the
-android.content.pm.PackageManager class [<a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">Resources, 53</a>]. Conversely, if the device implementation does not meet these requirements it
+android.content.pm.PackageManager class [<a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">Resources, 70</a>]. Conversely, if the device implementation does not meet these requirements it
MUST NOT report support for low-latency audio.</p>
-<p>Device implementations that include android.hardware.microphone SHOULD meet
+<p>Device implementations that include android.hardware.microphone are STRONGLY RECOMMENDED to meet
these input audio requirements:</p>
<ul>
@@ -2326,12 +2675,12 @@
<p>Devices MUST support the media network protocols for audio and video playback
-as specified in the Android SDK documentation [<a href="http://developer.android.com/guide/appendix/media-formats.html">Resources, 50</a>]. Specifically, devices MUST support the following media network protocols:</p>
+as specified in the Android SDK documentation [<a href="http://developer.android.com/guide/appendix/media-formats.html">Resources, 64</a>]. Specifically, devices MUST support the following media network protocols:</p>
<ul>
<li>RTSP (RTP, SDP)</li>
<li>HTTP(S) progressive streaming</li>
- <li>HTTP(S) Live Streaming draft protocol, Version 3 [<a href="http://tools.ietf.org/html/draft-pantos-http-live-streaming-03">Resources, 54</a>]</li>
+ <li>HTTP(S) Live Streaming draft protocol, Version 3 [<a href="http://tools.ietf.org/html/draft-pantos-http-live-streaming-03">Resources, 71</a>]</li>
</ul>
<h2 id="5_8_secure_media">5.8. Secure Media</h2>
@@ -2355,10 +2704,10 @@
If a device implementation supports the inter-app MIDI software transport
(virtual MIDI devices), and it supports MIDI over
<em>all</em> of the following MIDI-capable hardware transports
-for which it provides generic non-MIDI connectivity, it MAY report
+for which it provides generic non-MIDI connectivity, it is STRONGLY RECOMMENDED to report
support for feature android.software.midi via the
android.content.pm.PackageManager class
-[<a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">Resources, 53</a>].
+[<a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">Resources, 70</a>].
</p>
<p>The MIDI-capable hardware transports are:</p>
@@ -2380,6 +2729,61 @@
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 is STRONGLY RECOMMENDED to 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, 70</a>].
+</p>
+
+<ul>
+
+<li>
+The device implementation MUST report support for feature 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 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.
+</li>
+
+<li>
+If the device includes an HDMI port, the device implementation
+MUST support output in stereo and eight 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>
+
+<li>
+If the device includes a 4 conductor 3.5mm audio jack,
+the device implementation is STRONGLY RECOMMENDED to comply with section
+<a href="https://source.android.com/accessories/headset/specification.html#mobile_device_jack_specifications">Mobile device (jack) specifications</a>
+of the
+<a href="https://source.android.com/accessories/headset/specification.html">Wired Audio Headset Specification (v1.1)</a>.
+</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>
@@ -2388,11 +2792,11 @@
Android SDK. Android compatible devices MUST be compatible with:</p>
<ul>
- <li><strong>Android Debug Bridge (adb)</strong> [<a href="http://developer.android.com/tools/help/adb.html">Resources, 55</a>]</li>
+ <li><strong>Android Debug Bridge (adb)</strong> [<a href="http://developer.android.com/tools/help/adb.html">Resources, 72</a>]</li>
</ul>
<p>Device implementations MUST support all adb functions as documented in the
-Android SDK including dumpsys [<a href="https://source.android.com/devices/input/diagnostics.html">Resources, 56</a>]. The device-side adb daemon MUST be inactive by default and there MUST be a
+Android SDK including dumpsys [<a href="https://source.android.com/devices/input/diagnostics.html">Resources, 73</a>]. The device-side adb daemon MUST be inactive by default and there MUST be a
user-accessible mechanism to turn on the Android Debug Bridge. If a device
implementation omits USB peripheral mode, it MUST implement the Android Debug
Bridge via local-area network (such as Ethernet or 802.11). </p>
@@ -2401,7 +2805,7 @@
authenticated hosts. Device implementations MUST support secure adb.</p>
<ul>
- <li><strong>Dalvik Debug Monitor Service (ddms)</strong> [<a href="http://developer.android.com/tools/debugging/ddms.html">Resources, 57</a>]</li>
+ <li><strong>Dalvik Debug Monitor Service (ddms)</strong> [<a href="http://developer.android.com/tools/debugging/ddms.html">Resources, 74</a>]</li>
</ul>
<p>Device implementations MUST support all ddms features as documented in the
@@ -2410,14 +2814,14 @@
as above.</p>
<ul>
- <li><strong>Monkey</strong> [<a href="http://developer.android.com/tools/help/monkey.html">Resources, 58</a>]</li>
+ <li><strong>Monkey</strong> [<a href="http://developer.android.com/tools/help/monkey.html">Resources, 75</a>]</li>
</ul>
<p>Device implementations MUST include the Monkey framework, and make it available
for applications to use.</p>
<ul>
- <li><strong>SysTrace</strong> [<a href="http://developer.android.com/tools/help/systrace.html">Resources, 59</a>]</li>
+ <li><strong>SysTrace</strong> [<a href="http://developer.android.com/tools/help/systrace.html">Resources, 76</a>]</li>
</ul>
<p>Device implementations MUST support systrace tool as documented in the Android
@@ -2432,7 +2836,8 @@
adb tool as provided in the standard Android SDK, device implementers MUST
provide Windows drivers allowing developers to connect to the device using the
adb protocol. These drivers MUST be provided for Windows XP, Windows Vista,
-Windows 7, Windows 8, and Windows 9 in both 32-bit and 64-bit versions.</p>
+Windows 7, Windows 8 and Windows 10 in both 32-bit and 64-bit versions.
+</p>
<h2 id="6_2_developer_options">6.2. Developer Options</h2>
@@ -2440,7 +2845,7 @@
<p>Android includes support for developers to configure application
development-related settings. Device implementations MUST honor the
android.settings.APPLICATION_DEVELOPMENT_SETTINGS intent to show application
-development-related settings [<a href="http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS">Resources, 60</a>]. The upstream Android implementation hides the Developer Options menu by
+development-related settings [<a href="http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS">Resources, 77</a>]. The upstream Android implementation hides the Developer Options menu by
default and enables users to launch Developer Options after pressing seven (7)
times on the <strong>Settings</strong> > <strong>About Device</strong> > <strong>Build Number</strong> menu item. Device implementations MUST provide a consistent experience for
Developer Options. Specifically, device implementations MUST hide Developer
@@ -2473,14 +2878,14 @@
<p>Device implementations MUST consistently report accurate hardware configuration
information via the getSystemAvailableFeatures() and hasSystemFeature(String)
methods on the android.content.pm.PackageManager class for the same build
-fingerprint. [<a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">Resources, 53]</a></p>
+fingerprint. [<a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">Resources, 70</a>]</p>
<h2 id="7_1_display_and_graphics">7.1. Display and Graphics</h2>
<p>Android includes facilities that automatically adjust application assets and UI
layouts appropriately for the device, to ensure that third-party applications
-run well on a variety of hardware configurations [<a href="http://developer.android.com/guide/practices/screens_support.html">Resources, 61</a>]. Devices MUST properly implement these APIs and behaviors, as detailed in
+run well on a variety of hardware configurations [<a href="http://developer.android.com/guide/practices/screens_support.html">Resources, 78</a>]. Devices MUST properly implement these APIs and behaviors, as detailed in
this section.</p>
<p>The units referenced by the requirements in this section are defined as
@@ -2512,7 +2917,7 @@
allows applications to query the device screen size (aka “screen layout") via
android.content.res.Configuration.screenLayout with the SCREENLAYOUT_SIZE_MASK.
Device implementations MUST report the correct screen size as defined in the
-Android SDK documentation [<a href="http://developer.android.com/guide/practices/screens_support.html">Resources, 61</a>] and determined by the upstream Android platform. Specifically, device
+Android SDK documentation [<a href="http://developer.android.com/guide/practices/screens_support.html">Resources, 78</a>] and determined by the upstream Android platform. Specifically, device
implementations MUST report the correct screen size according to the following
logical density-independent pixel (dp) screen dimensions.</p>
@@ -2573,7 +2978,9 @@
<li>240 dpi (hdpi)</li>
<li>280 dpi (280dpi)</li>
<li>320 dpi (xhdpi)</li>
+ <li>360 dpi (360dpi)</li>
<li>400 dpi (400dpi)</li>
+ <li>420 dpi (420dpi)</li>
<li>480 dpi (xxhdpi)</li>
<li>560 dpi (560dpi)</li>
<li>640 dpi (xxxhdpi)</li>
@@ -2591,7 +2998,7 @@
<p>Device implementations MUST report correct values for all display metrics
-defined in android.util.DisplayMetrics [<a href="http://developer.android.com/reference/android/util/DisplayMetrics.html">Resources, 62</a>] and MUST report the same values regardless of whether the embedded or
+defined in android.util.DisplayMetrics [<a href="http://developer.android.com/reference/android/util/DisplayMetrics.html">Resources, 79</a>] and MUST report the same values regardless of whether the embedded or
external screen is used as the default display.</p>
<h3 id="7_1_3_screen_orientation">7.1.3. Screen Orientation</h3>
@@ -2623,7 +3030,7 @@
detailed in the Android SDK documentations. Device implementations SHOULD
support OpenGL ES 3.0 or 3.1 on devices capable of supporting it. Device
implementations MUST also support Android RenderScript, as detailed in the
-Android SDK documentation [<a href="http://developer.android.com/guide/topics/renderscript/">Resources, 63</a>].</p>
+Android SDK documentation [<a href="http://developer.android.com/guide/topics/renderscript/">Resources, 80</a>].</p>
<p>Device implementations MUST also correctly identify themselves as supporting
OpenGL ES 1.0, OpenGL ES 2.0, OpenGL ES 3.0 or OpenGL 3.1. That is:</p>
@@ -2642,7 +3049,7 @@
</ul>
<p>In addition to OpenGL ES 3.1, Android provides an extension pack with Java
-interfaces [<a href="https://developer.android.com/reference/android/opengl/GLES31Ext.html">Resources, 64</a>] and native support for advanced graphics functionality such as tessellation
+interfaces [<a href="https://developer.android.com/reference/android/opengl/GLES31Ext.html">Resources, 81</a>] and native support for advanced graphics functionality such as tessellation
and the ASTC texture compression format. Android device implementations MAY
support this extension pack, and—only if fully implemented—MUST identify the
support through the android.hardware.opengles.aep feature flag.</p>
@@ -2662,7 +3069,7 @@
<p>Android includes a mechanism for applications to declare that they want to
enable hardware acceleration for 2D graphics at the Application, Activity,
Window, or View level through the use of a manifest tag
-android:hardwareAccelerated or direct API calls [<a href="http://developer.android.com/guide/topics/graphics/hardware-accel.html">Resources, 65</a>].</p>
+android:hardwareAccelerated or direct API calls [<a href="http://developer.android.com/guide/topics/graphics/hardware-accel.html">Resources, 82</a>].</p>
<p>Device implementations MUST enable hardware acceleration by default, and MUST
disable hardware acceleration if the developer so requests by setting
@@ -2670,7 +3077,7 @@
through the Android View APIs.</p>
<p>In addition, device implementations MUST exhibit behavior consistent with the
-Android SDK documentation on hardware acceleration [<a href="http://developer.android.com/guide/topics/graphics/hardware-accel.html">Resources, 65</a>].</p>
+Android SDK documentation on hardware acceleration [<a href="http://developer.android.com/guide/topics/graphics/hardware-accel.html">Resources, 82</a>].</p>
<p>Android includes a TextureView object that lets developers directly integrate
hardware-accelerated OpenGL ES textures as rendering targets in a UI hierarchy.
@@ -2680,7 +3087,7 @@
<p>Android includes support for EGL_ANDROID_RECORDABLE, an EGLConfig attribute
that indicates whether the EGLConfig supports rendering to an ANativeWindow
that records images to a video. Device implementations MUST support
-EGL_ANDROID_RECORDABLE extension [<a href="https://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt">Resources, 66</a>].</p>
+EGL_ANDROID_RECORDABLE extension [<a href="https://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt">Resources, 83</a>].</p>
<h3 id="7_1_5_legacy_application_compatibility_mode">7.1.5. Legacy Application Compatibility Mode</h3>
@@ -2722,7 +3129,7 @@
capabilities and developer APIs for accessing external displays. If a device
supports an external display either via a wired, wireless, or an embedded
additional display connection then the device implementation MUST implement the
-display manager API as described in the Android SDK documentation [<a href="http://developer.android.com/reference/android/hardware/display/DisplayManager.html">Resources, 67</a>].</p>
+display manager API as described in the Android SDK documentation [<a href="http://developer.android.com/reference/android/hardware/display/DisplayManager.html">Resources, 84</a>].</p>
<h2 id="7_2_input_devices">7.2. Input Devices</h2>
@@ -2749,7 +3156,7 @@
<li>MAY include additional soft keyboard implementations.</li>
<li>MAY include a hardware keyboard.</li>
<li>MUST NOT include a hardware keyboard that does not match one of the formats
-specified in android.content.res.Configuration.keyboard [<a href="http://developer.android.com/reference/android/content/res/Configuration.html">Resources, 68</a>] (QWERTY or 12-key).</li>
+specified in android.content.res.Configuration.keyboard [<a href="http://developer.android.com/reference/android/content/res/Configuration.html">Resources, 85</a>] (QWERTY or 12-key).</li>
</ul>
<h3 id="7_2_2_non-touch_navigation">7.2.2. Non-touch Navigation</h3>
@@ -2764,7 +3171,7 @@
<li>MAY omit a non-touch navigation option (trackball, d-pad, or wheel) if the
device implementation is not an Android Television device.</li>
<li>MUST report the correct value for android.content.res.Configuration.navigation
-[<a href="http://developer.android.com/reference/android/content/res/Configuration.html">Resources, 68</a>].</li>
+[<a href="http://developer.android.com/reference/android/content/res/Configuration.html">Resources, 85</a>].</li>
<li>MUST provide a reasonable alternative user interface mechanism for the
selection and editing of text, compatible with Input Management Engines. The
upstream Android open source implementation includes a selection mechanism
@@ -2834,13 +3241,11 @@
button, a software key, or gestures. This Menu function should be presented
unless hidden together with other navigation functions.</p>
-<p>Android supports Assist action [<a href="http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST">Resources, 69</a>]. Android device implementations except for Android Watch devices MUST make
-the Assist action available to the user at all times when running applications.
-The Assist action SHOULD be implemented as a long-press on the Home button or a
-swipe-up gesture on the software Home key. This function MAY be implemented via
-another physical button, software key, or gesture, but MUST be accessible with
-a single action (e.g. tap, double-click, or gesture) when other navigation keys
-are visible.</p>
+<p>Android device implementations with the support of the Assist action [<a
+href="http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST">Resources,
+30</a>] MUST make this accessisble with a single action (e.g. tap, double-click,
+or gesture) when other navigation keys are visible, and are STRONGLY RECOMMENDED to
+use the long-press on the Home button or software key as the single action.</p>
<p>Device implementations MAY use a distinct portion of the screen to display the
navigation keys, but if so, MUST meet these requirements:</p>
@@ -2876,12 +3281,12 @@
<ul>
<li>SHOULD support fully independently tracked pointers, if the device input system
supports multiple pointers.</li>
- <li>MUST report the value of android.content.res.Configuration.touchscreen [<a href="http://developer.android.com/reference/android/content/res/Configuration.html">Resources, 68</a>] corresponding to the type of the specific touchscreen on the device.</li>
+ <li>MUST report the value of android.content.res.Configuration.touchscreen [<a href="http://developer.android.com/reference/android/content/res/Configuration.html">Resources, 85</a>] corresponding to the type of the specific touchscreen on the device.</li>
</ul>
<p>Android includes support for a variety of touchscreens, touch pads, and fake
touch input devices. Touchscreen based device implementations are associated
-with a display [<a href="http://source.android.com/devices/tech/input/touch-devices.html">Resources, 70</a>] such that the user has the impression of directly manipulating items on
+with a display [<a href="http://source.android.com/devices/tech/input/touch-devices.html">Resources, 86</a>] such that the user has the impression of directly manipulating items on
screen. Since the user is directly touching the screen, the system does not
require any additional affordances to indicate the objects being manipulated.
In contrast, a fake touch interface provides a user input system that
@@ -2914,14 +3319,14 @@
<ul>
<li>MUST report the absolute X and Y screen positions of the pointer location and
-display a visual pointer on the screen [<a href="http://developer.android.com/reference/android/view/MotionEvent.html">Resources, 71</a>].</li>
+display a visual pointer on the screen [<a href="http://developer.android.com/reference/android/view/MotionEvent.html">Resources, 87</a>].</li>
<li>MUST report touch event with the action code that specifies the state change
-that occurs on the pointer going down or up on the screen [<a href="http://developer.android.com/reference/android/view/MotionEvent.html">Resources, 71</a>].</li>
+that occurs on the pointer going down or up on the screen [<a href="http://developer.android.com/reference/android/view/MotionEvent.html">Resources, 87</a>].</li>
<li>MUST support pointer down and up on an object on the screen, which allows users
to emulate tap on an object on the screen.</li>
<li>MUST support pointer down, pointer up, pointer down then pointer up in the same
place on an object on the screen within a time threshold, which allows users to
-emulate double tap on an object on the screen [<a href="http://developer.android.com/reference/android/view/MotionEvent.html">Resources, 71</a>].</li>
+emulate double tap on an object on the screen [<a href="http://developer.android.com/reference/android/view/MotionEvent.html">Resources, 87</a>].</li>
<li>MUST support pointer down on an arbitrary point on the screen, pointer move to
any other arbitrary point on the screen, followed by a pointer up, which allows
users to emulate a touch drag.</li>
@@ -2949,7 +3354,7 @@
<table>
<tr>
<th>Button</th>
- <th>HID Usage</strong><sup>2</sup></td>
+ <th>HID Usage<sup>2</sup></th>
<th>Android Button</th>
</tr>
<tr>
@@ -2973,16 +3378,16 @@
<td>KEYCODE_BUTTON_Y (100)</td>
</tr>
<tr>
- <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_DPAD_UP">D-pad up</a><sup>1</sup></p>
+ <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_DPAD_UP">D-pad up</a><sup>1</sup><br />
-<p><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_DPAD_DOWN">D-pad down</a><sup>1</sup></td>
+<a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_DPAD_DOWN">D-pad down</a><sup>1</sup></td>
<td>0x01 0x0039<sup>3</sup></td>
<td><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_HAT_Y">AXIS_HAT_Y</a><sup>4</sup></td>
</tr>
<tr>
- <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_DPAD_LEFT">D-pad left</a>1</p>
+ <td><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_DPAD_LEFT">D-pad left</a>1<br />
-<p><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_DPAD_RIGHT">D-pad right</a><sup>1</sup></td>
+<a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_DPAD_RIGHT">D-pad right</a><sup>1</sup></td>
<td>0x01 0x0039<sup>3</sup></td>
<td><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_HAT_X">AXIS_HAT_X</a><sup>4</sup></td>
</tr>
@@ -3019,7 +3424,7 @@
</table>
-<p class="table_footnote">1 [<a href="http://developer.android.com/reference/android/view/KeyEvent.html">Resources, 72</a>]</p>
+<p class="table_footnote">1 [<a href="http://developer.android.com/reference/android/view/KeyEvent.html">Resources, 88</a>]</p>
<p class="table_footnote">2 The above HID usages must be declared within a Game pad CA (0x01 0x0005).</p>
@@ -3030,11 +3435,11 @@
rotation and the up button being pressed, while a logical value of 1 represents
a rotation of 45 degrees and both the up and left keys being pressed.</p>
-<p class="table_footnote">4 [<a href="http://developer.android.com/reference/android/view/MotionEvent.html">Resources, 71</a>]</p>
+<p class="table_footnote">4 [<a href="http://developer.android.com/reference/android/view/MotionEvent.html">Resources, 87</a>]</p>
<table>
<tr>
- <th>Analog Controls</strong><sup>1</sup></td>
+ <th>Analog Controls<sup>1</sup></th>
<th>HID Usage</th>
<th>Android Button</th>
</tr>
@@ -3050,26 +3455,26 @@
</tr>
<tr>
<td><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_Y">Left Joystick</a></td>
- <td>0x01 0x0030</p>
+ <td>0x01 0x0030<br />
-<p>0x01 0x0031</td>
- <td>AXIS_X</p>
+0x01 0x0031</td>
+ <td>AXIS_X<br />
-<p>AXIS_Y</td>
+AXIS_Y</td>
</tr>
<tr>
<td><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_Z">Right Joystick</a></td>
- <td>0x01 0x0032</p>
+ <td>0x01 0x0032<br />
-<p>0x01 0x0035</td>
- <td>AXIS_Z</p>
+0x01 0x0035</td>
+ <td>AXIS_Z<br />
-<p>AXIS_RZ</td>
+AXIS_RZ</td>
</tr>
</table>
-<p class="table_footnote">1 [<a href="http://developer.android.com/reference/android/view/MotionEvent.html">Resources, 71</a>]</p>
+<p class="table_footnote">1 [<a href="http://developer.android.com/reference/android/view/MotionEvent.html">Resources, 87</a>]</p>
<h3 id="7_2_7_remote_control">7.2.7. Remote Control</h3>
@@ -3082,7 +3487,7 @@
<ul>
<li><strong>Search affordance</strong>. Device implementations MUST fire KEYCODE_SEARCH when the user invokes voice search either on the physical or software-based remote.</li>
<li><strong>Navigation</strong>. All Android Television remotes MUST include Back, Home, and Select buttons and
-support for D-pad events [<a href="http://developer.android.com/reference/android/view/KeyEvent.html">Resources, 72</a>].</li>
+support for D-pad events [<a href="http://developer.android.com/reference/android/view/KeyEvent.html">Resources, 88</a>].</li>
</ul>
<h2 id="7_3_sensors">7.3. Sensors</h2>
@@ -3093,11 +3498,11 @@
following subsections. If a device includes a particular sensor type that has a
corresponding API for third-party developers, the device implementation MUST
implement that API as described in the Android SDK documentation and the
-Android Open Source documentation on sensors [<a href="http://source.android.com/devices/sensors/">Resources, 73</a>]. For example, device implementations:</p>
+Android Open Source documentation on sensors [<a href="http://source.android.com/devices/sensors/">Resources, 89</a>]. For example, device implementations:</p>
<ul>
<li>MUST accurately report the presence or absence of sensors per the
-android.content.pm.PackageManager class [<a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">Resources, 53]</a>.</li>
+android.content.pm.PackageManager class [<a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">Resources, 70]</a>.</li>
<li>MUST return an accurate list of supported sensors via the
SensorManager.getSensorList() and similar methods.</li>
<li>MUST behave reasonably for all other sensor APIs (for example, by returning
@@ -3106,29 +3511,32 @@
etc.).</li>
<li>MUST report all sensor measurements using the relevant International System of
Units (metric) values for each sensor type as defined in the Android SDK
-documentation [<a href="http://developer.android.com/reference/android/hardware/SensorEvent.html">Resources, 74</a>].</li>
+documentation [<a href="http://developer.android.com/reference/android/hardware/SensorEvent.html">Resources, 90</a>].</li>
<li>SHOULD report the event time in nanoseconds as defined in the Android SDK
documentation, representing the time the event happened and synchronized with
the SystemClock.elapsedRealtimeNano() clock. Existing and new Android devices
-are <strong>very strongly encouraged</strong> to meet these requirement so they will be able to upgrade to the future
+are <strong>STRONGLY RECOMMENDED</strong> to meet these requirement so they will be able to upgrade to the future
platform releases where this might become a REQUIRED component. The
-synchronization error SHOULD be below 100 milliseconds [<a href="http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp">Resources, 75</a>].</li>
+synchronization error SHOULD be below 100 milliseconds [<a href="http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp">Resources, 91</a>].</li>
+ <li>MUST report sensor data with a maximum latency of 100 milliseconds + 2 * sample_time for the case of a sensor streamed
+ with a minimum required latency of 5 ms + 2 * sample_time when the application processor is active. This delay does not include any filtering delays.</li>
+ <li>MUST report the first sensor sample within 400 milliseconds + 2 * sample_time of the sensor being activated. It is acceptable for this sample to have an accuracy of 0.</li>
</ul>
<p>The list above is not comprehensive; the documented behavior of the Android SDK
-and the Android Open Source Documentations on Sensors [<a href="http://source.android.com/devices/sensors/">Resources, 73</a>] is to be considered authoritative.</p>
+and the Android Open Source Documentations on Sensors [<a href="http://source.android.com/devices/sensors/">Resources, 89</a>] is to be considered authoritative.</p>
<p>Some sensor types are composite, meaning they can be derived from data provided
by one or more other sensors. (Examples include the orientation sensor, and the
linear acceleration sensor.) Device implementations SHOULD implement these
sensor types, when they include the prerequisite physical sensors as described
-in [<a href="https://source.android.com/devices/sensors/sensor-types.html">Resources, 76</a>].
+in [<a href="https://source.android.com/devices/sensors/sensor-types.html">Resources, 92</a>].
If a device implementation includes a composite sensor it MUST implement the
sensor as described in the Android Open Source documentation on composite
-sensors [<a href="https://source.android.com/devices/sensors/sensor-types.html#composite_sensor_type_summary">Resources, 76</a>].</p>
+sensors [<a href="https://source.android.com/devices/sensors/sensor-types.html#composite_sensor_type_summary">Resources, 92</a>].</p>
<p>Some Android sensors support a “continuous” trigger mode, which returns data
-continuously [<a href="https://source.android.com/devices/sensors/report-modes.html#continuous">Resources, 77</a>]. For any API indicated by the Android SDK documentation to be a continuous
+continuously [<a href="https://source.android.com/devices/sensors/report-modes.html#continuous">Resources, 93</a>]. For any API indicated by the Android SDK documentation to be a continuous
sensor, device implementations MUST continuously provide periodic data samples
that SHOULD have a jitter below 3%, where jitter is defined as the standard
deviation of the difference of the reported timestamp values between
@@ -3145,20 +3553,20 @@
<p>Device implementations SHOULD include a 3-axis accelerometer. Android Handheld
-devices and Android Watch devices are strongly encouraged to include this
+devices and Android Watch devices are STRONGLY RECOMMENDED to include this
sensor. If a device implementation does include a 3-axis accelerometer, it:</p>
<ul>
- <li>MUST implement and report TYPE_ACCELEROMETER sensor [<a href="http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER">Resources, 78</a>].</li>
+ <li>MUST implement and report TYPE_ACCELEROMETER sensor [<a href="http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER">Resources, 94</a>].</li>
<li>MUST be able to report events up to a frequency of at least 50 Hz for
Android Watch devices as such devices have a stricter power constraint and
100 Hz for all other device types.</li>
<li>SHOULD report events up to at least 200 Hz.</li>
<li>MUST comply with the Android sensor coordinate system as detailed in the
-Android APIs [<a href="http://developer.android.com/reference/android/hardware/SensorEvent.html">Resources, 74</a>].</li>
+Android APIs [<a href="http://developer.android.com/reference/android/hardware/SensorEvent.html">Resources, 90</a>].</li>
<li>MUST be capable of measuring from freefall up to four times the gravity (4g) or
more on any axis.</li>
- <li>MUST have a resolution of at least 8-bits and SHOULD have a resolution of at
+ <li>MUST have a resolution of at least 12-bits and SHOULD have a resolution of at
least 16-bits.</li>
<li>SHOULD be calibrated while in use if the characteristics changes over the life
cycle and compensated, and preserve the compensation parameters between device
@@ -3169,15 +3577,15 @@
period of at least 3 seconds at the fastest sampling rate.</li>
<li>SHOULD implement the TYPE_SIGNIFICANT_MOTION, TYPE_TILT_DETECTOR,
TYPE_STEP_DETECTOR, TYPE_STEP_COUNTER composite sensors as described in the
-Android SDK document. Existing and new Android devices are <strong>very strongly encouraged</strong> to implement the TYPE_SIGNIFICANT_MOTION composite sensor. If any of these
+Android SDK document. Existing and new Android devices are <strong>STRONGLY RECOMMENDED</strong> to implement the TYPE_SIGNIFICANT_MOTION composite sensor. If any of these
sensors are implemented, the sum of their power consumption MUST always be less
than 4 mW and SHOULD each be below 2 mW and 0.5 mW for when the device is in a
dynamic or static condition.</li>
<li>If a gyroscope sensor is included, MUST implement the TYPE_GRAVITY and
TYPE_LINEAR_ACCELERATION composite sensors and SHOULD implement the
TYPE_GAME_ROTATION_VECTOR composite sensor. Existing and new Android devices
-are strongly encouraged to implement the TYPE_GAME_ROTATION_VECTOR sensor.</li>
- <li>SHOULD implement a TYPE_ROTATION_VECTOR composite sensor, if a gyroscope sensor
+are STRONGLY RECOMMENDED to implement the TYPE_GAME_ROTATION_VECTOR sensor.</li>
+ <li>MUST implement a TYPE_ROTATION_VECTOR composite sensor, if a gyroscope sensor
and a magnetometer sensor is also included.</li>
</ul>
@@ -3190,11 +3598,11 @@
<ul>
<li>MUST implement the TYPE_MAGNETIC_FIELD sensor and SHOULD also implement
TYPE_MAGNETIC_FIELD_UNCALIBRATED sensor. Existing and new Android devices are
-strongly encouraged to implement the TYPE_MAGNETIC_FIELD_UNCALIBRATED sensor.</li>
+STRONGLY RECOMMENDED to implement the TYPE_MAGNETIC_FIELD_UNCALIBRATED sensor.</li>
<li>MUST be able to report events up to a frequency of at least 10 Hz and SHOULD
report events up to at least 50 Hz.</li>
<li>MUST comply with the Android sensor coordinate system as detailed in the
-Android APIs [<a href="http://developer.android.com/reference/android/hardware/SensorEvent.html">Resources, 74</a>].</li>
+Android APIs [<a href="http://developer.android.com/reference/android/hardware/SensorEvent.html">Resources, 90</a>].</li>
<li>MUST be capable of measuring between -900 µT and +900 µT on each axis before
saturating.</li>
<li>MUST have a hard iron offset value less than 700 µT and SHOULD have a value
@@ -3210,7 +3618,7 @@
<li>SHOULD have a standard deviation, calculated on a per axis basis on samples
collected over a period of at least 3 seconds at the fastest sampling rate, no
greater than 0.5 µT.</li>
- <li>SHOULD implement a TYPE_ROTATION_VECTOR composite sensor, if an accelerometer
+ <li>MUST implement a TYPE_ROTATION_VECTOR composite sensor, if an accelerometer
sensor and a gyroscope sensor is also included.</li>
<li>MAY implement the TYPE_GEOMAGNETIC_ROTATION_VECTOR sensor if an accelerometer
sensor is also implemented. However if implemented, it MUST consume less than
@@ -3234,7 +3642,7 @@
<ul>
<li>MUST implement the TYPE_GYROSCOPE sensor and SHOULD also implement
TYPE_GYROSCOPE_UNCALIBRATED sensor. Existing and new Android devices are
-strongly encouraged to implement the SENSOR_TYPE_GYROSCOPE_UNCALIBRATED sensor.</li>
+STRONGLY RECOMMENDED to implement the SENSOR_TYPE_GYROSCOPE_UNCALIBRATED sensor.</li>
<li>MUST be capable of measuring orientation changes up to 1,000 degrees per second.</li>
<li>MUST be able to report events up to a frequency of at least 50 Hz for
Android Watch devices as such devices have a stricter power constraint and
@@ -3249,12 +3657,12 @@
or rad^2 / s). The variance is allowed to vary with the sampling rate, but must
be constrained by this value. In other words, if you measure the variance of
the gyro at 1 Hz sampling rate it should be no greater than 1e-7 rad^2/s^2.</li>
- <li>SHOULD implement a TYPE_ROTATION_VECTOR composite sensor, if an accelerometer
+ <li>MUST implement a TYPE_ROTATION_VECTOR composite sensor, if an accelerometer
sensor and a magnetometer sensor is also included.</li>
<li>If an accelerometer sensor is included, MUST implement the TYPE_GRAVITY and
TYPE_LINEAR_ACCELERATION composite sensors and SHOULD implement the
TYPE_GAME_ROTATION_VECTOR composite sensor. Existing and new Android devices
-are strongly encouraged to implement the TYPE_GAME_ROTATION_VECTOR sensor.</li>
+are STRONGLY RECOMMENDED to implement the TYPE_GAME_ROTATION_VECTOR sensor.</li>
</ul>
<h3 id="7_3_5_barometer">7.3.5. Barometer</h3>
@@ -3304,6 +3712,169 @@
<li>MUST have 1-bit of accuracy or more.</li>
</ul>
+
+<h3 id="7_3_9_hifi_sensors">7.3.9. High Fidelity Sensors</h3>
+
+<p>Device implementations supporting a set of higher quality sensors that can meet all
+the requirements listed in this section MUST identify the support through the
+<code>android.hardware.sensor.hifi_sensors</code> feature flag.</p>
+
+<p>A device declaring android.hardware.sensor.hifi_sensors MUST support all of the following
+sensor types meeting the quality requirements as below:</p>
+
+<ul>
+ <li>SENSOR_TYPE_ACCELEROMETER
+ <ul>
+ <li>MUST have a measurement range between at least -8g and +8g</li>
+ <li>MUST have a measurement resolution of at least 1024 LSB/G</li>
+ <li>MUST have a minimum measurement frequency of 12.5 Hz or lower</li>
+ <li>MUST have a maxmium measurement frequency of 200 Hz or higher</li>
+ <li>MUST have a measurement noise not above 400uG/√Hz</li>
+ <li>MUST implement a non-wake-up form of this sensor with a buffering capability of at least 3000 sensor events</li>
+ <li>MUST have a batching power consumption not worse than 3 mW</li>
+ </ul>
+ </li>
+ <li>SENSOR_TYPE_GYROSCOPE
+ <ul>
+ <li>MUST have a measurement range between at least -1000 and +1000 dps</li>
+ <li>MUST have a measurement resolution of at least 16 LSB/dps</li>
+ <li>MUST have a minimum measurement frequency of 12.5 Hz or lower</li>
+ <li>MUST have a maxmium measurement frequency of 200 Hz or higher</li>
+ <li>MUST have a measurement noise not above 0.014°/s/√Hz</li>
+ </ul>
+ </li>
+ <li>SENSOR_TYPE_GYROSCOPE_UNCALIBRATED with the same quality requirements as
+ SENSOR_TYPE_GYROSCOPE</li>
+ <li>SENSOR_TYPE_GEOMAGNETIC_FIELD
+ <ul>
+ <li>MUST have a measurement range between at least -900 and +900 uT</li>
+ <li>MUST have a measurement resolution of at least 5 LSB/uT</li>
+ <li>MUST have a minimum measurement frequency of 5 Hz or lower</li>
+ <li>MUST have a maxmium measurement frequency of 50 Hz or higher</li>
+ <li>MUST have a measurement noise not above 0.5 uT</li>
+ </ul>
+ </li>
+ <li>SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED with the same quality requirements as
+ SENSOR_TYPE_GEOMAGNETIC_FIELD and in addition:
+ <ul>
+ <li>MUST implement a non-wake-up form of this sensor with a buffering capability of at least 600 sensor events</li>
+ </ul>
+ </li>
+ <li>SENSOR_TYPE_PRESSURE
+ <ul>
+ <li>MUST have a measurement range between at least 300 and 1100 hPa</li>
+ <li>MUST have a measurement resolution of at least 80 LSB/hPa</li>
+ <li>MUST have a minimum measurement frequency of 1 Hz or lower</li>
+ <li>MUST have a maximum measurement frequency of 10 Hz or higher</li>
+ <li>MUST have a measurement noise not above 2 Pa/√Hz</li>
+ <li>MUST implement a non-wake-up form of this sensor with a buffering capability of at least 300 sensor events</li>
+ <li>MUST have a batching power consumption not worse than 2 mW</li>
+ </ul>
+ </li>
+ <li>SENSOR_TYPE_ROTATION_VECTOR
+ <ul>
+ <li>MUST have a batching power consumption not worse than 4 mW</li>
+ </ul>
+ </li>
+ <li>SENSOR_TYPE_GAME_ROTATION_VECTOR MUST implement a non-wake-up form of this sensor with a buffering capability of at least 300 sensor events</li>
+ <li>SENSOR_TYPE_SIGNIFICANT_MOTION
+ <ul>
+ <li>MUST have a power consumption not worse than 0.5 mW when device is static
+ and 1.5 mW when device is moving</li>
+ </ul>
+ </li>
+ <li>SENSOR_TYPE_STEP_DETECTOR
+ <ul>
+ <li>MUST implement a non-wake-up form of this sensor with a buffering capability of at least 100 sensor events</li>
+ <li>MUST have a power consumption not worse than 0.5 mW when device is static
+ and 1.5 mW when device is moving</li>
+ <li>MUST have a batching power consumption not worse than 4 mW</li>
+ </ul>
+ </li>
+ <li>SENSOR_TYPE_STEP_COUNTER
+ <ul>
+ <li>MUST have a power consumption not worse than 0.5 mW when device is static
+ and 1.5 mW when device is moving</li>
+ </ul>
+ </li>
+ <li>SENSOR_TILT_DETECTOR
+ <ul>
+ <li>MUST have a power consumption not worse than 0.5 mW when device is static
+ and 1.5 mW when device is moving</li>
+ </ul>
+ </li>
+</ul>
+
+<p>Also such a device MUST meet the following sensor subsystem requirements:</p>
+
+<ul>
+ <li>The event timestamp of the same physical event reported by the Accelerometer, Gyroscope
+ sensor and Magnetometer MUST be within 2.5 milliseconds of each other.</li>
+ <li>The Gyroscope sensor event timestamps MUST be on the same time base as the camera
+ subsystem and within 1 millisconds of error.</li>
+ <li>The latency of delivery of samples to the HAL SHOULD be below 5 milliseconds from
+ the instant the data is available on the physical sensor hardware.</li>
+ <li>The power consumption MUST not be higher than 0.5 mW when device is static and 2.0 mW
+ when device is moving when any combination of the following sensors are enabled:
+ <ul>
+ <li>SENSOR_TYPE_SIGNIFICANT_MOTION</li>
+ <li>SENSOR_TYPE_STEP_DETECTOR</li>
+ <li>SENSOR_TYPE_STEP_COUNTER</li>
+ <li>SENSOR_TILT_DETECTORS</li>
+ </ul>
+ </li>
+</ul>
+
+<p>Note that all power consumption requirements in this section do not include the power
+ consumption of the Application Processor. It is inclusive of the power drawn by the entire
+ sensor chain - the sensor, any supporting circuitry, any dedicated sensor processing system,
+ etc.</p>
+
+<p>The following sensor types MAY also be supported on a device implementation declaring
+ android.hardware.sensor.hifi_sensors, but if these sensor types are present they MUST meet the
+ following minimum buffering capability requirement:</p>
+
+<ul>
+ <li>SENSOR_TYPE_PROXIMITY: 100 sensor events</li>
+</ul>
+
+<h3 id="7_3_10_fingeprint">7.3.10. Fingerprint Sensor</h3>
+
+<p>Device implementations with a secure lock screen SHOULD include a fingerprint sensor.
+If a device implementation includes a fingerprint sensor and has a corresponding API for
+third-party developers, it:</p>
+
+<ul>
+ <li>MUST declare support for the android.hardware.fingerprint feature.</li>
+ <li>MUST fully implement the corresponding API as described in the Android SDK documentation
+[<a href="https://developer.android.com/reference/android/hardware/fingerprint/package-summary.html">Resources, 95</a>].
+ </li>
+ <li>MUST have a false acceptance rate not higher than 0.002%.</li>
+ <li>Is STRONGLY RECOMMENDED to have a false rejection rate not higher than 10%, and a
+ latency from when the fingerprint sensor is touched until the screen is unlocked below
+ 1 second, for 1 enrolled finger.</li>
+ <li>MUST rate limit attempts for at least 30 seconds after 5 false trials for fingerprint
+ verification.</li>
+ <li>MUST have a hardware-backed keystore implementation, and perform the fingerprint matching
+ in a Trusted Execution Environment (TEE) or on a chip with a secure channel to the TEE.
+ </li>
+ <li>MUST have all identifiable fingerprint data encrypted and cryptographically
+ authenticated such that they cannot be acquired, read or altered outside of the
+ Trusted Execution Environment (TEE) as documented in the implementation guidelines
+ on the Android Open Source Project site
+ [<a href="https://source.android.com/devices/tech/security/authentication/fingerprint-hal.html">Resources, 96</a>].
+ </li>
+ <li>MUST prevent adding a fingerprint without first establishing a chain of trust by
+ having the user confirm existing or add a new device credential (PIN/pattern/password)
+ using the TEE as implemented in the Android Open Source project.</li>
+ <li>MUST NOT enable 3rd-party applications to distinguish between individual fingerprints.
+ </li>
+ <li>MUST honor the DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT flag.</li>
+ <li>MUST, when upgraded from a version earlier than Android 6.0, have the fingerprint
+ data securely migrated to meet the above requirements or removed.</li>
+ <li>SHOULD use the Android Fingerprint icon provided in the Android Open Source Project.</li>
+</ul>
+
<h2 id="7_4_data_connectivity">7.4. Data Connectivity</h2>
@@ -3343,10 +3914,13 @@
<ul>
<li>MUST report the hardware feature flag android.hardware.wifi.</li>
- <li>MUST implement the multicast API as described in the SDK documentation [<a href="http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html">Resources, 79</a>].</li>
+ <li>MUST implement the multicast API as described in the SDK documentation [<a href="http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html">Resources, 97</a>].</li>
<li>MUST support multicast DNS (mDNS) and MUST NOT filter mDNS packets
-(224.0.0.251) at any time of operation including when the screen is not in an
-active state.</li>
+(224.0.0.251) at any time of operation including:
+ <ul>
+ <li>Even when the screen is not in an active state.</li>
+ <li>For Android Television device implementations, even when in standby power states.</li>
+ </ul>
</ul>
<h4 id="7_4_2_1_wi-fi_direct">7.4.2.1. Wi-Fi Direct</h4>
@@ -3355,7 +3929,7 @@
<p>Device implementations SHOULD include support for Wi-Fi Direct (Wi-Fi
peer-to-peer). If a device implementation does include support for Wi-Fi
Direct, it MUST implement the corresponding Android API as described in the SDK
-documentation [<a href="http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html">Resources, 80</a>]. If a device implementation includes support for Wi-Fi Direct, then it:</p>
+documentation [<a href="http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html">Resources, 98</a>]. If a device implementation includes support for Wi-Fi Direct, then it:</p>
<ul>
<li>MUST report the hardware feature android.hardware.wifi.direct.</li>
@@ -3374,7 +3948,7 @@
<p>Android Television device implementations MUST include support for Wi-Fi
Tunneled Direct Link Setup (TDLS) and other types of Android device
implementations SHOULD include support for Wi-Fi TDLS as described in the
-Android SDK Documentation [<a href="http://developer.android.com/reference/android/net/wifi/WifiManager.html">Resources, 81</a>]. If a device implementation does include support for TDLS and TDLS is enabled
+Android SDK Documentation [<a href="http://developer.android.com/reference/android/net/wifi/WifiManager.html">Resources, 99</a>]. If a device implementation does include support for TDLS and TDLS is enabled
by the WiFiManager API, the device:</p>
<ul>
@@ -3391,7 +3965,7 @@
</div>
-<p>Android includes support for Bluetooth and Bluetooth Low Energy [<a href="http://developer.android.com/reference/android/bluetooth/package-summary.html">Resources, 82</a>]. Device implementations that include support for Bluetooth and Bluetooth Low
+<p>Android includes support for Bluetooth and Bluetooth Low Energy [<a href="http://developer.android.com/reference/android/bluetooth/package-summary.html">Resources, 100</a>]. Device implementations that include support for Bluetooth and Bluetooth Low
Energy MUST declare the relevant platform features (android.hardware.bluetooth
and android.hardware.bluetooth_le respectively) and implement the platform
APIs. Device implementations SHOULD implement relevant Bluetooth profiles such
@@ -3403,9 +3977,11 @@
<ul>
<li>MUST declare the hardware feature android.hardware.bluetooth_le.</li>
<li>MUST enable the GATT (generic attribute profile) based Bluetooth APIs as
-described in the SDK documentation and [<a href="http://developer.android.com/reference/android/bluetooth/package-summary.html">Resources, 82</a>].</li>
+described in the SDK documentation and [<a href="http://developer.android.com/reference/android/bluetooth/package-summary.html">Resources, 100</a>].</li>
+ <li>MUST implement a Resolvable Private Address (RPA) timeout no longer than
+15 minutes, and rotate the address at timeout to protect user privacy.</li>
<li>SHOULD support offloading of the filtering logic to the bluetooth chipset when
-implementing the ScanFilter API [<a href="https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html">Resources, 83</a>], and MUST report the correct value of where the filtering logic is implemented whenever queried via the
+implementing the ScanFilter API [<a href="https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html">Resources, 101</a>], and MUST report the correct value of where the filtering logic is implemented whenever queried via the
android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported() method.</li>
<li>SHOULD support offloading of the batched scanning to the bluetooth chipset, but
if not supported, MUST report ‘false’ whenever queried via the
@@ -3424,7 +4000,7 @@
<ul>
<li>MUST report the android.hardware.nfc feature from the
-android.content.pm.PackageManager.hasSystemFeature() method [<a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">Resources, 53</a>].</li>
+android.content.pm.PackageManager.hasSystemFeature() method [<a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">Resources, 70</a>].</li>
<li>MUST be capable of reading and writing NDEF messages via the following NFC
standards:
<ul>
@@ -3434,35 +4010,41 @@
<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>STRONGLY RECOMMENDED to be capable of reading and writing NDEF messages as well
+ as raw data via the following NFC standards. Note that while the NFC standards
+ below are stated as STRONGLY RECOMMENDED, 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 very strongly encouraged to meet these
+ requirements now so they will be able to upgrade to the future platform releases.
<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, 102</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>NDEF Push Protocol [<a href="http://static.googleusercontent.com/media/source.android.com/en/us/compatibility/ndef-push-protocol.pdf">Resources, 103</a>]</li>
<li>SNEP 1.0 (defined by the NFC Forum)</li>
</ul></li>
- <li>MUST include support for Android Beam [<a href="http://developer.android.com/guide/topics/connectivity/nfc/nfc.html">Resources, 85</a>]:
+ <li>MUST include support for Android Beam [<a href="http://developer.android.com/guide/topics/connectivity/nfc/nfc.html">Resources, 104</a>]:
<ul>
<li>MUST implement the SNEP default server. Valid NDEF messages received by the
default SNEP server MUST be dispatched to applications using the
android.nfc.ACTION_NDEF_DISCOVERED intent. Disabling Android Beam in settings
MUST NOT disable dispatch of incoming NDEF message.</li>
<li>MUST honor the android.settings.NFCSHARING_SETTINGS intent to show NFC sharing
-settings [<a href="http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS">Resources, 86</a>].</li>
+settings [<a href="http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS">Resources, 105</a>].</li>
<li>MUST implement the NPP server. Messages received by the NPP server MUST be
processed the same way as the SNEP default server.</li>
<li>MUST implement a SNEP client and attempt to send outbound P2P NDEF to the
@@ -3479,7 +4061,7 @@
<li>MUST support NFC Connection handover to Bluetooth when the device supports
Bluetooth Object Push Profile. Device implementations MUST support connection
handover to Bluetooth when using android.nfc.NfcAdapter.setBeamPushUris, by
-implementing the “Connection Handover version 1.2” [<a href="http://members.nfc-forum.org/specs/spec_list/#conn_handover">Resources, 87</a>] and “Bluetooth Secure Simple Pairing Using NFC version 1.0” [<a href="http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf">Resources, 88</a>] specs from the NFC Forum. Such an implementation MUST implement the handover
+implementing the “Connection Handover version 1.2” [<a href="http://members.nfc-forum.org/specs/spec_list/#conn_handover">Resources, 106</a>] and “Bluetooth Secure Simple Pairing Using NFC version 1.0” [<a href="http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf">Resources, 107</a>] specs from the NFC Forum. Such an implementation MUST implement the handover
LLCP service with service name “urn:nfc:sn:handover” for exchanging the
handover request/select records over NFC, and it MUST use the Bluetooth Object
Push Profile for the actual Bluetooth data transfer. For legacy reasons (to
@@ -3503,7 +4085,7 @@
<ul>
<li>MUST report the android.hardware.nfc.hce feature constant.</li>
- <li>MUST support NFC HCE APIs as defined in the Android SDK [<a href="http://developer.android.com/guide/topics/connectivity/nfc/hce.html">Resources, 10</a>].</li>
+ <li>MUST support NFC HCE APIs as defined in the Android SDK [<a href="http://developer.android.com/guide/topics/connectivity/nfc/hce.html">Resources, 108</a>].</li>
</ul>
<p>Additionally, device implementations MAY include reader/writer support for the
@@ -3521,8 +4103,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, 70</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>
@@ -3530,7 +4112,7 @@
<p>If a device implementation does not include NFC hardware, it MUST NOT declare
the android.hardware.nfc feature from the
-android.content.pm.PackageManager.hasSystemFeature() method [<a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">Resources, 53]</a>, and MUST implement the Android NFC API as a no-op.</p>
+android.content.pm.PackageManager.hasSystemFeature() method [<a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">Resources, 70</a>], and MUST implement the Android NFC API as a no-op.</p>
<p>As the classes android.nfc.NdefMessage and android.nfc.NdefRecord represent a
protocol-independent data representation format, device implementations MUST
@@ -3552,11 +4134,40 @@
<p>Devices MAY implement more than one form of data connectivity.</p>
+<p>Devices MUST include an IPv6 networking stack and support IPv6 communication
+using the managed APIs, such as <code>java.net.Socket</code> and
+<code>java.net.URLConnection</code>, as well as the native APIs, such as
+<code>AF_INET6</code> sockets. The required level of IPv6 support depends on
+the network type, as follows:</p>
+<ul>
+ <li>Devices that support Wi-Fi networks MUST support dual-stack and IPv6-only
+ operation on Wi-Fi.</li>
+ <li>Devices that support Ethernet networks MUST support dual-stack operation
+ on Ethernet.</li>
+ <li>Devices that support cellular data SHOULD support IPv6 operation
+ (IPv6-only and possibly dual-stack) on cellular data.</li>
+ <li>When a device is simultaneously connected to more than one network (e.g.,
+ Wi-Fi and cellular data), it MUST simultaneously meet these requirements on
+ each network to which it is connected.</li>
+</ul>
+
+<p>IPv6 MUST be enabled by default.</p>
+
+<p>In order to ensure that IPv6 communication is as reliable as IPv4, unicast
+IPv6 packets sent to the device MUST NOT be dropped, even when the screen is
+not in an active state. Redundant multicast IPv6 packets, such as repeated
+identical Router Advertisements, MAY be rate-limited in hardware or firmware
+if doing so is necessary to save power. In such cases, rate-limiting MUST NOT
+cause the device to lose IPv6 connectivity on any IPv6-compliant network that
+uses RA lifetimes of at least 180 seconds.</p>
+
+<p>IPv6 connectivity MUST be maintained in doze mode.</p>
+
<h3 id="7_4_6_sync_settings">7.4.6. Sync Settings</h3>
<p>Device implementations MUST have the master auto-sync setting on by default so
-that the method getMasterSyncAutomatically() returns “true” [<a href="http://developer.android.com/reference/android/content/ContentResolver.html">Resources, 89</a>].</p>
+that the method getMasterSyncAutomatically() returns “true” [<a href="http://developer.android.com/reference/android/content/ContentResolver.html">Resources, 109</a>].</p>
<h2 id="7_5_cameras">7.5. Cameras</h2>
@@ -3619,7 +4230,7 @@
preview MUST be mirrored horizontally relative to the device’s current
orientation.</li>
<li>If the current application has explicitly requested that the Camera display be
-rotated via a call to the android.hardware.Camera.setDisplayOrientation()[<a href="http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)">Resources, 90</a>] method, the camera preview MUST be mirrored horizontally relative to the
+rotated via a call to the android.hardware.Camera.setDisplayOrientation()[<a href="http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)">Resources, 110</a>] method, the camera preview MUST be mirrored horizontally relative to the
orientation specified by the application.</li>
<li>Otherwise, the preview MUST be mirrored along the device’s default horizontal
axis.</li>
@@ -3688,7 +4299,8 @@
</ul>
<p>Device implementations MUST still implement the full Camera API included in the
-Android SDK documentation [<a href="http://developer.android.com/reference/android/hardware/Camera.html">Resources, 91</a>], regardless of whether the device includes hardware autofocus or other
+Android SDK documentation [<a href="http://developer.android.com/reference/android/hardware/Camera.html">Resources, 111</a>],
+regardless of whether the device includes hardware autofocus or other
capabilities. For instance, cameras that lack autofocus MUST still call any
registered android.hardware.Camera.AutoFocusCallback instances (even though
this has no relevance to a non-autofocus camera.) Note that this does apply to
@@ -3705,16 +4317,16 @@
implementations MUST support all standard Camera parameters if the hardware
allows, and MUST NOT support custom Camera parameter types. For instance,
device implementations that support image capture using high dynamic range
-(HDR) imaging techniques MUST support camera parameter Camera.SCENE_MODE_HDR [<a href="http://developer.android.com/reference/android/hardware/Camera.Parameters.html">Resources, 92</a>].</p>
+(HDR) imaging techniques MUST support camera parameter Camera.SCENE_MODE_HDR [<a href="http://developer.android.com/reference/android/hardware/Camera.Parameters.html">Resources, 112</a>].</p>
<p>Because not all device implementations can fully support all the features of
the android.hardware.camera2 API, device implementations MUST report the proper
level of support with the android.info.supportedHardwareLevel property as
-described in the Android SDK [<a href="https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL">Resources, 93]</a> and report the appropriate framework feature flags [<a href="http://source.android.com/devices/camera/versioning.html">Resources, 94]</a>. </p>
+described in the Android SDK [<a href="https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL">Resources, 113</a>] and report the appropriate framework feature flags [<a href="http://source.android.com/devices/camera/versioning.html">Resources, 114</a>].</p>
<p>Device implementations MUST also declare its Individual camera capabilities of
android.hardware.camera2 via the android.request.availableCapabilities property
-and declare the appropriate feature flags [<a href="http://source.android.com/devices/camera/versioning.html">Resources, 94]</a>; a device must define the feature flag if any of its attached camera devices supports the feature.</p>
+and declare the appropriate feature flags [<a href="http://source.android.com/devices/camera/versioning.html">Resources, 114</a>]; a device must define the feature flag if any of its attached camera devices supports the feature.</p>
<p>Device implementations MUST broadcast the Camera.ACTION_NEW_PICTURE intent
whenever a new picture is taken by the camera and the entry of the picture has
@@ -3807,11 +4419,11 @@
implementations MUST have at least 1.5GB of non-volatile storage available for
application private data. That is, the /data partition MUST be at least 5GB for
Android Television devices and at least 1.5GB for other device implementations.
-Device implementations that run Android are <strong>very strongly encouraged</strong> to have at least 3GB of non-volatile storage for application private data so
+Device implementations that run Android are <strong>STRONGLY RECOMMENDED</strong> to have at least 3GB of non-volatile storage for application private data so
they will be able to upgrade to the future platform releases.</p>
<p>The Android APIs include a Download Manager that applications MAY use to
-download data files [<a href="http://developer.android.com/reference/android/app/DownloadManager.html">Resources, 95</a>]. The device implementation of the Download Manager MUST be capable of
+download data files [<a href="http://developer.android.com/reference/android/app/DownloadManager.html">Resources, 115</a>]. The device implementation of the Download Manager MUST be capable of
downloading individual files of at least 100MB in size to the default “cache"
location.</p>
@@ -3868,11 +4480,26 @@
<ul>
<li>SHOULD be compatible with the reference Android MTP host, Android File Transfer
-[<a href="http://www.android.com/filetransfer">Resources, 96</a>].</li>
+[<a href="http://www.android.com/filetransfer">Resources, 116</a>].</li>
<li>SHOULD report a USB device class of 0x00.</li>
<li>SHOULD report a USB interface name of 'MTP'.</li>
</ul>
+<h3 id="7_6_3_adoptable_storage">7.6.3. Adoptable Storage</h3>
+
+<p>Device implementations are STRONGLY RECOMMENDED to implement adoptable
+storage if the removable storage device port is in a long-term stable location,
+such as within the battery compartment or other protective cover
+[<a
+href="http://source.android.com/devices/storage/adoptable.html">Resources,
+117</a>].</p>
+
+<p>Device implementations such as a television, MAY enable adoption through USB
+ports as the device is expected to be static and not mobile. But for other
+device implementations that are mobile in nature, it is STRONGLY RECOMMENDED to
+implement the adoptable storage in a long-term stable location, since accidentally
+disconnecting them can cause data loss/corruption.</p>
+
<h2 id="7_7_usb">7.7. USB</h2>
@@ -3885,12 +4512,12 @@
<li>The port MUST be connectable to a USB host that has a standard type-A or type
-C USB port.</li>
<li>The port SHOULD use micro-A, micro-AB or type-C USB form factor. Existing and
-new Android devices are <strong>very strongly encouraged to meet these requirements</strong> so they will be able to upgrade to the future platform releases.</li>
+new Android devices are <strong>STRONGLY RECOMMENDED to meet these requirements</strong> so they will be able to upgrade to the future platform releases.</li>
<li>The port SHOULD be centered in the middle of an edge. Device implementations
SHOULD either locate the port on the bottom of the device (according to natural
orientation) or enable software screen rotation for all apps (including home
screen), so that the display draws correctly when the device is oriented with
-the port at bottom. Existing and new Android devices are <strong>very strongly encouraged to meet these requirements</strong> so they will be able to upgrade to future platform releases.</li>
+the port at bottom. Existing and new Android devices are <strong>STRONGLY RECOMMENDED to meet these requirements</strong> so they will be able to upgrade to future platform releases.</li>
<li>It MUST allow a USB host connected with the Android device to access the
contents of the shared storage volume using either USB mass storage or Media
Transfer Protocol.</li>
@@ -3899,12 +4526,16 @@
device it MUST implement the AOA API. Device implementations implementing the
AOA specification:
<ul>
- <li>MUST declare support for the hardware feature android.hardware.usb.accessory [<a href="http://developer.android.com/guide/topics/connectivity/usb/accessory.html">Resources, 97</a>].</li>
+ <li>MUST declare support for the hardware feature android.hardware.usb.accessory [<a href="http://developer.android.com/guide/topics/connectivity/usb/accessory.html">Resources, 118</a>].</li>
<li>MUST implement the USB audio class as documented in the Android SDK
-documentation [<a href="http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO">Resources, 98</a>].</li>
- </ul></li>
+documentation [<a href="http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO">Resources, 119</a>].</li>
+ <li>And also the USB mass storage class, MUST include the string "android"
+at the end of the interface description <code>iInterface</code> string of the
+USB mass storage</li>
+ </ul>
+ </li>
<li>It SHOULD implement support to draw 1.5 A current during HS chirp and traffic
-as specified in the USB battery charging specification [<a href="http://www.usb.org/developers/docs/devclass_docs/USB_Battery_Charging_1.2.pdf">Resources, 99</a>]. Existing and new Android devices are <strong>very strongly encouraged to meet these requirements</strong> so they will be able to upgrade to the future platform releases.</li>
+as specified in the USB battery charging specification [<a href="http://www.usb.org/developers/docs/devclass_docs/USB_Battery_Charging_1.2.pdf">Resources, 120</a>]. Existing and new Android devices are <strong>STRONGLY RECOMMENDED to meet these requirements</strong> so they will be able to upgrade to the future platform releases.</li>
<li>The value of iSerialNumber in USB standard device descriptor MUST be equal to
the value of android.os.Build.SERIAL.</li>
</ul>
@@ -3917,12 +4548,12 @@
cables adapting the port to a standard type-A or type-C USB port.</li>
<li>MAY use a micro-AB USB port, but if so SHOULD ship with a cable or cables
adapting the port to a standard type-A or type-C USB port.</li>
- <li>is <strong>very strongly RECOMMENDED</strong> to implement the USB audio class as documented in the Android SDK
-documentation [<a href="http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO">Resources, 98</a>].</li>
+ <li>is <strong>STRONGLY RECOMMENDED</strong> to implement the USB audio class as documented in the Android SDK
+documentation [<a href="http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO">Resources, 119</a>].</li>
<li>MUST implement the Android USB host API as documented in the Android SDK, and
-MUST declare support for the hardware feature android.hardware.usb.host [<a href="http://developer.android.com/guide/topics/connectivity/usb/host.html">Resources, 100</a>].</li>
+MUST declare support for the hardware feature android.hardware.usb.host [<a href="http://developer.android.com/guide/topics/connectivity/usb/host.html">Resources, 121</a>].</li>
<li>SHOULD support the Charging Downstream Port output current range of 1.5 A ~ 5 A
-as specified in the USB Battery Charging Specifications [<a href="http://www.usb.org/developers/docs/devclass_docs/USB_Battery_Charging_1.2.pdf">Resources, 99</a>].</li>
+as specified in the USB Battery Charging Specifications [<a href="http://www.usb.org/developers/docs/devclass_docs/USB_Battery_Charging_1.2.pdf">Resources, 120</a>].</li>
</ul>
<h2 id="7_8_audio">7.8. Audio</h2>
@@ -3939,12 +4570,15 @@
<p>Device implementations MAY omit a microphone. However, if a device
implementation omits a microphone, it MUST NOT report the
android.hardware.microphone feature constant, and MUST implement the audio
-recording API at least as no-ops, per <a href="#7_hardware_compatibility">section 7</a>. Conversely, device implementations that do possess a microphone:</p>
+recording API at least as no-ops, per <a href="#7_hardware_compatibility">section 7</a>.
+Conversely, device implementations that do possess a microphone:</p>
<ul>
- <li>MUST report the android.hardware.microphone feature constant
- <li>MUST meet the audio recording requirements in <a href="#5_4_audio_recording">section 5.4</a>
- <li>MUST meet the audio latency requirements in <a href="#5_6_audio_latency">section 5.6</a>
+ <li>MUST report the android.hardware.microphone feature constant</li>
+ <li>MUST meet the audio recording requirements in <a href="#5_4_audio_recording">section 5.4</a></li>
+ <li>MUST meet the audio latency requirements in <a href="#5_6_audio_latency">section 5.6</a></li>
+ <li>STRONGLY RECOMMENDED to support near-ultrasound recording as described in
+ <a href="#7_8_3_near_ultrasound">section 7.8.3</a></li>
</ul>
<h3 id="7_8_2_audio_output">7.8.2. Audio Output</h3>
@@ -3960,6 +4594,8 @@
<li>MUST report the android.hardware.audio.output feature constant.</li>
<li>MUST meet the audio playback requirements in <a href="#5_5_audio_playback">section 5.5</a>.</li>
<li>MUST meet the audio latency requirements in <a href="#5_6_audio_latency">section 5.6</a>.</li>
+ <li>STRONGLY RECOMMENDED to support near-ultrasound playback as described in
+ <a href="#7_8_3_near_ultrasound">section 7.8.3</a></li>
</ul>
<p>Conversely, if a device implementation does not include a speaker or audio
@@ -3974,7 +4610,7 @@
<p>In order to be compatible with the headsets and other audio accessories using
-the 3.5mm audio plug across the Android ecosystem [<a href="http://source.android.com/accessories/headset-spec.html">Resources, 101</a>], if a device implementation includes one or more analog audio ports, at least
+the 3.5mm audio plug across the Android ecosystem [<a href="http://source.android.com/accessories/headset-spec.html">Resources, 122</a>], if a device implementation includes one or more analog audio ports, at least
one of the audio port(s) SHOULD be a 4 conductor 3.5mm audio jack. If a device
implementation has a 4 conductor 3.5mm audio jack, it:</p>
@@ -3992,7 +4628,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
@@ -4003,16 +4639,42 @@
</ul></li>
<li>MUST trigger ACTION_HEADSET_PLUG upon a plug insert, but only after all
contacts on plug are touching their relevant segments on the jack.</li>
- <li>MUST be capable of driving at least 150mV +/- 10% of output voltage on a 32 Ohm
+ <li>MUST be capable of driving at least 150mV ± 10% of output voltage on a 32 Ohm
speaker impedance.</li>
<li>MUST have a microphone bias voltage between 1.8V ~ 2.9V.</li>
</ul>
-<h1 id="8_performance_compatibility">8. Performance Compatibility</h1>
+<h3 id="7_8_3_near_ultrasound">7.8.3. Near-Ultrasound </h3>
+
+<p>Near-Ultrasound audio is the 18.5 kHz to 20 kHz band.
+Device implementations MUST correctly report the support
+of near-ultrasound audio capability via the
+<a href="http://developer.android.com/reference/android/media/AudioManager.html#getProperty(java.lang.String)">AudioManager.getProperty</a>
+API as follows:
+</p>
+
+<ul>
+ <li>If
+ <a href="http://developer.android.com/reference/android/media/AudioManager.html#PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND">PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND</a>
+ is "true", then
+ <ul>
+ <li>The microphone's mean power response in the 18.5 kHz to 20 kHz band MUST be no more than
+ 15 dB below the response at 2 kHz.</li>
+ <li>The signal to noise ratio of the microphone MUST be no lower than 80 dB.</li>
+ </ul>
+ </li>
+ <li>If
+ <a href="http://developer.android.com/reference/android/media/AudioManager.html#PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND">PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND</a>
+ is "true", then the speaker's mean response in 18.5 kHz - 20 kHz MUST be no lower than 40 dB
+ below the response at 2 kHz.
+ </li>
+</ul>
+
+<h1 id="8_performance_power">8. Performance and Power</h1>
-<p>Some minimum performance criterias are critical to the user experience and
-impacts the baseline assumptions developers would have when developing an app.
+<p>Some minimum performance and power criteria are critical to the user experience
+and impact the baseline assumptions developers would have when developing an app.
Android Watch devices SHOULD and other type of device implementations MUST meet
the following criteria:</p>
@@ -4050,12 +4712,50 @@
256MB file using 4KB write buffer.</li>
</ul>
+<h2 id="8_3_power_saving_modes">8.3. Power-Saving Modes</h2>
+
+<p>All apps exempted from App Standby and/or Doze mode MUST be made visible to
+the end user. Further, the triggering, maintenance, wakeup algorithms and
+the use of Global system settings of these power-saving modes MUST not deviate
+from the Android Open Source Project.</p>
+
+<h2 id="8_4_power_consumption_accounting">8.4. Power Consumption Accounting</h2>
+
+<p>A more accurate accounting and reporting of the power consumption provides the
+app developer both the incentives and the tools to optimize the power usage pattern
+of the application. Therefore, device implementations:</p>
+
+<ul>
+ <li>MUST be able to track hardware component power usage and attribute that power
+ usage to specific applications. Specifically, implementations:
+ <ul>
+ <li>MUST provide a per-component power profile that defines the current consumption
+ value for each hardware component and the approximate battery drain caused by the
+ components over time as documented in the Android Open Source Project site [<a
+href="http://source.android.com/devices/tech/power/values.html">Resources, 123</a>].</li>
+ <li>MUST report all power consumption values in milliampere hours (mAh)</li>
+ <li>SHOULD be attributed to the hardware component itself if unable to
+ attribute hardware component power usage to an application.</li>
+ <li>MUST report CPU power consumption per each process's UID. The Android Open
+ Source Project meets the requirement through the <code>uid_cputime</code>
+ kernel module implementation.</li>
+ </ul>
+ </li>
+ <li>MUST make this power usage available via the <code>adb shell dumpsys
+ batterystats</code> shell command to the app developer [<a
+href="http://source.android.com/devices/tech/power/batterystats.html">Resources, 124</a>].</li>
+ <li>MUST honor the android.intent.action.POWER_USAGE_SUMMARY intent and display
+ a settings menu that shows this power usage [<a
+href="http://developer.android.com/reference/android/content/Intent.html#ACTION_POWER_USAGE_SUMMARY">Resources,
+125</a>].</li>
+</ul>
+
<h1 id="9_security_model_compatibility">9. Security Model Compatibility</h1>
<p>Device implementations MUST implement a security model consistent with the
Android platform security model as defined in Security and Permissions
-reference document in the APIs [<a href="http://developer.android.com/guide/topics/security/permissions.html">Resources, 102</a>] in the Android developer documentation. Device implementations MUST support
+reference document in the APIs [<a href="http://developer.android.com/guide/topics/security/permissions.html">Resources, 126</a>] in the Android developer documentation. Device implementations MUST support
installation of self-signed applications without requiring any additional
permissions/certificates from any third parties/authorities. Specifically,
compatible devices MUST support the security mechanisms described in the follow
@@ -4065,11 +4765,28 @@
<p>Device implementations MUST support the Android permissions model as defined in
-the Android developer documentation [<a href="http://developer.android.com/guide/topics/security/permissions.html">Resources, 102</a>]. Specifically, implementations MUST enforce each permission defined as
+the Android developer documentation [<a href="http://developer.android.com/guide/topics/security/permissions.html">Resources, 126</a>]. Specifically, implementations MUST enforce each permission defined as
described in the SDK documentation; no permissions may be omitted, altered, or
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. Device implementations:</p>
+
+<ul>
+<li>MUST show a dedicated interface for the user to decide whether to grant the
+requested runtime permissions and also provide an interface for the user to manage
+runtime permissions.</li>
+<li>MUST have one and only one implementation of both user interfaces.</li>
+<li>MUST NOT grant any runtime permissions to preinstalled apps unless:
+ <ul>
+ <li>the user's consent can be obtained before the application uses it</li>
+ <li>the runtime permissions are associated with an intent pattern for which the preinstalled
+ application is set as the default handler</li>
+ </ul>
+</li>
+</ul>
+
<h2 id="9_2_uid_and_process_isolation">9.2. UID and Process Isolation</h2>
@@ -4077,13 +4794,13 @@
which each application runs as a unique Unixstyle UID and in a separate
process. Device implementations MUST support running multiple applications as
the same Linux user ID, provided that the applications are properly signed and
-constructed, as defined in the Security and Permissions reference [<a href="http://developer.android.com/guide/topics/security/permissions.html">Resources, 102</a>].</p>
+constructed, as defined in the Security and Permissions reference [<a href="http://developer.android.com/guide/topics/security/permissions.html">Resources, 126</a>].</p>
<h2 id="9_3_filesystem_permissions">9.3. Filesystem Permissions</h2>
<p>Device implementations MUST support the Android file access permissions model
-as defined in the Security and Permissions reference [<a href="http://developer.android.com/guide/topics/security/permissions.html">Resources, 102</a>].</p>
+as defined in the Security and Permissions reference [<a href="http://developer.android.com/guide/topics/security/permissions.html">Resources, 126</a>].</p>
<h2 id="9_4_alternate_execution_environments">9.4. Alternate Execution Environments</h2>
@@ -4142,8 +4859,8 @@
<p>Android includes support for multiple users and provides support for full user
-isolation [<a href="http://developer.android.com/reference/android/os/UserManager.html">Resources, 103]</a>. Device implementations MAY enable multiple users, but when enabled MUST meet
-the following requirements related to multi-user support [<a href="http://source.android.com/devices/storage/">Resources, 104</a>]:</p>
+isolation [<a href="http://developer.android.com/reference/android/os/UserManager.html">Resources, 127</a>]. Device implementations MAY enable multiple users, but when enabled MUST meet
+the following requirements related to multi-user support [<a href="http://source.android.com/devices/storage/traditional.html">Resources, 128</a>]:</p>
<ul>
<li>Device implementations that do not declare the android.hardware.telephony
@@ -4158,14 +4875,7 @@
voice calls and SMS.</li>
<li>Device implementations MUST, for each user, implement a security model
consistent with the Android platform security model as defined in Security and
-Permissions reference document in the APIs [<a href="http://developer.android.com/guide/topics/security/permissions.html">Resources, 102</a>].</li>
- <li>Device implementations MAY support creating users and managed profiles via the
-android.app.admin.DevicePolicyManager APIs, and if supported, MUST declare the
-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 &
-Notifications.</li>
+Permissions reference document in the APIs [<a href="http://developer.android.com/guide/topics/security/permissions.html">Resources, 126</a>].</li>
<li>Each user instance on an Android device MUST have separate and isolated
external storage directories. Device implementations MAY store multiple users'
data on the same volume or filesystem. However, the device implementation MUST
@@ -4179,14 +4889,14 @@
implementations will be required to switch to MTP or a similar system to
provide host PCs with access to the current user’s data. Accordingly, device
implementations MAY but SHOULD NOT enable multi-user if they use removable
-media [<a href="http://developer.android.com/reference/android/os/Environment.html">Resources, 105</a>] for primary external storage.</li>
+media [<a href="http://developer.android.com/reference/android/os/Environment.html">Resources, 129</a>] for primary external storage.</li>
</ul>
<h2 id="9_6_premium_sms_warning">9.6. Premium SMS Warning</h2>
<p>Android includes support for warning users of any outgoing premium SMS message
-[<a href="http://en.wikipedia.org/wiki/Short_code">Resources, 106</a>] . Premium SMS messages are text messages sent to a service registered with a
+[<a href="http://en.wikipedia.org/wiki/Short_code">Resources, 130</a>]. Premium SMS messages are text messages sent to a service registered with a
carrier that may incur a charge to the user. Device implementations that
declare support for android.hardware.telephony MUST warn users before sending a
SMS message to numbers identified by regular expressions defined in
@@ -4196,9 +4906,9 @@
<h2 id="9_7_kernel_security_features">9.7. Kernel Security Features</h2>
-<p>The Android Sandbox includes features that can use the Security-Enhanced Linux
+<p>The Android Sandbox includes features that use the Security-Enhanced Linux
(SELinux) mandatory access control (MAC) system and other security features in
-the Linux kernel. SELinux or any other security features, if implemented below
+the Linux kernel. SELinux or any other security features implemented below
the Android framework:</p>
<ul>
@@ -4213,31 +4923,28 @@
affect another application (such as a Device Administration API), the API MUST
NOT allow configurations that break compatibility.</p>
-<p>Devices MUST implement SELinux or an equivalent mandatory access control system
-if using a kernel other than Linux and meet the following requirements, which
-are satisfied by the reference implementation in the upstream Android Open
-Source Project.</p>
+<p>Devices MUST implement SELinux or, if using a kernel other than Linux, an
+equivalent mandatory access control system. Devices MUST also meet the
+following requirements, which are satisfied by the reference implementation
+in the upstream Android Open Source Project.</p>
<p>Device implementations:</p>
<ul>
- <li>MUST support a SELinux policy that allows the SELinux mode to be set on a
-per-domain basis, and MUST configure all domains in enforcing mode. No
-permissive mode domains are allowed, including domains specific to a
-device/vendor.</li>
- <li>SHOULD load policy from /sepolicy file on the device.</li>
+ <li>MUST set SELinux to global enforcing mode.</li>
+ <li>MUST configure all domains in enforcing mode. No permissive mode domains
+are allowed, including domains specific to a device/vendor.</li>
<li>MUST NOT modify, omit, or replace the neverallow rules present within the
-sepolicy file provided in the upstream Android Open Source Project (AOSP) and
-the policy MUST compile with all neverallow present, for both AOSP SELinux
+external/sepolicy folder provided in the upstream Android Open Source Project (AOSP) and
+the policy MUST compile with all neverallow rules present, for both AOSP SELinux
domains as well as device/vendor specific domains.</li>
- <li>MUST support dynamic updates of the SELinux policy file without requiring a
-system image update.</li>
</ul>
<p>Device implementations SHOULD retain the default SELinux policy provided in the
-upstream Android Open Source Project, until they have first audited their
-additions to the SELinux policy. Device implementations MUST be compatible with
-the upstream Android Open Source Project.</p>
+external/sepolicy folder of the upstream Android Open Source Project and only
+further add to this policy for their own device-specific configuration. Device
+implementations MUST be compatible with the upstream Android Open Source Project.
+</p>
<h2 id="9_8_privacy">9.8. Privacy</h2>
@@ -4251,22 +4958,34 @@
service with android.permission.CONTROL_VPN granted), the device implementation
MUST ask for the user's consent before enabling that mechanism.</p>
+<p>If a device implementation has a USB port with USB peripheral mode support,
+it MUST present a user interface asking for the user's consent before allowing
+access to the contents of the shared storage over the USB port.</p>
+
<h2 id="9_9_full-disk_encryption">9.9. Full-Disk Encryption</h2>
<div class="note">
<p>Optional for Android device implementations without a lock screen.</p>
</div>
+<p>If the device implementation supports a secure lock screen reporting "<code>true</code>"
+for KeyguardManager.isDeviceSecure()
+[<a href="http://developer.android.com/reference/android/app/KeyguardManager.html#isDeviceSecure()">Resources, 131</a>],
+and is not a device with restricted memory as reported through the
+ActivityManager.isLowRamDevice() method, then the device MUST support full-disk encryption
+[<a href="http://source.android.com/devices/tech/security/encryption/index.html">Resources, 132</a>]
+of the application private data (/data partition), as well as the application
+shared storage partition (/sdcard partition) if it is a permanent, non-removable
+part of the device.</p>
-<p>If the device implementation supports a lock screen with PIN (numeric) or
-PASSWORD (alphanumeric), the device MUST support full-disk encryption of the
-application private data (/data partition), as well
-as the SD card partition if it is a permanent, non-removable part of the device
-[<a href="http://source.android.com/devices/tech/security/encryption/index.html">Resources, 107</a>]. For devices supporting full-disk encryption, the full-disk encryption SHOULD
-be enabled all the time after the user has completed the out-of-box experience.
-While this requirement is stated as SHOULD for this version of the Android
-platform, it is <strong>very strongly RECOMMENDED</strong> as we expect this to change to MUST in the future versions of Android.
-Encryption MUST use AES with a key of 128-bits (or greater) and a mode designed
+<p>For device implementations supporting full-disk encryption and with Advanced
+Encryption Standard (AES) crypto performance above 50MiB/sec, the full-disk
+encryption MUST be enabled by default at the time the user has completed the out-of-box
+setup experience. If a device implementation is already launched on an earlier Android
+version with full-disk encryption disabled by default, such a device cannot
+meet the requirement through a system software update and thus MAY be exempted.</p>
+
+<p>Encryption MUST use AES with a key of 128-bits (or greater) and a mode designed
for storage (for example, AES-XTS, AES-CBC-ESSIV). The encryption key MUST NOT
be written to storage at any time without being encrypted. Other than when in
active use, the encryption key SHOULD be AES encrypted with the lockscreen
@@ -4277,7 +4996,7 @@
stretching algorithm MUST be cryptographically bound to that keystore. The
encryption key MUST NOT be sent off the device (even when wrapped with the user
passcode and/or hardware bound key). The upstream Android Open Source project
-provides a preferred implementation of this feature based on the linux kernel
+provides a preferred implementation of this feature based on the Linux kernel
feature dm-crypt.</p>
<h2 id="9_10_verified_boot">9.10. Verified Boot</h2>
@@ -4285,24 +5004,77 @@
<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>
-<li>Start verification from a hardware key that is the root of trust, and go
-all the way up to the system partition</li>
+<li>Start verification from an immutable hardware key that is the root of trust,
+and go all the way up to the system partition</li>
<li>Implement each stage of verification to check the integrity and authenticity
of all the bytes in the next stage before executing the code in the next stage</li>
<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>The upstream Android Open Source Project provides a preferred implementation of this
+feature based on the Linux kernel feature dm-verity.</p>
+
+<p>Starting from Android 6.0, device implementations with Advanced Encryption Standard (AES)
+crypto perfomance above 50MiB/seconds MUST support verified boot for device integrity.
+If a device implementation is already launched without supporting verified boot on an earlier
+version of Android, such a device can not add support for this feature with a system software
+update and thus are exempted from the requirement.</p>
+
+<h2 id="9_11_keys_and_credentials">9.11. Keys and Credentials</h2>
+
+<p>The Android Keystore System
+[<a href="https://developer.android.com/training/articles/keystore.html">Resources, 133</a>]
+allows app developers to store cryptographic keys in a container and use them in cryptographic
+operations through the KeyChain API
+[<a href="https://developer.android.com/reference/android/security/KeyChain.html">Resources, 134</a>]
+or the Keystore API
+ [<a href="https://developer.android.com/reference/java/security/KeyStore.html">Resources, 135</a>].
</p>
-<p>Device implementations SHOULD support verified boot for device integrity.
-While this requirement is SHOULD for this version of the Android platform,
-it is <strong>strongly RECOMMENDED</strong> as we expect this to change to MUST
-in future versions of Android. The upstream Android Open Source Project provides
-a preferred implementation of this feature based on the linux kernel feature dm-verity.
-</p>
+<p>All Android device implementations MUST meet the following requirements:</p>
+
+<ul>
+<li>SHOULD not limit the number of keys that can be generated, and MUST at least allow more
+than 8,192 keys to be imported.</li>
+<li>The lock screen authentication MUST rate limit attempts and SHOULD have an exponential
+ backoff algorithm as implemented in the Android Open Source Project.</li>
+<li>When the device implementation supports a secure lock screen and has a secure hardware
+ such as a Secure Element (SE) where a Trusted Execution Environment (TEE) can be implemented,
+ then it:
+ <ul>
+ <li>Is STRONGLY RECOMMENDED to back up the keystore implementation with the secure hardware.
+ The upstream Android Open Source Project provides the Keymaster Hardware Abstraction Layer
+ (HAL) implementation that can be used to satisfy this requirement.</li>
+ <li>MUST perform the lock screen authentication in the secure hardware if the device has a
+ hardware-backed keystore implementation and only when successful allow the authentication-bound
+ keys to be used. The upstream Android Open Source Project provides the Gatekeeper Hardware
+ Abstraction Layer (HAL) that can be used to satisfy this requirement
+ [<a href="http://source.android.com/devices/tech/security/authentication/gatekeeper.html">Resources, 136</a>].</li>
+ </ul>
+</li>
+</ul>
+
+<p>Note that while the above TEE-related requirements are stated as STRONGLY RECOMMENDED, the
+ Compatibility Definition for the next API version is planned to changed these to REQIUIRED. If a
+ device implementation is already launched on an earlier Android version and has not implemented a
+ trusted operating system on the secure hardware, such a device might not be able to meet the
+ requirements through a system software update and thus is STRONGLY RECOMMENDED to implement a
+ TEE.</p>
+
+<h2 id="9_12_data_deletion">9.12. Data Deletion</h2>
+
+<p>Devices MUST provide users with a mechanism to perform a "Factory Data Reset"
+that allows logical and physical deletion of all data. This MUST satisfy relevant
+industry standards for data deletion such as NIST SP800-88. This MUST be used for
+the implementation of the wipeData() API (part of the Android Device Administration API)
+described in <a href="#3_9_device_administration">section 3.9 Device Administration</a>.</p>
+
+<p>Devices MAY provide a fast data wipe that conducts a logical data erase.</p>
<h1 id="10_software_compatibility_testing">10. Software Compatibility Testing</h1>
@@ -4310,7 +5082,7 @@
<p>Device implementations MUST pass all tests described in this section.</p>
<p>However, note that no software test package is fully comprehensive. For this
-reason, device implementers are <strong>very strongly encouraged</strong> to make the minimum number of changes as possible to the reference and
+reason, device implementers are <strong>STRONGLY RECOMMENDED</strong> to make the minimum number of changes as possible to the reference and
preferred implementation of Android available from the Android Open Source
Project. This will minimize the risk of introducing bugs that create
incompatibilities requiring rework and potential device updates.</p>
@@ -4318,7 +5090,7 @@
<h2 id="10_1_compatibility_test_suite">10.1. Compatibility Test Suite</h2>
-<p>Device implementations MUST pass the Android Compatibility Test Suite (CTS) [<a href="http://source.android.com/compatibility/index.html">Resources, 108</a>] available from the Android Open Source Project, using the final shipping
+<p>Device implementations MUST pass the Android Compatibility Test Suite (CTS) [<a href="http://source.android.com/compatibility/index.html">Resources, 137</a>] available from the Android Open Source Project, using the final shipping
software on the device. Additionally, device implementers SHOULD use the
reference implementation in the Android Open Source tree as much as possible,
and MUST ensure compatibility in cases of ambiguity in CTS and for any
@@ -4397,397 +5169,500 @@
applications, the device implementer MUST correct the error via a software
update available that can be applied per the mechanism just described.</p>
+<p>Android includes features that allow the Device Owner app (if present) to control the
+installation of system updates. To facilitate this, the system update subsystem
+for devices that report android.software.device_admin MUST implement the behavior
+described in the SystemUpdatePolicy class
+[<a href="http://developer.android.com/reference/android/app/admin/SystemUpdatePolicy.html">
+Resources, 138</a>].</p>
+
<h1 id="12_document_changelog">12. Document Changelog</h1>
-
<p>The following table contains a summary of the changes to the Compatibility
-Definition in this release. </p>
+Definition in this release.</p>
<table>
<tr>
<th>Section</th>
- <th>Summary of change</th>
+ <th>Summary of changes</th>
+ </tr>
+ <tr>
+ <td>Various</td>
+ <td>Replaced instances of the "encouraged" term with "RECOMMENDED"</td>
</tr>
<tr>
<td>2. Device Types</td>
- <td>Added definition for Android automotive implementation.</td>
+ <td>Update for Android Automotive implementations</td>
</tr>
<tr>
- <td>2.1 Device Configurations</td>
- <td>Added column for Android automotive implementation.</td>
+ <td>3.2.2. Build Parameters</td>
+ <td>Additions for the hardware serial number and for the security patch level of a build</td>
</tr>
<tr>
- <td>3.3.2. 32-bit ARM Native Code Compatibility</td>
- <td>New section added.</td>
+ <td>3.2.3.2. Intent Resolution</td>
+ <td>Section renamed from "Intent Overrides" to "Intent Resolution," with new requirements related to authoritative default app linking</td>
+ </tr>
+ <tr>
+ <td>3.3.1. Application Binary Interfaces</td>
+ <td>Additions for Android ABI support; change related to Vulkan library name</td>
</tr>
<tr>
<td>3.4.1. WebView Compatibility</td>
- <td>Updated webview user agent string requirement to accomodate upstream
- implementation change.</td>
- </tr>
- <tr>
- <td>3.4.2. Browser compatibility</td>
- <td>Added Android automotive implementations as another case that MAY omit a
- browser application.</td>
+ <td>Change for the user agent string reported by the WebView</td>
</tr>
<tr>
<td>3.7. Runtime Compatibility</td>
- <td>Updated required runtime heap size for smaller screens and added requirement
- for the new dpi bucket (280dpi).</td>
+ <td>Updates to memory allocation table</td>
</tr>
<tr>
- <td>3.8.3. Notifications</td>
- <td>Clarified notification requirement for Android Watch, Television and
- Automotive implementations.</td>
+ <td>3.8.4. Search</td>
+ <td>Updates regarding Assistant requirements</td>
</tr>
<tr>
- <td>3.8.10. Lock Screen Media Control<</td>
- <td>Clarified requirement for Android Watch and Automotive implementations.</td>
+ <td>3.8.6. Themes</td>
+ <td>Added requirement to support black system icons when requested by the SYSTEM_UI_FLAG_LIGHT_STATUS_BAR flag</td>
</tr>
<tr>
- <td>3.8.13. Unicode and font</td>
- <td>Relaxed Emoji character input method requirement.</td>
+ <td>3.9.1. Device Provisioning</td>
+ <td>Contains new sections for device owner provisioning and managed profile provisioning</td>
</tr>
<tr>
- <td>3.9. Device Administration</td>
- <td>Clarified condition when the full range of device administration policies
- has to be supported.</td>
+ <td>3.9.2. Managed Profile Support</td>
+ <td>New section with requirements for device support of managed profile functionality</td>
+ </tr>
+<tr>
+ <td>3.12.1. TV App</td>
+ <td>Added section to clarify TV App requirements for Android Television devices</td>
</tr>
<tr>
- <td>3.10. Accessibility</td>
- <td>Added Android automotive requirements.</td>
+ <td>3.12.1.1. Electronic Program Guide</td>
+ <td>Added section to clarify EPG requirements for Android Television devices</td>
</tr>
<tr>
- <td>3.11. Text-To-Speech</td>
- <td>Added Android automotive requirements.</td>
+ <td>3.12.1.2. Navigation</td>
+ <td>Added section to clarify TV App navigation requirements for Android Television devices</td>
+ </tr>
+ <td>3.12.1.3. TV input app linking</td>
+ <td>Added section to clarify TV input app linking support requirements for Android Television devices</td>
</tr>
<tr>
<td>5.1. Media Codecs</td>
- <td>Mandated decoding support for codecs reported by CamcorderProfile.</td>
+ <td>Updates regarding support for core media formats and decoding.</td>
</tr>
- <tr>
- <td>5.1.3 Video Codecs</td>
- <td>Added Android automotive requirements.</td>
+ <tr>
+ <td>5.1.3. Video Codecs</td>
+ <td>Changes and additions related to Android Televisions</td>
+ </tr>
+ <tr>
+ <td>5.2. Video Encoding</td>
+ <td>Changes for encoders</td>
+ </tr>
+ <tr>
+ <td>5.3. Video Decoding</td>
+ <td>Changes for decoders, including regarding support for dynamic video resolution, frame rate
+switching, and more</td>
+ </tr>
+ <tr>
+ <td>5.4. Audio Recording</td>
+ <td>Additions related to audio capture</td>
+ </tr>
+ <tr>
+ <td>5.6. Audio Latency</td>
+ <td>Update regarding reporting of support for low-latency audio</td>
+ </tr>
+ <tr>
+ <td>5.10. Professional Audio</td>
+ <td>General updates for professional audio support; updates for mobile device (jack) specifications, USB audio host mode, and other updates</td>
+ </tr>
+ <tr>
+ <td>5.9. Musical Instrument Digital Interface (MIDI)</td>
+ <td>Added new section on optional Musical Instrument Digital Interface (MIDI) support</td>
+ </tr>
+<tr>
+ <td>6.1. Developer Tools</td>
+ <td>Update for drivers supporting Windows 10</td>
</tr>
<tr>
<td>7.1.1.3. Screen Density</td>
- <td>Added a new screen dpi (280dpi).</td>
- </tr>
- <tr>
- <td>7.1.5. Legacy Application Compatibility Mode</td>
- <td>Added Android automotive requirements.</td>
- </tr>
- <tr>
- <td>7.2 Input Devices</td>
- <td>Added general introduction statement.</td>
- </tr>
- <tr>
- <td>7.2.1. Keyboard</td>
- <td>Added Android Automotive requirements.</td>
+ <td>Updates for screen density, for example related to an Android watch</td>
</tr>
<tr>
<td>7.2.3. Navigation Keys</td>
- <td>Added Android Automotive requirements.</td>
+ <td>Updated requirements for device implementations that include the Assist action</td>
</tr>
<tr>
- <td>7.3.1. Accelerometer</td>
- <td>Relaxed requirement for reporting frequency on Android Watch.</td>
+ <td>7.3. Sensors (and subsections)</td>
+ <td>New requirements for some sensor types</td>
</tr>
<tr>
- <td>7.3.4. Gyroscope</td>
- <td>Relaxed requirement for reporting frequency on Android Watch.</td>
+ <td>7.3.9. High Fidelity Sensors</td>
+ <td>New section with requirements for devices supporting high fidelity sensors</td>
</tr>
<tr>
- <td>7.4.3 Bluetooth</td>
- <td>Added Android Automotive requirements.</td>
+ <td>7.3.10. Fingerprint Sensor</td>
+ <td>New section on requirements related to fingerprint sensors</td>
+ </tr>
+ <tr>
+ <td>7.4.2. IEEE 802.11 (Wi-Fi)</td>
+ <td>Updates regarding support for multicast DNS (mDNS)</td>
+ </tr>
+ <tr>
+ <td>7.4.3. Bluetooth</td>
+ <td>Addition related to Resolvable Private Address (RPA) for Bluetooth Low Energy (BLE)</td>
</tr>
<tr>
<td>7.4.4. Near-Field Communications</td>
- <td>Clarified condition for when Host Card Emulation is a requirement.</td>
+ <td>Additions to requirements for Near-Field Communications (NFC)</td>
</tr>
<tr>
- <td>7.6.1. Minimum Memory and Storage</td>
- <td>Updated minimum memory requirements for lower resulution screen devices
- and added hard-limit requirement isLowRamDevice().</td>
+ <td>7.4.5. Minimum Network Capability</td>
+ <td>Added requirements for IPv6 support</td>
</tr>
<tr>
- <td>7.6.2. Application Shared Storage</td>
- <td>Updated requirements when support for host machine access is mandatory.</td>
+ <td>7.6.3. Adoptable Storage</td>
+ <td>New section for implementation of adoptable storage</td>
</tr>
<tr>
- <td>7.8.1. Microphone</td>
- <td>Added Android Automotive requirements.</td>
+ <td>7.7. USB</td>
+ <td>Requirement related to implementing the AOA specification</td>
</tr>
<tr>
- <td>8.2. File I/O Access Performance</td>
- <td>Clarified requirements.</td>
+ <td>7.8.3. Near-Ultrasound</td>
+ <td>Additions related to near-ultrasound recording, playback, and audio</td>
</tr>
<tr>
+ <td>8.3. Power-Saving Modes</td>
+ <td>New section with requirements regarding the App Standby and Doze modes</td>
+ </tr>
+<tr>
+ <td>8.4. Power Consumption Accounting</td>
+ <td>New section with requirements for tracking hardware component power usage and attributing that power usage to specific applications</td>
+ </tr>
+ <tr>
+ <td>9.1. Permissions</td>
+ <td>Addition to Permissions requirements</td>
+ </tr>
+<tr>
+ <td>9.7. Kernel Security Features</td>
+ <td>SE Linux updates</td>
+ </tr>
+<tr>
<td>9.8. Privacy</td>
- <td>Added privacy requirement for preloaded VPNs.</td>
+ <td>Addition regarding user's consent for access to shared storage over a USB port</td>
</tr>
<tr>
<td>9.9. Full-Disk Encryption</td>
- <td>Clarified condition when Full-Disk encryption support is mandatory.</td>
+ <td>Requirements related to full disk encryption</td>
</tr>
<tr>
<td>9.10. Verified Boot</td>
- <td>Clarified definition of verified boot.</td>
+ <td>Additional requirement for verified boot</td>
+ </tr>
+ <tr>
+ <td>9.11. Keys and Credentials</td>
+ <td>New section of requirements related to keys and credentials</td>
+ </tr>
+ <tr>
+ <td>9.12. Data Deletion</td>
+ <td>New section for "Factory Data Reset"</td>
</tr>
<tr>
<td>11. Updatable Software</td>
- <td>Clarified the OTA download requirement is allowed but not mandatory for
- Android Automotive implementations.</td>
+ <td>Requirement related to the system update policy set by the device owner</td>
</tr>
-</table>
+ </table>
<h1 id="13_contact_us">13. Contact Us</h1>
-<p>You can join the android-compatibility forum <a href="https://groups.google.com/forum/#!forum/android-compatibility">[Resources, 109</a>] and ask for clarifications or bring up any issues that you think the document
+<p>You can join the android-compatibility forum <a href="https://groups.google.com/forum/#!forum/android-compatibility">[Resources, 139</a>] and ask for clarifications or bring up any issues that you think the document
does not cover.</p>
<h1 id="14_resources">14. Resources</h1>
-
<p>1. IETF RFC2119 Requirement Levels: <a href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a></p>
<p>2. Android Open Source Project: <a href="http://source.android.com/">http://source.android.com/</a></p>
-<p>3. Android Television features: <a href="http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK">http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK</a> </p>
+<p>3. Android Television features: <a href="http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK">http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK</a></p>
<p>4. Android Watch feature: <a href="http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_WATCH">http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_WATCH</a></p>
-<p>5. API definitions and documentation: <a href="http://developer.android.com/reference/packages.html">http://developer.android.com/reference/packages.html</a></p>
+<p>5. Android UI_MODE_TYPE_CAR API: <a href="http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR">http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR</a></p>
-<p>6. Android Permissions reference: <a href="http://developer.android.com/reference/android/Manifest.permission.html">http://developer.android.com/reference/android/Manifest.permission.html</a></p>
+<p>6. API definitions and documentation: <a href="http://developer.android.com/reference/packages.html">http://developer.android.com/reference/packages.html</a></p>
-<p>7. android.os.Build reference: <a href="http://developer.android.com/reference/android/os/Build.html">http://developer.android.com/reference/android/os/Build.html</a></p>
+<p>7. Android Permissions reference: <a href="http://developer.android.com/reference/android/Manifest.permission.html">http://developer.android.com/reference/android/Manifest.permission.html</a></p>
-<p>8. Android ANDROID_VERSION allowed version strings: <a href="http://source.android.com/compatibility/ANDROID_VERSION/versions.html">http://source.android.com/compatibility/ANDROID_VERSION/versions.html</a></p>
+<p>8. android.os.Build reference: <a href="http://developer.android.com/reference/android/os/Build.html">http://developer.android.com/reference/android/os/Build.html</a></p>
-<p>9. Telephony Provider: <a href="http://developer.android.com/reference/android/provider/Telephony.html">http://developer.android.com/reference/android/provider/Telephony.html</a></p>
+<p>9. Android ANDROID_VERSION allowed version strings: <a href="http://source.android.com/compatibility/ANDROID_VERSION/versions.html">http://source.android.com/compatibility/ANDROID_VERSION/versions.html</a></p>
-<p>10. Host-based Card Emulation: <a href="http://developer.android.com/guide/topics/connectivity/nfc/hce.html">http://developer.android.com/guide/topics/connectivity/nfc/hce.html</a></p>
+<p>10. Android Developer Settings: <a href="http://developer.android.com/reference/android/provider/Settings.html">http://developer.android.com/reference/android/provider/Settings.html</a></p>
-<p>11. Android Extension Pack: <a href="http://developer.android.com/guide/topics/graphics/opengl.html#aep">http://developer.android.com/guide/topics/graphics/opengl.html#aep</a> </p>
+<p>11. Telephony Provider: <a href="http://developer.android.com/reference/android/provider/Telephony.html">http://developer.android.com/reference/android/provider/Telephony.html</a></p>
-<p>12. android.webkit.WebView class: <a href="http://developer.android.com/reference/android/webkit/WebView.html">http://developer.android.com/reference/android/webkit/WebView.html</a></p>
+<p>12. Android NDK ABI Management: <a href="https://developer.android.com/ndk/guides/abis.html">https://developer.android.com/ndk/guides/abis.html</a></p>
-<p>13. WebView compatibility: <a href="http://www.chromium.org/">http://www.chromium.org/</a></p>
+<p>13. Advanced SIMD architecture: <a href="http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/Beijfcja.html">http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0388f/Beijfcja.html</a></p>
-<p>14. HTML5: <a href="http://html.spec.whatwg.org/multipage/">http://html.spec.whatwg.org/multipage/</a></p>
+<p>14. Android Extension Pack: <a href="http://developer.android.com/guide/topics/graphics/opengl.html#aep">http://developer.android.com/guide/topics/graphics/opengl.html#aep</a></p>
-<p>15. HTML5 offline capabilities:<a href="http://dev.w3.org/html5/spec/Overview.html#offline"> http://dev.w3.org/html5/spec/Overview.html#offline</a></p>
+<p>15. android.webkit.WebView class: <a href="http://developer.android.com/reference/android/webkit/WebView.html">http://developer.android.com/reference/android/webkit/WebView.html</a></p>
-<p>16. HTML5 video tag: <a href="http://dev.w3.org/html5/spec/Overview.html#video">http://dev.w3.org/html5/spec/Overview.html#video</a></p>
+<p>16. WebView compatibility: <a href="http://www.chromium.org/">http://www.chromium.org/</a></p>
-<p>17. HTML5/W3C geolocation API: <a href="http://www.w3.org/TR/geolocation-API/">http://www.w3.org/TR/geolocation-API/</a></p>
+<p>17. HTML5: <a href="http://html.spec.whatwg.org/multipage/">http://html.spec.whatwg.org/multipage/</a></p>
-<p>18. HTML5/W3C webstorage API: <a href="http://www.w3.org/TR/webstorage/">http://www.w3.org/TR/webstorage/</a></p>
+<p>18. HTML5 offline capabilities:<a href="http://dev.w3.org/html5/spec/Overview.html#offline"> http://dev.w3.org/html5/spec/Overview.html#offline</a></p>
-<p>19. HTML5/W3C IndexedDB API: <a href="http://www.w3.org/TR/IndexedDB/">http://www.w3.org/TR/IndexedDB/</a></p>
+<p>19. HTML5 video tag: <a href="http://dev.w3.org/html5/spec/Overview.html#video">http://dev.w3.org/html5/spec/Overview.html#video</a></p>
-<p>20. Dalvik Executable Format and bytecode specification: available in the
+<p>20. HTML5/W3C geolocation API: <a href="http://www.w3.org/TR/geolocation-API/">http://www.w3.org/TR/geolocation-API/</a></p>
+
+<p>21. HTML5/W3C webstorage API: <a href="http://www.w3.org/TR/webstorage/">http://www.w3.org/TR/webstorage/</a></p>
+
+<p>22. HTML5/W3C IndexedDB API: <a href="http://www.w3.org/TR/IndexedDB/">http://www.w3.org/TR/IndexedDB/</a></p>
+
+<p>23. Dalvik Executable Format and bytecode specification: available in the
Android source code, at dalvik/docs</p>
-<p>21. AppWidgets: <a href="http://developer.android.com/guide/practices/ui_guidelines/widget_design.html">http://developer.android.com/guide/practices/ui_guidelines/widget_design.html</a></p>
+<p>24. AppWidgets: <a href="http://developer.android.com/guide/practices/ui_guidelines/widget_design.html">http://developer.android.com/guide/practices/ui_guidelines/widget_design.html</a></p>
-<p>22. Notifications: <a href="http://developer.android.com/guide/topics/ui/notifiers/notifications.html">http://developer.android.com/guide/topics/ui/notifiers/notifications.html</a></p>
+<p>25. Notifications: <a href="http://developer.android.com/guide/topics/ui/notifiers/notifications.html">http://developer.android.com/guide/topics/ui/notifiers/notifications.html</a></p>
-<p>23. Application Resources: <a href="https://developer.android.com/guide/topics/resources/available-resources.html">https://developer.android.com/guide/topics/resources/available-resources.html</a></p>
+<p>26. Application Resources: <a href="https://developer.android.com/guide/topics/resources/available-resources.html">https://developer.android.com/guide/topics/resources/available-resources.html</a></p>
-<p>24. Status Bar icon style guide: <a href="http://developer.android.com/design/style/iconography.html">http://developer.android.com/design/style/iconography.html</a></p>
+<p>27. Status Bar icon style guide: <a href="http://developer.android.com/design/style/iconography.html">http://developer.android.com/design/style/iconography.html</a></p>
-<p>25. Notifications Resources: <a href="https://developer.android.com/design/patterns/notifications.html">https://developer.android.com/design/patterns/notifications.html</a> </p>
+<p>28. Notifications Resources: <a href="https://developer.android.com/design/patterns/notifications.html">https://developer.android.com/design/patterns/notifications.html</a></p>
-<p>26. Search Manager: <a href="http://developer.android.com/reference/android/app/SearchManager.html">http://developer.android.com/reference/android/app/SearchManager.html</a> </p>
+<p>29. Search Manager: <a href="http://developer.android.com/reference/android/app/SearchManager.html">http://developer.android.com/reference/android/app/SearchManager.html</a></p>
-<p>27. Toasts: <a href="http://developer.android.com/reference/android/widget/Toast.html">http://developer.android.com/reference/android/widget/Toast.html</a></p>
+<p>30. Action Assist: <a href="http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST">http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST</a></p>
-<p>28. Themes: <a href="http://developer.android.com/guide/topics/ui/themes.html">http://developer.android.com/guide/topics/ui/themes.html</a></p>
+<p>31. Android Assist APIs: <a href="https://developer.android.com/reference/android/app/assist/package-summary.html">https://developer.android.com/reference/android/app/assist/package-summary.html</a></p>
-<p>29. R.style class: <a href="http://developer.android.com/reference/android/R.style.html">http://developer.android.com/reference/android/R.style.html</a></p>
+<p>32. Toasts: <a href="http://developer.android.com/reference/android/widget/Toast.html">http://developer.android.com/reference/android/widget/Toast.html</a></p>
-<p>30. Material design: <a href="http://developer.android.com/reference/android/R.style.html#Theme_Material">http://developer.android.com/reference/android/R.style.html#Theme_Material</a> </p>
+<p>33. Themes: <a href="http://developer.android.com/guide/topics/ui/themes.html">http://developer.android.com/guide/topics/ui/themes.html</a></p>
-<p>31. Live Wallpapers: <a href="http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html">http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html</a></p>
+<p>34. R.style class: <a href="http://developer.android.com/reference/android/R.style.html">http://developer.android.com/reference/android/R.style.html</a></p>
-<p>32. Overview screen resources: <a href="http://developer.android.com/guide/components/recents.html">http://developer.android.com/guide/components/recents.html</a> </p>
+<p>35. Material design: <a href="http://developer.android.com/reference/android/R.style.html#Theme_Material">http://developer.android.com/reference/android/R.style.html#Theme_Material</a></p>
-<p>33. Screen pinning: <a href="https://developer.android.com/about/versions/android-5.0.html#ScreenPinning">https://developer.android.com/about/versions/android-5.0.html#ScreenPinning</a> </p>
+<p>36. Live Wallpapers: <a href="http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html">http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html</a></p>
-<p>34. Input methods: <a href="http://developer.android.com/guide/topics/text/creating-input-method.html">http://developer.android.com/guide/topics/text/creating-input-method.html</a> </p>
+<p>37. Overview screen resources: <a href="http://developer.android.com/guide/components/recents.html">http://developer.android.com/guide/components/recents.html</a></p>
-<p>35. Media Notification: <a href="https://developer.android.com/reference/android/app/Notification.MediaStyle.html">https://developer.android.com/reference/android/app/Notification.MediaStyle.html</a></p>
+<p>38. Screen pinning: <a href="https://developer.android.com/about/versions/android-5.0.html#ScreenPinning">https://developer.android.com/about/versions/android-5.0.html#ScreenPinning</a></p>
-<p>36. Dreams: <a href="http://developer.android.com/reference/android/service/dreams/DreamService.html">http://developer.android.com/reference/android/service/dreams/DreamService.html</a></p>
+<p>39. Input methods: <a href="http://developer.android.com/guide/topics/text/creating-input-method.html">http://developer.android.com/guide/topics/text/creating-input-method.html</a></p>
-<p>37. Settings.Secure LOCATION_MODE:</p>
+<p>40. Media Notification: <a href="https://developer.android.com/reference/android/app/Notification.MediaStyle.html">https://developer.android.com/reference/android/app/Notification.MediaStyle.html</a></p>
-<p><a href="http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE">http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE</a></p>
+<p>41. Dreams: <a href="http://developer.android.com/reference/android/service/dreams/DreamService.html">http://developer.android.com/reference/android/service/dreams/DreamService.html</a></p>
-<p>38. Unicode 6.1.0: <a href="http://www.unicode.org/versions/Unicode6.1.0/">http://www.unicode.org/versions/Unicode6.1.0/</a></p>
+<p>42. Settings.Secure LOCATION_MODE: <a href="http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE">http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE</a></p>
-<p>39. Android Device Administration: <a href="http://developer.android.com/guide/topics/admin/device-admin.html">http://developer.android.com/guide/topics/admin/device-admin.html</a></p>
+<p>43. Unicode 6.1.0: <a href="http://www.unicode.org/versions/Unicode6.1.0/">http://www.unicode.org/versions/Unicode6.1.0/</a></p>
-<p>40. DevicePolicyManager reference: <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html">http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html</a></p>
+<p>44. Android Device Administration: <a href="http://developer.android.com/guide/topics/admin/device-admin.html">http://developer.android.com/guide/topics/admin/device-admin.html</a></p>
-<p>41. Android Device Owner App:</p>
+<p>45. DevicePolicyManager reference: <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html">http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html</a></p>
-<p><a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)">http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)</a></p>
+<p>46. Device Owner App: <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)">http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)</a></p>
-<p>42. Android Accessibility Service APIs: <a href="http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html">http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html</a></p>
-<p>43. Android Accessibility APIs: <a href="http://developer.android.com/reference/android/view/accessibility/package-summary.html">http://developer.android.com/reference/android/view/accessibility/package-summary.html</a></p>
+<p>47. Android Device Owner Provisioning Flow: <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_DEVICE">http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_DEVICE</a></p>
-<p>44. Eyes Free project: <a href="http://code.google.com/p/eyes-free/">http://code.google.com/p/eyes-free</a></p>
+<p>48. Device Owner Provisioning via NFC: <a href="https://source.android.com/devices/tech/admin/provision.html#device_owner_provisioning_via_nfc">https://source.android.com/devices/tech/admin/provision.html#device_owner_provisioning_via_nfc</a></p>
-<p>45. Text-To-Speech APIs: <a href="http://developer.android.com/reference/android/speech/tts/package-summary.html">http://developer.android.com/reference/android/speech/tts/package-summary.html</a></p>
+<p>49. Android Profile Owner App:<a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isProfileOwnerApp(java.lang.String)">http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isProfileOwnerApp(java.lang.String)</a></p>
-<p>46. Television Input Framework: <a href="https://source.android.com/devices/tv/index.html">https://source.android.com/devices/tv/index.html</a></p>
+<p>50. Android Managed Profile Provisioning flow: <a href="http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_PROFILE">http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#ACTION_PROVISION_MANAGED_PROFILE</a></p>
-<p>47. Reference tool documentation (for adb, aapt, ddms, systrace): <a href="http://developer.android.com/tools/help/index.html">http://developer.android.com/tools/help/index.html</a></p>
+<p>51. Android Accessibility Service APIs: <a href="http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html">http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html</a></p>
-<p>48. Android apk file description: <a href="http://developer.android.com/guide/components/fundamentals.html">http://developer.android.com/guide/components/fundamentals.html </a></p>
+<p>52. Android Accessibility APIs: <a href="http://developer.android.com/reference/android/view/accessibility/package-summary.html">http://developer.android.com/reference/android/view/accessibility/package-summary.html</a></p>
-<p>49. Manifest files: <a href="http://developer.android.com/guide/topics/manifest/manifest-intro.html">http://developer.android.com/guide/topics/manifest/manifest-intro.html</a></p>
+<p>53. Eyes Free project: <a href="http://code.google.com/p/eyes-free/">http://code.google.com/p/eyes-free</a></p>
-<p>50. Android Media Formats: <a href="http://developer.android.com/guide/appendix/media-formats.html">http://developer.android.com/guide/appendix/media-formats.html</a></p>
+<p>54. Text-To-Speech APIs: <a href="http://developer.android.com/reference/android/speech/tts/package-summary.html">http://developer.android.com/reference/android/speech/tts/package-summary.html</a></p>
-<p>51. RTC Hardware Coding Requirements: <a href="http://www.webmproject.org/hardware/rtc-coding-requirements/">http://www.webmproject.org/hardware/rtc-coding-requirements/</a></p>
+<p>55. Television Input Framework: <a href="https://source.android.com/devices/tv/index.html">https://source.android.com/devices/tv/index.html</a></p>
-<p>52. AudioEffect API: <a href="http://developer.android.com/reference/android/media/audiofx/AudioEffect.html">http://developer.android.com/reference/android/media/audiofx/AudioEffect.html</a></p>
+<p>56. TV App channels: <a href="http://developer.android.com/reference/android/media/tv/TvContract.Channels.html">http://developer.android.com/reference/android/media/tv/TvContract.Channels.html</a></p>
-<p>53. Android android.content.pm.PackageManager class and Hardware Features List:</p>
+<p>57. Third-party TV inputs: <a href="https://source.android.com/devices/tv/index.html#third-party_input_example">https://source.android.com/devices/tv/index.html#third-party_input_example</a></p>
-<p><a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">http://developer.android.com/reference/android/content/pm/PackageManager.html</a></p>
+<p>58. TV inputs: <a href="https://source.android.com/devices/tv/index.html#tv_inputs">https://source.android.com/devices/tv/index.html#tv_inputs</a></p>
-<p>54. HTTP Live Streaming Draft Protocol: <a href="http://tools.ietf.org/html/draft-pantos-http-live-streaming-03">http://tools.ietf.org/html/draft-pantos-http-live-streaming-03</a></p>
+<p>59. TV channel EPG fields: <a href="https://developer.android.com/reference/android/media/tv/TvContract.Programs.html">https://developer.android.com/reference/android/media/tv/TvContract.Programs.html</a></p>
-<p>55. ADB: <a href="http://developer.android.com/tools/help/adb.html">http://developer.android.com/tools/help/adb.html</a> </p>
+<p>60. TV input app linking: <a href="http://developer.android.com/reference/android/media/tv/TvContract.Channels.html#COLUMN_APP_LINK_INTENT_URI">http://developer.android.com/reference/android/media/tv/TvContract.Channels.html#COLUMN_APP_LINK_INTENT_URI</a></p>
-<p>56. Dumpsys: <a href="https://source.android.com/devices/input/diagnostics.html">https://source.android.com/devices/input/diagnostics.html</a> </p>
+<p>61. Reference tool documentation (for adb, aapt, ddms, systrace): <a href="http://developer.android.com/tools/help/index.html">http://developer.android.com/tools/help/index.html</a></p>
-<p>57. DDMS: <a href="http://developer.android.com/tools/debugging/ddms.html">http://developer.android.com/tools/debugging/ddms.html</a> </p>
+<p>62. Android apk file description: <a href="http://developer.android.com/guide/components/fundamentals.html">http://developer.android.com/guide/components/fundamentals.html</a></p>
-<p>58. Monkey testing tool: <a href="http://developer.android.com/tools/help/monkey.html">http://developer.android.com/tools/help/monkey.html</a> </p>
+<p>63. Manifest files: <a href="http://developer.android.com/guide/topics/manifest/manifest-intro.html">http://developer.android.com/guide/topics/manifest/manifest-intro.html</a></p>
+
+<p>64. Android Media Formats: <a href="http://developer.android.com/guide/appendix/media-formats.html">http://developer.android.com/guide/appendix/media-formats.html</a></p>
+
+<p>65. Android MediaCodecList API: <a href="http://developer.android.com/reference/android/media/MediaCodecList.html">http://developer.android.com/reference/android/media/MediaCodecList.html</a></p>
+
+<p>66. Android CamcorderProfile API: <a href="http://developer.android.com/reference/android/media/CamcorderProfile.html">http://developer.android.com/reference/android/media/CamcorderProfile.html</a></p>
+
+<p>67. WebM project: <a href="http://www.webmproject.org/">http://www.webmproject.org/</a></p>
+
+<p>68. RTC Hardware Coding Requirements: <a href="http://www.webmproject.org/hardware/rtc-coding-requirements/">http://www.webmproject.org/hardware/rtc-coding-requirements/</a></p>
+
+<p>69. AudioEffect API: <a href="http://developer.android.com/reference/android/media/audiofx/AudioEffect.html">http://developer.android.com/reference/android/media/audiofx/AudioEffect.html</a></p>
+
+<p>70. Android android.content.pm.PackageManager class and Hardware Features List: <a href="http://developer.android.com/reference/android/content/pm/PackageManager.html">http://developer.android.com/reference/android/content/pm/PackageManager.html</a></p>
+
+<p>71. HTTP Live Streaming Draft Protocol: <a href="http://tools.ietf.org/html/draft-pantos-http-live-streaming-03">http://tools.ietf.org/html/draft-pantos-http-live-streaming-03</a></p>
+
+<p>72. ADB: <a href="http://developer.android.com/tools/help/adb.html">http://developer.android.com/tools/help/adb.html</a></p>
+
+<p>73. Dumpsys: <a href="https://source.android.com/devices/input/diagnostics.html">https://source.android.com/devices/input/diagnostics.html</a></p>
+
+<p>74. DDMS: <a href="http://developer.android.com/tools/debugging/ddms.html">http://developer.android.com/tools/debugging/ddms.html</a></p>
+
+<p>75. Monkey testing tool: <a href="http://developer.android.com/tools/help/monkey.html">http://developer.android.com/tools/help/monkey.html</a></p>
+
+<p>76. SysyTrace tool: <a href="http://developer.android.com/tools/help/systrace.html">http://developer.android.com/tools/help/systrace.html</a></p>
+
+<p>77. Android Application Development-Related Settings: <a href="http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS">http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS</a></p>
+
+<p>78. Supporting Multiple Screens: <a href="http://developer.android.com/guide/practices/screens_support.html">http://developer.android.com/guide/practices/screens_support.html</a></p>
+
+<p>79. android.util.DisplayMetrics: <a href="http://developer.android.com/reference/android/util/DisplayMetrics.html">http://developer.android.com/reference/android/util/DisplayMetrics.html</a></p>
+
+<p>80. RenderScript: <a href="http://developer.android.com/guide/topics/renderscript/">http://developer.android.com/guide/topics/renderscript/</a></p>
+
+<p>81. Android extension pack for OpenGL ES: <a href="https://developer.android.com/reference/android/opengl/GLES31Ext.html">https://developer.android.com/reference/android/opengl/GLES31Ext.html</a></p>
+
+<p>82. Hardware Acceleration: <a href="http://developer.android.com/guide/topics/graphics/hardware-accel.html">http://developer.android.com/guide/topics/graphics/hardware-accel.html</a></p>
+
+<p>83. EGL Extension-EGL_ANDROID_RECORDABLE: <a href="http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt">http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt</a></p>
-<p>59. SysyTrace tool: <a href="http://developer.android.com/tools/help/systrace.html">http://developer.android.com/tools/help/systrace.html</a></p>
+<p>84. Display Manager: <a href="http://developer.android.com/reference/android/hardware/display/DisplayManager.html">http://developer.android.com/reference/android/hardware/display/DisplayManager.html</a></p>
-<p>60. Android Application Development-Related Settings:</p>
+<p>85. android.content.res.Configuration: <a href="http://developer.android.com/reference/android/content/res/Configuration.html">http://developer.android.com/reference/android/content/res/Configuration.html</a></p>
-<p><a href="http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS">http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS</a></p>
+<p>86. Touch Input Configuration: <a href="http://source.android.com/devices/tech/input/touch-devices.html">http://source.android.com/devices/tech/input/touch-devices.html</a></p>
-<p>61. Supporting Multiple Screens: <a href="http://developer.android.com/guide/practices/screens_support.html">http://developer.android.com/guide/practices/screens_support.html</a></p>
+<p>87. Motion Event API: <a href="http://developer.android.com/reference/android/view/MotionEvent.html">http://developer.android.com/reference/android/view/MotionEvent.html</a></p>
-<p>62. android.util.DisplayMetrics: <a href="http://developer.android.com/reference/android/util/DisplayMetrics.html">http://developer.android.com/reference/android/util/DisplayMetrics.html</a></p>
+<p>88. Key Event API: <a href="http://developer.android.com/reference/android/view/KeyEvent.html">http://developer.android.com/reference/android/view/KeyEvent.html</a></p>
-<p>63. RenderScript: <a href="http://developer.android.com/guide/topics/renderscript/">http://developer.android.com/guide/topics/renderscript/</a></p>
+<p>89. Android Open Source sensors: <a href="http://source.android.com/devices/sensors/">http://source.android.com/devices/sensors</a></p>
-<p>64. Android extension pack for OpenGL ES: <a href="https://developer.android.com/reference/android/opengl/GLES31Ext.html">https://developer.android.com/reference/android/opengl/GLES31Ext.html</a> </p>
+<p>90. android.hardware.SensorEvent: <a href="http://developer.android.com/reference/android/hardware/SensorEvent.html">http://developer.android.com/reference/android/hardware/SensorEvent.html</a></p>
-<p>65. Hardware Acceleration: <a href="http://developer.android.com/guide/topics/graphics/hardware-accel.html">http://developer.android.com/guide/topics/graphics/hardware-accel.html</a></p>
+<p>91. Timestamp sensor event: <a href="http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp">http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp</a></p>
-<p>66. EGL Extension-EGL_ANDROID_RECORDABLE:</p>
+<p>92. Android Open Source composite sensors: <a href="http://source.android.com/devices/sensors/sensor-types.html#composite_sensor_type_summary">https://source.android.com/devices/sensors/sensor-types.html#composite_sensor_type_summary</a></p>
-<p><a href="http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt">http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt</a></p>
+<p>93. Continuous trigger mode: <a href="http://source.android.com/devices/sensors/report-modes.html#continuous">https://source.android.com/devices/sensors/report-modes.html#continuous</a></p>
-<p>67. Display Manager: <a href="http://developer.android.com/reference/android/hardware/display/DisplayManager.html">http://developer.android.com/reference/android/hardware/display/DisplayManager.html</a></p>
+<p>94. Accelerometer sensor: <a href="http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER">http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER</a></p>
-<p>68. android.content.res.Configuration: <a href="http://developer.android.com/reference/android/content/res/Configuration.html">http://developer.android.com/reference/android/content/res/Configuration.html</a></p>
+<p>95. Android Fingerprint API: <a href="https://developer.android.com/reference/android/hardware/fingerprint/package-summary.html">https://developer.android.com/reference/android/hardware/fingerprint/package-summary.html</a></p>
-<p>69. Action Assist: <a href="http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST">http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST</a></p>
+<p>96. Android Fingerprint HAL: <a href="https://source.android.com/devices/tech/security/authentication/fingerprint-hal.html">https://source.android.com/devices/tech/security/authentication/fingerprint-hal.html</a></p>
-<p>70. Touch Input Configuration: <a href="http://source.android.com/devices/tech/input/touch-devices.html">http://source.android.com/devices/tech/input/touch-devices.html</a></p>
+<p>97. Wi-Fi Multicast API: <a href="http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html">http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html</a></p>
-<p>71. Motion Event API: <a href="http://developer.android.com/reference/android/view/MotionEvent.html">http://developer.android.com/reference/android/view/MotionEvent.html</a></p>
+<p>98. Wi-Fi Direct (Wi-Fi P2P): <a href="http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html">http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html</a></p>
-<p>72. Key Event API: <a href="http://developer.android.com/reference/android/view/KeyEvent.html">http://developer.android.com/reference/android/view/KeyEvent.html</a> </p>
+<p>99. WifiManager API: <a href="http://developer.android.com/reference/android/net/wifi/WifiManager.html">http://developer.android.com/reference/android/net/wifi/WifiManager.html</a></p>
-<p>73. Android Open Source sensors: <a href="http://source.android.com/devices/sensors/">http://source.android.com/devices/sensors</a></p>
+<p>100. Bluetooth API: <a href="http://developer.android.com/reference/android/bluetooth/package-summary.html">http://developer.android.com/reference/android/bluetooth/package-summary.html</a></p>
-<p>74. android.hardware.SensorEvent: <a href="http://developer.android.com/reference/android/hardware/SensorEvent.html">http://developer.android.com/reference/android/hardware/SensorEvent.html</a></p>
+<p>101. Bluetooth ScanFilter API: <a href="https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html">https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html</a></p>
-<p>75. Timestamp sensor event: <a href="http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp">http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp</a></p>
+<p>102. NFC Barcode: <a href="http://developer.android.com/reference/android/nfc/tech/NfcBarcode.html">http://developer.android.com/reference/android/nfc/tech/NfcBarcode.html</a></p>
-<p>76. Android Open Source composite sensors: <a href="http://source.android.com/devices/sensors/sensor-types.html#composite_sensor_type_summary">https://source.android.com/devices/sensors/sensor-types.html#composite_sensor_type_summary</a></p>
+<p>103. NDEF Push Protocol: <a href="http://source.android.com/compatibility/ndef-push-protocol.pdf">http://source.android.com/compatibility/ndef-push-protocol.pdf</a></p>
-<p>77. Continuous trigger mode: <a href="http://source.android.com/devices/sensors/report-modes.html#continuous">https://source.android.com/devices/sensors/report-modes.html#continuous</a></p>
+<p>104. Android Beam: <a href="http://developer.android.com/guide/topics/connectivity/nfc/nfc.html">http://developer.android.com/guide/topics/connectivity/nfc/nfc.html</a></p>
-<p>78. Accelerometer sensor: <a href="http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER">http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER</a></p>
+<p>105. Android NFC Sharing Settings: <a href="http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS">http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS</a></p>
-<p>79. Wi-Fi Multicast API: <a href="http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html">http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html</a></p>
+<p>106. NFC Connection Handover: <a href="http://members.nfc-forum.org/specs/spec_list/#conn_handover">http://members.nfc-forum.org/specs/spec_list/#conn_handover</a></p>
-<p>80. Wi-Fi Direct (Wi-Fi P2P): <a href="http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html">http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html</a></p>
+<p>107. Bluetooth Secure Simple Pairing Using NFC: <a href="http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf">http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf</a></p>
-<p>81. WifiManager API: <a href="http://developer.android.com/reference/android/net/wifi/WifiManager.html">http://developer.android.com/reference/android/net/wifi/WifiManager.html</a></p>
+<p>108. Host-based Card Emulation: <a href="http://developer.android.com/guide/topics/connectivity/nfc/hce.html">http://developer.android.com/guide/topics/connectivity/nfc/hce.html</a></p>
-<p>82. Bluetooth API: <a href="http://developer.android.com/reference/android/bluetooth/package-summary.html">http://developer.android.com/reference/android/bluetooth/package-summary.html</a></p>
+<p>109. Content Resolver: <a href="http://developer.android.com/reference/android/content/ContentResolver.html">http://developer.android.com/reference/android/content/ContentResolver.html</a></p>
-<p>83. Bluetooth ScanFilter API: <a href="https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html">https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html</a></p>
+<p>110. Camera orientation API: <a href="http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)">http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)</a></p>
-<p>84. NDEF Push Protocol: <a href="http://source.android.com/compatibility/ndef-push-protocol.pdf">http://source.android.com/compatibility/ndef-push-protocol.pdf</a></p>
+<p>111. Camera: <a href="http://developer.android.com/reference/android/hardware/Camera.html">http://developer.android.com/reference/android/hardware/Camera.html</a></p>
-<p>85. Android Beam: <a href="http://developer.android.com/guide/topics/connectivity/nfc/nfc.html">http://developer.android.com/guide/topics/connectivity/nfc/nfc.html</a> </p>
+<p>112. Camera: <a href="http://developer.android.com/reference/android/hardware/Camera.Parameters.html">http://developer.android.com/reference/android/hardware/Camera.Parameters.html</a></p>
-<p>86. Android NFC Sharing Settings:</p>
+<p>113. Camera hardware level: <a href="https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL">https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL</a></p>
-<p><a href="http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS">http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS</a></p>
+<p>114. Camera version support: <a href="http://source.android.com/devices/camera/versioning.html">http://source.android.com/devices/camera/versioning.html</a></p>
-<p>87. NFC Connection Handover: <a href="http://members.nfc-forum.org/specs/spec_list/#conn_handover">http://members.nfc-forum.org/specs/spec_list/#conn_handover</a></p>
+<p>115. Android DownloadManager: <a href="http://developer.android.com/reference/android/app/DownloadManager.html">http://developer.android.com/reference/android/app/DownloadManager.html</a></p>
-<p>88. Bluetooth Secure Simple Pairing Using NFC: <a href="http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf">http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf</a> </p>
+<p>116. Android File Transfer: <a href="http://www.android.com/filetransfer">http://www.android.com/filetransfer</a></p>
-<p>89. Content Resolver: <a href="http://developer.android.com/reference/android/content/ContentResolver.html">http://developer.android.com/reference/android/content/ContentResolver.html</a></p>
+<p>117. Adoptable storage: <a href="http://source.android.com/devices/storage/adoptable.html">http://source.android.com/devices/storage/adoptable.html</a></p>
-<p>90. Camera orientation API: <a href="http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)">http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)</a></p>
+<p>118. Android Open Accessories: <a href="http://developer.android.com/guide/topics/connectivity/usb/accessory.html">http://developer.android.com/guide/topics/connectivity/usb/accessory.html</a></p>
-<p>91. Camera: <a href="http://developer.android.com/reference/android/hardware/Camera.html">http://developer.android.com/reference/android/hardware/Camera.html</a></p>
+<p>119. Android USB Audio: <a href="http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO">http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO</a></p>
-<p>92. Camera: <a href="http://developer.android.com/reference/android/hardware/Camera.Parameters.html">http://developer.android.com/reference/android/hardware/Camera.Parameters.html</a></p>
+<p>120. USB Charging Specification: <a href="http://www.usb.org/developers/docs/devclass_docs/USB_Battery_Charging_1.2.pdf">http://www.usb.org/developers/docs/devclass_docs/USB_Battery_Charging_1.2.pdf</a></p>
-<p>93. Camera hardware level: <a href="https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL">https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL</a> </p>
+<p>121. USB Host API:<a href="http://developer.android.com/guide/topics/connectivity/usb/host.html"> http://developer.android.com/guide/topics/connectivity/usb/host.html</a></p>
-<p>94. Camera version support: <a href="http://source.android.com/devices/camera/versioning.html">http://source.android.com/devices/camera/versioning.html</a> </p>
+<p>122. Wired audio headset: <a href="http://source.android.com/accessories/headset-spec.html">http://source.android.com/accessories/headset-spec.html</a></p>
-<p>95. Android DownloadManager: <a href="http://developer.android.com/reference/android/app/DownloadManager.html">http://developer.android.com/reference/android/app/DownloadManager.html</a></p>
+<p>123. Power profile components: <a href="http://source.android.com/devices/tech/power/values.html">http://source.android.com/devices/tech/power/values.html</a></p>
-<p>96. Android File Transfer: <a href="http://www.android.com/filetransfer">http://www.android.com/filetransfer</a></p>
+<p>124. Batterystats: <a href="http://source.android.com/devices/tech/power/batterystats.html">http://source.android.com/devices/tech/power/batterystats.html</a></p>
-<p>97. Android Open Accessories: <a href="http://developer.android.com/guide/topics/connectivity/usb/accessory.html">http://developer.android.com/guide/topics/connectivity/usb/accessory.html</a></p>
+<p>125. Power usage summary: <a href="http://developer.android.com/reference/android/content/Intent.html#ACTION_POWER_USAGE_SUMMARY">http://developer.android.com/reference/android/content/Intent.html#ACTION_POWER_USAGE_SUMMARY</a></p>
-<p>98. Android USB Audio: <a href="http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO">http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO</a></p>
+<p>126. Android Security and Permissions reference: <a href="http://developer.android.com/guide/topics/security/permissions.html">http://developer.android.com/guide/topics/security/permissions.html</a></p>
-<p>99. USB Charging Specification: <a href="http://www.usb.org/developers/docs/devclass_docs/USB_Battery_Charging_1.2.pdf">http://www.usb.org/developers/docs/devclass_docs/USB_Battery_Charging_1.2.pdf</a></p>
+<p>127. UserManager reference: <a href="http://developer.android.com/reference/android/os/UserManager.html">http://developer.android.com/reference/android/os/UserManager.html</a></p>
-<p>100. USB Host API:<a href="http://developer.android.com/guide/topics/connectivity/usb/host.html"> http://developer.android.com/guide/topics/connectivity/usb/host.html</a></p>
+<p>128. External Storage reference: <a href="http://source.android.com/devices/storage/traditional.html">http://source.android.com/devices/storage</a></p>
-<p>101. Wired audio headset: <a href="http://source.android.com/accessories/headset-spec.html">http://source.android.com/accessories/headset-spec.html</a> </p>
+<p>129. External Storage APIs: <a href="http://developer.android.com/reference/android/os/Environment.html">http://developer.android.com/reference/android/os/Environment.html</a></p>
-<p>102. Android Security and Permissions reference: <a href="http://developer.android.com/guide/topics/security/permissions.html">http://developer.android.com/guide/topics/security/permissions.html</a></p>
+<p>130. SMS Short Code: <a href="http://en.wikipedia.org/wiki/Short_code">http://en.wikipedia.org/wiki/Short_code</a></p>
-<p>103. UserManager reference: <a href="http://developer.android.com/reference/android/os/UserManager.html">http://developer.android.com/reference/android/os/UserManager.html</a></p>
+<p>131. Secure lock screen reporting: <a href="http://developer.android.com/reference/android/app/KeyguardManager.html#isDeviceSecure()">http://developer.android.com/reference/android/app/KeyguardManager.html#isDeviceSecure()</a></p>
-<p>104. External Storage reference: <a href="http://source.android.com/devices/storage">http://source.android.com/devices/storage</a></p>
+<p>132. Android Open Source Encryption: <a href="http://source.android.com/devices/tech/security/encryption/index.html">http://source.android.com/devices/tech/security/encryption/index.html</a></p>
-<p>105. External Storage APIs: <a href="http://developer.android.com/reference/android/os/Environment.html">http://developer.android.com/reference/android/os/Environment.html</a></p>
+<p>133. Android Keystore System: <a href="https://developer.android.com/training/articles/keystore.html">https://developer.android.com/training/articles/keystore.html</a></p>
-<p>106. SMS Short Code: <a href="http://en.wikipedia.org/wiki/Short_code">http://en.wikipedia.org/wiki/Short_code</a></p>
+<p>134. KeyChain API: <a href="https://developer.android.com/reference/android/security/KeyChain.html">https://developer.android.com/reference/android/security/KeyChain.html</a></p>
-<p>107. Android Open Source Encryption: <a href="http://source.android.com/devices/tech/security/encryption/index.html">http://source.android.com/devices/tech/security/encryption/index.html</a></p>
+<p>135. Keystore API: <a href="https://developer.android.com/reference/java/security/KeyStore.html">https://developer.android.com/reference/java/security/KeyStore.html</a></p>
-<p>108. Android Compatibility Program Overview: <a href="http://source.android.com/compatibility/index.html">http://source.android.com/compatibility/index.html</a></p>
+<p>136. Gatekeeper HAL: <a href="http://source.android.com/devices/tech/security/authentication/gatekeeper.html">http://source.android.com/devices/tech/security/authentication/gatekeeper.html</a></p>
-<p>109. Android Compatibility forum: <a href="https://groups.google.com/forum/#!forum/android-compatibility">https://groups.google.com/forum/#!forum/android-compatibility</a></p>
+<p>137. Android Compatibility Program Overview: <a href="http://source.android.com/compatibility/index.html">http://source.android.com/compatibility/index.html</a></p>
-<p>110. WebM project: <a href="http://www.webmproject.org/">http://www.webmproject.org/</a> </p>
+<p>138. SystemUpdatePolicy class: <a href="http://developer.android.com/reference/android/app/admin/SystemUpdatePolicy.html">http://developer.android.com/reference/android/app/admin/SystemUpdatePolicy.html</a></p>
-<p>111. Android UI_MODE_TYPE_CAR API: <a href="http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR">http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_CAR</a></p>
+<p>139. Android Compatibility forum: <a href="https://groups.google.com/forum/#!forum/android-compatibility">https://groups.google.com/forum/#!forum/android-compatibility</a></p>
-<p>112. Android MediaCodecList API: <a href="http://developer.android.com/reference/android/media/MediaCodecList.html">http://developer.android.com/reference/android/media/MediaCodecList.html</a></p>
+<p>140. Handling app links: <a href="https://developer.android.com/training/app-links">https://developer.android.com/training/app-links/index.html</a></p>
-<p>113. Android CamcorderProfile API: <a href="http://developer.android.com/reference/android/media/CamcorderProfile.html">http://developer.android.com/reference/android/media/CamcorderProfile.html</a></p>
+<p>141. Google Digital Asset Links: <a href="https://developers.google.com/digital-asset-links">https://developers.google.com/digital-asset-links</a></p>
<p>Many of these resources are derived directly or indirectly from the Android
SDK, and will be functionally identical to the information in that SDK’s
diff --git a/src/compatibility/android-cdd.pdf b/src/compatibility/android-cdd.pdf
index 55023f5..a0ca71d 100644
--- a/src/compatibility/android-cdd.pdf
+++ b/src/compatibility/android-cdd.pdf
Binary files differ
diff --git a/src/compatibility/downloads.jd b/src/compatibility/downloads.jd
index 94d5754..9eb072a 100644
--- a/src/compatibility/downloads.jd
+++ b/src/compatibility/downloads.jd
@@ -32,6 +32,8 @@
The source code for the following tests can be synced with the
'android-cts-6.0_r1' tag in the open-source tree.</p>
<ul>
+<li><a href="6.0/android-6.0-cdd.pdf">Android 6.0 Compatibility Definition
+Document (CDD)</a></li>
<li><a
href="https://dl.google.com/dl/android/cts/android-cts-6.0_r1-linux_x86-arm.zip">Android
6.0 R1 Compatibility Test Suite (CTS) - ARM</a></li>
@@ -141,7 +143,7 @@
</ul>
<h2 id="android-403">Android 4.0.3</h2>
<p>Android 4.0.3 is the release of the development milestone code-named
-Ice Cream Sandwich. Android 4.0.3 is the current version of Android. Source code for
+Ice Cream Sandwich. Source code for
Android 4.0.3 is found in the 'android-4.0.3_r1' branch in the open source tree.</p>
<ul>
<li><a href="4.0/android-4.0-cdd.pdf">Android 4.0 Compatibility Definition Document (CDD)</a></li>
diff --git a/src/compatibility/source/android-cdd-cover.html b/src/compatibility/source/android-cdd-cover.html
index eccca0c..ee76ef8 100644
--- a/src/compatibility/source/android-cdd-cover.html
+++ b/src/compatibility/source/android-cdd-cover.html
@@ -17,14 +17,14 @@
<tr>
<td>
-<img src="images/android-marshmallow.png" alt="Marshmallow logo" style="border-top: 5px solid orange; border-bottom: 5px solid orange"/>
+<img src="images/android-marshmallow-1.png" alt="Marshmallow logo" style="border-top: 5px solid orange; border-bottom: 5px solid orange"/>
</td>
</tr>
<tr>
<td>
<p class="subtitle">Android 6.0</p>
-<p class="cover-text">Last updated: August 20th, 2015</p>
+<p class="cover-text">Last updated: October 7th, 2015</p>
<p class="cover-text">Copyright © 2015, Google Inc. All rights reserved.</p>
<p class="cover-text"><a href="mailto:compatibility@android.com">compatibility@android.com</a></p>
</td>
diff --git a/src/compatibility/source/android-cdd-footer.html b/src/compatibility/source/android-cdd-footer.html
index dfb0f51..fce6481 100644
--- a/src/compatibility/source/android-cdd-footer.html
+++ b/src/compatibility/source/android-cdd-footer.html
@@ -24,7 +24,7 @@
<table class="noborder" style="border-top: 1px solid silver; width: 100%">
<tr>
- <td class="noborder"><img src="images/android-logo.png" alt="Android logo"/></td>
+ <td class="noborder"><img src="../images/android-logo.png" alt="Android logo"/></td>
<td class="noborder" style="text-align:right">
Page <span class="page"></span> of <span class="topage"></span>
</td>
@@ -34,4 +34,4 @@
</div>
</body>
-</html>
+</html>
\ No newline at end of file
diff --git a/src/compatibility/source/android-cdd.css b/src/compatibility/source/android-cdd.css
index 83c46bc..cef5969 100644
--- a/src/compatibility/source/android-cdd.css
+++ b/src/compatibility/source/android-cdd.css
@@ -284,16 +284,14 @@
width: 950px;
}
-#toc_left,
-#toc_left_2 {
+#toc_left {
float: left;
padding-top:15px;
padding-bottom:15px;
width: 470px;
}
-#toc_right,
-#toc_right_2 {
+#toc_right {
float: right;
padding-top:15px;
padding-bottom:15px;
diff --git a/src/compatibility/source/images/android-marshmallow-1.png b/src/compatibility/source/images/android-marshmallow-1.png
new file mode 100644
index 0000000..4d51b87
--- /dev/null
+++ b/src/compatibility/source/images/android-marshmallow-1.png
Binary files differ
diff --git a/src/devices/Android-6.0-Bluetooth-HCI-Reqs.pdf b/src/devices/Android-6.0-Bluetooth-HCI-Reqs.pdf
new file mode 100644
index 0000000..5a3e0f7
--- /dev/null
+++ b/src/devices/Android-6.0-Bluetooth-HCI-Reqs.pdf
Binary files differ
diff --git a/src/devices/audio/midi_test.jd b/src/devices/audio/midi_test.jd
new file mode 100644
index 0000000..fa80670
--- /dev/null
+++ b/src/devices/audio/midi_test.jd
@@ -0,0 +1,259 @@
+page.title=MIDI Test Procedure
+@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>These tests may be used to validate the MIDI feature on Android devices.
+Successful execution of these tests is a prerequisite to
+<a href="midi.html#claim-feature">claim the MIDI feature</a>.
+</p>
+
+<h2 id="preparation">Preparation</h2>
+
+
+<h3 id="hardware">Hardware</h3>
+
+<p>
+The following hardware is needed for the tests.
+</p>
+
+<ul>
+ <li> MIDI keyboard with USB connector, e.g. the <a href="http://www.akaipro.com/product/lpk25">Akai LPK25</a></li>
+ <li> MIDI keyboard with Bluetooth Low Energy (BLE) support, e.g. the <a href="http://miselu.com/">Miselu C.24</a></li>
+ <li> USB cables</li>
+ <li> USB On-The-Go (OTG) adapter to convert a female USB-A to male micro-USB or USB-C</li>
+ <li> Android device running Android 6.0 Marshmallow or later release</li>
+ <li> Optional: desktop computer</li>
+</ul>
+
+<h3 id="apps">Apps</h3>
+
+
+<p>Several apps are used by this test procedure:</p>
+
+<table>
+<tr>
+ <th>App</th>
+ <th>Description</th>
+</tr>
+<tr>
+ <td><a href="https://github.com/philburk/android-midisuite/tree/master/MidiScope">MidiScope</a> or
+ <a href="https://github.com/googlesamples/android-MidiScope">MidiScope</a></td>
+ <td>displays MIDI messages on-screen</td>
+</tr>
+<tr>
+ <td><a href="https://github.com/philburk/android-midisuite/tree/master/MidiKeyboard">MidiKeyboard</a></td>
+ <td>sends MIDI messages by pressing an on-screen music keyboard</td>
+</tr>
+<tr>
+ <td><a href="https://github.com/philburk/android-midisuite/tree/master/MidiSynthExample">MidiSynthExample</a> or
+ <br /><a href="https://github.com/googlesamples/android-MidiSynth">MidiSynth</a></td>
+ <td>simple MIDI synthesizer that uses sawtooth oscillators</td>
+</tr>
+<tr>
+ <td><a href="https://github.com/philburk/android-midisuite/tree/master/MidiBtlePairing">MidiBtlePairing</a></td>
+ <td>pairs an Android device with a BLE peripheral</td>
+</tr>
+<tr>
+ <td><a href="https://github.com/philburk/android-midisuite/tree/master/MidiTools">MidiTools</a></td>
+ <td>library dependency of the above apps</td>
+</tr>
+</table>
+
+<p>
+Most of these apps are part of the GitHub project
+<a href="https://github.com/philburk/android-midisuite">android-midisuite</a>.
+</p>
+
+<p>Each test has a list of apps that are used. After building each app, you can install the app using
+<a href="http://developer.android.com/tools/help/adb.html">Android Debug Bridge</a> (ADB).
+For example, to install the <em>MidiScope</em> app:</p>
+
+<ol>
+ <li> Use a workstation with ADB installed.</li>
+ <li> Connect a USB cable from the workstation to the Android device.</li>
+ <li> You may need to allow the USB connection on the Android device; see <a href="midi.html#usb-peripheral">USB peripheral mode</a></li>
+ <li> On the workstation, enter:</li>
+</ol>
+
+<pre>
+cd <em><this-folder></em>
+adb install -r MidiScope.apk
+</pre>
+
+
+<h2 id="virtual_synth_tests">Virtual synth tests</h2>
+
+
+<p>Note that a MIDI input port can have only one connection. So if another app is
+already using an input port, that port will not be available. If you cannot connect to
+an input port then try closing other apps.</p>
+
+<p>Hardware needed: Android device under test</p>
+
+<h3 id="simple_connection">Simple connection</h3>
+
+
+<p>Apps needed: <em>MidiKeyboard</em>, <em>MidiSynthExample</em></p>
+
+<p>This tests device enumeration, virtual devices, port connections, and message
+sending.</p>
+
+<ol>
+ <li> Adjust volume on Android device to about halfway.</li>
+ <li> Orient phone in landscape mode.</li>
+ <li> Launch <em>MidiKeyboard</em> app.</li>
+ <li> Select <strong>SynthExample</strong> from the spinner menu.</li>
+ <li> Play keys. You should hear notes being played in the <em>SynthExample</em> app.</li>
+ <li> Exit the application by pressing the <strong>Back</strong> button so that the port will be
+closed.</li>
+</ol>
+
+<h2 id="host_mode">USB test: host mode</h2>
+
+
+<p>Hardware needed: USB MIDI keyboard, USB cable, OTG adapter</p>
+
+<p>Repeat these tests several times. We have seen the USB stack crash hard on some
+prototype devices if devices were plugged in and unplugged a few times.</p>
+
+<h3 id="keyboard_already_plugged_in">Keyboard already plugged in</h3>
+
+
+<p>Apps needed: <em>MidiSynthExample</em> or <em>MidiScope</em></p>
+
+<p>This tests USB MIDI in host mode.</p>
+
+<ol>
+ <li> Adjust volume on Android device to about halfway.</li>
+ <li> Plug in USB keyboard using the OTG adapter.</li>
+ <li> Launch <em>SynthExample</em> app or the <em>MidiScope</em> app.</li>
+ <li> From the menu select the USB keyboard. It will display the brand.</li>
+ <li> Play notes on the keyboard. If you ran <em>SynthExample</em> then you should hear notes
+being played on the phone. If you ran <em>MidiScope</em> then you should see <em>NoteOn</em> and
+<em>NoteOff</em> messages on-screen.</li>
+ <li> Unplug the keyboard. The <em>Sender for Synth</em> menu should display <em>- - - - -</em>.</li>
+ <li> Exit the application by pressing the <strong>Back</strong> button.</li>
+</ol>
+
+<h3 id="hot_plug_usb_keyboard">Hot-plug USB keyboard</h3>
+
+
+<p>Apps needed: <em>MidiSynthExample</em> or <em>MidiScope</em></p>
+
+<p>This tests USB MIDI in host mode.</p>
+
+<ol>
+ <li> Adjust volume on Android device to about halfway.</li>
+ <li> Make sure there is not a USB MIDI keyboard plugged in.</li>
+ <li> Launch <em>SynthExample</em> app.</li>
+ <li> At middle, next to <em>Sender for Synth</em>, look in menu. You should not see the USB
+keyboard listed.</li>
+ <li> Plug in USB keyboard using the OTG adapter.</li>
+ <li> At middle, next to <em>Sender for Synth</em>, select the USB keyboard. It will display
+the brand.</li>
+ <li> Play notes on the keyboard. You should hear notes being played on the phone.</li>
+ <li> At middle, next to <em>Sender for Synth</em>, select <strong>- - - - -</strong>.</li>
+ <li> Play notes on the keyboard. You should hear nothing.</li>
+ <li> At middle, next to <em>Sender for Synth</em>, select the USB keyboard. It will display
+the brand.</li>
+ <li> Play notes on the keyboard. You should hear notes being played on the phone.</li>
+ <li> Unplug the synthesizer. The <em>Sender for Synth</em> menu should display <em>- - - - -</em>.</li>
+ <li> Exit the application by pressing the <strong>Back</strong> button.</li>
+</ol>
+
+<h2 id="peripheral_mode">USB test: peripheral mode</h2>
+
+
+<p>Hardware needed: USB cable, OTG adapter</p>
+
+<h3 id="android_to_android">Android-to-Android</h3>
+
+
+<p>Apps needed: <em>MidiKeyboard</em> on Android device under test, <em>MidiScope</em> on another
+Android device.</p>
+
+<p>Use Android devices as a peripheral controller for another Android device. To help test
+this mode, use another Android device running in host mode. Note that
+you could modify the test to work with a desktop computer running Digital Audio Workstation (DAW)
+software such as
+GarageBand.</p>
+
+<ol>
+ <li> Connect the USB cable to the Android device under test (Android device <strong>A</strong>).</li>
+ <li> Use an OTG adapter to connect the other end of the cable to a second Android
+device <strong>B</strong> that operates in host mode.</li>
+ <li> On Android device A:
+ <ol>
+ <li> Drag finger down from top of screen.</li>
+ <li> Select <strong>USB for Charging</strong> icon.</li>
+ <li> Select <strong>MIDI</strong>.</li>
+ <li> Launch <em>MidiKeyboard</em> app.</li>
+ <li> Select <strong>Android USB Peripheral Port</strong> from <em>Receiver for Keys</em> menu at top.</li>
+ </ol>
+ </li>
+ <li> On Android device B:
+ <ol>
+ <li> Launch <em>MidiScope</em> app.</li>
+ <li> Select the other Android device as the source.</li>
+ </ol>
+ </li>
+ <li> On Android device A:
+ <ol>
+ <li> Play notes on the keyboard and look for <em>NoteOn</em> and <em>NoteOff</em> on Android device B.</li>
+ </ol>
+ </li>
+ </ol>
+
+<h2 id="bluetooth_le_test">BLE test</h2>
+
+
+<p>Hardware needed: MIDI keyboard supporting BLE</p>
+
+<h3 id="basic_pairing_and_playing">Basic pairing and playing</h3>
+
+
+<p>Apps needed: <em>MidiBtlePairing</em>, <em>MidiSynthExample</em></p>
+
+<p>Test a keyboard connected to Android over BLE.</p>
+
+<ol>
+ <li> Reboot the Android device.</li>
+ <li> Power on the BLE keyboard.<br />
+ (The Miselu C.24 keyboard is powered on by pushing the button near the back so
+that it pops open. The power button on the C.24 pulses blue when in pairing
+mode.)</li>
+ <li> Launch the <em>MidiBtlePairing</em> app. It has a <em>MIDI+BTLE</em> icon.</li>
+ <li> Press the <strong>Bluetooth Scan</strong> button.</li>
+ <li> Select desired BLE peripheral.</li>
+ <li> The app should return to the main page, and you should see the peripheral listed. If
+you are using a C.24, then you will notice that the light should turn green on
+the C.24 to indicate paired mode.</li>
+ <li> Exit the app by pressing the <strong>Home</strong> button, not the <strong>Back</strong> button.</li>
+ <li> Launch the SynthExample app.</li>
+ <li> Select the BLE keyboard as the sender from the menu.</li>
+ <li> You should be able to press keys on the BLE keyboard and hear notes on
+Android.</li>
+</ol>
diff --git a/src/devices/bluetooth.jd b/src/devices/bluetooth.jd
index a1ec72f..9137e5b 100644
--- a/src/devices/bluetooth.jd
+++ b/src/devices/bluetooth.jd
@@ -26,9 +26,13 @@
<img style="float: right; margin: 0px 15px 15px 15px;" src="images/ape_fwk_hal_bluetooth.png" alt="Android Bluetooth HAL icon"/>
-<p>Android provides a default Bluetooth stack that is divided into two layers: The Bluetooth Embedded System (BTE), which implements the core Bluetooth functionality, and the Bluetooth Application Layer (BTA), which communicates with Android framework applications.</p>
+<p>Android provides a default Bluetooth stack that is divided into two layers: The Bluetooth Embedded System (BTE),
+which implements the core Bluetooth functionality, and the Bluetooth Application Layer (BTA), which
+communicates with Android framework applications.</p>
-<p>To fully leverage the <a href="http://developer.android.com/about/versions/android-5.0.html#BluetoothBroadcasting">Bluetooth Low Energy APIs</a> added in Android 5.0, you should implement the <a href="Android-5.0-Bluetooth-HCI-Reqs.pdf">Android 5.0 Bluetooth HCI Requirements</a>.</p>
+<p>To fully leverage the <a href="http://developer.android.com/about/versions/android-5.0.html#BluetoothBroadcasting">Bluetooth Low Energy APIs</a>
+added in Android 5.0, you should implement the <a href="Android-6.0-Bluetooth-HCI-Reqs.pdf">Android 6.0 Bluetooth HCI Requirements</a>.
+That document initially was provided as the <a href="Android-5.0-Bluetooth-HCI-Reqs.pdf">Android 5.0 Bluetooth HCI Requirements</a>.</p>
<h2 id="architecture">Architecture</h2>
<p>A Bluetooth system service communicates with the Bluetooth stack through JNI and with applications through Binder IPC. The system service provides developers with access to various Bluetooth profiles. The following diagram shows the general structure of the Bluetooth stack:
diff --git a/src/devices/devices_toc.cs b/src/devices/devices_toc.cs
index c1149ec..85c5f76 100644
--- a/src/devices/devices_toc.cs
+++ b/src/devices/devices_toc.cs
@@ -52,7 +52,15 @@
<li><a href="<?cs var:toroot ?>devices/audio/avoiding_pi.html">Priority Inversion</a></li>
<li><a href="<?cs var:toroot ?>devices/audio/src.html">Sample Rate Conversion</a></li>
<li><a href="<?cs var:toroot ?>devices/audio/debugging.html">Debugging</a></li>
- <li><a href="<?cs var:toroot ?>devices/audio/midi.html">MIDI</a></li>
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>devices/audio/midi.html">
+ <span class="em">MIDI</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>devices/audio/midi_test.html">MIDI Test Procedure</a></li>
+ </ul>
<li><a href="<?cs var:toroot ?>devices/audio/usb.html">USB Digital Audio</a></li>
<li><a href="<?cs var:toroot ?>devices/audio/tv.html">TV Audio</a></li>
</ul>
@@ -121,7 +129,17 @@
<li><a href="<?cs var:toroot ?>devices/input/validate-keymaps.html">Validate Keymaps</a></li>
</ul>
</li>
- <li><a href="<?cs var:toroot ?>devices/media.html">Media</a></li>
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>devices/media/index.html">
+ <span class="en">Media</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>devices/media/soc.html">SoC Dependencies</a></li>
+ <li><a href="<?cs var:toroot ?>devices/media/oem.html">OEM Dependencies</a></li>
+ </ul>
+ </li>
<li class="nav-section">
<div class="nav-section-header">
<a href="<?cs var:toroot ?>devices/sensors/index.html">
@@ -147,8 +165,10 @@
</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>
+ <li><a href="<?cs var:toroot ?>devices/storage/traditional.html">Traditional Storage</a></li>
+ <li><a href="<?cs var:toroot ?>devices/storage/adoptable.html">Adoptable Storage</a></li>
+ <li><a href="<?cs var:toroot ?>devices/storage/config.html">Device Configuration</a></li>
+ <li><a href="<?cs var:toroot ?>devices/storage/config-example.html">Configuration Examples</a></li>
</ul>
</li>
<li class="nav-section">
@@ -184,6 +204,7 @@
<li><a href="<?cs var:toroot ?>devices/tech/dalvik/instruction-formats.html">Instruction Formats</a></li>
<li><a href="<?cs var:toroot ?>devices/tech/dalvik/constraints.html">Constraints</a></li>
<li><a href="<?cs var:toroot ?>devices/tech/dalvik/configure.html">Configuration</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/dalvik/gc-debug.html">Garbage Collection</a></li>
</ul>
</li>
@@ -194,11 +215,14 @@
</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/config/carrier.html">Carrier Customization</a></li>
+ <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>
+ <li><a href="<?cs var:toroot ?>devices/tech/config/voicemail.html">Visual Voicemail</a></li>
</ul>
</li>
@@ -277,6 +301,8 @@
<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/mgmt.html">Power Management</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>
@@ -328,7 +354,29 @@
</a>
</div>
<ul>
- <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/authentication/index.html">
+ <span class="en">Authentication</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>devices/tech/security/authentication/fingerprint-hal.html">Fingerprint HAL</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/security/authentication/gatekeeper.html">Gatekeeper</a></li>
+ <li class="nav-section">
+ <div class="nav-section-header">
+ <a href="<?cs var:toroot ?>devices/tech/security/authentication/keymaster.html">
+ <span class="en">Keymaster</span>
+ </a>
+ </div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>devices/tech/security/authentication/km-features.html">Features</a></li>
+ <li><a href="<?cs var:toroot ?>devices/tech/security/authentication/km-implementer-ref.html">Implementer's Reference</a></li>
+ </ul>
+ </li>
+ </ul>
+ </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">
@@ -360,7 +408,6 @@
<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/images/media.png b/src/devices/images/media.png
deleted file mode 100644
index 7aaee93..0000000
--- a/src/devices/images/media.png
+++ /dev/null
Binary files differ
diff --git a/src/devices/images/ape_fwk_hal_media.png b/src/devices/media/images/ape_fwk_hal_media.png
similarity index 100%
rename from src/devices/images/ape_fwk_hal_media.png
rename to src/devices/media/images/ape_fwk_hal_media.png
Binary files differ
diff --git a/src/devices/images/ape_fwk_media.png b/src/devices/media/images/ape_fwk_media.png
similarity index 100%
rename from src/devices/images/ape_fwk_media.png
rename to src/devices/media/images/ape_fwk_media.png
Binary files differ
diff --git a/src/devices/media.jd b/src/devices/media/index.jd
similarity index 100%
rename from src/devices/media.jd
rename to src/devices/media/index.jd
diff --git a/src/devices/media/oem.jd b/src/devices/media/oem.jd
new file mode 100644
index 0000000..a271ecd
--- /dev/null
+++ b/src/devices/media/oem.jd
@@ -0,0 +1,162 @@
+page.title=OEM Dependencies for Media Resource Manager
+@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>This document is intended to help original equipment manufacturers (OEMs)
+properly implement support for Android media resource manager and related APIs.</p>
+
+<h2 id=1_max_concurrent_codec_instances>1. Max concurrent codec instances</h2>
+
+<p>The <code>CodecCapabilities.getMaxSupportedInstances</code> interface
+returns the maximum number of supported concurrent codec instances.</p>
+
+<p>The CTS test
+<code>testGetMaxSupportedInstances(android.media.cts.MediaCodecCapabilitiesTest)</code>
+is used to enforce the proper maximum is set in
+<code>/etc/media_codecs.xml</code>.</p>
+
+<p>Here is an example:</p>
+
+<pre>
+...
+<MediaCodecs>
+ ...
+ <Encoders>
+ <MediaCodec name="OMX.<em><vendor></em>.video.encoder.avc" type="video/avc" >
+ ...
+ <Limit name="concurrent-instances" max="13" />
+ </MediaCodec>
+ ...
+ </Encoders>
+ ...
+</MediaCodecs>
+</pre>
+
+<p>OEMs can use this test to generate the concurrent limits that pass the test.
+To do this:</p>
+
+ <ol>
+ <li>Run the test first using cts-tradefed.
+ <li>Evaluate the resulting failure message. Here is an example:
+
+<pre>
+There was 1 failure:
+1) testGetMaxSupportedInstances(android.media.cts.MediaCodecCapabilitiesTest)
+junit.framework.AssertionFailedError: In order to pass the test, please publish
+following codecs' concurrent instances limit in /etc/media_codecs.xml:
+<MediaCodec name="OMX.<em><vendor></em>.video.encoder.mpeg4" type="video/mp4v-es" >
+ <Limit name="concurrent-instances" max="13" />
+</MediaCodec>
+<MediaCodec name="OMX.<em><vendor></em>.video.encoder.h263" type="video/3gpp" >
+ <Limit name="concurrent-instances" max="13" />
+</MediaCodec>
+<MediaCodec name="OMX.<em><vendor></em>.video.encoder.avc" type="video/avc" >
+ <Limit name="concurrent-instances" max="13" />
+</MediaCodec>
+<MediaCodec name="OMX.<em><vendor></em>.video.encoder.vp8" type="video/x-vnd.on2.vp8" >
+ <Limit name="concurrent-instances" max="13" />
+</MediaCodec>
+<MediaCodec name="OMX.<em><vendor></em>.video.decoder.avc" type="video/avc" >
+ <Limit name="concurrent-instances" max="13" />
+</MediaCodec>
+<MediaCodec name="OMX.<em><vendor></em>.video.decoder.avc.secure" type="video/avc" >
+ <Limit name="concurrent-instances" max="4" />
+</MediaCodec>
+<MediaCodec name="OMX.<em><vendor></em>.video.decoder.mpeg4" type="video/mp4v-es" >
+ <Limit name="concurrent-instances" max="12" />
+</MediaCodec>
+<MediaCodec name="OMX.<em><vendor></em>.video.decoder.h263" type="video/3gpp" >
+ <Limit name="concurrent-instances" max="12" />
+</MediaCodec>
+<MediaCodec name="OMX.<em><vendor></em>.video.decoder.vp8" type="video/x-vnd.on2.vp8" >
+ <Limit name="concurrent-instances" max="12" />
+</MediaCodec>
+</pre>
+
+ <li>Add the <code>concurrent-instances</code> lines suggested in the test
+failure message to the <code>/etc/media_codecs.xml</code> file.
+
+ <li>Re-run the test to verify its success.
+ </ol>
+
+<h2 id=2_achievable_frame_rates_for_video_codecs>2. Achievable frame rates for video codecs</h2>
+<p>The <code>VideoCapabilities.getAchievableFrameRatesFor</code> interface
+returns the range of achievable video frame rates for a video size. This
+information must be provided by the OEM for each device via an XML file placed at
+<code>/etc/media_codecs_performance.xml</code>. These settings are tested by
+the <code>com.android.cts.videoperf.VideoEncoderDecoderTest</code> and
+<code>android.media.cts.VideoDecoderPerfTest</code> CTS tests.</p>
+
+<p>OEMs can use the CTS tests to generate the XML files that pass the tests. To do this:</p>
+ <ol>
+ <li>Run the tests first using cts-tradefed. Given the
+variability of Android performance, it is recommended the tests are run
+multiple times to get more accurate minimum and maximum values.
+ <li>Use the provided <code>get_achievable_rates.py</code> script to
+generate the XML file.
+ <li>Place the XML file at: <code>/etc/media_codecs_performance.xml</code><br>
+This is usually done by placing the XML file in the device project
+(device/<em><vendor></em>/<em><product></em>) and adding a
+<code>PRODUCT_COPY_FILES</code> line to <code>device.mk</code> like so:
+<pre>
+PRODUCT_COPY_FILES += \
+...
+ device/moto/shamu/media_codecs.xml:system/etc/media_codecs.xml \
++ device/moto/shamu/media_codecs_performance.xml:system/etc/media_codecs_performance.xml
+</pre>
+ <li>Re-run the performance tests to verify their success.
+ </ol>
+
+<h2 id=3_co-exist_of_secure_codec_and_non-secure_codec>3. Co-exist of secure codec and non-secure codec</h2>
+
+<ul>
+ <li>supports-secure-with-non-secure-codec —
+If the instance of secure codec and the instance of non-secure codec can’t
+co-exist at the same time, that should be indicated as global setting in the
+<code>media_codecs.xml</code> file.
+<pre>
+<MediaCodecs>
+ <Settings>
+ <Setting name="supports-secure-with-non-secure-codec" value="false" />
+ </Settings>
+ <Encoders>
+…
+</pre>
+ <li>supports-multiple-secure-codecs —
+If co-exist of multiple secure codec instances is not supported, that should be
+indicated as a global setting in the <code>media_codecs.xml</code> file.
+<pre>
+<MediaCodecs>
+ <Settings>
+ <Setting name="supports-multiple-secure-codecs" value="false" />
+ </Settings>
+ <Encoders>
+…
+</pre>
+ <li>Note that the both settings are true by default, meaning if they are supported,
+there’s no need to add the setting line to the <code>media_codecs.xml</code>.
+ <li>The <code>ResourceManagerTest</code> CTS tests may fail if these two settings were not set
+properly.
+</ul>
diff --git a/src/devices/media/soc.jd b/src/devices/media/soc.jd
new file mode 100644
index 0000000..e42a2af
--- /dev/null
+++ b/src/devices/media/soc.jd
@@ -0,0 +1,74 @@
+page.title=SoC Vendor Dependencies for Media Resource Manager
+@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>This document is intended to help system on chip vendors (SoCs) properly
+implement support for priority, operating rate and the hooks needed for Android
+media resource manager.</p>
+
+<h2 id=1_omx_errorinsufficientresources>1. OMX_ErrorInsufficientResources</h2>
+
+<p>The codec component should return
+<code>OMX_ErrorInsufficientResources</code> on <code>GetHandle</code>,
+<code>Init</code>, <code>UseBuffer</code>, <code>AllocateBuffer</code> or a
+state transition if the failure is due to insufficient resource. The error code
+will be used by the media resource manager as the indicator to potentially
+preempt media resource from other lower priority process.</p>
+
+<p>An Android Compatibility Test Suite (CTS) test exists to allocate, configure
+and start each codec repeatedly until <code>catching
+OMX_ErrorInsufficientResources</code> (pass) or any other error (fail).</p>
+
+<h2 id=2_omx_indexconfigpriority>2. OMX_IndexConfigPriority</h2>
+
+<p>This configuration lets the application describe desired codec priority.</p>
+
+<p>The associated value is an integer. Higher value means lower priority.
+Currently, only two levels are supported:</p>
+
+<ul>
+ <li>0: realtime priority - meaning that the codec shall support the given
+performance configuration (e.g. framerate) at realtime. This will only be used
+by media playback, capture, and possibly by realtime communication scenarios if
+best effort performance is not suitable.</li>
+ <li>1: non-realtime priority (best effort). This is the default value.</li>
+</ul>
+
+<p>Vendor is suggested to use this as a hint used at codec configuration and
+resource planning - to understand the realtime requirements of the application.</p>
+
+<p>Don’t assume realtime priority unless it is configured to 0.</p>
+
+<h2 id=3_omx_indexconfigoperatingrate>3. OMX_IndexConfigOperatingRate</h2>
+
+<p>This configuration lets the application describe operating frame rate for
+video or sample rate for audio at which the codec will need to operate.</p>
+
+<p>This is used for cases like high-speed/slow-motion video capture, where the
+video encoder format contains the target playback rate (e.g. 30fps), but the
+component must be able to handle the high operating capture rate (e.g. 240fps).</p>
+
+<p>This rate should be used for resource planning and setting the operating
+points.</p>
diff --git a/src/devices/storage/adoptable.jd b/src/devices/storage/adoptable.jd
new file mode 100644
index 0000000..899db9b
--- /dev/null
+++ b/src/devices/storage/adoptable.jd
@@ -0,0 +1,98 @@
+page.title=Adoptable Storage
+@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 has always supported external storage accessories (such as SD cards), but
+these accessories were historically limited to simple file storage, due to
+their expected impermanence and the minimal data protection offered to
+<a href="{@docRoot}devices/storage/traditional.html">traditional external storage</a>.
+Android 6.0 introduces the ability to
+<a href="https://developer.android.com/preview/behavior-changes.html#behavior-adoptable-storage">adopt</a>
+external storage media to act like internal storage.</p>
+
+<p>When external storage media is adopted, it’s formatted and encrypted to only
+work with a single Android device at a time. Because the media is strongly tied
+to the Android device that adopted it, it can safely store both apps and
+private data for all users.</p>
+
+<p>When users insert new storage media (such as an SD card) in an adoptable
+location, Android asks them how they want to use the media. They can choose to
+adopt the media, which formats and encrypts it, or they can continue using it
+as-is for simple file storage. If they choose to adopt, the platform offers to
+migrate the primary shared storage contents (typically mounted at <code>/sdcard</code>)
+to the newly adopted media, freeing up valuable space on internal storage.</p>
+
+<p>Apps can be placed on adopted storage media only when the developer has
+indicated support through the <code>android:installLocation</code> attribute.
+New installs of supported apps are automatically placed on the
+storage device with the most free space, and users can move supported apps
+between storage devices in the <em>Settings</em> app. Apps moved to adopted
+media are remembered while the media is ejected,
+and return when the media is reinserted.</p>
+
+<h2 id=security>Security</h2>
+
+
+<p>The platform randomly generates an encryption key for each adopted device,
+and that key is stored on the internal storage of the Android device. This
+effectively makes the adopted media as secure as internal storage. Keys are
+associated with adopted devices based on the adopted partition GUID. The
+adopted device is encrypted using <code>dm-crypt</code> configured with the
+<code>aes-cbc-essiv:sha256</code> algorithm and a 128-bit key size.</p>
+
+<p>The on-disk layout of the adopted device closely mirrors the internal data
+partition, including SELinux labels, etc. When multi-user is supported on the
+Android device, the adopted storage device also supports multi-user with the
+same level of isolation as internal storage.</p>
+
+<p>Because the contents of an adopted storage device are strongly tied to the
+Android device that adopted it, the encryption keys should not be extractable
+from the parent device, and therefore the storage device can't be mounted elsewhere.</p>
+
+<h2 id=performance_and_stability>Performance and stability</h2>
+
+
+<p>Only external storage media in stable locations, such as a slot inside a
+battery compartment or behind a protective cover, should be considered for
+adoption to help avoid accidental data loss or corruption. In particular, USB
+devices connected to a phone or tablet should never be considered for adoption.
+One common exception would be an external USB drive connected to a TV-style
+device, because the entire TV is typically installed in a stable location.</p>
+
+<p>When a user adopts a new storage device, the platform runs a benchmark and
+compares its performance against internal storage. If the adopted device is
+significantly slower than internal storage, the platform warns the user about a
+possibly degraded experience. This benchmark was derived from the actual I/O
+behavior of popular Android apps. Currently, the AOSP implementation will only
+warn users beyond a single threshold, but device manufacturers may adapt this
+further, such as rejecting adoption completely if the card is extremely slow.</p>
+
+<p>Adopted devices must be formatted with a filesystem that supports POSIX
+permissions and extended attributes, such as <code>ext4</code> or <code>f2fs</code>.
+For optimal performance, the <code>f2fs</code> filesystem is recommended for
+flash-based storage devices.</p>
+
+<p>When performing periodic idle maintenance, the platform issues <code>FI_TRIM</code>
+to adopted media just like it does for internal storage. The current SD card
+specification does not support the <code>DISCARD</code> command; but the kernel
+instead falls back to the <code>ERASE</code> command, which SD card firmware
+may choose to use for optimization purposes.</p>
diff --git a/src/devices/storage/config-example.jd b/src/devices/storage/config-example.jd
index fd55db8..91be81b 100644
--- a/src/devices/storage/config-example.jd
+++ b/src/devices/storage/config-example.jd
@@ -1,15 +1,11 @@
-page.title=Typical Configuration Examples
+page.title=Configuration Examples
@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.
@@ -24,40 +20,34 @@
</div>
</div>
-<p>Below are examples of external storage configurations as of Android 4.4
-for various typical devices. Only the relevant portions of the configuration
+<p>Below are examples of external storage configurations
+for various device types. Only the relevant portions of the configuration
files are included.
+<p>Due to configuration changes in Android 6.0 (like the removal of the
+<code>storage_list.xml</code> resource overlay), the configuration examples are
+split into two categories.</p>
-<h2>Physical primary only (like Nexus One)</h2>
-
+<h2 id=android_5_x>Android 5.x and earlier</h2>
+<h3 id=android_5_x_physical>Physical primary only</h3>
<p>This is a typical configuration for a device with single external storage
-device which is a physical SD card.</p>
-
+device which is a physical SD card, like Nexus One.</p>
<p>The raw physical device must first be mounted under
<code>/mnt/media_rw</code> where only the system and FUSE daemon can access
it. <code>vold</code> will then manage the <code>fuse_sdcard0</code> service
when media is inserted/removed.
-
-<h3>fstab.hardware</h3>
-
+<h4>fstab.hardware</h4>
<pre><code>[physical device node] auto vfat defaults voldmanaged=sdcard0:auto,noemulatedsd
</code></pre>
-
-<h3>init.hardware.rc</h3>
-
+<h4>init.hardware.rc</h4>
<pre><code>on init
mkdir /mnt/media_rw/sdcard0 0700 media_rw media_rw
mkdir /storage/sdcard0 0700 root root
-
export EXTERNAL_STORAGE /storage/sdcard0
-
service fuse_sdcard0 /system/bin/sdcard -u 1023 -g 1023 -d /mnt/media_rw/sdcard0 /storage/sdcard0
class late_start
disabled
</code></pre>
-
-<h3>storage_list.xml</h3>
-
+<h4>storage_list.xml</h4>
<pre><code><storage
android:mountPoint="/storage/sdcard0"
android:storageDescription="@string/storage_sd_card"
@@ -65,82 +55,57 @@
android:primary="true"
android:maxFileSize="4096" />
</code></pre>
-
-
-<h2>Emulated primary only (like Nexus 4)</h2>
-
+<h3 id=android_5_x_emulated>Emulated primary only</h3>
<p>This is a typical configuration for a device with single external storage
-device which is backed by internal storage on the device.</p>
-
-<h3>init.hardware.rc</h3>
-
+device which is backed by internal storage on the device, like Nexus 4.</p>
+<h4>init.hardware.rc</h4>
<pre><code>on init
mkdir /mnt/shell/emulated 0700 shell shell
mkdir /storage/emulated 0555 root root
-
export EXTERNAL_STORAGE /storage/emulated/legacy
export EMULATED_STORAGE_SOURCE /mnt/shell/emulated
export EMULATED_STORAGE_TARGET /storage/emulated
-
on fs
setprop ro.crypto.fuse_sdcard true
-
service sdcard /system/bin/sdcard -u 1023 -g 1023 -l /data/media /mnt/shell/emulated
class late_start
</code></pre>
-
-<h3>storage_list.xml</h3>
-
+<h4>storage_list.xml</h4>
<pre><code><storage
android:storageDescription="@string/storage_internal"
android:emulated="true"
android:mtpReserve="100" />
</code></pre>
-
-
-<h2>Emulated primary, physical secondary (like Xoom)</h2>
-
+<h3 id=android_5_x_both>Emulated primary, physical secondary</h3>
<p>This is a typical configuration for a device with multiple external
storage devices, where the primary device is backed by internal storage
-on the device, and where the secondary device is a physical SD card.</p>
-
+on the device, and where the secondary device is a physical SD card, like Xoom.</p>
<p>The raw physical device must first be mounted under
<code>/mnt/media_rw</code> where only the system and FUSE daemon can
access it. <code>vold</code> will then manage the <code>fuse_sdcard1</code>
service when media is inserted/removed.</p>
-
-<h3>fstab.hardware</h3>
-
+<h4>fstab.hardware</h4>
<pre><code>[physical device node] auto vfat defaults voldmanaged=sdcard1:auto
</code></pre>
-
-<h3>init.hardware.rc</h3>
-
+<h4>init.hardware.rc</h4>
<pre><code>on init
mkdir /mnt/shell/emulated 0700 shell shell
mkdir /storage/emulated 0555 root root
-
mkdir /mnt/media_rw/sdcard1 0700 media_rw media_rw
mkdir /storage/sdcard1 0700 root root
-
export EXTERNAL_STORAGE /storage/emulated/legacy
export EMULATED_STORAGE_SOURCE /mnt/shell/emulated
export EMULATED_STORAGE_TARGET /storage/emulated
export SECONDARY_STORAGE /storage/sdcard1
-
on fs
setprop ro.crypto.fuse_sdcard true
-
service sdcard /system/bin/sdcard -u 1023 -g 1023 -l /data/media /mnt/shell/emulated
class late_start
-
service fuse_sdcard1 /system/bin/sdcard -u 1023 -g 1023 -w 1023 -d /mnt/media_rw/sdcard1 /storage/sdcard1
class late_start
disabled
</code></pre>
-
-<h3>storage_list.xml</h3>
-
+<h4>storage_list.xml</h4>
<pre><code><storage
android:storageDescription="@string/storage_internal"
android:emulated="true"
@@ -151,3 +116,43 @@
android:removable="true"
android:maxFileSize="4096" />
</code></pre>
+
+<h2 id=android_6>Android 6.0</h2>
+<h3 id=android_6_physical>Physical primary only</h3>
+<p>This is a typical configuration for a device with single external storage
+device which is a physical SD card, like the original Android One. There is no
+secondary shared storage and the device cannot support multi-user.</p>
+<h4>fstab.device</h4>
+<pre><code>/devices/platform/mtk-msdc.1/mmc_host* auto auto defaults
+voldmanaged=sdcard0:auto,encryptable=userdata,noemulatedsd
+</code></pre>
+<h4>init.device.rc</h4>
+<pre><code>on init
+ # By default, primary storage is physical
+ setprop ro.vold.primary_physical 1
+ </code></pre>
+<h3 id=android_6_emulated> Emulated primary only</h3>
+<p>This is a typical configuration for a device with single external storage
+device which is backed by internal storage on the device, like Nexus 6.</p>
+<ul>
+ <li>Primary shared storage (<code>/sdcard</code>) is emulated on top of internal storage.
+ <li>No secondary SD card storage.
+ <li>USB OTG storage devices supported.
+ <li>Supports multi-user.
+</ul>
+<h4>fstab.device</h4>
+<pre><code>/devices/*/xhci-hcd.0.auto/usb* auto auto defaults
+ voldmanaged=usb:auto</code></pre>
+<h3 id=android_6_both>Emulated primary, physical secondary</h3>
+<p>This is a typical configuration for a device with multiple external storage
+devices, where the primary device is backed by internal storage on the device,
+and where the secondary device is a physical SD card, like Xoom.</p>
+<ul>
+ <li>Primary shared storage (<code>/sdcard</code>) is emulated on top of internal storage.
+ <li>Secondary storage is a physical SD card slot that can be adopted.
+ <li>Supports multi-user.
+</ul>
+<h4>fstab.device</h4>
+<pre><code>/devices/platform/mtk-msdc.1/mmc_host* auto auto defaults
+voldmanaged=sdcard1:auto,encryptable=userdata
+</code></pre>
diff --git a/src/devices/storage/config.jd b/src/devices/storage/config.jd
index b8e4e4f..6db706c 100644
--- a/src/devices/storage/config.jd
+++ b/src/devices/storage/config.jd
@@ -1,34 +1,36 @@
-page.title=Device Specific Configuration
+page.title=Device Configuration
@jd:body
-
<!--
- Copyright 2013 The Android Open Source Project
-
+ 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>External storage is managed by a combination of the <code>vold</code> init
-service and <code>MountService</code> system servic. Mounting of physical
+service and <code>MountService</code> system service. Mounting of physical
external storage volumes is handled by <code>vold</code>, which performs
staging operations to prepare the media before exposing it to apps.</p>
+<h2 id=file_mappings>File mappings</h2>
<p>For Android 4.2.2 and earlier, the device-specific <code>vold.fstab</code>
configuration file defines mappings from sysfs devices to filesystem mount
points, and each line follows this format:</p>
-
<pre><code>dev_mount <label> <mount_point> <partition> <sysfs_path> [flags]
</code></pre>
-
<ul>
<li><code>label</code>: Label for the volume.</li>
<li><code>mount_point</code>: Filesystem path where the volume should be mounted.</li>
@@ -38,7 +40,6 @@
<li><code>flags</code>: Optional comma separated list of flags, must not contain <code>/</code>.
Possible values include <code>nonremovable</code> and <code>encryptable</code>.</li>
</ul>
-
<p>For Android releases 4.3 and later, the various fstab files used by init, vold and
recovery were unified in the <code>/fstab.<device></code> file. For external
storage volumes that are managed by <code>vold</code>, the entries should have the
@@ -58,10 +59,18 @@
be followed by a label describing the card, and a partition number or the word
<code>auto</code>. Here is an example: <code>voldmanaged=sdcard:auto</code>.
Other possible flags are <code>nonremovable</code>,
-<code>encryptable=sdcard</code>, and <code>noemulatedsd</code>.</li>
+<code>encryptable=sdcard</code>, <code>noemulatedsd</code>, and <code>encryptable=userdata</code>.</li>
</ul>
+
+<h2 id=configuration_details>Configuration details</h2>
<p>External storage interactions at and above the framework level are handled
-through <code>MountService</code>. The device-specific <code>storage_list.xml</code> configuration
+through <code>MountService</code>.
+Due to configuration changes in Android 6.0 (like the
+removal of the storage_list.xml resource overlay), the configuration details
+are split into two categories.
+
+<h3 id=android_5_x_and_earlier>Android 5.x and earlier</h3>
+The device-specific <code>storage_list.xml</code> configuration
file, typically provided through a <code>frameworks/base</code> overlay, defines the
attributes and constraints of storage devices. The <code><StorageList></code> element
contains one or more <code><storage></code> elements, exactly one of which should be marked
@@ -94,3 +103,46 @@
storage. The <code>/sdcard</code> path must also resolve to the same location, possibly
through a symlink. If a device adjusts the location of external storage between
platform updates, symlinks should be created so that old paths continue working.</p>
+
+<h3 id=android_6_0>Android 6.0</h3>
+<p>Configuration of the storage subsystem is now concentrated in the
+device-specific <code>fstab</code> file, and several historical static configuration files/variables have been
+removed to support more dynamic behavior:</p>
+<ul>
+ <li>The <code>storage_list.xml</code> resource overlay has been removed and is no longer used by the framework.
+Storage devices are now configured dynamically when detected by <code>vold</code>.
+ <li>The <code>EMULATED_STORAGE_SOURCE/TARGET</code> environment variables have been removed and are no longer used by Zygote to
+configure user-specific mount points. Instead, user separation is now enforced
+with user-specific GIDs, and primary shared storage is mounted into place by <code>vold</code> at runtime.
+ <ul>
+ <li>Developers may continue to build paths dynamically or statically depending on
+their use case. Including the UUID in the path identifies each card to make
+location clearer for developers. (For example, <code>/storage/ABCD-1234/report.txt</code> is clearly a different file than <code>/storage/DCBA-4321/report.txt</code>.)
+ </ul>
+ <li>The hard-coded FUSE services have been removed from device-specific <code>init.rc</code> files and are instead forked dynamically from <code>vold</code> when needed.
+</ul>
+<p>In addition to these configuration changes, Android 6.0 includes the notion of
+adoptable storage. For Android 6.0 devices, any physical media that is not
+adopted is viewed as portable. </p>
+
+<h4 id=adoptable_storage>Adoptable storage </h4>
+<p>To indicate an adoptable storage device in the <code>fstab</code>, use the <code>encryptable=userdata</code> attribute in the <code>fs_mgr_flags</code> field. Here’s a typical definition:</p>
+<pre><code>/devices/platform/mtk-msdc.1/mmc_host* auto auto defaults
+voldmanaged=sdcard1:auto,encryptable=userdata
+</code></pre>
+<p>When a storage device is adopted, the platform erases the contents and writes a
+GUID partition table that defines two partitions:</p>
+<ul>
+ <li>a small empty <code>android_meta</code> partition that is reserved for future use. The partition type GUID is
+19A710A2-B3CA-11E4-B026-10604B889DCF.
+ <li>a large <code>android_ext</code> partition that is encrypted using dm-crypt and formatted using either <code>ext4</code> or <code>f2fs</code> depending on the kernel capabilities. The partition type GUID is
+193D1EA4-B3CA-11E4-B075-10604B889DCF.
+</ul>
+<h4 id=portable_storage>Portable storage </h4>
+<p>In the <code>fstab</code>, storage devices with the <code>voldmanaged</code> attribute are considered to be portable by default unless another attribute
+like <code>encryptable=userdata</code> is defined. For example, here’s a typical definition for USB OTG devices:</p>
+<pre><code>/devices/*/xhci-hcd.0.auto/usb* auto auto defaults
+ voldmanaged=usb:auto
+</code></pre>
+<p>The platform uses <code>blkid</code> to detect filesystem types before mounting, and users can choose to format the
+media when the filesystem is unsupported.</p>
diff --git a/src/devices/storage/index.jd b/src/devices/storage/index.jd
index 43ee949..7e62fe6 100644
--- a/src/devices/storage/index.jd
+++ b/src/devices/storage/index.jd
@@ -1,15 +1,11 @@
page.title=Storage
@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.
@@ -25,19 +21,25 @@
</div>
<img style="float: right; margin: 0px 15px 15px 15px;" src="images/ape_fwk_hal_extstor.png" alt="Android external storage HAL icon"/>
+<p>Android has evolved over time to support a wide variety of storage device types
+and features. All versions of Android support devices with <a href="{@docRoot}devices/storage/traditional.html">traditional storage</a>,
+which includes portable and emulated storage. <em>Portable</em> storage can be provided by physical media, like an SD card or USB, that is for
+temporary data transfer/ file storage. The physical media may remain with the
+device for an extended period of time, but is not tied to the device and may be
+removed. SD cards have been available as portable storage since Android 1.0;
+Android 6.0 added USB support. <em>Emulated</em> storage is provided by exposing a portion of internal storage through an
+emulation layer and has been available since Android 3.0.</p>
-<p>Android supports devices with external storage, which is defined to be a
-case-insensitive filesystem with immutable POSIX permission classes and
-modes. External storage can be provided by physical media (such as an SD
-card), or by exposing a portion of internal storage through an emulation
-layer. Devices may contain multiple instances of external storage.</p>
+<p>Starting in Android 6.0, Android supports <a href="{@docRoot}devices/storage/adoptable.html"><em>adoptable</em> storage</a>, which is provided by physical media, like an SD card or USB, that is
+encrypted and formatted to behave like internal storage. Adoptable storage can
+store all types of application data. </p>
+<h2 id=permissions>Permissions</h2>
<p>Access to external storage is protected by various Android
permissions. Starting in Android 1.0, write access is protected with the
<code>WRITE_EXTERNAL_STORAGE</code> permission. Starting in Android 4.1,
read access is protected with the <code>READ_EXTERNAL_STORAGE</code>
permission.</p>
-
<p>Starting in Android 4.4, the owner, group and modes of files on external
storage devices are now synthesized based on directory structure. This
enables apps to manage their package-specific directories on external
@@ -48,65 +50,29 @@
no permissions. These synthesized permissions are accomplished by wrapping
raw storage devices in a FUSE daemon.</p>
-<p>Since external storage offers minimal protection for stored data, system
-code should not store sensitive data on external storage. Specifically,
-configuration and log files should only be stored on internal storage where
-they can be effectively protected.</p>
+<h3 id=runtime_permissions>Runtime permissions</h3>
-<h2 id="multiple-external-storage-devices">Multiple external storage devices</h2>
-
-<p>Starting in Android 4.4, multiple external storage devices are surfaced
-to developers through <code>Context.getExternalFilesDirs()</code>,
-<code>Context.getExternalCacheDirs()</code>, and
-<code>Context.getObbDirs()</code>.</p>
-
-</p>External storage devices surfaced through these APIs must be a
-semi-permanent part of the device (such as an SD card slot in a battery
-compartment). Developers expect data stored in these locations to be
-available over long periods of time. For this reason, transient storage
-devices (such as USB mass storage drives) should not be surfaced through
-these APIs.</p>
-
-<p>The <code>WRITE_EXTERNAL_STORAGE</code> permission must only grant write
-access to the primary external storage on a device. Apps must not be
-allowed to write to secondary external storage devices, except in their
-package-specific directories as allowed by synthesized
-permissions. Restricting writes in this way ensures the system can clean
-up files when applications are uninstalled.</p>
-
-
-<h2 id="multi-user-external-storage">Multi-user external storage</h2>
-
-<p>Starting in Android 4.2, devices can support multiple users, and external
-storage must meet the following constraints:</p>
+<p>Android 6.0 introduces a new <a href="{@docRoot}devices/tech/config/runtime_perms.html">runtime permissions</a> model where apps request
+capabilities when needed at runtime. Because the new model includes the <code>READ/WRITE_EXTERNAL_STORAGE</code> permissions, the platform needs to dynamically grant storage access without
+killing or restarting already-running apps. It does this by maintaining three
+distinct views of all mounted storage devices:</p>
<ul>
-<li>Each user must have their own isolated primary external storage, and
-must not have access to the primary external storage of other users.</li>
-<li>The <code>/sdcard</code> path must resolve to the correct user-specific
-primary external storage based on the user a process is running as.</li>
-<li>Storage for large OBB files in the <code>Android/obb</code> directory
-may be shared between multiple users as an optimization.</li>
-<li>Secondary external storage must not be writable by apps, except in
-package-specific directories as allowed by synthesized permissions.</li>
+ <li><code>/mnt/runtime/default</code> is shown to apps with no special storage permissions, and to the root
+namespace where <code>adbd</code> and other system components live.
+ <li><code>/mnt/runtime/read</code> is shown to apps with <code>READ_EXTERNAL_STORAGE</code>
+ <li><code>/mnt/runtime/write</code> is shown to apps with <code>WRITE_EXTERNAL_STORAGE</code>
</ul>
-<p>The default platform implementation of this feature leverages Linux kernel
-namespaces to create isolated mount tables for each Zygote-forked process,
-and then uses bind mounts to offer the correct user-specific primary external
-storage into that private namespace.</p>
+<p>At Zygote fork time, we create a mount namespace for each running app and bind
+mount the appropriate initial view into place. Later, when runtime permissions
+are granted, <code>vold</code> jumps into the mount namespace of already-running apps and bind mounts the
+upgraded view into place. Note that permission downgrades always result in the
+app being killed.</p>
-<p>At boot, the system mounts a single emulated external storage FUSE daemon
-at <code>EMULATED_STORAGE_SOURCE</code>, which is hidden from apps. After
-the Zygote forks, it bind mounts the appropriate user-specific subdirectory
-from under the FUSE daemon to <code>EMULATED_STORAGE_TARGET</code> so that
-external storage paths resolve correctly for the app. Because an app lacks
-accessible mount points for other users' storage, they can only access
-storage for the user it was started as.</p>
+<p>The <code>setns()</code> functionality used to implement this feature requires at least Linux 3.8, but
+patches have been backported successfully to Linux 3.4. The <code>PermissionsHostTest</code> CTS test can be used to verify correct kernel behavior.</p>
-<p>This implementation also uses the shared subtree kernel feature to
-propagate mount events from the default root namespace into app namespaces,
-which ensures that features like ASEC containers and OBB mounting continue
-working correctly. It does this by mounting the rootfs as shared, and then
-remounting it as slave after each Zygote namespace is created.</p>
+<p>In Android 6.0, third-party apps don’t have access to the <code>sdcard_r</code> and <code>sdcard_rw</code> GIDs. Instead, access is controlled by mounting only the appropriate runtime
+view in place for that app. Cross-user interactions are blocked using the <code>everybody</code> GID.</p>
diff --git a/src/devices/storage/traditional.jd b/src/devices/storage/traditional.jd
new file mode 100644
index 0000000..c71c644
--- /dev/null
+++ b/src/devices/storage/traditional.jd
@@ -0,0 +1,94 @@
+page.title=Traditional Storage
+@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>
+
+<img style="float: right; margin: 0px 15px 15px 15px;" src="images/ape_fwk_hal_extstor.png" alt="Android external storage HAL icon"/>
+
+<p>Android supports devices with traditional storage, which is defined to be a
+case-insensitive filesystem with immutable POSIX permission classes and modes.
+The notion of traditional storage encompasses emulated and portable storage.
+Portable storage is defined as any external storage that is not <a href="{@docRoot}devices/storage/adoptable.html">
+adopted</a> by the
+system and therefore not formatted and encrypted or tied to a specific device.
+Because traditional external storage offers minimal protection for stored data,
+system code should not store sensitive data on external storage. Specifically,
+configuration and log files should only be stored on internal storage where
+they can be effectively protected.</p>
+
+<h2 id="multi-user-external-storage">Multi-user external storage</h2>
+<p>Starting in Android 4.2, devices can support multiple users, and external
+storage must meet the following constraints:</p>
+<ul>
+<li>Each user must have their own isolated primary external storage, and
+must not have access to the primary external storage of other users.</li>
+<li>The <code>/sdcard</code> path must resolve to the correct user-specific
+primary external storage based on the user a process is running as.</li>
+<li>Storage for large OBB files in the <code>Android/obb</code> directory
+may be shared between multiple users as an optimization.</li>
+<li>Secondary external storage must not be writable by apps, except in
+package-specific directories as allowed by synthesized permissions.</li>
+</ul>
+<p>The default platform implementation of this feature leverages Linux kernel
+namespaces to create isolated mount tables for each Zygote-forked process,
+and then uses bind mounts to offer the correct user-specific primary external
+storage into that private namespace.</p>
+<p>At boot, the system mounts a single emulated external storage FUSE daemon
+at <code>EMULATED_STORAGE_SOURCE</code>, which is hidden from apps. After
+the Zygote forks, it bind mounts the appropriate user-specific subdirectory
+from under the FUSE daemon to <code>EMULATED_STORAGE_TARGET</code> so that
+external storage paths resolve correctly for the app. Because an app lacks
+accessible mount points for other users' storage, they can only access
+storage for the user it was started as.</p>
+<p>This implementation also uses the shared subtree kernel feature to
+propagate mount events from the default root namespace into app namespaces,
+which ensures that features like ASEC containers and OBB mounting continue
+working correctly. It does this by mounting the rootfs as shared, and then
+remounting it as slave after each Zygote namespace is created.</p>
+
+<h2 id="multiple-external-storage-devices">Multiple external storage devices</h2>
+<p>Starting in Android 4.4, multiple external storage devices are surfaced
+to developers through <code>Context.getExternalFilesDirs()</code>,
+<code>Context.getExternalCacheDirs()</code>, and
+<code>Context.getObbDirs()</code>.</p>
+</p>External storage devices surfaced through these APIs must be a
+semi-permanent part of the device (such as an SD card slot in a battery
+compartment). Developers expect data stored in these locations to be
+available over long periods of time. For this reason, transient storage
+devices (such as USB mass storage drives) should not be surfaced through
+these APIs.</p>
+<p>The <code>WRITE_EXTERNAL_STORAGE</code> permission must only grant write
+access to the primary external storage on a device. Apps must not be
+allowed to write to secondary external storage devices, except in their
+package-specific directories as allowed by synthesized
+permissions. Restricting writes in this way ensures the system can clean
+up files when applications are uninstalled.</p>
+
+<h2 id=support_usb_media>USB media support</h2>
+
+<p>Android 6.0 supports portable storage devices which are only connected to the
+device for a short period of time, like USB flash drives. When a user inserts a
+new portable device, the platform shows a notification to let them copy or
+manage the contents of that device.</p>
+
+<p>In Android 6.0, any device that is not adopted is considered portable. Because
+portable storage is connected for only a short time, the platform avoids heavy
+operations such as media scanning. Third-party apps must go through the <a href="https://developer.android.com/guide/topics/providers/document-provider.html">Storage Access Framework</a> to interact with files on portable storage; direct access is explicitly
+blocked for privacy and security reasons.</p>
diff --git a/src/devices/tech/config/carrier.jd b/src/devices/tech/config/carrier.jd
new file mode 100644
index 0000000..51261ff
--- /dev/null
+++ b/src/devices/tech/config/carrier.jd
@@ -0,0 +1,236 @@
+page.title=Carrier Configuration
+@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 Marshmallow release introduces a capability for privileged
+applications to provide carrier-specific configuration to the platform. This
+functionality, based on the <a href="uicc.html">UICC carrier privilege
+functionality</a> introduced in Android 5.1 (Lollipop MR1), will allow carrier
+configuration to be moved away from the static configuration overlays and give
+carriers and OEMs the ability to dynamically provide carrier configuration to
+the platform through a defined interface.</p>
+
+<p>A properly signed carrier app can either be preloaded in the system image,
+installed automatically, or manually installed through an app store. The app
+will be queried by the platform to provide configuration for settings
+including:</p>
+
+<ul>
+ <li>Roaming/Non-roaming networks
+ <li>Visual Voicemail
+ <li>SMS/MMS network settings
+ <li>VoLTE/IMS configurations
+</ul>
+
+<p class="note"><strong>Note</strong>: This app must be signed with the
+certificate that has a matching signature to one on the SIM. See the <a
+href="#how_privilege_is_granted_to_a_carrier_app">How is privilege granted to a
+Carrier App</a> section for details.</p>
+
+<p>The determination of what values to return is entirely up to the Carrier App
+and can be dynamic based on detailed information passed to the app via the
+platform. </p>
+
+<p>The key benefits of this approach are:</p>
+
+<ul>
+ <li><strong>Dynamic configuration</strong> - Support for concepts like
+non-MCCMNC derived configuration, for example
+mobile virtual network operators (MVNOs) or customer opt in to extra services
+ <li><strong>Support for devices sold through any channel</strong> - e.g. an
+open market phone can be automatically configured with the right
+settings by downloading an app from an app store.
+ <li><strong>Security</strong> - Privilege to provide this configuration is
+given only to applications signed by the carrier
+ <li><strong>Defined API</strong> - Previously this configuration was stored
+mostly in internal XML overlays within the framework and not through a public
+API. The carrier config API in Android 6.0 is public and well defined.
+</ul>
+
+<h2 id=how_it_works>How it works</h2>
+
+<h3 id=loading_the_config>Loading the config</h3>
+
+<p>The carrier configuration supplied by this feature is a set of key-value pairs
+that change various telephony-related behaviors in the platform.</p>
+
+<p>The set of values for a particular device is determined by querying the
+following components in order:</p>
+
+<ol>
+ <li>The Carrier App (although this is technically optional, it is the recommended
+location for additional configuration beyond what exists in the Android Open
+Source Project - AOSP)
+ <li>The Platform Config App bundled with the system image
+ <li>Default values, hardcoded into the framework (equivalent to the behavior prior
+to M)
+</ol>
+
+<p class="caution"><strong>Important</strong>: If a value for a particular key
+is returned at any stage, the first value found takes precedence over the
+further stages.</p>
+
+<h4 id=the_platform_config_app>The Platform Config App</h4>
+
+<p>A generic Platform Config App is bundled with the system image that can supply
+values for any variables the regular Carrier App does not. The platform config
+app can be found (in M) in: <code>packages/apps/CarrierConfig</code></p>
+
+<p>This app’s purpose is to provide some per-network configuration when a Carrier
+App is not installed, and carriers/OEMs should make only minimal changes to it
+in their own images. Instead carriers should provide the separate Carrier App
+for carrier customization, allowing updates to be distributed via avenues such
+as app stores.</p>
+
+<h4 id=how_privilege_is_granted_to_a_carrier_app>How privilege is granted to a Carrier App</h4>
+
+<p>The Carrier App in question must be signed with the same certificate found on
+the SIM card, as documented in <a href="uicc.html">UICC Carrier Privileges</a>.</p>
+
+<h4 id=what_information_is_passed_to_the_carrier_app>What information is passed to the Carrier App</h4>
+
+<p>The Carrier App is supplied with the following values, enabling it to make a
+dynamic decision as to what values to return:</p>
+
+<ul>
+ <li>MCC
+ <li>MNC
+ <li>SPN
+ <li>IMSI
+ <li>GID1
+ <li>GID2
+</ul>
+
+<h4 id=when_loading_the_carrier_config_occurs>When loading the carrier config occurs</h4>
+
+<p>The building of the list of key value pairs occurs:</p>
+
+<ul>
+ <li>When the SIM is loaded (boot, or SIM hot swap)
+ <li>When the Carrier app manually triggers a reload
+ <li>When the Carrier app gets updated
+</ul>
+
+<p>See the <a
+href="http://developer.android.com/reference/android/service/carrier/CarrierService.html#onLoadConfig(android.service.carrier.CarrierIdentifier)">android.service.carrier.CarrierService#onLoadConfig()</a>
+reference for more details.</p>
+
+<p class="note"><strong>Note</strong>: The platform caches carrier
+configuration bundles and loads from the cache for SIM state changes. This is
+to speed up boot and SIM hot swap. It is assumed that without a package update
+or an explicit <code>notifyConfigChangedForSubId</code>, the config bundle has
+not been modified.</p>
+
+<h3 id=using_the_config>Using the config</h3>
+
+<p>Once the configuration has been built, the values contained within it are used
+to set various values of system configuration, including:</p>
+
+<ul>
+ <li>Internal framework telephony settings
+ <li>SDK-returned configuration values, e.g. in SmsManager
+ <li>App settings like VVM connection values in the Dialer
+</ul>
+
+<h3 id=configuration_keys>Configuration keys</h3>
+
+<p>The list of keys is defined as part of the public SDK in <code><a
+href="http://developer.android.com/reference/android/telephony/CarrierConfigManager.html">android.telephony.CarrierConfigManager</a></code>
+and cannot change within the same API level. See the table below for a summary of keys.</p>
+
+<h2 id=how_to_build_your_application>How to build your application</h2>
+
+<h3 id=create_your_application>Create your application</h3>
+
+<p>Your application must target the Android 6.0 API level (23).</p>
+
+<h3 id=declare_a_class_that_overrides_android_service_carrier_carrierservice>Declare a class that overrides android.service.carrier.CarrierService</h3>
+
+<ol>
+ <li>Override <code>onLoadConfig</code> to return the values you wish to
+supply based on the <code>service.carrier.CarrierIdentifier</code> object
+passed.
+ <li>Add logic to call <code>notifyConfigChangedForSubId</code> in scenarios
+where carrier configuration may change over time (e.g. when the
+user adds extra services to their account)
+</ol>
+
+<p>An example is below:</p>
+
+<pre>
+public class SampleCarrierConfigService extends CarrierService {
+
+ private static final String TAG = "SampleCarrierConfigService";
+
+ public SampleCarrierConfigService() {
+ Log.d(TAG, "Service created");
+ }
+
+ @Override
+ public PersistableBundle onLoadConfig(CarrierIdentifier id) {
+ Log.d(TAG, "Config being fetched");
+ PersistableBundle config = new PersistableBundle();
+ config.putBoolean(
+ CarrierConfigManager.KEY_CARRIER_VOLTE_AVAILABLE_BOOL, true);
+ config.putBoolean(
+ CarrierConfigManager.KEY_CARRIER_VOLTE_TTY_SUPPORTED_BOOL, false);
+ config.putInt(CarrierConfigManager.KEY_VOLTE_REPLACEMENT_RAT_INT, 6);
+ // Check CarrierIdentifier and add more config if needed…
+ return config;
+ }
+}
+</pre>
+
+
+<p>Please see the <a
+href="https://developer.android.com/reference/android/service/carrier/CarrierService.html">android.service.carrier.CarrierService</a> reference on developer.android.com for more details.</p>
+
+<h3 id=name_the_class_in_your_manifest>Name the class in your manifest</h3>
+
+<p>An example is below:</p>
+
+<pre>
+<service android:name=".SampleCarrierConfigService"
+android:label="@string/service_name"
+android:permission="android.permission.BIND_CARRIER_SERVICES">
+ <intent-filter>
+ <action android:name="android.service.carrier.ConfigService"/></intent-filter>
+</service>
+</pre>
+
+<h3 id=sign_app_with_same_certificate_on_sim>Sign app with same certificate on SIM</h3>
+
+<p>See <a href="uicc.html">UICC Carrier Privileges</a> for the requirements.</p>
+
+<h2 id=testing_your_application>Testing your application</h2>
+
+<p>Once you have built your configuration application, you can test your code
+with:</p>
+
+<ul>
+ <li>A SIM containing a valid certificate signature
+ <li>A device running Android 6.0 and later, for example a Nexus device
+</ul>
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/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/voicemail.jd b/src/devices/tech/config/voicemail.jd
new file mode 100644
index 0000000..2d88828
--- /dev/null
+++ b/src/devices/tech/config/voicemail.jd
@@ -0,0 +1,185 @@
+page.title=Visual Voicemail
+@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 6.0 (Marshmallow) brings an implementation of Visual Voicemail (VVM)
+support integrated into the Dialer, allowing compatible Carrier VVM services to
+hook into the Dialer with minimal configuration. Visual voicemail lets users
+easily check voicemail without making any phone calls. Users can view a list of
+messages in an inbox-like interface, listen to them in any order, and can
+delete them as desired.</p>
+
+<p>This article gives an overview of what is provided, how carriers can integrate
+with it, and some details of the implementation.</p>
+
+<h2 id=visual_voicemail_vvm_client>Visual Voicemail (VVM) client</h2>
+
+<p>Android 6.0 includes a OMTP VVM client, which (when provided with the correct
+configuration) will connect to Carrier VVM servers and populate Visual
+Voicemail messages within the AOSP Dialer. The VVM client:</p>
+
+<ul>
+ <li>Handles the SMS messages used to activate/deactivate/query status of the
+service and the SMS messages used to notify the device of events in the
+subscriber’s mailbox
+ <li>Syncs the mailbox with the IMAP server
+ <li>Downloads the voicemails when the user chooses to listen to them
+ <li>Integrates into the Dialer for user functionality such as calling back, viewing
+unread messages, deleting messages, etc.
+</ul>
+
+<h2 id=integrate_with_the_vvm_client>Integrate with the VVM client</h2>
+
+<h3 id=implementation>Implementation</h3>
+
+<p>The Carrier must provide a Visual Voicemail server implementing the <a href="http://www.gsma.com/newsroom/wp-content/uploads/2012/07/OMTP_VVM_Specification_1_3.pdf">OMTP VVM specifications</a>. The current implementation of the Google VVM client supports the core
+features (read/delete voicemails, download/sync/listen) but the additional TUI
+features (password change, voicemail greeting, languages) are not implemented.
+At this time, we only support OMTP version 1.1 and do not use encryption for
+IMAP authentication. </p>
+
+<p><strong>Note</strong> that server-originated SMS messages to the device (e.g. STATUS or SYNC) must
+not be class 0 messages.</p>
+
+<h3 id=configuration>Configuration</h3>
+
+<p>In order for a carrier to integrate with the VVM service, the carrier must
+provide configuration details to the platform that the OMTP client can use.
+These parameters are:</p>
+
+<ul>
+ <li>Destination number and port number for SMS
+ <li>Authentication security type for IMAP (SSL, TLS, none, etc.)
+ <li>The package name of the carrier-provided Visual Voicemail app (if one is
+provided), so that the platform implementation can be disabled if that package
+is installed
+</ul>
+
+<p>These values are provided through the <a href="https://developer.android.com/reference/android/telephony/CarrierConfigManager.html">Carrier Config API</a>. This functionality, launched in Android 6.0, allows an application to
+dynamically provide telephony-related configuration to the various platform
+components that need it. In particular the following keys must have values
+defined:</p>
+
+<ul>
+ <li><code>KEY_VVM_DESTINATION_NUMBER_STRING</code>
+ <li><code>KEY_VVM_PORT_NUMBER_INT</code>
+ <li><code>KEY_VVM_TYPE_STRING</code>
+ <li><code>KEY_CARRIER_VVM_PACKAGE_NAME_STRING</code>
+</ul>
+
+<p>Please see the <a href="{@docRoot}devices/tech/config/carrier.html">Carrier Configuration</a> article for more detail.</p>
+
+<h2 id=implementation>Implementation</h2>
+
+<p>The OMTP VVM client is implemented within <code>packages/services/Telephony</code>, in particular within <code>src/com/android/phone/vvm/</code></p>
+
+<h3 id=setup>Setup</h3>
+
+<ol>
+ <li>The VVM client listens for <code>TelephonyIntents#ACTION_SIM_STATE_CHANGED</code> or <code>CarrierConfigManager#ACTION_CARRIER_CONFIG_CHANGED</code>.
+ <li>When a SIM is added that has the right Carrier Config values (<code>KEY_VVM_TYPE_STRING</code> set to <code>TelephonyManager.VVM_TYPE_OMTP</code> or <code>TelephonyManager.VVM_TYPE_CVVM</code>), the VVM client sends an ACTIVATE SMS to the value specified in <code>KEY_VVM_DESTINATION_NUMBER_STRING</code>.
+ <li>The server activates the visual voicemail service and sends the OMTP
+credentials via STATUS sms. When the VVM client receives the STATUS sms, it
+registers the voicemail source and displays the voicemail tab on the device.
+ <li>The OMTP credentials are saved locally and the device begins a full sync, as
+described below.
+</ol>
+
+<h3 id=syncing>Syncing</h3>
+
+<p>There are a variety of ways that the VVM client can sync with the carrier
+server and vice versa.</p>
+
+<ul>
+ <li><strong>Full syncs</strong> occur upon initial download. The VVM client only fetches voicemail metadata
+like date and time, origin number, duration, etc. Full syncs can be triggered
+by a:
+ <ul>
+ <li>new SIM
+ <li>device reboot
+ <li>device coming back in service
+ </ul>
+ <li><strong>Upload sync</strong> happens when a user interacts with a voicemail to read or delete it. Upload
+syncs result in the server changing its data to match the data on the device.
+For example, if the user reads a voicemail, it's marked as read on the server;
+if a user deletes a voicemail, it's deleted on the server.
+ <li><strong>Download sync</strong> occurs when the VVM client receives a "MBU" (mailbox update) SYNC sms from the
+carrier. A SYNC message contains the metadata for a new message so that it can
+be stored in the voicemail content provider.
+</ul>
+
+<h3 id=voicemail_download>Voicemail Download</h3>
+
+<p>When a user presses play to listen to a voicemail, the corresponding audio file
+is downloaded. If the user chooses to listen to the Voicemail, the Dialer can
+broadcast <code>VoicemailContract.ACTION_FETCH_VOICEMAIL</code>, which the voicemail client will receive, initiate the download of the
+content, and update the record in the platform Voicemail content provider.</p>
+
+<h3 id=disabling_vvm>Disabling VVM</h3>
+
+<p>The VVM service can be disabled or deactivated by user interaction, removal of
+a valid SIM, or replacement by a carrier VVM app. <em>Disabled</em> means that the local device no longer displays visual voicemail. <em>Deactivated</em> means that the service is turned off for the subscriber. User interaction can
+deactivate the service, SIM removal temporarily disables the service because
+it's no longer present, and carrier VVM replacement disables the Google
+component of visual voicemail.</p>
+
+<h4 id=user_interaction>User interaction</h4>
+
+<p>The user may manually enable or disable visual voicemail. If a user disables
+visual voicemail, they are also deactivating their service. When they disable
+visual voicemail, a DEACTIVATE sms is sent, the voicemail source is
+unregistered locally, and voicemail tab disappears. If they re-enable visual
+voicemail, their service is reactivated as well.</p>
+
+<h4 id=sim_removal>SIM removal</h4>
+
+<p>If there are changes to the device’s SIM state (<code>ACTION_SIM_STATE_CHANGED</code>) or Carrier Config values (<code>ACTION_CARRIER_CONFIG_CHANGED</code>), and a valid configuration for the given SIM no longer exists, then the
+voicemail source is unregistered locally and the voicemail tab disappears. If
+the SIM is replaced, VVM will be re-enabled.</p>
+
+<h4 id=replaced_by_carrier_vvm>Replaced by carrier VVM</h4>
+
+<p>If the device or the user installs a corresponding carrier visual voicemail app
+and the carrier has opted to disable Google visual voicemail if the carrier
+equivalent is installed, then the Google visual voicemail client will be
+automatically disabled. This is achieved by checking if a package with a name
+matching the <code>KEY_CARRIER_VVM_PACKAGE_NAME_STRING</code> parameter is installed.</p>
+
+<p>The VVM client can still be enabled through user interaction.</p>
+
+<h2 id=testing>Testing</h2>
+
+<p>There is an existing (since Android 4.0) set of CTS tests for the
+VoicemailProvider APIs that allow an app to insert/query/delete voicemails into
+the platform. These are the same APIs that VVM uses to add/delete voicemails so
+that any Dialer app can display them in the UI.</p>
+
+<p>To test your configuration application is passing the OMTP configuration
+correctly you can test your code with:</p>
+
+<ul>
+ <li>A SIM containing a valid certificate signature
+ <li>A device running Android 6.0 with an unmodified version of the AOSP phone framework
+</ul>
diff --git a/src/devices/tech/dalvik/gc-debug.jd b/src/devices/tech/dalvik/gc-debug.jd
new file mode 100644
index 0000000..676d38b
--- /dev/null
+++ b/src/devices/tech/dalvik/gc-debug.jd
@@ -0,0 +1,449 @@
+page.title=Debugging ART Garbage Collection
+@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 id="Contents">In this document</h2>
+ <ol id="auto-toc">
+ </ol>
+</div>
+</div>
+
+<p>This document describes how to debug Android Runtime (ART) Garbage Collection
+(GC) correctness and performance issues. It explains how to use GC verification
+options, identify solutions for GC verification failures, and measure and
+address GC performance problems.</p>
+
+<p>See <a href="index.html">ART and Dalvik</a>, the <a
+href="dex-format.html">Dalvik Executable format</a>, and the remaining pages
+within this <a href="index.html">ART and Dalvik</a> section to work with
+ART. See <a
+href="http://developer.android.com/guide/practices/verifying-apps-art.html">Verifying
+App Behavior on the Android Runtime (ART)</a> for additional help verifying app
+behavior.</p>
+
+<h2 id=art_gc_overview>ART GC overview</h2>
+
+<p>ART, introduced as a developer option in Android 4.4, is the default Android
+runtime for Android 5.0 and beyond. The Dalvik runtime is no longer maintained
+or available and its byte-code format is now used by ART. Please note this
+section merely summarizes ART’s GC. For additional information, see the <a
+href="https://www.google.com/events/io/io14videos/b750c8da-aebe-e311-b297-00155d5066d7">Android
+runtime</a> presentation conducted at Google I/O 2014. </p>
+
+<p>ART has a few different GC plans that consist of running different garbage
+collectors. The default plan is the CMS (concurrent mark sweep) plan, which
+uses mostly sticky CMS and partial CMS. Sticky CMS is ART’s non-moving
+generational garbage collector. It scans only the portion of the heap that was
+modified since the last GC and can reclaim only the objects allocated since the
+last GC. In addition to the CMS plan, ART performs heap compaction when an app
+changes process state to a jank-imperceptible process state (e.g. background or
+cached).</p>
+
+<p>Aside from the new garbage collectors, ART also introduces a new bitmap-based
+memory allocator called RosAlloc (runs of slots allocator). This new allocator
+has sharded locking and outperforms DlMalloc by adding thread local buffers for
+small allocation sizes.</p>
+
+<p>Compared to Dalvik, the ART CMS garbage collection plan has a number of
+improvements:</p>
+
+<ul>
+ <li>The number of pauses is reduced from two to one compared to Dalvik.
+Dalvik’s first pause, which did mostly root marking, is done concurrently in
+ART by getting the threads to mark their own roots, then resume running right away.
+ <li>Similarly to Dalvik, the ART GC also has a pause before the sweeping process.
+The key difference in this area is that some of the Dalvik phases during this
+pause are done concurrently in ART. These phases include
+<code>java.lang.ref.Reference</code> processing, system weak sweeping (e.g. jni
+weak globals, etc.), re-marking non-thread roots, and card pre-cleaning. The
+phases that are still done paused in ART are scanning the dirty cards and
+re-marking the thread roots, which helps reduce the pause time.
+ <li>The last area where the ART GC improves over Dalvik is with increased GC
+throughput enabled by the sticky CMS collector. Unlike normal generational GC,
+sticky CMS is non-moving. Instead of having a dedicated region for young
+objects, young objects are kept in an allocation stack, which is basically an
+array of <code>java.lang.Object</code>. This avoids moving objects required to
+maintain low pauses but has the disadvantage of having longer collections for
+heaps with complex object graphs.
+</ul>
+
+<p>The other main other area where the ART GC is different than Dalvik is the
+introduction of moving garbage collectors. The goal of moving GCs is to
+reduce memory usage of backgrounded apps through heap compaction. Currently,
+the event that triggers heap compaction is ActivityManager process-state
+changes. When an app goes to background, it notifies ART the process state is
+no longer jank “perceptible.” This enables ART do things that cause long
+application thread pauses, such as compaction and monitor deflation. The two
+current moving GCs that are in use are homogeneous space compaction and
+semi-space compaction.</p>
+
+<ul>
+ <li>Semi-space compaction moves objects between two tightly packed bump pointer
+spaces. This moving GC occurs on low-memory devices since it saves slightly
+more memory than homogeneous space compaction. The additional savings come
+mostly from having tightly packed objects, which avoid RosAlloc / DlMalloc
+allocator accounting overhead. Since CMS is still used in the foreground and it
+can’t collect from a bump pointer space, semi space requires another transition
+when the app is foregrounded. This is not ideal since it can cause a noticeable pause.
+ <li>Homogenous space compaction works by copying from one RosAlloc space to another
+RosAlloc space. This helps reduce memory usage by reducing heap fragmentation.
+This is currently the default compaction mode for non-low-memory devices. The
+main advantage that homogeneous space compaction has over semi-space compaction
+is not needing a heap transition when the app goes back to foreground.
+</ul>
+
+<h2 id=gc_verification_and_performance_options>GC verification and performance options</h2>
+
+<p>It is possible to change the GC type if you are an OEM. The process for doing
+this involves modifying system properties through adb. Keep in mind that these
+are only modifiable on non-user or rooted builds.</p>
+
+<h3 id=changing_the_gc_type>Changing the GC type</h3>
+
+<p>There are ways to change the GC plans that ART uses. The main way to change the
+foreground GC plan is by changing the <code>dalvik.vm.gctype</code> property or
+passing in an <code>-Xgc:</code> option. It is possible to pass in multiple GC
+options separated by commas.</p>
+
+<p>In order to derive the entire list of available <code>-Xgc</code> settings,
+it is possible to type <code>adb shell dalvikvm -help</code> to print the
+various runtime command-line options.</p>
+
+<p>Here is one example that changes the GC to semi space and turns on pre-GC heap
+verification:
+<code>adb shell setprop dalvik.vm.gctype SS,preverify</code></p>
+
+<ul>
+ <li><code>CMS</code>, which is also the default value, specifies the
+concurrent mark sweep GC plan. This plan consists of running sticky
+generational CMS, partial CMS, and full CMS. The allocator for this plan is
+RosAlloc for movable objects and DlMalloc for non-movable objects.
+ <li><code>SS</code> specifies the semi space GC plan. This plan has two semi
+spaces for movable objects and a DlMalloc space for non-movable objects. The
+movable object allocator defaults to a shared bump pointer allocator which uses
+atomic operations. However, if the <code>-XX:UseTLAB</code> flag is also passed
+in, the allocator uses thread local bump pointer allocation.
+ <li><code>GSS</code> specifies the generational semi space plan. This plan is
+very similar to the semi-space plan with the exception that older-lived objects
+are promoted into a large RosAlloc space. This has the advantage of needing to
+copy significantly fewer objects for typical use cases.
+</ul>
+
+<h3 id=verifying_the_heap>Verifying the heap</h3>
+
+<p>Heap verification is probably the most useful GC option for debugging
+GC-related errors or heap corruption. Enabling heap verification causes the GC
+to check the correctness of the heap at a few points during the garbage
+collection process. Heap verification shares the same options as the ones that
+change the GC type. If enabled, heap verification verifies the roots and
+ensures that reachable objects reference only other reachable objects. GC
+verification is enabled by passing in the following -<code>Xgc</code> values:</p>
+
+<ul>
+ <li>If enabled, <code>[no]preverify</code> performs heap verification before starting the GC.
+ <li>If enabled, <code>[no]presweepingverify</code> performs heap verification
+before starting the garbage collector sweeping
+process.
+ <li>If enabled, <code>[no]postverify</code> performs heap verification after
+the GC has finished sweeping.
+ <li><code>[no]preverify_rosalloc</code>,
+<code>[no]postsweepingverify_rosalloc</code>,
+<code>[no]postverify_rosalloc</code> are also additional GC options that verify
+only the state of RosAlloc’s internal accounting. The main things verified are
+that magic values match expected constants, and free blocks of memory are all
+registered in the <code>free_page_runs_</code> map.
+</ul>
+
+<h3 id=using_the_tlab_allocator_option>Using the TLAB allocator option</h3>
+
+<p>Currently, the only option that changes the allocator used without affecting
+the active GC type is the TLAB option. This option is not available through
+system properties but can be enabled by passing in -<code>XX:UseTLAB</code> to
+<code>dalvikvm</code>. This option enables faster allocation by having a
+shorter allocation code path. Since this option requires using either the SS or
+GSS GC types, which have rather long pauses, it is not enabled by default.</p>
+
+<h2 id=performance>Performance</h2>
+
+<p>There are two main tools that can be used to measure GC performance. GC timing
+dumps and systrace. The most visual way to measure GC performance problems
+would be to use systrace to determine which GCs are causing long pauses or
+preempting application threads. Although the ART GC is relatively efficient,
+there are still a few ways to get performance problems through excessive
+allocations or bad mutator behavior.</p>
+
+<h3 id=ergonomics>Ergonomics</h3>
+
+<p>Compared to Dalvik, ART has a few key differences regarding GC ergonomics. One
+of the major improvements compared to Dalvik is no longer having GC for alloc
+in cases where we start the concurrent GC later than needed. However, there is
+one downside to this, not blocking on the GC can cause the heap to grow more
+than Dalvik in some circumstances. Fortunately, ART has heap compaction, which
+mitigates this issue by defragmenting the heap when the process changes to a
+background process state.</p>
+
+<p>The CMS GC ergonomics have two types of GCs that are regularly run. Ideally,
+the GC ergonomics will run the generational sticky CMS more often than the
+partial CMS. The GC does sticky CMS until the throughput (calculated by bytes
+freed / second of GC duration) of the last GC is less than the mean throughput
+of partial CMS. When this occurs, the ergonomics plan the next concurrent GC to
+be a partial CMS instead of sticky CMS. After the partial CMS completes, the
+ergonomics changes the next GC back to sticky CMS. One key factor that makes
+the ergonomics work is that sticky CMS doesn’t adjust the heap footprint limit
+after it completes. This causes sticky CMS to happen more and more often until
+the throughput is lower than partial CMS, which ends up growing the heap.</p>
+
+<h3 id=using_sigquit_to_obtain_gc_performance_info>Using SIGQUIT to obtain GC performance info</h3>
+
+<p>It is possible to get GC performance timings for apps by sending SIGQUIT to
+already running apps or passing in -<code>XX:DumpGCPerformanceOnShutdown</code>
+to <code>dalvikvm</code> when starting a command line program. When an app gets
+the ANR request signal (SIGQUIT) it dumps information related to its locks,
+thread stacks, and GC performance.</p>
+
+<p>The way to get GC timing dumps is to use:<br>
+<code>$ adb shell kill -S QUIT <pid></code></p>
+
+<p>This creates a <code>traces.txt</code> file in <code>/data/anr/</code>. This
+file contains some ANR dumps as well as GC timings. You can locate the
+GC timings by searching for: “Dumping cumulative Gc timings” These timings will
+show a few things that may be of interest. It will show the histogram info for
+each GC type’s phases and pauses. The pauses are usually more important to look
+at. For example:</p>
+
+<pre>
+sticky concurrent mark sweep paused: Sum: 5.491ms 99% C.I. 1.464ms-2.133ms Avg: 1.830ms Max: 2.133ms
+</pre>
+
+<p><code>This</code> shows that the average pause was 1.83ms. This should be low enough to not
+cause missed frames in most applications and shouldn’t be a concern.</p>
+
+<p>Another area of interest is time to suspend. What time to suspend measures is
+how long it takes a thread to reach a suspend point after the GC requests that
+it suspends. This time is included in the GC pauses, so it is useful to
+determine if long pauses are caused by the GC being slow or the thread
+suspending slowly. Here is an example of what a normal time to suspend
+resembles on a Nexus 5:</p>
+
+<pre>
+suspend all histogram: Sum: 1.513ms 99% C.I. 3us-546.560us Avg: 47.281us Max: 601us
+</pre>
+
+<p>There are also a few other areas of interest, such as total time spent, GC
+throughput, etc. Examples:</p>
+
+<pre>
+Total time spent in GC: 502.251ms
+Mean GC size throughput: 92MB/s
+Mean GC object throughput: 1.54702e+06 objects/s
+</pre>
+
+<p>Here is an example of how to dump the GC timings of an already running app:
+
+<pre>
+$ adb shell kill -s QUIT <pid>
+$ adb pull /data/anr/traces.txt
+</pre>
+
+<p>At this point the GC timings are inside of traces.txt. Here is example output
+from Google maps:</p>
+
+<pre>
+Start Dumping histograms for 34 iterations for sticky concurrent mark sweep
+ScanGrayAllocSpaceObjects: Sum: 196.174ms 99% C.I. 0.011ms-11.615ms Avg: 1.442ms Max: 14.091ms
+FreeList: Sum: 140.457ms 99% C.I. 6us-1676.749us Avg: 128.505us Max: 9886us
+MarkRootsCheckpoint: Sum: 110.687ms 99% C.I. 0.056ms-9.515ms Avg: 1.627ms Max: 10.280ms
+SweepArray: Sum: 78.727ms 99% C.I. 0.121ms-11.780ms Avg: 2.315ms Max: 12.744ms
+ProcessMarkStack: Sum: 77.825ms 99% C.I. 1.323us-9120us Avg: 576.481us Max: 10185us
+(Paused)ScanGrayObjects: Sum: 32.538ms 99% C.I. 286us-3235.500us Avg: 986us Max: 3434us
+AllocSpaceClearCards: Sum: 30.592ms 99% C.I. 10us-2249.999us Avg: 224.941us Max: 4765us
+MarkConcurrentRoots: Sum: 30.245ms 99% C.I. 3us-3017.999us Avg: 444.779us Max: 3774us
+ReMarkRoots: Sum: 13.144ms 99% C.I. 66us-712us Avg: 386.588us Max: 712us
+ScanGrayImageSpaceObjects: Sum: 13.075ms 99% C.I. 29us-2538.999us Avg: 192.279us Max: 3080us
+MarkingPhase: Sum: 9.743ms 99% C.I. 170us-518us Avg: 286.558us Max: 518us
+SweepSystemWeaks: Sum: 8.046ms 99% C.I. 28us-479us Avg: 236.647us Max: 479us
+MarkNonThreadRoots: Sum: 5.215ms 99% C.I. 31us-698.999us Avg: 76.691us Max: 703us
+ImageModUnionClearCards: Sum: 2.708ms 99% C.I. 26us-92us Avg: 39.823us Max: 92us
+ScanGrayZygoteSpaceObjects: Sum: 2.488ms 99% C.I. 19us-250.499us Avg: 37.696us Max: 295us
+ResetStack: Sum: 2.226ms 99% C.I. 24us-449us Avg: 65.470us Max: 452us
+ZygoteModUnionClearCards: Sum: 2.124ms 99% C.I. 18us-233.999us Avg: 32.181us Max: 291us
+FinishPhase: Sum: 1.881ms 99% C.I. 31us-431.999us Avg: 55.323us Max: 466us
+RevokeAllThreadLocalAllocationStacks: Sum: 1.749ms 99% C.I. 8us-349us Avg: 51.441us Max: 377us
+EnqueueFinalizerReferences: Sum: 1.513ms 99% C.I. 3us-201us Avg: 44.500us Max: 201us
+ProcessReferences: Sum: 438us 99% C.I. 3us-212us Avg: 12.882us Max: 212us
+ProcessCards: Sum: 381us 99% C.I. 4us-17us Avg: 5.602us Max: 17us
+PreCleanCards: Sum: 363us 99% C.I. 8us-17us Avg: 10.676us Max: 17us
+ReclaimPhase: Sum: 357us 99% C.I. 7us-91.500us Avg: 10.500us Max: 93us
+(Paused)PausePhase: Sum: 312us 99% C.I. 7us-15us Avg: 9.176us Max: 15us
+SwapBitmaps: Sum: 166us 99% C.I. 4us-8us Avg: 4.882us Max: 8us
+(Paused)ScanGrayAllocSpaceObjects: Sum: 126us 99% C.I. 14us-112us Avg: 63us Max: 112us
+MarkRoots: Sum: 121us 99% C.I. 2us-7us Avg: 3.558us Max: 7us
+(Paused)ScanGrayImageSpaceObjects: Sum: 68us 99% C.I. 68us-68us Avg: 68us Max: 68us
+BindBitmaps: Sum: 50us 99% C.I. 1us-3us Avg: 1.470us Max: 3us
+UnBindBitmaps: Sum: 49us 99% C.I. 1us-3us Avg: 1.441us Max: 3us
+SwapStacks: Sum: 47us 99% C.I. 1us-3us Avg: 1.382us Max: 3us
+RecordFree: Sum: 42us 99% C.I. 1us-3us Avg: 1.235us Max: 3us
+ForwardSoftReferences: Sum: 37us 99% C.I. 1us-2us Avg: 1.121us Max: 2us
+InitializePhase: Sum: 36us 99% C.I. 1us-2us Avg: 1.058us Max: 2us
+FindDefaultSpaceBitmap: Sum: 32us 99% C.I. 250ns-1000ns Avg: 941ns Max: 1000ns
+(Paused)ProcessMarkStack: Sum: 5us 99% C.I. 250ns-3000ns Avg: 147ns Max: 3000ns
+PreSweepingGcVerification: Sum: 0 99% C.I. 0ns-0ns Avg: 0ns Max: 0ns
+Done Dumping histograms
+sticky concurrent mark sweep paused: Sum: 63.268ms 99% C.I. 0.308ms-8.405ms
+Avg: 1.860ms Max: 8.883ms
+sticky concurrent mark sweep total time: 763.787ms mean time: 22.464ms
+sticky concurrent mark sweep freed: 1072342 objects with total size 75MB
+sticky concurrent mark sweep throughput: 1.40543e+06/s / 98MB/s
+Total time spent in GC: 4.805s
+Mean GC size throughput: 18MB/s
+Mean GC object throughput: 330899 objects/s
+Total number of allocations 2015049
+Total bytes allocated 177MB
+Free memory 4MB
+Free memory until GC 4MB
+Free memory until OOME 425MB
+Total memory 90MB
+Max memory 512MB
+Zygote space size 4MB
+Total mutator paused time: 229.566ms
+Total time waiting for GC to complete: 187.655us
+</pre>
+
+<h2 id=tools_for_analyzing_gc_correctness_problems>Tools for analyzing GC correctness problems</h2>
+
+<p>There are various things that can cause crashes inside of ART. Crashes that
+occur reading or writing to object fields may indicate heap corruption. If the
+GC crashes when it is running, it could also point to heap corruption. There
+are various things that can cause heap corruption, the most common cause is
+probably incorrect app code. Fortunately, there are tools to debug GC and
+heap-related crashes. These include the heap verification options specified
+above, valgrind, and CheckJNI.</p>
+
+<h3 id=checkjni>CheckJNI</h3>
+
+<p>Another way to verify app behavior is to use CheckJNI. CheckJNI is a mode that
+adds additional JNI checks; these aren’t enabled by default due to performance
+reasons. The checks will catch a few errors that could cause heap corruption
+such as using invalid/stale local and global references. Here is how to enable
+CheckJNI:</p>
+
+<pre>
+$ adb shell setprop dalvik.vm.checkjni true
+</pre>
+
+<p>Forcecopy mode is another part of CheckJNI that is very useful for detecting
+writes past the end of array regions. When enabled, forcecopy causes the array
+access JNI functions to always return copies with red zones. A <em>red
+zone</em> is a region at the end/start of the returned pointer that has a
+special value, which is verified when the array is released. If the values in
+the red zone don’t match what is expected, this usually means a buffer overrun
+or underrun occurred. This would cause CheckJNI to abort. Here is how to enable
+forcecopy mode:</p>
+
+<pre>
+$ adb shell setprop dalvik.vm.jniopts forcecopy
+</pre>
+
+<p>One example of an error that CheckJNI should catch is writing past the end of
+an array obtained from <code>GetPrimitiveArrayCritical</code>. This operation
+would very likely corrupt the Java heap. If the write is
+within the CheckJNI red zone area, then CheckJNI would catch the issue when the
+corresponding <code>ReleasePrimitiveArrayCritical</code> is called. Otherwise,
+the write will end up corrupting some random object in
+the Java heap and possibly causing a future GC crash. If the corrupted memory
+is a reference field, then the GC may catch the error and print a “<em>Tried to
+mark <ptr> not contained by any spaces</em>” error.</p>
+
+<p>This error occurs when the GC attempts to mark an object for which it can’t
+find a space. After this check fails, the GC traverses the roots and tries to
+see if the invalid object is a root. From here, there are two options: The
+object is a root or a non-root object.</p>
+
+<h3 id=valgrind>Valgrind</h3>
+
+<p>The ART heap supports optional valgrind instrumentation, which provides a
+way to detect reads and writes to and from an invalid heap address. ART detects
+when the app is running under valgrind and inserts red zones before and after
+each object allocation. If there are any reads or writes to these red zones,
+valgrind prints an error. One example of when this could happen is if you read
+or write past the end of an array’s elements while using direct array access
+through JNI. Since the AOT compilers use implicit null checks, it is
+recommended to use eng builds for running valgrind. Another thing to note is
+that valgrind is orders of magnitude slower than normal execution.</p>
+
+<p>Here is an example use:</p>
+
+<pre>
+# build and install
+$ mmm external/valgrind
+$ adb remount && adb sync
+# disable selinux
+$ adb shell setenforce 0
+$ adb shell setprop wrap.com.android.calculator2
+"TMPDIR=/data/data/com.android.calculator2 logwrapper valgrind"
+# push symbols
+$ adb shell mkdir /data/local/symbols
+$ adb push $OUT/symbols /data/local/symbols
+$ adb logcat
+</pre>
+
+
+<h3 id=invalid_root_example>Invalid root example</h3>
+
+<p>In the case where the object is actually an invalid root, it will print some
+useful information:
+<code>art E 5955 5955 art/runtime/gc/collector/mark_sweep.cc:383] Tried to mark 0x2
+not contained by any spaces</code></p>
+
+<pre>
+art E 5955 5955 art/runtime/gc/collector/mark_sweep.cc:384] Attempting see if
+it's a bad root
+art E 5955 5955 art/runtime/gc/collector/mark_sweep.cc:485] Found invalid
+root: 0x2
+art E 5955 5955 art/runtime/gc/collector/mark_sweep.cc:486]
+Type=RootJavaFrame thread_id=1 location=Visiting method 'java.lang.Object
+com.google.gwt.corp.collections.JavaReadableJsArray.get(int)' at dex PC 0x0002
+(native PC 0xf19609d9) vreg=1
+</pre>
+
+<p>In this case, <code>vreg 1</code> inside of
+<code>com.google.gwt.corp.collections.JavaReadableJsArray.get</code> is
+supposed to contain a heap reference but actually contains an invalid pointer
+of address <code>0x2</code>. This is clearly an invalid root. The next step to
+debug this issue would be to use <code>oatdump</code> on the oat file and look
+at the method that has the invalid root. In this case, the error turned out to
+be a compiler bug in the x86 backend. Here is the changelist that fixed it: <a
+href="https://android-review.googlesource.com/#/c/133932/">https://android-review.googlesource.com/#/c/133932/</a></p>
+
+<h3 id=corrupted_object_example>Corrupted object example</h3>
+
+<p>In the case where the object isn’t a root, output similar to the following
+prints:</p>
+
+<pre>
+01-15 12:38:00.196 1217 1238 E art : Attempting see if it's a bad root
+01-15 12:38:00.196 1217 1238 F art :
+art/runtime/gc/collector/mark_sweep.cc:381] Can't mark invalid object
+</pre>
+
+<p>When heap corruption isn’t an invalid root, it is unfortunately hard to debug.
+This error message indicates that there was at least one object in the heap
+that was pointing to the invalid object.</p>
diff --git a/src/devices/tech/ota/device_code.jd b/src/devices/tech/ota/device_code.jd
index 8d23674..0133705 100755
--- a/src/devices/tech/ota/device_code.jd
+++ b/src/devices/tech/ota/device_code.jd
@@ -581,7 +581,7 @@
<p class="img-caption"><strong>Figure 6.</strong> Installing animation frame 1
(icon_installing.png + icon_installing_overlay01.png)
</td>
-<td><img align="center" src="../images/composite01.png" alt="composite image of
+<td><img align="center" src="../images/composite07.png" alt="composite image of
install plus seventh overlay">
<p class="img-caption"><strong>Figure 7.</strong> Installing animation frame 7
(icon_installing.png + icon_installing_overlay07.png)
diff --git a/src/devices/tech/power/batterystats.jd b/src/devices/tech/power/batterystats.jd
index 11b0b48..d42bc33 100644
--- a/src/devices/tech/power/batterystats.jd
+++ b/src/devices/tech/power/batterystats.jd
@@ -42,41 +42,67 @@
<li>App UID aggregated statistics</li>
</ul>
- <p class="note">You can use the <a href=
- "https://github.com/google/battery-historian">Battery Historian</a> tool on
- the output of the dumpsys command to generate an HTML visualization of
- power-related events from the logs. This information makes it easier for
- you to understand and diagnose any battery-related issues.</p>
+ <p>Use the <a href="https://github.com/google/battery-historian">Battery
+ Historian</a> tool on the output of the dumpsys command to generate an HTML
+ visualization of power-related events from the logs. This information makes it
+ easier to understand and diagnose battery-related issues.</p>
- <h2 id="command-line_options">Command line options</h2>
-
- <p>Use the <code>--help</code> option to learn about the various options
- for tailoring the output.</p>
-
- <p>Use the <code>--checkin</code> option to get the results in
- machine-readable csv format.</p>
-
- <p>To print battery usage statistics for a given app package since the
- device was last charged, run this command:</p>
+ <h2 id="command-line_options">Command input</h2>
+ <p>The basic <code>batterystats</code> command is:</p>
<pre class="prettyprint">
-$ adb shell dumpsys batterystats --charged <package-name>
- </pre>
-
- <h2 id="sample_input">Input</h2>
-
- <p>To print battery usage statistics for all apps since the device was last
- charged, in machine-readable format, run this command:</p>
+$ adb shell dumpsys batterystats</pre>
+ <p>Supported options:</p>
+ <ul>
+ <li><code>--help</code> displays additional options for tailoring the output.
+ </li>
+ <li><code>--checkin</code> exports results in machine-readable csv format.
+ </li>
+ </ul>
+ <p>For example, to print battery usage statistics in csv format for all apps
+ since the device was last charged, run the command:</p>
<pre class="prettyprint">
-$ adb shell dumpsys batterystats --charged --checkin
- </pre>
+$ adb shell dumpsys batterystats --charged --checkin</pre>
+ <p>You can also specify a package name to get statistics for a single app. For
+ example, to print battery usage statistics for a given app package
+ since the device was last charged, run the command:</p>
+ <pre class="prettyprint">
+$ adb shell dumpsys batterystats --charged <package-name></pre>
- <h2 id="output">Output</h2>
+ <h2 id="output">Command output</h2>
- <p>The output looks like this:</p>
+ <p>The <code>batterystats</code> command generates aggregated observations
+ about battery use on the device since it was last charged. Observations may be
+ per-UID or system-level; data is selected for inclusion based on its
+ usefulness in analyzing battery performance. Output includes one (1) entry
+ per observation, and each entry consists of a comma-separated list of values
+ in the format:
+ <em>int</em>,<em>uid</em>,<em>mode</em>,<em>section</em>,<em>fields</em>
+ (one or more).</p>
- <p>$ adb shell dumpsys batterystats --charged --checkin</p>
+ <p>The first four values correspond to the following:</p>
- <pre class="no-pretty=print">
+ <ul>
+ <li>Dummy integer</li>
+
+ <li>UID</li>
+
+ <li>Aggregation mode
+
+ <ul>
+ <li>"i" for information not tied to charged/uncharged status.</li>
+ <li>"l" for --charged (usage since last charge).</li>
+ <li>"u" for --unplugged (usage since last unplugged). Deprecated in
+ Android 5.1.1.</li>
+ </ul>
+ </li>
+
+ <li><a href="#interpreting_the_output">Section identifier</a>, which
+ determines how to interpret subsequent values in the line.</li>
+ </ul>
+
+<p>Sample output:</p>
+
+ <pre class="no-pretty-print">
9,0,i,vers,11,116,K,L 9,0,i,uid,1000,android
9,0,i,uid,1000,com.android.providers.settings
9,0,i,uid,1000,com.android.inputdevices
@@ -177,6 +203,8 @@
9,0,l,pwi,idle,8.73 9,0,l,pwi,uid,5.46 9,1000,l,pwi,uid,5.11
9,0,l,pwi,wifi,3.28 9,10019,l,pwi,uid,0.847 9,10069,l,pwi,uid,0.408
9,0,l,pwi,scrn,0.385 9,10034,l,pwi,uid,0.322 9,10025,l,pwi,uid,0.185
+ 9,0,l,pwi,blue,0.0273
+ 9,0,l,pwi,cell,14.0
9,10002,l,pwi,uid,0.180 9,10023,l,pwi,uid,0.168 9,1001,l,pwi,uid,0.0297
9,10068,l,pwi,uid,0.0296 9,10057,l,pwi,uid,0.0234 9,1027,l,pwi,uid,0.0157
9,10079,l,pwi,uid,0.00905 9,10054,l,pwi,uid,0.00527
@@ -227,811 +255,320 @@
9,10068,l,nt,0,0,11929,8383,0,0,50,47,0,0
9,10069,l,nt,0,0,41553,22886,0,0,85,91,0,0</pre>
- <h2 id="interpreting_the_output">Interpreting the output</h2>
+ <h2 id="interpreting_the_output">Section identifiers</h2>
- <p>The sample output is in CSV format. Each line in the output contains
- statistics related to battery usage.</p>
+ <p>Command output for <code>batterystats</code> supports the following
+ sections:</p>
- <p>The first four values in each line correspond to the following:</p>
+ <table id="batterystats-section-ids">
- <ul>
- <li>Dummy integer</li>
-
- <li>UID</li>
-
- <li>Aggregation mode
-
- <ul>
- <li>"l" for --charged, means usage since last charge.</li>
- <li>"u" for --unplugged, which means usage since last unplugged.</li>
- <li>"i" for information that is not
- tied to charged/uncharged status.</li>
- </ul>
- </li>
-
- <li>Section identifier, which determines how to interpret the fifth
- value and the following ones in the line.</li>
- </ul>
-
- <p>Currently, there are 41 sections and the interpretation for each section
- is shown in the following table:</p>
-
- <table>
<tr>
- <td>
- <p><strong>Order</strong></p>
- </td>
-
- <td class="tab0">
- <p><strong>Section Identifier</strong></p>
- </td>
-
- <td class="tab0">
- <p><strong>Description</strong></p>
- </td>
-
- <td class="tab0">
- <p><strong>Remaining Fields</strong></p>
- </td>
+ <th width="10%">Section Identifier</th>
+ <th width="20%">Description</th>
+ <th width="70%">Remaining Fields</th>
</tr>
<tr>
- <td>
- <p>1</p>
- </td>
-
- <td class="tab0">
- <p>vers</p>
- </td>
-
- <td class="tab0">
- <p>Version</p>
- </td>
-
- <td class="tab0">
- <p>checkin version, parcel version, start platform version, end
- platform version</p>
- </td>
+ <td><p>vers</p></td>
+ <td><p>Version</p></td>
+ <td><p>checkin version, parcel version, start platform version, end
+ platform version</p></td>
</tr>
<tr>
- <td>
- <p>2</p>
- </td>
-
- <td class="tab0">
- <p>uid</p>
- </td>
-
- <td class="tab0">
- <p>UID</p>
- </td>
-
- <td class="tab0">
- <p>uid, package name</p>
- </td>
+ <td><p>uid</p></td>
+ <td><p>UID</p></td>
+ <td><p>uid, package name</p></td>
</tr>
<tr>
- <td>
- <p>3</p>
- </td>
-
- <td class="tab0">
- <p>apk</p>
- </td>
-
- <td class="tab0">
- <p>APK</p>
- </td>
-
- <td class="tab0">
- <p>wakeups, APK, service, start time, starts, launches</p>
- </td>
+ <td><p>apk</p></td>
+ <td><p>APK</p></td>
+ <td><p>wakeups, APK, service, start time, starts, launches</p></td>
</tr>
<tr>
- <td>
- <p>4</p>
- </td>
-
- <td class="tab0">
- <p>pr</p>
- </td>
-
- <td class="tab0">
- <p>Process</p>
- </td>
-
- <td class="tab0">
- <p>process, user, system, foreground, starts</p>
- </td>
+ <td><p>pr</p></td>
+ <td><p>Process</p></td>
+ <td><p>process, user, system, foreground, starts</p></td>
</tr>
<tr>
- <td>
- <p>5</p>
- </td>
-
- <td class="tab0">
- <p>sr</p>
- </td>
-
- <td class="tab0">
- <p>Sensor</p>
- </td>
-
- <td class="tab0">
- <p>sensor number, time, count</p>
- </td>
+ <td><p>sr</p></td>
+ <td><p>Sensor</p></td>
+ <td><p>sensor number, time, count</p></td>
</tr>
<tr>
- <td>
- <p>6</p>
- </td>
-
- <td class="tab0">
- <p>vib</p>
- </td>
-
- <td class="tab0">
- <p>Vibrator</p>
- </td>
-
- <td class="tab0">
- <p>time, count</p>
- </td>
+ <td><p>vib</p></td>
+ <td><p>Vibrator</p></td>
+ <td><p>time, count</p></td>
</tr>
<tr>
- <td>
- <p>7</p>
- </td>
-
- <td class="tab0">
- <p>fg</p>
- </td>
-
- <td class="tab0">
- <p>Foreground</p>
- </td>
-
- <td class="tab0">
- <p>time, count</p>
- </td>
+ <td><p>fg</p></td>
+ <td><p>Foreground</p></td>
+ <td><p>time, count</p></td>
</tr>
<tr>
- <td>
- <p>8</p>
- </td>
-
- <td class="tab0">
- <p>st</p>
- </td>
-
- <td class="tab0">
- <p>State Time</p>
- </td>
-
- <td class="tab0">
- <p>foreground, active, running</p>
- </td>
+ <td><p>st</p></td>
+ <td><p>State Time</p></td>
+ <td><p>foreground, active, running</p></td>
</tr>
<tr>
- <td>
- <p>9</p>
- </td>
-
- <td class="tab0">
- <p>wl</p>
- </td>
-
- <td class="tab0">
- <p>Wake lock</p>
- </td>
-
- <td class="tab0">
- <p>wake lock, full time, 'f', full count, partial time, 'p', partial
- count, window time, 'w', window count</p>
- </td>
+ <td><p>wl</p></td>
+ <td><p>Wake lock</p></td>
+ <td><p>wake lock, full time, 'f', full count, partial time, 'p', partial
+ count, window time, 'w', window count</p></td>
</tr>
<tr>
- <td>
- <p>10</p>
- </td>
-
- <td class="tab0">
- <p>sy</p>
- </td>
-
- <td class="tab0">
- <p>Sync</p>
- </td>
-
- <td class="tab0">
- <p>sync, time, count</p>
- </td>
+ <td><p>sy</p></td>
+ <td><p>Sync</p></td>
+ <td><p>sync, time, count</p></td>
</tr>
<tr>
- <td>
- <p>11</p>
- </td>
-
- <td class="tab0">
- <p>jb</p>
- </td>
-
- <td class="tab0">
- <p>Job</p>
- </td>
-
- <td class="tab0">
- <p>job, time, count</p>
- </td>
+ <td><p>jb</p></td>
+ <td><p>Job</p></td>
+ <td><p>job, time, count</p></td>
</tr>
<tr>
- <td>
- <p>12</p>
- </td>
-
- <td class="tab0">
- <p>kwl</p>
- </td>
-
- <td class="tab0">
- <p>Kernel Wake Lock</p>
- </td>
-
- <td class="tab0">
- <p>kernel wake lock, time, count</p>
- </td>
+ <td><p>kwl</p></td>
+ <td><p>Kernel Wake Lock</p></td>
+ <td><p>kernel wake lock, time, count</p></td>
</tr>
<tr>
- <td>
- <p>13</p>
- </td>
-
- <td class="tab0">
- <p>wr</p>
- </td>
-
- <td class="tab0">
- <p>Wakeup Reason</p>
- </td>
-
- <td class="tab0">
- <p>wakeup reason, time, count</p>
- </td>
+ <td><p>wr</p></td>
+ <td><p>Wakeup Reason</p></td>
+ <td><p>wakeup reason, time, count</p></td>
</tr>
<tr>
- <td>
- <p>14</p>
- </td>
-
- <td class="tab0">
- <p>nt</p>
- </td>
-
- <td class="tab0">
- <p>Network</p>
- </td>
-
- <td class="tab0">
- <p>mobile bytes RX, mobile bytes TX, Wi-Fi bytes RX, Wi-Fi bytes TX,
+ <td><p>nt</p></td>
+ <td><p>Network</p></td>
+ <td><p>mobile bytes RX, mobile bytes TX, Wi-Fi bytes RX, Wi-Fi bytes TX,
mobile packets RX, mobile packets TX, Wi-Fi packets RX, Wi-Fi packets
- TX, mobile active time, mobile active count</p>
- </td>
+ TX, mobile active time, mobile active count</p></td>
</tr>
<tr>
- <td>
- <p>15</p>
- </td>
-
- <td class="tab0">
- <p>ua</p>
- </td>
-
- <td class="tab0">
- <p>User Activity</p>
- </td>
-
- <td class="tab0">
- <p>other, button, touch</p>
- </td>
+ <td><p>ua</p></td>
+ <td><p>User Activity</p></td>
+ <td><p>other, button, touch</p></td>
</tr>
<tr>
- <td>
- <p>16</p>
- </td>
-
- <td class="tab0">
- <p>bt</p>
- </td>
-
- <td class="tab0">
- <p>Battery</p>
- </td>
-
- <td class="tab0">
- <p>start count, battery realtime, battery uptime, total realtime,
+ <td><p>bt</p></td>
+ <td><p>Battery</p></td>
+ <td><p>start count, battery realtime, battery uptime, total realtime,
total uptime, start clock time, battery screen off realtime, battery
- screen off uptime</p>
+ screen off uptime</p></td>
+ </tr>
+
+ <tr>
+ <td><p>dc</p></td>
+ <td><p>Battery Discharge</p></td>
+ <td><p>low, high, screen on, screen off</p></td>
+ </tr>
+
+ <tr>
+ <td><p>lv</p></td>
+ <td><p>Battery Level</p></td>
+ <td><p>start level, current level</p></td>
+ </tr>
+
+ <tr>
+ <td><p>wfl</p></td>
+ <td><p>Wi-Fi</p></td>
+ <td><p>full Wi-Fi lock on time, Wi-Fi scan time, Wi-Fi running time, Wi-Fi
+ scan count, Wi-Fi idle time, Wi-Fi receive time, Wi-Fi transmit time</p>
</td>
</tr>
<tr>
- <td>
- <p>17</p>
- </td>
+ <td><p>gwfl</p></td>
+ <td><p>Global Wi-Fi</p></td>
+ <td><p>Wi-Fi on time, Wi-Fi running time, Wi-Fi idle time, Wi-Fi receive
+ time, Wi-Fi transmit time, Wi-Fi power (mAh)</p></td>
+ </tr>
- <td class="tab0">
- <p>dc</p>
- </td>
-
- <td class="tab0">
- <p>Battery Discharge</p>
- </td>
-
- <td class="tab0">
- <p>low, high, screen on, screen off</p>
+ <tr>
+ <td><p>gble</p></td>
+ <td><p>Global Bluetooth</p></td>
+ <td><p>BT idle time, BT receive time, BT transmit time, BT power (mAh)</p>
</td>
</tr>
<tr>
- <td>
- <p>18</p>
- </td>
-
- <td class="tab0">
- <p>lv</p>
- </td>
-
- <td class="tab0">
- <p>Battery Level</p>
- </td>
-
- <td class="tab0">
- <p>start level, current level</p>
- </td>
+ <td><p>m</p></td>
+ <td><p>Misc</p></td>
+ <td><p>screen on time, phone on time, full wakelock time total, partial
+ wakelock time total, mobile radio active time, mobile radio active
+ adjusted time, interactive time, power save mode enabled time,
+ connectivity changes, device idle mode enabled time, device idle mode
+ enabled count, device idling time, device idling count, mobile radio
+ active count, mobile radio active unknown time</p></td>
</tr>
<tr>
- <td>
- <p>19</p>
- </td>
-
- <td class="tab0">
- <p>wfl</p>
- </td>
-
- <td class="tab0">
- <p>Wi-Fi</p>
- </td>
-
- <td class="tab0">
- <p>full Wi-Fi lock on time, Wi-Fi scan time, Wi-Fi running time</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <p>20</p>
- </td>
-
- <td class="tab0">
- <p>m</p>
- </td>
-
- <td class="tab0">
- <p>Misc</p>
- </td>
-
- <td class="tab0">
- <p>screen on time, phone on time, Wi-Fi on time, Wi-Fi running time,
- Bluetooth on time, mobile RX total bytes, mobile TX total bytes,
- Wi-Fi RX total bytes, Wi-Fi TX total bytes, full wake lock time
- total, partial wake lock time total, legacy input event count, mobile
- radio active time, mobile radio active adjusted time, interactive
- time, low-power mode enabled time</p>
- </td>
- </tr>
-
- <tr>
- <td>
- <p>21</p>
- </td>
-
- <td class="tab0">
- <p>gn</p>
- </td>
-
- <td class="tab0">
- <p>Global Network</p>
- </td>
-
- <td class="tab0">
- <p>mobile RX total bytes, mobile TX total bytes, Wi-Fi RX total
+ <td><p>gn</p></td>
+ <td><p>Global Network</p></td>
+ <td><p>mobile RX total bytes, mobile TX total bytes, Wi-Fi RX total
bytes, Wi-Fi TX total bytes, mobile RX total packets, mobile TX total
- packets, Wi-Fi RX total packets, Wi-Fi TX total packets</p>
- </td>
+ packets, Wi-Fi RX total packets, Wi-Fi TX total packets</p></td>
</tr>
<tr>
- <td>
- <p>22</p>
- </td>
-
- <td class="tab0">
- <p>br</p>
- </td>
-
- <td class="tab0">
- <p>Screen Brightness</p>
- </td>
-
- <td class="tab0">
- <p>dark, dim, medium, light, bright</p>
- </td>
+ <td><p>br</p></td>
+ <td><p>Screen Brightness</p></td>
+ <td><p>dark, dim, medium, light, bright</p></td>
</tr>
<tr>
- <td>
- <p>23</p>
- </td>
-
- <td class="tab0">
- <p>sst</p>
- </td>
-
- <td class="tab0">
- <p>Signal Scanning Time</p>
- </td>
-
- <td class="tab0">
- <p>signal scanning time</p>
- </td>
+ <td><p>sst</p></td>
+ <td><p>Signal Scanning Time</p></td>
+ <td><p>signal scanning time</p></td>
</tr>
<tr>
- <td>
- <p>24</p>
- </td>
-
- <td class="tab0">
- <p>sgt</p>
- </td>
-
- <td class="tab0">
- <p>Signal Strength Time</p>
- </td>
-
- <td class="tab0">
- <p>none, poor, moderate, good, great</p>
- </td>
+ <td><p>sgt</p></td>
+ <td><p>Signal Strength Time</p></td>
+ <td><p>none, poor, moderate, good, great</p></td>
</tr>
<tr>
- <td>
- <p>25</p>
- </td>
-
- <td class="tab0">
- <p>sgc</p>
- </td>
-
- <td class="tab0">
- <p>Signal Strength Count</p>
- </td>
-
- <td class="tab0">
- <p>none, poor, moderate, good, great</p>
- </td>
+ <td><p>sgc</p></td>
+ <td><p>Signal Strength Count</p></td>
+ <td><p>none, poor, moderate, good, great</p></td>
</tr>
<tr>
- <td>
- <p>26</p>
- </td>
-
- <td class="tab0">
- <p>dct</p>
- </td>
-
- <td class="tab0">
- <p>Data Connection Time</p>
- </td>
-
- <td class="tab0">
- <p>none, GPRS, EDGE, UMTS, CDMA, EVDO_0, EVDO_A, 1xRTT, HSDPA, HSUPA,
- HSPA, IDEN, EVDO_B, LTE, EHRPD, HSPAP, other</p>
- </td>
+ <td><p>dct</p></td>
+ <td><p>Data Connection Time</p></td>
+ <td><p>none, GPRS, EDGE, UMTS, CDMA, EVDO_0, EVDO_A, 1xRTT, HSDPA, HSUPA,
+ HSPA, IDEN, EVDO_B, LTE, EHRPD, HSPAP, other</p></td>
</tr>
<tr>
- <td>
- <p>27</p>
- </td>
-
- <td class="tab0">
- <p>dcc</p>
- </td>
-
- <td class="tab0">
- <p>Data Connection Count</p>
- </td>
-
- <td class="tab0">
- <p>none, GPRS, EDGE, UMTS, CDMA, EVDO_0, EVDO_A, 1xRTT, HSDPA, HSUPA,
- HSPA, IDEN, EVDO_B, LTE, EHRPD, HSPAP, other</p>
- </td>
+ <td><p>dcc</p></td>
+ <td><p>Data Connection Count</p></td>
+ <td><p>none, GPRS, EDGE, UMTS, CDMA, EVDO_0, EVDO_A, 1xRTT, HSDPA, HSUPA,
+ HSPA, IDEN, EVDO_B, LTE, EHRPD, HSPAP, other</p></td>
</tr>
<tr>
- <td>
- <p>28</p>
- </td>
-
- <td class="tab0">
- <p>wst</p>
- </td>
-
- <td class="tab0">
- <p>Wi-Fi State Time</p>
- </td>
-
- <td class="tab0">
- <p>off, off scanning, on no networks, on disconnected, on connected
- STA, on connected P2P, on connected STA P2P, soft AP</p>
- </td>
+ <td><p>wst</p></td>
+ <td><p>Wi-Fi State Time</p></td>
+ <td><p>off, off scanning, on no networks, on disconnected, on connected
+ STA, on connected P2P, on connected STA P2P, soft AP</p></td>
</tr>
<tr>
- <td>
- <p>29</p>
- </td>
-
- <td class="tab0">
- <p>wsc</p>
- </td>
-
- <td class="tab0">
- <p>Wi-Fi State Count</p>
- </td>
-
- <td class="tab0">
- <p>off, off scanning, on no networks, on disconnected, on connected
- STA, on connected P2P, on connected STA P2P, soft AP</p>
- </td>
+ <td><p>wsc</p></td>
+ <td><p>Wi-Fi State Count</p></td>
+ <td><p>off, off scanning, on no networks, on disconnected, on connected
+ STA, on connected P2P, on connected STA P2P, soft AP</p></td>
</tr>
<tr>
- <td>
- <p>30</p>
- </td>
-
- <td class="tab0">
- <p>wsst</p>
- </td>
-
- <td class="tab0">
- <p>Wi-Fi Supplicant State Time</p>
- </td>
-
- <td class="tab0">
- <p>invalid, disconnected, interface disabled, inactive, scanning,
+ <td><p>wsst</p></td>
+ <td><p>Wi-Fi Supplicant State Time</p></td>
+ <td><p>invalid, disconnected, interface disabled, inactive, scanning,
authenticating, associating, associated, four-way handshake, group
- handshake, completed, dormant, uninitialized</p>
- </td>
+ handshake, completed, dormant, uninitialized</p></td>
</tr>
<tr>
- <td>
- <p>31</p>
- </td>
-
- <td class="tab0">
- <p>wssc</p>
- </td>
-
- <td class="tab0">
- <p>Wi-Fi Supplicant State Count</p>
- </td>
-
- <td class="tab0">
- <p>invalid, disconnected, interface disabled, inactive, scanning,
+ <td><p>wssc</p></td>
+ <td><p>Wi-Fi Supplicant State Count</p></td>
+ <td><p>invalid, disconnected, interface disabled, inactive, scanning,
authenticating, associating, associated, four-way handshake, group
- handshake, completed, dormant, uninitialized</p>
- </td>
+ handshake, completed, dormant, uninitialized</p></td>
</tr>
<tr>
- <td>
- <p>32</p>
- </td>
-
- <td class="tab0">
- <p>wsgt</p>
- </td>
-
- <td class="tab0">
- <p>Wi-Fi Signal Strength Time</p>
- </td>
-
- <td class="tab0">
- <p>none, poor, moderate, good, great</p>
- </td>
+ <td><p>wsgt</p></td>
+ <td><p>Wi-Fi Signal Strength Time</p></td>
+ <td><p>none, poor, moderate, good, great</p></td>
</tr>
<tr>
- <td>
- <p>33</p>
- </td>
-
- <td class="tab0">
- <p>wsgc</p>
- </td>
-
- <td class="tab0">
- <p>Wi-Fi Signal Strength Count</p>
- </td>
-
- <td class="tab0">
- <p>none, poor, moderate, good, great</p>
- </td>
+ <td><p>wsgc</p></td>
+ <td><p>Wi-Fi Signal Strength Count</p></td>
+ <td><p>none, poor, moderate, good, great</p></td>
</tr>
<tr>
- <td>
- <p>34</p>
- </td>
+ <td><p>bst</p></td>
+ <td><p>Bluetooth State Time</p></td>
+ <td><p>inactive, low, med, high</p></td>
+ </tr>
- <td class="tab0">
- <p>bst</p>
- </td>
-
- <td class="tab0">
- <p>Bluetooth State Time</p>
- </td>
-
- <td class="tab0">
- <p>inactive, low, med, high</p>
- </td>
+ <tr>
+ <td><p>bsc</p></td>
+ <td><p>Bluetooth State Count</p></td>
+ <td><p>inactive, low, med, high</p></td>
</tr>
<tr>
- <td>
- <p>35</p>
- </td>
-
- <td class="tab0">
- <p>bsc</p>
- </td>
-
- <td class="tab0">
- <p>Bluetooth State Count</p>
- </td>
-
- <td class="tab0">
- <p>inactive, low, med, high</p>
- </td>
+ <td><p>pws</p></td>
+ <td><p>Power Use Summary</p></td>
+ <td><p>battery capacity, computed power, minimum drained power, maximum
+ drained power</p></td>
</tr>
<tr>
- <td>
- <p>36</p>
- </td>
-
- <td class="tab0">
- <p>pws</p>
- </td>
-
- <td class="tab0">
- <p>Power Use Summary</p>
- </td>
-
- <td class="tab0">
- <p>battery capacity, computed power, minimum drained power, maximum
- drained power</p>
- </td>
+ <td><p>pwi</p></td>
+ <td><p>Power Use Item</p></td>
+ <td><p>label, mAh</p></td>
</tr>
<tr>
- <td>
- <p>37</p>
- </td>
-
- <td class="tab0">
- <p>pwi</p>
- </td>
-
- <td class="tab0">
- <p>Power Use Item</p>
- </td>
-
- <td class="tab0">
- <p>label, mAh</p>
- </td>
+ <td><p>dsd</p></td>
+ <td><p>Discharge Step</p></td>
+ <td><p>duration, level, screen, power-save</p></td>
</tr>
<tr>
- <td>
- <p>38</p>
- </td>
-
- <td class="tab0">
- <p>dsd</p>
- </td>
-
- <td class="tab0">
- <p>Discharge Step</p>
- </td>
-
- <td class="tab0">
- <p>duration, level, screen, power-save</p>
- </td>
+ <td><p>csd</p></td>
+ <td><p>Charge Step</p></td>
+ <td><p>duration, level, screen, power-save</p></td>
</tr>
<tr>
- <td>
- <p>39</p>
- </td>
-
- <td class="tab0">
- <p>csd</p>
- </td>
-
- <td class="tab0">
- <p>Charge Step</p>
- </td>
-
- <td class="tab0">
- <p>duration, level, screen, power-save</p>
- </td>
+ <td><p>dtr</p></td>
+ <td><p>Discharge Time Remaining</p></td>
+ <td><p>battery time remaining</p></td>
</tr>
<tr>
- <td>
- <p>40</p>
- </td>
-
- <td class="tab0">
- <p>dtr</p>
- </td>
-
- <td class="tab0">
- <p>Discharge Time Remaining</p>
- </td>
-
- <td class="tab0">
- <p>battery time remaining</p>
- </td>
+ <td><p>ctr</p></td>
+ <td><p>Charge Time Remaining</p></td>
+ <td><p>charge time remaining</p></td>
</tr>
- <tr>
- <td>
- <p>41</p>
- </td>
-
- <td class="tab0">
- <p>ctr</p>
- </td>
-
- <td class="tab0">
- <p>Charge Time Remaining</p>
- </td>
-
- <td class="tab0">
- <p>charge time remaining</p>
- </td>
- </tr>
</table>
+
+<h2 id="wifi-reqs">Wi-Fi, Bluetooth, and cellular usage</h2>
+
+<p>Support for battery usage data on Wi-Fi, Bluetooth, and cellular data
+requires that the device Wi-Fi, Bluetooth, and cellular chipsets implement radio
+support and the chipset firmware passes usage data to the framework. OEMs must
+work with their chipset providers to facilitate in-field firmware updates on
+existing chipsets and compatible firmware on new chipsets.</p>
+
+<p>Additionally, OEMs must continue to configure and submit the power profile
+for their devices. However, when the platform detects that Wi-Fi and Bluetooth
+radio power data is available from the chipset, it uses chipset data instead of
+power profile data (cell radio power data is not yet used).</p>
+
+<p class="note"><strong>Note</strong>: Prior to Android 6.0, power use for Wi-Fi
+radio, Bluetooth radio, and cellular radio was tracked in the <em>m</em> (Misc)
+section category. In Android 6.0 and higher, power use for these components is
+tracked in the <em>pwi</em> (Power Use Item) section with individual labels
+(<em>wifi</em>, <em>blue</em>, <em>cell</em>) for each component.</p>
\ No newline at end of file
diff --git a/src/devices/tech/power/index.jd b/src/devices/tech/power/index.jd
index 33e08a8..0876ae7 100644
--- a/src/devices/tech/power/index.jd
+++ b/src/devices/tech/power/index.jd
@@ -79,4 +79,4 @@
<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>
\ No newline at end of file
+background activity are reported separately).</p>
diff --git a/src/devices/tech/power/mgmt.jd b/src/devices/tech/power/mgmt.jd
new file mode 100644
index 0000000..32c20aa
--- /dev/null
+++ b/src/devices/tech/power/mgmt.jd
@@ -0,0 +1,262 @@
+page.title=Power Management
+@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>Battery life is a perennial user concern. To extend battery life, Android
+continually adds new features and optimizations to help the platform optimize
+the off-charger behavior of applications and devices.</p>
+<p>The Android 6.0 release includes the following improvements to battery life:
+</p>
+
+<ul>
+<li><b><a href="#app-standby">App Standby</b></a>. The platform can now place
+unused applications in App Standby mode, temporarily restricting network access
+and deferring syncs and jobs for those applications.</li>
+<li><b><a href="#doze">Doze</b></a>. The platform now enters a state of deep
+sleep (periodically resuming normal operations) if users have not actively used
+their device (screen off and stationary) for extended periods of time. As this
+feature requires the platform to detect the stationary state, it is available
+only on devices that implement the significant motion detection APIs in the
+Sensor HAL. Doze dramatically improves battery life.</li>
+<li><b><a href="#exempt-apps">Exemptions</b></a>. System apps and cloud
+messaging services preloaded on a device are typically exempted by default. App
+developers can intent their applications into this setting. Users can also
+exempt applications from App Standby and Doze via Settings > Battery >
+Battery optimization > All apps and then selecting the app to turn off (or back
+on) optimization.</li>
+</ul>
+<p>The following sections describe these improvements.</p>
+
+<h2 id="app-standby">App Standby</h2>
+<p>App Standby extends battery life by deferring background network activity
+and jobs for applications the user is not actively using.</p>
+
+<h3 id="app-standby-life">App Standby lifecycle</h3>
+<p>The platform detects inactive applications and places them in App Standby
+until the user begins actively engaging with the application.</p>
+
+<table>
+<tbody>
+<tr>
+<th width=33%>Detection</th>
+<th width=33%>During App Standby</th>
+<th width=33%>Exit</th>
+</tr>
+
+<tr>
+<td><p>The platform detects an application is inactive when the device is not
+charging <strong>and</strong> the user has not launched the application directly
+or indirectly for a specific amount of clock time as well as a specific amount
+of screen-on time. (Indirect launches occur when a foreground app accesses a
+service in a second app.)</p></td>
+<td><p>The platform prevents applications from accessing the network more than
+once a day, deferring application syncs and other jobs.</p></td>
+<td><p>The platform exits the app from App Standby when:</p>
+<ul>
+<li>Application becomes active.</li>
+<li>Device is plugged in and charging.</li>
+</ul>
+</td>
+</tr>
+</tbody>
+</table>
+
+<p>Active applications are unaffected by App Standby. An application is active
+when it has:</p>
+<ul>
+<li>A process currently in the foreground (either as an activity or foreground
+service, or in use by another activity or foreground service), such as
+notification listener, accessibility services, live wallpaper, etc.</li>
+<li>A notification viewed by the user, such as in the lock screen or
+notification tray.</li>
+<li>Explicitly been launched by the user.</li>
+</ul>
+<p>An application is inactive if none of the above activities has occurred for
+a period of time.
+</p>
+
+<h3>Testing App Standby</h3>
+<p>You can manually test App Standby using the following ADB commands:</p>
+
+<pre>
+$ adb shell dumpsys battery unplug
+$ adb shell am set-idle packageName true
+$ adb shell am set-idle packageName false
+$ adb shell am get-idle packageName
+</pre>
+
+<h2 id="doze">Doze</h2>
+
+<p>Doze extends battery life by deferring application background CPU and
+network activity when a device is unused for long periods.</p>
+
+<p>Idle devices in Doze periodically enter a maintenance window, during which
+apps can complete pending activities (syncs, jobs, etc.). Doze then resumes sleep
+for a longer period of time, followed by another maintenance window. The
+platform continues the Doze sleep/maintenance sequence, increasing the length of
+idle each time, until a maximum of a few hours of sleep time is reached. At all
+times, a device in Doze remains aware of motion and immediately leaves Doze
+if motion is detected.</p>
+
+<p>System services (such as telephony) may be preloaded and exempted from Doze
+by default. Users can also exempt specific applications from Doze in the
+Settings menu. By default, Doze is <b>disabled</b> in the Android Open Source
+Project (AOSP). For details on enabling Doze, see
+<a href="#integrate-doze">Integrating Doze</a>.</p>
+
+<h3 id="doze-reqs">Doze requirements</h3>
+
+<p>Doze support requires the following:</p>
+<ul>
+<li>Device implements the
+<a href="http://source.android.com/devices/sensors/sensor-types.html#significant_motion">significant
+motion detector (SMD) APIs</a> in the Sensor HAL. Devices that do not implement
+these APIs cannot support Doze.</li>
+<li>Device has a cloud messaging service, such as
+<a href="https://developers.google.com/cloud-messaging/">Google Cloud Messaging
+(GCM).</a> This enables the device to know when to wake from Doze.</li>
+</ul>
+
+<h3 id="doze-life">Doze lifecycle</h3>
+
+<p>The Doze lifecycle begins when the platform detects the device is idle and
+ends when the device exits Doze mode.</p>
+
+<table>
+<tbody>
+<tr>
+<th width=33%>Detection</td>
+<th width=33%>During Doze</th>
+<th width=33%>Exit</th>
+</tr>
+<tr>
+<td><p>The platform detects a device is idle when:</p>
+<ul>
+<li>Device is stationary (using significant motion detector).</li>
+<li>Device screen is off for some amount of time.</li>
+</ul>
+<p>Doze mode does not engage when the device is plugged into a power charger.
+</p>
+</td>
+<td><p>The platform attempts to keep the system in a sleep state, periodically
+resuming normal operations during a maintenance window then returning the device
+to sleep for longer repeating periods. During the sleep state, the following
+restrictions are active:</p>
+<ul>
+<li>Apps not allowed network access.</li>
+<li>App wakelocks ignored.</li>
+<li>Alarms deferred. Excludes alarm clock alarms and alarms set using
+<code>setAndAllowWhileIdle()</code> (limited to 1 per 15 minutes per app while
+in Doze). This exemption is intended for apps (such as Calendar) that must show
+event reminder notifications.</li>
+<li>Wi-Fi scans not performed.</li>
+<li>SyncAdapter syncs and JobScheduler jobs deferred until the next maintenance
+window.</li>
+<li>Apps receiving SMS and MMS messages are put on a temporary whitelist so
+they can complete their processing.</li>
+</ul>
+</td>
+<td><p>The platform exits the device from Doze when it detects:</p>
+<ul>
+<li>User interaction with device.</li>
+<li>Device movement.</li>
+<li>Device screen turns on.</li>
+<li>Imminent AlarmClock alarm.</li>
+</ul>
+<p>Notifications do not cause the device to exit from Doze.</p>
+</td>
+</tr>
+</tbody>
+</table>
+
+<h3 id="doze-interactions">Interaction with App Standby</h3>
+<ul>
+<li>Time spent in Doze does not count towards App Standby.</li>
+<li>While the device is in Doze, idle applications are allowed to perform normal
+operations at least once a day.</li>
+</ul>
+
+<h3 id="integrate-doze">Integrating Doze</h3>
+<p>To enable Doze for a device, perform the following tasks:</p>
+
+<ol>
+<li>Confirm the device supports
+<a href="http://source.android.com/devices/sensors/sensor-types.html#significant_motion">SENSOR_TYPE_SIGNIFICANT_MOTION
+</a>. If the device does not support this sensor, it cannot support Doze.</li>
+<li>Confirm the device has a cloud messaging service installed.</li>
+<li>In the device overlay config file
+<code>overlay/frameworks/base/core/res/res/values/config.xml</code>, set
+<code>config_enableAutoPowerModes</code> to <b>true</b>:
+<pre>
+bool name="config_enableAutoPowerModes">true</bool>
+</pre>
+<br>In AOSP, this parameter is set to false (Doze disabled) by default.<br>
+</li>
+<li>Confirm that preloaded apps and services:
+<ul>
+<li>Use the new
+<a href="https://developer.android.com/preview/behavior-changes.html#behavior-power">power-saving
+optimization guidelines</a>. For details, see <a href="#test-apps">Testing and
+optimizing applications</a>.
+<p><b>OR</b></p>
+<li>Are exempted from Doze and App Standby. For details, see
+<a href="#exempt-apps">Exempting applications</a>.</li>
+</ul>
+</li>
+<li>Confirm the necessary services are exempted from Doze.</a>
+</li>
+</ol>
+
+<h4 id="test-apps">Testing and optimizing applications</h4>
+<p>Test all applications (especially preloaded applications) in Doze mode. For
+details, refer to
+<a href="https://developer.android.com/preview/testing/guide.html#doze-standby">Testing
+Doze and App Standby</a>.</p>
+
+<p class="note"><b>Note</b>: MMS/SMS/Telephony services function independently
+of Doze and will always wake client apps even while the device remains in Doze
+mode.</p>
+
+<h2 id="exempt-apps">Exempting applications</h2>
+<p>You can exempt applications from being subject to Doze or App Standby.</p>
+
+<p class="warning"><b>Warning</b>: Do not exempt apps to avoid testing and
+optimizing. Unnecessary exemptions undermine the benefits of Doze and App
+Standby and can compromise the user experience, so we strongly suggest
+minimizing such exemptions as they allow applications to defeat beneficial
+controls the platform has over power use. If users become unhappy about the
+power consumption of these apps, it can lead to frustration, bad experiences
+(and negative user reviews for the app), and customer support questions. For
+these reasons, we strongly recommend that you do not exempt third-party
+applications and instead exempt only cloud messaging services or apps with
+similar functions.</p>
+
+<p>Apps exempted by default are listed in a single view within the Settings >
+Battery menu. This list is used for exempting the app from both Doze and App
+Standby modes. To provide transparency to the user, the Settings menu
+<b>MUST</b> show all exempted applications.</p>
+
+<p>Users can manually exempt apps using the Settings menu. However, users cannot
+unexempt any application or service that is exempted by default in the system
+image.</p>
\ No newline at end of file
diff --git a/src/devices/tech/power/values.jd b/src/devices/tech/power/values.jd
index e88900a..8c6d4ac 100644
--- a/src/devices/tech/power/values.jd
+++ b/src/devices/tech/power/values.jd
@@ -33,7 +33,46 @@
the values (deriving differences from other baseline power uses as appropriate).
</p>
+<h2 id="multiple-cpus">Devices with heterogeneous CPUs</h2>
+
+<p>The power profile for devices with CPU cores of heterogeneous architecture
+must include the following additional fields:
+<ul>
+<li>Number of total CPUs for each cluster.</li>
+<li>CPU speeds supported by each cluster.</li>
+</ul>
+
+<p>To differentiate between active CPUs and supported CPU speeds for each
+cluster, append the cluster number to the name of the array. Example:</p>
+
+<pre>
+<array name="cpu.active.cluster0">
+<value>200</value>
+<value>300</value>
+<value>400</value>
+</array>
+<array name="cpu.speeds.cluster0">
+<value>600000</value>
+<value>800000</value>
+<value>1200000</value>
+</array>
+
+<array name="cpu.active.cluster1">
+<value>400</value>
+<value>500</value>
+<value>600</value>
+</array>
+<array name="cpu.speeds.cluster1">
+<value>800000</value>
+<value>1200000</value>
+<value>1400000</value>
+</array>
+</pre>
+
<h2 id="values">Power values</h2>
+<p>The following table describes available power value settings. To view the
+sample file in AOSP, see
+<a href="https://android.googlesource.com/platform/frameworks/base/+/master/core/res/res/xml/power_profile.xml">power_profile.xml</a>.</p>
<table>
<tr>
@@ -205,60 +244,20 @@
</tr>
<tr>
+ <td>cpu.clusters.cores</td>
+ <td>Number of cores each CPU cluster contains.</td>
+ <td>4, 2</td>
+ <td>Required only for devices with <a href="#multiple-cpus">heterogeneous CPU
+ architectures</a>. Number of entries and order should match the number of
+ cluster entries for the cpu.active and cpu.speeds. The first entry represents
+ the number of CPU cores in cluster0, the second entry represents the number of
+ CPU cores in cluster1, and so on.</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
+</table>
\ No newline at end of file
diff --git a/src/devices/tech/security/authentication/fingerprint-hal.jd b/src/devices/tech/security/authentication/fingerprint-hal.jd
new file mode 100644
index 0000000..f2bbed7
--- /dev/null
+++ b/src/devices/tech/security/authentication/fingerprint-hal.jd
@@ -0,0 +1,174 @@
+page.title=Fingerprint HAL
+@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>If a device has a fingerprint sensor, a user can enroll one or more
+fingerprints and then use their fingerprints to unlock the device and perform
+other tasks.</p>
+
+<p>Android uses the Fingerprint Hardware Abstraction Layer (HAL) to connect to a
+vendor-specific library and fingerprint hardware, e.g. a fingerprint sensor.</p>
+
+<p>To implement the Fingerprint HAL, you must implement
+<a href="#major_functions_in_the_fingerprint_hal">functions</a>
+in <code>fingerprint.h</code> (<code>/hardware/libhardware/include/hardware/fingerprint.h</code>)
+in a vendor-specific library; please see the comments in
+the <a href="https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/fingerprint.h"><code>fingerprint.h</code></a> file.</p>
+
+<h3 id=fingerprint_matching_flow>Fingerprint matching flow</h3>
+
+<p>The following is a high-level flow for fingerprint matching. This flow assumes
+that a fingerprint already has been enrolled on the device, i.e. the
+vendor-specific library already has enrolled a template for the fingerprint.
+Also see <a href="index.html">Authentication</a>.</p>
+
+<p>The fingerprint sensor of a device generally is idle. But in response to a call
+to the <code>authenticate</code> or <code>enroll</code> function, the fingerprint
+sensor listens for a touch (and perhaps the screen
+wakes up when a user touches the fingerprint sensor).</p>
+
+<ol>
+ <li>The user places a finger on the fingerprint sensor, and the vendor-specific
+library determines if there is a match based on the current set of enrolled
+templates.
+ <li>The result of step 1 is passed to the Fingerprint HAL, which notifies
+<code>fingerprintd</code> (the Fingerprint daemon) of a fingerprint authentication.
+</ol>
+
+<p>Note that as more templates are stored on a single device, the time needed for
+matching is increased.</p>
+
+<h2 id=architecture>Architecture</h2>
+
+<p>The <strong>Fingerprint HAL</strong> interacts with the following components:</p>
+
+<ul>
+ <li><strong>FingerprintManager API</strong>. Interacts directly with an app in an app process.
+ <ul>
+ <li>Each app has an instance of FingerprintManager.
+ <li>FingerprintManager is a wrapper that communicates with FingerprintService.
+ </ul>
+ <li><strong>FingerprintService</strong>. A singleton service that operates in the system
+ process, which handles
+communication with <code>fingerprintd</code>.
+ <li><strong>fingerprintd (Fingerprint daemon)</strong>. A C/C++ implementation of the
+ binder interface from FingerprintService. The
+<code>fingerprintd</code> daemon operates in its own process and wraps the Fingerprint HAL
+vendor-specific library.
+ <li><strong>Fingerprint HAL vendor-specific library</strong>. A hardware vendor's
+ implementation of the Fingerprint HAL. The
+vendor-specific library communicates with the device-specific hardware.
+ <li><strong>Keystore API and Keymaster</strong>. These components provide hardware-backed cryptography
+ for secure key storage
+ in a Trusted Execution Environment (TEE).
+</ul>
+
+<p>As shown in the following diagram, a vendor-specific HAL implementation needs
+to use the communication protocol required by a TEE.</p>
+
+<img src="../images/fingerprint-data-flow.png" alt="Data flow for fingerprint authentication" id="figure1" />
+
+<p class="img-caption"><strong>Figure 1.</strong> High-level data flow for fingerprint authentication</p>
+
+<p>Thus, raw images and processed fingerprint features must not be passed in
+untrusted memory. All such biometric data needs to be secured within sensor
+hardware or trusted memory. (Memory inside the TEE is considered as trusted
+memory; memory outside the TEE is considered untrusted.)</p>
+
+<p>Rooting must not compromise biometric data.</p>
+
+<p>As shown in the following diagram, <code>fingerprintd</code> makes calls through the
+Fingerprint HAL to the vendor-specific library to enroll fingerprints and
+perform other operations.</p>
+
+<img src="../images/fingerprint-daemon.png" alt="Interaction with fingerprintd" id="figure2" />
+<p class="img-caption"><strong>Figure 2.</strong> Interaction of the
+fingerprint daemon (<code>fingerprintd</code>) with the fingerprint vendor-specific library</p>
+
+<h2 id=fingerprint_implementation_guidelines>Fingerprint implementation guidelines</h2>
+
+<p>The guidelines in this section are intended to ensure the following:</p>
+
+<ul>
+ <li>Fingerprint data is not leaked
+ <li>Fingerprint data is removed when a user is removed from a device
+</ul>
+
+<p>Here are the guidelines:</p>
+
+<ol>
+ <li>Raw fingerprint data or derivatives (e.g. templates) must never be accessible
+from outside the sensor driver or Trusted Execution Environment (TEE). Hardware
+access must be limited to the TEE, if the hardware supports it, and must be protected by
+an SELinux policy. That is, the Serial Peripheral Interface (SPI) channel must
+be accessible only to the TEE, and there must be an explicit SELinux policy on
+all device files.
+ <li>Fingerprint acquisition, enrollment and recognition must occur inside the TEE.
+ <li>Only the encrypted form of the fingerprint data can be stored on the file
+system, even if the file system itself is encrypted.
+ <li>Fingerprint templates must be signed with a private, device-specific key, for
+example with AES, with at least the absolute file-system path, group and finger
+ID such that template files are inoperable on another device or for anyone
+other than the user that enrolled them on the same device. For example, copying
+the fingerprint data from a different user on the same device, or from another
+device, must not work.
+ <li>Implementations must either use the file system path provided by the
+ <code>set_active_group()</code> function or provide a way to erase all user template data when the user
+is removed. It is strongly recommended that fingerprint template files
+be stored as encrypted in the path provided. If this is infeasible due to TEE
+storage requirements, then the implementer must add hooks to ensure removal of
+the data when the user is removed.
+</ol>
+
+<h2 id=major_functions_in_the_fingerprint_hal>Major functions in the Fingerprint HAL</h2>
+
+<p>Below are the major functions in the <code>/hardware/libhardware/include/hardware/fingerprint.h</code> file; see the detailed descriptions in that
+file.</p>
+
+<ul>
+ <li><strong>enroll.</strong> Switches the HAL state machine to start the collection and storage of a
+fingerprint template. As soon as enrollment is complete, or after a timeout,
+the HAL state machine is returned to the idle state.
+ <li><strong>pre_enroll.</strong> Generates a unique token to indicate the start of a fingerprint enrollment.
+Provides a token to the <code>enroll</code> function to ensure there was prior authentication, e.g. using a password. The
+token is wrapped and, for example, HMAC'd, once the device credential is
+confirmed, to prevent tampering. The token must be checked during enrollment to
+verify that the token is still valid.
+ <li><strong>get_authenticator_id.</strong> Returns a token associated with the current fingerprint set.
+ <li><strong>cancel.</strong> Cancels any pending enroll or authenticate operations. The HAL state machine
+is returned to the idle state.
+ <li><strong>enumerate.</strong> Synchronous call for enumerating all known fingerprint templates.
+ <li><strong>remove.</strong> Deletes a fingerprint template.
+ <li><strong>set_active_group.</strong> Restricts a HAL operation to a set of fingerprints that belong to a specified
+group (identified by a group identifier, or GID).
+ <li><strong>authenticate.</strong> Authenticates a fingerprint-related operation (identified by an operation ID).
+ <li><strong>set_notify.</strong> Registers a user function that will get notifications from the HAL. If the HAL
+state machine is in a busy state, the function is blocked until the HAL leaves
+the busy state.
+</ul>
+
diff --git a/src/devices/tech/security/authentication/gatekeeper.jd b/src/devices/tech/security/authentication/gatekeeper.jd
new file mode 100644
index 0000000..9d760bc
--- /dev/null
+++ b/src/devices/tech/security/authentication/gatekeeper.jd
@@ -0,0 +1,192 @@
+page.title=Gatekeeper
+@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>The Gatekeeper subsystem performs device pattern/password authentication in a
+Trusted Execution Environment (TEE). Gatekeeper enrolls and verifies passwords
+via an HMAC with a hardware-backed secret key. Additionally, Gatekeeper
+throttles consecutive failed verification attempts and must refuse to service
+requests based on a given timeout and a given number of consecutive failed
+attempts.</p>
+
+<p>When users verify their passwords, Gatekeeper uses the TEE-derived shared
+secret to sign an authentication attestation to
+send to <a href="keymaster.html">Keymaster</a>. That is, a
+Gatekeeper attestation notifies Keymaster that authentication-bound keys (for
+example, keys that apps have created) can be released for use by apps.</p>
+
+<h2 id=architecture>Architecture</h2>
+
+<p>Gatekeeper involves three main components:</p>
+
+<ul>
+ <li><strong>gatekeeperd (Gatekeeper daemon)</strong>.
+ A C++ binder service containing platform-independent logic and corresponding
+to the <code>GateKeeperService</code> Java interface.
+ <li><strong>Gatekeeper Hardware Abstraction Layer (HAL)</strong>.
+ The HAL interface in <code>hardware/libhardware/include/hardware/gatekeeper.h</code>,
+ and the implementing module.
+ <li><strong>Gatekeeper (TEE)</strong>.
+ The TEE counterpart of <code>gatekeeperd</code>. A TEE-based implementation of Gatekeeper.
+</ul>
+
+<p>To implement Gatekeeper:</p>
+
+<ul>
+ <li>Implement the Gatekeeper HAL, specifically the functions in <code>gatekeeper.h</code>
+ (<code>hardware/libhardware/include/hardware/gatekeeper.h</code>). See <a href="#hal_implementation">HAL Implementation</a>.
+ <li>Implement the TEE-specific Gatekeeper component, in part based on the following
+header file: <code>system/gatekeeper/include/gatekeeper/gatekeeper.h</code>. This
+header file includes pure virtual functions for creating and accessing
+keys, as well as for computing signatures.
+See <a href="#trusty_and_other_implementations">Trusty and other implementations</a>.
+</ul>
+
+<p>As shown in the following diagram, the <code>LockSettingsService</code> makes a request (via
+Binder) that reaches the <code>gatekeeperd</code> daemon in the Android OS. The <code>gatekeeperd</code>
+daemon makes a request that reaches its counterpart (Gatekeeper) in the TEE.</p>
+
+<img src="../images/gatekeeper-flow.png" alt="Gatekeeper flow" id="figure1" />
+<p class="img-caption"><strong>Figure 1.</strong> High-level data flow for authentication by GateKeeper</p>
+
+<p>The <code>gatekeeperd</code> daemon gives the Android framework APIs access to the HAL, and
+participates in reporting device <a href="index.html">authentications</a> to Keymaster.
+The <code>gatekeeperd</code> daemon runs in its own process, separate from the system
+server.</p>
+
+<h2 id=hal_implementation>HAL Implementation</h2>
+
+<p>The <code>gatekeeperd</code> daemon uses the HAL to interact
+with the <code>gatekeeperd</code> daemon's TEE
+counterpart for password authentication. The HAL implementation must be able to
+sign (enroll) and verify blobs. All implementations are expected to adhere to
+the standard format for the authentication token (AuthToken) generated on each
+successful password verification. The contents and semantics of the AuthToken
+are described in <a href="index.html">Authentication</a>.</p>
+
+<p>Specifically, an implementation of the <code>gatekeeper.h</code> header file (in the
+<code>hardware/libhardware/include/hardware</code> folder) needs to implement the
+<code>enroll</code> and <code>verify</code> functions.</p>
+
+<p>The <code>enroll</code> function takes a password blob, signs it, and returns the signature
+as a handle. The returned blob (from a call to <code>enroll</code>) must have the structure
+shown in <code>system/gatekeeper/include/gatekeeper/password_handle.h</code>.</p>
+
+<p>The <code>verify</code> function needs to compare the signature produced by the provided password and
+ensure that it matches the enrolled password handle.</p>
+
+<p>The key used to enroll and verify must never change, and should be re-derivable
+at every device boot.</p>
+
+<h2 id=trusty_and_other_implementations>Trusty and other implementations</h2>
+
+<p>The Trusty operating system is Google's open source trusted OS for TEE
+environments. It contains an approved implementation of GateKeeper. However,
+<strong>any TEE OS</strong> can be used for the implementation of Gatekeeper.
+The TEE <strong>must</strong> have access to a hardware-backed key as well as a secure,
+monotonic clock <strong>that ticks in suspend</strong>.</p>
+
+<p>Trusty uses an internal IPC system to communicate a shared secret directly
+between Keymaster and the Trusty implementation of Gatekeeper ("Trusty
+Gatekeeper"). This shared secret is used for signing AuthTokens that will be
+sent to Keymaster, providing attestations of password verification. Trusty
+Gatekeeper requests the key from Keymaster for each use and does not persist
+or cache the value. Implementations are free to share this secret in any way
+that does not compromise security.</p>
+
+<p>The HMAC key, used to enroll and verify passwords, is derived and kept solely
+in GateKeeper.</p>
+
+<p>The Android tree provides a generic C++ implementation of GateKeeper, requiring
+only the addition of device-specific routines to be complete. To implement a
+TEE Gatekeeper with device-specific code for your TEE, please refer to the
+functions and comments in the following file:</p>
+<pre>
+system/gatekeeper/include/gatekeeper/gatekeeper.h
+</pre>
+
+<p>For the TEE GateKeeper, the primary responsibilities of a compliant
+implementation are:</p>
+
+<ul>
+ <li>Adherence to the Gatekeeper HAL
+ <li>Returned AuthTokens must be formatted according to the AuthToken specification
+(described in <a href="index.html">Authentication</a>)
+ <li>The TEE Gatekeeper must be able to share an HMAC key with Keymaster, either by
+requesting the key through a TEE IPC on demand or maintaining a valid cache of
+the value at all times
+</ul>
+
+<h2 id=user_sids>User SIDs</h2>
+
+<p>A User Secure ID (User SID) is the TEE representation of a user.
+The User SID has no strong connection to an Android user ID.</p>
+
+<p>A User SID is generated with a cryptographic
+PRNG whenever a user enrolls a new password without providing a previous one.
+This is known as an "untrusted" re-enroll.
+A "trusted" re-enroll occurs when a user provides a valid, previous password.
+In this case, the User SID is migrated to the new password handle,
+conserving the keys that were bound to it.
+The Android framework does not allow for an "untrusted" re-enroll under regular circumstances.</p>
+
+<p>The User SID is HMAC'ed along with the password in the password handle when the
+password is enrolled.</p>
+
+<p>User SIDs are written into the AuthToken returned by the <code>verify</code>
+function and associated to all authentication-bound Keymaster keys. For
+information about the AuthToken format and Keymaster, see
+<a href="index.html">Authentication</a>.
+Since an untrusted call to the <code>enroll</code> function
+will change the User SID, the call will render the keys bound to that password useless.</p>
+
+<p>Attackers can change the password for the device if they control the Android
+OS, but they will destroy root-protected, sensitive keys in the process.</p>
+
+<h2 id=request_throttling>Request throttling</h2>
+
+<p>GateKeeper must be able to securely throttle brute-force attempts on a user
+credential. As shown in the <code>gatekeeper.h</code>
+file (in <code>hardware/libhardware/include/hardware</code>),
+the HAL provides for returning a timeout in milliseconds. The timeout
+informs the client not to call GateKeeper again until after the timeout has
+elapsed. GateKeeper should not service requests if there is a pending timeout.</p>
+
+<p>GateKeeper must write a failure counter before verifying a user password. If
+the password verification succeeds, the failure counter should be cleared. This
+prevents attacks that prevent throttling by disabling the embedded MMC (eMMC)
+after issuing a <code>verify</code> call. The <code>enroll</code> function also verifies
+the user password (if provided) and so must be throttled in the same way.</p>
+
+<p>If supported by the device, it is highly recommended that the failure counter
+be written to secure storage. If the device does not support
+file-based encryption, or if secure storage is too slow, implementations may
+use RPMB directly.</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..86564eb
--- /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 <a href="keymaster.html">Keymaster</a>.</strong> Cryptographic services,
+ including hardware-backed cryptography for key storage,
+ which might include a Trusted Execution Environment (TEE).</li>
+ <li><strong><a href="gatekeeper.html">Gatekeeper</a>.</strong> Components for PIN, pattern, and password authentication.</li>
+ <li><strong><a href="fingerprint-hal.html">Fingerprint</a>.</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/authentication/keymaster.jd b/src/devices/tech/security/authentication/keymaster.jd
new file mode 100644
index 0000000..8febf76
--- /dev/null
+++ b/src/devices/tech/security/authentication/keymaster.jd
@@ -0,0 +1,100 @@
+page.title=Keymaster
+@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 availability of a trusted execution environment in a system on a chip (SoC)
+offers an opportunity for Android devices to provide hardware-backed, strong
+security services to the Android OS, to platform services, and even to
+third-party apps.</p>
+
+<p>Keymaster has been <a href="km-features.html">significantly enhanced</a>
+in Android 6.0 with the addition of symmetric cryptographic primitives,
+AES and HMAC, and the addition of an access control
+system for hardware-backed keys. Access controls are specified during key
+generation and enforced for the lifetime of the key. Keys can be restricted to
+be usable only after the user has authenticated, only at a specific usage
+velocity, and only for specified purposes or with specified cryptographic
+parameters. For more information, please see
+the <a href="km-implementer-ref.html">Implementer's Reference</a>.</p>
+
+<p>Before Keymaster 1.0, Android already had a simple, hardware-backed crypto
+services API: Keymaster versions 0.2 and 0.3, which provided only digital
+signing and verification operations, plus generation of
+asymmetric signing key pairs. This is already
+implemented on many devices, but there are many security goals that cannot
+easily be achieved with only a signature API. The intent of Keymaster 1.0 is to
+extend the Keymaster API to provide a broader range of capabilities.</p>
+
+<h2 id=goals>Goals</h2>
+
+<p>The goal of the Keymaster API is to provide a basic but adequate set of
+cryptographic primitives to allow the implementation of protocols using
+access-controlled, hardware-backed keys.</p>
+
+<p>In addition to expanding the range of cryptographic primitives, Keymaster v1.0
+adds the following:</p>
+
+<ul>
+ <li>A usage control scheme to allow key usage to be limited, to mitigate the risk
+of security compromise due to misuse of keys
+ <li>An access control scheme to enable restriction of keys to specified users,
+clients, and a defined time range
+</ul>
+
+<h2 id=architecture>Architecture</h2>
+
+<p>The Keymaster API is a Hardware Abstraction Layer module, which is a
+dynamically-loaded library. Implementations must not
+perform any sensitive operations in user space, or even in kernel space.
+Sensitive operations are delegated to a secure processor reached through some
+kernel interface. The resulting architecture looks something like the
+following:</p>
+
+<img src="../images/access-to-keymaster.png" alt="Access to Keymaster" id="figure1" />
+<p class="img-caption"><strong>Figure 1.</strong> Access to Keymaster</p>
+
+<p>Within an Android device, the "client" actually consists of multiple layers
+(e.g. app, framework, keystore daemon), but that can be ignored for the
+purposes of this document. This means that the described API is low-level, used
+by platform-internal components, and not exposed to app developers. The
+higher-level API, for API level 23, is described on
+the <a href="http://developer.android.com/reference/java/security/KeyStore.html">Android Developer site</a>.</p>
+
+<p>The purpose of the <code>libkeymaster</code> library is not to implement the
+security-sensitive algorithms but only to
+marshal and unmarshal requests to the secure world. The wire format is
+implementation-defined.</p>
+
+<h2 id=compatibility_with_previous_versions>Compatibility with previous versions</h2>
+
+<p>The Keymaster v1.0 API is completely incompatible with the previously-released
+APIs, e.g. Keymaster v0.2 and v0.3.
+To facilitate interoperability on pre-Marshmallow devices that launched
+with the older Keymaster APIs, Keystore provides an adapter that provides
+the 1.0 API implemented with calls to the existing hardware library. The result
+cannot provide the full range of functionality in the
+1.0 API. In particular, it will only support RSA and ECDSA algorithms, and all
+of the key authorization enforcement will be performed by the adapter, in the
+non-secure world.</p>
diff --git a/src/devices/tech/security/authentication/km-features.jd b/src/devices/tech/security/authentication/km-features.jd
new file mode 100644
index 0000000..2b469c9
--- /dev/null
+++ b/src/devices/tech/security/authentication/km-features.jd
@@ -0,0 +1,412 @@
+page.title=Features
+@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>This page contains information about the features of <a href="keymaster.html">Keymaster</a> 1.0.</p>
+
+<h2 id=cryptographic_primitives>Cryptographic primitives</h2>
+
+<p>The <code>libkeymaster</code> library and Keymaster provide the following categories of operations:</p>
+
+<ul>
+ <li>Key generation
+ <li>Import and export of asymmetric keys (no key wrapping)
+ <li>Import of raw symmetric keys (again, no wrapping)
+ <li>Asymmetric encryption and decryption with appropriate padding modes
+ <li>Asymmetric signing and verification with digesting and appropriate padding
+modes
+ <li>Symmetric encryption and decryption in appropriate modes, including an AEAD
+mode
+ <li>Generation and verification of symmetric message authentication codes
+</ul>
+
+<p>Within each category, <code>libkeymaster</code> provides a mechanism for
+discovering the available options (algorithms,
+modes, etc.). But we also specify at least one required option, to ensure that
+client software can depend on the presence of the required primitives.</p>
+
+<p>Protocol elements, such as purpose, mode and padding, as well
+as <a href="#key_access_control">access control constraints</a>,
+must be specified when keys are generated or imported and are permanently
+bound to the key, ensuring the key cannot be used in any other way.</p>
+
+<p>In addition to the list above, there is one more service that Keymaster
+implementations must provide but which is not exposed as an API: Random number
+generation. This is used internally for generation of keys, Initialization
+Vectors (IVs), random padding and other elements of secure protocols that
+require randomness.</p>
+
+<h2 id=required_primitives>Required primitives</h2>
+
+<p>All implementations must provide:</p>
+
+<ul>
+ <li><a href="http://en.wikipedia.org/wiki/RSA_(cryptosystem)">RSA</a>
+ <ul>
+ <li>2048, 3072 and 4096-bit key support are required
+ <li>Support for public exponent F4 (2^16+1)
+ <li>Required padding modes for RSA signing are:
+ <ul>
+ <li>No padding (deprecated, will be removed in the future)
+ <li>RSASSA-PSS (<code>KM_PAD_RSA_PSS</code>)
+ <li>RSASSA-PKCS1-v1_5 (<code>KM_PAD_RSA_PKCS1_1_5_SIGN</code>)
+ </ul>
+ <li>Required digest modes for RSA signing are:
+ <ul>
+ <li>No digest (deprecated, will be removed in the future)
+ <li>SHA-256
+ </ul>
+ <li>Required padding modes for RSA encryption/decryption are:
+ <ul>
+ <li>RSAES-OAEP (<code>KM_PAD_RSA_OAEP</code>)
+ <li>RSAES-PKCS1-v1_5 (<code>KM_PAD_RSA_PKCS1_1_5_ENCRYPT</code>)
+ </ul>
+ <li>Unpadded RSA encryption must not be supported
+ </ul>
+ <li><a href="http://en.wikipedia.org/wiki/Elliptic_Curve_DSA">ECDSA</a>
+ <ul>
+ <li>224, 256, 384 and 521-bit key support are required, using the NIST P-224,
+P-256, P-384 and P-521 curves, respectively
+ <li>Required digest modes for ECDSA are:
+ <ul>
+ <li>No digest (deprecated, will be removed in the future)
+ <li>SHA-256
+ </ul>
+ </ul>
+ <li><a href="http://en.wikipedia.org/wiki/Advanced_Encryption_Standard">AES</a>
+ <ul>
+ <li>128 and 256-bit keys are required
+ <li><a href="http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher-block_chaining_.28CBC.29">CBC</a>,
+ CTR, ECB and and GCM. The GCM implementation must not allow the use of tags
+smaller than 96 bits or nonce lengths other than 96 bits.
+ <li>Padding modes <code>KM_PAD_NONE</code> and <code>KM_PAD_PKCS7</code> must
+ be supported for CBC and ECB modes. With no padding, CBC or ECB mode
+encryption must fail if the input isn't a multiple of the block size.
+ </ul>
+ <li><a href="http://en.wikipedia.org/wiki/Hash-based_message_authentication_code">HMAC</a>
+ <a href="http://en.wikipedia.org/wiki/SHA-2">SHA-256</a>, with any key size up to at least 32 bytes.
+</ul>
+</ul>
+
+<p>SHA1 and the other members of the SHA2 family (SHA-224, SHA384 and SHA512) are
+strongly recommended, but not required. Keystore will provide them in software
+if the hardware Keymaster implementation doesn't provide them.</p>
+
+<p>Some primitives are also recommended for interoperability with other systems:</p>
+
+<ul>
+ <li>Smaller key sizes for RSA
+ <li>Arbitrary public exponents for RSA
+</ul>
+
+<h2 id=key_access_control>Key access control</h2>
+
+<p>Hardware-based keys that can never be extracted from the device don't provide
+much security if an attacker can use them at will (though they're more secure
+than keys which <em>can</em> be exfiltrated). Thus, it's crucial that Keymaster enforce access controls.</p>
+
+<p>Access controls are defined as an "authorization list" of tag/value pairs.
+Authorization tags are 32-bit integers and the values are a variety of types.
+Some tags may be repeated to specify multiple values. Whether a tag may be
+repeated is specified in the documentation for the tag. When a key is created,
+the caller specifies an authorization list. The Keymaster implementation will
+modify the list to specify some additional information, such as whether the key
+has rollback protection, and return a "final" authorization list, encoded into
+the returned key blob. Any attempt to use the key for any cryptographic
+operation must fail if the final authorization list is modified.</p>
+
+<p>The set of possible tags is defined in the enumeration <code>keymaster_authorization_tag_t</code> and
+the set must be permanently fixed (though it can be extended).
+Names are prefixed with <code>KM_TAG_</code>. The top
+four bits of tag IDs are used to indicate the type.</p>
+
+<p>Possible types include:</p>
+
+<p><strong><code>KM_ENUM</code>:</strong> Many tags' values are defined in enumerations. For example, the possible
+values of <code>KM_TAG_PURPOSE</code> are defined in enum <code>keymaster_purpose_t</code>.</p>
+
+<p><strong><code>KM_ENUM_REP</code></strong>: Same as <code>KM_ENUM</code>, except that the tag may
+be repeated in an authorization list. Repetition
+indicates multiple authorized values. For example, an encryption key will
+likely have <code>KM_PURPOSE_ENCRYPT</code> and <code>KM_PURPOSE_DECRYPT</code>.</p>
+
+<p><strong><code>KM_UINT</code>:</strong> 32-bit unsigned integers. Example: <code>KM_TAG_KEY_SIZE</code></p>
+
+<p><strong><code>KM_UINT_REP</code></strong>: Same as <code>KM_UINT</code>, except that the tag may be
+repeated in an authorization list. Repetition indicates multiple authorized values.</p>
+
+<p><strong><code>KM_ULONG</code></strong>: 64-bit unsigned integers. Example: <code>KM_TAG_RSA_PUBLIC_EXPONENT</code></p>
+
+<p><strong><code>KM_ULONG_REP</code></strong>: Same as <code>KM_ULONG</code>, except that the tag may be
+repeated in an authorization list. Repetition
+indicates multiple authorized values.</p>
+
+<p><strong><code>KM_DATE</code></strong>: Date/time values, expressed as milliseconds since January 1, 1970.
+Example: <code>KM_TAG_PRIVKEY_EXPIRE_DATETIME</code></p>
+
+<p><strong><code>KM_BOOL</code></strong>: True or false. A tag of type <code>KM_BOOL</code> is assumed
+to be "false" if the tag is not present and "true" if present. Example: <code>KM_TAG_ROLLBACK_RESISTANT</code></p>
+
+<p><strong><code>KM_BIGNUM</code></strong>: Arbitrary-length integers, expressed as a byte array
+in big-endian order. Example: <code>KM_TAG_RSA_PUBLIC_EXPONENT</code></p>
+
+<p><strong><code>KM_BYTES</code></strong>: A sequence of bytes. Example: <code>KM_TAG_ROOT_OF_TRUST</code></p>
+
+<h3 id=hardware_vs_software_enforcement>Hardware vs. software enforcement</h3>
+
+<p>Not all Keymaster implementations will implement the same features. To support
+a variety of approaches, Keymaster 1.0 distinguishes between secure and
+non-secure world access control enforcement, which we call hardware and
+software enforcement, respectively.</p>
+
+<p>Implementations are required to:</p>
+
+<ul>
+ <li>Enforce exact matching (not enforcement) of all authorizations. Authorization
+lists in key blobs must exactly match the authorizations returned during key
+generation, including ordering. Any mismatch must cause an error diagnostic.
+ <li>Declare the authorizations whose semantic values are enforced.
+</ul>
+
+<p>The API mechanism for declaring hardware-enforced authorizations is in
+the <code>keymaster_key_characteristics_t</code> structure. It divides the authorization
+list into two sub-lists, <code>hw_enforced</code> and <code>sw_enforced</code>. The
+Keymaster implementation is responsible for placing the appropriate
+values in each, based on what it can enforce.</p>
+
+<p>In addition, the keystore daemon will implement software-based enforcement of <em>all</em> authorizations,
+whether they're enforced in hardware or not.</p>
+
+<p>For example, consider a TrustZone-based implementation that does not support
+key expiration. A key with an expiration date may still be created. That key's
+authorization list will include the tag <code>KM_TAG_ORIGINATION_EXPIRE_DATETIME</code> with
+the expiration date. A request to Keymaster for the key characteristics
+will find this tag in the <code>sw_enforced</code> list and the Keymaster implementation will
+not enforce the expiration
+requirement. However, attempts to use the key after expiration will be rejected
+by the keystore daemon.</p>
+
+<p>If the device is then upgraded with a Keymaster implementation that does
+support expiration, then a request for key characteristics will
+find <code>KM_TAG_ORIGINATION_EXPIRE_DATETIME</code> in
+the <code>hw_enforced</code> list, and attempts to use the key after expiration will fail even if the
+keystore is somehow subverted or bypassed.</p>
+
+<h3 id=cryptographic_message_construction_authorizations>Cryptographic message construction authorizations</h3>
+
+<p>The following tags are used to define the cryptographic characteristics of
+operations using the associated key: <code>KM_TAG_ALGORITHM</code>, <code>KM_TAG_KEY_SIZE</code>,
+<code>KM_TAG_BLOCK_MODE</code>, <code>KM_TAG_PADDING</code>, <code>KM_TAG_CALLER_NONCE</code>, and <code>KM_TAG_DIGEST</code></p>
+
+<p><code>KM_TAG_PADDING</code>, <code>KM_TAG_DIGEST</code>, and <code>KM_PAD_BLOCK_MODE</code>
+are repeatable, meaning that multiple values may be associated with a single
+key, and the value to be used will be specified at operation time.</p>
+
+<h3 id=purpose>Purpose</h3>
+
+<p>Keys have an associated set of purposes, expressed as one or more authorization
+entries with tag <code>KM_TAG_PURPOSE</code>, which defines how they can be used. The purposes are:</p>
+
+<ul>
+ <li><code>KM_PURPOSE_ENCRYPT</code>
+ <li><code>KM_PURPOSE_DECRYPT</code>
+ <li><code>KM_PURPOSE_SIGN</code>
+ <li><code>KM_PURPOSE_VERIFY</code>
+</ul>
+
+<p>Any key can have any subset of these purposes. Note that some combinations
+create security problems. For example, an RSA key that can be used to both
+encrypt and to sign allows an attacker who can convince the system to decrypt
+arbitrary data to generate signatures.</p>
+
+<p>Other purposes for keys that may be added in the future include:</p>
+
+<ul>
+ <li>"Derive Key" purpose, for key derivation keys
+ <li>"Attest" purpose, for keys that can generate attestations of the Keymaster
+implementation and/or its environment
+ <li>"Wrap Key" purpose, for keys used to wrap keys for secure import or export
+</ul>
+
+<h3 id=import_and_export>Import and export</h3>
+
+<p>Keymaster supports export of public keys only, in X.509 format, and import of:</p>
+
+<ul>
+ <li>Public and private key pairs in DER-encoded PKCS#8 format, without
+password-based encryption, and
+ <li>Symmetric keys as raw bytes
+</ul>
+
+<p>Future versions will likely expand the import/export options.</p>
+
+<p>To ensure that imported keys can be distinguished from securely-generated
+keys, <code>KM_TAG_ORIGIN</code> is included in the appropriate key
+authorization list. For example, if a key
+was generated in secure hardware, <code>KM_TAG_ORIGIN</code> with
+value <code>KM_ORIGIN_GENERATED</code> will be found in
+the <code>hw_enforced</code> list of the key characteristics, while a key
+that was imported into secure
+hardware will have the value <code>KM_ORIGIN_IMPORTED</code>.</p>
+
+<h3 id=user_authentication>User authentication</h3>
+
+<p>Keymaster does not implement user authentication, but depends on other trusted
+apps which do. For the interface that must be implemented by these apps, see
+the Gatekeeper page.</p>
+
+<p>User authentication requirements are specified via two sets of tags. The first
+set indicate which user can use the key:</p>
+
+<ul>
+ <li><code>KM_TAG_ALL_USERS</code> indicates the key is usable by all users. If
+ present, <code>KM_TAG_USER_ID</code> and <code>KM_TAG_SECURE_USER_ID</code> must not be present.
+ <li><code>KM_TAG_USER_ID</code> has a numeric value specifying the ID of the authorized user.
+ Note that this
+is the Android user ID (for multi-user), not the application UID, and it is
+enforced by non-secure software only. If present, <code>KM_TAG_ALL_USERS</code> must not be present.
+ <li><code>KM_TAG_SECURE_USER_ID</code> has a 64-bit numeric value specifying the secure user ID
+ that must be provided
+in a secure authentication token to unlock use of the key. If repeated, the key
+may be used if any of the values is provided in a secure authentication token.
+</ul>
+
+<p>The second set indicate whether and when the user must be authenticated. If
+neither of these tags is present, but <code>KM_TAG_SECURE_USER_ID</code> is, authentication is
+required for every use of the key.</p>
+
+<ul>
+ <li><code>KM_NO_AUTHENTICATION_REQUIRED</code> indicates no user authentication is required, though
+ the key still may only be
+used by apps running as the user(s) specified by <code>KM_TAG_USER_ID</code>.
+ <li><code>KM_TAG_AUTH_TIMEOUT</code> is a numeric value specifying, in seconds, how fresh the user
+ authentication
+must be to authorize key usage. This applies only to private/secret key
+operations. Public key operations don't require authentication. Timeouts do not
+cross reboots; after a reboot, all keys are "never authenticated." The timeout
+may be set to a large value to indicate that authentication is required once
+per boot (2^32 seconds is ~136 years; presumably Android devices are rebooted
+more often than that).
+</ul>
+
+<h3 id=client_binding>Client binding</h3>
+
+<p>Client binding, the association of a key with a particular client application,
+is done via an optional client ID and some optional client data (<code>KM_TAG_APPLICATION_ID</code>
+and <code>KM_TAG_APPLICATION_DATA</code>, respectively). Keymaster treats these values as opaque blobs,
+only ensuring
+that the same blobs presented during key generation/import are presented for
+every use and are byte-for-byte identical. The client binding data is not
+returned by Keymaster. The caller must know it in order to use the key.</p>
+
+<h3 id=expiration>Expiration</h3>
+
+<p>Keymaster supports restricting key usage by date. Key start of validity and key
+expirations can be associated with a key and Keymaster will refuse to perform
+key operations if the current date/time is outside of the valid range. The key
+validity range is specified with the tags <code>KM_TAG_ACTIVE_DATETIME</code>,
+<code>KM_TAG_ORIGINATION_EXPIRE_DATETIME</code>, and <code>KM_TAG_USAGE_EXPIRE_DATETIME</code>.
+The distinction between "origination" and "usage" is based on whether the key
+is being used to "originate" a new ciphertext/signature/etc., or to "use" an
+existing ciphertext/signature/etc.</p>
+
+<p>The <code>KM_TAG_ACTIVE_DATETIME</code>, <code>KM_TAG_ORIGINATION_EXPIRE_DATETIME</code>,
+and <code>KM_TAG_USAGE_EXPIRE_DATETIME</code> tags are optional. If the tags are absent, it is
+assumed that the key in
+question can always be used to decrypt/verify messages.</p>
+
+<p>Because wall-clock time is provided by the non-secure world, it's unlikely that
+the expiration-related tags will be in the hardware-enforced list. Hardware
+enforcement of expiry would require that the secure world somehow obtain
+trusted time and data, for example via a challenge response protocol with a
+trusted remote timeserver.</p>
+
+<h3 id=root_of_trust_binding>Root of trust binding</h3>
+
+<p>Keymaster allows keys to be bound to a root of trust, which is a bitstring
+provided to Keymaster during startup, preferably by the bootloader. If
+provided, this bitstring must be cryptographically bound to every key managed
+by Keymaster.</p>
+
+<p>The intent is for the bootloader to pass in the public key, used to verify the
+signature on the boot image, along with the verified boot state (locked or
+unlocked). If the public key is changed to allow a different system image to be
+used or if the verified boot state is changed, then none of the
+Keymaster-protected keys created by the previous system will be usable, unless
+the previous root of trust is restored and a system that is signed by that key
+is booted. The goal is to increase the value of the software-enforced key
+access controls by making it imposSTEM</code>sible for an attacker-installed operating
+system to use Keymaster keys.</p>
+
+<h3 id=standalone_keys>Standalone keys</h3>
+
+<p>Some Keymaster implementations may choose to store key material internally and
+return handles rather than encrypted key material. Or there may be other cases
+in which keys cannot be used until some other non-secure or secure world system
+component is available. The Keymaster 1.0 API allows the caller to request that
+a key be "standalone," via the <code>KM_TAG_STANDALONE</code> tag,
+meaning that no resources other than the blob and the running Keymaster
+system are required. The tags associated with a key may be inspected to see
+whether a key is standalone. At present, only two values are defined:</p>
+
+<ul>
+ <li><code>KM_BLOB_STANDALONE</code>
+ <li><code>KM_BLOB_REQUIRES_FILE_SYSTEM</code>
+</ul>
+
+<h3 id=velocity>Velocity</h3>
+
+<p>When it's created, the maximum usage velocity can be specified
+with <code>KM_TAG_MIN_SECONDS_BETWEEN_OPS</code>.
+TrustZone implementations will refuse to perform cryptographic operations
+with that key if an operation was performed less
+than <code>KM_TAG_MIN_SECONDS_BETWEEN_OPS</code> seconds earlier.</p>
+
+<p>The simple approach to implementing velocity limits is a table of key IDs and
+last-use timestamps. This table will likely be of limited size, but must
+accommodate at least 16 entries. In the event that the table is full and no
+entries may be updated or discarded, Keymaster implementations must "fail
+safe," preferring to refuse all velocity-limited key operations until one of
+the entries expires. It is acceptable for all entries to expire upon reboot.</p>
+
+<p>Keys can also be limited to <em>n</em> uses per boot with <code>KM_TAG_USES_PER_BOOT</code>.
+This also requires a tracking table, which must accommodate at least four
+keys, and must also fail safe. Note that applications will be unable to create
+per-boot limited keys. This feature will not be exposed through keystore and
+will be reserved for system operations.</p>
+
+<h3 id=random_number_generator_re-seeding>Random number generator re-seeding</h3>
+
+<p>Because Keymaster must generate random numbers for key material and
+Initialization Vectors (IVs), and because hardware random number generators may
+not always be fully trustworthy, Keymaster provides an interface to allow the
+client to provide additional entropy which will be mixed into the random
+numbers generated.</p>
+
+<p>A hardware random-number generator should be used as the primary seed source,
+if available, and the seed data provided through the external API must not be
+the sole source of randomness used for number generation. Further, the mixing
+operation used must ensure that the random output is unpredictable if any one
+of the seed sources is unpredictable.</p>
diff --git a/src/devices/tech/security/authentication/km-implementer-ref.jd b/src/devices/tech/security/authentication/km-implementer-ref.jd
new file mode 100644
index 0000000..9c8c619
--- /dev/null
+++ b/src/devices/tech/security/authentication/km-implementer-ref.jd
@@ -0,0 +1,1229 @@
+page.title=Implementer's Reference
+@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>This page provides details to assist implementers of <a href="keymaster.html">Keymaster</a> HALs. It
+covers each tag and each function in the API.</p>
+
+<h2 id=authorization_tags>Authorization tags</h2>
+
+<p>Except as noted in the tag descriptions, all of the tags below are used during
+key generation to specify key characteristics.</p>
+
+<h3 id=km_tag_purpose>KM_TAG_PURPOSE</h3>
+
+<p>Specifies the set of purposes for which the key may be used.</p>
+
+<p>Possible values are defined by the following enumeration:</p>
+
+<pre>
+typedef enum {
+ KM_PURPOSE_ENCRYPT = 0,
+ KM_PURPOSE_DECRYPT = 1,
+ KM_PURPOSE_SIGN = 2,
+ KM_PURPOSE_VERIFY = 3,
+} keymaster_purpose_t;
+</pre>
+
+<p>This tag is repeatable; keys may be generated with multiple values, although an
+operation has a single purpose. When the <a href="#begin">begin</a> function is called to
+start an operation, the purpose of the operation is
+specified. If the purpose specified to the operation is not authorized by the
+key, the operation must fail with <code>KM_ERROR_INCOMPATIBLE_PURPOSE</code>.</p>
+
+<h3 id=km_tag_algorithm>KM_TAG_ALGORITHM</h3>
+
+<p>Specifies the cryptographic algorithm with which the key is used.</p>
+
+<p>Possible values are defined by the following enumeration:</p>
+
+<pre>
+typedef enum {
+ KM_ALGORITHM_RSA = 1,
+ KM_ALGORITHM_EC = 3,
+ KM_ALGORITHM_AES = 32,
+ KM_ALGORITHM_HMAC = 128,
+} keymaster_algorithm_t;
+</pre>
+
+<p>This tag is not repeatable.</p>
+
+<h3 id=km_tag_key_size>KM_TAG_KEY_SIZE</h3>
+
+<p>Specifies the size, in bits, of the key, measuring in the normal way for the
+key's algorithm. For example, for RSA keys, <code>KM_TAG_KEY_SIZE</code> specifies
+the size of the public modulus. For AES keys it specifies the length
+of the secret key material.</p>
+
+<p>This tag is not repeatable.</p>
+
+<h3 id=km_tag_block_mode>KM_TAG_BLOCK_MODE</h3>
+
+<p>Specifies the block cipher mode(s) with which the key may be used. This tag is
+only relevant to AES keys.</p>
+
+<p>Possible values are defined by the following enumeration:</p>
+
+<pre>
+typedef enum {
+ KM_MODE_ECB = 1,
+ KM_MODE_CBC = 2,
+ KM_MODE_CTR = 3,
+ KM_MODE_GCM = 32,
+} keymaster_block_mode_t;
+</pre>
+
+<p>This tag is repeatable, and for AES key operations a mode must be specified in
+the <code>additional_params</code> argument of <a href="#begin">begin</a>. If the specified
+mode is not in the modes associated with the key, the
+operation must fail with <code>KM_ERROR_INCOMPATIBLE_BLOCK_MODE</code>.</p>
+
+<h3 id=km_tag_digest>KM_TAG_DIGEST</h3>
+
+<p>Specifies the digest algorithms which may be used with the key to perform
+signing and verification operations. This tag is relevant to RSA, ECDSA and
+HMAC keys.</p>
+
+<p>Possible values are defined by the following enumeration:</p>
+
+<pre>
+typedef enum {
+ KM_DIGEST_NONE = 0,
+ KM_DIGEST_MD5 = 1,
+ KM_DIGEST_SHA1 = 2,
+ KM_DIGEST_SHA_2_224 = 3,
+ KM_DIGEST_SHA_2_256 = 4,
+ KM_DIGEST_SHA_2_384 = 5,
+ KM_DIGEST_SHA_2_512 = 6,
+}
+keymaster_digest_t;
+</pre>
+
+<p>This tag is repeatable. For signing and verification operations a digest must
+be specified in the <code>additional_params</code> argument of <a href="#begin">begin</a>.
+If the specified digest is not in the digests associated with the key, the
+operation must fail with <code>KM_ERROR_INCOMPATIBLE_DIGEST</code>.</p>
+
+<h3 id=km_tag_padding>KM_TAG_PADDING</h3>
+
+<p>Specifies the padding modes which may be used with the key. This tag is
+relevant to RSA and AES keys.</p>
+
+<p>Possible values are defined by the following enumeration:</p>
+
+<pre>
+typedef enum {
+ KM_PAD_NONE = 1,
+ KM_PAD_RSA_OAEP = 2,
+ KM_PAD_RSA_PSS = 3,
+ KM_PAD_RSA_PKCS1_1_5_ENCRYPT = 4,
+ KM_PAD_RSA_PKCS1_1_5_SIGN = 5,
+ KM_PAD_PKCS7 = 64,
+} keymaster_padding_t;
+</pre>
+
+<p><code>KM_PAD_RSA_OAEP</code> and <code>KM_PAD_RSA_PKCS1_1_5_ENCRYPT</code> are used
+only for RSA encryption/decryption keys and specify RSA PKCS#1v2 OAEP
+padding and RSA PKCS#1 v1.5 randomized padding, respectively. <code>KM_PAD_RSA_PSS</code> and
+<code>KM_PAD_RSA_PKCS1_1_5_SIGN</code> are used only for RSA signing/verification keys and
+specify RSA PKCS#1v2 PSS
+padding and RSA PKCS#1 v1.5 deterministic padding, respectively. Note also that
+the RSA PSS padding mode is incompatible with <a href="#km_tag_digest">KM_DIGEST_NONE</a>.</p>
+
+<p><code>KM_PAD_NONE</code> may be used with either RSA or AES keys. For AES keys,
+if <code>KM_PAD_NONE</code> is used with block mode ECB or CBC and the data to be encrypted
+or decrypted
+is not a multiple of the AES block size in length, the call to finish must fail
+with <code>KM_ERROR_INVALID_INPUT_LENGTH</code>.</p>
+
+<p><code>KM_PAD_PKCS7</code> may only be used with AES keys, and only with ECB and CBC modes.</p>
+
+<p>This tag is repeatable. A padding mode must be specified in the call to
+<a href="#begin">begin</a>. If the specified mode is not authorized for the key,
+the operation must fail
+with <code>KM_ERROR_INCOMPATIBLE_BLOCK_MODE</code>.</p>
+
+<h3 id=km_tag_caller_nonce>KM_TAG_CALLER_NONCE</h3>
+
+<p>Specifies that the caller is allowed to provide a nonce for nonce-requiring
+operations.</p>
+
+<p>This tag is boolean, so the possible values are true (if the tag is present)
+and false (if the tag is not present).</p>
+
+<p>This tag is used only for AES keys, and is only relevant for CBC, CTR and GCM
+block modes. If the tag is not present, implementations should reject any
+operation which provides <a href="#km_tag_nonce">KM_TAG_NONCE</a> to <a href="#begin">begin</a>
+with <code>KM_ERROR_CALLER_NONCE_PROHIBITED</code>.</p>
+
+<p>This tag is not repeatable.</p>
+
+<h3 id=km_tag_min_mac_length>KM_TAG_MIN_MAC_LENGTH</h3>
+
+<p>Required for HMAC keys and AES keys that support GCM mode, this tag specifies
+the minimum length of MAC that can be requested or verified with this key.</p>
+
+<p>This value is the minimum MAC length, in bits. It must be a multiple of 8. For
+HMAC keys, the value must be at least 64. For GCM keys it must be at least 96
+and must not exceed 128.</p>
+
+<h3 id=km_tag_rsa_public_exponent>KM_TAG_RSA_PUBLIC_EXPONENT</h3>
+
+<p>Specifies the value of the public exponent for an RSA key pair. This tag is
+relevant only to RSA keys, and required for all RSA keys.</p>
+
+<p>The value is a 64-bit unsigned integer that must satisfy the requirements of an
+RSA public exponent. Because it is specified by the caller and therefore cannot
+be chosen by the implementation, it must be a prime number. Trustlets are
+required to support the value 2^16+1. It is recommended that other reasonable
+values be supported, in particular the value 3. If no exponent is specified or
+if the specified exponent is not supported, key generation must fail
+with <code>KM_ERROR_INVALID_ARGUMENT</code>.</p>
+
+<p>This tag is not repeatable.</p>
+
+<h3 id=km_tag_blob_usage_requirements>KM_TAG_BLOB_USAGE_REQUIREMENTS</h3>
+
+<p>Specifies the system environment conditions which must hold for the generated
+key to be used.</p>
+
+<p>Possible values are defined by the following enumeration:</p>
+
+<pre>
+typedef enum {
+ KM_BLOB_STANDALONE = 0,
+ KM_BLOB_REQUIRES_FILE_SYSTEM = 1,
+} keymaster_key_blob_usage_requirements_t;
+</pre>
+
+<p>This tag may be specified during key generation to require that the key be
+usable in the specified condition, and must be returned with the key
+characteristics (from <a href="#generate_key">generate_key</a> and
+<a href="#get_key_characteristics">get_key_characteristics</a>). If
+the caller specifies <code>KM_TAG_BLOB_USAGE_REQUIREMENTS</code> with
+value <code>KM_BLOB_STANDALONE</code> the trustlet must return a key blob
+which can be used without file system
+support. This is critical for devices with encrypted disks, where the file
+system may not be available until after a Keymaster key is used to decrypt the
+disk.</p>
+
+<p>This tag is not repeatable.</p>
+
+<h3 id=km_tag_bootloader_only>KM_TAG_BOOTLOADER_ONLY</h3>
+
+<p>Specifies that the key may only be used by the bootloader.</p>
+
+<p>This tag is boolean, so the possible values are true (if the tag is present)
+and false (if the tag is not present).</p>
+
+<p>Any attempt to use a key with <code>KM_TAG_BOOTLOADER_ONLY</code> from the
+Android system must fail with <code>KM_ERROR_INVALID_KEY_BLOB</code>.</p>
+
+<p>This tag is not repeatable.</p>
+
+<h3 id=km_tag_active_datetime>KM_TAG_ACTIVE_DATETIME</h3>
+
+<p>Specifies the date and time at which the key becomes active. Prior to this
+time, any attempt to use the key must fail with <code>KM_ERROR_KEY_NOT_YET_VALID</code>.</p>
+
+<p>The value is a 64-bit integer representing milliseconds since January 1, 1970.</p>
+
+<p>This tag is not repeatable.</p>
+
+<h3 id=km_tag_origination_expire_datetime>KM_TAG_ORIGINATION_EXPIRE_DATETIME</h3>
+
+<p>Specifies the date and time at which the key expires for signing and encryption
+purposes. After this time, any attempt to use a key
+with <a href="#km_tag_purpose">KM_PURPOSE_SIGN</a> or
+<a href="#km_tag_purpose">KM_PURPOSE_ENCRYPT</a> provided
+to <a href="#begin">begin</a> must fail with <code>KM_ERROR_KEY_EXPIRED</code>.</p>
+
+<p>The value is a 64-bit integer representing milliseconds since January 1, 1970.</p>
+
+<p>This tag is not repeatable.</p>
+
+<h3 id=km_tag_usage_expire_datetime>KM_TAG_USAGE_EXPIRE_DATETIME</h3>
+
+<p>Specifies the date and time at which the key expires for verification and
+decryption purposes. After this time, any attempt to use a key with
+<a href="#km_tag_purpose">KM_PURPOSE_VERIFY</a> or <a href="#km_tag_purpose">KM_PURPOSE DECRYPT</a>
+provided to <a href="#begin">begin</a> must fail with <code>KM_ERROR_KEY_EXPIRED</code>.</p>
+
+<p>The value is a 64-bit integer representing milliseconds since January 1, 1970.</p>
+
+<p>This tag is not repeatable.</p>
+
+<h3 id=km_tag_min_seconds_between_ops>KM_TAG_MIN_SECONDS_BETWEEN_OPS</h3>
+
+<p>Specifies the minimum amount of time that must elapse between allowed
+operations using a key. This can be used to rate-limit uses of keys in contexts
+where unlimited use may enable brute force attacks.</p>
+
+<p>The value is a 32-bit integer representing seconds between allowed operations.</p>
+
+<p>When a key with this tag is used in an operation, a timer should be started
+during the <a href="#finish">finish</a> or <a href="#abort">abort</a> call. Any
+call to <a href="#begin">begin</a> that is received before the timer indicates
+that the interval specified by <code>KM_TAG_MIN_SECONDS_BETWEEN_OPS</code> has
+elapsed must fail with <code>KM_ERROR_KEY_RATE_LIMIT_EXCEEDED</code>. This
+requirement implies that a trustlet must keep a table of timers for keys
+with this tag. Because Keymaster memory is often limited, it is acceptable for
+this table to have a fixed maximum size and for Keymaster to fail operations
+which attempt to use keys with this tag when the table is full. At least 32
+in-use keys must be accommodated, and table slots must be aggressively reused
+when key minimum-usage intervals expire. If an operation fails because the
+table is full, Keymaster should return <code>KM_ERROR_TOO_MANY_OPERATIONS</code>.</p>
+
+<p>This tag is not repeatable.</p>
+
+<h3 id=km_tag_max_uses_per_boot>KM_TAG_MAX_USES_PER_BOOT</h3>
+
+<p>Specifies the maximum number of times that a key may be used between system
+reboots. This is another mechanism to rate-limit key use.</p>
+
+<p>The value is a 32-bit integer representing uses per boot.</p>
+
+<p>When a key with this tag is used in an operation, a key-associated counter
+should be incremented during the <a href="#begin">begin</a> call. After the key counter
+has exceeded this value, all subsequent attempts
+to use the key must fail with <code>KM_ERROR_MAX_OPS_EXCEEDED</code>, until the device is
+restarted. This requirement implies that a trustlet must
+keep a table of use counters for keys with this tag. Because Keymaster memory
+is often limited, it is acceptable for this table to have a fixed maximum size
+and for Keymaster to fail operations that attempt to use keys with this tag
+when the table is full. At least 16 keys must be accommodated. If an operation
+fails because the table is full, Keymaster should return <code>KM_ERROR_TOO_MANY_OPERATIONS</code>.</p>
+
+<p>This tag is not repeatable.</p>
+
+<h3 id=km_tag_user_secure_id>KM_TAG_USER_SECURE_ID</h3>
+
+<p>Specifies that a key may only be used under a particular secure user
+authentication state. This tag is mutually exclusive
+with <a href="#km_tag_no_auth_required">KM_TAG_NO_AUTH_REQUIRED</a>.</p>
+
+<p>The value is a 64-bit integer specifying the authentication policy state value
+which must be present in an authentication token (provided to <a href="#begin">begin</a> with
+the <a href="#km_tag_auth_token">KM_TAG_AUTH_TOKEN</a>) to authorize use of the key. Any
+call to <a href="#begin">begin</a> with a key with this tag that does not provide an
+authentication token, or provides an
+authentication token without a matching policy state value, must fail.</p>
+
+<p>This tag is repeatable. If any of the provided values matches any policy state
+value in the authentication token, the key is authorized for use. Otherwise the operation
+must fail with <code>KM_ERROR_KEY_USER_NOT_AUTHENTICATED</code>.</p>
+
+<h3 id=km_tag_no_auth_required>KM_TAG_NO_AUTH_REQUIRED</h3>
+
+<p>Specifies that no authentication is required to use this key. This tag is
+mutually exclusive with <a href="#km_tag_user_secure_id">KM_TAG_USER_SECURE_ID</a>.</p>
+
+<p>This tag is boolean, so the possible values are true (if the tag is present)
+and false (if the tag is not present).</p>
+
+<p>This tag is not repeatable.</p>
+
+<h3 id=km_tag_user_auth_type>KM_TAG_USER_AUTH_TYPE</h3>
+
+<p>Specifies the types of user authenticators that may be used to authorize this
+key.</p>
+
+<p>The value is a 32-bit integer bitmask of values from the enumeration:</p>
+
+<pre>
+typedef enum {
+ HW_AUTH_NONE = 0,
+ HW_AUTH_PASSWORD = 1 << 0,
+ HW_AUTH_FINGERPRINT = 1 << 1,
+ // Additional entries should be powers of 2.
+ HW_AUTH_ANY = UINT32_MAX,
+} hw_authenticator_type_t;
+</pre>
+
+<p>This tag is not repeatable.</p>
+
+<h3 id=km_tag_auth_timeout>KM_TAG_AUTH_TIMEOUT</h3>
+
+<p>Specifies the time in seconds for which the key is authorized for use, after
+authentication. If <a href="#km_tag_user_secure_id">KM_TAG_USER_SECURE_ID</a> is present and this tag
+is not, then the key requires authentication for every
+usage (see <a href="#begin">begin</a> for the details of the authentication-per-operation flow).</p>
+
+<p>The value is a 32-bit integer specifying the time in seconds after a successful
+authentication of the user specified by <a href="#km_tag_user_secure_id">KM_TAG_USER_SECURE_ID</a> with
+the authentication method specified
+by <a href="#km_tag_mac_length">KM_TAG_USER_AUTH_TYPE</a> that the key can be used.</p>
+
+<p>This tag is not repeatable.</p>
+
+<h3 id=km_tag_all_applications>KM_TAG_ALL_APPLICATIONS</h3>
+
+<p>Reserved for future use.</p>
+
+<p>This tag is not repeatable.</p>
+
+<h3 id=km_tag_application_id>KM_TAG_APPLICATION_ID</h3>
+
+<p>When provided to <a href="#generate_key">generate_key</a> or <a href="#import_key">import_key</a>,
+this tag specifies data that must be provided during all uses of the key. In
+particular, calls to <a href="#export_key">export_key</a> and
+<a href="#get_key_characteristics">get_key_characteristics</a> must
+provide the same value in the <code>client_id</code> parameter, and
+calls to <a href="#begin">begin</a> must provide this tag and the
+same associated data as part of the <code>in_params</code> set. If the correct
+data is not provided the function must return <code>KM_ERROR_INVALID_KEY_BLOB</code>.</p>
+
+<p>The value is a blob, an arbitrary-length array of bytes.</p>
+
+<p>This tag is not repeatable.</p>
+
+<h3 id=km_tag_application_data>KM_TAG_APPLICATION_DATA</h3>
+
+<p>When provided to <a href="#generate_key">generate_key</a> or <a href="#import_key">import_key</a>,
+this tag specifies data that must be provided during all uses of the key. In
+particular, calls to <a href="#export_key">export_key</a> and
+<a href="#get_key_characteristics">get_key_characteristics</a> must
+provide the same value to the <code>client_id</code> parameter, and calls
+to <a href="#begin">begin</a> must provide this tag and the same associated
+data as part of the <code>in_params</code> set. If the correct data is not
+provided, the function must return <code>KM_ERROR_INVALID_KEY_BLOB</code>.</p>
+
+<p>This tag is not repeatable.</p>
+
+<h3 id=km_tag_creation_datetime>KM_TAG_CREATION_DATETIME</h3>
+
+<p>Specifies the date and time the key was created, in milliseconds since January
+1, 1970. This tag is optional and informational only.</p>
+
+<p>This tag is not repeatable.</p>
+
+<h3 id=km_tag_origin>KM_TAG_ORIGIN</h3>
+
+<p>Specifies where the key was created, if known. This tag may not be specified
+during key generation or import, and must be added to the key characteristics
+by the trustlet.</p>
+
+<p>The possible values are defined in <code>keymaster_origin_t</code>:</p>
+
+<pre>
+typedef enum {
+ KM_ORIGIN_GENERATED = 0,
+ KM_ORIGIN_IMPORTED = 2,
+ KM_ORIGIN_UNKNOWN = 3,
+} keymaster_key_origin_t
+</pre>
+
+<p>The full meaning of the value depends not only on the value but on whether it's
+found in the hardware-enforced or software-enforced characteristics list.</p>
+
+<p><code>KM_ORIGIN_GENERATED</code> indicates that Keymaster generated the key.
+If in the hardware-enforced list,
+the key was generated in secure hardware and is permanently hardware-bound. If
+in the software-enforced list, the key was generated in SoftKeymaster and is
+not hardware-bound.</p>
+
+<p><code>KM_ORIGIN_IMPORTED</code> indicates that the key was generated outside
+of Keymaster and imported into
+Keymaster. If in the hardware-enforced list, it is permanently hardware-bound,
+although copies outside of secure hardware may exist. If in the
+software-enforces list, the key was imported into SoftKeymaster and is not
+hardware-bound.</p>
+
+<p><code>KM_ORIGIN_UNKNOWN</code> should only appear in the hardware-enforced list.
+It indicates that the key is
+hardware-bound, but it is not known whether the key was originally generated in
+secure hardware or was imported. This only occurs when keymaster0 hardware is
+being used to emulate keymaster1 services.</p>
+
+<p>This tag is not repeatable.</p>
+
+<h3 id=km_tag_rollback_resistant>KM_TAG_ROLLBACK_RESISTANT</h3>
+
+<p>Indicates that the key is rollback-resistant, meaning that when deleted
+by <a href="#delete_key">delete_key</a> or <a href="#delete_all_keys">delete_all_keys</a>,
+the key is guaranteed to be permanently deleted and unusable. It's possible
+that keys without this tag could be deleted and then restored from backup.</p>
+
+<p>This tag is boolean, so the possible values are true (if the tag is present)
+and false (if the tag is not present).</p>
+
+<p>This tag is not repeatable.</p>
+
+<h3 id=km_tag_root_of_trust>KM_TAG_ROOT_OF_TRUST</h3>
+
+<p>Specifies the "root of trust," the key used by verified boot to validate the
+operating system booted (if any). This tag is never provided to or returned
+from Keymaster in the key characteristics.</p>
+
+<h3 id=km_tag_associated_data>KM_TAG_ASSOCIATED_DATA</h3>
+
+<p>Provides "associated data" for AES-GCM encryption or decryption. This tag is
+provided to <a href="#update">update</a> and specifies data that is not
+encrypted/decrypted but is used in computing
+the GCM tag.</p>
+
+<p>The value is a blob, an arbitrary-length array of bytes.</p>
+
+<p>This tag is not repeatable.</p>
+
+<h3 id=km_tag_nonce>KM_TAG_NONCE</h3>
+
+<p>Provides or returns a nonce or Initialization Vector (IV) for AES GCM, CBC or
+CTR encryption or decryption. This tag is provided to <a href="#begin">begin</a>
+during encryption and decryption operations. It may only be provided to <a href="#begin">begin</a>
+if the key has <a href="#km_tag_caller_nonce">KM_TAG_CALLER_NONCE</a>. If not provided,
+an appropriate nonce or IV will be randomly generated by
+Keymaster and returned from begin.</p>
+
+<p>The value is a blob, an arbitrary-length array of bytes. Allowed lengths depend
+on the mode: GCM nonces are 12 bytes in length; CBC and CTR IVs are 16 bytes in
+length.</p>
+
+<p>This tag is not repeatable.</p>
+
+<h3 id=km_tag_auth_token>KM_TAG_AUTH_TOKEN</h3>
+
+<p>Provides an authentication token (see the Authentication page) to
+<a href="#begin">begin</a>, <a href="#update">update</a> or <a href="#finish">finish</a>,
+to prove user authentication for a key operation that requires
+it (key has <a href="#km_tag_user_secure_id">KM_TAG_USER_SECURE_ID</a>).</p>
+
+<p>The value is a blob which contains a <code>hw_auth_token_t</code> structure.</p>
+
+<p>This tag is not repeatable.</p>
+
+<h3 id=km_tag_mac_length>KM_TAG_MAC_LENGTH</h3>
+
+<p>Provides the requested length of a MAC or GCM authentication tag, in bits.</p>
+
+<p>The value is the MAC length in bits. It must be a multiple of 8 and must be at
+least as large as the value of <a href="#km_tag_min_mac_length">KM_TAG_MIN_MAC_LENGTH</a>
+associated with the key.</p>
+
+<h2 id=functions>Functions</h2>
+
+<h3 id=deprecated_functions>Deprecated functions</h3>
+
+<p>The following functions are in the <code>keymaster1_device_t</code> definition but
+should not be implemented. The function pointers should be set
+to <code>NULL</code>:</p>
+
+<ul>
+ <li><code>generate_keypair</code>
+ <li><code>import_keypair</code>
+ <li><code>get_keypair_public</code>
+ <li><code>delete_keypair</code>
+ <li><code>delete_all</code>
+ <li><code>sign_data</code>
+ <li><code>verify_data</code>
+</ul>
+
+<h3 id=general_implementation_guidelines>General implementation guidelines</h3>
+
+<p>The following guidelines apply to all functions in the API.</p>
+
+<h4 id=input_pointer_parameters>Input pointer parameters</h4>
+
+<p>Input pointer parameters that are not used for a given call may be <code>NULL</code>.
+The caller is not required to provide placeholders. For example, some key
+types and modes may not use any values from the <code>in_params</code> argument
+to <a href="#begin">begin</a>, so the caller may set <code>in_params</code>
+to <code>NULL</code> or provide an empty parameter set. It is also acceptable for the caller to
+provide unused parameters, and Keymaster methods should not issue errors.</p>
+
+<p>If a required input parameter is NULL, Keymaster methods should return
+<code>KM_ERROR_UNEXPECTED_NULL_POINTER</code>.</p>
+
+<h4 id=output_pointer_parameters>Output pointer parameters</h4>
+
+<p>Similar to input pointer parameters, unused output pointer parameters
+may be <code>NULL</code>. If a method needs to return data in an output
+parameter found to be <code>NULL</code>, it should return <code>KM_ERROR_OUTPUT_PARAMETER_NULL</code>.</p>
+
+<h4 id=api_misuse>API misuse</h4>
+
+<p>There are many ways that callers can make requests that don't make sense or are
+foolish but not technically wrong. Keymaster1 implementations are not required
+to fail in such cases or issue a diagnostic. Use of too-small keys,
+specification of irrelevant input parameters, reuse of IVs or nonces,
+generation of keys with no purposes (hence useless) and the like should not be
+diagnosed by implementations. Omission of required parameters, specification of
+invalid required parameters, and similar errors must be diagnosed.</p>
+
+<p>It is the responsibility of apps, the framework, and Android keystore to ensure
+that the calls to Keymaster modules are sensible and useful.</p>
+
+<h3 id=get_supported_algorithms>get_supported_algorithms</h3>
+
+<p>Returns the list of algorithms supported by the Keymaster hardware
+implementation. A software implementation must return an empty list; a hybrid
+implementation must return a list containing only the algorithms that are
+supported by hardware.</p>
+
+<p>Keymaster1 implementations must support RSA, EC, AES and HMAC.</p>
+
+<h3 id=get_supported_block_modes>get_supported_block_modes</h3>
+
+<p>Returns the list of AES block modes supported by the Keymaster hardware
+implementation for a specified algorithm and purpose.</p>
+
+<p>For RSA, EC and HMAC, which are not block ciphers, the method must return an
+empty list for all valid purposes. Invalid purposes should cause the method to
+return <code>KM_ERROR_INVALID_PURPOSE</code>.</p>
+
+<p>Keymaster1 implementations must support ECB, CBC, CTR and GCM for AES
+encryption and decryption.</p>
+
+<h3 id=get_supported_padding_modes>get_supported_padding_modes</h3>
+
+<p>Returns the list of padding modes supported by the Keymaster hardware
+implementation for a specified algorithm and purpose.</p>
+
+<p>HMAC and EC have no notion of padding so the method must return an empty list
+for all valid purposes. Invalid purposes should cause the method to return <code>KM_ERROR_INVALID_PURPOSE</code>.</p>
+
+<p>For RSA, keymaster1 implementations must support:</p>
+
+<ul>
+ <li>Unpadded encryption, decryption, signing and verification. For unpadded
+encryption and signing, if the message is shorter than the public modulus,
+implementations must left-pad it with zeros. For unpadded decryption and
+verification, the input length must match the public modulus size.
+ <li>PKCS#1 v1.5 encryption and signing padding modes
+ <li>PSS with a minimum salt length of 20
+ <li>OAEP
+</ul>
+
+<p>For AES in ECB and CBC modes, keymaster1 implementations must support no
+padding and PKCS#7-padding. CTR and GCM modes must support only no padding.</p>
+
+<h3 id=get_supported_digests>get_supported_digests</h3>
+
+<p>Returns the list of digest modes supported by the Keymaster hardware
+implementation for a specified algorithm and purpose.</p>
+
+<p>No AES modes support or require digesting, so the method must return an empty
+list for valid purposes.</p>
+
+<p>Keymaster1 implementations are allowed to implement a subset of the defined
+digests, but must provide SHA-256. It is strongly recommended that keymaster1
+implementations provide MD5, SHA1, SHA-224, SHA-256, SHA384 and SHA512 (the
+full set of defined digests).</p>
+
+<h3 id=get_supported_import_formats>get_supported_import_formats</h3>
+
+<p>Returns the list of import formats supported by the Keymaster hardware
+implementation of a specified algorithm.</p>
+
+<p>Keymaster1 implementations must support the PKCS#8 format (without password
+protection) for importing RSA and EC key pairs, and must support RAW import of
+AES and HMAC key material.</p>
+
+<h3 id=get_supported_export_formats>get_supported_export_formats</h3>
+
+<p>Returns the list of export formats supported by the Keymaster hardware
+implementation of a specified algorithm.</p>
+
+<p>Keymaster1 implementations must support the X.509 format for exporting RSA and
+EC public keys. Export of private keys or asymmetric keys must not be
+supported.</p>
+
+<h3 id=add_rng_entropy>add_rng_entropy</h3>
+
+<p>Adds caller-provided entropy to the pool used by the Keymaster1 implementation
+for generating random numbers, for keys, IVs, etc.</p>
+
+<p>Keymaster1 implementations must <strong>securely</strong> mix the provided
+entropy into their pool, which must also contain
+internally-generated entropy from a hardware random number generator. Mixing
+must have the property that an attacker with complete control of either
+the <code>add_rng_entropy</code>-provided bits or the hardware-generated bits, but not both, cannot predict
+bits generated from the entropy pool with probability greater than ½.</p>
+
+<p>Keymaster1 implementations that attempt to estimate the entropy in their
+internal pool must assume that data provided by <code>add_rng_entropy</code> contains no entropy.</p>
+
+<h3 id=generate_key>generate_key</h3>
+
+<p>Generates a new cryptographic key, specifying associated authorizations, which
+will be permanently bound to the key. Keymaster1 implementations must make it
+impossible to use a key in any way inconsistent with the authorizations
+specified at generation time. With respect to authorizations that the secure
+hardware cannot enforce, the secure hardware's obligation is limited to
+ensuring that the unenforceable authorizations associated with the key cannot
+be modified, so that every call to <a href="#get_key_characteristics">get_key_characteristics</a>
+will return the original value. In addition, the characteristics returned by <code>generate_key</code>
+must allocate authorizations correctly between the hardware-enforced and
+software-enforced lists. See <a href="#get_key_characteristics">get_key_characteristics</a>
+for more details.</p>
+
+<p>The parameters that must be provided to <code>generate_key</code> depend on the type of key
+being generated. This section will summarize the
+required and allowed tags for each type of key. <a href="#km_tag_algorithm">KM_TAG_ALGORITHM</a>
+is always required, to specify the type.</p>
+
+<h4 id=rsa_keys>RSA keys</h4>
+
+<p>The following parameters are required when generating an RSA key.</p>
+
+<ul>
+ <li><a href="#km_tag_key_size">KM_TAG_KEY_SIZE</a> specifies the size of the public
+ modulus, in bits. If omitted, the method must
+return <code>KM_ERROR_UNSUPPORTED_KEY_SIZE</code>. Values that must be supported are
+1024, 2048, 3072 and 4096. It is
+recommended to support all key sizes that are a multiple of 8.
+ <li><a href="#km_tag_rsa_public_exponent">KM_TAG_RSA_PUBLIC_EXPONENT</a> specifies
+ the RSA public exponent value. If omitted, the method must
+ return <code>KM_ERROR_INVALID_ARGUMENT</code>.
+ Implementations must support the values 3 and 65537. It is recommended to
+support all prime values up to 2^64.
+</ul>
+
+<p>The following parameters are not required to generate an RSA key, but creating
+an RSA key without them will produce a key that is unusable.
+The <code>generate_key</code> function should not return an error if these parameters are omitted.</p>
+
+<ul>
+ <li><a href="#km_tag_purpose">KM_TAG_PURPOSE</a> specifies allowed purposes.
+ All purposes must be supported for RSA keys, in
+any combination.
+ <li><a href="#km_tag_digest">KM_TAG_DIGEST</a> specifies digest algorithms that
+ may be used with the new key. Implementations
+that do not support all digest algorithms must accept key generation requests
+that include unsupported digests. The unsupported digests should be placed in
+the "software-enforced" list in the returned key characteristics. This is
+because the key will be usable with those other digests, but digesting will be
+performed in software. Then hardware will be called to perform the operation
+with <code>KM_DIGEST_NONE</code>.
+ <li><a href="#km_tag_padding">KM_TAG_PADDING</a> specifies the padding modes
+ that may be used with the new key. Implementations
+that do not support all digest algorithms must place <code>KM_PAD_RSA_PSS</code>
+and <code>KM_PAD_RSA_OAEP</code> in the software-enforced list of the key
+characteristics if any unsupported
+digest algorithms are specified.
+</ul>
+
+<h4 id=ecdsa_keys>ECDSA keys</h4>
+
+<p>Only <a href="#km_tag_key_size">KM_TAG_KEY_SIZE</a> is required to generate an
+ECDSA key. It is used to select the EC group.
+Implementations must support values 224, 256, 384 and 521, which indicate the
+NIST p-224, p-256, p-384 and p521 curves, respectively.</p>
+
+<p><a href="#km_tag_digest">KM_TAG_DIGEST</a> is also needed for a useful ECDSA key,
+but is not required for generation.</p>
+
+<h4 id=aes_keys>AES keys</h4>
+
+<p>Only <a href="#km_tag_key_size">KM_TAG_KEY_SIZE</a> is required when
+generating an AES key. If omitted, the method must return <code>KM_ERROR_UNSUPPORTED_KEY_SIZE</code>.
+Values that must be supported are 128 and 256. It is recommended to support
+192-bit AES keys.</p>
+
+<p>The following parameters are particularly relevant for AES keys, but not
+required to generate one:</p>
+
+<ul>
+ <li><code>KM_TAG_BLOCK_MODE</code> specifies the block modes with which the new key may be used.
+ <li><code>KM_TAG_PADDING</code> specifies the padding modes that may be used. This is only relevant for ECB
+and CBC modes.
+</ul>
+
+<p>If the GCM block mode is specified, then <a href="#km_tag_min_mac_length">KM_TAG_MIN_MAC_LENGTH</a>
+must be provided. If omitted, the method must return
+<code>KM_ERROR_MISSING_MIN_MAC_LENGTH</code>. The value of the tag must be a multiple of 8 and must
+be at least 96 and no more than 128.</p>
+
+<h4 id=hmac_keys>HMAC keys</h4>
+
+<p>The following parameters are required for HMAC key generation:</p>
+
+<ul>
+ <li><a href="#km_tag_key_size">KM_TAG_KEY_SIZE</a> specifies the key size in bits. Values
+ smaller than 64 and values that are not
+multiples of 8 must not be supported. All multiples of 8, from 64 to 512, must
+be supported. Larger values may be supported.
+ <li><a href="#km_tag_min_mac_length">KM_TAG_MIN_MAC_LENGTH</a> specifies the minimum length of
+ MACs that can be generated or verified with
+this key. The value must be a multiple of 8 and must be at least 64.
+ <li><a href="#km_tag_digest">KM_TAG_DIGEST</a> specifies the digest algorithm for the key. Exactly
+ one digest must be
+specified, otherwise return <code>KM_ERROR_UNSUPPORTED_DIGEST</code>. If the digest is not supported
+by the trustlet, return <code>KM_ERROR_UNSUPPORTED_DIGEST</code>.
+</ul>
+
+<h4 id=key_characteristics>Key characteristics</h4>
+
+<p>If the characteristics argument is non-NULL, <code>generate_key</code> must return the newly-generated
+key's characteristics divided appropriately
+into hardware-enforced and software-enforced lists. See <a href="#get_key_characteristics">get_key_characteristics</a>
+for a description of which characteristics go in which list. The returned
+characteristics must include all of the parameters specified to key generation,
+except <a href="#km_tag_application_id">KM_TAG_APPLICATION_ID</a> and
+<a href="#km_tag_application_data">KM_TAG_APPLICATION_DATA</a>.
+If these tags were included in the key parameters, they must be removed from
+the returned characteristics; it must not be possible to find their values by
+examining the returned key blob. However, they must be cryptographically bound
+to the key blob, so that if the correct values are not provided when the key is
+used, usage will fail. Similarly, <a href="#km_tag_root_of_trust">KM_TAG_ROOT_OF_TRUST</a> must
+be cryptographically bound to the key, but it may not be specified during
+key creation or import and must never be returned.</p>
+
+<p>In addition to the provided tags, the trustlet must also
+add <a href="#km_tag_origin">KM_TAG_ORIGIN</a>, with the value <code>KM_ORIGIN_GENERATED</code>,
+and if the key is rollback resistant, <a href="#km_tag_rollback_resistant">KM_TAG_ROLLBACK_RESISTANT</a>.</p>
+
+<h4 id=rollback_resistance>Rollback resistance </h4>
+
+<p>Rollback resistance means that once a key is deleted with
+<a href="#delete_key">delete_key</a> or <a href="#delete_all_keys">delete_all_keys</a>,
+it is guaranteed by secure hardware never to be usable again. Implementations
+without rollback resistance will typically return generated or imported key
+material to the caller as a key blob, an encrypted and authenticated form. When
+keystore deletes the key blob, the key is gone, but an attacker who has
+previously managed to retrieve the key material can potentially restore it to
+the device.</p>
+
+<p>A key is rollback resistant if the secure hardware guarantees that deleted keys
+cannot be restored later. This is generally done by storing additional key
+metadata in a trusted location that cannot be manipulated by an attacker. On
+mobile devices, the mechanism used for this is usually Replay Protected Memory
+Blocks (RPMB). Because the number of keys that may be created is essentially
+unbounded and the trusted storage used for rollback resistance may be limited
+in size, it is required that this method succeed even if rollback resistance
+cannot be provided for the new key. In that case,
+<a href="#km_tag_rollback_resistant">KM_TAG_ROLLBACK_RESISTANT</a> should not be
+added to the key characteristics.</p>
+
+<h3 id=get_key_characteristics>get_key_characteristics</h3>
+
+<p>Returns parameters and authorizations associated with the provided key, divided
+into two sets: hardware-enforced and software-enforced. The description here
+applies equally to the key characteristics lists returned
+by <a href="#generate_key">generate_key</a> and <a href="#import_key">import_key</a>.</p>
+
+<p>If <code>KM_TAG_APPLICATION_ID</code> was provided during key generation
+or import, the same value must provided to
+this method in the <code>client_id</code> argument. Otherwise, the
+method must return <code>KM_ERROR_INVALID_KEY_BLOB</code>. Similarly,
+if <code>KM_TAG_APPLICATION_DATA </code>was provided during generation
+or import, the same value must be provided to
+this method in the <code>app_data</code> argument.</p>
+
+<p>The characteristics returned by this method completely describe the type and
+usage of the specified key.</p>
+
+<p>The general rule for deciding whether a given tag belongs in the
+hardware-enforced or software-enforced list is that if the meaning of the tag
+is fully assured by secure hardware, it is hardware-enforced. Otherwise, it's
+software enforced. Below is a list of specific tags whose correct allocation
+may be unclear:</p>
+
+<ul>
+ <li><a href="#km_tag_algorithm">KM_TAG_ALGORITHM</a>, <a href="#km_tag_key_size">KM_TAG_KEY_SIZE</a>,
+ and <a href="#km_tag_rsa_public_exponent">KM_TAG_RSA_PUBLIC_EXPONENT</a> are
+ intrinsic properties of the key. For any key that is secured by hardware,
+these will be in the hardware-enforced list, because the statement that, for
+example, "This RSA key material is only used as an RSA key" is enforced by
+hardware because the hardware will use it in no other way and software has no
+access to the key material and cannot use it at all.
+ <li><a href="#km_tag_digest">KM_TAG_DIGEST</a> values that are supported by the
+ secure hardware are to be placed in the
+hardware-supported list. Unsupported digests go in the software-supported list.
+ <li><a href="#km_tag_padding">KM_TAG_PADDING</a> values generally go in the
+ hardware-supported list, but if there is a
+possibility that a specific padding mode may have to be performed by software,
+they go in the software-enforced list. Such a possibility arises for RSA keys
+that permit PSS or OAEP padding with digest algorithms that are not supported
+by the secure hardware.
+ <li><a href="#km_tag_user_secure_id">KM_TAG_USER_SECURE_ID</a> and
+ <a href="#km_tag_mac_length">KM_TAG_USER_AUTH_TYPE</a> are hardware-enforced
+ only if user authentication is hardware enforced. For
+that to be true, the Keymaster trustlet and the relevant authentication
+trustlet must both be secure and must share a secret HMAC key used to sign and
+validate authentication tokens. See the Authentication page for details.
+ <li><a href="#km_tag_active_datetime">KM_TAG_ACTIVE_DATETIME</a>,
+ <a href="#km_tag_origination_expire_datetime">KM_TAG_ORIGINATION_EXPIRE_DATETIME</a>,
+ and <a href="#km_tag_usage_expire_datetime">KM_TAG_USAGE_EXPIRE_DATETIME</a> tags
+ require access to a verifiably correct wall clock. Most secure hardware
+will only have access to time information provided by the non-secure OS, which
+means the tags are software-enforced.
+ <li><a href="#km_tag_origin">KM_TAG_ORIGIN</a> is always in the hardware list for
+ hardware-bound keys. Its presence in that
+list is the way higher layers determine that a key is hardware-backed.
+</ul>
+
+<h3 id=import_key>import_key</h3>
+
+<p>Imports key material into Keymaster hardware. Key definition parameters and
+output characteristics are handled the same as for <code>generate_key</code>,
+with the following exceptions:</p>
+
+<ul>
+ <li><a href="#km_tag_key_size">KM_TAG_KEY_SIZE</a> and
+ <a href="#km_tag_rsa_public_exponent">KM_TAG_RSA_PUBLIC_EXPONENT</a> (for RSA keys only)
+ are not required in the input parameters. If not provided,
+the trustlet must deduce the values from the provided key material and add
+appropriate tags and values to the key characteristics. If the parameters are
+provided, the trustlet must validate them against the key material. In the
+event of a mismatch, the method must return <code>KM_ERROR_IMPORT_PARAMETER_MISMATCH</code>.
+ <li>The returned <a href="#km_tag_origin">KM_TAG_ORIGIN</a> must have the
+ value <code>KM_ORIGIN_IMPORTED</code>.
+</ul>
+
+<h3 id=export_key>export_key</h3>
+
+<p>Exports a public key from a Keymaster RSA or EC key pair.</p>
+
+<p>If <code>KM_TAG_APPLICATION_ID</code> was provided during key generation or import,
+the same value must provided to
+this method in the <code>client_id</code> argument. Otherwise, the method must return
+<code>KM_ERROR_INVALID_KEY_BLOB</code>. Similarly, if <code>KM_TAG_APPLICATION_DATA</code>
+was provided during generation or import, the same value must be provided to
+this method in the <code>app_data</code> argument.</p>
+
+<h3 id=delete_key>delete_key</h3>
+
+<p>Deletes the provided key. This method is optional, and will likely be
+implemented only by Keymaster modules that provide rollback resistance.</p>
+
+<h3 id=delete_all_keys>delete_all_keys</h3>
+
+<p>Deletes all keys. This method is optional, and will likely be implemented only
+by Keymaster modules that provide rollback resistance.</p>
+
+<h3 id=begin>begin</h3>
+
+<p>Begins a cryptographic operation, using the specified key, for the specified
+purpose, with the specified parameters (as appropriate), and returns an
+operation handle which is used with <a href="#update">update</a> and <a href="#finish">finish</a> to complete the operation.</p>
+
+<p>If <a href="#km_tag_application_id">KM_TAG_APPLICATION_ID</a> or <a href="#km_tag_application_data">KM_TAG_APPLICATION_DATA</a>
+were specified during key generation or import, calls to begin must include
+those tags with the originally-specified values in the <code>in_params</code> argument to this method.</p>
+
+<h4 id=authorization_enforcement>Authorization enforcement</h4>
+
+<p>During this method, the following key authorizations must be enforced by the
+trustlet if the implementation placed them in the "hardware-enforced"
+characteristics and if the operation is not a public key operation. Public key
+operations, meaning <code>KM_PURPOSE_ENCRYPT</code> and <code>KM_PURPOSE_VERIFY</code>,
+with RSA or EC keys, must be allowed to succeed even if authorization
+requirements are not met.</p>
+
+<ul>
+ <li><a href="#km_tag_purpose">KM_TAG_PURPOSE</a> requires that the purpose specified
+ for this method match one of the purposes
+in the key authorizations, unless the requested operation is a public key
+operation, meaning that the key is RSA or EC and the purpose is <code>KM_PURPOSE_ENCRYPT</code>
+or <code>KM_PURPOSE_VERIFY</code>. Note that <code>KM_PURPOSE_ENCRYPT</code> is not valid for EC keys.
+Begin should return <code>KM_ERROR_UNSUPPORTED_PURPOSE</code> in that case.
+ <li><a href="#km_tag_active_datetime">KM_TAG_ACTIVE_DATETIME</a> requires comparison with a trusted
+ UTC time source. If the current date and
+time is prior to the tag value, the method must return <code>KM_ERROR_KEY_NOT_YET_VALID</code>.
+ <li><a href="#km_tag_origination_expire_datetime">KM_TAG_ORIGINATION_EXPIRE_DATETIME</a> requires
+ comparison with a trusted UTC time source. If the current date and
+time is later than the tag value and the purpose is <code>KM_PURPOSE_ENCRYPT</code> or <code>KM_PURPOSE_SIGN</code>,
+the method must return <code>KM_ERROR_KEY_EXPIRED</code>.
+ <li><a href="#km_tag_usage_expire_datetime">KM_TAG_USAGE_EXPIRE_DATETIME</a> requires comparison with a
+ trusted UTC time source. If the current date and
+time is later than the tag value and the purpose is <code>KM_PURPOSE_DECRYPT</code> or <code>KM_PURPOSE_VERIFY</code>,
+the method must return <code>KM_ERROR_KEY_EXPIRED</code>.
+ <li><a href="#km_tag_min_seconds_between_ops">KM_TAG_MIN_SECONDS_BETWEEN_OPS</a> requires comparison with a
+ trusted relative timer indicating the last use of
+the key. If the last use time plus the tag value is less than the current time,
+the method must return <code>KM_ERROR_KEY_RATE_LIMIT_EXCEEDED</code>. See the tag description for
+important implementation requirements.
+ <li><a href="#km_tag_max_uses_per_boot">KM_TAG_MAX_USES_PER_BOOT</a> requires comparison against a
+ secure counter that tracks the uses of the key
+since boot time. If the count of previous uses exceeds the tag value, the
+method must return <code>KM_ERROR_KEY_MAX_OPS_EXCEEDED</code>.
+ <li><a href="#km_tag_user_secure_id">KM_TAG_USER_SECURE_ID</a> is enforced by this method only
+ if the key also has <a href="#km_tag_auth_timeout">KM_TAG_AUTH_TIMEOUT</a>. If the key has both,
+ then this method must have received a <a href="#km_tag_auth_token">KM_TAG_AUTH_TOKEN</a> in
+ <code>in_params</code> and that token must be valid, meaning that the HMAC field validates correctly.
+In addition, at least one of the <a href="#km_tag_user_secure_id">KM_TAG_USER_SECURE_ID</a>
+values from the key must match at least one of the secure ID values in the
+token. Finally, the key must also have a <a href="#km_tag_mac_length">KM_TAG_USER_AUTH_TYPE</a> and
+it must match the auth type in the token. If any of these requirements is
+not met, the method must return <code>KM_ERROR_KEY_USER_NOT_AUTHENTICATED</code>.
+ <li><a href="#km_tag_caller_nonce">KM_TAG_CALLER_NONCE</a> allows the caller to specify a nonce
+ or initialization vector (IV). If the key
+does not have this tag but the caller provided <a href="#km_tag_nonce">KM_TAG_NONCE</a> to this method,
+<code>KM_ERROR_CALLER_NONCE_PROHIBITED</code> must be returned.
+ <li><a href="#km_tag_bootloader_only">KM_TAG_BOOTLOADER_ONLY</a> specifies that the key may only be
+ used by the bootloader. If this method is
+called with a bootloader-only key after the bootloader has finished executing,
+it must return <code>KM_ERROR_INVALID_KEY_BLOB</code>.
+</ul>
+
+<h4 id=rsa_keys>RSA keys</h4>
+
+<p>All RSA key operations must specify exactly one padding mode in <code>in_params</code>. If
+unspecified or specified more than once, the method must return <code>KM_ERROR_UNSUPPORTED_PADDING_MODE</code>.</p>
+
+<p>RSA signing and verification operations require a digest, as do RSA encryption
+and decryption operations with OAEP padding mode. For those cases, the caller
+must specify exactly one digest in <code>in_params</code>. If unspecified or specified more than once,
+the method must return <code>KM_ERROR_UNSUPPORTED_DIGEST</code>.</p>
+
+<p>Private key operations (<code>KM_PURPOSE_DECYPT</code> and <code>KM_PURPOSE_SIGN</code>) require
+authorization of digest and padding, which means that the specified
+values must be in the key authorizations. If not, the method must return <code>KM_ERROR_INCOMPATIBLE_DIGEST</code>
+or <code>KM_ERROR_INCOMPATIBLE_PADDING</code>, as appropriate. Public key operations
+(<code>KM_PURPOSE_ENCRYPT</code> and <code>KM_PURPOSE_VERIFY</code>) are permitted with
+unauthorized digest or padding.</p>
+
+<p>With the exception of <code>KM_PAD_NONE</code>, all RSA padding modes are applicable only to
+certain purposes. Specifically, <code>KM_PAD_RSA_PKCS1_1_5_SIGN</code> and <code>KM_PAD_RSA_PSS</code>
+only support signing and verification, while <code>KM_PAD_RSA_PKCS1_1_1_5_ENCRYPT</code> and
+<code>KM_PAD_RSA_OAEP</code> only support encryption and decryption. The method must return
+<code>KM_ERROR_UNSUPPORTED_PADDING_MODE</code> if the specified mode does not support the specified purpose.</p>
+
+<p>There are some important interactions between padding modes and digests:</p>
+
+<ul>
+ <li><code>KM_PAD_NONE</code> indicates that a "raw" RSA operation will be performed. If signing or
+verifying, <code>KM_DIGEST_NONE </code>must be specified for the digest. No digest is required for unpadded encryption
+or decryption.
+ <li><code>KM_PAD_RSA_PKCS1_1_5_SIGN</code> padding requires a digest, which may be <code>KM_DIGEST_NONE.</code>
+ <li><code>KM_PAD_RSA_PKCS1_1_1_5_ENCRYPT</code> padding does not require a digest.
+ <li><code>KM_PAD_RSA_PSS</code> padding requires a digest, which may not be <code>KM_DIGEST_NONE</code>.
+ If <code>KM_DIGEST_NONE</code> is specified, the method must return
+ <code>KM_ERROR_INCOMPATIBLE_PADDING_MODE</code>. In addition, the
+ size of the RSA key must be at least 22 bytes larger than
+the output size of the digest. Otherwise, the method must return <code>KM_ERROR_INCOMPATIBLE_DIGEST</code>.
+ <li><code>KM_PAD_RSA_OAEP</code> padding requires a digest, which may not be <code>KM_DIGEST_NONE</code>.
+ If <code>KM_DIGEST_NONE</code> is specified, the method must return <code>KM_ERROR_INCOMPATIBLE_DIGEST</code>.
+</ul>
+
+<h4 id=ec_keys>EC keys</h4>
+
+<p>EC key operations must specify exactly one padding mode in <code>in_params</code>.
+If unspecified or specified more than once,
+return <code>KM_ERROR_UNSUPPORTED_PADDING_MODE</code>.</p>
+
+<p>Private key operations (<code>KM_PURPOSE_SIGN</code>) require authorization of the
+digest, which means that the specified value must be in the key authorizations.
+If not, return <code>KM_ERROR_INCOMPATIBLE_DIGEST</code>.
+Public key operations (<code>KM_PURPOSE_VERIFY</code>) are permitted with unauthorized digest or padding.</p>
+
+<h4 id=aes_keys>AES keys</h4>
+
+<p>AES key operations must specify exactly one block mode and one padding mode in <code>in_params</code>.
+If either value is unspecified or specified more than once, return <code>KM_ERROR_UNSUPPORTED_BLOCK_MODE</code> or
+<code>KM_ERROR_UNSUPPORTED_PADDING_MODE</code>. The specified modes must be authorized by the key.
+Otherwise, the method must
+return <code>KM_ERROR_INCOMPATIBLE_BLOCK_MODE</code> or <code>KM_ERROR_INCOMPATIBLE_PADDING_MODE</code>.</p>
+
+<p>If the block mode is <code>KM_MODE_GCM</code>, <code>in_params</code> must specify <code>KM_TAG_MAC_LENGTH</code>, and the
+specified value must be a multiple of 8 and must not be greater than
+128, or less than the value of <code>KM_TAG_MIN_MAC_LENGTH</code> in the key authorizations. For MAC lengths greater than 128 or non-multiples of
+8, return <code>KM_ERROR_UNSUPPORTED_MAC_LENGTH</code>. For values less than the key's minimum length, return <code>KM_ERROR_INVALID_MAC_LENGTH</code>.</p>
+
+<p>If the block mode is <code>KM_MODE_GCM</code> or <code>KM_MODE_CTR</code>, the specified padding mode must
+be <code>KM_PAD_NONE</code>. For <code>KM_MODE_ECB</code> or <code>KM_MODE_CBC</code>, the mode may
+be <code>KM_PAD_NONE</code> or <code>KM_PAD_PKCS7</code>. If the padding mode doesn't meet these
+requirements, return <code>KM_ERROR_INCOMPATIBLE_PADDING_MODE</code>.</p>
+
+<p>If the block mode is <code>KM_MODE_CBC</code>, <code>KM_MODE_CTR</code>, or <code>KM_MODE_GCM</code>, an initialization vector or nonce is needed.
+In most cases, callers should not
+provide an IV or nonce and the Keymaster implementation must generate a random
+IV or nonce and return it via <a href="#km_tag_nonce">KM_TAG_NONCE</a> in <code>out_params</code>. CBC
+and CTR IVs are 16 bytes. GCM nonces are 12 bytes. If the key
+authorizations contain <a href="#km_tag_caller_nonce">KM_TAG_CALLER_NONCE</a>, then the caller may
+provide an IV/nonce with <a href="#km_tag_nonce">KM_TAG_NONCE</a> in <code>in_params</code>. If a
+nonce is provided when <a href="#km_tag_caller_nonce">KM_TAG_CALLER_NONCE</a> is not authorized,
+return <code>KM_ERROR_CALLER_NONCE_PROHIBITED</code>. If a nonce is not provided when
+<a href="#km_tag_caller_nonce">KM_TAG_CALLER_NONCE</a> is authorized, generate a random IV/nonce.</p>
+
+<h4 id=hmac_keys>HMAC keys</h4>
+
+<p>HMAC key operations must specify <code>KM_TAG_MAC_LENGTH</code> in <code>in_params</code>.
+The specified value must be a multiple of 8 and must not be greater than the
+digest length, or less than the value of <code>KM_TAG_MIN_MAC_LENGTH</code> in the key authorizations.
+For MAC lengths greater than the digest length or
+non-multiples of 8, return <code>KM_ERROR_UNSUPPORTED_MAC_LENGTH</code>. For values less than
+the key's minimum length, return <code>KM_ERROR_INVALID_MAC_LENGTH</code>.</p>
+
+<h3 id=update>update</h3>
+
+<p>Provides data to process in an ongoing operation started with <a href="#begin">begin</a>.
+The operation is specified by the <code>operation_handle</code> parameter.</p>
+
+<p>To provide more flexibility for buffer handling, implementations of this method
+have the option of consuming less data than was provided. The caller is
+responsible for looping to feed the rest of the data in subsequent calls. The
+amount of input consumed must be returned in the <code>input_consumed</code> parameter.
+Implementations must always consume at least one byte, unless the
+operation cannot accept any more; if more than zero bytes are provided and zero
+bytes are consumed, callers will consider this an error and abort the
+operation.</p>
+
+<p>Implementations may also choose how much data to return, as a result of the
+update. This is only relevant for encryption and decryption operations, since
+signing and verification return no data until <a href="#finish">finish</a>. It is recommended
+to return data as early as possible, rather than buffer it.</p>
+
+<h4 id=error_handling>Error handling</h4>
+
+<p>If this method returns an error code other than <code>KM_ERROR_OK</code>, the operation is
+aborted and the operation handle must be invalidated. Any
+future use of the handle, with this method or <a href="#finish">finish</a> or <a href="#abort">abort</a>,
+must return <code>KM_ERROR_INVALID_OPERATION_HANDLE</code>.</p>
+
+<h4 id=authorization_enforcement>Authorization enforcement</h4>
+
+<p>Key authorization enforcement is performed primarily in <a href="#begin">begin</a>. The one exception
+is the case where the key has:</p>
+
+<ul>
+ <li>One or more <a href="#km_tag_user_secure_id">KM_TAG_USER_SECURE_IDs</a>, and
+ <li>Does not have a <a href="#km_tag_auth_timeout">KM_TAG_AUTH_TIMEOUT</a>
+</ul>
+
+<p>In this case, the key requires an authorization per operation, and the update
+method must receive a <a href="#km_tag_auth_token">KM_TAG_AUTH_TOKEN</a> in the <code>in_params</code> argument.
+The token must be valid (HMAC must verify) and it must contain a
+matching secure user ID, must match the key's <a href="#km_tag_mac_length">KM_TAG_USER_AUTH_TYPE</a>, and must
+contain the operation handle of the current operation in the
+challenge field. If these requirements aren't met, return <code>KM_ERROR_KEY_USER_NOT_AUTHENTICATED</code>.</p>
+
+<p>The caller must provide the authentication token to every call to <a href="#update">update</a> and
+<a href="#finish">finish</a>. The implementation need only validate the token once if it prefers.</p>
+
+<h4 id=rsa_keys>RSA keys</h4>
+
+<p>For signing and verification operations with <code>KM_DIGEST_NONE</code>, this method must accept
+the entire block to be signed or verified in a single
+update. It may not consume only a portion of the block. It still must accept
+the data in multiple updates if the caller chooses to provide it that way,
+however. If the caller provides more data to sign than can be used (length of
+data exceeds RSA key size), return <code>KM_ERROR_INVALID_INPUT_LENGTH</code>.</p>
+
+<h4 id=ecdsa_keys>ECDSA keys</h4>
+
+<p>For signing and verification operations with <code>KM_DIGEST_NONE</code>, this method must accept the
+entire block to be signed or verified in a single
+update. This method may not consume only a portion of the block.</p>
+
+<p>However, this method still must accept the data in multiple updates if the
+caller chooses to provide it that way. If the caller provides more data to sign
+than can be used, the data should be silently truncated. (This differs from the
+handling of excess data provided in similar RSA operations. The reason for this
+is compatibility with legacy clients.)</p>
+
+<h4 id=aes_keys>AES keys</h4>
+
+<p>AES GCM mode supports "associated authentication data," provided via the
+<a href="#km_tag_associated_data">KM_TAG_ASSOCIATED_DATA</a> tag in the <code>in_params</code> argument.
+The associated data may be provided in repeated calls (important if
+the data is too large to send in a single block) but must always precede data
+to be encrypted or decrypted. An update call may receive both associated data
+and data to encrypt/decrypt, but subsequent updates may not include associated
+data. If the caller provides associated data to an update call after a call
+that includes data to encrypt/decrypt, return <code>KM_ERROR_INVALID_TAG</code>.</p>
+
+<p>For GCM encryption, the tag is appended to the ciphertext by <a href="#finish">finish</a>.
+During decryption, the last <code>KM_TAG_MAC_LENGTH</code> bytes of the data provided to the last
+update call is the tag. Since a given
+invocation of <a href="#update">update</a> cannot know if it's the last invocation, it must process all but the tag
+length and buffer the possible tag data for processing during <a href="#finish">finish</a>.</p>
+
+<h3 id=finish>finish</h3>
+
+<p>Finished an ongoing operation started with <a href="#begin">begin</a>, processing all of the
+as-yet-unprocessed data provided by <a href="#update">update</a>(s).</p>
+
+<p>This method is the last one called in an operation, so all processed data must
+be returned.</p>
+
+<p>Whether it completes successfully or returns an error, this method finalizes
+the operation and therefore invalidates the provided operation handle. Any
+future use of the handle, with this method or <a href="#update">update</a> or
+<a href="#abort">abort</a>, must return <code>KM_ERROR_INVALID_OPERATION_HANDLE</code>.</p>
+
+<p>Signing operations return the signature as the output. Verification operations
+accept the signature in the <code>signature</code> parameter, and return no output.</p>
+
+<h4 id=authorization_enforcement>Authorization enforcement</h4>
+
+<p>Key authorization enforcement is performed primarily in <a href="#begin">begin</a>. The one exception is the case where the key has:</p>
+
+<ul>
+ <li>One or more <a href="#km_tag_user_secure_id">KM_TAG_USER_SECURE_IDs</a>, and
+ <li>Does not have a <a href="#km_tag_auth_timeout">KM_TAG_AUTH_TIMEOUT</a>
+</ul>
+
+<p>In this case, the key requires an authorization per operation, and the update
+method must receive a <a href="#km_tag_auth_token">KM_TAG_AUTH_TOKEN</a> in the <code>in_params</code> argument.
+The token must be valid (HMAC must verify) and it must contain a
+matching secure user ID, must match the key's <a href="#km_tag_mac_length">KM_TAG_USER_AUTH_TYPE</a>, and must
+contain the operation handle of the current operation in the
+challenge field. If these requirements aren't met, return <code>KM_ERROR_KEY_USER_NOT_AUTHENTICATED</code>.</p>
+
+<p>The caller must provide the authentication token to every call to <a href="#update">update</a> and <a href="#finish">finish</a>.
+The implementation need only validate the token once if it prefers.</p>
+
+<h4 id=rsa_keys>RSA keys</h4>
+
+<p>Some additional requirements, depending on the padding mode:</p>
+
+<ul>
+ <li><strong>KM_PAD_NONE</strong>. For unpadded signing and encryption operations, if the provided data is
+shorter than the key, the data must be zero-padded on the left before
+signing/encryption. If the data is the same length as the key but numerically
+larger, return <code>KM_ERROR_INVALID_ARGUMENT</code>. For verification and decryption operations, the data must be exactly as long
+as the key. Otherwise, return <code>KM_ERROR_INVALID_INPUT_LENGTH.</code>
+ <li><strong>KM_PAD_RSA_PSS</strong>. For PSS-padded signature operations, the PSS salt must be at least 20 bytes
+in length and randomly-generated. The salt may be longer; the reference
+implementation uses maximally-sized salt. The digest specified with <a href="#km_tag_digest">KM_TAG_DIGEST</a> in
+<code>input_params</code> on <a href="#begin">begin</a> is used as the PSS digest algorithm, and SHA1 is used as the MGF1 digest
+algorithm.
+ <li><strong>KM_PAD_RSA_OAEP</strong>. The digest specified with <a href="#km_tag_digest">KM_TAG_DIGEST</a> in
+ <code>input_params</code> on <a href="#begin">begin</a> is used as the OAEP digest algorithm, and SHA1 is used as the MGF1 digest
+algorithm.
+</ul>
+
+<h4 id=ecdsa_keys>ECDSA keys</h4>
+
+<p>If the data provided for unpadded signing or verification is too long, truncate
+it.</p>
+
+<h4 id=aes_keys>AES keys</h4>
+
+<p>Some additional requirements, depending on block mode:</p>
+
+<ul>
+ <li><strong>KM_MODE_ECB</strong> or <strong>KM_MODE_CBC</strong>. If padding is <code>KM_PAD_NONE</code> and the
+ data length is not a multiple of the AES block size, return <code>KM_ERROR_INVALID_INPUT_LENGTH</code>. If
+ padding is <code>KM_PAD_PKCS7</code>, pad the data per the PKCS#7 specification. Note that PKCS#7 requires that if
+the data is a multiple of the block length, an additional padding block must be
+added.
+ <li><strong>KM_MODE_GCM</strong>. During encryption, after processing all plaintext, compute the
+ tag (<a href="#km_tag_mac_length">KM_TAG_MAC_LENGTH</a> bytes) and append it to the returned ciphertext.
+ During decryption, process
+the last <a href="#km_tag_mac_length">KM_TAG_MAC_LENGTH</a> bytes as the tag. If tag verification fails,
+return <code>KM_ERROR_VERIFICATION_FAILED</code>.
+</ul>
+
+<h3 id=abort>abort</h3>
+
+<p>Aborts the in-progress operation. After the call to abort, return <code>KM_ERROR_INVALID_OPERATION_HANDLE</code> for
+any subsequent use of the provided operation handle with <a href="#update">update</a>,
+<a href="#finish">finish</a>, or <a href="#abort">abort</a>.</p>
diff --git a/src/devices/tech/security/images/access-to-keymaster.png b/src/devices/tech/security/images/access-to-keymaster.png
new file mode 100644
index 0000000..611f8e3
--- /dev/null
+++ b/src/devices/tech/security/images/access-to-keymaster.png
Binary files differ
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
diff --git a/src/devices/tech/security/images/fingerprint-daemon.png b/src/devices/tech/security/images/fingerprint-daemon.png
new file mode 100644
index 0000000..a57a7a4
--- /dev/null
+++ b/src/devices/tech/security/images/fingerprint-daemon.png
Binary files differ
diff --git a/src/devices/tech/security/images/fingerprint-data-flow.png b/src/devices/tech/security/images/fingerprint-data-flow.png
new file mode 100644
index 0000000..bc3ff36
--- /dev/null
+++ b/src/devices/tech/security/images/fingerprint-data-flow.png
Binary files differ
diff --git a/src/devices/tech/security/images/gatekeeper-flow.png b/src/devices/tech/security/images/gatekeeper-flow.png
new file mode 100644
index 0000000..693ebec
--- /dev/null
+++ b/src/devices/tech/security/images/gatekeeper-flow.png
Binary files differ
diff --git a/src/devices/tech/security/verifiedboot/index.jd b/src/devices/tech/security/verifiedboot/index.jd
index 9146f1a..d254074 100644
--- a/src/devices/tech/security/verifiedboot/index.jd
+++ b/src/devices/tech/security/verifiedboot/index.jd
@@ -26,26 +26,26 @@
<h2 id="introduction">Introduction</h2>
-<p>Android 4.4 and later supports verified boot through the optional device-mapper-verity
-(dm-verity) kernel feature, which provides transparent integrity checking of
-block devices. dm-verity helps prevent persistent rootkits that can hold onto
-root privileges and compromise devices. This experimental feature helps Android
-users be sure when booting a device it is in the same state as when it was last
-used.</p>
+<p>Android 4.4 and later supports verified boot through the optional
+device-mapper-verity (dm-verity) kernel feature, which provides transparent
+integrity checking of block devices. dm-verity helps prevent persistent rootkits
+that can hold onto root privileges and compromise devices. This experimental
+feature helps Android users be sure when booting a device it is in the same
+state as when it was last used.</p>
-<p>Clever malware with root privileges can hide from detection programs and
-otherwise mask themselves. The rooting software can do this because it is often
-more privileged than the detectors, enabling the software to "lie" to to the
+<p>Clever malware with root privileges can hide from detection programs and
+otherwise mask themselves. The rooting software can do this because it is often
+more privileged than the detectors, enabling the software to "lie" to the
detection programs.</p>
-<p>The dm-verity feature lets you look at a block device, the underlying storage
-layer of the file system, and determine if it matches its expected
-configuration. It does this using a cryptographic hash tree. For every block
+<p>The dm-verity feature lets you look at a block device, the underlying storage
+layer of the file system, and determine if it matches its expected
+configuration. It does this using a cryptographic hash tree. For every block
(typically 4k), there is a SHA256 hash.</p>
-<p>And since the hash values are stored in a tree of pages, only the top-level
-"root" hash must be trusted to verify the rest of the tree. The ability to
-modify any of the blocks would be equivalent to breaking the cryptographic hash.
+<p>Since the hash values are stored in a tree of pages, only the top-level
+"root" hash must be trusted to verify the rest of the tree. The ability to
+modify any of the blocks would be equivalent to breaking the cryptographic hash.
See the following diagram for a depiction of this structure.</p>
<img src="../images/dm-verity-hash-table.png" alt="dm-verity-hash-table" id="figure1"/>
@@ -53,16 +53,16 @@
<strong>Figure 1.</strong> dm-verity hash table
</p>
-<p>
-A public key is included on the boot partition, which must be verified
-externally by the OEM. That key is used to verify the signature for that hash
+<p>A public key is included on the boot partition, which must be verified
+externally by the OEM. That key is used to verify the signature for that hash
and confirm the device's system partition is protected and unchanged.</p>
<h2 id="prerequisites">Prerequisites</h2>
<h3 id="verified-boot">Establishing a verified boot flow</h3>
<p>To greatly reduce the risk of compromise, verify the kernel using a key
-burned into the device. For details, see <a href="verified-boot.html">Verified boot</a>.</p>
+burned into the device. For details, see <a href="verified-boot.html">Verified
+boot</a>.</p>
<h3 id="block-otas">Switching to block-oriented OTAs</h3>
<p>To enable dm-verity for a device, you must use block-based over-the-air
@@ -71,23 +71,23 @@
<h3 id="config-dm-verity">Configuring dm-verity</h3>
-<p>After switching to block-oriented OTAs, incorporate the latest Android kernel or
-use a stock upstream kernel and enable dm-verity support by including the
-relevant configuration option:<br/>
-<code>CONFIG_DM_VERITY
-</code></p>
-<p>When using the Android kernel, dm-verity is turned on when the kernel is built. For details, see <a href="dm-verity.html">Implementing dm-verity</a>.</p>
+<p>After switching to block-oriented OTAs, incorporate the latest Android kernel
+or use a stock upstream kernel and enable dm-verity support by including the
+relevant configuration option <code>CONFIG_DM_VERITY</code>.</p>
+
+<p>When using the Android kernel, dm-verity is turned on when the kernel is
+built. For details, see <a href="dm-verity.html">Implementing dm-verity</a>.</p>
<h2 id="supporting-docs">Supporting documentation</h2>
<p><a href="verified-boot.html">Verifying Boot</a><br/>
<a href="{@docRoot}devices/tech/ota/block.html">Block-Based OTA</a><br/>
<a href="dm-verity.html">Implementing dm-verity</a><br/>
-<a href="https://code.google.com/p/cryptsetup/wiki/DMVerity">cryptsetup - dm-verity: device-mapper block integrity checking
-target</a><br/>
-<a href="http://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot">The Chromium Projects - Verified
-Boot</a><br/>
+<a href="https://gitlab.com/cryptsetup/cryptsetup/wikis/DMVerity">cryptsetup -
+dm-verity: device-mapper block integrity checking target</a><br/>
+<a href="http://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot">The
+Chromium Projects - Verified Boot</a><br/>
<a
-href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/device-mapper/verity.txt">Linux Kernel Documentation:
-verity.txt</a></p>
+href="http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/device-mapper/verity.txt">Linux Kernel Documentation: verity.txt</a></p>
-<p>For additional assistance, contact <a href="mailto:security@android.com">security@android.com</a>.</p>
+<p>For additional assistance, contact
+<a href="mailto:security@android.com">security@android.com</a>.</p>
\ No newline at end of file
diff --git a/src/images/jack-library-file.png b/src/images/jack-library-file.png
new file mode 100644
index 0000000..b25dd85
--- /dev/null
+++ b/src/images/jack-library-file.png
Binary files differ
diff --git a/src/images/jack-overview.png b/src/images/jack-overview.png
new file mode 100644
index 0000000..74d396f
--- /dev/null
+++ b/src/images/jack-overview.png
Binary files differ
diff --git a/src/images/jill.png b/src/images/jill.png
new file mode 100644
index 0000000..0d9ba14
--- /dev/null
+++ b/src/images/jill.png
Binary files differ
diff --git a/src/images/pre-dex.png b/src/images/pre-dex.png
new file mode 100644
index 0000000..4d39700
--- /dev/null
+++ b/src/images/pre-dex.png
Binary files differ
diff --git a/src/index.jd b/src/index.jd
index b77ab6e..02f6a7d 100644
--- a/src/index.jd
+++ b/src/index.jd
@@ -33,6 +33,7 @@
devices meet compatibility requirements.
</p>
+<h2 align="center">Android 6.0 Updates Available — see details below</h2>
</div>
</div>
@@ -42,6 +43,27 @@
<div class="landing-docs">
<div class="col-8">
<h3>What's New</h3>
+<a href="{@docRoot}compatibility/index.html">
+ <h4>6.0 Compatibility Definition Document</h4></a>
+ <p>The <strong><a
+ href="{@docRoot}compatibility/android-cdd.pdf">Android 6.0
+ Compatibility Definition Document (CDD)</a></strong>
+ has been published to source.android.com. It contains a changelog that
+ summarizes updates. Use the <strong>Send Feedback</strong> button at
+ the bottom of any page to provide input on the CDD or any other contents of
+ this site.</p>
+
+<a href="{@docRoot}devices/audio/index.html">
+ <h4>MIDI, Audio Latency, and Path Updates</h4></a>
+ <p>Instructions now exist for <strong><a
+ href="{@docRoot}devices/audio/midi_test.html">Testing MIDI</a></strong>
+ functionality. And Android 6.0 results have been added to <strong><a
+ href="{@docRoot}devices/audio/latency_measurements.html#measurements">Audio Latency
+ Measurements</a></strong>. Finally, the path to the audio hardware abstraction
+ layer has moved to <code>system/media/audio/include/system/audio*</code> in
+ <strong><a href="{@docRoot}devices/audio/implement.html">Audio
+ Implementation</a></strong>.</p>
+
<a href="{@docRoot}source/build-numbers.html">
<h4>Android 6.0 and 5.1 Build Numbers and CTS Packages</h4></a>
<p>You can now find <strong><a
@@ -53,7 +75,7 @@
5.1</a></strong>.</p>
<a href="{@docRoot}devices/halref/index.html">
- <h4>HAL and Trad Fed Reference Files</h4></a>
+ <h4>HAL and Trade Federation Reference Files</h4></a>
<p>Both the <strong><a
href="{@docRoot}devices/halref/index.html">Hardware Abstraction Layer
(HAL)</a></strong> and <strong><a
@@ -90,27 +112,6 @@
features</a></strong> and an <strong><a
href="{@docRoot}devices/tech/security/authentication/km-implementer-ref.html">implementer's
reference</a></strong>.</p>
-
-<a href="{@docRoot}devices/storage/index.html">
- <h4>Adoptable Storage</h4></a>
- <p>The <strong><a
- href="{@docRoot}devices/storage/index.html">Storage</a></strong>
- section has been revised to introduce <strong><a
- href="{@docRoot}devices/storage/adoptable.html">adoptable
- storage</a></strong> that can hold app data and distinguish between it and <strong><a
- href="{@docRoot}devices/storage/traditional.html">traditional
- storage</a></strong>.</p>
-
-<a href="{@docRoot}devices/tech/config/index.html">
- <h4>Configuration</h4></a>
- <p>Instructions now exist for configuring <strong><a
- href="{@docRoot}devices/tech/config/runtime_perms.html">runtime permissions</a></strong>,
- <strong><a href="{@docRoot}devices/tech/config/voicemail.html">visual
- voicemail</a></strong>, and Android's new <strong><a
- href="{@docRoot}devices/tech/config/filesystem.html">file
- system</a></strong>. And carriers get <strong><a
- href="{@docRoot}devices/tech/config/carrier.html">custom
- configuration</a></strong>.</p>
</div>
<div class="col-8">
diff --git a/src/source/jack.jd b/src/source/jack.jd
new file mode 100644
index 0000000..7abead7
--- /dev/null
+++ b/src/source/jack.jd
@@ -0,0 +1,357 @@
+page.title=Jack (Java Android Compiler Kit)
+@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=the_jack_toolchain>The Jack toolchain</h2>
+
+<p>Jack (Java Android Compiler Kit) is a new Android toolchain that compiles Java
+source into Android dex bytecode. It replaces the previous Android toolchain,
+which consists of multiple tools, such as javac, ProGuard, jarjar, and dx.</p>
+
+<p>The Jack toolchain provides the following advantages:</p>
+
+<ul>
+ <li> <strong>Completely open source</strong><br>
+Available in AOSP; partners are welcome to contribute.
+ <li> <strong>Speeds compilation time</strong><br>
+
+Jack has specific supports to reduce compilation time: pre-dexing, incremental
+compilation and a Jack compilation server.
+ <li> <strong>Handles shrinking, obfuscation, repackaging and multidex</strong><br>
+Using a separate package such as ProGuard is no longer necessary.
+</ul>
+
+<img src="{@docRoot}images/jack-overview.png" height="75%" width="75%" alt="Jack overview" />
+<p class="img-caption"><strong>Figure 1. </strong>Jack (Java Android Compiler Kit)</p>
+
+<h2 id=the_jack_library_format>The .jack library format</h2>
+
+<p>Jack has its own .jack file format, which contains the pre-compiled dex code
+for the library, allowing for faster compilation (pre-dex).</p>
+
+<img src="{@docRoot}images/jack-library-file.png" height="75%" width="75%" alt="Jack library file contents" />
+<p class="img-caption"><strong>Figure 2. </strong>Jack library file contents</p>
+
+<h2 id=jack_intermediate_library_linker_jill>Jack Intermediate Library Linker (Jill)</h2>
+
+<p>The Jill tool translates the existing .jar libraries into the new library
+format, as shown below.</p>
+
+<img src="{@docRoot}images/jill.png" alt="Importing existing .jar libraries using Jill" />
+<p class="img-caption"><strong>Figure 3. </strong>Workflow to import an existing .jar library</p>
+
+<h2 id=using_jack_in_your_android_build>Using Jack in your Android build</h2>
+
+<p>You don’t have to do anything differently to use Jack — just use your standard
+makefile commands to compile the tree or your project. Jack is the default
+Android build toolchain for M.</p>
+
+<p>The first time Jack is used, it launches a local Jack compilation server on
+your computer:</p>
+
+<ul>
+ <li> This server brings an intrinsic speedup, because it avoids launching a new host
+JRE JVM, loading Jack code, initializing Jack and warming up the JIT at each
+compilation. It also provides very good compilation times during small
+compilations (e.g. in incremental mode).
+ <li> The server is also a short-term solution to control the number of parallel Jack
+compilations, and so to avoid overloading your computer (memory or disk issue),
+because it limits the number of parallel compilations.
+</ul>
+
+<p>The Jack server shuts itself down after an idle time without any compilation.
+It uses two TCP ports on the localhost interface, and so is not available
+externally. All these parameters (number of parallel compilations, timeout,
+ports number, etc) can be modified by editing the<code> $HOME/.jack</code> file.</p>
+
+<h3 id=$home_jack_file>$HOME/.jack file</h3>
+
+<p>The <code>$HOME/.jack</code> file contains settings for Jack server variables, in a full bash syntax. </p>
+
+<p>Here are the available settings, with their definitions and default values:</p>
+
+<ul>
+ <li> <strong><code>SERVER=true</strong> </code>Enable the server feature of Jack.
+ <li> <strong><code>SERVER_PORT_SERVICE=8072</code>
+</strong>Set the TCP port number of the server for compilation purposes.
+ <li> <strong><code>SERVER_PORT_ADMIN=8073</code></strong>
+Set the TCP port number of the server for admin purposes.
+ <li> <strong><code>SERVER_COUNT=1</code></strong>
+Unused at present.
+ <li> <strong><code>SERVER_NB_COMPILE=4</code></strong>
+Maximum number of parallel compilations allowed.
+ <li> <strong><code>SERVER_TIMEOUT=60</code></strong>
+Number of idle seconds the server has to wait without any compilation before
+shutting itself down.
+ <li> <strong><code>SERVER_LOG=${SERVER_LOG:=$SERVER_DIR/jack-$SERVER_PORT_SERVICE.log}</code></strong>
+File where server logs are written. By default, this variable can be
+overloaded by an environment variable.
+ <li> <strong><code>JACK_VM_COMMAND=${JACK_VM_COMMAND:=java}</code></strong>
+The default command used to launch a JVM on the host. By default, this
+variable can be overloaded by environment variable.
+</ul>
+
+<h3 id=jack_troubleshooting>Jack troubleshooting</h3>
+
+<p><strong>If your computer becomes unresponsive during compilation or if you experience
+Jack compilations failing on “Out of memory error”</strong></p>
+
+<p>You can improve the situation by reducing the number of Jack simultaneous
+compilations by editing your<code> $HOME/.jack</code> and changing<code> SERVER_NB_COMPILE</code> to a lower value.</p>
+
+<p><strong>If your compilations are failing on “Cannot launch background server”</strong></p>
+
+<p>The most likely cause is TCP ports are already used on your computer. Try to
+change it by editing your <code>$HOME/.jack </code>(<code>SERVER_PORT_SERVICE</code> and <code>SERVER_PORT_ADMIN</code> variables).</p>
+
+<p>If it doesn’t solve the problem, please report and attach your compilation log
+and the Jack server log (see ‘Finding the Jack log’ below to know where to find
+the server log file). To unblock the situation, disable jack compilation server
+by editing your <code>$HOME/.jack</code> and changing <code>SERVER</code> to false. Unfortunately this will significantly slow down your compilation and
+may force you to launch <code>make -j</code> with load control (option "<code>-l</code>" of <code>make</code>). </p>
+
+<p><strong>If your compilation gets stuck without any progress</strong></p>
+
+<p>Please report this and give us the following additional information (where
+possible):</p>
+
+<ul>
+ <li> The command line at which you are stuck.
+ <li> The output of this command line.
+ <li> The result of executing <code>jack-admin server-stat</code>.
+ <li> The <code>$HOME/.jack</code> file.
+ <li> The content of the server log with the server state dumped. To get this —
+ <ul>
+ <li> Find the Jack background server process by running <code>jack-admin list-server</code>.
+ <li> Send a <code>kill -3</code> command to this server to dump its state into the log file.
+ <li> To locate the server log file, see ‘Finding the Jack log’ below.
+ </ul>
+ <li> The result of executing <code>ls -lR $TMPDIR/jack-$USER.</code>
+ <li> The result of running <code>ps j -U $USER.</code>
+</ul>
+
+<p>You should be able to unblock yourself by killing the Jack background server
+(use <code>jack-admin kill-server</code>), and then by removing its temporary directories contained in <code>jack-$USER</code> of your temporary directory (<code>/tmp</code> or <code>$TMPDIR</code>).</p>
+
+<p><strong>If you have any other issues </strong></p>
+
+<p>To report bugs or request features, please use our public issue tracker,
+available at <a href="http://b.android.com">http://b.android.com</a>, with the <a href="https://code.google.com/p/android/issues/entry?template=Jack%20bug%20report">Jack tool bug report</a> or <a href="https://code.google.com/p/android/issues/entry?template=Jack%20feature%20request">Jack tool feature request</a> templates. Please attach the Jack log to the bug report. </p>
+<table>
+ <tr>
+ <td><strong>Finding the Jack log</strong>
+<ul>
+ <li> If you ran a make command with a dist target, the Jack log is located at <code>$ANDROID_BUILD_TOP/out/dist/logs/jack-server.log</code>
+ <li> Otherwise you can find it in by running <code>jack-admin server-log</code>
+</ul>
+</td>
+ </tr>
+</table>
+
+<p>In case of reproducible Jack failures, you can get a more detailed log by
+setting one variable, as follows:</p>
+
+<pre class=prettyprint>
+$ export ANDROID_JACK_EXTRA_ARGS= "--verbose debug --sanity-checks on -D
+sched.runner=single-threaded"
+</pre>
+
+<p>Then use your standard makefile commands to compile the tree or your project
+and attach its standard output and error.</p>
+
+<p>To remove detailed build logs use:</p>
+
+<pre class=prettyprint>
+$ unset ANDROID_JACK_EXTRA_ARGS
+</pre>
+
+<h3 id=jack_limitations>Jack limitations</h3>
+
+<ul>
+ <li> The Jack server is mono-user by default, so can be only used by one user on a
+computer. If it is not the case, please, choose different port numbers for each
+user and adjust SERVER_NB_COMPILE accordingly. You can also disable the Jack
+server by setting SERVER=false in your $HOME/.jack.
+ <li> CTS compilation is slow due to current vm-tests-tf integration.
+ <li> Bytecode manipulation tools, like JaCoCo, are not supported.
+</ul>
+
+<h2 id=using_jack_features>Using Jack features</h2>
+
+<p>Jack supports Java programming language 1.7 and integrates additional features
+described below.</p>
+
+<h3 id=predexing>Predexing </h3>
+
+<p>When generating a JACK library file, the .dex of the library is generated and
+stored inside the .jack library file as a pre-dex. When compiling, JACK reuses
+the pre-dex from each library.</p>
+
+<p>All libraries are pre-dexed.</p>
+
+<img src="{@docRoot}images/pre-dex.png" height="75%" width="75%" alt="Jack libraries with pre-dex" />
+<p class="img-caption"><strong>Figure 4. </strong>Jack libraries with pre-dex</p>
+
+<h4 id=limitations>Limitations</h4>
+
+
+<p>Currently, JACK does not reuse the library pre-dex if
+shrinking/obfuscation/repackaging is used in the compilation.</p>
+
+<h3 id=incremental_compilation>Incremental compilation</h3>
+
+
+<p>Incremental compilation means that only components that were touched since the
+last compilation, and their dependencies, are recompiled. Incremental
+compilation can be significantly faster than a full compilation when changes
+are limited to only a limited set of components.</p>
+
+<h4 id=limitations>Limitations</h4>
+
+
+<p>Incremental compilation is deactivated when shrinking, obfuscation, repackaging
+or multi-dex legacy is enabled.</p>
+
+<h4 id=enabling_incremental_builds>Enabling incremental builds</h4>
+
+
+<p>Currently incremental compilation is not enabled by default. To enable
+incremental builds, add the following line to the Android.mk file of the
+project that you want to build incrementally:</p>
+
+<pre class=prettyprint>
+LOCAL_JACK_ENABLED := incremental
+</pre>
+
+<p class="note"><strong>Note:</strong> The first time that you build your project with Jack if some dependencies
+are not built, use <code>mma</code> to build them, and after that you can use the standard build command.</p>
+
+<h3 id=shrinking_and_obfuscation>Shrinking and Obfuscation</h3>
+
+<p>JACK has shrinking and obfuscation support and uses proguard configuration
+files to enable shrinking and obfuscation features. Here are the supported and
+ignored options:</p>
+
+<h4 id=supported_common_options>Supported common options</h4>
+
+
+<p>Common options include the following:</p>
+
+<ul>
+ <li> <code>@</code>
+ <li> <code>-include</code>
+ <li> <code>-basedirectory</code>
+ <li> <code>-injars</code>
+ <li> <code>-outjars // only 1 output jar supported</code>
+ <li> <code>-libraryjars</code>
+ <li> <code>-keep</code>
+ <li> <code>-keepclassmembers</code>
+ <li> <code>-keepclasseswithmembers</code>
+ <li> <code>-keepnames</code>
+ <li> <code>-keepclassmembernames</code>
+ <li> <code>-keepclasseswithmembernames</code>
+ <li> <code>-printseeds</code>
+</ul>
+
+<h4 id=supported_shrinking_options>Supported shrinking options</h4>
+
+
+<p>Shrinking options include the following:</p>
+
+<ul>
+ <li> <code>-dontshrink</code>
+</ul>
+
+<h4 id=supported_obfuscation_options>Supported obfuscation options</h4>
+
+
+<p>Obfuscation options include the following:</p>
+
+<ul>
+ <li> <code>-dontobfuscate</code>
+ <li> <code>-printmapping</code>
+ <li> <code>-applymapping</code>
+ <li> <code>-obfuscationdictionary</code>
+ <li> <code>-classobfuscationdictionary</code>
+ <li> <code>-packageobfuscationdictionary</code>
+ <li> <code>-useuniqueclassmembernames</code>
+ <li> <code>-dontusemixedcaseclassnames</code>
+ <li> <code>-keeppackagenames</code>
+ <li> <code>-flattenpackagehierarchy</code>
+ <li> <code>-repackageclasses</code>
+ <li> <code>-keepattributes</code>
+ <li> <code>-adaptclassstrings</code>
+</ul>
+
+<h4 id=ignored_options>Ignored options</h4>
+
+
+<p>Ignored options include the following:</p>
+
+<ul>
+ <li> <code>-dontoptimize // Jack does not optimize</code>
+ <li> <code>-dontpreverify // Jack does not preverify</code>
+ <li> <code>-skipnonpubliclibraryclasses</code>
+ <li> <code>-dontskipnonpubliclibraryclasses</code>
+ <li> <code>-dontskipnonpubliclibraryclassmembers</code>
+ <li> <code>-keepdirectories</code>
+ <li> <code>-target</code>
+ <li> <code>-forceprocessing</code>
+ <li> <code>-printusage</code>
+ <li> <code>-whyareyoukeeping</code>
+ <li> <code>-optimizations</code>
+ <li> <code>-optimizationpasses</code>
+ <li> <code>-assumenosideeffects</code>
+ <li> <code>-allowaccessmodification</code>
+ <li> <code>-mergeinterfacesaggressively</code>
+ <li> <code>-overloadaggressively</code>
+ <li> <code>-microedition</code>
+ <li> <code>-verbose</code>
+ <li> <code>-dontnote</code>
+ <li> <code>-dontwarn</code>
+ <li> <code>-ignorewarnings</code>
+ <li> <code>-printconfiguration</code>
+ <li> <code>-dump</code>
+</ul>
+
+<p class="note"><strong>Note:</strong> Other options will generate an error.</p>
+
+<h3 id=repackaging>Repackaging</h3>
+
+<p>JACK uses jarjar configuration files to do the repackaging.</p>
+
+<p class="note"><strong>Note:</strong> JACK is compatible with "rule" rule types, but is not compatible with "zap" or
+"keep" rule types. If you need "zap" or "keep" rule types please file a feature
+request with a description of how you use the feature in your app.</p>
+
+<h3 id=multidex_support>Multidex support</h3>
+
+
+<p>Since dex files are limited to 65K methods, apps with over 65K methods must be
+split into multiple dex files. (See <a href="http://developer.android.com/tools/building/multidex.html">‘Building Apps with Over 65K Methods’</a> for more information about multidex.)</p>
+
+<p>Jack offers native and legacy multidex support. </p>
+
