diff --git a/src/compatibility/4.4/android-4.4-cdd.xhtml b/src/compatibility/4.4/android-4.4-cdd.xhtml
new file mode 100644
index 0000000..3aacabb
--- /dev/null
+++ b/src/compatibility/4.4/android-4.4-cdd.xhtml
@@ -0,0 +1,3023 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+<head>
+<title>Android 4.4 Compatibility Definition</title>
+<link rel="stylesheet" type="text/css" href="cdd.css"/>
+</head>
+<body>
+<div><img src="header.jpg" alt="Android logo"/></div>
+<h1>Android 4.4 Compatibility Definition</h1>
+<!--
+<span style="color: red; font-weight: bold;"><h2>Revision 1</h2></span><br/>
+<span style="color: red;">Last updated: July 23, 2013</span>
+-->
+<p><b><font color="red">Revision 1</font></b><br/>
+Last updated: November 27, 2013
+</p>
+<p>Copyright &copy; 2013, Google Inc. All rights reserved.<br/>
+<a href="mailto:compatibility@android.com">compatibility@android.com</a>
+</p>
+
+<h2>Table of Contents</h2>
+<div style="margin-left: 2em;">
+  <a href="#section-1">1. Introduction</a><br/>
+  <a href="#section-2">2. Resources</a><br/>
+  <a href="#section-3">3. Software</a><br/>
+  <div style="margin-left: 2em;">
+    <a href="#section-3.1">3.1. Managed API Compatibility</a><br/>
+    <a href="#section-3.2">3.2. Soft API Compatibility</a><br/>
+    <div style="margin-left: 2em;">
+      <a href="#section-3.2.1">3.2.1. Permissions</a><br/>
+      <a href="#section-3.2.2">3.2.2. Build Parameters</a><br/>
+      <a href="#section-3.2.3">3.2.3. Intent Compatibility</a><br/>
+      <div style="margin-left: 2em;">
+        <a href="#section-3.2.3.1">3.2.3.1. Core Application Intents</a><br/>
+        <a href="#section-3.2.3.2">3.2.3.2. Intent Overrides</a><br/>
+        <a href="#section-3.2.3.3">3.2.3.3. Intent Namespaces</a><br/>
+        <a href="#section-3.2.3.4">3.2.3.4. Broadcast Intents</a><br/>
+        <a href="#section-3.2.3.5">3.2.3.5. Default App Settings</a><br/>
+      </div>
+    </div>
+    <a href="#section-3.3">3.3. Native API Compatibility</a><br/>
+    <div style="margin-left: 2em;">
+      <a href="#section-3.3.1">3.3.1 Application Binary Interfaces</a><br/>
+    </div>
+    <a href="#section-3.4">3.4. Web Compatibility</a><br/>
+    <div style="margin-left: 2em;">
+      <a href="#section-3.4.1">3.4.1. WebView Compatibility</a><br/>
+      <a href="#section-3.4.2">3.4.2. Browser Compatibility</a><br/>
+    </div>
+    <a href="#section-3.5">3.5. API Behavioral Compatibility</a><br/>
+    <a href="#section-3.6">3.6. API Namespaces</a><br/>
+    <a href="#section-3.7">3.7. Virtual Machine Compatibility</a><br/>
+    <a href="#section-3.8">3.8. User Interface Compatibility</a><br/>
+    <div style="margin-left: 2em;">
+      <a href="#section-3.8.1">3.8.1. Launcher (Home Screen)</a><br/>
+      <a href="#section-3.8.2">3.8.2. Widgets</a><br/>
+      <a href="#section-3.8.3">3.8.3. Notifications</a><br/>
+      <a href="#section-3.8.4">3.8.4. Search</a><br/>
+      <a href="#section-3.8.5">3.8.5. Toasts</a><br/>
+      <a href="#section-3.8.6">3.8.6. Themes</a><br/>
+      <a href="#section-3.8.7">3.8.7. Live Wallpapers</a><br/>
+      <a href="#section-3.8.8">3.8.8. Recent Application Display</a><br/>
+      <a href="#section-3.8.9">3.8.9. Input Management</a><br/>
+      <a href="#section-3.8.10">3.8.10. Lock Screen Media Remote Control</a><br/>
+      <a href="#section-3.8.11">3.8.11. Dreams</a><br/>
+      <a href="#section-3.8.12">3.8.12. Location</a><br/>
+      <a href="#section-3.8.13">3.8.13. Unicode</a><br/>
+    </div>
+    <a href="#section-3.9">3.9 Device Administration</a><br/>
+    <a href="#section-3.10">3.10 Accessibility</a><br/>
+    <a href="#section-3.11">3.11 Text-to-Speech</a><br/>
+  </div>
+  <a href="#section-4">4. Application Packaging Compatibility</a><br/>
+  <a href="#section-5">5. Multimedia Compatibility</a><br/>
+    <div style="margin-left: 2em;">
+      <a href="#section-5.1">5.1. Media Codecs</a><br/>
+      <a href="#section-5.2">5.2. Video Encoding</a><br/>
+      <a href="#section-5.3">5.3. Video Decoding</a><br/>
+      <a href="#section-5.4">5.4. Audio Recording</a><br/>
+      <a href="#section-5.5">5.5. Audio Latency</a><br/>
+      <a href="#section-5.6">5.6. Network Protocols</a><br/>
+    </div>
+  <a href="#section-6">6. Developer Tools and Options Compatibility</a><br/>
+    <div style="margin-left: 2em;">
+      <a href="#section-6.1">6.1. Developer Tools</a><br/>
+      <a href="#section-6.2">6.2. Developer Options</a><br/>
+      <a href="#section-6.2.1">6.2.1. Experimental</a><br/>
+    </div>
+  <a href="#section-7">7. Hardware Compatibility</a><br/>
+  <div style="margin-left: 2em;">
+    <a href="#section-7.1">7.1. Display and Graphics</a><br/>
+    <div style="margin-left: 2em;">
+      <a href="#section-7.1.1">7.1.1. Screen Configuration</a><br/>
+      <a href="#section-7.1.2">7.1.2. Display Metrics</a><br/>
+      <a href="#section-7.1.3">7.1.3. Screen Orientation</a><br/>
+      <a href="#section-7.1.4">7.1.4. 2D and 3D Graphics Acceleration</a><br/>
+      <a href="#section-7.1.5">7.1.5. Legacy Application Compatibility Mode</a><br/>
+      <a href="#section-7.1.6">7.1.6. Screen Types</a><br/>
+      <a href="#section-7.1.7">7.1.7. Screen Technology</a><br/>
+      <a href="#section-7.1.8">7.1.8. External Displays</a><br/>
+    </div>
+    <a href="#section-7.2">7.2. Input Devices</a><br/>
+    <div style="margin-left: 2em;">
+      <a href="#section-7.2.1">7.2.1. Keyboard</a><br/>
+      <a href="#section-7.2.2">7.2.2. Non-touch Navigation</a><br/>
+      <a href="#section-7.2.3">7.2.3. Navigation keys</a><br/>
+      <a href="#section-7.2.4">7.2.4. Touchscreen input</a><br/>
+      <a href="#section-7.2.5">7.2.5. Fake touch input</a><br/>
+      <a href="#section-7.2.6">7.2.6. Microphone</a><br/>
+    </div>
+    <a href="#section-7.3">7.3. Sensors</a><br/>
+    <div style="margin-left: 2em;">
+      <a href="#section-7.3.1">7.3.1. Accelerometer</a><br/>
+      <a href="#section-7.3.2">7.3.2. Magnetometer</a><br/>
+      <a href="#section-7.3.3">7.3.3. GPS</a><br/>
+      <a href="#section-7.3.4">7.3.4. Gyroscope</a><br/>
+      <a href="#section-7.3.5">7.3.5. Barometer</a><br/>
+      <a href="#section-7.3.6">7.3.6. Thermometer</a><br/>
+      <a href="#section-7.3.7">7.3.7. Photometer</a><br/>
+      <a href="#section-7.3.8">7.3.8. Proximity Sensor</a><br/>
+    </div>
+    <a href="#section-7.4">7.4. Data Connectivity</a><br/>
+    <div style="margin-left: 2em;">
+      <a href="#section-7.4.1">7.4.1. Telephony</a><br/>
+      <a href="#section-7.4.2">7.4.2. IEEE 802.11 (Wi-Fi)</a><br/>
+      <div style="margin-left: 2em;">
+        <a href="#section-7.4.2.1">7.4.2.1. Wi-Fi Direct</a><br/>
+        <a href="#section-7.4.2.2">7.4.2.2. Wi-Fi Tunneled Direct Link Setup</a><br/>
+      </div>
+      <a href="#section-7.4.3">7.4.3. Bluetooth</a><br/>
+      <a href="#section-7.4.4">7.4.4. Near-Field Communications</a><br/>
+      <a href="#section-7.4.5">7.4.5. Minimum Network Capability</a><br/>
+      <a href="#section-7.4.6">7.4.6. Sync Settings</a><br/>
+    </div>
+    <a href="#section-7.5">7.5. Cameras</a><br/>
+    <div style="margin-left: 2em;">
+      <a href="#section-7.5.1">7.5.1. Rear-Facing Camera</a><br/>
+      <a href="#section-7.5.2">7.5.2. Front-Facing Camera</a><br/>
+      <a href="#section-7.5.3">7.5.3. Camera API Behavior</a><br/>
+      <a href="#section-7.5.4">7.5.4. Camera Orientation</a><br/>
+    </div>
+    <a href="#section-7.6">7.6. Memory and Storage</a><br/>
+    <div style="margin-left: 2em;">
+      <a href="#section-7.6.1">7.6.1. Minimum Memory and Storage</a><br/>
+      <a href="#section-7.6.2">7.6.2. Shared External Storage</a><br/>
+    </div>
+    <a href="#section-7.7">7.7. USB</a><br/>
+  </div>
+  <a href="#section-8">8. Performance Compatibility</a><br/>
+  <a href="#section-9">9. Security Model Compatibility</a><br/>
+  <div style="margin-left: 2em;">
+    <a href="#section-9.1">9.1. Permissions</a><br/>
+    <a href="#section-9.2">9.2. UID and Process Isolation</a><br/>
+    <a href="#section-9.3">9.3. Filesystem Permissions</a><br/>
+    <a href="#section-9.4">9.4. Alternate Execution Environments</a><br/>
+    <a href="#section-9.5">9.5. Multi-User Support</a><br/>
+    <a href="#section-9.6">9.6. Premium SMS Warning</a><br/>
+    <a href="#section-9.7">9.7. Kernel Security Features</a><br/>
+    <a href="#section-9.8">9.8. Privacy</a><br/>
+    <a href="#section-9.9">9.9. Full-Disk Encryption</a><br/>
+  </div>
+  <a href="#section-10">10. Software Compatibility Testing</a><br/>
+  <div style="margin-left: 2em;">
+    <a href="#section-10.1">10.1. Compatibility Test Suite</a><br/>
+    <a href="#section-10.2">10.2. CTS Verifier</a><br/>
+    <a href="#section-10.3">10.3. Reference Applications</a><br/>
+  </div>
+  <a href="#section-11">11. Updatable Software</a><br/>
+  <a href="#section-12">12. Document Changelog</a><br/>
+  <a href="#section-13">13. Contact Us</a><br/>
+</div>
+
+<div style="page-break-before: always;"></div>
+
+<a name="section-1"></a><h2 id="section-1">1. Introduction</h2>
+<p>This document enumerates the requirements that must be met in order for
+devices to be compatible with Android 4.4.</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="#resources01">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
+4.4. A "device implementation" or "implementation" is the hardware/software
+solution so developed.</p>
+<p>To be considered compatible with Android 4.4, 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="#section-10">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="#resources03">Resources, 3</a>] is both the reference and preferred
+implementation of Android. Device implementers are strongly encouraged 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, 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>
+<a name="section-2"></a><h2 id="section-2">2. Resources</h2>
+<ol>
+<a name="resources01"></a><li id="resources01">IETF RFC2119 Requirement Levels: <a href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a></li>
+<a name="resources02"></a><li id="resources02">Android Compatibility Program Overview: <a href="http://source.android.com/compatibility/index.html">http://source.android.com/compatibility/index.html</a></li>
+<a name="resources03"></a><li id="resources03">Android Open Source Project: <a href="http://source.android.com/">http://source.android.com/</a></li>
+<a name="resources04"></a><li id="resources04">API definitions and documentation: <a href="http://developer.android.com/reference/packages.html">http://developer.android.com/reference/packages.html</a></li>
+<a name="resources05"></a><li id="resources05">Android Permissions reference: <a href="http://developer.android.com/reference/android/Manifest.permission.html">http://developer.android.com/reference/android/Manifest.permission.html</a></li>
+<a name="resources06"></a><li id="resources06">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></li>
+<a name="resources07"></a><li id="resources07">Android 4.4 allowed version strings: <a href="http://source.android.com/compatibility/4.4/versions.html">http://source.android.com/compatibility/4.4/versions.html</a></li>
+<a name="resources08"></a><li id="resources08">Renderscript: <a href="http://developer.android.com/guide/topics/graphics/renderscript.html">http://developer.android.com/guide/topics/graphics/renderscript.html</a></li>
+<a name="resources09"></a><li id="resources09">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></li>
+<a name="resources10"></a><li id="resources10">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></li>
+<a name="resources11"></a><li id="resources11">HTML5: <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/">http://www.whatwg.org/specs/web-apps/current-work/multipage/</a></li>
+<a name="resources12"></a><li id="resources12">HTML5 offline capabilities: <a href="http://dev.w3.org/html5/spec/Overview.html#offline">http://dev.w3.org/html5/spec/Overview.html#offline</a></li>
+<a name="resources13"></a><li id="resources13">HTML5 video tag: <a href="http://dev.w3.org/html5/spec/Overview.html#video">http://dev.w3.org/html5/spec/Overview.html#video</a></li>
+<a name="resources14"></a><li id="resources14">HTML5/W3C geolocation API: <a href="http://www.w3.org/TR/geolocation-API/">http://www.w3.org/TR/geolocation-API/</a></li>
+<a name="resources15"></a><li id="resources15">HTML5/W3C webstorage API: <a href="http://www.w3.org/TR/webstorage/">http://www.w3.org/TR/webstorage/</a></li>
+<a name="resources16"></a><li id="resources16">HTML5/W3C IndexedDB API: <a href="http://www.w3.org/TR/IndexedDB/">http://www.w3.org/TR/IndexedDB/</a></li>
+<a name="resources17"></a><li id="resources17">Dalvik Virtual Machine specification: available in the Android source code, at dalvik/docs</li>
+<a name="resources18"></a><li id="resources18">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></li>
+<a name="resources19"></a><li id="resources19">Notifications: <a href="http://developer.android.com/guide/topics/ui/notifiers/notifications.html">http://developer.android.com/guide/topics/ui/notifiers/notifications.html</a></li>
+<a name="resources20"></a><li id="resources20">Application Resources: <a href="http://code.google.com/android/reference/available-resources.html">http://code.google.com/android/reference/available-resources.html</a></li>
+<a name="resources21"></a><li id="resources21">Status Bar icon style guide: <a href="http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html">http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html</a></li>
+<a name="resources22"></a><li id="resources22">Search Manager: <a href="http://developer.android.com/reference/android/app/SearchManager.html">http://developer.android.com/reference/android/app/SearchManager.html</a></li>
+<a name="resources23"></a><li id="resources23">Toasts: <a href="http://developer.android.com/reference/android/widget/Toast.html">http://developer.android.com/reference/android/widget/Toast.html</a></li>
+<a name="resources24"></a><li id="resources24">Themes: <a href="http://developer.android.com/guide/topics/ui/themes.html">http://developer.android.com/guide/topics/ui/themes.html</a></li>
+<a name="resources25"></a><li id="resources25">R.style class: <a href="http://developer.android.com/reference/android/R.style.html">http://developer.android.com/reference/android/R.style.html</a></li>
+<a name="resources26"></a><li id="resources26">Live Wallpapers: <a href="http://developer.android.com/resources/articles/live-wallpapers.html">http://developer.android.com/resources/articles/live-wallpapers.html</a></li>
+<a name="resources27"></a><li id="resources27">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></li>
+<a name="resources28"></a><li id="resources28">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></li>
+<a name="resources29"></a><li id="resources29">Android Accessibility Service APIs: <a href="http://developer.android.com/reference/android/accessibilityservice/package-summary.html">http://developer.android.com/reference/android/accessibilityservice/package-summary.html</a></li>
+<a name="resources30"></a><li id="resources30">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></li>
+<a name="resources31"></a><li id="resources31">Eyes Free project: <a href="http://http://code.google.com/p/eyes-free">http://code.google.com/p/eyes-free</a></li>
+<a name="resources32"></a><li id="resources32">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></li>
+<a name="resources33"></a><li id="resources33">Reference tool documentation (for adb, aapt, ddms, systrace): <a href="http://developer.android.com/guide/developing/tools/index.html">http://developer.android.com/guide/developing/tools/index.html</a></li>
+<a name="resources34"></a><li id="resources34">Android apk file description: <a href="http://developer.android.com/guide/topics/fundamentals.html">http://developer.android.com/guide/topics/fundamentals.html</a></li>
+<a name="resources35"></a><li id="resources35">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></li>
+<a name="resources36"></a><li id="resources36">Monkey testing tool: <a href="http://developer.android.com/guide/developing/tools/monkey.html">http://developer.android.com/guide/developing/tools/monkey.html</a></li>
+<a name="resources37"></a><li id="resources37">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></li>
+<a name="resources38"></a><li id="resources38">Supporting Multiple Screens: <a href="http://developer.android.com/guide/practices/screens_support.html">http://developer.android.com/guide/practices/screens_support.html</a></li>
+<a name="resources39"></a><li id="resources39">android.util.DisplayMetrics: <a href="http://developer.android.com/reference/android/util/DisplayMetrics.html">http://developer.android.com/reference/android/util/DisplayMetrics.html</a></li>
+<a name="resources40"></a><li id="resources40">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></li>
+<a name="resources41"></a><li id="resources41">android.hardware.SensorEvent: <a href="http://developer.android.com/reference/android/hardware/SensorEvent.html">http://developer.android.com/reference/android/hardware/SensorEvent.html</a></li>
+<a name="resources42"></a><li id="resources42">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></li>
+<a name="resources43"></a><li id="resources43">NDEF Push Protocol: <a href="http://source.android.com/compatibility/ndef-push-protocol.pdf">http://source.android.com/compatibility/ndef-push-protocol.pdf</a></li>
+<a name="resources44"></a><li id="resources44">MIFARE MF1S503X: <a href="http://www.nxp.com/documents/data_sheet/MF1S503x.pdf">http://www.nxp.com/documents/data_sheet/MF1S503x.pdf</a></li>
+<a name="resources45"></a><li id="resources45">MIFARE MF1S703X: <a href="http://www.nxp.com/documents/data_sheet/MF1S703x.pdf">http://www.nxp.com/documents/data_sheet/MF1S703x.pdf</a></li>
+<a name="resources46"></a><li id="resources46">MIFARE MF0ICU1: <a href="http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf">http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf</a></li>
+<a name="resources47"></a><li id="resources47">MIFARE MF0ICU2: <a href="http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf">http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf</a></li>
+<a name="resources48"></a><li id="resources48">MIFARE AN130511: <a href="http://www.nxp.com/documents/application_note/AN130511.pdf">http://www.nxp.com/documents/application_note/AN130511.pdf</a></li>
+<a name="resources49"></a><li id="resources49">MIFARE AN130411: <a href="http://www.nxp.com/documents/application_note/AN130411.pdf">http://www.nxp.com/documents/application_note/AN130411.pdf</a></li>
+<a name="resources50"></a><li id="resources50">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></li>
+<a name="resources51"></a><li id="resources51">Camera: <a href="http://developer.android.com/reference/android/hardware/Camera.html">http://developer.android.com/reference/android/hardware/Camera.html</a></li>
+<a name="resources52"></a><li id="resources52">Android Open Accessories: <a href="http://developer.android.com/guide/topics/usb/accessory.html">http://developer.android.com/guide/topics/usb/accessory.html</a></li>
+<a name="resources53"></a><li id="resources53">USB Host API: <a href="http://developer.android.com/guide/topics/usb/host.html">http://developer.android.com/guide/topics/usb/host.html</a></li>
+<a name="resources54"></a><li id="resources54">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></li>
+<a name="resources55"></a><li id="resources55">Apps for Android: <a href="http://code.google.com/p/apps-for-android">http://code.google.com/p/apps-for-android</a></li>
+<a name="resources56"></a><li id="resources56">Android DownloadManager: <a href="http://developer.android.com/reference/android/app/DownloadManager.html">http://developer.android.com/reference/android/app/DownloadManager.html</a></li>
+<a name="resources57"></a><li id="resources57">Android File Transfer: <a href="http://www.android.com/filetransfer">http://www.android.com/filetransfer</a></li>
+<a name="resources58"></a><li id="resources58">Android Media Formats: <a href="http://developer.android.com/guide/appendix/media-formats.html">http://developer.android.com/guide/appendix/media-formats.html</a></li>
+<a name="resources59"></a><li id="resources59">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></li>
+<a name="resources60"></a><li id="resources60">NFC Connection Handover: <a href="http://www.nfc-forum.org/specs/spec_list/#conn_handover/">http://www.nfc-forum.org/specs/spec_list/#conn_handover</a></li>
+<a name="resources61"></a><li id="resources61">Bluetooth Secure Simple Pairing Using NFC: <a href="http://www.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf">http://www.nfc-forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf</a></li>
+<a name="resources62"></a>
+<li id="resources62">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></li>
+<a name="resources63"></a><li id="resources63">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></li>
+<a name="resources64"></a><li id="resources64">USB Charging Specification: <a href="http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf">http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf</a></li>
+<a name="resources65"></a><li id="resources65">Android Beam: <a href="http://developer.android.com/guide/topics/nfc/nfc.html">http://developer.android.com/guide/topics/nfc/nfc.html</a></li>
+<a name="resources66"></a><li id="resources66">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></li>
+<a name="resources67"></a><li id="resources67">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></li>
+<a name="resources68"></a>
+<li id="resources68">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></li>
+<a name="resources69"></a><li id="resources69">Lock and Home Screen Widget: <a href="http://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html">http://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html</a></li>
+<a name="resources70"></a><li id="resources70">UserManager reference: <a href="http://developer.android.com/reference/android/os/UserManager.html">http://developer.android.com/reference/android/os/UserManager.html</a></li>
+<a name="resources71"></a><li id="resources71">External Storage reference: <a
+href="http://source.android.com/devices/tech/storage">http://source.android.com/devices/tech/storage</a></li>
+<a name="resources72"></a><li id="resources72">External Storage APIs: <a href="http://developer.android.com/reference/android/os/Environment.html">http://developer.android.com/reference/android/os/Environment.html</a></li>
+<a name="resources73"></a><li id="resources73">SMS Short Code: <a href="http://en.wikipedia.org/wiki/Short_code">http://en.wikipedia.org/wiki/Short_code</a></li>
+<a name="resources74"></a><li id="resources74">Media Remote Control Client: <a href="http://developer.android.com/reference/android/media/RemoteControlClient.html">http://developer.android.com/reference/android/media/RemoteControlClient.html</a></li>
+<a name="resources75"></a><li id="resources75">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></li>
+<a name="resources76"></a><li id="resources76">Dreams: <a href="http://developer.android.com/reference/android/service/dreams/DreamService.html">http://developer.android.com/reference/android/service/dreams/DreamService.html</a></li>
+<a name="resources77"></a><li id="resources77">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></li>
+<a name="resources78"></a><li id="resources78">Camera: <a href="http://developer.android.com/reference/android/hardware/Camera.Parameters.html">http://developer.android.com/reference/android/hardware/Camera.Parameters.html</a></li>
+<a name="resources79"></a><li id="resources79">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></li>
+<a name="resources80"></a><li id="resources80">Motion Event API: <a href="http://developer.android.com/reference/android/view/MotionEvent.html">http://developer.android.com/reference/android/view/MotionEvent.html</a></li>
+<a name="resources81"></a><li id="resources81">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></li>
+<a name="resources82"></a><li id="resources82">Unicode 6.1.0: <a href="http://www.unicode.org/versions/Unicode6.1.0/">http://www.unicode.org/versions/Unicode6.1.0/</a></li>
+<a name="resources83"></a><li id="resources83">WebView compatibility: <a href="http://www.chromium.org/">http://www.chromium.org/</a></li>
+<a name="resources84"></a><li id="resources84">Android 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></li>
+<a name="resources85"></a><li id="resources85">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></li>
+<a name="resources86"></a><li id="resources86">RTC Hardware Coding Requirements: <a href="http://www.webmproject.org/hardware/rtc-coding-requirements/">http://www.webmproject.org/hardware/rtc-coding-requirements/</a></li>
+<a name="resources87"></a><li id="resources87">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></li>
+<a name="resources88"></a><li id="resources88">Content Resolver: <a href="http://developer.android.com/reference/android/content/ContentResolver.html">http://developer.android.com/reference/android/content/ContentResolver.html</a></li>
+<a name="resources89"></a><li id="resources89">SettingInjectorService: <a
+href="http://developer.android.com/reference/android/location/SettingInjectorService.html">http://developer.android.com/reference/android/location/SettingInjectorService.html</a></li>
+<a name="resources90"></a><li id="resources90">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></li>
+<a name="resources91"></a><li id="resources91">Telephony Provider: <a href="http://developer.android.com/reference/android/provider/Telephony.html">http://developer.android.com/reference/android/provider/Telephony.html</a></li>
+</ol>
+<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>
+
+<a name="section-3"></a><h2 id="section-3">3. Software</h2>
+<a name="section-3.1"></a><h3 id="section-3.1">3.1. Managed API Compatibility</h3>
+<p>The managed (Dalvik-based) 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 VM environment. Device implementations MUST provide complete
+implementations, including all documented behaviors, of any documented API
+exposed by the Android SDK [<a href="#resources04">Resources, 4</a>].</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="#section-7">Section 7</a> for specific requirements for this scenario.
+</p>
+
+<a name="section-3.2"></a><h3 id="section-3.2">3.2. Soft API Compatibility</h3>
+<p>In addition to the managed APIs from Section 3.1, Android also includes a
+significant runtime-only "soft" API, in the form of such things such as
+Intents, permissions, and similar aspects of Android applications that cannot
+be enforced at application compile time.</p>
+<a name="section-3.2.1"></a><h4 id="section-3.2.1">3.2.1. Permissions</h4>
+<p>Device implementers MUST support and enforce all permission constants as
+documented by the Permission reference page [<a
+href="#resources05">Resources, 5</a>]. Note that Section 9 lists additional
+requirements related to the Android security model.</p>
+<a name="section-3.2.2"></a><h4 id="section-3.2.2">3.2.2. Build Parameters</h4>
+<p>The Android APIs include a number of constants on the <code>android.os.Build</code>
+class [<a href="#resources06">Resources, 6</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>
+<tbody>
+<tr>
+<td><b>Parameter</b></td>
+<td><b>Comments</b></td>
+</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="#resources07">Resources, 7</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 4.4, this
+field MUST have the integer value 19.</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 4.4, this
+field MUST have the integer value 19.</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 re-used 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
+<code>"^[a-zA-Z0-9.,_-]+$"</code>.</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 <code>"^[a-zA-Z0-9.,_-]+$"</code>.
+</td>
+</tr>
+<tr>
+<td>CPU_ABI</td>
+<td>The name of the instruction set (CPU type + ABI convention) of native code.
+See <a href="#section-3.3">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="#section-3.3">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 <code>"^[a-zA-Z0-9.,_-]+$"</code>.
+</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:
+<br/><code>$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)</code><br/>
+For example:
+<br/><code>acme/myproduct/mydevice:4.4/KRT16/3359:userdebug/test-keys</code><br/>
+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>
+</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 <code>"^[a-zA-Z0-9.,_-]+$"</code>.</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
+<code>"^[a-zA-Z0-9.,_-]+$"</code>.
+</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 SHOULD 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 <code>"^[a-zA-Z0-9.,_-]+$"</code>.
+</td>
+</tr>
+<tr>
+<td>SERIAL</td>
+<td>A hardware serial number, which MUST be available. The value of this field MUST be encodable
+as 7-bit ASCII and match the regular expression
+<code>"^([a-zA-Z0-9]{6,20})$"</code>.</td>
+</tr>
+<tr>
+<td>TAGS</td>
+<td>A comma-separated list of tags chosen by the device implementer that
+further distinguishes the build. For example, "unsigned,debug". The value of
+this field MUST be encodable as 7-bit ASCII and match the regular expression
+<code>"^[a-zA-Z0-9.,_-]+$"</code>.</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 SHOULD have one of the values
+corresponding to the three typical Android runtime configurations: "user",
+"userdebug", or "eng". The value of this field MUST be
+encodable as 7-bit ASCII and match the regular expression
+<code>"^[a-zA-Z0-9.,_-]+$"</code>.</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>
+</tbody>
+</table>
+<a name="section-3.2.3"></a><h4 id="section-3.2.3">3.2.3. Intent Compatibility</h4>
+<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 and binds to and implements correct behavior for each
+specified Intent pattern.</p>
+<a name="section-3.2.3.1"></a><h4 id="section-3.2.3.1">3.2.3.1. Core Application Intents</h4>
+<p>The Android upstream project defines a number of core applications, such as
+contacts, calendar, photo gallery, music player, and so on. Device implementers
+MAY replace these applications with alternative versions.</p>
+<p>However, any such alternative versions MUST honor the same Intent patterns
+provided by the upstream project. For example, if a device contains an
+alternative music player, it must still honor the Intent pattern issued by
+third-party applications to pick a song.</p>
+<p>The following applications are considered core Android system
+applications:</p>
+<ul>
+<li>Desk Clock</li>
+<li>Browser</li>
+<li>Calendar</li>
+<li>Contacts</li>
+<!--<li>Email</li>-->
+<li>Gallery</li>
+<li>GlobalSearch</li>
+<li>Launcher</li>
+<!-- <li>LivePicker (that is, the Live Wallpaper picker application; MAY be omitted
+if the device does not support Live Wallpapers, per Section 3.8.5.)</li> -->
+<!-- <li>Messaging (AKA "Mms")</li> -->
+<li>Music</li>
+<!-- <li>Phone</li> -->
+<li>Settings</li>
+<!-- <li>SoundRecorder</li> -->
+</ul>
+<p>The core Android system applications include various Activity, or Service
+components that are considered "public".  That is, the attribute
+"android:exported" may be absent, or may have the value "true".</p>
+<p>For every Activity or Service defined
+in one of the core Android system apps that is not marked as non-public via an
+android:exported attribute with the value "false", device implementations MUST
+include a component of the same type implementing the same Intent filter
+patterns as the core Android system app.</p>
+<p>In other words, a device implementation MAY replace core Android system
+apps; however, if it does, the device implementation MUST support all Intent
+patterns defined by each core Android system app being replaced.</p>
+<a name="section-3.2.3.2"></a><h4 id="section-3.2.3.2">3.2.3.2. Intent Overrides</h4>
+<p>As Android is an extensible platform, device implementations MUST allow each
+Intent pattern referenced in Section 3.2.3.1 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 which all handle the same Intent pattern.</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>
+
+<a name="section-3.2.3.3"></a><h4 id="section-3.2.3.3">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 Section
+3.2.3.1. Device implementations MAY include Intent patterns using
+namespaces clearly and obviously associated with their own organization.</p>
+<p>This prohibition is analogous to that specified for Java language classes
+in Section 3.6.</p>
+
+<a name="section-3.2.3.4"></a><h4 id="section-3.2.3.4">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>
+
+<a name="section-3.2.3.5"></a><h4 id="section-3.2.3.5">3.2.3.5. Default App Settings</h4>
+<p>Android 4.4 adds settings that allow users to select their default Home and
+SMS applications. Device implementations MUST provide a similar user settings
+menu for each, compatible with the Intent filter pattern and API methods
+described in the SDK documentation [<a href="#resources91">Resources, 91</a>].
+</p>
+
+<a name="section-3.3"></a><h3 id="section-3.3">3.3. Native API Compatibility</h3>
+<a name="section-3.3.1"></a><h4 id="section-3.3.1">3.3.1 Application Binary Interfaces</h4>
+<p>Managed code running in Dalvik 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, in the file
+<code>docs/CPU-ARCH-ABIS.html</code>. If a device implementation is compatible
+with one or more defined ABIs, it SHOULD 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 accurately report the native Application Binary Interface (ABI)
+supported by the device, via the <code>android.os.Build.CPU_ABI</code>
+API and <code>android.os.Build.CPU_ABI2</code> parameters.</li>
+<li>MUST report, via <code>android.os.Build.CPU_ABI2</code>, only those ABIs
+documented in the latest version of the Android NDK, in the file 
+<code>docs/CPU-ARCH-ABIS.html</code></li>
+<li>MUST report, via <code>android.os.Build.CPU_ABI</code>, only one of the
+ABIs listed below</li>
+  <ul>
+  <li>armeabi-v7a</li>
+  <li>x86</li>
+  <li>mips</li>
+  </ul>
+<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.0)</li>
+<li>libGLESv2.so (OpenGL ES 2.0)</li>
+<li>libGLESv3.so (OpenGL ES 3.0)</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>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 ABI at all.</p>
+<p>Note that device implementations MUST include libGLESv3.so and it MUST symlink (symbolic)
+link to libGLESv2.so. On device implementations that declare support for OpenGL ES 3.0, libGLESv2.so
+MUST export the OpenGL ES 3.0 function symbols in addition to the OpenGL ES 2.0 function symbols.</p>
+<p>Native code compatibility is challenging. For this reason, it should be
+repeated that device implementers are VERY strongly encouraged to use the
+upstream implementations of the libraries listed above to help ensure
+compatibility.</p>
+
+<a name="section-3.4"></a><h3 id="section-3.4">3.4. Web Compatibility</h3>
+<a name="section-3.4.1"></a><h4 id="section-3.4.1">3.4.1. WebView Compatibility</h4>
+<p>The Android Open Source implementation uses code from the Chromium
+Project to implement the <code>android.webkit.WebView</code> [<a href="#resources10">Resources, 10</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 <code>android.webkit.WebView</code> implementations MUST be based
+on the Chromium build from the upstream Android Open Source Project for Android 4.4.
+This build includes a specific set of functionality and security fixes for the
+WebView. [<a href="#resources83">Resources, 83</a>]</li>
+<li>The user agent string reported by the WebView MUST be in this format:<br/>
+    <code>Mozilla/5.0 (Linux; Android $(VERSION); $(LOCALE); $(MODEL)
+Build/$(BUILD)) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0
+$(CHROMIUM_VER) Mobile Safari/537.36</code>
+  <ul>
+  <li>The value of the $(VERSION) string MUST be the same as the value for
+<code>android.os.Build.VERSION.RELEASE</code>.</li>
+  <li>The value of the $(LOCALE) string is optional, SHOULD follow the ISO
+conventions for country code and language, and SHOULD refer to the current
+configured locale of the device. If omitted, the trailing semicolon MUST
+also be removed.</li>
+  <li>The value of the $(MODEL) string MUST be the same as the value for
+<code>android.os.Build.MODEL</code>.</li>
+  <li>The value of the $(BUILD) string MUST be the same as the value for
+<code>android.os.Build.ID</code>.</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 <code>Mobile</code> in the user agent
+string.</li>
+  </ul>
+</li>
+</ul>
+<p>The WebView component SHOULD include support for as much of HTML5 [<a
+href="#resources11">Resources, 11</a>] as possible.</p>
+<a name="section-3.4.2"></a><h4 id="section-3.4.2">3.4.2. Browser Compatibility</h4>
+<p>Device implementations MUST include a standalone Browser application for
+general user web browsing. The standalone Browser MAY be based on a
+browser technology other than WebKit. However, even if an alternate Browser
+application is used, the <code>android.webkit.WebView</code> component
+provided to third-party applications MUST be based on WebKit, as described in
+Section 3.4.1.</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="#resources11">Resources, 11</a>] as possible.
+Minimally, device implementations MUST support each of these APIs associated
+with HTML5:</p>
+<ul>
+<li>application cache/offline operation [<a href="#resources12">Resources, 12</a>]</li>
+<li>the &lt;video&gt; tag [<a href="#resources13">Resources, 13</a>]</li>
+<li>geolocation [<a href="#resources14">Resources, 14</a>]</li>
+</ul>
+<p>Additionally, device implementations MUST support the HTML5/W3C webstorage
+API [<a href="#resources15">Resources, 15</a>], and SHOULD support the
+HTML5/W3C IndexedDB API [<a href="#resources16">Resources, 16</a>]. <i>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.</i></p>
+
+<a name="section-3.5"></a><h3 id="section-3.5">3.5. API Behavioral Compatibility</h3>
+<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="#resources03">Resources, 3</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>
+
+
+<a name="section-3.6"></a><h3 id="section-3.6">3.6. API Namespaces</h3>
+<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>Prohibited modifications include:</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
+<code>&lt;uses-library&gt;</code> 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 source.android.com 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>
+
+<a name="section-3.7"></a><h3 id="section-3.7">3.7. Virtual Machine Compatibility</h3>
+<p>Device implementations MUST support the full Dalvik Executable (DEX)
+bytecode specification and Dalvik Virtual Machine semantics [<a
+href="#resources17">Resources, 17</a>].</p>
+<p>Device implementations MUST configure Dalvik to allocate memory in
+accordance with the upstream Android platform, and as specified by the following
+table.  (See <a href="#section-7.1.1">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>
+<tbody>
+<tr>
+<td><b>Screen Size</b></td>
+<td><b>Screen Density</b></td>
+<td><b>Application Memory</b></td>
+</tr>
+<tr>
+<td>small / normal / large</td>
+<td>ldpi / mdpi</td>
+<td>16MB</td>
+</tr>
+<tr>
+<td>small / normal / large</td>
+<td>tvdpi / hdpi</td>
+<td>32MB</td>
+</tr>
+<tr>
+<td>small / normal / large</td>
+<td>xhdpi</td>
+<td>64MB</td>
+</tr>
+<tr>
+<td>small / normal / large</td>
+<td>400dpi</td>
+<td>96MB</td>
+</tr>
+<tr>
+<td>small / normal / large</td>
+<td>xxhdpi</td>
+<td>128MB</td>
+</tr>
+<tr>
+<td>small / normal / large</td>
+<td>xxxhdpi</td>
+<td>256MB</td>
+</tr>
+<tr>
+<td>xlarge</td>
+<td>mdpi</td>
+<td>32MB</td>
+</tr>
+<tr>
+<td>xlarge</td>
+<td>tvdpi / hdpi</td>
+<td>64MB</td>
+</tr>
+<tr>
+<td>xlarge</td>
+<td>xhdpi</td>
+<td>128MB</td>
+</tr>
+<tr>
+<td>xlarge</td>
+<td>400dpi</td>
+<td>192MB</td>
+</tr>
+<tr>
+<td>xlarge</td>
+<td>xxhdpi</td>
+<td>256MB</td>
+</tr>
+<tr>
+<td>xlarge</td>
+<td>xxxhdpi</td>
+<td>512MB</td>
+</tr>
+</tbody>
+</table>
+
+<a name="section-3.8"></a><h3 id="section-3.8">3.8. User Interface Compatibility</h3>
+
+<a name="section-3.8.1"></a><h4 id="section-3.8.1">3.8.1. Launcher (Home Screen)</h4>
+<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 <code>android.software.home_screen</code>.</p>
+
+<a name="section-3.8.2"></a><h4 id="section-3.8.2">3.8.2. Widgets</h4>
+<p>Android defines a component type and corresponding API and lifecycle that allows applications to expose an "AppWidget"
+to the end user [<a href="#resources18">Resources, 18</a>]. Device implementations that support embedding widgets on the
+home screen MUST meet the following requirements and declare support for platform feature <code>android.software.app_widgets</code>.</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="#resources18">Resources, 18</a>] for details.</li>
+ <li>Device implementations that include support for lock screen MUST support application widgets on the lock screen.</li>
+</ul>
+
+<a name="section-3.8.3"></a><h4 id="section-3.8.3">3.8.3. Notifications</h4>
+<p>Android includes APIs that allow developers to notify users of notable
+events [<a href="#resources19">Resources, 19</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. Note that this
+behavior is further detailed in <a href="#section-7">Section 7.</a></p>
+<p>Additionally, the implementation MUST correctly render all resources
+(icons, sound files, etc.) provided for in the APIs [<a
+href="#resources20">Resources, 20</a>], or in the
+Status/System Bar icon style guide [<a href="#resources21">Resources, 21</a>].
+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 rich notifications, such as interactive
+Views for ongoing notifications. Device implementations MUST properly display
+and execute rich notifications, as documented in the Android APIs.</p>
+<a name="section-3.8.4"></a><h4 id="section-3.8.4">3.8.4. Search</h4>
+<p>Android includes APIs [<a href="#resources22">Resources, 22</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>Device implementations MUST include a single, shared, system-wide search
+user interface capable of real-time suggestions in response to user input.
+Device implementations MUST implement the APIs that allow developers to reuse
+this user interface to provide search within their own applications. Device
+implementations 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>
+<a name="section-3.8.5"></a><h4 id="section-3.8.5">3.8.5. Toasts</h4>
+<p>Applications can use the "Toast" API (defined in [<a
+href="#resources23">Resources, 23</a>]) to
+display short non-modal strings to the end user, that disappear after a brief
+period of time. Device implementations MUST display Toasts from applications
+to end users in some high-visibility manner.</p>
+
+<a name="section-3.8.6"></a><h4 id="section-3.8.6">3.8.6. Themes</h4>
+<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="#resources24">Resources, 24</a>]. 
+Device implementations MUST NOT alter any of the Holo theme attributes exposed 
+to applications [<a href="#resources25">Resources, 25</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 DeviceDefault theme attributes exposed to applications
+[<a href="#resources25">Resources, 25</a>].</p>
+<p>From version 4.4, Android now supports a new variant theme with translucent system bars, 
+allowing 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="#resources25">Resources, 25</a>].</p>
+
+<a name="section-3.8.7"></a><h4 id="section-3.8.7">3.8.7. Live Wallpapers</h4>
+<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="#resources26">Resources, 26</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 framerate with no adverse affects 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 Open GL 1.0 or 2.0
+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. Device implementations
+determined to not run live wallpapers reliably as described above MUST NOT
+implement live wallpapers.</p>
+<a name="section-3.8.8"></a><h4 id="section-3.8.8">3.8.8. Recent Application Display</h4>
+<p>The upstream Android source code includes a user interface for
+displaying recent applications using a thumbnail image of the application's
+graphical state at the moment the user last left the application. Device
+implementations MAY alter or eliminate this user interface; however, a future
+version of Android is planned to make more extensive use of this
+functionality. Device implementations are strongly encouraged to use the
+upstream Android user interface (or a similar thumbnail-based interface)
+for recent applications, or else they may not be compatible with a future
+version of Android.</p>
+<a name="section-3.8.9"></a><h4 id="section-3.8.9">3.8.9. Input Management</h4>
+<p>Android includes support for Input Management and support for third party input method editors.
+Device implementations that allow users to use third party input methods on the device MUST declare the platform feature
+<code>android.software.input_methods</code> and support IME APIs as defined in the Android SDK documentation.</p>
+<p>Device implementations that declare the <code>android.software.input_methods</code> 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
+<code>android.settings.INPUT_METHOD_SETTINGS</code> intent.</p>
+
+<a name="section-3.8.10"></a><h4 id="section-3.8.10">3.8.10. Lock Screen Media Remote Control</h4>
+<p>Android includes support for Remote Control API that lets media applications integrate with playback controls
+that are displayed in a remote view like the device lock screen [<a href="#resources74">Resources, 74</a>]. Device implementations 
+that support lock screen in the device and allow users to add widgets on the home screen MUST
+include support for embedding remote controls in the device lock screen [<a href="#resources69">Resources, 69</a>].</p>
+
+<a name="section-3.8.11"></a><h4 id="section-3.8.11">3.8.11. Dreams</h4>
+<p>Android includes support for interactive screensavers called Dreams [<a href="#resources76">Resources, 76</a>].
+Dreams allows users to interact with applications when a charging device is idle, or docked in a desk dock. Device implementations
+MUST include support for Dreams and provide a settings option for users to configure Dreams.</p>
+
+<a name="section-3.8.12"></a><h4 id="section-3.8.12">3.8.12. Location</h4>
+<p>Location modes MUST be displayed in the Location menu within Settings [<a
+href="#resources87">Resources, 87</a>]. Location services provided through the
+<code>SettingInjectorService</code> introduced in Android 4.4 must be displayed 
+in the same Location menu [<a href="#resources89">Resources, 89</a>].</p>
+
+<a name="section-3.8.13"></a><h4 id="section-3.8.13">3.8.13. Unicode</h4>
+<p>Android 4.4 includes support for color emoji characters. Android device
+implementations MUST provide an input method to the user for the Emoji
+characters defined in Unicode 6.1 [<a href="#resources82">Resources, 82</a>]
+and MUST be capable of rendering these emoji characters in color glyph.</p>
+
+<a name="section-3.9"></a><h3 id="section-3.9">3.9. Device Administration</h3>
+<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="#resources27">Resources, 27</a>]. Device
+implementations MUST provide an implementation of the <code>DevicePolicyManager</code>
+class [<a href="#resources28">Resources, 28</a>]. Device implementations that include support for lock screen
+MUST support the full range of device administration policies defined in the Android SDK
+documentation [<a href="#resources27">Resources, 27</a>].</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="#resources84">Resources, 84</a>].</p>
+
+<a name="section-3.10"></a><h3 id="section-3.10">3.10. Accessibility</h3>
+<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="#resources29">Resources, 29</a>]. Device implementations MUST provide an
+implementation of the Android accessibility framework consistent with the
+default Android implementation.  Specifically, device implementations MUST meet
+the following requirements.</p>
+<ul>
+ <li>Device implementations MUST support third party accessibility service
+     implementations through the <code>android.accessibilityservice</code>
+     APIs [<a href="#resources30">Resources, 30</a>].</li>
+ <li>Device implementations MUST generate <code>AccessibilityEvents</code>
+     and deliver these events to all registered <code>AccessibilityService
+     </code> implementations in a manner consistent with the default Android
+     implementation.</li>
+ <li>Device implementations MUST provide a user-accessible mechanism to enable
+     and disable accessibility services, and MUST display this interface in
+     response to the
+     <code>android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS</code>
+     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="#resources31">Resources, 31</a>].</p>
+
+<a name="section-3.11"></a><h3 id="section-3.11">3.11. Text-to-Speech</h3>
+<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="#resources32">Resources, 32</a>].
+Device implementations MUST meet these requirements related to the Android TTS
+framework:</p>
+<ul>
+  <li>Device implementations 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>
+  <li>Device implementations MUST support installation of third-party TTS
+      engines.</li>
+  <li>Device implementations MUST provide a user-accessible interface that allows
+      users to select a TTS engine for use at the system level.</li>
+</ul>
+
+<a name="section-4"></a><h2 id="section-4">4. Application Packaging Compatibility</h2>
+<p>Device implementations MUST install and run Android ".apk" files as
+generated by the "aapt" tool included in the official Android SDK [<a
+href="#resources33">Resources, 33</a>].</p>
+<p>Devices implementations MUST NOT extend either the .apk [<a
+href="#resources34">Resources, 34</a>], Android Manifest [<a
+href="#resources35">Resources, 35</a>],
+Dalvik bytecode [<a href="#resources17">Resources, 17</a>], or renderscript
+bytecode formats in such a way that would prevent those files from installing
+and running correctly on other compatible devices. Device implementers SHOULD
+use the reference upstream implementation of Dalvik, and the reference
+implementation's package management system.</p>
+
+<a name="section-5"></a><h2 id="section-5">5. Multimedia Compatibility</h2>
+<p>Device implementations MUST include at least one form of audio output, such as
+speakers, headphone jack, external speaker connection, etc.</p>
+<a name="section-5.1"></a><h3 id="section-5.1">5.1. Media Codecs</h3>
+<p>Device implementations MUST support the core media formats specified
+in the Android SDK documentation [<a href="#resources58">Resources, 58</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. All of these codecs are provided as
+software implementations in the preferred Android implementation from the Android
+Open Source Project.</p>
+
+<p><strong>Please note that neither Google nor the Open Handset Alliance make any
+representation that these codecs are unencumbered by 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.</strong></p>
+
+<p>Note that these tables do not list specific bitrate requirements for
+most video codecs because current device hardware does not necessarily support
+bitrates that map exactly to the required bitrates specified by the relevant
+standards. Instead, device implementations SHOULD support the highest bitrate
+practical on the hardware, up to the limits defined by the specifications.</p>
+<div style="page-break-before: always;"></div>
+<table>
+<tbody>
+
+<tr>
+<th>Type</th>
+<th>Format / Codec</th>
+<th>Encoder</th>
+<th>Decoder</th>
+<th>Details</th>
+<th>File Type(s) / Container Formats</th>
+</tr>
+
+<tr>
+<td rowspan="11">Audio</td>
+<td>MPEG-4 AAC Profile (AAC LC)</td>
+<td>REQUIRED for device implementations that include microphone hardware
+and define <code>android.hardware.microphone</code>.</td>
+<td style="text-align: center;">REQUIRED</td>
+<td rowspan="1"> Support for mono/stereo/5.0/5.1* content with standard sampling rates from 8 to 48 kHz.</td>
+<td rowspan="4">
+  <ul>
+    <li>3GPP (.3gp)</li>
+    <li>MPEG-4 (.mp4, .m4a)</li>
+    <li>ADTS raw AAC (.aac, decode in Android 3.1+, encode in Android 4.0+, ADIF not supported)</li>
+    <li>MPEG-TS (.ts, not seekable, Android 3.0+)</li>
+  </ul>
+</td>
+</tr>
+
+<tr>
+<td>MPEG-4 HE AAC Profile (AAC+)</td>
+<td>REQUIRED for device implementations that include microphone hardware and define android.hardware.microphone</td>
+<td style="text-align: center;">REQUIRED</td>
+<td>Support for mono/stereo/5.0/5.1* content with standard sampling rates from 16 to 48 kHz.</td>
+</tr>
+
+<tr>
+<td>MPEG-4 HE AAC v2 Profile (enhanced AAC+)</td>
+<td>&nbsp;</td>
+<td style="text-align: center;">REQUIRED</td>
+<td>Support for mono/stereo/5.0/5.1* content with standard sampling rates from 16 to 48 kHz.</td>
+</tr>
+
+<tr>
+<td>MPEG-4 Audio Object Type ER AAC ELD (Enhanced Low Delay AAC)</td>
+<td>REQUIRED for device implementations that include microphone hardware and define android.hardware.microphone</td>
+<td style="text-align: center;">REQUIRED</td>
+<td>Support for mono/stereo content with standard
+sampling rates from 16 to 48 kHz.</td>
+</tr>
+
+<tr>
+<td>AMR-NB</td>
+<td>REQUIRED for device implementations that include microphone hardware
+and define <code>android.hardware.microphone</code>.</td>
+<td style="text-align: center;">REQUIRED</td>
+<td>4.75 to 12.2 kbps sampled @ 8kHz</td>
+<td>3GPP (.3gp)
+</td>
+</tr>
+
+<tr>
+<td>AMR-WB</td>
+<td>REQUIRED for device implementations that include microphone hardware
+and define <code>android.hardware.microphone</code>.</td>
+<td style="text-align: center;">REQUIRED</td>
+<td>9 rates from 6.60 kbit/s to 23.85 kbit/s sampled @ 16kHz</td>
+<td>3GPP (.3gp)</td>
+</tr>
+
+<tr>
+<td>FLAC</td>
+<td>&nbsp;</td>
+<td style="text-align: center;">REQUIRED<br/><small>(Android 3.1+)</small></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>&nbsp;</td>
+<td style="text-align: center;">REQUIRED</td>
+<td>Mono/Stereo 8-320Kbps constant (CBR) or variable bit-rate (VBR)
+</td>
+<td>MP3 (.mp3)</td>
+</tr>
+
+<tr>
+<td>MIDI</td>
+<td>&nbsp;</td>
+<td style="text-align: center;">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>Type 0 and 1 (.mid, .xmf, .mxmf)</li>
+    <li>RTTTL/RTX (.rtttl, .rtx)</li>
+    <li>OTA (.ota)</li>
+    <li>iMelody (.imy)</li>
+  </ul>
+</td>
+</tr>
+
+<tr>
+<td>Vorbis</td>
+<td>&nbsp;</td>
+<td style="text-align: center;">REQUIRED</td>
+<td>&nbsp;</td>
+<td>
+  <ul>
+    <li>Ogg (.ogg)</li>
+    <li>Matroska (.mkv)</li>
+  </ul>
+</td>
+</tr>
+
+<tr>
+<td>PCM/WAVE</td>
+<td style="text-align: center;">REQUIRED</td>
+<td style="text-align: center;">REQUIRED</td>
+<td>8-bit and 16-bit linear PCM** (rates up to limit of hardware).Devices MUST support sampling rates
+for raw PCM recording at 8000,16000 and 44100 Hz frequencies</td>
+<td>WAVE (.wav)</td>
+</tr>
+
+<tr>
+<td rowspan="5">Image</td>
+<td>JPEG</td>
+<td style="text-align: center;">REQUIRED</td>
+<td style="text-align: center;">REQUIRED</td>
+<td>Base+progressive</td>
+<td>JPEG (.jpg)</td>
+</tr>
+
+<tr>
+<td>GIF</td>
+<td>&nbsp;</td>
+<td style="text-align: center;">REQUIRED</td>
+<td>&nbsp;</td>
+<td>GIF (.gif)</td>
+</tr>
+
+<tr>
+<td>PNG</td>
+<td style="text-align: center;">REQUIRED</td>
+<td style="text-align: center;">REQUIRED</td>
+<td>&nbsp;</td>
+<td>PNG (.png)</td>
+</tr>
+
+<tr>
+<td>BMP</td>
+<td>&nbsp;</td>
+<td style="text-align: center;">REQUIRED</td>
+<td>&nbsp;</td>
+<td>BMP (.bmp)</td>
+</tr>
+
+
+<tr>
+<td>WEBP</td>
+<td style="text-align: center;">REQUIRED</td>
+<td style="text-align: center;">REQUIRED</td>
+<td>&nbsp;</td>
+<td>WebP (.webp)</td>
+</tr>
+
+<tr>
+<td rowspan="5">Video</td>
+<td>H.263</td>
+<td>REQUIRED for device implementations that include camera hardware
+and define <code>android.hardware.camera</code> or
+<code>android.hardware.camera.front</code>.</td>
+<td style="text-align: center;">REQUIRED</td>
+<td>&nbsp;</td>
+<td>
+  <ul>
+    <li>3GPP (.3gp)</li>
+    <li>MPEG-4 (.mp4)</li>
+  </ul>
+</td>
+</tr>
+
+<tr>
+<td>H.264 AVC</td>
+<td>REQUIRED for device implementations that include camera hardware
+and define <code>android.hardware.camera</code> or
+<code>android.hardware.camera.front</code>.</td>
+<td style="text-align: center;">REQUIRED</td>
+<td>Baseline Profile (BP)</td>
+<td>
+  <ul>
+    <li>3GPP (.3gp)</li>
+    <li>MPEG-4 (.mp4)</li>
+    <li>MPEG-TS (.ts, AAC audio only, not seekable, Android 3.0+)</li>
+  </ul>
+</td>
+</tr>
+
+<tr>
+<td>MPEG-4 SP</td>
+<td>&nbsp;</td>
+<td style="text-align: center;">REQUIRED</td>
+<td>&nbsp;</td>
+<td>3GPP (.3gp)</td>
+</tr>
+
+<tr>
+<td>VP8****</td>
+<td style="text-align: center;">REQUIRED<br/><small>(Android 4.3+)</small></td>
+<td style="text-align: center;">REQUIRED<br/><small>(Android 2.3.3+)</small></td>
+<td>&nbsp;</td>
+<td><a href="http://www.webmproject.org/">WebM</a> (.webm) and Matroska (.mkv, Android 4.0+)***</td>
+</tr>
+
+<tr>
+<td>VP9</td>
+<td>&nbsp;</td>
+<td style="text-align: center;">REQUIRED<br/><small>(Android 4.4+)</small></td>
+<td>&nbsp;</td>
+<td><a href="http://www.webmproject.org/">WebM</a> (.webm) and Matroska (.mkv,
+Android 4.0+)***</td>
+</tr>
+
+</tbody></table>
+<ul>
+<li>*Note: Only downmix of 5.0/5.1 content is required; recording or rendering more than 2 channels is optional.</li>
+<li>**Note: 16-bit linear PCM capture is mandatory. 8-bit linear PCM capture is not mandatory.</li>
+<li>***Note: Device implementations SHOULD support writing Matroska WebM files.</li>
+<li>****Note: 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="#resources86">Resources, 86</a>].</li>
+</ul>
+
+<a name="section-5.2"></a><h3 id="section-5.2">5.2. Video Encoding</h3>
+<p>Android device implementations that include a rear-facing camera and declare
+<code>android.hardware.camera</code> SHOULD support the following H.264 video encoding
+profiles.</p>
+<table>
+  <thead>
+  <tr>
+    <th>&nbsp;</th>
+    <th>SD (Low quality)</th>
+    <th>SD (High quality)</th>
+    <th>HD (When supported by hardware)</th>
+  </tr>
+  </thead>
+  <tbody>
+  <tr>
+    <th>Video resolution</th>
+    <td>176 x 144 px</td>
+    <td>480 x 360 px</td>
+    <td>1280 x 720 px</td>
+  </tr>
+  <tr>
+    <th>Video frame rate</th>
+    <td>12 fps</td>
+    <td>30 fps</td>
+    <td>30 fps</td>
+  </tr>
+  <tr>
+    <th>Video bitrate</th>
+    <td>56 Kbps</td>
+    <td>500 Kbps or higher</td>
+    <td>2 Mbps or higher</td>
+  </tr>
+  <tr>
+    <th>Audio codec</th>
+    <td>AAC-LC</td>
+    <td>AAC-LC</td>
+    <td>AAC-LC</td>
+  </tr>
+  <tr>
+    <th>Audio channels</th>
+    <td>1 (mono)</td>
+    <td>2 (stereo)</td>
+    <td>2 (stereo)</td>
+  </tr>
+  <tr>
+    <th>Audio bitrate</th>
+    <td>24 Kbps</td>
+    <td>128 Kbps</td>
+    <td>192 Kbps</td>
+  </tr>
+  </tbody>
+</table>
+
+<p>Android device implementations that include a rear-facing camera and declare
+<code>android.hardware.camera</code> SHOULD support the following VP8 video encoding profiles</p>
+<table>
+  <thead>
+  <tr>
+    <th>&nbsp;</th>
+    <th>SD (Low quality)</th>
+    <th>SD (High quality)</th>
+    <th>HD 720p <br/> (When supported by hardware)</th>
+    <th>HD 1080p <br/>(When supported by hardware)</th>
+  </tr>
+  </thead>
+  <tbody>
+  <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>
+  </tbody>
+</table>
+
+<a name="section-5.3"></a><h3 id="section-5.3">5.3. Video Decoding</h3>
+<p>Android device implementations SHOULD support the following VP8, VP9 and
+H.264 video decoding profiles. Device implementations SHOULD also support
+dynamic video resolution switching within the same stream for VP8, VP9 and
+H.264 codecs.</p>
+<table>
+  <thead>
+  <tr>
+    <th>&nbsp;</th>
+    <th>SD (Low quality)</th>
+    <th>SD (High quality)</th>
+    <th>HD 720p <br/> (When supported by hardware)</th>
+    <th>HD 1080p <br/>(When supported by hardware)</th>
+  </tr>
+  </thead>
+  <tbody>
+  <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>8 Mbps</td>
+    <td>20 Mbps</td>
+  </tr>
+  </tbody>
+</table>
+
+<a name="section-5.4"></a><h3 id="section-5.4">5.4. Audio Recording</h3>
+<p>When an application has used the <code>android.media.AudioRecord</code> API to
+start recording an audio stream, device implementations that include microphone
+hardware and declare <code>android.hardware.microphone</code> MUST sample and
+record audio with each of these behaviors:</p>
+<ul>
+<li>The device SHOULD exhibit approximately flat amplitude versus frequency
+    characteristics; specifically, &plusmn;3 dB, from 100 Hz to 4000 Hz</li>
+<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>
+<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>
+<li>Total harmonic distortion SHOULD be less than 1% for 1Khz at 90 dB SPL input level.</li>
+</ul>
+<p>In addition to the above recording specifications, when an application has
+started recording an audio stream using the
+<code>android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION</code> audio
+source:</p>
+<ul>
+<li>Noise reduction processing, if present, MUST be disabled.</li>
+<li>Automatic gain control, if present, MUST be disabled.</li>
+</ul>
+<p>From Android 4.4, <code>android.media.MediaRecorder.AudioSource</code> class has a new
+audio source: <code>REMOTE_SUBMIX</code>. Devices MUST properly implement the
+<code>REMOTE_SUBMIX</code> audio source so that when an application uses the 
+<code>android.media.AudioRecord</code> API to record from this audio source, 
+it can capture a mix of all audio streams except for the following:</p>
+<ul>
+<li><code>STREAM_RING</code></li>
+<li><code>STREAM_ALARM</code></li>
+<li><code>STREAM_NOTIFICATION</code></li>
+</ul>
+<p><b>Note:</b> while some of the requirements outlined above are stated as
+"SHOULD" since Android 4.3, the Compatibility Definition for a future version
+is planned to change these to "MUST". That is, these requirements are optional
+in Android 4.4 but <b>will be required</b> by a future version. Existing and new
+devices that run Android are <b>very strongly encouraged to meet these
+requirements</b>, or they will not be able to attain Android
+compatibility when upgraded to the future version.</p>
+<p>If the platform supports noise suppression technologies tuned for speech
+recognition, the effect MUST be controllable from the 
+<code>android.media.audiofx.NoiseSuppressor</code> API. Moreover, the "uuid"
+field for the noise suppressor's effect descriptor MUST uniquely identify each
+implementation of the noise suppression technology.</p>
+
+<a name="section-5.5"></a><h3 id="section-5.5">5.5. Audio Latency</h3>
+<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:</p>
+<ul>
+<li>"output latency" is defined as 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>"cold output latency" is defined as the output latency for the first frame, when
+    the audio output system has been idle and powered down prior to the request</li>
+<li>"continuous output latency" is defined as the output latency for subsequent frames,
+    after the device is already playing audio</li>
+<li>"input latency" is 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>"cold input latency" is defined as 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>"continuous input latency" is defined as the input latency for subsequent frames,
+    while the device is already capturing audio</li>
+<li>"OpenSL ES PCM buffer queue API" is the set of PCM-related OpenSL ES APIs within Android NDK;
+see <i>NDK_root</i><code>/docs/opensles/index.html</code></li>
+</ul>
+<p>Per <a href="#section-5">Section 5</a>,
+all compatible device implementations MUST include at least one form of audio output.
+Device implementations SHOULD meet or exceed these output latency requirements:</p>
+<ul>
+<li>cold output latency of 100 milliseconds or less</li>
+<li>continuous output latency of 45 milliseconds or less</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 MAY
+report support for low-latency audio, by reporting the feature
+"android.hardware.audio.low-latency" via the
+<code>android.content.pm.PackageManager</code> class. [<a
+href="#resources37">Resources, 37</a>] Conversely, if the device
+implementation does not meet these requirements it MUST NOT report support for
+low-latency audio.</p>
+<p>
+Per <a href="#section-7.2.5">Section 7.2.5</a>,
+microphone hardware may be omitted by device implementations.</p>
+<p>
+Device implementations that include microphone
+hardware and declare <code>android.hardware.microphone</code> SHOULD
+meet these input audio latency requirements:</p>
+<ul>
+<li>cold input latency of 100 milliseconds or less</li>
+<li>continuous input latency of 50 milliseconds or less</li>
+</ul>
+
+<a name="section-5.6"></a><h3 id="section-5.6">5.6. Network Protocols</h3>
+<p>Devices MUST support the media network protocols for audio and video playback
+as specified in the Android SDK documentation
+[<a href="#resources58">Resources, 58</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="#resources59">Resources, 59</a>]</li>
+</ul>
+<a name="section-6"></a><h2 id="section-6">6. Developer Tools and Options Compatibility</h2>
+
+<a name="section-6.1"></a><h3 id="section-6.1">6.1. Developer Tools</h3>
+<p>Device implementations MUST support the Android Developer Tools provided in the Android SDK.
+Specifically, Android-compatible devices MUST be compatible with:</p>
+<ul>
+<li><b>Android Debug Bridge (known as adb)</b> [<a href="#resources33">Resources, 33</a>]<br/>
+Device implementations MUST support all <code>adb</code> functions as
+documented in the Android SDK. The device-side <code>adb</code> daemon MUST
+be inactive by default, and there MUST be a user-accessible mechanism to turn
+on the Android Debug Bridge.</li>
+<li>Android includes support for secure adb. Secure adb enables adb on known authenticated hosts.
+Device implementations MUST support secure adb.</li>
+<li><b>Dalvik Debug Monitor Service (known as ddms)</b> [<a href="#resources33">Resources, 33</a>]<br/>
+Device implementations MUST support all <code>ddms</code> features as documented in the
+Android SDK. As <code>ddms</code> uses <code>adb</code>, support for
+<code>ddms</code> SHOULD be inactive by default,
+but MUST be supported whenever the user has activated the Android Debug
+Bridge, as above.</li>
+<li><b>Monkey</b> [<a href="#resources36">Resources, 36</a>]<br/>
+Device implementations MUST include the Monkey framework, and make it
+available for applications to use.</li>
+<li><b>SysTrace</b> [<a href="#resources33">Resources, 33</a>]<br/>
+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.</li>
+</ul>
+<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 <code>adb</code> tool as provided in the standard Android
+SDK, device implementers MUST provide Windows drivers allowing developers to
+connect to the device using the <code>adb</code> protocol. These drivers MUST
+be provided for Windows XP, Windows Vista, Windows 7, and Windows 8, in both 32-bit and
+64-bit versions.</p>
+
+<a name="section-6.2"></a><h3 id="section-6.2">6.2. Developer Options</h3>
+<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="#resources77">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 Settings > About Device > Build Number 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>
+
+<a name="section-6.2.1"></a><h4 id="section-6.2.1">6.2.1. Experimental</h4>
+<p>Android 4.4 introduces ART, an experimental Android runtime, accessible 
+within the Developer Options menu for preview. Device
+implementations SHOULD include ART (libart.so) and support dual boot from
+Developer Options, but MUST keep Dalvik (libdvm.so) as the default runtime.</p>
+
+<a name="section-7"></a><h2 id="section-7">7. Hardware Compatibility</h2>
+<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's
+APIs MUST still be present</li>
+<li>the API's behaviors MUST be implemented as no-ops in some reasonable
+fashion</li>
+<li>API methods MUST return null values where permitted by the SDK
+documentation</li>
+<li>API methods MUST return no-op implementations of classes where null
+values are not permitted by the SDK documentation</li>
+<li>API methods MUST NOT throw exceptions not documented by the SDK
+documentation</li>
+</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 accurately report accurate hardware configuration
+information via the <code>getSystemAvailableFeatures()</code> and
+<code>hasSystemFeature(String)</code> methods on the
+<code>android.content.pm.PackageManager</code> class. [<a
+href="#resources37">Resources, 37</a>]</p>
+
+<a name="section-7.1"></a><h3 id="section-7.1">7.1. Display and Graphics</h3>
+<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="#resources38">Resources, 38</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>"Physical diagonal size" is the distance in inches between two opposing
+corners of the illuminated portion of the display.</li>
+<li>"dpi" (meaning "dots per inch") is 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>"Aspect ratio" is the ratio of the longer dimension of the screen to the
+shorter dimension. For example, a display of 480x854 pixels would be 854 / 480
+= 1.779, or roughly "16:9".</li>
+<li>A "density-independent pixel" or ("dp") is the virtual pixel unit normalized to a
+160 dpi screen, calculated as:
+<code>pixels = dps * (density / 160)</code>.</li>
+</ul>
+
+
+<a name="section-7.1.1"></a><h4 id="section-7.1.1">7.1.1. Screen Configuration</h4>
+
+<p style="font-weight:bold;">Screen Size</p>
+<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
+<code>android.content.res.Configuration.screenLayout</code> with the
+<code>SCREENLAYOUT_SIZE_MASK</code>. Device implementations MUST report the
+correct screen size as defined in the Android SDK documentation
+[<a href="#resources38">Resources, 38</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')</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, devices MUST have screen sizes of at least 2.5 inches in
+physical diagonal size.</p>
+
+<p>Devices MUST NOT change their reported screen size at any time.</p>
+<p>Applications optionally indicate which screen sizes they support via the
+<code>&lt;supports-screens&gt;</code> 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>
+
+<p style="font-weight:bold;">Screen Aspect Ratio</p>
+<p>The aspect ratio MUST be a value from 1.3333 (4:3) to 1.86 (roughly 16:9)</p>
+
+<p style="font-weight:bold;">Screen Density</p>
+<p>The Android UI framework defines a set of standard logical densities to
+help application developers target application resources. Device
+implementations MUST report one of the following logical Android framework
+densities through the <code>android.util.DisplayMetrics</code> APIs, and MUST
+execute applications at this standard density.
+<ul>
+<li>120 dpi, known as 'ldpi'</li>
+<li>160 dpi, known as 'mdpi'</li>
+<li>213 dpi, known as 'tvdpi'</li>
+<li>240 dpi, known as 'hdpi'</li>
+<li>320 dpi, known as 'xhdpi'</li>
+<li>400 dpi, known as '400dpi'</li>
+<li>480 dpi, known as 'xxhdpi'</li>
+<li>640 dpi, known as 'xxxhdpi'</li>
+</ul>
+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>
+
+<a name="section-7.1.2"></a><h4 id="section-7.1.2">7.1.2. Display Metrics</h4>
+<p>Device implementations MUST report correct values for all display metrics
+defined in <code>android.util.DisplayMetrics</code> [<a
+href="#resources39">Resources, 39</a>].</p>
+
+<a name="section-7.1.3"></a><h4 id="section-7.1.3">7.1.3. Screen Orientation</h4>
+<p>Devices 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>
+<p>Devices MUST report which screen orientations they support (
+<code>android.hardware.screen.portrait</code> and/or
+<code>android.hardware.screen.landscape</code>) and MUST report at least one
+supported orientation.  For example, a device with a fixed-orientation
+landscape screen, such as a television or laptop, MUST only report
+<code>android.hardware.screen.landscape</code>.</p>
+
+<a name="section-7.1.4"></a><h4 id="section-7.1.4">7.1.4. 2D and 3D Graphics Acceleration</h4>
+<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 on devices capable of supporting OpenGL ES 3.0.
+Device implementations MUST also support Android Renderscript, as detailed in the Android SDK
+documentation [<a href="#resources08">Resources, 8</a>].</p>
+<p>Device implementations MUST also correctly identify themselves as
+supporting OpenGL ES 1.0, OpenGL ES 2.0, or OpenGL ES 3.0. That is:</p>
+<ul>
+<li>The managed APIs (such as via the <code>GLES10.getString()</code> method)
+MUST report support for OpenGL ES 1.0 and OpenGL ES 2.0 </li>
+<li>The native C/C++ OpenGL APIs (that is, those 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 MUST support
+OpenGL ES 3.0 managed APIs and include support for native C/C++ APIs. On device
+implementations that declare support for OpenGL ES 3.0, libGLESv2.so MUST export the OpenGL ES 3.0
+function symbols in addition to the OpenGL ES 2.0 function symbols.
+</li>
+</ul>
+
+<p>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 <code>getString()</code> method in the OpenGL API.</p>
+
+<p>Android includes a mechanism for applications to declare that they
+wanted to enable hardware acceleration for 2D graphics at the Application,
+Activity, Window or View level through the use of a manifest tag
+<code>android:hardwareAccelerated</code> or direct API calls
+[<a href="#resources09">Resources, 9</a>].</p>
+<p>In Android 4.4, device implementations MUST enable hardware acceleration by
+default, and MUST disable hardware acceleration if the developer so requests
+by setting <code>android:hardwareAccelerated="false"</code> 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="#resources09">Resources, 9</a>].</p>
+<p>Android includes a <code>TextureView</code> object that lets developers
+directly integrate hardware-accelerated OpenGL ES textures as rendering targets
+in a UI hierarchy. Device implementations MUST support the <code>TextureView
+</code> API, and MUST exhibit consistent behavior with the upstream Android
+implementation.</p>
+<p>Android includes support for <code>EGL_ANDROID_RECORDABLE</code>, a EGLConfig attribute
+that indicates whether the EGLConfig supports rendering to an ANativeWindow that records images to a video.
+Device implementations MUST support <code>EGL_ANDROID_RECORDABLE</code> extension [<a href="#resources79">Resources, 79</a>].</p>
+
+<a name="section-7.1.5"></a><h4 id="section-7.1.5">7.1.5. Legacy Application Compatibility Mode</h4>
+<p>Android specifies a "compatibility mode" in which the framework
+operates in an '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. 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.</p>
+
+<a name="section-7.1.6"></a><h4 id="section-7.1.6">7.1.6. Screen Types</h4>
+<p>Device implementation screens are classified as one of two types:</p>
+<ul>
+<li>Fixed-pixel display implementations: the screen is a single panel that supports only a
+single pixel width and height. Typically the screen is physically integrated with
+the device. Examples include mobile phones, tablets, and so on.</li>
+<li>Variable-pixel display implementations: the device implementation either has no
+embedded screen and includes a video output port such as VGA, HDMI or a wireless port
+for display, or has an embedded screen that can change pixel dimensions. Examples
+include televisions, set-top boxes, and so on.</li>
+</ul>
+<p style="font-weight: bold;">Fixed-Pixel Device Implementations</p>
+<p>Fixed-pixel device implementations MAY use screens of any pixel dimensions, provided
+that they meet the requirements defined this Compatibility Definition.</p>
+<p>Fixed-pixel implementations MAY include a video output port for use with an
+external display. However, if that display is ever used for running apps, the
+device MUST meet the following requirements:</p>
+<ul>
+<li>The device MUST report the same screen configuration and display metrics, as detailed
+in Sections 7.1.1 and 7.1.2, as the fixed-pixel display.</li>
+<li>The device MUST report the same logical density as the fixed-pixel display.</li>
+<li>The device MUST report screen dimensions that are the same as, or very close to,
+the fixed-pixel display.</li>
+</ul>
+<p>For example, a tablet that is 7" diagonal size with a 1024x600 pixel resolution is
+considered a fixed-pixel large mdpi display implementation.  If it contains a video
+output port that displays at 720p or 1080p the device implementation MUST scale the output so that
+applications are only executed in a large mdpi window, regardless of whether the fixed-pixel display
+or video output port is in use.</p>
+
+<p style="font-weight: bold;">Variable-Pixel Device Implementations</p>
+<p>Variable-pixel device implementations MUST support at least one of 1280x720,
+1920x1080, or 3840x2160 (that is, 720p, 1080p, or 4K). Device implementations with
+variable-pixel displays MUST NOT support any other screen configuration or
+mode. Device implementations with variable-pixel screens MAY change screen
+configuration or mode at runtime or boot-time. For example, a user of a
+set-top box may replace a 720p display with a 1080p display, and the device
+implementation may adjust accordingly.</p>
+
+<p>Additionally, variable-pixel device implementations MUST report the following
+configuration buckets for these pixel dimensions:</p>
+<ul>
+<li>1280x720 (also known as 720p): 'large' screen size, 'tvdpi' (213 dpi)
+density</li>
+<li>1920x1080 (also known as 1080p): 'large' screen size, 'xhdpi' (320 dpi)
+density</li>
+<li>3840x2160 (also known as 4K): 'large' screen size, 'xxxhdpi' (640 dpi)
+density</li>
+</ul>
+<p>For clarity, device implementations with variable pixel dimensions are
+restricted to 720p, 1080p, or 4K in Android 4.4, and MUST be configured to report
+screen size and density buckets as noted above.</p>
+
+<a name="section-7.1.7"></a><h4 id="section-7.1.7">7.1.7. Screen Technology</h4>
+<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.  Specifically:</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.1. That is, the pixel aspect ratio MUST be near square (1.0) with
+    a 10% tolerance.</li>
+</ul>
+<a name="section-7.1.8"></a><h4 id="section-7.1.8">7.1.8. External Displays</h4>
+<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="#resources75">Resources, 75</a>].
+Device implementations that support secure video output and are capable of supporting secure surfaces MUST declare support
+for <code>Display.FLAG_SECURE</code>. Specifically, device implementations that declare support for <code>Display.FLAG_SECURE</code>,
+MUST support <b>HDCP 2.x or higher</b> for Miracast wireless displays or <b>HDCP 1.2 or higher</b> for wired displays. The upstream
+Android open source implementation includes support for wireless (Miracast) and wired (HDMI) displays that satisfies this requirement.</p>
+
+<a name="section-7.2"></a><h3 id="section-7.2">7.2. Input Devices</h3>
+<a name="section-7.2.1"></a><h4 id="section-7.2.1">7.2.1. Keyboard</h4>
+<p>Device implementations:</p>
+<ul>
+<li>MUST include support for the Input Management Framework (which allows third
+party developers to create Input Management Engines - 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)</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 <code>android.content.res.Configuration.keyboard</code>
+[<a href="#resources40">Resources, 40</a>] (that is, QWERTY, or 12-key)</li>
+</ul>
+<a name="section-7.2.2"></a><h4 id="section-7.2.2">7.2.2. Non-touch Navigation</h4>
+<p>Device implementations:</p>
+<ul>
+<li>MAY omit a non-touch navigation option (that is, may omit a trackball, d-pad,
+or wheel)</li>
+<li>MUST report the correct value for
+<code>android.content.res.Configuration.navigation</code>
+[<a href="#resources40">Resources, 40</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>
+<a name="section-7.2.3"></a><h4 id="section-7.2.3">7.2.3. Navigation keys</h4>
+<p>The Home, Recents and Back functions are essential to the Android navigation
+paradigm. Device implementations MUST make these functions available to the user
+at all times when running applications. 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>The Back and Recents functions SHOULD have a visible button or icon unless
+hidden together with other navigation functions in full-screen mode. The Home
+function MUST have a visible button or icon unless hidden together with other
+navigation functions in full-screen mode.</p>
+<p>The Menu function is deprecated in favor of action bar since Android 4.0.
+Device implementations SHOULD NOT implement a dedicated physical button for
+the Menu function. If the physical Menu button is implemented and the device
+is running applications with <code>targetSdkVersion</code> &gt; 10, the device
+implementation:</p>
+<ul>
+  <li>for a device launching with Android 4.4, MUST display the action overflow
+    button on the action bar when the action bar is visible and the resulting action
+    overflow menu popu is not empty.</li>
+  <li>for an existing device launched with an earlier version but upgrading to
+    Android 4.4, SHOULD display the action overflow button on the action bar
+    when the action bar is visible and the resulting action overflow menu popup
+    is not empty.</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 available the
+Menu function to applications when <code>targetSdkVersion</code> &lt;= 10,
+either by a phsyical 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="#resources63">Resources, 63</a>].
+Device implementations 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
+gestures, but MUST be accessible with a single action (e.g. tap, double-click or
+gesture) when other navigation keys are visible.</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="section-7.1.1">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
+      <code>SYSTEM_UI_FLAG_VISIBLE</code>.</li>
+  <li>Device implementations MUST present the navigation keys in an unobtrusive
+      "low profile" (eg. dimmed) mode when applications specify
+      <code>SYSTEM_UI_FLAG_LOW_PROFILE</code>.</li>
+  <li>Device implementations MUST hide the navigation keys when applications
+      specify <code>SYSTEM_UI_FLAG_HIDE_NAVIGATION</code>.</li>
+</ul>
+<a name="section-7.2.4"></a><h4 id="section-7.2.4">7.2.4. Touchscreen input</h4>
+<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 <code>android.hardware.touchscreen</code> or
+<code>android.hardware.faketouch</code> 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 <code>android.content.res.Configuration.touchscreen</code> [<a href="#resources40">Resources, 40</a>]
+corresponding to the type of the specific touchscreen on the device</li>
+</ul>
+
+<p>Android includes support for a variety of touch screens, touch pads, and fake touch input devices.
+Touch screen based device implementations are associated with a display [<a href="#resources81">Resources, 81</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 4.0 includes the feature constant <code>android.hardware.faketouch</code>,
+which corresponds to a high-fidelity non-touch (that is, 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="section 7.2.5">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 <code>android.hardware.touchscreen</code>.
+Device implementations that report the platform feature constant <code>android.hardware.touchscreen</code> MUST also report the platform feature constant
+<code>android.hardware.faketouch</code>. 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 <code>android.hardware.faketouch</code> if they meet the fake touch requirements in <a href="section 7.2.5">Section 7.2.5</a>.</p>
+
+<a name="section-7.2.5"></a><h4 id="section-7.2.5">7.2.5. Fake touch input</h4>
+<p>Device implementations that declare support for <code>android.hardware.faketouch</code></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="#resources80">Resources, 80</a>] </li>
+<li> MUST report touch event with the action code [<a href="#resources80">Resources, 80</a>] that specifies the state change
+that occurs on the pointer going <code>down</code> or <code>up</code> on the screen [<a href="#resources80">Resources, 80</a>] </li>
+<li> MUST support pointer <code>down</code> and <code>up</code> on an object on the screen, which allows users to emulate tap on an object on the screen</li>
+<li> MUST support pointer <code>down</code>, pointer <code>up</code>, pointer <code>down</code> then pointer <code>up</code> 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="#resources80">Resources, 80</a>]</li>
+<li>MUST support pointer <code>down</code> on an arbitrary point on the screen, pointer move to any other arbitrary point on the screen,
+followed by a pointer <code>up</code>, which allows users to emulate a touch drag</li>
+<li> MUST support pointer <code>down</code> then allow users to quickly move the object to a different position on the screen
+and then pointer <code>up</code> on the screen, which allows users to fling an object on the screen</li>
+</ul>
+
+<p>Devices that declare support for <code>android.hardware.faketouch.multitouch.distinct</code> MUST meet the requirements for
+faketouch above, and MUST also support distinct tracking of two or more independent pointer inputs.</p>
+
+<a name="section-7.2.6"></a><h4 id="section-7.2.6">7.2.6. Microphone</h4>
+<p>Device implementations MAY omit a microphone. However, if a device
+implementation omits a microphone, it MUST NOT report the
+<code>android.hardware.microphone</code> feature constant, and must implement
+the audio recording API as no-ops, per <a href="section-7">Section 7</a>.
+Conversely, device implementations that do possess a microphone:</p>
+<ul>
+<li>MUST report the <code>android.hardware.microphone</code> feature constant</li>
+<li>SHOULD meet the audio quality requirements in <a href="section-5.4">Section 5.4</a></li>
+<li>SHOULD meet the audio latency requirements in <a href="section-5.5">Section 5.5</a></li>
+</ul>
+
+<a name="section-7.3"></a><h3 id="section-7.3">7.3. Sensors</h3>
+<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. For example,
+device implementations:</p>
+<ul>
+<li>MUST accurately report the presence or absence of sensors per the
+<code>android.content.pm.PackageManager</code> class. [<a
+href="#resources37">Resources, 37</a>]</li>
+<li>MUST return an accurate list of supported sensors via the
+<code>SensorManager.getSensorList()</code> 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 (i.e. metric) values for each sensor type as defined in the Android SDK
+documentation [<a href="#resources41">Resources, 41</a>]</li>
+</ul>
+<p>The list above is not comprehensive; the documented behavior of the Android
+SDK is to be considered authoritative.</p>
+<p>Some sensor types are synthetic, 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.</p>
+<p>Android includes a notion of a "streaming" sensor, which is
+one that returns data continuously, rather than only when the data changes.
+Device implementations MUST continuously provide periodic data samples for any
+API indicated by the Android SDK documentation to be a streaming
+sensor. Note that the device implementations MUST ensure that the sensor stream must not
+prevent the device CPU from entering a suspend state or waking up from a suspend state.</p>
+
+<a name="section-7.3.1"></a><h4 id="section-7.3.1">7.3.1. Accelerometer</h4>
+<p>Device implementations SHOULD include a 3-axis accelerometer. If a device
+implementation does include a 3-axis accelerometer, it:</p>
+<ul>
+<li>SHOULD be able to deliver events at 120 Hz or greater. Note that while the
+accelerometer frequency above is stated as "SHOULD" for Android 4.4, the Compatibility Definition
+for a future version is planned to change these to "MUST". That is, these standards are
+optional in Android but <b>will be required</b> in future versions. Existing and
+new devices that run Android are <b>very strongly encouraged to meet these requirements
+in Android</b> so they will be able to upgrade to the future platform releases
+</li>
+<li>MUST comply with the Android sensor coordinate system as detailed
+in the Android APIs (see [<a href="#resources41">Resources, 41</a>])</li>
+<li>MUST be capable of measuring from freefall up to twice gravity (2g) or
+more on any three-dimensional vector</li>
+<li>MUST have 8-bits of accuracy or more</li>
+<li>MUST have a standard deviation no greater than 0.05 m/s^2</li>
+</ul>
+<a name="section-7.3.2"></a><h4 id="section-7.3.2">7.3.2. Magnetometer</h4>
+<p>Device implementations SHOULD include a 3-axis magnetometer (i.e. compass.)
+If a device does include a 3-axis magnetometer, it:</p>
+<ul>
+<li>MUST be able to deliver events at 10 Hz or greater</li>
+<li>MUST comply with the Android sensor coordinate system as detailed
+in the Android APIs (see [<a href="#resources41">Resources, 41</a>]).</li>
+<li>MUST be capable of sampling a range of field strengths adequate to cover the
+geomagnetic field</li>
+<li>MUST have 8-bits of accuracy or more</li>
+<li>MUST have a standard deviation no greater than 0.5 &micro;T</li>
+</ul>
+<a name="section-7.3.3"></a><h4 id="section-7.3.3">7.3.3. GPS</h4>
+<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>
+<a name="section-7.3.4"></a><h4 id="section-7.3.4">7.3.4. Gyroscope</h4>
+<p>Device implementations SHOULD include a gyroscope (i.e. 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 be temperature compensated.</li>
+<li>MUST be capable of measuring orientation changes up to 5.5*Pi
+radians/second (that is, approximately 1,000 degrees per second).</li>
+<li>SHOULD be able to deliver events at 200 Hz or greater. Note that while the
+gyroscope frequency above is stated as "SHOULD" for Android 4.4, the Compatibility Definition
+for a future version is planned to change these to "MUST". That is, these standards are
+optional in Android but <b>will be required</b> in future versions. Existing and
+new devices that run Android are <b>very strongly encouraged to meet these requirements</b> 
+so they will be able to upgrade to the future platform releases.
+</li>
+<li>MUST have 12-bits of accuracy or more</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 have timestamps as close to when the hardware event happened as possible. The constant latency must be removed.</li>
+</ul>
+<a name="section-7.3.5"></a><h4 id="section-7.3.5">7.3.5. Barometer</h4>
+<p>Device implementations MAY include a barometer (i.e. ambient air pressure
+sensor.) If a device implementation includes a barometer, it:</p>
+<ul>
+<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>
+<a name="section-7.3.6"></a><h4 id="section-7.3.6">7.3.6. Thermometer</h4>
+<p>Device implementations MAY include an ambient thermometer (i.e. temperature
+sensor). If present, it MUST be defined as <code>SENSOR_TYPE_AMBIENT_TEMPERATURE</code>
+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 <code>SENSOR_TYPE_TEMPERATURE</code>, it MUST
+measure the temperature of the device CPU, and it MUST NOT measure any other
+temperature. Note the <code>SENSOR_TYPE_TEMPERATURE</code> sensor type was
+deprecated in Android 4.0.</p>
+<a name="section-7.3.7"></a><h4 id="section-7.3.7">7.3.7. Photometer</h4>
+<p>Device implementations MAY include a photometer (i.e. ambient light
+sensor.)</p>
+<a name="section-7.3.8"></a><h4 id="section-7.3.8">7.3.8. Proximity Sensor</h4>
+<p>Device implementations MAY include a proximity sensor.  If a device
+implementation does include a proximity sensor, it 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. If a device
+implementation has a proximity sensor, it MUST be have 1-bit of accuracy or
+more.</p>
+
+<a name="section-7.4"></a><h3 id="section-7.4">7.4. Data Connectivity</h3>
+<a name="section-7.4.1"></a><h4 id="section-7.4.1">7.4.1. Telephony</h4>
+<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 sub-features, 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>
+<a name="section-7.4.2"></a><h4 id="section-7.4.2">7.4.2. IEEE 802.11 (Wi-Fi)</h4>
+<p>Android device implementations SHOULD include support for one or more
+forms of 802.11 (b/g/a/n, etc.) If a device implementation does include
+support for 802.11, it MUST implement the corresponding Android API.</p>
+<p>Device implementations MUST implement the multicast API as described in
+the SDK documentation [<a href="#resources62">Resources, 62</a>]. Device
+implementations that do include Wi-Fi support MUST support multicast DNS (mDNS).
+Device implementations MUST NOT filter mDNS packets (224.0.0.251) at any time
+of operation including when the screen is not in an active state.</p>
+
+<a name="section-7.4.2.1"></a>
+<h4 id="section-7.4.2.1">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="#resources68">Resources, 68</a>].
+If a device implementation includes support for Wi-Fi direct, then it:</p>
+<ul>
+  <li>MUST support regular Wi-Fi operation</li>
+  <li>SHOULD support concurrent Wi-Fi and Wi-Fi Direct operation</li>
+</ul>
+
+<a name="section-7.4.2.2"></a><h4 id="section-7.4.2.2">7.4.2.2. Wi-Fi Tunneled Direct Link Setup</h4>
+<p>Device implementations SHOULD include support for Wi-Fi Tunneled Direct Link
+Setup (TDLS) as described in the Android SDK Documentation
+[<a href="#resources85">Resources, 85</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>
+
+<a name="section-7.4.3"></a><h4 id="section-7.4.3">7.4.3. Bluetooth</h4>
+<p>Device implementations SHOULD include a Bluetooth transceiver. Device
+implementations that do include a Bluetooth transceiver MUST enable the
+RFCOMM-based Bluetooth API as described in the SDK documentation and declare
+hardware feature android.hardware.bluetooth [<a href="#resources42">Resources, 42</a>].
+Device implementations SHOULD implement relevant Bluetooth profiles, such as A2DP, AVRCP, OBEX, etc. as
+appropriate for the device.</p>
+
+<p>Device implementations that do include support for Bluetooth GATT (generic attribute profile)
+to enable communication with Bluetooth Smart or Smart Ready devices MUST enable the
+GATT-based Bluetooth API as described in the SDK documentation and declare hardware feature
+android.hardware.bluetooth_le [<a href="#resources42">Resources, 42</a>].</p>
+
+<a name="section-7.4.4"></a><h4 id="section-7.4.4">7.4.4. Near-Field Communications</h4>
+<p>Device implementations SHOULD include a transceiver and related hardware
+for Near-Field Communications (NFC). If a device implementation does include
+NFC hardware, then it:</p>
+<ul>
+  <li>MUST report the android.hardware.nfc feature from the
+      <code>android.content.pm.PackageManager.hasSystemFeature()</code> method.
+      [<a href="#resources37">Resources, 37</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 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>
+   </ul>
+  </li>
+  <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". That is, these standards are optional in this
+      version but <b>will be required</b> in future versions. Existing and new
+      devices that run this version of Android are <b>very strongly encouraged
+      to meet these requirements now</b> so they will be able to upgrade to the
+      future platform releases.
+    <ul>
+      <li>NfcV (ISO 15693)</li>
+    </ul>
+  </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>SDP 1.0 (defined by the NFC Forum)</li>
+      <li>NDEF Push Protocol [<a href="#resources43">Resources, 43</a>]</li>
+      <li>SNEP 1.0 (defined by the NFC Forum)</li>
+    </ul>
+  </li>
+  <li>MUST include support for Android Beam [<a href="#resources65">Resources, 65</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>Device implementations MUST honor the android.settings.NFCSHARING_SETTINGS intent
+        to show NFC sharing settings [<a href="#resources67">Resources, 67</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</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="#resources60">Resources, 60</a>]
+        and "Bluetooth Secure Simple Pairing Using NFC version 1.0" [<a href="#resources61">Resources, 61</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>
+
+<p>(Note that publicly available links are not available for the JIS, ISO, and
+NFC Forum specifications cited above.)</p>
+<p>Android 4.4 introduces support for NFC Host Card Emulation (HCE) mode. If a
+device implementation does include an NFC controller capable of HCE and
+Application ID (AID) routing, then it:</p>
+<ul>
+  <li>MUST report the <code>android.hardware.nfc.hce</code> feature constant
+  </li>
+  <li>MUST support NFC HCE APIs as defined in the Android SDK
+  [<a href="#resources90">Resources, 90</a>]</li>
+</ul>
+<p>Additionally, device implementations MAY include reader/writer support for
+the following MIFARE technologies.</p>
+<ul>
+  <li>MIFARE Classic (NXP MF1S503x [<a href="#resources44">Resources, 44</a>],
+      MF1S703x [<a href="#resources45">Resources, 45</a>])</li>
+  <li>MIFARE Ultralight (NXP MF0ICU1 [<a href="#resources46">Resources, 46</a>],
+      MF0ICU2 [<a href="#resources47">Resources, 47</a>])</li>
+  <li>NDEF on MIFARE Classic (NXP AN130511 [<a href="#resources48">Resources, 48</a>],
+      AN130411 [<a href="#resources49">Resources, 49</a>])</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
+  <code>android.content.pm.PackageManager.hasSystemFeature()</code> method.
+  [<a href="#resources37">Resources, 37</a>] Note that this is not a standard
+  Android feature, and as such does not appear as a constant on the
+  <code>PackageManager</code> 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
+<code>android.content.pm.PackageManager.hasSystemFeature()</code> method [<a
+href="#resources37">Resources, 37</a>], and MUST implement the Android NFC
+API as a no-op.</p>
+<p>As the classes <code>android.nfc.NdefMessage</code> and
+<code>android.nfc.NdefRecord</code> 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>
+<a name="section-7.4.5"></a><h4 id="section-7.4.5">7.4.5. Minimum Network Capability</h4>
+<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, 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>
+
+<a name="section-7.4.6"></a><h4 id="section-7.4.6">7.4.6. Sync Settings</h4>
+<p>Device implementations MUST have the master auto-sync setting on by default
+so that the method <code>getMasterSyncAutomatically()</code> returns
+&quot;true&quot; [<a href="#resources88">Resources, 88</a>].</p>
+
+<a name="section-7.5"></a><h3 id="section-7.5">7.5. Cameras</h3>
+<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>
+<a name="section-7.5.1"></a><h4 id="section-7.5.1">7.5.1. Rear-Facing Camera</h4>
+<p>Device implementations SHOULD include a rear-facing camera. If a device
+implementation includes a rear-facing camera, it:</p>
+<ul>
+<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 <code>FLASH_MODE_AUTO</code> or
+<code>FLASH_MODE_ON</code> attributes of a <code>Camera.Parameters</code>
+object. Note that this constraint does not apply to the device's built-in
+system camera application, but only to third-party applications using
+<code>Camera.PreviewCallback</code>.</li>
+</ul>
+<a name="section-7.5.2"></a><h4 id="section-7.5.2">7.5.2. Front-Facing Camera</h4>
+<p>Device implementations MAY include a front-facing camera. If a device
+implementation includes a front-facing camera, it:</p>
+<ul>
+<li>MUST have a resolution of at least VGA (that is, 640x480 pixels)</li>
+<li>MUST NOT use a front-facing camera as the default for the Camera API.
+That is, 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 Section 7.5.1.</li>
+<li>MUST horizontally reflect (i.e. mirror) the stream displayed by an app in a
+CameraPreview, as follows:</li>
+<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
+<code>android.hardware.Camera.setDisplayOrientation()</code> [<a
+href="#resources50">Resources, 50</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>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>
+<a name="section-7.5.3"></a><h4 id="section-7.5.3">7.5.3. Camera API Behavior</h4>
+<p>Device implementations MUST implement the following behaviors for the
+camera-related APIs, for both front- and rear-facing cameras:</p>
+<ol>
+<li>If an application has never called
+<code>android.hardware.Camera.Parameters.setPreviewFormat(int)</code>, then the
+device MUST use <code>android.hardware.PixelFormat.YCbCr_420_SP</code> for
+preview data provided to application callbacks.</li>
+<li>If an application registers an <code>android.hardware.Camera.PreviewCallback
+</code> instance and the system calls the <code>onPreviewFrame()</code> method
+when the preview format is YCbCr_420_SP, the data in the <code>byte[]</code>
+passed into <code>onPreviewFrame()</code> must further be in the NV21 encoding
+format. That is, NV21 MUST be the default.</li>
+<li>Device implementations MUST support the YV12 format (as denoted by the
+<code>android.graphics.ImageFormat.YV12</code> 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>
+</ol>
+<p>Device implementations MUST implement the full Camera API included in the
+Android SDK documentation [<a href="#resources51">Resources, 51</a>]),
+regardless of whether the device includes hardware autofocus or other
+capabilities. For instance, cameras that lack autofocus MUST still call any
+registered <code>android.hardware.Camera.AutoFocusCallback</code> 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 <code>android.hardware.Camera.Parameters</code> 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 <code>android.hardware.Camera.setParameters()</code> method other than
+those documented as constants on the
+<code>android.hardware.Camera.Parameters</code>.  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 <code>Camera.SCENE_MODE_HDR</code>
+[<a href="#resources78">Resources, 78</a>]).</p>
+<p>Device implementations MUST broadcast the <code>Camera.ACTION_NEW_PICTURE</code>
+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 <code>Camera.ACTION_NEW_VIDEO</code>
+intent whenever a new video is recorded by the camera and the entry of the picture
+has been added to the media store.</p>
+<a name="section-7.5.4"></a><h4 id="section-7.5.4">7.5.4. Camera Orientation</h4>
+<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>
+
+<a name="section-7.6"></a><h3 id="section-7.6">7.6. Memory and Storage</h3>
+<a name="section-7.6.1"></a><h4 id="section-7.6.1">7.6.1. Minimum Memory and Storage</h4>
+<p>Device implementations MUST have at least 340MB of memory available to the
+kernel and userspace. The 340MB MUST be in addition to any memory 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 MUST return the value &quot;true&quot; for
+<code>ActivityManager.isLowRamDevice()</code>.</p>
+<p>Device implementations MUST have at least 1GB of non-volatile storage available
+for application private data. That is, the <code>/data</code> partition MUST be at
+least 1GB. Device implementations that run Android are <b>very strongly encouraged to
+have at least 2GB of non-volatile storage for application private data</b> 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="#resources56">Resources, 56</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>
+<a name="section-7.6.2"></a><h4 id="section-7.6.2">7.6.2. Shared External Storage</h4>
+<p>Device implementations MUST offer shared storage for applications. The
+shared storage provided MUST be at least 1GB in size.</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 <code>/sdcard</code>, then the device MUST include a Linux symbolic link
+from <code>/sdcard</code> to the actual mount point.</p>
+<p>Device implementations MUST enforce as documented the
+<code>android.permission.WRITE_EXTERNAL_STORAGE</code> permission on this
+shared storage. Shared storage MUST otherwise be writable by any application
+that obtains that permission.</p>
+<p>Device implementations MAY have hardware for user-accessible removable
+storage, such as a Secure Digital card. Alternatively, device implementations
+MAY allocate internal (non-removable) storage as shared storage for apps. The
+upstream Android Open Source Project includes an implementation that uses
+internal device storage for shared external storage APIs; device implementations
+SHOULD use this configuration and software implementation.</p>
+<p>Regardless of the form of shared storage used, device implementations MUST
+provide some mechanism to access the contents of shared storage from a host
+computer, such as USB mass storage (UMS) or Media Transfer Protocol (MTP). Device
+implementations MAY use USB mass storage, but SHOULD use Media Transfer
+Protocol. If the device implementation supports Media Transfer Protocol:</p>
+<ul>
+<li>The device implementation SHOULD be compatible with the reference Android
+MTP host, Android File Transfer [<a href="#resources57">Resources, 57</a>].</li>
+<li>The device implementation SHOULD report a USB device class of <code>0x00</code>.</li>
+<li>The device implementation SHOULD report a USB interface name of 'MTP'.</li>
+</ul>
+<p>If the device implementation lacks USB ports, it MUST provide a host
+computer with access to the contents of shared storage by some other means,
+such as a network file system.</p>
+<p>It is illustrative to consider two common examples. If a device
+implementation includes an SD card slot to satisfy the shared storage
+requirement, a FAT-formatted SD card 1GB in size or larger MUST be included
+with the device as sold to users, and MUST be mounted by default.
+Alternatively, if a device implementation uses internal fixed storage to
+satisfy this requirement, that storage MUST be 1GB in size or larger
+and mounted on <code>/sdcard</code> (or <code>/sdcard</code>
+MUST be a symbolic link to the physical location if it is mounted elsewhere.)</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>
+
+<a name="section-7.7"></a><h3 id="section-7.7">7.7. USB</h3>
+<p>Device implementations SHOULD include a USB client port, and SHOULD include
+a USB host port.</p>
+<p>If a device implementation includes a USB client port:</p>
+<ul>
+<li>the port MUST be connectable to a USB host with a standard USB-A port</li>
+<li>the port SHOULD use the micro USB form factor on the device side. Existing and
+new devices that run Android are <b>very strongly encouraged to meet these requirements
+in Android</b> 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 devices that run Androidare <b>very strongly
+encouraged to meet these requirements in Android</b> so they will be able to upgrade to future platform releases.</li>
+<li>if the device has other ports (such as a non-USB charging port) it SHOULD be on the same edge as the
+micro-USB port</li>
+<li>it MUST allow a host connected to the device to access the contents of the
+shared storage volume using either USB mass storage or Media Transfer
+Protocol</li>
+<li>it MUST implement the Android Open Accessory API and specification as documented
+in the Android SDK documentation, and MUST declare support for the hardware
+feature <code>android.hardware.usb.accessory</code> [<a href="#resources52">Resources,
+52</a>]</li>
+<li>it MUST implement the USB audio class as documented in the Android SDK documentation [<a href="#resources66">Resources, 66</a>]</li>
+<li>it SHOULD implement support for USB battery charging specification [<a href="#resources64">Resources, 64</a>]
+Existing and new devices that run Android are <b>very strongly encouraged to
+meet these requirements</b>
+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 host port:</p>
+<ul>
+<li>it MAY use a non-standard port form factor, but if so MUST ship with a
+cable or cables adapting the port to standard USB-A</li>
+<li>it MUST implement the Android USB host API as documented in the Android
+SDK, and MUST declare support for the hardware feature
+<code>android.hardware.usb.host</code> [<a href="#resources53">Resources, 53</a>]</li>
+</ul>
+<p>Device implementations MUST implement the Android Debug Bridge. If a device
+implementation omits a USB client port, it MUST implement the Android Debug
+Bridge via local-area network (such as Ethernet or 802.11)</p>
+
+<a name="section-8"></a><h2 id="section-8">8. Performance Compatibility</h2>
+<p>Device implementations MUST meet the key performance metrics of an Android-
+compatible device defined in the table below:</p>
+<table><tbody><tr>
+<td><b>Metric</b></td>
+<td><b>Performance Threshold</b></td>
+<td><b>Comments</b></td>
+</tr>
+<tr>
+<td>Application Launch Time</td>
+<td>The following applications should launch within the specified time.<ul>
+<li>Browser: less than 1300ms</li>
+<li>Contacts: less than 700ms</li>
+<li>Settings: less than 700ms</li>
+</ul></td>
+<td>The launch time is measured as the total time to
+complete loading the default activity for the application, including the time
+it takes to start the Linux process, load the Android package into the Dalvik
+VM, and call onCreate.</td>
+</tr>
+<tr>
+<td>Simultaneous Applications</td>
+<td>When multiple applications have been launched, re-launching an
+already-running application after it has been launched must take less than the
+original launch time.</td>
+<td>&nbsp;</td>
+</tr>
+</tbody>
+</table>
+
+<a name="section-9"></a><h2 id="section-9">9. Security Model Compatibility</h2>
+<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="#resources54">Resources, 54</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 sub-sections.</p>
+<a name="section-9.1"></a><h3 id="section-9.1">9.1. Permissions</h3>
+<p>Device implementations MUST support the Android permissions model as
+defined in the Android developer documentation [<a
+href="#resources54">Resources, 54</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>
+<a name="section-9.2"></a><h3 id="section-9.2">9.2. UID and Process Isolation</h3>
+<p>Device implementations MUST support the Android application sandbox model,
+in which each application runs as a unique Unix-style 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="#resources54">Resources, 54</a>].</p>
+<a name="section-9.3"></a><h3 id="section-9.3">9.3. Filesystem Permissions</h3>
+<p>Device implementations MUST support the Android file access permissions
+model as defined in the Security and Permissions reference [<a
+href="#resources54">Resources, 54</a>].</p>
+<a name="section-9.4"></a><h3 id="section-9.4">9.4. Alternate Execution Environments</h3>
+<p>Device implementations MAY include runtime environments that execute
+applications using some other software or technology than the Dalvik virtual
+machine 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 Section 9.</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
+   <code>&lt;uses-permission&gt;</code> 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:</p>
+<ul>
+<li>Alternate runtimes SHOULD install apps via the PackageManager into
+    separate Android sandboxes (that is, Linux user IDs, etc.)</li>
+<li>Alternate runtimes MAY provide a single Android sandbox shared by all
+    applications using the alternate runtime</li>
+<li>Alternate runtimes 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>Alternate runtimes MUST NOT launch with, grant, or be granted access to
+    the sandboxes corresponding to other Android applications</li>
+</ul>
+<p>Alternate runtimes MUST NOT be launched with, be granted, or grant to other
+   applications any privileges of the superuser (root), or of any other user ID.</p>
+<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. That is, 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>
+
+<a name="section-9.5"></a><h3 id="section-9.5">9.5. Multi-User Support </h3>
+<p>Android includes support for multiple users and provides support for full user isolation
+[<a href="#resources70">Resources, 70</a>].</p>
+<p>Device implementations MUST meet these requirements related to multi-user support [<a href="#resources71">Resources, 71</a>]:</p>
+<ul>
+<li>As the behavior of the telephony APIs on devices with multiple users is currently undefined, device implementations that
+declare android.hardware.telephony MUST NOT enable multi-user support. </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 [Resources, 54]</li>
+<li>Android includes support for 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. Device implementations that include support for multiple users
+MUST include support for restricted profiles. The upstream Android Open Source Project includes an implementation that satisfies this requirement.</li>
+</ul>
+
+<p>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 multi-user 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="#resources72">Resources, 72</a>] for primary external storage.</p>
+
+<a name="section-9.6"></a><h3 id="section-9.6">9.6. Premium SMS Warning</h3>
+<p>Android includes support for warning users for any outgoing premium SMS message [<a href="#resources73">Resources, 73</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 <code>android.hardware.telephony</code> MUST warn users before sending a SMS message to numbers identified by regular expressions defined in <code>/data/misc/sms/codes.xml</code> file in the device.
+The upstream Android Open Source Project provides an implementation that satisfies this requirement.
+</p>
+
+<a name="section-9.7"></a><h3 id="section-9.7">9.7. Kernel Security Features</h3>
+<p>The Android Sandbox includes features that can 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 Android framework:</p>
+<ul>
+<li>MUST maintain compatibility with existing applications</li>
+<li>MUST not have a visible user interface, even when violations are detected
+</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 and meet the following requirements, which
+are satisfied by the reference implementation in the upstream Android Open
+Source Project.</p>
+<ul>
+<li>it MUST support a SELinux policy that allows the SELinux mode to be set on
+a per-domain basis with:</li>
+<ul>
+  <li>domains that are in enforcing mode in the upstream Android Open Source
+  implementation (such as installd, netd, and vold) MUST be in enforcing mode
+  </li>
+  <li>domain(s) for third-party applications SHOULD remain in permissive mode to
+   ensure continued compatibility</li>
+</ul>
+<li>it SHOULD load policy from <code>/sepolicy</code> file on the device</li>
+<li>it MUST support dynamic updates of the SELinux policy file without requiring
+a system image update</li>
+<li>it MUST log any policy violations without breaking applications or affecting
+system behavior</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>
+
+<a name="section-9.8"></a><h3 id="section-9.8">9.8. Privacy</h3>
+<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>
+
+<a name="section-9.9"></a><h3 id="section-9.9">9.9. Full-Disk Encryption</h3>
+<p>IF the device has lockscreen, the device MUST support full-disk
+encryption.</p>
+
+<a name="section-10"></a><h2 id="section-10">10. Software Compatibility Testing</h2>
+<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 very strongly encouraged 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>
+<a name="section-10.1"></a><h3 id="section-10.1">10.1. Compatibility Test Suite</h3>
+<p>Device implementations MUST pass the Android Compatibility Test Suite (CTS)
+[<a href="#resources02">Resources, 2</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 4.4. Device implementations MUST pass the latest CTS version
+available at the time the device software is completed.</p>
+<a name="section-10.2"></a><h3 id="section-10.2">10.2. CTS Verifier</h3>
+<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 which 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>
+<a name="section-10.3"></a><h3 id="section-10.3">10.3. Reference Applications</h3>
+<p>Device implementers MUST test implementation compatibility using the
+following open source applications:</p>
+<ul>
+<li>The "Apps for Android" applications [<a href="#resources55">Resources, 55</a>]</li>
+<li>Replica Island (available in Google Play Store)</li>
+</ul>
+<p>Each app above MUST launch and behave correctly on the implementation, for
+the implementation to be considered compatible.</p>
+
+
+<a name="section-11"></a><h2 id="section-11">11. Updatable Software</h2>
+<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>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>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>
+
+<a name="section-12"></a><h2 id="section-12">12. Document Changelog</h2>
+<p>The following table contains a summary of the changes to the Compatibility Definition in this release.</p>
+<table width="100%" border="1">
+  <tr>
+    <th width="25%" scope="col">Section(s)</th>
+    <th width="75%" scope="col">Summary of change</th>
+  </tr>
+  <tr>
+    <td>3.2.2. Build Parameters</td>
+    <td>Revised descriptions of BRAND, DEVICE, and PRODUCT. SERIAL is now
+required.</td>
+  </tr>
+  <tr>
+    <td>3.2.3.5. Default App Settings</td>
+    <td>New section that adds requirement to comply with new default
+    application settings</td>
+  </tr>
+  <tr>
+    <td>3.3.1 Application Binary Interfaces</td>
+    <td>Clarified allowed values for the <code>android.os.Build.CPU_ABI</code>
+     and <code>android.os.Build.CPU_ABI2</code> parameters.</td>
+  </tr>
+  <tr>
+    <td>3.4.1. WebView Compatibility</td>
+    <td>Added Chromium as required WebView implementation.</td>
+  </tr>
+  <tr>
+    <td>3.7. Virtual Machine Compatibility</td>
+    <td>Added requirement for xxhdpi and 400dpi screen densities.</td>
+  </tr>
+  <tr>
+    <td>3.8.6. Themes</td>
+    <td>Updated to reflect use of translucent system bars.</td>
+  </tr>
+  <tr>
+    <td>3.8.12. Location</td>
+    <td>New section that adds requirement location settings be centralized.</td>
+  </tr>
+  <tr>
+    <td>3.8.13. Unicode</td>
+    <td>New section that adds requirement for emoji support.</td>
+  </tr>
+  <tr>
+    <td>3.9. Device Administration</td>
+    <td>Noted preinstalled administrative applications cannot be the default 
+     Device Owner application.</td>
+  </tr>
+  <tr>
+    <td>5.1. Media Codecs</td>
+    <td>Added VP9 decoder requirement. Added recommended specification for
+     hardware VP8 codecs.</td>
+  </tr>
+  <tr>
+    <td>5.3. Video Decoding</td>
+    <td>Added VP9. Added recommendation for dynamic resolution switching.</td> 
+  </tr>
+  <tr>
+    <td>5.4. Audio Recording</td>
+    <td>Added <code>REMOTE_SUBMIX</code> as new required audio source. Made use
+     of <code>android.media.audiofx.NoiseSuppressor</code> API a requirement.</td>
+  </tr>
+  <tr>
+    <td>6.2.1 Experimental</td>
+    <td>New section that introduces the ART runtime and requires Dalvik as the
+      default runtime.</td>
+  </tr>
+  <tr>
+    <td>7.1.1. Screen Configuration</td>
+    <td>Replaced 1.85 aspect ratio with 1.86. Added 400dpi screen density.</td>
+  </tr>
+  <tr>
+    <td>7.1.6. Screen Types</td>
+    <td>Added 640 dpi (4K) resolution configuration.</td>
+  </tr>
+  <tr>
+    <td>7.2.3. Navigation keys</td>
+    <td>Added Recents function as essential; demoted Menu function in priority.</td>
+  </tr>
+  <tr>
+    <td>7.3.6. Thermometer</td>
+    <td>Added SENSOR_TYPE_AMBIENT_TEMPERATURE as recommended thermometer.</td>
+  </tr>
+  <tr>
+    <td>7.4.2.2. Wi-Fi Tunneled Direct Link Setup</td>
+    <td>New section that adds support for Wi-Fi Tunneled Direct Link Setup
+     (TDLS).</td>
+  </tr>
+  <tr>
+    <td>7.4.4. Near-Field Communications</td>
+    <td>Added Host Card Emulation (HCE) as a requirement. Replaced SNEP GET with
+     Logical Link Control Protocol (LLCP) and added the Bluetooth Object Push
+     Profile as a requirement.</td>
+  </tr>
+  <tr>
+    <td>7.4.6. Sync Settings</td>
+    <td>New section that adds requirement auto-sync data be enabled by default.</td>
+  </tr>
+  <tr>
+    <td>7.6.1. Minimum Memory and Storage</td>
+    <td>Added <code>ActivityManager.isLowRamDevice()</code> setting requirement
+    for devices with less than 512MB of memory. Increased storage requirements 
+    from 512MB and 1GB to 1GB and 2GB, respectively.</td>
+  </tr>
+  <tr>
+    <td>7.6.2. Shared "External" Storage</td>
+    <td>Editorial fixes such as change of section name, and moved text that fits
+     in this section from section 9.5. Noted applications may write to their
+     package-specific directories on secondary external storage.</td> 
+  </tr>
+  <tr>
+    <td>7.7. USB</td>
+    <td>Added requirement all devices report a USB serial number.</td>
+  </tr>
+  <tr>
+    <td>9.5. Multi-User Support</td>
+    <td>Moved non multi-user specific text to  section 7.6.2.</td>
+  </tr>
+  <tr>
+    <td>9.7. Kernel Security Features</td>
+    <td>Rewritten to note switch of SELinux to enforcing mode and requirement
+     SELinux output not be rendered in the user interface.</td>
+  </tr>
+  <tr>
+    <td>9.8. Privacy</td>
+    <td>New section that adds requirement audio and video recording must trigger
+     continuous notifications to the user.</td>
+  </tr>
+  <tr>
+    <td>9.9. Full-Disk Encryption</td>
+    <td>New section that adds requirement devices with lockscreen support full-disk encryption.</td>
+  </tr>
+  <tr>
+    <td>12. Document Changelog</td>
+    <td>New section that summarizes changes in the CDD by section.</td>
+  </tr>
+</table>
+<p>&nbsp;</p>
+
+<a name="section-13"></a><h2 id="section-13">13. Contact Us</h2>
+<p>You can contact the document authors at <a
+href="mailto:compatibility@android.com">compatibility@android.com</a> for
+clarifications and to bring up any issues that you think the document does not
+cover.</p>
+
+<div style="page-break-before: always;"></div>
+
+<div id="footerContent" xmlns:pdf="http://whatever">
+<pdf:pagenumber/>
+</div>
+</body>
+</html>
diff --git a/src/compatibility/5.0/android-5.0-cdd.xhtml b/src/compatibility/5.0/android-5.0-cdd.xhtml
new file mode 100644
index 0000000..76c50ac
--- /dev/null
+++ b/src/compatibility/5.0/android-5.0-cdd.xhtml
@@ -0,0 +1,6066 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+<head>
+<title>Android 5.0 Compatibility Definition</title>
+<link rel="stylesheet" type="text/css" href="cdd.css"/>
+</head>
+<body>
+<div><img src="header.jpg" alt="Android logo"/></div>
+<h1>Android 5.0 Compatibility Definition</h1>
+<!--
+<span style="color: red; font-weight: bold;"><h2>Revision 1</h2></span><br/>
+<span style="color: red;">Last updated: July 23, 2013</span>
+-->
+<p><b><font color="red">Revision 1</font></b><br/>
+Last updated: January 12, 2015
+</p>
+<p>Copyright &copy; 2015, Google Inc. All rights reserved.<br/>
+<a href="mailto:compatibility@android.com">compatibility@android.com</a>
+</p>
+
+<h1 id=table_of_contents>Table of Contents</h1>
+
+<table>
+ <tr>
+    <td>
+<p><a href="#heading=h.msc7y995n414">1. Introduction</a></p>
+
+<p><a href="#heading=h.40sdoojaw5k9">2. Device Types</a></p>
+
+<p><a href="#heading=h.562rcc5o7p3c">2.1 Device Configurations</a></p>
+
+<p><a href="#heading=h.yhzgiu12663m">3. Software</a></p>
+
+<p><a href="#heading=h.kr68507hndy4">3.1. Managed API Compatibility</a></p>
+
+<p><a href="#heading=h.klxc9p5alm1k">3.2. Soft API Compatibility</a></p>
+
+<p><a href="#heading=h.db11p7gvg81n">3.2.1. Permissions</a></p>
+
+<p><a href="#heading=h.3710ebc7nsew">3.2.2. Build Parameters</a></p>
+
+<p><a href="#heading=h.gthv9fjcs0pe">3.2.3. Intent Compatibility</a></p>
+
+<p><a href="#heading=h.qiy4ddbiirgy">3.2.3.1. Core Application Intents</a></p>
+
+<p><a href="#heading=h.bpmvwqbxsymp">3.2.3.2. Intent Overrides</a></p>
+
+<p><a href="#heading=h.r3yyvgtvim43">3.2.3.3. Intent Namespaces</a></p>
+
+<p><a href="#heading=h.r8urpa426zy">3.2.3.4. Broadcast Intents</a></p>
+
+<p><a href="#heading=h.oek6k3rdi0v8">3.2.3.5. Default App Settings</a></p>
+
+<p><a href="#heading=h.3dpths90svxf">3.3. Native API Compatibility</a></p>
+
+<p><a href="#heading=h.jcm6fp8o7lhj">3.3.1 Application Binary Interfaces</a></p>
+
+<p><a href="#heading=h.svlldf3npn1t">3.4. Web Compatibility</a></p>
+
+<p><a href="#heading=h.swqsalizdkk8">3.4.1. WebView Compatibility</a></p>
+
+<p><a href="#heading=h.minm6jqu934x">3.4.2. Browser Compatibility</a></p>
+
+<p><a href="#heading=h.xq343byyb0fz">3.5. API Behavioral Compatibility</a></p>
+
+<p><a href="#heading=h.blmhfmxlmvir">3.6. API Namespaces</a></p>
+
+<p><a href="#heading=h.5159yfnui03c">3.7. Runtime Compatibility</a></p>
+
+<p><a href="#heading=h.6jv9libgzj5i">3.8. User Interface Compatibility</a></p>
+
+<p><a href="#heading=h.uihb1eijkvo">3.8.1. Launcher (Home Screen)</a></p>
+
+<p><a href="#heading=h.v9h5ffzht332">3.8.2. Widgets</a></p>
+
+<p><a href="#heading=h.i9vjtu1lr6go">3.8.3. Notifications</a></p>
+
+<p><a href="#heading=h.6hexhtx5tmrs">3.8.4. Search</a></p>
+
+<p><a href="#heading=h.xc1emmi207w5">3.8.5. Toasts</a></p>
+
+<p><a href="#heading=h.qip8398skywq">3.8.6. Themes</a></p>
+
+<p><a href="#heading=h.c5ay2hae9td">3.8.7. Live Wallpapers</a></p>
+
+<p><a href="#heading=h.zc10jlx04bz">3.8.8. Activity Switching</a></p>
+
+<p><a href="#heading=h.z2dmdulh39vh">3.8.9. Input Management</a></p>
+
+<p><a href="#heading=h.y1dfuxk4g759">3.8.10. Lock Screen Media Control</a></p>
+
+<p><a href="#heading=h.w9tpfodgdigq">3.8.11. Dreams</a></p>
+
+<p><a href="#heading=h.ifi3tjbpjckl">3.8.12. Location</a></p>
+
+<p><a href="#heading=h.ugmg9aj091f8">3.8.13. Unicode and Font</a></p>
+</td>
+    <td>
+<p><a href="#heading=h.yyjxs5mhy231">3.9. Device Administration</a></p>
+
+<p><a href="#heading=h.ynv25r97q6m">3.10. Accessibility</a></p>
+
+<p><a href="#heading=h.d6m0oago1d3y">3.11. Text-to-Speech</a></p>
+
+<p><a href="#heading=h.zdns59cgtxwy">3.12. TV Input Framework</a></p>
+
+<p><a href="#heading=h.z51ce4vpkix">4. Application Packaging Compatibility</a></p>
+
+<p><a href="#heading=h.ddcqv1ggh4y7">5. Multimedia Compatibility</a></p>
+
+<p><a href="#heading=h.qj4xbxk4bysl">5.1. Media Codecs</a></p>
+
+<p><a href="#heading=h.iad8gjulqe75">5.1.1. Audio Codecs</a></p>
+
+<p><a href="#heading=h.rv9qy784zhuc">5.1.2. Image Codecs</a></p>
+
+<p><a href="#heading=h.gxu0pnbldfle">5.1.3. Video Codecs</a></p>
+
+<p><a href="#heading=h.be1ledetmole">5.2. Video Encoding</a></p>
+
+<p><a href="#heading=h.7971wdynbtij">5.3. Video Decoding</a></p>
+
+<p><a href="#heading=h.vtmgyrsev5dt">5.4. Audio Recording</a></p>
+
+<p>        <a href="#heading=h.ng7fac8ci8vj">5.4.1. Raw Audio Capture</a></p>
+
+<p><a href="#heading=h.sro7nvcaeuc1">5.4.2. Capture for Voice Recognition</a></p>
+
+<p><a href="#heading=h.n5ikz5dupfno">5.4.3. Capture for Rerouting of Playback</a></p>
+
+<p><a href="#heading=h.1xocvxnwynnm">5.5. Audio Playback</a></p>
+
+<p><a href="#heading=h.6zy7486s5cfa">5.5.1. Raw Audio Playback</a></p>
+
+<p><a href="#heading=h.ai1naitm7qfy">5.5.2. Audio Effects</a></p>
+
+<p><a href="#heading=h.fngymkz0321y">5.5.3. Audio Output Volume</a></p>
+
+<p><a href="#heading=h.qpj70us2l5pn">5.6. Audio Latency</a></p>
+
+<p><a href="#heading=h.1p55xhbym9l4">5.7. Network Protocols</a></p>
+
+<p><a href="#heading=h.mpxr2yu72m6t">5.8. Secure Media</a></p>
+
+<p><a href="#heading=h.9v14hzhfhm3p">6. Developer Tools and Options Compatibility</a></p>
+
+<p><a href="#heading=h.9cfw1b5q4g96">6.1. Developer Tools</a></p>
+
+<p><a href="#heading=h.yipuqt964xra">6.2. Developer Options</a></p>
+
+<p><a href="#heading=h.5h5uvpadidzr">7. Hardware Compatibility</a></p>
+
+<p><a href="#heading=h.22h5j37xan6e">7.1. Display and Graphics</a></p>
+
+<p><a href="#heading=h.6fey5v3qb5m3">7.1.1. Screen Configuration</a></p>
+
+<p><a href="#heading=h.mrv5xyps1ba8">7.1.1.1. Screen Size</a></p>
+
+<p><a href="#heading=h.h4amzk7515h2">7.1.1.2. Screen Aspect Ratio</a></p>
+
+<p><a href="#heading=h.2d6r63hcnjt0">7.1.1.3. Screen Density</a></p>
+
+<p><a href="#heading=h.p3dcj1v9ofv0">7.1.2. Display Metrics</a></p>
+</td>
+ </tr>
+</table>
+
+<table>
+ <tr>
+    <td>
+
+<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 5.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 5.0. A
+"device implementation" or "implementation" is the hardware/software solution
+so developed.</p>
+
+<p>To be considered compatible with Android 5.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="#heading=h.rafv96b0uwer">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 encouraged 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,
+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="#heading=h.jhgs5yq2lqtj">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="#heading=h.jhgs5yq2lqtj">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> MUST have a power source that provides mobility, such as a battery 
+</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> 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>]
+</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> MUST declare the feature android.hardware.type.watch
+  <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>]
+</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 5.0
+compatible, unless the requirement is explicitly described to be only
+applicable to a specific Android device type. </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>
+    <td class="tab0">
+<p><strong>Category</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>Feature </strong></p>
+</td>
+    <td class="tab0">
+<p><strong>Section</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>Handheld</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>Television</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>Watch</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>Other</strong></p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>Input</p>
+</td>
+    <td>
+<p>D-pad</p>
+</td>
+    <td>
+<p><a href="#heading=h.h86aqgcxrqbz">7.2.2. Non-touch Navigation</a></p>
+</td>
+    <td></td>
+    <td>
+<p>MUST</p>
+</td>
+    <td></td>
+    <td></td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>Touchscreen </p>
+</td>
+    <td>
+<p> <a href="#heading=h.p7pmjzzatkph">7.2.4. Touchscreen input</a></p>
+</td>
+    <td>
+<p>MUST</p>
+</td>
+    <td></td>
+    <td>
+<p>MUST</p>
+</td>
+    <td>
+<p>SHOULD</p>
+</td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>Microphone </p>
+</td>
+    <td>
+<p><a href="#heading=h.74o7ndqnyrjr">7.8.1. Microphone</a></p>
+</td>
+    <td>
+<p>MUST</p>
+</td>
+    <td>
+<p>SHOULD </p>
+</td>
+    <td>
+<p>MUST</p>
+</td>
+    <td>
+<p>SHOULD</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>Sensors</p>
+</td>
+    <td>
+<p>Accelerometer </p>
+</td>
+    <td>
+<p><a href="#heading=h.3u857dtnrtuj">7.3.1 Accelerometer</a></p>
+</td>
+    <td>
+<p>SHOULD</p>
+</td>
+    <td></td>
+    <td>
+<p>SHOULD</p>
+</td>
+    <td>
+<p>SHOULD</p>
+</td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>GPS </p>
+</td>
+    <td>
+<p><a href="#heading=h.2x1nre62p60d">7.3.3. GPS</a></p>
+</td>
+    <td>
+<p>SHOULD</p>
+</td>
+    <td></td>
+    <td></td>
+    <td></td>
+ </tr>
+ <tr>
+    <td>
+<p>Connectivity</p>
+</td>
+    <td>
+<p>Wi-Fi </p>
+</td>
+    <td>
+<p><a href="#heading=h.39g0jrqcl40">7.4.2. IEEE 802.11</a></p>
+</td>
+    <td>
+<p>SHOULD</p>
+</td>
+    <td>
+<p> MUST</p>
+</td>
+    <td></td>
+    <td>
+<p>SHOULD</p>
+</td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>Wi-Fi Direct </p>
+</td>
+    <td>
+<p><a href="#heading=h.82i6ovyqynfx">7.4.2.1. Wi-Fi Direct</a></p>
+</td>
+    <td>
+<p>SHOULD</p>
+</td>
+    <td>
+<p>SHOULD</p>
+</td>
+    <td></td>
+    <td>
+<p>SHOULD</p>
+</td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>Bluetooth </p>
+</td>
+    <td>
+<p><a href="#heading=h.420i0exy2mxj">7.4.3. Bluetooth</a></p>
+</td>
+    <td>
+<p>SHOULD</p>
+</td>
+    <td>
+<p>MUST</p>
+</td>
+    <td>
+<p>MUST</p>
+</td>
+    <td>
+<p>SHOULD</p>
+</td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>Bluetooth Low Energy </p>
+</td>
+    <td>
+<p><a href="#heading=h.420i0exy2mxj">7.4.3. Bluetooth</a></p>
+</td>
+    <td>
+<p>SHOULD</p>
+</td>
+    <td>
+<p>MUST</p>
+</td>
+    <td>
+<p>SHOULD</p>
+</td>
+    <td>
+<p>SHOULD</p>
+</td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>USB peripheral/ host mode </p>
+</td>
+    <td>
+<p><a href="#heading=h.rp4zc78xvn6s">7.7. USB</a></p>
+</td>
+    <td>
+<p>SHOULD</p>
+</td>
+    <td>
+<p> </p>
+</td>
+    <td></td>
+    <td>
+<p>SHOULD</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>Output</p>
+</td>
+    <td>
+<p>Speaker and/or Audio output ports </p>
+</td>
+    <td>
+<p><a href="#heading=h.ro0d402dzkaq">7.8.2. Audio Output</a></p>
+</td>
+    <td>
+<p>MUST</p>
+</td>
+    <td>
+<p>MUST</p>
+</td>
+    <td></td>
+    <td>
+<p>MUST</p>
+</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, 5</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="#heading=h.5h5uvpadidzr">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="#heading=h.kr68507hndy4">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, 6]</a>. Note that <a href="#heading=h.a32osmf1tmwt">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,
+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>
+    <td class="tab0">
+<p><strong>Parameter</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>Details</strong></p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>VERSION.RELEASE</p>
+</td>
+    <td>
+<p>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/5.0/versions.html">Resources, 8]</a>.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>VERSION.SDK</p>
+</td>
+    <td>
+<p>The version of the currently-executing Android system, in a format accessible
+to third-party application code. For Android 5.0, this field MUST have the
+integer value 21.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>VERSION.SDK_INT</p>
+</td>
+    <td>
+<p>The version of the currently-executing Android system, in a format accessible
+to third-party application code. For Android 5.0, this field MUST have the
+integer value 21.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>VERSION.INCREMENTAL</p>
+</td>
+    <td>
+<p>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 ("").</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>BOARD</p>
+</td>
+    <td>
+<p>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_-]+$".</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>BRAND</p>
+</td>
+    <td>
+<p>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_-]+$".</p>
+</td>
+ </tr>
+ <tr>
+    <td class="tab1">
+<p>SUPPORTED_ABIS</p>
+</td>
+    <td>
+<p>The name of the instruction set (CPU type + ABI convention) of native code. See <a href="#heading=h.3dpths90svxf">section 3.3. Native API Compatibility</a>.</p>
+</td>
+ </tr>
+ <tr>
+    <td class="tab1">
+<p>SUPPORTED_32_BIT_ABIS</p>
+</td>
+    <td>
+<p>The name of the instruction set (CPU type + ABI convention) of native code. See <a href="#heading=h.3dpths90svxf">section 3.3. Native API Compatibility</a>.</p>
+</td>
+ </tr>
+ <tr>
+    <td class="tab1">
+<p>SUPPORTED_64_BIT_ABIS</p>
+</td>
+    <td>
+<p>The name of the second instruction set (CPU type + ABI convention) of native
+code. See <a href="#heading=h.3dpths90svxf">section 3.3. Native API Compatibility</a>.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>CPU_ABI</p>
+</td>
+    <td>
+<p>The name of the instruction set (CPU type + ABI convention) of native code. See <a href="#heading=h.3dpths90svxf">section 3.3. Native API Compatibility</a>.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>CPU_ABI2</p>
+</td>
+    <td>
+<p>The name of the second instruction set (CPU type + ABI convention) of native
+code. See <a href="#heading=h.3dpths90svxf">section 3.3. Native API Compatibility</a>.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>DEVICE</p>
+</td>
+    <td>
+<p>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_-]+$".</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>FINGERPRINT</p>
+</td>
+    <td>
+<p>A string that uniquely identifies this build. It SHOULD be reasonably
+human-readable. It MUST follow this template:</p>
+
+<p>$(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)</p>
+
+<p>For example:</p>
+
+<p>acme/myproduct/mydevice:5.0/LRWXX/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>
+<p>HARDWARE</p>
+</td>
+    <td>
+<p>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_-]+$". </p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>HOST</p>
+</td>
+    <td>
+<p>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 ("").</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>ID</p>
+</td>
+    <td>
+<p>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._-]+$".</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>MANUFACTURER</p>
+</td>
+    <td>
+<p>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 ("").</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>MODEL</p>
+</td>
+    <td>
+<p>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 ("").</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>PRODUCT</p>
+</td>
+    <td>
+<p>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_-]+$".</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>SERIAL</p>
+</td>
+    <td>
+<p>A hardware serial number, which MUST be available. The value of this field MUST
+be encodable as 7-bit ASCII and match the regular expression
+"^([a-zA-Z0-9]{6,20})$".</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>TAGS</p>
+</td>
+    <td>
+<p>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. </p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>TIME</p>
+</td>
+    <td>
+<p>A value representing the timestamp of when the build occurred.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>TYPE</p>
+</td>
+    <td>
+<p>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.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>USER</p>
+</td>
+    <td>
+<p>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 ("").</p>
+</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> Browser 
+  <li> Calendar
+  <li> Contacts
+  <li> Gallery
+  <li> GlobalSearch
+  <li> Launcher
+  <li> Music
+  <li> Settings
+</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_overrides>3.2.3.2. Intent Overrides</h4>
+
+
+<p>As Android is an extensible platform, device implementations MUST allow each
+intent pattern referenced in <a href="#heading=h.qiy4ddbiirgy">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>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>
+
+<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="#heading=h.qiy4ddbiirgy">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="#heading=h.blmhfmxlmvir">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> 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="https://developer.android.com/reference/android/provider/Telephony.Sms.Intents.html">Resources, 9</a>] 
+  <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>
+</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> MUST be source-compatible (i.e. header compatible) and binary-compatible (for
+the ABI) with each required library in the list below
+  <li> MUST support the equivalent 32-bit ABI if any 64-bit ABI is supported
+  <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> 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> SHOULD be built using the source code and header files available in the
+upstream Android Open Source Project
+</ul>
+
+<p>The following native code APIs MUST be available to apps that include native
+code:</p>
+
+<ul>
+  <li> libc (C library)
+  <li> libm (math library)
+  <li> Minimal support for C++
+  <li> JNI interface
+  <li> liblog (Android logging)
+  <li> libz (Zlib compression)
+  <li> libdl (dynamic linker)
+  <li> libGLESv1_CM.so (OpenGL ES 1.x)
+  <li> libGLESv2.so (OpenGL ES 2.0)
+  <li> libGLESv3.so (OpenGL ES 3.x)
+  <li> libEGL.so (native OpenGL surface management)
+  <li> libjnigraphics.so
+  <li> libOpenSLES.so (OpenSL ES 1.0.1 audio support)
+  <li> libOpenMAXAL.so (OpenMAX AL 1.0.1 support)
+  <li> libandroid.so (native Android activity support)
+  <li> libmediandk.so (native media APIs support)
+  <li> Support for OpenGL, as described below
+</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, 11</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>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
+Android Open Source Project. </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>
+
+<table>
+ <tr>
+    <td class="tab2"></td>
+    <td>
+<p>The complete implementation of the android.webkit.Webview API MAY be provided
+on Android Watch devices but MUST be provided on all other types of device
+implementations.</p>
+</td>
+ </tr>
+</table>
+
+
+<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, 12</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 5.0. This build
+includes a specific set of functionality and security fixes for the WebView [<a href="http://www.chromium.org/">Resources, 13</a>].
+  <li> The user agent string reported by the WebView MUST be in this format: 
+</ul>
+
+<p>Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD))
+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> The value of the $(MODEL) string MUST be the same as the value for
+android.os.Build.MODEL.
+    <li> The value of the $(BUILD) string MUST be the same as the value for
+android.os.Build.ID.
+    <li> The value of the $(CHROMIUM_VER) string MUST be the version of Chromium in the
+upstream Android Open Source Project.
+    <li> Device implementations MAY omit Mobile in the user agent string.
+  </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="https://www.google.com/url?q=https%3A%2F%2Fhtml.spec.whatwg.org%2Fmultipage%2F&sa=D&sntz=1&usg=AFQjCNH7pPjEWho8n19H_n0ZXrQbI9RVlg">Resources, 14</a>].</p>
+
+<h3 id=3_4_2_browser_compatibility>3.4.2. Browser Compatibility</h3>
+
+<table>
+ <tr>
+    <td class="tab2"></td>
+    <td>
+<p>Android Television and Watch Devices MAY omit a browser application, but MUST
+support the public intent patterns as described in <a href="#heading=h.qiy4ddbiirgy">section 3.2.3.1</a>. All other types of device implementations MUST include a standalone Browser
+application for general user web browsing. </p>
+</td>
+ </tr>
+</table>
+
+
+<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="#heading=h.swqsalizdkk8">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="https://www.google.com/url?q=https%3A%2F%2Fhtml.spec.whatwg.org%2Fmultipage%2F&sa=D&sntz=1&usg=AFQjCNH7pPjEWho8n19H_n0ZXrQbI9RVlg">Resources, 14</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> the <video> tag [<a href="http://www.w3.org/html/wg/drafts/html/master/embedded-content.html#video">Resources, 16</a>]
+  <li> geolocation [<a href="http://www.w3.org/TR/geolocation-API/">Resources, 17</a>]
+</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
+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> Devices MUST NOT alter the lifecycle or lifecycle semantics of a particular
+type of system component (such as Service, Activity, ContentProvider, etc.).
+  <li> Devices MUST NOT change the semantics of a standard permission.
+</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> javax.*
+  <li> sun.*
+  <li> android.*
+  <li> com.android.*
+</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> 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> 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.
+</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
+<uses-library> 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="https://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/+/lollipop-release/docs/">Resources, 20</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="#heading=h.6fey5v3qb5m3">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>
+    <td class="tab0">
+<p><strong>Screen Layout</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>Screen Density</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>Minimum Application Memory</strong></p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>small / normal</p>
+</td>
+    <td>
+<p>120 dpi (ldpi) </p>
+</td>
+    <td>
+<p>16MB</p>
+</td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>160 dpi (mdpi)</p>
+</td>
+    <td></td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>213 dpi (tvdpi)</p>
+</td>
+    <td>
+<p>32MB</p>
+</td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>240 dpi (hdpi)</p>
+</td>
+    <td></td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>320 dpi (xhdpi)</p>
+</td>
+    <td>
+<p>64MB</p>
+</td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>400 dpi (400dpi)</p>
+</td>
+    <td>
+<p>96MB</p>
+</td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>480 dpi (xxhdpi)</p>
+</td>
+    <td>
+<p>128MB</p>
+</td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>560 dpi (560dpi)</p>
+</td>
+    <td>
+<p>192MB</p>
+</td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>640 dpi (xxxhdpi)</p>
+</td>
+    <td>
+<p>256MB</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>large</p>
+</td>
+    <td>
+<p>120 dpi (ldpi) </p>
+</td>
+    <td>
+<p>16MB</p>
+</td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>160 dpi (mdpi)</p>
+</td>
+    <td>
+<p>32MB</p>
+</td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>213 dpi (tvdpi)</p>
+</td>
+    <td>
+<p>64MB</p>
+</td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>240 dpi (hdpi)</p>
+</td>
+    <td></td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>320 dpi (xhdpi)</p>
+</td>
+    <td>
+<p>128MB</p>
+</td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>400 dpi (400dpi)</p>
+</td>
+    <td>
+<p>192MB</p>
+</td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>480 dpi (xxhdpi)</p>
+</td>
+    <td>
+<p>256MB</p>
+</td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>560 dpi (560dpi)</p>
+</td>
+    <td>
+<p>384MB</p>
+</td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>640 dpi (xxxhdpi)</p>
+</td>
+    <td>
+<p>512MB</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>xlarge</p>
+</td>
+    <td>
+<p>160 dpi (mdpi)</p>
+</td>
+    <td>
+<p>64MB</p>
+</td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>213 dpi (tvdpi)</p>
+</td>
+    <td>
+<p>96MB</p>
+</td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>240 dpi (hdpi)</p>
+</td>
+    <td></td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>320 dpi (xhdpi)</p>
+</td>
+    <td>
+<p>192MB</p>
+</td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>400 dpi (400dpi)</p>
+</td>
+    <td>
+<p>288MB</p>
+</td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>480 dpi (xxhdpi)</p>
+</td>
+    <td>
+<p>384MB</p>
+</td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>560 dpi (560dpi)</p>
+</td>
+    <td>
+<p>576MB</p>
+</td>
+ </tr>
+ <tr>
+    <td></td>
+    <td>
+<p>640 dpi (xxxhdpi)</p>
+</td>
+    <td>
+<p>768MB</p>
+</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>
+
+<table>
+ <tr>
+    <td class="tab2"></td>
+    <td>
+<p>Widgets are optional for all Android device implementations, but SHOULD be
+supported on Android Handheld devices.</p>
+</td>
+ </tr>
+</table>
+
+
+<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
+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> 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> Device implementations that include support for lock screen MAY support
+application widgets on the lock screen.
+</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, 22</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="#heading=h.5h5uvpadidzr">section 7</a>.</p>
+
+<p>Additionally, the implementation MUST correctly render all resources (icons,
+sound files, etc.) provided for in the APIs [<a href="https://developer.android.com/guide/topics/resources/available-resources.html">Resources, 23</a>], or in the Status/System Bar icon style guide [<a href="http://developer.android.com/design/style/iconography.html">Resources, 24</a>]. 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> <strong>Heads-up notifications</strong>—Interactive Views users can act on or dismiss without leaving the current app.
+  <li> <strong>Lockscreen notifications</strong>—Notifications shown over a lock screen with granular control on visibility.
+</ul>
+
+<p>Device implementations MUST properly display and execute these notifications,
+including the title/name, icon, text as documented in the Android APIs <a href="https://developer.android.com/design/patterns/notifications.html">[Resources, 25]</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, 26</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>
+
+<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
+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, 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>
+
+<p>Android 5.0 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>
+
+<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>
+
+<p>Android supports a new 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>
+
+<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
+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>
+
+<table>
+ <tr>
+    <td class="tab2"></td>
+    <td>
+<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>
+</td>
+ </tr>
+</table>
+
+
+<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
+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="#heading=h.dzfhwcjzm5z6">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> MUST support at least up to 20 displayed activities
+  <li> MUST at least display the title of 4 activities at a time
+  <li> SHOULD display highlight color, icon, screen title in recents
+  <li> MUST implement the screen pinning behavior [<a href="https://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> SHOULD display a closing affordance ("x") but MAY delay this until user
+interacts with screens 
+</ul>
+
+<p>Device implementations are STRONGLY ENCOURAGED 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
+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="https://developer.android.com/reference/android/app/Notification.MediaStyle.html">Resources, 35</a>]. Device implementations that support a lock screen in the device MUST support
+the Media Notification Template along with other notifications.</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, 36</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, 37</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 MUST 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>
+
+<p>Android 5.0 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, 39</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>]. Device implementations that include support for lock screen 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>] 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>
+
+<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, 42</a>]. Device implementations MUST provide an implementation of the Android
+accessibility framework consistent with the default Android implementation.
+Device implementations MUST meet the following requirements:</p>
+
+<ul>
+  <li> 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> MUST generate AccessibilityEvents and deliver these events to all registered
+AccessibilityService implementations in a manner consistent with the default
+Android implementation
+  <li> Unless an Android Watch device with no audio output, device implementations
+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.
+</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="https://code.google.com/p/eyes-free/">Resources, 44</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
+MUST meet these requirements related to the Android TTS framework. </p>
+
+<p>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 Television Input Framework [<a href="https://source.android.com/devices/tv/index.html">Resources, 46</a>].</p>
+
+<p>Device implementations that support TIF MUST declare the platform feature
+android.software.live_tv. </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/guide/developing/tools/index.html">Resources, 47</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
+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, 50</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. 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>
+    <td class="tab0">
+<p><strong>Format / Codec</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>Encoder</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>Decoder</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>Details</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>Supported File Type(s) / Container Formats</strong></p>
+</td>
+ </tr>
+ <tr>
+    <td class="tab3">
+<p>MPEG-4 AAC Profile</p>
+
+<p>(AAC LC)</p>
+</td>
+    <td class="tab3">
+<p>REQUIRED1</p>
+</td>
+    <td class="tab3">
+<p>REQUIRED</p>
+</td>
+    <td class="tab3">
+<p>Support for mono/stereo/5.0/5.12 content with standard sampling rates from 8 to
+48 kHz.</p>
+</td>
+    <td class="tab4">
+<p>• 3GPP (.3gp)</p>
+
+<p>• MPEG-4 (.mp4, .m4a)</p>
+
+<p>• ADTS raw AAC (.aac, decode in Android 3.1+, encode in Android 4.0+, ADIF not
+supported)</p>
+
+<p>• MPEG-TS (.ts, not seekable, Android 3.0+)</p>
+</td>
+ </tr>
+ <tr>
+    <td class="tab3">
+<p>MPEG-4 HE AAC Profile (AAC+)</p>
+</td>
+    <td>
+<p>REQUIRED1</p>
+
+<p>(Android 4.1+)</p>
+</td>
+    <td class="tab3">
+<p>REQUIRED</p>
+</td>
+    <td class="tab3">
+<p>Support for mono/stereo/5.0/5.12 content with standard sampling rates from 16
+to 48 kHz.</p>
+</td>
+    <td class="tab4"></td>
+ </tr>
+ <tr>
+    <td class="tab3">
+<p>MPEG-4 HE AACv2</p>
+
+<p>Profile (enhanced AAC+)</p>
+</td>
+    <td class="tab3">
+<p> </p>
+</td>
+    <td class="tab3">
+<p>REQUIRED</p>
+</td>
+    <td class="tab3">
+<p>Support for mono/stereo/5.0/5.12 content with standard sampling rates from 16
+to 48 kHz.</p>
+</td>
+    <td class="tab4"></td>
+ </tr>
+ <tr>
+    <td class="tab3">
+<p>AAC ELD (enhanced low delay AAC)</p>
+</td>
+    <td>
+<p>REQUIRED1 </p>
+
+<p>(Android 4.1+)</p>
+</td>
+    <td>
+<p>REQUIRED</p>
+
+<p>(Android 4.1+)</p>
+</td>
+    <td class="tab3">
+<p>Support for mono/stereo content with standard sampling rates from 16 to 48 kHz.</p>
+</td>
+    <td class="tab4"></td>
+ </tr>
+ <tr>
+    <td class="tab3">
+<p>AMR-NB</p>
+</td>
+    <td class="tab3">
+<p>REQUIRED3</p>
+</td>
+    <td class="tab3">
+<p>REQUIRED3</p>
+</td>
+    <td class="tab3">
+<p>4.75 to 12.2 kbps sampled @ 8kHz</p>
+</td>
+    <td class="tab4">
+<p>3GPP (.3gp)</p>
+</td>
+ </tr>
+ <tr>
+    <td class="tab3">
+<p>AMR-WB</p>
+</td>
+    <td class="tab3">
+<p>REQUIRED3 </p>
+</td>
+    <td class="tab3">
+<p>REQUIRED3</p>
+</td>
+    <td class="tab3">
+<p>9 rates from 6.60 kbit/s to 23.85 kbit/s sampled @ 16kHz</p>
+</td>
+    <td class="tab4"></td>
+ </tr>
+ <tr>
+    <td class="tab3">
+<p>FLAC</p>
+</td>
+    <td class="tab3">
+<p> </p>
+</td>
+    <td>
+<p>REQUIRED</p>
+
+<p>(Android 3.1+)</p>
+</td>
+    <td class="tab3">
+<p>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.</p>
+</td>
+    <td class="tab3">
+<p>FLAC (.flac) only</p>
+</td>
+ </tr>
+ <tr>
+    <td class="tab3">
+<p>MP3</p>
+</td>
+    <td class="tab3">
+<p> </p>
+</td>
+    <td class="tab3">
+<p>REQUIRED</p>
+</td>
+    <td>
+<p>Mono/Stereo 8-320Kbps constant (CBR) or variable bitrate (VBR)</p>
+</td>
+    <td class="tab3">
+<p>MP3 (.mp3)</p>
+</td>
+ </tr>
+ <tr>
+    <td class="tab3">
+<p>MIDI</p>
+</td>
+    <td class="tab3">
+<p> </p>
+</td>
+    <td class="tab3">
+<p>REQUIRED</p>
+</td>
+    <td class="tab3">
+<p>MIDI Type 0 and 1. DLS Version 1 and 2. XMF and Mobile XMF. Support for
+ringtone formats RTTTL/RTX, OTA, and iMelody</p>
+</td>
+    <td class="tab3">
+<p>• Type 0 and 1 (.mid, .xmf, .mxmf)</p>
+
+<p>• RTTTL/RTX (.rtttl, .rtx)</p>
+
+<p>• OTA (.ota)</p>
+
+<p>• iMelody (.imy)</p>
+</td>
+ </tr>
+ <tr>
+    <td class="tab3">
+<p>Vorbis</p>
+</td>
+    <td class="tab3">
+<p> </p>
+</td>
+    <td class="tab3">
+<p>REQUIRED</p>
+</td>
+    <td class="tab3">
+<p> </p>
+</td>
+    <td class="tab3">
+<p>• Ogg (.ogg)</p>
+
+<p>• Matroska (.mkv, Android 4.0+)</p>
+</td>
+ </tr>
+ <tr>
+    <td class="tab3">
+<p>PCM/WAVE</p>
+</td>
+    <td>
+<p>REQUIRED4</p>
+
+<p>(Android 4.1+)</p>
+</td>
+    <td class="tab3">
+<p>REQUIRED</p>
+</td>
+    <td class="tab3">
+<p>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.</p>
+</td>
+    <td class="tab3">
+<p>WAVE (.wav)</p>
+</td>
+ </tr>
+ <tr>
+    <td class="tab3">
+<p>Opus</p>
+</td>
+    <td class="tab3"></td>
+    <td class="tab3">
+<p>REQUIRED</p>
+
+<p>(Android 5.0+)</p>
+</td>
+    <td class="tab3"></td>
+    <td class="tab3">
+<p>Matroska (.mkv)</p>
+</td>
+ </tr>
+</table>
+
+
+<p>1 Required for device implementations that define android.hardware.microphone
+but optional for Android Watch device implementations.</p>
+
+<p>2 Only downmix of 5.0/5.1 content is required; recording or rendering more than
+2 channels is optional.</p>
+
+<p>3 Required for Android Handheld device implementations. </p>
+
+<p>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>
+    <td class="tab0">
+<p><strong>Format / Codec</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>Encoder</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>Decoder</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>Details</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>Supported File Type(s) / Container Formats</strong></p>
+</td>
+ </tr>
+ <tr>
+    <td class="tab3">
+<p>JPEG</p>
+</td>
+    <td class="tab3">
+<p>REQUIRED</p>
+</td>
+    <td class="tab3">
+<p>REQUIRED</p>
+</td>
+    <td class="tab3">
+<p>Base+progressive</p>
+</td>
+    <td class="tab3">
+<p>JPEG (.jpg)</p>
+</td>
+ </tr>
+ <tr>
+    <td class="tab3">
+<p>GIF</p>
+</td>
+    <td class="tab3">
+<p> </p>
+</td>
+    <td class="tab3">
+<p>REQUIRED</p>
+</td>
+    <td class="tab3">
+<p> </p>
+</td>
+    <td class="tab3">
+<p>GIF (.gif)</p>
+</td>
+ </tr>
+ <tr>
+    <td class="tab3">
+<p>PNG</p>
+</td>
+    <td class="tab3">
+<p>REQUIRED</p>
+</td>
+    <td class="tab3">
+<p>REQUIRED</p>
+</td>
+    <td class="tab3">
+<p> </p>
+</td>
+    <td class="tab3">
+<p>PNG (.png)</p>
+</td>
+ </tr>
+ <tr>
+    <td class="tab3">
+<p>BMP</p>
+</td>
+    <td class="tab3">
+<p> </p>
+</td>
+    <td class="tab3">
+<p>REQUIRED</p>
+</td>
+    <td class="tab3">
+<p> </p>
+</td>
+    <td class="tab3">
+<p>BMP (.bmp)</p>
+</td>
+ </tr>
+ <tr>
+    <td class="tab3">
+<p>WebP</p>
+</td>
+    <td class="tab3">
+<p>REQUIRED</p>
+</td>
+    <td class="tab3">
+<p>REQUIRED</p>
+</td>
+    <td class="tab3">
+<p> </p>
+</td>
+    <td class="tab3">
+<p>WebP (.webp)</p>
+</td>
+ </tr>
+</table>
+
+
+<h3 id=5_1_3_video_codecs>5.1.3. Video Codecs</h3>
+
+<table>
+ <tr>
+    <td class="tab2"></td>
+    <td>
+<p>Video codecs are optional for Android Watch device implementations.</p>
+</td>
+ </tr>
+</table>
+
+<table>
+ <tr>
+    <td class="tab0">
+<p><strong>Format / Codec</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>Encoder</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>Decoder</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>Details</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>Supported File Type(s) / Container Formats</strong></p>
+</td>
+ </tr>
+ <tr>
+    <td class="tab3">
+<p>H.263</p>
+</td>
+    <td class="tab3">
+<p>REQUIRED1</p>
+</td>
+    <td class="tab3">
+<p>REQUIRED2</p>
+</td>
+    <td class="tab3">
+<p> </p>
+</td>
+    <td class="tab3">
+<p>• 3GPP (.3gp)</p>
+
+<p>• MPEG-4 (.mp4)</p>
+</td>
+ </tr>
+ <tr>
+    <td class="tab3">
+<p>H.264 AVC</p>
+</td>
+    <td class="tab3">
+<p>REQUIRED2</p>
+</td>
+    <td class="tab3">
+<p>REQUIRED2</p>
+</td>
+    <td>
+<p>See <a href="#heading=h.be1ledetmole">section 5.2 </a>and <a href="#heading=h.ogx7l5t9zub6">5.3</a> for details</p>
+</td>
+    <td class="tab3">
+<p>• 3GPP (.3gp)</p>
+
+<p>• MPEG-4 (.mp4)</p>
+
+<p>• MPEG-TS (.ts, AAC audio only, not seekable, Android 3.0+)</p>
+</td>
+ </tr>
+ <tr>
+    <td class="tab3">
+<p>H.265 HEVC</p>
+</td>
+    <td class="tab3"></td>
+    <td class="tab3">
+<p>REQUIRED2</p>
+</td>
+    <td>
+<p>See <a href="#heading=h.be1ledetmole">section 5.3</a> for details</p>
+</td>
+    <td class="tab3">
+<p>MPEG-4 (.mp4)</p>
+</td>
+ </tr>
+ <tr>
+    <td class="tab3">
+<p>MPEG-4 SP</p>
+</td>
+    <td class="tab3">
+<p> </p>
+</td>
+    <td class="tab3">
+<p>REQUIRED2</p>
+</td>
+    <td class="tab3">
+<p> </p>
+</td>
+    <td class="tab3">
+<p>3GPP (.3gp)</p>
+</td>
+ </tr>
+ <tr>
+    <td class="tab3">
+<p>VP83</p>
+</td>
+    <td>
+<p>REQUIRED2</p>
+
+<p>(Android 4.3+)</p>
+</td>
+    <td>
+<p>REQUIRED2</p>
+
+<p>(Android 2.3.3+)</p>
+</td>
+    <td>
+<p>See <a href="#heading=h.be1ledetmole">section 5.2</a> and <a href="#heading=h.ogx7l5t9zub6">5.3</a> for details</p>
+</td>
+    <td>
+<p>• WebM (.webm) [<a href="http://www.webmproject.org/">Resources, 110</a>]</p>
+
+<p>• Matroska (.mkv, Android 4.0+)4</p>
+</td>
+ </tr>
+ <tr>
+    <td class="tab3">
+<p>VP9</p>
+</td>
+    <td class="tab3"></td>
+    <td class="tab3">
+<p>REQUIRED2</p>
+
+<p>(Android 4.4+)</p>
+</td>
+    <td>
+<p>See <a href="#heading=h.be1ledetmole">section 5.</a><u>3</u> for details</p>
+</td>
+    <td>
+<p>• WebM (.webm) [<a href="http://www.webmproject.org/">Resources, 110</a>]</p>
+
+<p>• Matroska (.mkv, Android 4.0+)4</p>
+</td>
+ </tr>
+</table>
+
+
+<p>1 Required for device implementations that include camera hardware and define
+android.hardware.camera or android.hardware.camera.front.</p>
+
+<p>2 Required for device implementations except Android Watch devices. </p>
+
+<p>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>
+
+<p>4 Device implementations SHOULD support writing Matroska WebM files.</p>
+
+<h2 id=5_2_video_encoding>5.2. Video Encoding</h2>
+
+<table>
+ <tr>
+    <td class="tab2"></td>
+    <td>
+<p>Video codecs are optional for Android Watch device implementations.</p>
+</td>
+ </tr>
+</table>
+
+
+<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>
+    <td class="tab0"></td>
+    <td class="tab0">
+<p><strong>SD (Low quality)</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>SD (High quality)</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>HD 720p1</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>HD 1080p1</strong></p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><strong>  Video resolution</strong></p>
+</td>
+    <td class="tab3">
+<p>320 x 240 px</p>
+</td>
+    <td class="tab3">
+<p>720 x 480 px</p>
+</td>
+    <td class="tab3">
+<p>1280 x 720 px</p>
+</td>
+    <td>
+<p>1920 x 1080 px</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><strong>  Video frame rate</strong></p>
+</td>
+    <td class="tab3">
+<p>20 fps</p>
+</td>
+    <td class="tab3">
+<p>30 fps</p>
+</td>
+    <td class="tab3">
+<p>30 fps</p>
+</td>
+    <td>
+<p>30 fps</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><strong>  Video bitrate</strong></p>
+</td>
+    <td class="tab3">
+<p>384 Kbps</p>
+</td>
+    <td class="tab3">
+<p>2 Mbps</p>
+</td>
+    <td class="tab3">
+<p>4 Mbps</p>
+</td>
+    <td>
+<p>10 Mbps</p>
+</td>
+ </tr>
+</table>
+
+
+<p>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>
+    <td class="tab0"></td>
+    <td class="tab0">
+<p><strong>SD (Low quality)</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>SD (High quality)</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>HD 720p1</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>HD 1080p1</strong></p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><strong>Video resolution</strong></p>
+</td>
+    <td>
+<p>320 x 180 px</p>
+</td>
+    <td>
+<p>640 x 360 px</p>
+</td>
+    <td>
+<p>1280 x 720 px</p>
+</td>
+    <td>
+<p>1920 x 1080 px</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><strong>Video frame rate</strong></p>
+</td>
+    <td>
+<p>30 fps</p>
+</td>
+    <td>
+<p>30 fps</p>
+</td>
+    <td>
+<p>30 fps</p>
+</td>
+    <td>
+<p>30 fps</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><strong>Video bitrate</strong></p>
+</td>
+    <td>
+<p>800 Kbps </p>
+</td>
+    <td>
+<p>2 Mbps</p>
+</td>
+    <td>
+<p>4 Mbps</p>
+</td>
+    <td>
+<p>10 Mbps</p>
+</td>
+ </tr>
+</table>
+
+
+<p>1 When supported by hardware.</p>
+
+<h2 id=5_3_video_decoding>5.3. Video Decoding</h2>
+
+<table>
+ <tr>
+    <td class="tab2"></td>
+    <td>
+<p>Video codecs are optional for Android Watch device implementations.</p>
+</td>
+ </tr>
+</table>
+
+
+<p>Device implementations MUST support dynamic video resolution switching within
+the same stream for VP8, VP9 ,H.264, and H.265 codecs.</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
+Level 4.2 and the HD 1080p decoding profile.</p>
+<table>
+ <tr>
+    <td class="tab0"></td>
+    <td class="tab0">
+<p><strong>SD (Low quality)</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>SD (High quality)</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>HD 720p1</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>HD 1080p1</strong></p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><strong>Video resolution</strong></p>
+</td>
+    <td>
+<p>320 x 240 px</p>
+</td>
+    <td>
+<p>720 x 480 px</p>
+</td>
+    <td>
+<p>1280 x 720 px</p>
+</td>
+    <td>
+<p>1920 x 1080 px</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><strong>Video frame rate</strong></p>
+</td>
+    <td>
+<p>30 fps</p>
+</td>
+    <td>
+<p>30 fps</p>
+</td>
+    <td>
+<p>30 fps / 60 fps2</p>
+</td>
+    <td>
+<p>30 fps / 60 fps2</p>
+</td>
+ </tr>
+ <tr>
+    <td></td>
+    <td></td>
+    <td></td>
+    <td></td>
+    <td></td>
+ </tr>
+ <tr>
+    <td>
+<p><strong>Video bitrate</strong></p>
+</td>
+    <td>
+<p>800 Kbps </p>
+</td>
+    <td>
+<p>2 Mbps</p>
+</td>
+    <td>
+<p>8 Mbps</p>
+</td>
+    <td>
+<p>20 Mbps</p>
+</td>
+ </tr>
+</table>
+
+
+<p>1 Required for Android Television device implementations, but for other device
+types only when supported by hardware.</p>
+
+<p>2 Required for Android Television device implementations.</p>
+
+<p>Android device implementations when supporting VP8 codec as described in <a href="#heading=h.hitn8abpwkj2">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>
+    <td class="tab0"></td>
+    <td class="tab0">
+<p><strong>SD (Low quality)</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>SD (High quality)</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>HD 720p1</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>HD 1080p1</strong></p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><strong>Video resolution</strong></p>
+</td>
+    <td>
+<p>320 x 180 px</p>
+</td>
+    <td>
+<p>640 x 360 px</p>
+</td>
+    <td>
+<p>1280 x 720 px</p>
+</td>
+    <td>
+<p>1920 x 1080 px</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><strong>Video frame rate</strong></p>
+</td>
+    <td>
+<p>30 fps</p>
+</td>
+    <td>
+<p>30 fps</p>
+</td>
+    <td>
+<p>30 fps / 60 fps2</p>
+</td>
+    <td>
+<p>30 / 60 fps2</p>
+</td>
+ </tr>
+ <tr>
+    <td></td>
+    <td></td>
+    <td></td>
+    <td></td>
+    <td></td>
+ </tr>
+ <tr>
+    <td>
+<p><strong>Video bitrate</strong></p>
+</td>
+    <td>
+<p>800 Kbps </p>
+</td>
+    <td>
+<p>2 Mbps</p>
+</td>
+    <td>
+<p>8 Mbps</p>
+</td>
+    <td>
+<p>20 Mbps</p>
+</td>
+ </tr>
+</table>
+
+
+<p>1 Required for Android Television device implementations, but for other type of
+devices only when supported by hardware.</p>
+
+<p>2 Required for Android Television device implementations.</p>
+
+<p>Android device implementations, when supporting VP9 codec as described in <a href="#heading=h.hitn8abpwkj2">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>
+<table>
+ <tr>
+    <td class="tab0"></td>
+    <td class="tab0">
+<p><strong>SD (Low quality)</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>SD (High quality)</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>HD 720p 1</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>HD 1080p 2</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>UHD 2</strong></p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><strong>Video resolution</strong></p>
+</td>
+    <td>
+<p>320 x 180 px</p>
+</td>
+    <td>
+<p>640 x 360 px</p>
+</td>
+    <td>
+<p>1280 x 720 px</p>
+</td>
+    <td>
+<p>1920 x 1080 px</p>
+</td>
+    <td>
+<p>3840 x 2160 px</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><strong>Video frame rate</strong></p>
+</td>
+    <td>
+<p>30 fps</p>
+</td>
+    <td>
+<p>30 fps</p>
+</td>
+    <td>
+<p>30 fps</p>
+</td>
+    <td>
+<p>30 fps</p>
+</td>
+    <td>
+<p>30 fps</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><strong>Video bitrate</strong></p>
+</td>
+    <td>
+<p>600 Kbps </p>
+</td>
+    <td>
+<p>1.6 Mbps</p>
+</td>
+    <td>
+<p>4 Mbps</p>
+</td>
+    <td>
+<p>10 Mbps</p>
+</td>
+    <td>
+<p>20 Mbps</p>
+</td>
+ </tr>
+</table>
+
+
+<p>1 Required for Android Television device implementations, but for other type of
+devices only when supported by hardware.</p>
+
+<p>2 STRONGLY RECOMMENDED for Android Television device implementations when
+supported by hardware.</p>
+
+<p>Android device implementations, when supporting H.265 codec as described in <a href="#heading=h.hitn8abpwkj2">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>
+    <td class="tab0"></td>
+    <td class="tab0">
+<p><strong>SD (Low quality)</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>SD (High quality)</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>HD 720p </strong>1 </p>
+</td>
+    <td class="tab0">
+<p><strong>HD 1080p </strong>1 </p>
+</td>
+    <td class="tab0">
+<p><strong>UHD </strong>2</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><strong>Video resolution</strong></p>
+</td>
+    <td>
+<p>352 x 288 px</p>
+</td>
+    <td>
+<p>640 x 360 px</p>
+</td>
+    <td>
+<p>1280 x 720 px</p>
+</td>
+    <td>
+<p>1920 x 1080 px</p>
+</td>
+    <td>
+<p>3840 x 2160 px</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><strong>Video frame rate</strong></p>
+</td>
+    <td>
+<p>30 fps</p>
+</td>
+    <td>
+<p>30 fps</p>
+</td>
+    <td>
+<p>30 fps</p>
+</td>
+    <td>
+<p>30 fps</p>
+</td>
+    <td>
+<p>30 fps</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><strong>Video bitrate</strong></p>
+</td>
+    <td>
+<p>600 Kbps </p>
+</td>
+    <td>
+<p>1.6 Mbps</p>
+</td>
+    <td>
+<p>4 Mbps</p>
+</td>
+    <td>
+<p>10 Mbps</p>
+</td>
+    <td>
+<p>20 Mbps</p>
+</td>
+ </tr>
+</table>
+
+
+<p>1 Required for Android Television device implementation, but for other type of
+devices only when supported by hardware.</p>
+
+<p>2 Required for 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>
+
+<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>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>
+
+<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 1Khz 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> <strong>Sampling rates</strong>: 8000, 11025, 16000, 22050, 32000, 44100
+  <li> <strong>Channels</strong>: Mono, Stereo
+</ul>
+
+<p>The device SHOULD allow playback of raw audio content with the following
+characteristics:</p>
+
+<ul>
+  <li> <strong>Sampling rates</strong>: 24000, 48000
+</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, 52</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> MUST support the visualizer API implementation, controllable through the
+Visualizer class
+  <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
+</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> <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> <strong>continuous output latency</strong>—The output latency for subsequent frames, after the device is playing audio.
+  <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> <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> <strong>continuous input latency</strong>—The input latency for subsequent frames, while the device is capturing audio.
+  <li> <strong>cold output jitter</strong>—The variance among separate measurements of cold output latency values.
+  <li> <strong>cold input jitter</strong>—The variance among separate measurements of cold input latency values. 
+  <li> <strong>continuous round-trip latency</strong>—The sum of continuous input latency plus continuous output latency plus 5
+milliseconds.
+  <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.
+</ul>
+
+<p>Device implementations that declare android.hardware.audio.output SHOULD meet
+or exceed these audio output requirements:</p>
+
+<ul>
+  <li> cold output latency of 100 milliseconds or less
+  <li> continuous output latency of 45 milliseconds or less
+  <li> minimize the cold output jitter
+</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 MAY 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
+MUST NOT report support for low-latency audio.</p>
+
+<p>Device implementations that include android.hardware.microphone SHOULD meet
+these input audio requirements:</p>
+
+<ul>
+  <li> cold input latency of 100 milliseconds or less
+  <li> continuous input latency of 30 milliseconds or less
+  <li> continuous round-trip latency of 50 milliseconds or less
+  <li> minimize the cold input jitter
+</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, 50</a>]. Specifically, devices MUST support the following media network protocols:</p>
+
+<ul>
+  <li> RTSP (RTP, SDP)
+  <li> HTTP(S) progressive streaming
+  <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>]
+</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>
+
+<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, 55</a>]
+</ul>
+
+<p>Device implementations MUST support all adb functions as documented in the
+Android SDK including dumpsys [<a href="https://source.android.com/devices/tech/input/dumpsys.html">Resources, 56</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, 57</a>]
+</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, 58</a>]
+</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>]
+</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 9 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, 60</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's 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, 53]</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
+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> <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> <strong>aspect ratio</strong>—The ratio of the longer dimension of the screen to the shorter dimension. For
+example, a display of 480x854 pixels would be 854 / 480 = 1.779, or roughly
+"16:9".
+  <li> <strong>density-independent pixel (dp)</strong>—The virtual pixel unit normalized to a 160 dpi screen, calculated as: pixels =
+dps * (density / 160).
+</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>
+
+<table>
+ <tr>
+    <td class="tab2"></td>
+    <td>
+<p>Android Watch devices (detailed in <a href="#heading=h.40sdoojaw5k9">section 2</a>) MAY have smaller screen sizes as described in this section.</p>
+</td>
+ </tr>
+</table>
+
+
+<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, 61</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> Devices that report screen size 'normal' MUST have screen sizes of at least 480
+dp x 320 dp.
+  <li> Devices that report screen size 'large' MUST have screen sizes of at least 640
+dp x 480 dp.
+  <li> Devices that report screen size 'xlarge' MUST have screen sizes of at least 960
+dp x 720 dp.
+</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> Other types of Android device implementations, with a physically integrated
+screen, MUST have a screen at least 2.5 inches in physical diagonal size.
+</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>
+
+<table>
+ <tr>
+    <td class="tab2"></td>
+    <td>
+<p>Android Watch devices MAY have an aspect ratio of 1.0 (1:1).</p>
+</td>
+ </tr>
+</table>
+
+
+<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> 160 dpi (mdpi)
+  <li> 213 dpi (tvdpi)
+  <li> 240 dpi (hdpi)
+  <li> 320 dpi (xhdpi)
+  <li> 400 dpi (400dpi)
+  <li> 480 dpi (xxhdpi)
+  <li> 560 dpi (560dpi)
+  <li> 640 dpi (xxxhdpi)
+</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, 62</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, 63</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> 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> 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.
+</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
+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, 65</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, 65</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, 66</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. 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.</p>
+
+<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> Devices MUST support displays capable of rendering animations.
+  <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.
+</ul>
+
+<h3 id=7_1_7_external_displays>7.1.7. External 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, 67</a>].</p>
+
+<h2 id=7_2_input_devices>7.2. Input Devices</h2>
+
+
+<h3 id=7_2_1_keyboard>7.2.1. Keyboard</h3>
+
+<table>
+ <tr>
+    <td class="tab2"></td>
+    <td>
+<p>Android Watch devices MAY but other type of device implementations MUST
+implement a soft keyboard.</p>
+</td>
+ </tr>
+</table>
+
+
+<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> 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> MAY include additional soft keyboard implementations
+  <li> MAY include a hardware keyboard
+  <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)
+</ul>
+
+<h3 id=7_2_2_non-touch_navigation>7.2.2. Non-touch Navigation</h3>
+
+<table>
+ <tr>
+    <td class="tab2"></td>
+    <td>
+<p>Android Television devices MUST support D-pad.</p>
+</td>
+ </tr>
+</table>
+
+
+<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> 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> 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.
+</ul>
+
+<h3 id=7_2_3_navigation_keys>7.2.3. Navigation Keys</h3>
+
+<table>
+ <tr>
+    <td class="tab2"></td>
+    <td>
+<p>The availability and visibility requirement of the Home, Recents, and Back
+functions differ between device types as described in this section.</p>
+</td>
+ </tr>
+</table>
+
+
+<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> Android Television device implementations MUST provide the Home and Back
+functions.
+  <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> All other types of device implementations MUST provide the Home and Back
+functions.
+</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 5.0 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 5.0, this
+is RECOMMENDED.
+  <li> MUST NOT modify the position of the action overflow popup displayed by
+selecting the overflow button in the action bar
+  <li> MAY render the action overflow popup at a modified position on the screen when
+it is displayed by selecting the physical menu button
+</ul>
+
+<p>For backwards compatibility, device implementations MUST make the Menu function
+available to applications when targetSdkVersion <= 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 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>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> Device implementations MUST make available a portion of the display to
+applications that meets the requirements defined in <a href="#heading=h.mrv5xyps1ba8">section 7.1.1</a>.
+  <li> Device implementations MUST display the navigation keys when applications do
+not specify a system UI mode, or specify SYSTEM_UI_FLAG_VISIBLE.
+  <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> Device implementations MUST hide the navigation keys when applications specify
+SYSTEM_UI_FLAG_HIDE_NAVIGATION.
+</ul>
+
+<h3 id=7_2_4_touchscreen_input>7.2.4. Touchscreen Input</h3>
+
+<table>
+ <tr>
+    <td class="tab2"></td>
+    <td>
+<p>Android Handhelds and Watch Devices MUST support touchscreen input.</p>
+</td>
+ </tr>
+</table>
+
+
+<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> 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
+</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
+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 5.0 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="#heading=h.7tz929qk2hjr">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="#heading=h.7tz929qk2hjr">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, 71</a>]
+  <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> 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> 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> 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> 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
+</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>
+    <td class="tab0">
+<p><strong>Button</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>HID Usage</strong>2</p>
+</td>
+    <td class="tab0">
+<p><strong>Android Button</strong></p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_A">A</a>1</p>
+</td>
+    <td>
+<p>0x09 0x0001</p>
+</td>
+    <td>
+<p>KEYCODE_BUTTON_A (96)</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_B">B</a>1</p>
+</td>
+    <td>
+<p>0x09 0x0002</p>
+</td>
+    <td>
+<p>KEYCODE_BUTTON_B (97)</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_X">X</a>1</p>
+</td>
+    <td>
+<p>0x09 0x0004</p>
+</td>
+    <td>
+<p>KEYCODE_BUTTON_X (99)</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_Y">Y</a>1</p>
+</td>
+    <td>
+<p>0x09 0x0005</p>
+</td>
+    <td>
+<p>KEYCODE_BUTTON_Y (100)</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_DPAD_UP">D-pad up</a>1</p>
+
+<p><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_DPAD_DOWN">D-pad down</a>1</p>
+</td>
+    <td>
+<p>0x01 0x00393</p>
+</td>
+    <td>
+<p><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_HAT_Y">AXIS_HAT_Y</a>4</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_DPAD_LEFT">D-pad left</a>1</p>
+
+<p><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_DPAD_RIGHT">D-pad right</a>1</p>
+</td>
+    <td>
+<p>0x01 0x00393</p>
+</td>
+    <td>
+<p><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_HAT_X">AXIS_HAT_X4 </a></p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_L1">Left shoulder button</a>1</p>
+</td>
+    <td>
+<p>0x09 0x0007</p>
+</td>
+    <td>
+<p>KEYCODE_BUTTON_L1 (102)</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_R1">Right shoulder button</a>1</p>
+</td>
+    <td>
+<p>0x09 0x0008</p>
+</td>
+    <td>
+<p>KEYCODE_BUTTON_R1 (103)</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_THUMBL">Left stick click</a>1</p>
+</td>
+    <td>
+<p>0x09 0x000E</p>
+</td>
+    <td>
+<p>KEYCODE_BUTTON_THUMBL (106)</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BUTTON_THUMBR">Right stick click</a>1</p>
+</td>
+    <td>
+<p>0x09 0x000F</p>
+</td>
+    <td>
+<p>KEYCODE_BUTTON_THUMBR (107)</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_HOME">Home</a>1</p>
+</td>
+    <td>
+<p>0x0c 0x0223</p>
+</td>
+    <td>
+<p>KEYCODE_HOME (3)</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><a href="http://developer.android.com/reference/android/view/KeyEvent.html#KEYCODE_BACK">Back</a>1</p>
+</td>
+    <td>
+<p>0x0c 0x0224</p>
+</td>
+    <td>
+<p>KEYCODE_BACK (4)</p>
+</td>
+ </tr>
+</table>
+
+
+<p>1 [<a href="http://developer.android.com/reference/android/view/KeyEvent.html">Resources, 72</a>]</p>
+
+<p>2 The above HID usages must be declared within a Game pad CA (0x01 0x0005).</p>
+
+<p>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>4 [<a href="http://developer.android.com/reference/android/view/MotionEvent.html">Resources, 71</a>]</p>
+<table>
+ <tr>
+    <td class="tab0">
+<p><strong>Analog Controls</strong>1</p>
+</td>
+    <td class="tab0">
+<p><strong>HID Usage</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>Android Button</strong></p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_LTRIGGER">Left Trigger</a></p>
+</td>
+    <td>
+<p>0x02 0x00C5</p>
+</td>
+    <td>
+<p>AXIS_LTRIGGER </p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_THROTTLE">Right Trigger</a></p>
+</td>
+    <td>
+<p>0x02 0x00C4</p>
+</td>
+    <td>
+<p>AXIS_RTRIGGER </p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_Y">Left Joystick</a></p>
+</td>
+    <td>
+<p>0x01 0x0030</p>
+
+<p>0x01 0x0031</p>
+</td>
+    <td>
+<p>AXIS_X</p>
+
+<p>AXIS_Y</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p><a href="http://developer.android.com/reference/android/view/MotionEvent.html#AXIS_Z">Right Joystick</a></p>
+</td>
+    <td>
+<p>0x01 0x0032</p>
+
+<p>0x01 0x0035</p>
+</td>
+    <td>
+<p>AXIS_Z</p>
+
+<p>AXIS_RZ</p>
+</td>
+ </tr>
+</table>
+
+
+<p>1 [<a href="http://developer.android.com/reference/android/view/MotionEvent.html">Resources, 71</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> <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>].
+</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, 73</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> MUST return an accurate list of supported sensors via the
+SensorManager.getSensorList() and similar methods
+  <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> 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> 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
+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>].
+</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>
+
+<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="http://source.android.com/devices/sensors/composite_sensors.html">Resources, 76</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="http://source.android.com/devices/sensors/composite_sensors.html">Resources, 76</a>].</p>
+
+<p>Some Android sensor supports a "continuous" trigger mode, which returns data
+continuously [<a href="http://source.android.com/devices/sensors/base_triggers.html#continuous">Resources, 77</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 encouraged 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> MUST be able to report events up to a frequency of at least 100 Hz and SHOULD
+report events up to at least 200 Hz
+  <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> MUST be capable of measuring from freefall up to four times the gravity (4g) or
+more on any axis
+  <li> MUST have a resolution of at least 8-bits and SHOULD have a resolution of at
+least 16-bits
+  <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> SHOULD be temperature compensated
+  <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> 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
+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> 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> SHOULD implement a TYPE_ROTATION_VECTOR composite sensor, if a gyroscope sensor
+and a magnetometer sensor is also included
+</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 encouraged to implement the TYPE_MAGNETIC_FIELD_UNCALIBRATED sensor.
+  <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> 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> MUST be capable of measuring between -900 μT and +900 μT on each axis before
+saturating
+  <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> MUST have a resolution equal or denser than 0.6 μT and SHOULD have a resolution
+equal or denser than 0.2 μT
+  <li> SHOULD be temperature compensated
+  <li> MUST support online calibration and compensation of the hard iron bias, and
+preserve the compensation parameters between device reboots
+  <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> 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> SHOULD implement a TYPE_ROTATION_VECTOR composite sensor, if an accelerometer
+sensor and a gyroscope sensor is also included
+  <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. 
+</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 encouraged to implement the SENSOR_TYPE_GYROSCOPE_UNCALIBRATED sensor. 
+  <li> MUST be capable of measuring orientation changes up to 1,000 degrees per second
+  <li> MUST be able to report events up to a frequency of at least 100 Hz and SHOULD
+report events up to at least 200 Hz
+  <li> MUST have a resolution of 12-bits or more and SHOULD have a resolution of
+16-bits or more
+  <li> MUST be temperature compensated
+  <li> MUST be calibrated and compensated while in use, and preserve the compensation
+parameters between device reboots
+  <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> SHOULD implement a TYPE_ROTATION_VECTOR composite sensor, if an accelerometer
+sensor and a magnetometer sensor is also included
+  <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.
+</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> MUST be able to deliver events at 5 Hz or greater
+  <li> MUST have adequate precision to enable estimating altitude
+  <li> MUST be temperature compensated
+</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> MUST have 1-bit of accuracy or more
+</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>
+
+<table>
+ <tr>
+    <td class="tab2"></td>
+    <td>
+<p>Android Television device implementations MUST include Wi-Fi support. </p>
+</td>
+ </tr>
+</table>
+
+
+<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> 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> 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
+</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, 80</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> MUST support regular Wi-Fi operation
+  <li> SHOULD support concurrent Wi-Fi and Wi-Fi Direct operation
+</ul>
+
+<h4 id=7_4_2_2_wi-fi_tunneled_direct_link_setup>7.4.2.2. Wi-Fi Tunneled Direct Link Setup</h4>
+
+<table>
+ <tr>
+    <td class="tab2"></td>
+    <td>
+<p>Android Television device implementations MUST include support for Wi-Fi
+Tunneled Direct Link Setup (TDLS).</p>
+</td>
+ </tr>
+</table>
+
+
+<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
+by the WiFiManager API, the device:</p>
+
+<ul>
+  <li> SHOULD use TDLS only when it is possible AND beneficial
+  <li> SHOULD have some heuristic and NOT use TDLS when its performance might be worse
+than going through the Wi-Fi access point
+</ul>
+
+<h3 id=7_4_3_bluetooth>7.4.3. Bluetooth</h3>
+
+<table>
+ <tr>
+    <td class="tab2"></td>
+    <td>
+<p>Android Television device implementations MUST support Bluetooth and Bluetooth
+LE and Android Watch device implementations MUST support Bluetooth.</p>
+</td>
+ </tr>
+</table>
+
+
+<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
+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> 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> 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
+android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported() method
+  <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> 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
+</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, 53</a>]
+  <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> NfcB (ISO14443-3B)
+      <li> NfcF (JIS 6319-4)
+      <li> IsoDep (ISO 14443-4)
+      <li> NFC Forum Tag Types 1, 2, 3, 4 (defined by the NFC Forum)
+    </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.
+  <ul>
+    <li> NfcV (ISO 15693)
+  </ul>
+  <li> MUST be capable of transmitting and receiving data via the following
+peer-to-peer standards and protocols:
+  <ul>
+    <li> ISO 18092
+    <li> LLCP 1.0 (defined by the NFC Forum)
+    <li> SDP 1.0 (defined by the NFC Forum)
+    <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> SNEP 1.0 (defined by the NFC Forum)
+  </ul>
+  <li> MUST include support for Android Beam [<a href="http://developer.android.com/guide/topics/connectivity/nfc/nfc.html">Resources, 85</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> 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> MUST implement the NPP server. Messages received by the NPP server MUST be
+processed the same way as the SNEP default server.
+    <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> 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> SHOULD use a gesture or on-screen confirmation, such as 'Touch to Beam', before
+sending outbound P2P NDEF messages
+    <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> 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://www.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
+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.
+  </ul>
+  <li> MUST poll for all supported technologies while in NFC discovery mode
+  <li> SHOULD be in NFC discovery mode while the device is awake with the screen
+active and the lock-screen unlocked
+</ul>
+</ul>
+
+<p>(Note that publicly available links are not available for the JIS, ISO, and NFC
+Forum specifications cited above.)</p>
+
+<p>Android 5.0 includes support for NFC Host Card Emulation (HCE) mode. If a
+device implementation does include an NFC controller capable of HCE and
+Application ID (AID) routing, then it:</p>
+
+<ul>
+  <li> MUST report the android.hardware.nfc.hce feature constant
+  <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>]
+</ul>
+
+<p>Additionally, device implementations MAY include reader/writer support for the
+following MIFARE technologies.</p>
+
+<ul>
+  <li> MIFARE Classic
+  <li> MIFARE Ultralight 
+  <li> NDEF on MIFARE Classic 
+</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> 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> 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
+</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, 53]</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>
+
+<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>
+
+<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> MUST have a resolution of at least 2 megapixels
+  <li> SHOULD have either hardware auto-focus or software auto-focus implemented in
+the camera driver (transparent to application software)
+  <li> MAY have fixed-focus or EDOF (extended depth of field) hardware
+  <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.
+</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> MUST have a resolution of at least VGA (640x480 pixels)
+  <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> MAY include features (such as auto-focus, flash, etc.) available to rear-facing
+cameras as described in <a href="#heading=h.v6dmzvarwqkm">section 7.5.1</a>
+  <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> 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
+orientation specified by the application.
+    <li> Otherwise, the preview MUST be mirrored along the device's default horizontal
+axis.
+  </ul>
+  <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> MUST NOT mirror the final captured still image or video streams returned to
+application callbacks or committed to media storage
+</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> MUST support USB Video Class (UVC 1.0 or higher)
+  <li> MAY support multiple cameras
+</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> 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> 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> 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.
+</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
+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, 92</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>
+
+<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>
+
+<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>
+
+<table>
+ <tr>
+    <td class="tab2"></td>
+    <td>
+<p>Android Television devices MUST have at least 5GB of non-volatile storage
+available for application private data.</p>
+</td>
+ </tr>
+</table>
+
+
+<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="#heading=h.6fey5v3qb5m3">section 7.1.1</a> for screen size and density definitions.)</p>
+<table>
+ <tr>
+    <td class="tab0">
+<p><strong>Density and screen size</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>32-bit device</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>64-bit device</strong></p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>Android Watch devices (due to smaller screens)</p>
+</td>
+    <td>
+<p>416MB</p>
+</td>
+    <td>
+<p>Not applicable</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>xhdpi or lower on small/normal screens</p>
+
+<p>hdpi or lower on large screens</p>
+
+<p>mdpi or lower on extra large screens</p>
+</td>
+    <td>
+<p>512MB</p>
+</td>
+    <td>
+<p>832MB</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>400dpi or higher on small/normal screens</p>
+
+<p>xhdpi or higher on large screens</p>
+
+<p>tvdpi or higher on extra large screens</p>
+</td>
+    <td>
+<p>896MB</p>
+</td>
+    <td>
+<p>1280MB</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>560dpi or higher on small/normal screens</p>
+
+<p>400dpi or higher on large screens</p>
+
+<p>xhdpi or higher on extra large screens</p>
+</td>
+    <td>
+<p>1344MB</p>
+</td>
+    <td>
+<p>1824MB</p>
+</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>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>very strongly encouraged</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
+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> 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> MUST mount the SD card by default
+</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, device implementations MUST
+provide some mechanism to access the contents of shared storage from a host
+computer, such as USB mass storage (UMS) or Media Transfer Protocol (MTP).
+Device implementations MAY use USB mass storage, but SHOULD use Media Transfer
+Protocol. 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, 96</a>]
+  <li> SHOULD report a USB device class of 0x00
+  <li> SHOULD report a USB interface name of 'MTP'
+</ul>
+
+<p>If the device implementation lacks USB ports, it MUST provide a host computer
+with access to the contents of shared storage by some other means, such as a
+network file system.</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> 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> 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> 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, if the device reports the android.hardware.feature.output
+feature or the android.hardware.camera feature.
+  <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, 97</a>]
+    <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>]
+  </ul>
+  <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> The value of iSerialNumber in USB standard device descriptor MUST be equal to
+the value of android.os.Build.SERIAL.
+</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> 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> 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> 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> 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> 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>]
+</ul>
+
+<h2 id=7_8_audio>7.8. Audio</h2>
+
+
+<h3 id=7_8_1_microphone>7.8.1. Microphone</h3>
+
+<table>
+ <tr>
+    <td class="tab2"></td>
+    <td>
+<p>Android Handheld and Watch devices MUST include a microphone.</p>
+</td>
+ </tr>
+</table>
+
+
+<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="#heading=h.5h5uvpadidzr">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="#heading=h.q24elivs4xtv">section 5.4</a>
+  <li> MUST meet the audio latency requirements in <a href="#heading=h.1p55xhbym9l4">section 5.6</a>
+</ul>
+
+<h3 id=7_8_2_audio_output>7.8.2. Audio Output</h3>
+
+<table>
+ <tr>
+    <td class="tab2"></td>
+    <td>
+<p>Android Watch devices MAY include an audio output.</p>
+</td>
+ </tr>
+</table>
+
+
+<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> MUST meet the audio playback requirements in <a href="#heading=h.1xocvxnwynnm">section 5.5</a>
+  <li> MUST meet the audio latency requirements in <a href="#heading=h.1p55xhbym9l4">section 5.6</a>
+</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, 101</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> MUST support TRRS audio plugs with the CTIA pin-out order, and SHOULD support
+audio plugs with the OMTP pin-out order
+  <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> 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> <strong>210–290 Ohm</strong>:<strong> </strong>KEYCODE_VOLUME_UP
+    <li> <strong>360–680 Ohm</strong>: KEYCODE_VOLUME_DOWN
+  </ul>
+  <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
+  </ul>
+  <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> MUST be capable of driving at least 150mV +/- 10% of output voltage on a 32 Ohm
+speaker impedance
+  <li> MUST have a microphone bias voltage between 1.8V ~ 2.9V
+</ul>
+
+<h1 id=8_performance_compatibility>8. Performance Compatibility</h1>
+
+
+<p>Some minimum performance criterias are critical to the user experience and
+impacts 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> <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> <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.
+</ul>
+
+<h2 id=8_2_file_i_o_access_performance>8.2. File I/O Access Performance</h2>
+
+
+<p>Device implementations MUST ensure 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 10MB/s
+for a 256MB file using 10MB write buffer. 
+  <li> <strong>Random write</strong>—Device implementations MUST ensure a random write performance of 0.5MB/s for a
+256MB file using 4KB write buffer. 
+  <li> <strong>Sequential read</strong>—Device implementations MUST ensure a sequential read performance of 15MB/s for
+a 256MB file using 10MB write buffer. 
+  <li> <strong>Random read</strong>—Device implementations MUST ensure a random read performance of 3.5MB/s for a
+256MB file using 4KB write buffer. 
+</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
+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, 102</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>
+
+<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, 102</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>
+
+<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="#heading=h.a32osmf1tmwt">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> MAY provide a single Android sandbox shared by all applications using the
+alternate runtime
+  <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> MUST NOT launch with, grant, or be granted access to the sandboxes
+corresponding to other Android applications
+  <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
+</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>
+
+<table>
+ <tr>
+    <td class="tab2"></td>
+    <td>
+<p>This feature is optional for all device types.</p>
+</td>
+ </tr>
+</table>
+
+
+<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/tech/storage">Resources, 104</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> 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> 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> 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> 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, 105</a>] for primary external storage. 
+</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
+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 can 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 Android framework:</p>
+
+<ul>
+  <li> MUST maintain compatibility with existing applications
+  <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> SHOULD NOT be user or developer configurable
+</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 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>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> SHOULD load policy from /sepolicy file on the device
+  <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
+domains as well as device/vendor specific domains
+  <li> MUST support dynamic updates of the SELinux policy file without requiring a
+system image update
+</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>
+
+<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>
+
+<h2 id=9_9_full-disk_encryption>9.9. Full-Disk Encryption</h2>
+
+<table>
+ <tr>
+    <td class="tab2"></td>
+    <td>
+<p>Optional for Android device implementations without a lock screen.</p>
+</td>
+ </tr>
+</table>
+
+
+<p>If the device implementation has a lock screen, 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/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
+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>Device implementations SHOULD support verified boot for device integrity, and
+if the feature is supported it MUST declare the platform feature flag
+android.software.verified_boot. 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. The
+upstream Android Open Source Project provides a preferred implementation of
+this feature based on the linux kernel feature dm-verity.</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>very strongly encouraged</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, 108</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 5.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> "Tethered" updates over USB from a host PC
+  <li> "Offline" updates via a reboot and update from a file on removable storage
+</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, the
+device MUST support Over-the-air download with offline update via reboot.</p>
+
+<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 5.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.0, 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>
+
+<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>
+    <td class="tab0">
+<p><strong>Section(s)</strong></p>
+</td>
+    <td class="tab0">
+<p><strong>Summary of change</strong></p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>1. Introduction</p>
+</td>
+    <td>
+<p>Updated requirements to refer to SDK documentation as source of truth.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>2. Device Types</p>
+</td>
+    <td>
+<p>Included definitions for device types for handheld, television, and watch
+devices.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>2.1 Device Configuration</p>
+</td>
+    <td>
+<p>Added non-exhaustive list to illustrate hardware configuration deviation across
+devices.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>3.1. Managed API Compatibility</p>
+</td>
+    <td>
+<p>MUST also provide complete implementations of APIs with "@SystemApi" marker in
+the upstream Android source code.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>3.2.2. Build Parameters</p>
+</td>
+    <td>
+<p>Included SUPPORTED_ABIS, SUPPORTED_32_BIT_ABIS, and SUPPORTED_64_BIT_ABIS
+parameters in list, updated PRODUCT to require unique Product SKUs, and updated
+TAGS.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>3.2.3.1. Core Application Intents</p>
+</td>
+    <td>
+<p>Clarified language that the compatibility requirement is for mainly the intents
+pattern </p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>3.2.3.5. Default App Settings</p>
+</td>
+    <td>
+<p>Included new requirements for home screen, NFC, and default SMS applications.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>3.3.1 Application Binary Interfaces</p>
+</td>
+    <td>
+<p>Added requirements to support equivalent 32-bit ABI if any 64-bit ABI is
+supported. Updated parameters to reflect this change.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>3.4.1. WebView Compatibility</p>
+</td>
+    <td>
+<p>Webview compatibility required for all devices except Android Watch devices.
+Removed Locale string requirement.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>3.4.2. Browser compatibility</p>
+</td>
+    <td>
+<p>Android Television and Watch Devices MAY omit a browser application, but all
+other types of device implementations MUST include one.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>3.7. Runtime compatibility</p>
+</td>
+    <td>
+<p>Updated Minimum application memory requirements</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>3.8.2. Widgets</p>
+</td>
+    <td>
+<p>Widget support is optional for all device types, but recommended for Handheld
+Devices.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>3.8.3. Notifications</p>
+</td>
+    <td>
+<p>Expanded definitions for types of supported notifications. </p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>3.8.4. Search</p>
+</td>
+    <td>
+<p>Android Television devices MUST include global search. All other device types
+SHOULD.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>3.8.6. Themes</p>
+</td>
+    <td>
+<p>Devices MUST support material theme.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>3.8.7. Live Wallpapers</p>
+</td>
+    <td>
+<p>Devices that include live wallpaper MUST report the platform feature flag
+android.software.live_wallpaper.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>3.8.8. Activity Switching</p>
+</td>
+    <td>
+<p>Advised requirement to support new Recents User Interface</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>3.8.10. Lock Screen Media Remote Control</p>
+</td>
+    <td>
+<p> Remote Control Client API deprecated in favor of the Media Notification
+Template</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>3.8.11. Dreams</p>
+</td>
+    <td>
+<p>Optional for Android Watch devices. Required for all other device types.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>3.8.13 Unicode and font</p>
+</td>
+    <td>
+<p>MUST support Roboto 2 in addition to existing requirements.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>3.12. TV Input Framework</p>
+</td>
+    <td>
+<p>Android Television device implementations MUST support Television Input
+Framework.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>5.1. Media Codecs</p>
+</td>
+    <td>
+<p>Added 3 sections for Audio, Image, and Video codecs.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>5.4 Audio Recording</p>
+</td>
+    <td>
+<p>Broken into subsections</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>5.4.1. Raw audio capture</p>
+</td>
+    <td>
+<p>Defined characteristics for raw audio capture on devices that declare
+android.hardware.microphone</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>5.5. Audio Playback</p>
+</td>
+    <td>
+<p>Added section 5.5. Audio Playback with 2 subsections: 5.5.1 Audio Effects and
+5.5.2. Audio Output Volume</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>5.6 Audio Latency</p>
+</td>
+    <td>
+<p>Added definitions and requirements for cold output jitter, cold input jitter,
+and continuous round-trip latency.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>5.8 Secure Media</p>
+</td>
+    <td>
+<p>Included secure media requirements from 7.1.8. External Displays and added
+requirements for Android Television.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>6.1. Developer Tools</p>
+</td>
+    <td>
+<p>Updated resources.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>6.2.1. Experimental</p>
+</td>
+    <td>
+<p>Removed section</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7. Hardware Compatibility</p>
+</td>
+    <td>
+<p>Updated to reflect that device implementations MUST consistently report
+accurate hardware configuration for the same build fingerprint.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.1.1.1. Screen Size</p>
+</td>
+    <td>
+<p>Updated to reflect Android Watch devices screen size and that the value can’t
+change</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.1.1.2. Screen Aspect Ratio</p>
+</td>
+    <td>
+<p>Updated to reflect Android Watch devices screen aspect ratio (1:1).</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.1.3. Screen Orientation</p>
+</td>
+    <td>
+<p>Updated to reflect that devices with a fixed orientation landscape screen
+SHOULD only report that orientation. </p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.1.4. 2D and 3D Graphics Acceleration</p>
+</td>
+    <td>
+<p>Added that Android devices MAY support the Android extension pack. </p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>(old) 7.1.6. Screen Types</p>
+</td>
+    <td>
+<p>Section Removed </p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.1.6. Screen Technology</p>
+</td>
+    <td>
+<p>Updated pixel aspect ratio (PAR) to be between 0.9 and 1.15. (~15% tolerance)</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.1.7. External Displays</p>
+</td>
+    <td>
+<p>Moved part of section to section 5.8. Secure Media.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.2.2. Non-touch Navigation</p>
+</td>
+    <td>
+<p>Android Television devices MUST support D-pad. </p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.2.3. Navigation keys</p>
+</td>
+    <td>
+<p>Included language for support across different device types. </p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.2.4. Touchscreen input</p>
+</td>
+    <td>
+<p>Android Watch devices MUST support touchscreen input. </p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.2.6. Game Controller Support</p>
+</td>
+    <td>
+<p>Added section with Android Television requirements.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.2.7. Remote Control </p>
+</td>
+    <td>
+<p>Added section with Android Television requirements.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.3. Sensors</p>
+</td>
+    <td>
+<p>Redefined synthetic sensors as composite sensors and streaming sensors as
+continuous sensors. Sensors should report event time in nanoseconds.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.3.1. Accelerometer</p>
+</td>
+    <td>
+<p>Clarified required sensor types and revised requirement thresholds. </p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.3.2. Magnetometer</p>
+</td>
+    <td>
+<p>Clarified required sensor types and revised requirement thresholds.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.3.4. Gyroscope</p>
+</td>
+    <td>
+<p>Clarified required sensor types and revised requirement thresholds.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.3.5. Barometer</p>
+</td>
+    <td>
+<p>Changed from MAY to SHOULD implement barometer. MUST implement and report
+TYPE_PRESSURE sensor.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.3.6. Thermometer</p>
+</td>
+    <td>
+<p>Devices MAY include ambient thermometer. MAY but SHOULD NOT include CPU
+thermometer.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.3.8. Proximity Sensor</p>
+</td>
+    <td>
+<p>Devices that can make a voice call and indicate any value other than
+PHONE_TYPE_NONE in getPhoneType SHOULD include a proximity sensor.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.4.2. IEEE 802.11 (Wi-Fi)</p>
+</td>
+    <td>
+<p>Android Television devices MUST include Wi-Fi support. Devices that DO support
+wifi must report android.hardware.wifi. </p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.4.2.1. Wi-Fi Direct</p>
+</td>
+    <td>
+<p>MUST report the hardware feature android.hardware.wifi.direct.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.4.2.2. Wi-Fi Tunneled Direct Link Setup</p>
+</td>
+    <td>
+<p>Android Television devices MUST include support for Wi-Fi TDLS.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.5. Cameras</p>
+</td>
+    <td>
+<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>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.5.3. External Cameras</p>
+</td>
+    <td>
+<p>Added requirements that device implementations with USB host mode MAY include
+support for an external camera.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.5.5. Camera System Features</p>
+</td>
+    <td>
+<p>Added list of camera features and when they should be defined. </p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.6.1. Minimum Memory and Storage</p>
+</td>
+    <td>
+<p>Updated requirements for 32- and 64-bit devices. SVELTE memory requirement
+removed. Devices MUST have at least 1.5GB of non-volatile storage</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.6.2. Application Shared Storage</p>
+</td>
+    <td>
+<p>Updated requirements for user-accessible removable storage</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.7. USB</p>
+</td>
+    <td>
+<p>Removed requirements for non-charging ports being on the same edge as the
+micro-USB port. Updated requirements for Host and Peripheral mode. </p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>7.8.1. Audio</p>
+</td>
+    <td>
+<p>Moved microphone section here. Added requirements for Audio Output and Audio
+Analog ports. </p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>8. Performance Compatibility</p>
+</td>
+    <td>
+<p>Added requirements for user interface consistency.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>9.5. Multi-User Support</p>
+</td>
+    <td>
+<p>Multi-user support feature is optional for all device types. Detailed
+requirements by device type in section.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>9.7. Kernel Security Features</p>
+</td>
+    <td>
+<p>MAY have a visible user interface when an unblocked security violation occurs
+resulting in a successful exploit. No permissive mode domains allowed.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>9.9. Full-Disk Encryption</p>
+</td>
+    <td>
+<p>Devices with a lock screen MUST support full-disk encryption. For new devices,
+full-disk encryption must be enabled out of box. </p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>9.10 Verified boot</p>
+</td>
+    <td>
+<p>Added section to recommend that Device implementations support verified boot
+for device integrity.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>10.3. Reference Applications</p>
+</td>
+    <td>
+<p>Removed section from CDD.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>11. Updatable Software</p>
+</td>
+    <td>
+<p>If a device supports 802.11 or Bluetooth PAN (Personal Area Network) profile,
+then it MUST support Over-the-air download with offline update via reboot.</p>
+</td>
+ </tr>
+ <tr>
+    <td>
+<p>14. Resources</p>
+</td>
+    <td>
+<p>Resources moved from section 2 to section 14</p>
+</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, 109</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. API definitions and documentation: <a href="http://developer.android.com/reference/packages.html">http://developer.android.com/reference/packages.html</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>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>8. Android 5.0 allowed version strings: <a href="http://source.android.com/compatibility/5.0/versions.html">http://source.android.com/compatibility/5.0/versions.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>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>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>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>13. WebView compatibility: <a href="http://www.chromium.org/">http://www.chromium.org/</a></p>
+
+<p>14. HTML5: <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/">http://www.whatwg.org/specs/web-apps/current-work/multipage/</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>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>17. HTML5/W3C geolocation API: <a href="http://www.w3.org/TR/geolocation-API/">http://www.w3.org/TR/geolocation-API/</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>19. HTML5/W3C IndexedDB API: <a href="http://www.w3.org/TR/IndexedDB/">http://www.w3.org/TR/IndexedDB/</a></p>
+
+<p>20. 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>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>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>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>25. 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>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>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>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>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>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>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>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>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>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>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>37. Settings.Secure LOCATION_MODE:</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>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>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>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>41. Android Device Owner App:</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>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>44. Eyes Free project: <a href="http://code.google.com/p/eyes-free">http://code.google.com/p/eyes-free</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>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>47. Reference tool documentation (for adb, aapt, ddms, systrace): <a href="http://developer.android.com/guide/developing/tools/index.html">http://developer.android.com/guide/developing/tools/index.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>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>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>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>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>53. Android android.content.pm.PackageManager class and Hardware Features List:</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>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>55. ADB: <a href="http://developer.android.com/tools/help/adb.html">http://developer.android.com/tools/help/adb.html</a> </p>
+
+<p>56. Dumpsys: <a href="https://source.android.com/devices/tech/input/dumpsys.html">https://source.android.com/devices/tech/input/dumpsys.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>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>59. SysyTrace tool: <a href="http://developer.android.com/tools/help/systrace.html">http://developer.android.com/tools/help/systrace.html</a></p>
+
+<p>60. Android Application Development-Related Settings:</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>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>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>63. RenderScript: <a href="http://developer.android.com/guide/topics/renderscript/">http://developer.android.com/guide/topics/renderscript/</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>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>66. EGL Extension-EGL_ANDROID_RECORDABLE:</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>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>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>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>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>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>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>73. Android Open Source sensors: <a href="http://source.android.com/devices/sensors/">http://source.android.com/devices/sensors/</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>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>76. Android Open Source composite sensors: <a href="http://source.android.com/devices/sensors/composite_sensors.html">http://source.android.com/devices/sensors/composite_sensors.html</a></p>
+
+<p>77. Continuous trigger mode: <a href="http://source.android.com/devices/sensors/base_triggers.html#continuous">http://source.android.com/devices/sensors/base_triggers.html#continuous</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>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>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>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>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>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>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>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>86. Android NFC Sharing Settings:</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>87. NFC Connection Handover: <a href="http://www.nfc-forum.org/specs/spec_list/#conn_handover">http://www.nfc-forum.org/specs/spec_list/#conn_handover</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>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>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>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>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>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>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>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>96. Android File Transfer: <a href="http://www.android.com/filetransfer">http://www.android.com/filetransfer</a></p>
+
+<p>97. Android Open Accessories: <a href="http://developer.android.com/guide/topics/usb/accessory.html">http://developer.android.com/guide/topics/usb/accessory.html</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>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>100. USB Host API:<a href="http://developer.android.com/guide/topics/usb/host.html"> http://developer.android.com/guide/topics/usb/host.html</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>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>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>104. External Storage reference: <a href="http://source.android.com/devices/tech/storage">http://source.android.com/devices/tech/storage</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>106. SMS Short Code: <a href="http://en.wikipedia.org/wiki/Short_code">http://en.wikipedia.org/wiki/Short_code</a></p>
+
+<p>107. Android Open Source Encryption: <a href="http://source.android.com/devices/tech/encryption/index.html">http://source.android.com/devices/tech/encryption/index.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>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>110. WebM project: <a href="http://www.webmproject.org/">http://www.webmproject.org/</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 style="page-break-before: always;"></div>
+
+<div id="footerContent" xmlns:pdf="https://source.android.com">
+<pdf:pagenumber/>
+</div>
+</body>
+</html>