diff options
author | Clay Murphy <claym@google.com> | 2015-02-13 10:22:33 -0800 |
---|---|---|
committer | Unsuk Jung <unsuk@google.com> | 2015-02-13 18:22:44 -0800 |
commit | 0e4e4088318ea517c36d4821737af402279bab78 (patch) | |
tree | c707a8923d9a47dc60836c42c9f3ccba881d6f89 | |
parent | 0ae76f7f9c4b73c0d0a832d2486c9ab2a6b7f180 (diff) | |
download | source.android.com-0e4e4088318ea517c36d4821737af402279bab78.tar.gz |
Docs: Adding reverse-engineered XHTML variant of CDDs from Docs
Bug: 18341319
Change-Id: Ib5571ff464bee3f6fa581f837fd7fa62be0f8665
-rw-r--r-- | src/compatibility/4.4/android-4.4-cdd.xhtml | 3023 | ||||
-rw-r--r-- | src/compatibility/5.0/android-5.0-cdd.xhtml | 6066 |
2 files changed, 9089 insertions, 0 deletions
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 00000000..3aacabb5 --- /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 © 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 <video> 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><uses-library></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> </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> </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> </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> </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> </td> +<td style="text-align: center;">REQUIRED</td> +<td> </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> </td> +<td style="text-align: center;">REQUIRED</td> +<td> </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> </td> +<td>PNG (.png)</td> +</tr> + +<tr> +<td>BMP</td> +<td> </td> +<td style="text-align: center;">REQUIRED</td> +<td> </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> </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> </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> </td> +<td style="text-align: center;">REQUIRED</td> +<td> </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> </td> +<td><a href="http://www.webmproject.org/">WebM</a> (.webm) and Matroska (.mkv, Android 4.0+)***</td> +</tr> + +<tr> +<td>VP9</td> +<td> </td> +<td style="text-align: center;">REQUIRED<br/><small>(Android 4.4+)</small></td> +<td> </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> </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> </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> </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, ±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><supports-screens></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> > 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> <= 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 µ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 +"true" [<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 "true" 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> </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><uses-permission></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> </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 00000000..76c50ac4 --- /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 © 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> |