Docs: Adding source files for older PDFs to ease diffing
Bug: 18341319
Change-Id: I074181c486b6d338f4ab5c5dde5f76c2afb6142a
diff --git a/src/compatibility/2.1/android-2.1-cdd.xhtml b/src/compatibility/2.1/android-2.1-cdd.xhtml
new file mode 100644
index 0000000..cd7a7ca
--- /dev/null
+++ b/src/compatibility/2.1/android-2.1-cdd.xhtml
@@ -0,0 +1,1193 @@
+<?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 2.1 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 2.1 Compatibility Definition</h1>
+<p>Copyright © 2010, Google Inc. All rights reserved.<br/>
+<a href="mailto:compatibility@android.com">compatibility@android.com</a>
+</p>
+
+<h2>1. Introduction</h2>
+<p>This document enumerates the requirements that must be met in order for
+mobile phones to be compatible with Android 2.1.</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
+2.1. A "device implementation" or "implementation" is the hardware/software
+solution so developed.</p>
+<p>To be considered compatible with Android 2.1, device implementations:</p>
+<ul>
+<li>MUST meet the requirements presented in this Compatibility Definition,
+including any documents incorporated via reference.</li>
+<li>MUST pass the most recent version of the Android Compatibility Test Suite
+(CTS) available at the time of the device implementation's software is
+completed. (The CTS is available as part of the Android Open Source Project [<a
+href="#resources02">Resources, 2</a>].) The CTS tests many, but not all, of the
+components outlined in this document.</li>
+</ul>
+<p>Where this definition or the CTS is silent, ambiguous, or incomplete, it is
+the responsibility of the device implementer to ensure compatibility with
+existing implementations. 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 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 CTS 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="resources"/><h2>2. Resources</h2>
+<ol>
+<a name="resources01"/><li>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"/><li>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"/><li>Android Open Source Project: <a href="http://source.android.com/">http://source.android.com/</a></li>
+<a name="resources04"/><li>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"/><li>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"/><li>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"/><li>Android 2.1 allowed version strings: <a href="http://source.android.com/compatibility/2.1/versions.xhtml">http://source.android.com/compatibility/2.1/versions.xhtml</a></li>
+<a name="resources08"/><li>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="resources09"/><li>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="resources10"/><li>Dalvik Virtual Machine specification: available in the Android source code, at dalvik/docs</li>
+<a name="resources11"/><li>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="resources12"/><li>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="resources13"/><li>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="resources14"/><li>Status Bar icon style guide: <a href="http://developer.android.com/guide/practices/ui_guidelines/icon_design.html#statusbarstructure">http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure</a></li>
+<a name="resources15"/><li>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="resources16"/><li>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="resources17"/><li>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="resources18"/><li>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="resources19"/><li>Reference tool documentation (for adb, aapt, ddms): <a href="http://developer.android.com/guide/developing/tools/index.html">http://developer.android.com/guide/developing/tools/index.html</a></li>
+<a name="resources20"/><li>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="resources21"/><li>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="resources22"/><li>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="resources23"/><li>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="resources24"/><li>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="resources25"/><li>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="resources26"/><li>android.hardware.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="resources27"/><li>Sensor coordinate space: <a href="http://developer.android.com/reference/android/hardware/SensorEvent.html">http://developer.android.com/reference/android/hardware/SensorEvent.html</a></li>
+<a name="resources28"/><li>Android Security and Permissions reference: <a href="http://developer.android.com/guide/topics/security/security.html">http://developer.android.com/guide/topics/security/security.html</a></li>
+<a name="resources29"/><li>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>
+</ol>
+<p>Many of these resources are derived directly or indirectly from the Android
+2.1 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>
+
+<h2>3. Software</h2>
+<p>The Android platform includes a set of managed APIs, a set of native APIs,
+and a body of so-called "soft" APIs such as the Intent system and
+web-application APIs. This section details the hard and soft APIs that are
+integral to compatibility, as well as certain other relevant technical and
+user interface behaviors. Device implementations MUST comply with all the
+requirements in this section.</p>
+
+<h3>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 2.1 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>
+
+<h3>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. This section details the "soft" APIs
+and system behaviors required for compatibility with Android 2.1. Device
+implementations MUST meet all the requirements presented in this section.</p>
+<h4>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 10 lists addtional
+requirements related to the Android security model.</p>
+<h4>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>android.os.Build.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>android.os.Build.VERSION.SDK</td>
+<td>The version of the currently-executing Android system, in a format
+accessible to third-party application code. For Android 2.1, this field MUST have
+the integer value 7.</td>
+</tr>
+<tr>
+<td>android.os.Build.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 shipped 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>android.os.Build.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.
+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>android.os.Build.BRAND</td>
+<td>A value chosen by the device implementer identifying the name of the
+company, organization, individual, etc. who produced the device, in
+human-readable format. A possible use of this field is to indicate the OEM
+and/or carrier who sold the device. 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>android.os.Build.DEVICE</td>
+<td>A value chosen by the device implementer identifying the specific
+configuration or revision of the body (sometimes called "industrial design")
+of the device. 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>android.os.Build.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)/$(BOARD):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)</code><br/>
+For example:
+<br/><code>acme/mydevice/generic/generic:2.1-update1/ERC77/3359:userdebug/test-keys</code><br/>
+The fingerprint MUST NOT include spaces. If other fields included in the
+template above have spaces, they SHOULD be replaced with the ASCII underscore
+("_") character in the fingerprint.</td>
+</tr>
+<tr>
+<td>android.os.Build.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>android.os.Build.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. 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>android.os.Build.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>android.os.Build.PRODUCT</td>
+<td>A value chosen by the device implementer containing the development name
+or code name of the device. MUST be human-readable, but is not necessarily
+intended for view by 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>android.os.Build.TAGS</td>
+<td>A comma-separated list of tags chosen by the device implementer that
+further distinguish the build. For example, "unsigned,debug". This field MUST
+NOT be null or the empty string (""), but a single tag (such as "release") is
+fine.</td>
+</tr>
+<tr>
+<td>android.os.Build.TIME</td>
+<td>A value representing the timestamp of when the build occurred.</td>
+</tr>
+<tr>
+<td>android.os.Build.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".</td>
+</tr>
+<tr>
+<td>android.os.Build.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>
+<h4>3.2.3. Intent Compatibility</h4>
+<p>Android uses Intents to achieve loosely-coupled integration between
+applications. This section describes requirements related to the Intent
+patterns that MUST be honored by device implementations. 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>
+<h4>3.2.3.1. Core Application Intents</h4>
+<p>The Android upstream project defines a number of core applications, such as
+a phone dialer, calendar, contacts book, 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>Calculator</li>
+<li>Camera</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 compontent 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>
+<h4>3.2.3.2. Intent Overrides</h4>
+<p>As Android is an extensible platform, device implementers MUST allow each
+Intent pattern defined in core system apps to be overridden by third-party
+applications. The upstream Android open source project 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 which
+allows the user to select between multiple applications which all handle the
+same Intent pattern.</p>
+<div class="cdd-erratum">Note: this section was modified by Erratum EX6580.</div>
+<h4>3.2.3.3. Intent Namespaces</h4>
+<p>Device implementers 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.* 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.</p>
+<p>This prohibition is analogous to that specified for Java language classes
+in Section 3.6.</p>
+<h4>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>
+
+<h3>3.3. Native API Compatibility</h3>
+<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. Device implementations MUST include support for code
+running in the managed environment to call into native code, using the
+standard Java Native Interface (JNI) semantics. The following APIs MUST be
+available to native code:</p>
+<ul>
+<li>libc (C library)</li>
+<li>libm (math library)</li>
+<li>JNI interface</li>
+<li>libz (Zlib compression)</li>
+<li>liblog (Android logging)</li>
+<li>Minimal support for C++</li>
+<li>Support for OpenGL, as described below</li>
+</ul>
+<p>Device implementations MUST support OpenGL ES 1.0. Devices that lack
+hardware acceleration MUST implement OpenGL ES 1.0 using a software renderer.
+Device implementations SHOULD implement as much of OpenGL ES 1.1 as the device
+hardware supports. Device implementations SHOULD provide an implementation
+for OpenGL ES 2.0, if the hardware is capable of reasonable performance on
+those APIs.</p>
+<p>These libraries MUST be source-compatible (i.e. header compatible) and
+binary-compatible (for a given processor architecture) with the versions
+provided in Bionic by the Android Open Source project. Since the Bionic
+implementations are not fully compatible with other implementations such as
+the GNU C library, device implementers SHOULD use the Android implementation.
+If device implementers use a different implementation of these libraries, they
+MUST ensure header, binary, and behavioral compatibility.</p>
+<p>Device implementations MUST accurately report the native Application Binary
+Interface (ABI) supported by the device, via the
+<code>android.os.Build.CPU_ABI</code> API. The ABI MUST be one of the entries
+documented in the latest version of the Android NDK, in the file
+<code>docs/CPU-ARCH-ABIS.txt</code>. Note that additional releases of the
+Android NDK may introduce support for additional ABIs.</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>
+
+<h3>3.4. Web API Compatibility</h3>
+<p>Many developers and applications rely on the behavior of the
+<code>android.webkit.WebView</code> class [<a
+href="#resources08">Resources, 8</a>]
+for their user interfaces, so the WebView implementation must be
+compatible across Android implementations. The Android Open Source
+implementation uses the WebKit rendering engine to implement the
+WebView.</p>
+<p>Because it is not feasible to develop a comprehensive test suite for a web
+browser, device implementers MUST use the specific upstream build of WebKit in
+the WebView implementation. Specifically:</p>
+<ul>
+<li>WebView MUST use the 530.17 WebKit build from the upstream Android Open
+Source tree for Android 2.1. This build includes a specific set of functionality
+and security fixes for the WebView.</li>
+<li>The user agent string reported by the WebView MUST be in this format:<br/>
+ <code>Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Mobile Safari/530.17</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 SHOULD follow the ISO conventions for country code and language, and SHOULD refer to the current configured locale of the device</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>
+ </ul></li>
+</ul>
+<p>Implementations MAY ship a custom user agent string in the standalone
+Browser application. What's more, the standalone Browser MAY be based on an
+alternate browser technology (such as Firefox, Opera, etc.) However, even if an
+alternate Browser application is shipped, the WebView component provided to
+third-party applications MUST be based on WebKit, as above.</p>
+<p>The WebView configuration MUST include support for the HTML5 database,
+application cache, and geolocation APIs [<a href="#resources09">Resources,
+9</a>]. The WebView MUST include support for
+the HTML5 <code><video></code> tag in
+some form. The standalone Browser application (whether based on the upstream
+WebKit Browser application or a third-party replacement) MUST include support
+for the same HTML5 features just listed for WebView.</p>
+
+<h3>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 meaning 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 particular permission</li>
+</ul>
+<p>The above list is not comprehensive, and the onus is on device implementers
+to ensure behavioral compatibility. 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>
+<p>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.</p>
+
+<h3>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 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.</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>
+
+<h3>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="#resources10">Resources, 10</a>].</p>
+<p>Device implementations MUST configure Dalvik to allocate at least 16MB of
+memory to each application on devices with screens classified as medium- or
+low-density. Device implementations MUST configure Dalvik to allocate at least
+24MB of memory to each application on devices with screens classified as
+high-density. Note that device implementations MAY allocate more memory than
+these figures, but are not required to.</p>
+
+<h3>3.8. User Interface Compatibility</h3>
+<p>The Android platform includes some developer APIs that allow developers to
+hook into the system user interface. Device implementations MUST incorporate
+these standard UI APIs into custom user interfaces they develop, as explained
+below.</p>
+<h4>3.8.1. 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="#resources11">Resources, 11</a>].
+The Android Open Source reference release includes a Launcher application that
+includes user interface elements allowing the user to add, view, and remove
+AppWidgets from the home screen.</p>
+<p>Device implementers MAY substitute an alternative to the reference Launcher
+(i.e. home screen). Alternative Launchers SHOULD include built-in support for
+AppWidgets, and expose user interface elements to add, configure, view, and remove
+AppWidgets directly within the Launcher. Alternative Launchers MAY omit these
+user interface elements; however, if they are omitted, the device implementer
+MUST provide a separate application accessible from the Launcher that allows
+users to add, configure, view, and remove AppWidgets.</p>
+<h4>3.8.2. Notifications</h4>
+<p>Android includes APIs that allow developers to notify users of notable
+events [<a href="#resources12">Resources, 12</a>]. Device implementers MUST provide support for each
+class of notification so defined; specifically: sounds, vibration, light and
+status bar.</p>
+<p>Additionally, the implementation MUST correctly render all resources
+(icons, sound files, etc.) provided for in the APIs [<a
+href="#resources13">Resources, 13</a>], or in the
+Status Bar icon style guide [<a href="#resources14">Resources, 14</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>
+<h4>3.8.3. Search</h4>
+<p>Android includes APIs [<a href="#resources15">Resources, 15</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>
+<p>Device implementations MAY ship alternate search user interfaces, but
+SHOULD include a hard or soft dedicated search button, that can be used at any
+time within any app to invoke the search framework, with the behavior provided
+for in the API documentation.</p>
+<h4>3.8.4. Toasts</h4>
+<p>Applications can use the "Toast" API (defined in [<a
+href="#resources16">Resources, 16</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>
+<h4>3.8.5. 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="#resources17">Resources, 17</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 implemenations 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>
+
+<h2>4. Reference Software Compatibility</h2>
+<p>Device implementers MUST test implementation compatibility using the
+following open-source applications:</p>
+<ul>
+<li>Calculator (included in SDK)</li>
+<li>Lunar Lander (included in SDK)</li>
+<li>The "Apps for Android" applications [<a href="#resources18">Resources, 18</a>].</li>
+</ul>
+<p>Each app above MUST launch and behave correctly on the implementation, for
+the implementation to be considered compatible.</p>
+<p>Additionally, device implementations MUST test each menu item (including all
+sub-menus) of each of these smoke-test applications:</p>
+<ul>
+<li>ApiDemos (included in SDK)</li>
+<li>ManualSmokeTests (included in CTS)</li>
+</ul>
+<p>Each test case in the applications above MUST run correctly on the device
+implementation.</p>
+
+<h2>5. 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="#resources19">Resources, 19</a>].</p>
+<p>Devices implementations MUST NOT extend either the .apk [<a
+href="#resources20">Resources, 20</a>], Android Manifest [<a
+href="#resources21">Resources, 21</a>],
+or Dalvik bytecode [<a href="#resources10">Resources, 10</a>] 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>
+
+<h2>6. Multimedia Compatibility</h2>
+<p>Device implemenations MUST support the following multimedia codecs. 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 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.</p>
+<table><tbody>
+<tr>
+<td rowspan="11"><b>Audio</b></td>
+</tr>
+<tr>
+<td><b>Name</b></td>
+<td><b>Encoder</b></td>
+<td><b>Decoder</b></td>
+<td><b>Details</b></td>
+<td><b>File/Container Format</b></td>
+</tr>
+<tr>
+<td>AAC LC/LTP</td>
+<td> </td>
+<td>X</td>
+<td rowspan="3">Mono/Stereo content in any combination of standard bit rates up to 160 kbps and sampling rates between 8 to 48kHz</td>
+<td rowspan="3">3GPP (.3gp) and MPEG-4 (.mp4, .m4a). No support for raw AAC (.aac)</td>
+</tr>
+<tr>
+<td>HE-AACv1 (AAC+)</td>
+<td> </td>
+<td>X</td>
+</tr>
+<tr>
+<td>HE-AACv2 (enhanced AAC+)</td>
+<td> </td>
+<td>X</td>
+</tr>
+<tr>
+<td>AMR-NB</td>
+<td>X</td>
+<td>X</td>
+<td>4.75 to 12.2 kbps sampled @ 8kHz</td>
+<td>3GPP (.3gp)</td>
+</tr>
+<tr>
+<td>AMR-WB</td>
+<td> </td>
+<td>X</td>
+<td>9 rates from 6.60 kbit/s to 23.85 kbit/s sampled @ 16kHz</td>
+<td>3GPP (.3gp)</td>
+</tr>
+<tr>
+<td>MP3</td>
+<td> </td>
+<td>X</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>X</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>Type 0 and 1 (.mid, .xmf, .mxmf). Also RTTTL/RTX (.rtttl, .rtx), OTA (.ota), and iMelody (.imy)</td>
+</tr>
+<tr>
+<td>Ogg Vorbis</td>
+<td> </td>
+<td>X</td>
+<td> </td>
+<td>Ogg (.ogg)</td>
+</tr>
+<tr>
+<td>PCM</td>
+<td> </td>
+<td>X</td>
+<td>8- and 16-bit linear PCM (rates up to limit of hardware)</td>
+<td>WAVE (.wav)</td>
+</tr>
+<tr>
+<td rowspan="5"><b>Image</b></td>
+</tr>
+<tr>
+<td>JPEG</td>
+<td>X</td>
+<td>X</td>
+<td>base+progressive</td>
+<td> </td>
+</tr>
+<tr>
+<td>GIF</td>
+<td> </td>
+<td>X</td>
+<td> </td>
+<td> </td>
+</tr>
+<tr>
+<td>PNG</td>
+<td>X</td>
+<td>X</td>
+<td> </td>
+<td> </td>
+</tr>
+<tr>
+<td>BMP</td>
+<td> </td>
+<td>X</td>
+<td> </td>
+<td> </td>
+</tr>
+<tr>
+<td rowspan="4"><b>Video</b></td>
+</tr>
+<tr>
+<td>H.263</td>
+<td>X</td>
+<td>X</td>
+<td> </td>
+<td>3GPP (.3gp) files</td>
+</tr>
+<tr>
+<td>H.264</td>
+<td> </td>
+<td>X</td>
+<td> </td>
+<td>3GPP (.3gp) and MPEG-4 (.mp4) files</td>
+</tr>
+<tr>
+<td>MPEG4 Simple Profile</td>
+<td> </td>
+<td>X</td>
+<td> </td>
+<td>3GPP (.3gp) file</td>
+</tr>
+</tbody>
+</table>
+<p>Note that the table above does not list specific bitrate requirements for
+most video codecs. The reason for this is that in practice, 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>
+
+<h2>7. Developer Tool Compatibility</h2>
+<p>Device implemenations 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="#resources19">Resources, 19</a>]<br/>
+Device implementations MUST support all <code>adb</code> functions as
+documented in the Android SDK. The device-side <code>adb</code> daemon SHOULD
+be inactive by default, but there MUST be a user-accessible mechanism to turn
+on the Android Debug Bridge.</li>
+<li><b>Dalvik Debug Monitor Service (known as ddms)</b> [<a href="#resources19">Resources, 19</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="#resources22">Resources, 22</a>]<br/>
+Device implementations MUST include the Monkey framework, and make it
+available for applications to use.</li>
+</ul>
+
+<h2>8. Hardware Compatibility</h2>
+<p>Android is intended to support device implementers creating innovative form
+factors and configurations. At the same time Android developers expect
+certain hardware, sensors and APIs across all Android device. This section
+lists the hardware features that all Android 2.1 compatible devices must
+support.</p>
+<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 defined 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>class definitions for the component's APIs MUST 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>
+</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 accurate 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.</p>
+
+<h3>8.1. Display</h3>
+<p>Android 2.1 includes facilities that perform certain automatic scaling and
+transformation operations under some circumstances, to ensure that third-party
+applications run reasonably well on a variety of hardware configurations [<a
+href="#resources23">Resources, 23</a>]. Devices MUST properly implement these
+behaviors, as detailed in this section.</p>
+<p>For Android 2.1, this are the most common display configurations:</p>
+<table><tbody>
+<tr>
+<td>Screen Type</td>
+<td>Width (Pixels)</td>
+<td>Height (Pixels)</td>
+<td>Diagonal Length Range (inches)</td>
+<td>Screen Size Group</td>
+<td>Screen Density Group</td>
+</tr>
+<tr>
+<td>QVGA</td>
+<td>240</td>
+<td>320</td>
+<td>2.6 - 3.0</td>
+<td>Small</td>
+<td>Low</td>
+</tr>
+<tr>
+<td>WQVGA</td>
+<td>240</td>
+<td>400</td>
+<td>3.2 - 3.5</td>
+<td>Normal</td>
+<td>Low</td>
+</tr>
+<tr>
+<td>FWQVGA</td>
+<td>240</td>
+<td>432</td>
+<td>3.5 - 3.8</td>
+<td>Normal</td>
+<td>Low</td>
+</tr>
+<tr>
+<td>HVGA</td>
+<td>320</td>
+<td>480</td>
+<td>3.0 - 3.5</td>
+<td>Normal</td>
+<td>Medium</td>
+</tr>
+<tr>
+<td>WVGA</td>
+<td>480</td>
+<td>800</td>
+<td>3.3 - 4.0</td>
+<td>Normal</td>
+<td>High</td>
+</tr>
+<tr>
+<td>FWVGA</td>
+<td>480</td>
+<td>854</td>
+<td>3.5 - 4.0</td>
+<td>Normal</td>
+<td>High</td>
+</tr>
+<tr>
+<td>WVGA </td>
+<td>480 </td>
+<td>800 </td>
+<td>4.8 - 5.5 </td>
+<td>Large </td>
+<td>Medium</td>
+</tr>
+<tr>
+<td>FWVGA</td>
+<td>480</td>
+<td>854</td>
+<td>5.0 - 5.8</td>
+<td>Large</td>
+<td>Medium</td>
+</tr>
+</tbody></table>
+
+<p>Device implementations corresponding to one of the standard configurations
+above MUST be configured to report the indicated screen size to applications
+via the <code>android.content.res.Configuration</code> [<a href="#resources24">Resources,
+24</a>] class.</p>
+<p>Some .apk packages have manifests that do not identify them as supporting a
+specific density range. When running such applications, the following
+constraints apply:</p>
+<ul>
+<li>Device implementations MUST interpret resources in a .apk that lack a
+density qualifier as defaulting to "medium" (known as "mdpi" in the SDK
+documentation.)</li>
+<li>When operating on a "low" density screen, device implementations MUST
+scale down medium/mdpi assets by a factor of 0.75.</li>
+<li>When operating on a "high" density screen, device implementations MUST
+scale up medium/mdpi assets by a factor of 1.5.</li>
+<li>Device implementations MUST NOT scale assets within a density range, and
+MUST scale assets by exactly these factors between density ranges.</li>
+</ul>
+
+<h4>8.1.2. Non-Standard Display Configurations</h4>
+<p>Display configurations that do not match one of the standard configurations
+listed in Section 8.1.1 require additional consideration and work to be
+compatible. Device implementers MUST contact Android Compatibility Team as
+provided for in Section 12 to obtain classifications for screen-size bucket,
+density, and scaling factor. When provided with this information, device
+implementations MUST implement them as specified.</p>
+<p>Note that some display configurations (such as very large or very small
+screens, and some aspect ratios) are fundamentally incompatible with Android
+2.1; therefore device implementers are encouraged to contact Android
+Compatibility Team as early as possible in the development process.</p>
+<h4>8.1.3. Display Metrics</h4>
+<p>Device implementations MUST report correct valuesfor all display metrics
+defined in <code>android.util.DisplayMetrics</code> [<a
+href="#resources25">Resources, 25</a>].</p>
+
+<h3>8.2. Keyboard</h3>
+<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 developer.android.com</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="#resources24">Resources, 24</a>] (that is, QWERTY, or 12-key)</li>
+</ul>
+<h3>8.3. Non-touch Navigation</h3>
+<p>Device implementations:</p>
+<ul>
+<li>MAY omit a non-touch navigation options (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="#resources24">Resources, 24</a>]</li>
+</ul>
+<h3>8.4. Screen Orientation</h3>
+<p>Compatible 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>
+
+<h3>8.5. Touchscreen input</h3>
+<p>Device implementations:</p>
+<ul>
+<li>MUST have a touchscreen</li>
+<li>MAY have either capacative or resistive touchscreen</li>
+<li>MUST report the value of <code>android.content.res.Configuration</code>
+[<a href="#resources24">Resources, 24</a>]
+reflecting corresponding to the type of the specific touchscreen on the
+device</li>
+</ul>
+
+<h3>8.6. USB</h3>
+<p>Device implementations:</p>
+<ul>
+<li>MUST implement a USB client, connectable to a USB host with a standard
+USB-A port</li>
+<li>MUST implement the Android Debug Bridge over USB (as described in Section
+7)</li>
+<li>MUST implement the USB mass storage specification, to allow a host
+connected to the device to access the contents of the /sdcard volume </li>
+<li>SHOULD use the micro USB form factor on the device side</li>
+<li>MAY include a non-standard port on the device side, but if so MUST ship
+with a cable capable of connecting the custom pinout to standard USB-A
+port</li>
+</ul>
+
+<h3>8.7. Navigation keys</h3>
+<p>The Home, Menu and Back functions are essential to the Android navigation
+paradigm. Device implementations MUST make these functions available to the
+user at all times, regardless of application state. These functions SHOULD be
+implemented via dedicated buttons. They MAY be implemented using software,
+gestures, touch panel, etc., but if so they MUST be always accessible and not
+obscure or interfere with the available application display area.</p>
+<p>Device implementers SHOULD also provide a dedicated search key. Device
+implementers MAY also provide send and end keys for phone calls.</p>
+
+<h3>8.8. Wireless Data Networking</h3>
+<p>Device implementations MUST include support for wireless high-speed data
+networking. Specifically, device implementations MUST include support for at
+least one wireless data standard capable of 200Kbit/sec or greater. Examples of
+technologies that satisfy this requirement include EDGE, HSPA, EV-DO, 802.11g, etc.</p>
+<p>If a device implementation includes a particular modality for which the
+Android SDK includes an API (that is, WiFi, GSM, or CDMA), the implementation
+MUST support the API.</p>
+<p>Devices MAY implement more than one form of wireless data connectivity.
+Devices MAY implement wired data connectivity (such as Ethernet), but MUST
+nonetheless include at least one form of wireless connectivity, as above.</p>
+<h3>8.9. Camera</h3>
+<p>Device implementations MUST include a camera. The included camera:</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>
+<p>Device implementations MUST implement the following behaviors for the
+camera-related APIs:</p>
+<ol>
+<li>If an application has never called
+android.hardware.Camera.Parameters.setPreviewFormat(int), then the device MUST
+use android.hardware.PixelFormat.YCbCr_420_SP for preview data provided to
+application callbacks.</li>
+<li>If an application registers an android.hardware.Camera.PreviewCallback
+instance and the system calls the onPreviewFrame() method when the preview
+format is YCbCr_420_SP, the data in the byte[] passed into onPreviewFrame()
+must further be in the NV21 encoding format. (This is the format used natively
+by the 7k hardware family.) That is, NV21 MUST be the default.</li>
+</ol>
+<p>Device implementations MUST implement the full Camera API included in the
+Android 2.1 SDK documentation [<a href="#resources26">Resources, 26</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.)</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>, unless the constants are
+prefixed with a string indicating the name of the device implementer. That is,
+device implementations MUST support all standard Camera parameters if the
+hardware allows, and MUST NOT support custom Camera parameter types unless
+the parameter names are clearly indicated via a string prefix to be non-standard.</p>
+
+<h3>8.10. Accelerometer</h3>
+<p>Device implementations MUST include a 3-axis accelerometer and MUST be able
+to deliver events at 50 Hz or greater. The coordinate system used by the
+accelerometer MUST comply with the Android sensor coordinate system as detailed
+in the Android APIs (see [<a href="#resources27">Resources, 27</a>]).</p>
+
+<h3>8.11. Compass</h3>
+<p>Device implementations MUST include a 3-axis compass and MUST be able to
+deliver events 10 Hz or greater. The coordinate system used by the compass
+MUST comply with the Android sensor coordinate system as defined in the Android
+API (see [<a href="#resources27">Resources, 27</a>]).</p>
+
+<h3>8.12. GPS</h3>
+<p>Device implementations MUST include a GPS, and SHOULD include some form of
+"assisted GPS" technique to minimize GPS lock-on time.</p>
+
+<h3>8.13. Telephony</h3>
+<p>Android 2.1 MAY be used on devices that do not include telephony hardware.
+That is, Android 2.1 is compatible with devices that are not phones.
+However, if a device implementation does include GSM or CDMA telephony, it
+MUST implement the 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>
+<p>See also Section 8.8, Wireless Data Networking.</p>
+
+<h3>8.14. Memory and Storage</h3>
+<p>Device implementations MUST have at least 92MB of memory available to the
+kernel and userspace. The 92MB MUST be in addition to any memory dedicated to
+hardware components such as radio, memory, and so on that is not under the
+kernel's control.</p>
+<p>Device implementations MUST have at least 150MB of non-volatile storage
+available for user data. That is, the <code>/data</code> partition must be at
+least 150MB.</p>
+<div class="cdd-erratum">Note: this section was modified by Erratum EX6580.</div>
+
+<h3>8.15. Application Shared Storage</h3>
+<p>Device implementations MUST offer shared storage for applications. The
+shared storage provided MUST be at least 2GB 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.</p>
+<p>Regardless of the form of shared storage used, the shared storage MUST
+implement USB mass storage, as described in Section 8.6. As shipped out of the
+box, the shared storage MUST be mounted with the FAT filesystem.</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 2GB 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 2GB 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>
+<div class="cdd-erratum">Note: this section was added by Erratum EX6580.</div>
+
+<h3>8.16. Bluetooth</h3>
+<p>Device implementations MUST include a Bluetooth transceiver. Device
+implementations MUST enable the RFCOMM-based Bluetooth API as described in the
+SDK documentation [<a href="#resources29">Resources, 29</a>]. Device
+implementations SHOULD implement relevant Bluetooth profiles, such as A2DP,
+AVRCP, OBEX, etc. as appropriate for the device.</p>
+<div class="cdd-erratum">Note: this section was added by Erratum EX6580.</div>
+
+<h2>9. Performance Compatibility</h2>
+<p>One of the goals of the Android Compatibility Program is to enable
+consistent application experience to consumers. Compatible implementations
+must ensure not only that applications simply run correctly on the device, but
+that they do so with reasonable performance and overall good user experience.
+Device implementations MUST meet the key performance metrics of an Android 2.1
+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>MMS/SMS: less than 700ms</li>
+<li>AlarmClock: less than 650ms</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>
+
+<h2>10. 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="#resources28">Resources, 28</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>
+<h3>10.1. Permissions</h3>
+<p>Device implementations MUST support the Android permissions model as
+defined in the Android developer documentation [<a
+href="#resources28">Resources, 28</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>
+<h3>10.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="#resources28">Resources, 28</a>].</p>
+<h3>10.3. Filesystem Permissions</h3>
+<p>Device implementations MUST support the Android file access permissions
+model as defined in as defined in the Security and Permissions reference [<a
+href="#resources28">Resources, 28</a>].</p>
+
+<h2>11. Compatibility Test Suite</h2>
+<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 2.1. Device implementations MUST pass the latest CTS version
+available at the time the device software is completed.</p>
+
+<h2>12. 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.
+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 thid-party
+applications, the device implementer MUST correct the error via a software
+update available that can be applied per the mechanism just described.</p>
+
+<h2>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>
+</body>
+</html>
diff --git a/src/compatibility/2.2/android-2.2-cdd.xhtml b/src/compatibility/2.2/android-2.2-cdd.xhtml
new file mode 100644
index 0000000..c486dc9
--- /dev/null
+++ b/src/compatibility/2.2/android-2.2-cdd.xhtml
@@ -0,0 +1,1515 @@
+<?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 2.2 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 2.2 Compatibility Definition</h1>
+<!--<span style="color: red; font-weight: bold;"><h2>DRAFT</h2></span>-->
+<p>Copyright © 2010, 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/>
+ </div>
+ </div>
+ <a href="#section-3.3">3.3. Native API Compatibility</a><br/>
+ <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. Widgets</a><br/>
+ <a href="#section-3.8.2">3.8.2. Notifications</a><br/>
+ <a href="#section-3.8.3">3.8.3. Search</a><br/>
+ <a href="#section-3.8.4">3.8.4. Toasts</a><br/>
+ <a href="#section-3.8.5">3.8.5. Live Wallpapers</a><br/>
+ </div>
+ </div>
+ <a href="#section-4">4. Reference Software Compatibility</a><br/>
+ <a href="#section-5">5. Application Packaging Compatibility</a><br/>
+ <a href="#section-6">6. Multimedia Compatibility</a><br/>
+ <div style="margin-left: 2em;">
+ <a href="#section-6.1">6.1. Media Codecs</a><br/>
+ <a href="#section-6.2">6.2. Audio Recording</a><br/>
+ <a href="#section-6.3">6.3. Audio Latency</a><br/>
+ </div>
+ <a href="#section-7">7. Developer Tool Compatibility</a><br/>
+ <a href="#section-8">8. Hardware Compatibility</a><br/>
+ <div style="margin-left: 2em;">
+ <a href="#section-8.1">8.1. Display</a><br/>
+ <div style="margin-left: 2em;">
+ <a href="#section-8.1.2">8.1.2. Non-Standard Display Configurations</a><br/>
+ <a href="#section-8.1.3">8.1.3. Display Metrics</a><br/>
+ <a href="#section-8.1.4">8.1.4. Declared Screen Support</a><br/>
+ </div>
+ <a href="#section-8.2">8.2. Keyboard</a><br/>
+ <a href="#section-8.3">8.3. Non-touch Navigation</a><br/>
+ <a href="#section-8.4">8.4. Screen Orientation</a><br/>
+ <a href="#section-8.5">8.5. Touchscreen input</a><br/>
+ <a href="#section-8.6">8.6. USB</a><br/>
+ <a href="#section-8.7">8.7. Navigation keys</a><br/>
+ <a href="#section-8.8">8.8. Wireless Data Networking</a><br/>
+ <a href="#section-8.9">8.9. Camera</a><br/>
+ <a href="#section-8.10">8.10. Accelerometer</a><br/>
+ <a href="#section-8.11">8.11. Compass</a><br/>
+ <a href="#section-8.12">8.12. GPS</a><br/>
+ <a href="#section-8.13">8.13. Telephony</a><br/>
+ <a href="#section-8.14">8.14. Memory and Storage</a><br/>
+ <a href="#section-8.15">8.15. Application Shared Storage</a><br/>
+ <a href="#section-8.16">8.16. Bluetooth</a><br/>
+ </div>
+ <a href="#section-9">9. Performance Compatibility</a><br/>
+ <a href="#section-10">10. Security Model Compatibility</a><br/>
+ <div style="margin-left: 2em;">
+ <a href="#section-10.1">10.1. Permissions</a><br/>
+ <a href="#section-10.2">10.2. UID and Process Isolation</a><br/>
+ <a href="#section-10.3">10.3. Filesystem Permissions</a><br/>
+ <a href="#section-10.4">10.4. Alternate Execution Environments</a><br/>
+ </div>
+ <a href="#section-11">11. Compatibility Test Suite</a><br/>
+ <a href="#section-12">12. Updatable Software</a><br/>
+ <a href="#section-13">13. Contact Us</a><br/>
+ <a href="#appendix-A">Appendix A - Bluetooth Test Procedure</a><br/>
+</div>
+
+<div style="page-break-before: always;"></div>
+
+<a name="section-1"></a><h2>1. Introduction</h2>
+<p>This document enumerates the requirements that must be met in order for
+mobile phones to be compatible with Android 2.2.</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
+2.2. A "device implementation" or "implementation" is the hardware/software
+solution so developed.</p>
+<p>To be considered compatible with Android 2.2, device implementations:</p>
+<ul>
+<li>MUST meet the requirements presented in this Compatibility Definition,
+including any documents incorporated via reference.</li>
+<li>MUST pass the most recent version of the Android Compatibility Test Suite
+(CTS) available at the time of the device implementation's software is
+completed. (The CTS is available as part of the Android Open Source Project [<a
+href="#resources02">Resources, 2</a>].) The CTS tests many, but not all, of the
+components outlined in this document.</li>
+</ul>
+<p>Where this definition or the CTS is silent, ambiguous, or incomplete, it is
+the responsibility of the device implementer to ensure compatibility with
+existing implementations. 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 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 CTS 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>2. Resources</h2>
+<ol>
+<a name="resources01"></a><li>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>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>Android Open Source Project: <a href="http://source.android.com/">http://source.android.com/</a></li>
+<a name="resources04"></a><li>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>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>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>Android 2.2 allowed version strings: <a href="http://source.android.com/compatibility/2.2/versions.html">http://source.android.com/compatibility/2.2/versions.html</a></li>
+<a name="resources08"></a><li>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="resources09"></a><li>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="resources10"></a><li>Dalvik Virtual Machine specification: available in the Android source code, at dalvik/docs</li>
+<a name="resources11"></a><li>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="resources12"></a><li>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="resources13"></a><li>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="resources14"></a><li>Status Bar icon style guide: <a href="http://developer.android.com/guide/practices/ui_guidelines/icon_design.html#statusbarstructure">http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure</a></li>
+<a name="resources15"></a><li>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="resources16"></a><li>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="resources17"></a><li>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="resources18"></a><li>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="resources19"></a><li>Reference tool documentation (for adb, aapt, ddms): <a href="http://developer.android.com/guide/developing/tools/index.html">http://developer.android.com/guide/developing/tools/index.html</a></li>
+<a name="resources20"></a><li>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="resources21"></a><li>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="resources22"></a><li>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="resources23"></a><li>Android 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="resources24"></a><li>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="resources25"></a><li>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="resources26"></a><li>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="resources27"></a><li>android.hardware.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="resources28"></a><li>Sensor coordinate space: <a href="http://developer.android.com/reference/android/hardware/SensorEvent.html">http://developer.android.com/reference/android/hardware/SensorEvent.html</a></li>
+<a name="resources29"></a><li>Android Security and Permissions reference: <a href="http://developer.android.com/guide/topics/security/security.html">http://developer.android.com/guide/topics/security/security.html</a></li>
+<a name="resources30"></a><li>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>
+</ol>
+<p>Many of these resources are derived directly or indirectly from the Android
+2.2 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>3. Software</h2>
+<p>The Android platform includes a set of managed APIs, a set of native APIs,
+and a body of so-called "soft" APIs such as the Intent system and
+web-application APIs. This section details the hard and soft APIs that are
+integral to compatibility, as well as certain other relevant technical and
+user interface behaviors. Device implementations MUST comply with all the
+requirements in this section.</p>
+
+<a name="section-3.1"></a><h3>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 2.2 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>
+
+<a name="section-3.2"></a><h3>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. This section details the "soft" APIs
+and system behaviors required for compatibility with Android 2.2. Device
+implementations MUST meet all the requirements presented in this section.</p>
+<a name="section-3.2.1"></a><h4>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 10 lists additional
+requirements related to the Android security model.</p>
+<a name="section-3.2.2"></a><h4>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>android.os.Build.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>android.os.Build.VERSION.SDK</td>
+<td>The version of the currently-executing Android system, in a format
+accessible to third-party application code. For Android 2.2, this field MUST have
+the integer value 8.</td>
+</tr>
+<tr>
+<td>android.os.Build.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>android.os.Build.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.
+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>android.os.Build.BRAND</td>
+<td>A value chosen by the device implementer identifying the name of the
+company, organization, individual, etc. who produced the device, in
+human-readable format. A possible use of this field is to indicate the OEM
+and/or carrier who sold the device. 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>android.os.Build.DEVICE</td>
+<td>A value chosen by the device implementer identifying the specific
+configuration or revision of the body (sometimes called "industrial design")
+of the device. 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>android.os.Build.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)/$(BOARD):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)</code><br/>
+For example:
+<br/><code>acme/mydevice/generic/generic:2.2/ERC77/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.</td>
+</tr>
+<tr>
+<td>android.os.Build.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>android.os.Build.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. 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>android.os.Build.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>android.os.Build.PRODUCT</td>
+<td>A value chosen by the device implementer containing the development name
+or code name of the device. MUST be human-readable, but is not necessarily
+intended for view by 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>android.os.Build.TAGS</td>
+<td>A comma-separated list of tags chosen by the device implementer that
+further distinguish the build. For example, "unsigned,debug". This field MUST
+NOT be null or the empty string (""), but a single tag (such as "release") is
+fine.</td>
+</tr>
+<tr>
+<td>android.os.Build.TIME</td>
+<td>A value representing the timestamp of when the build occurred.</td>
+</tr>
+<tr>
+<td>android.os.Build.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".</td>
+</tr>
+<tr>
+<td>android.os.Build.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>3.2.3. Intent Compatibility</h4>
+<p>Android uses Intents to achieve loosely-coupled integration between
+applications. This section describes requirements related to the Intent
+patterns that MUST be honored by device implementations. 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>3.2.3.1. Core Application Intents</h4>
+<p>The Android upstream project defines a number of core applications, such as
+a phone dialer, calendar, contacts book, 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>Calculator</li>
+<li>Camera</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 compontent 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>3.2.3.2. Intent Overrides</h4>
+<p>As Android is an extensible platform, device implementers MUST allow each
+Intent pattern referenced in Section 3.2.3.1 to be overridden by third-party
+applications. The upstream Android open source project 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 which
+allows the user to select between multiple applications which all handle the
+same Intent pattern.</p>
+<a name="section-3.2.3.3"></a><h4>3.2.3.3. Intent Namespaces</h4>
+<p>Device implementers 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.* 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.</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>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.3"></a><h3>3.3. Native API Compatibility</h3>
+<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. Device implementations MUST include support for code
+running in the managed environment to call into native code, using the
+standard Java Native Interface (JNI) semantics. The following APIs MUST be
+available to native code:</p>
+<ul>
+<li>libc (C library)</li>
+<li>libm (math library)</li>
+<li>JNI interface</li>
+<li>libz (Zlib compression)</li>
+<li>liblog (Android logging)</li>
+<li>Minimal support for C++</li>
+<li>Support for OpenGL, as described below</li>
+</ul>
+<p>Device implementations MUST support OpenGL ES 1.0. Devices that lack
+hardware acceleration MUST implement OpenGL ES 1.0 using a software renderer.
+Device implementations SHOULD implement as much of OpenGL ES 1.1 as the device
+hardware supports. Device implementations SHOULD provide an implementation
+for OpenGL ES 2.0, if the hardware is capable of reasonable performance on
+those APIs.</p>
+<p>These libraries MUST be source-compatible (i.e. header compatible) and
+binary-compatible (for a given processor architecture) with the versions
+provided in Bionic by the Android Open Source project. Since the Bionic
+implementations are not fully compatible with other implementations such as
+the GNU C library, device implementers SHOULD use the Android implementation.
+If device implementers use a different implementation of these libraries, they
+MUST ensure header, binary, and behavioral compatibility.</p>
+<p>Device implementations MUST accurately report the native Application Binary
+Interface (ABI) supported by the device, via the
+<code>android.os.Build.CPU_ABI</code> API. The ABI MUST be one of the entries
+documented in the latest version of the Android NDK, in the file
+<code>docs/CPU-ARCH-ABIS.txt</code>. Note that additional releases of the
+Android NDK may introduce support for additional ABIs.</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>3.4. Web Compatibility</h3>
+<p>Many developers and applications rely on the behavior of the
+<code>android.webkit.WebView</code> class [<a
+href="#resources08">Resources, 8</a>]
+for their user interfaces, so the WebView implementation must be
+compatible across Android implementations. Similarly, a full web experience is
+central to the Android user experience. Device implementations MUST include a
+version of <code>android.webkit.WebView</code> consistent with the upstream
+Android software, and MUST include a modern HTML5-capable browser, as
+described below.</p>
+<a name="section-3.4.1"></a><h4>3.4.1. WebView Compatibility</h4>
+<p>The Android Open Source implementation uses the WebKit rendering engine to
+implement the <code>android.webkit.WebView</code>. 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 WebKit in the WebView
+implementation. Specifically:</p>
+<ul>
+<li>Device implementations' <code>android.webkit.WebView</code>
+implementations MUST be based on the 533.1 WebKit build from the upstream
+Android Open Source tree for Android 2.2. This build includes a specific set
+of functionality and security fixes for the WebView. Device implementers MAY
+include customizations to the WebKit implementation; however, any such
+customizations MUST NOT alter the behavior of the WebView, including rendering
+behavior.</li>
+<li>The user agent string reported by the WebView MUST be in this format:<br/>
+ <code>Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1</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 SHOULD follow the ISO conventions for country code and language, and SHOULD refer to the current configured locale of the device</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>
+ </ul></li>
+</ul>
+<p>The WebView configuration MUST include support for the HTML5 database,
+application cache, and geolocation APIs [<a href="#resources09">Resources,
+9</a>]. The WebView MUST include support for the HTML5
+<code><video></code> tag. HTML5 APIs, like all JavaScript APIs, MUST be
+disabled by default in a WebView, unless the developer explicitly enables them
+via the usual Android APIs.</p>
+<a name="section-3.4.2"></a><h4>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 an
+browser technology other than WebKit. However, even if an alternate Browser
+application is shipped, 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="#resources09">Resources, 9</a>] as possible.
+Minimally, device implementations MUST support HTML5 geolocation, application
+cache, and database APIs and the <video> tag in standalone the Browser
+application.</p>
+
+<a name="section-3.5"></a><h3>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 meaning 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 particular permission</li>
+</ul>
+<p>The above list is not comprehensive, and the onus is on device implementers
+to ensure behavioral compatibility. 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>
+<p>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.</p>
+
+<a name="section-3.6"></a><h3>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 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.</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>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="#resources10">Resources, 10</a>].</p>
+<p>Device implementations with screens classified as medium- or low-density
+MUST configure Dalvik to allocate at least 16MB of memory to each application.
+Device implementations with screens classified as high-density MUST configure
+Dalvik to allocate at least 24MB of memory to each application. Note that
+device implementations MAY allocate more memory than these figures.</p>
+
+<a name="section-3.8"></a><h3>3.8. User Interface Compatibility</h3>
+<p>The Android platform includes some developer APIs that allow developers to
+hook into the system user interface. Device implementations MUST incorporate
+these standard UI APIs into custom user interfaces they develop, as explained
+below.</p>
+<a name="section-3.8.1"></a><h4>3.8.1. 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="#resources11">Resources, 11</a>].
+The Android Open Source reference release includes a Launcher application that
+includes user interface elements allowing the user to add, view, and remove
+AppWidgets from the home screen.</p>
+<p>Device implementers MAY substitute an alternative to the reference Launcher
+(i.e. home screen). Alternative Launchers SHOULD include built-in support for
+AppWidgets, and expose user interface elements to add, configure, view, and remove
+AppWidgets directly within the Launcher. Alternative Launchers MAY omit these
+user interface elements; however, if they are omitted, the device implementer
+MUST provide a separate application accessible from the Launcher that allows
+users to add, configure, view, and remove AppWidgets.</p>
+<a name="section-3.8.2"></a><h4>3.8.2. Notifications</h4>
+<p>Android includes APIs that allow developers to notify users of notable
+events [<a href="#resources12">Resources, 12</a>]. Device implementers MUST provide support for each
+class of notification so defined; specifically: sounds, vibration, light and
+status bar.</p>
+<p>Additionally, the implementation MUST correctly render all resources
+(icons, sound files, etc.) provided for in the APIs [<a
+href="#resources13">Resources, 13</a>], or in the
+Status Bar icon style guide [<a href="#resources14">Resources, 14</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>
+<a name="section-3.8.3"></a><h4>3.8.3. Search</h4>
+<p>Android includes APIs [<a href="#resources15">Resources, 15</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>
+<p>Device implementations MAY ship alternate search user interfaces, but
+SHOULD include a hard or soft dedicated search button, that can be used at any
+time within any app to invoke the search framework, with the behavior provided
+for in the API documentation.</p>
+<a name="section-3.8.4"></a><h4>3.8.4. Toasts</h4>
+<p>Applications can use the "Toast" API (defined in [<a
+href="#resources16">Resources, 16</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.5"></a><h4>3.8.5. 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="#resources17">Resources, 17</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-4"></a><h2>4. Reference Software Compatibility</h2>
+<p>Device implementers MUST test implementation compatibility using the
+following open-source applications:</p>
+<ul>
+<li>Calculator (included in SDK)</li>
+<li>Lunar Lander (included in SDK)</li>
+<li>The "Apps for Android" applications [<a href="#resources18">Resources, 18</a>].</li>
+<li>Replica Island (available in Android Market; only required for device
+ implementations that support with OpenGL ES 2.0)</li>
+</ul>
+<p>Each app above MUST launch and behave correctly on the implementation, for
+the implementation to be considered compatible.</p>
+<p>Additionally, device implementations MUST test each menu item (including all
+sub-menus) of each of these smoke-test applications:</p>
+<ul>
+<li>ApiDemos (included in SDK)</li>
+<li>ManualSmokeTests (included in CTS)</li>
+</ul>
+<p>Each test case in the applications above MUST run correctly on the device
+implementation.</p>
+
+<a name="section-5"></a><h2>5. 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="#resources19">Resources, 19</a>].</p>
+<p>Devices implementations MUST NOT extend either the .apk [<a
+href="#resources20">Resources, 20</a>], Android Manifest [<a
+href="#resources21">Resources, 21</a>],
+or Dalvik bytecode [<a href="#resources10">Resources, 10</a>] 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-6"></a><h2>6. Multimedia Compatibility</h2>
+<p>Device implementations MUST fully implement all multimedia APIs. Device
+implementations MUST include support for all multimedia codecs described
+below, and SHOULD meet the sound processing guidelines described below.</p>
+<a name="section-6.1"></a><h3>6.1. Media Codecs</h3>
+<p>Device implementations MUST support the following multimedia codecs. 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 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.</p>
+<table><tbody>
+<tr>
+<td rowspan="11"><b>Audio</b></td>
+</tr>
+<tr>
+<td><b>Name</b></td>
+<td><b>Encoder</b></td>
+<td><b>Decoder</b></td>
+<td><b>Details</b></td>
+<td><b>File/Container Format</b></td>
+</tr>
+<tr>
+<td>AAC LC/LTP</td>
+<td> </td>
+<td>X</td>
+<td rowspan="3">Mono/Stereo content in any combination of standard bit rates up to 160 kbps and sampling rates between 8 to 48kHz</td>
+<td rowspan="3">3GPP (.3gp) and MPEG-4 (.mp4, .m4a). No support for raw AAC (.aac)</td>
+</tr>
+<tr>
+<td>HE-AACv1 (AAC+)</td>
+<td> </td>
+<td>X</td>
+</tr>
+<tr>
+<td>HE-AACv2 (enhanced AAC+)</td>
+<td> </td>
+<td>X</td>
+</tr>
+<tr>
+<td>AMR-NB</td>
+<td>X</td>
+<td>X</td>
+<td>4.75 to 12.2 kbps sampled @ 8kHz</td>
+<td>3GPP (.3gp)</td>
+</tr>
+<tr>
+<td>AMR-WB</td>
+<td> </td>
+<td>X</td>
+<td>9 rates from 6.60 kbit/s to 23.85 kbit/s sampled @ 16kHz</td>
+<td>3GPP (.3gp)</td>
+</tr>
+<tr>
+<td>MP3</td>
+<td> </td>
+<td>X</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>X</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>Type 0 and 1 (.mid, .xmf, .mxmf). Also RTTTL/RTX (.rtttl, .rtx), OTA (.ota), and iMelody (.imy)</td>
+</tr>
+<tr>
+<td>Ogg Vorbis</td>
+<td> </td>
+<td>X</td>
+<td> </td>
+<td>Ogg (.ogg)</td>
+</tr>
+<tr>
+<td>PCM</td>
+<td> </td>
+<td>X</td>
+<td>8- and 16-bit linear PCM (rates up to limit of hardware)</td>
+<td>WAVE (.wav)</td>
+</tr>
+<tr>
+<td rowspan="5"><b>Image</b></td>
+</tr>
+<tr>
+<td>JPEG</td>
+<td>X</td>
+<td>X</td>
+<td>base+progressive</td>
+<td> </td>
+</tr>
+<tr>
+<td>GIF</td>
+<td> </td>
+<td>X</td>
+<td> </td>
+<td> </td>
+</tr>
+<tr>
+<td>PNG</td>
+<td>X</td>
+<td>X</td>
+<td> </td>
+<td> </td>
+</tr>
+<tr>
+<td>BMP</td>
+<td> </td>
+<td>X</td>
+<td> </td>
+<td> </td>
+</tr>
+<tr>
+<td rowspan="4"><b>Video</b></td>
+</tr>
+<tr>
+<td>H.263</td>
+<td>X</td>
+<td>X</td>
+<td> </td>
+<td>3GPP (.3gp) files</td>
+</tr>
+<tr>
+<td>H.264</td>
+<td> </td>
+<td>X</td>
+<td> </td>
+<td>3GPP (.3gp) and MPEG-4 (.mp4) files</td>
+</tr>
+<tr>
+<td>MPEG4 Simple Profile</td>
+<td> </td>
+<td>X</td>
+<td> </td>
+<td>3GPP (.3gp) file</td>
+</tr>
+</tbody>
+</table>
+<p>Note that the table above does not list specific bitrate requirements for
+most video codecs. The reason for this is that in practice, 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>
+
+<a name="section-6.2"></a><h3>6.2. Audio Recording</h3>
+<p>When an application has used the <code>android.media.AudioRecord</code> API to
+start recording an audio stream, device implementations SHOULD sample and
+record audio with each of these behaviors:</p>
+<ul>
+<li>Noise reduction processing, if present, SHOULD be disabled.</li>
+<li>Automatic gain control, if present, SHOULD be disabled.</li>
+<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 5000 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% from 100 Hz to 4000 Hz at
+ 90 dB SPL input level.</li>
+</ul>
+<p><b>Note:</b> while the requirements outlined above are stated as "SHOULD"
+for Android 2.2, the Compatibility Definition for a future version is planned
+to change these to "MUST". That is, these requirements are optional in Android
+2.2 but <b>will be required</b> by a future version. Existing and new devices
+that run Android 2.2 Android are <b>very strongly encouraged to meet
+these requirements in Android 2.2</b>, or they will not be able to attain
+Android compatibility when upgraded to the future version.</p>
+
+<a name="section-6.3"></a><h3>6.3. Audio Latency</h3>
+<p>Audio latency is broadly defined as the interval between when an
+application requests an audio playback or record operation, and when the
+device implementation actually begins the operation. Many classes of
+applications rely on short latencies, to achieve real-time effects such sound
+effects or VOIP communication. Device implementations SHOULD meet all audio
+latency requirements outlined in this section.</p>
+<p>For the purposes of this section:</p>
+<ul>
+<li>"cold output latency" is defined to be the interval between when an
+ application requests audio playback and when sound begins playing, when
+ the audio system has been idle and powered down prior to the request</li>
+<li>"warm output latency" is defined to be the interval between when an
+ application requests audio playback and when sound begins playing, when
+ the audio system has been recently used but is currently idle (that is,
+ silent)</li>
+<li>"continuous output latency" is defined to be the interval between when an
+ application issues a sample to be played and when the speaker physically
+ plays the corresponding sound, while the device is currently playing back
+ audio</li>
+<li>"cold input latency" is defined to be the interval between when an
+ application requests audio recording and when the first sample is
+ delivered to the application via its callback, when the audio system and
+ microphone has been idle and powered down prior to the request</li>
+<li>"continuous input latency" is defined to be when an ambient sound occurs
+ and when the sample corresponding to that sound is delivered to a
+ recording application via its callback, while the device is in recording
+ mode</li>
+</ul>
+<p>Using the above definitions, device implementations SHOULD exhibit each of
+these properties:</p>
+<ul>
+<li>cold output latency of 100 milliseconds or less</li>
+<li>warm output latency of 10 milliseconds or less</li>
+<li>continuous output latency of 45 milliseconds or less</li>
+<li>cold input latency of 100 milliseconds or less</li>
+<li>continuous input latency of 50 milliseconds or less</li>
+</ul>
+<p><b>Note:</b> while the requirements outlined above are stated as "SHOULD"
+for Android 2.2, the Compatibility Definition for a future version is planned
+to change these to "MUST". That is, these requirements are optional in Android
+2.2 but <b>will be required</b> by a future version. Existing and new devices
+that run Android 2.2 Android are <b>very strongly encouraged to meet
+these requirements in Android 2.2</b>, or they will not be able to attain
+Android compatibility when upgraded to the future version.</p>
+
+<a name="section-7"></a><h2>7. Developer Tool Compatibility</h2>
+<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="#resources19">Resources, 19</a>]<br/>
+Device implementations MUST support all <code>adb</code> functions as
+documented in the Android SDK. The device-side <code>adb</code> daemon SHOULD
+be inactive by default, but there MUST be a user-accessible mechanism to turn
+on the Android Debug Bridge.</li>
+<li><b>Dalvik Debug Monitor Service (known as ddms)</b> [<a href="#resources19">Resources, 19</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="#resources22">Resources, 22</a>]<br/>
+Device implementations MUST include the Monkey framework, and make it
+available for applications to use.</li>
+</ul>
+
+<a name="section-8"></a><h2>8. Hardware Compatibility</h2>
+<p>Android is intended to support device implementers creating innovative form
+factors and configurations. At the same time Android developers expect
+certain hardware, sensors and APIs across all Android device. This section
+lists the hardware features that all Android 2.2 compatible devices must
+support.</p>
+<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 defined 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>class definitions for the component's APIs MUST 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>
+</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="#resources23">Resources, 23</a>]</p>
+
+<a name="section-8.1"></a><h3>8.1. Display</h3>
+<p>Android 2.2 includes facilities that perform certain automatic scaling and
+transformation operations under some circumstances, to ensure that third-party
+applications run reasonably well on a variety of hardware configurations [<a
+href="#resources24">Resources, 24</a>]. Devices MUST properly implement these
+behaviors, as detailed in this section.</p>
+<p>For Android 2.2, these are the most common display configurations:</p>
+<table><tbody>
+<tr>
+<td>Screen Type</td>
+<td>Width (Pixels)</td>
+<td>Height (Pixels)</td>
+<td>Diagonal Length Range (inches)</td>
+<td>Screen Size Group</td>
+<td>Screen Density Group</td>
+</tr>
+<tr>
+<td>QVGA</td>
+<td>240</td>
+<td>320</td>
+<td>2.6 - 3.0</td>
+<td>Small</td>
+<td>Low</td>
+</tr>
+<tr>
+<td>WQVGA</td>
+<td>240</td>
+<td>400</td>
+<td>3.2 - 3.5</td>
+<td>Normal</td>
+<td>Low</td>
+</tr>
+<tr>
+<td>FWQVGA</td>
+<td>240</td>
+<td>432</td>
+<td>3.5 - 3.8</td>
+<td>Normal</td>
+<td>Low</td>
+</tr>
+<tr>
+<td>HVGA</td>
+<td>320</td>
+<td>480</td>
+<td>3.0 - 3.5</td>
+<td>Normal</td>
+<td>Medium</td>
+</tr>
+<tr>
+<td>WVGA</td>
+<td>480</td>
+<td>800</td>
+<td>3.3 - 4.0</td>
+<td>Normal</td>
+<td>High</td>
+</tr>
+<tr>
+<td>FWVGA</td>
+<td>480</td>
+<td>854</td>
+<td>3.5 - 4.0</td>
+<td>Normal</td>
+<td>High</td>
+</tr>
+<tr>
+<td>WVGA </td>
+<td>480 </td>
+<td>800 </td>
+<td>4.8 - 5.5 </td>
+<td>Large </td>
+<td>Medium</td>
+</tr>
+<tr>
+<td>FWVGA</td>
+<td>480</td>
+<td>854</td>
+<td>5.0 - 5.8</td>
+<td>Large</td>
+<td>Medium</td>
+</tr>
+
+</tbody></table>
+
+<p>Device implementations corresponding to one of the standard configurations
+above MUST be configured to report the indicated screen size to applications
+via the <code>android.content.res.Configuration</code> [<a href="#resources25">Resources,
+24</a>] class.</p>
+<p>Some .apk packages have manifests that do not identify them as supporting a
+specific density range. When running such applications, the following
+constraints apply:</p>
+<ul>
+<li>Device implementations MUST interpret resources in a .apk that lack a
+density qualifier as defaulting to "medium" (known as "mdpi" in the SDK
+documentation.)</li>
+<li>When operating on a "low" density screen, device implementations MUST
+scale down medium/mdpi assets by a factor of 0.75.</li>
+<li>When operating on a "high" density screen, device implementations MUST
+scale up medium/mdpi assets by a factor of 1.5.</li>
+<li>Device implementations MUST NOT scale assets within a density range, and
+MUST scale assets by exactly these factors between density ranges.</li>
+</ul>
+
+<a name="section-8.1.2"></a><h4>8.1.2. Non-Standard Display Configurations</h4>
+<p>Display configurations that do not match one of the standard configurations
+listed in Section 8.1.1 require additional consideration and work to be
+compatible. Device implementers MUST contact Android Compatibility Team as
+described in Section 13 to obtain classifications for screen-size bucket,
+density, and scaling factor. When provided with this information, device
+implementations MUST implement them as specified.</p>
+<p>Note that some display configurations (such as very large or very small
+screens, and some aspect ratios) are fundamentally incompatible with Android
+2.2; therefore device implementers are encouraged to contact Android
+Compatibility Team as early as possible in the development process.</p>
+
+<a name="section-8.1.3"></a><h4>8.1.3. Display Metrics</h4>
+<p>Device implementations MUST report correct valuesfor all display metrics
+defined in <code>android.util.DisplayMetrics</code> [<a
+href="#resources26">Resources, 26</a>].</p>
+
+<a name="section-8.1.4"></a><h4>8.1.4. Declared Screen Support</h4>
+<p>Applications may 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, medium, and large screens, as described in the Android
+SDK documentation.</p>
+
+<a name="section-8.2"></a><h3>8.2. Keyboard</h3>
+<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 developer.android.com</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="#resources25">Resources, 25</a>] (that is, QWERTY, or 12-key)</li>
+</ul>
+<a name="section-8.3"></a><h3>8.3. Non-touch Navigation</h3>
+<p>Device implementations:</p>
+<ul>
+<li>MAY omit a non-touch navigation options (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="#resources25">Resources, 25</a>]</li>
+</ul>
+<a name="section-8.4"></a><h3>8.4. Screen Orientation</h3>
+<p>Compatible 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>
+
+<a name="section-8.5"></a><h3>8.5. Touchscreen input</h3>
+<p>Device implementations:</p>
+<ul>
+<li>MUST have a touchscreen</li>
+<li>MAY have either capacative or resistive touchscreen</li>
+<li>MUST report the value of <code>android.content.res.Configuration</code>
+[<a href="#resources25">Resources, 25</a>]
+reflecting corresponding to the type of the specific touchscreen on the
+device</li>
+<li>SHOULD support fully independently tracked pointers, if the touchscreen supports multiple pointers</li>
+</ul>
+
+<a name="section-8.6"></a><h3>8.6. USB</h3>
+<p>Device implementations:</p>
+<ul>
+<li>MUST implement a USB client, connectable to a USB host with a standard
+USB-A port</li>
+<li>MUST implement the Android Debug Bridge over USB (as described in Section
+7)</li>
+<li>MUST implement the USB mass storage specification, to allow a host
+connected to the device to access the contents of the /sdcard volume </li>
+<li>SHOULD use the micro USB form factor on the device side</li>
+<li>MAY include a non-standard port on the device side, but if so MUST ship
+with a cable capable of connecting the custom pinout to standard USB-A
+port</li>
+<li>SHOULD implement support for the USB Mass Storage specification (so that
+either removable or fixed storage on the device can be accessed from a host
+PC)</li>
+</ul>
+
+<a name="section-8.7"></a><h3>8.7. Navigation keys</h3>
+<p>The Home, Menu and Back functions are essential to the Android navigation
+paradigm. Device implementations MUST make these functions available to the
+user at all times, regardless of application state. These functions SHOULD be
+implemented via dedicated buttons. They MAY be implemented using software,
+gestures, touch panel, etc., but if so they MUST be always accessible and not
+obscure or interfere with the available application display area.</p>
+<p>Device implementers SHOULD also provide a dedicated search key. Device
+implementers MAY also provide send and end keys for phone calls.</p>
+
+<a name="section-8.8"></a><h3>8.8. Wireless Data Networking</h3>
+<p>Device implementations MUST include support for wireless high-speed data
+networking. Specifically, device implementations MUST include support for at
+least one wireless data standard capable of 200Kbit/sec or greater. Examples of
+technologies that satisfy this requirement include EDGE, HSPA, EV-DO, 802.11g, etc.</p>
+<p>If a device implementation includes a particular modality for which the
+Android SDK includes an API (that is, WiFi, GSM, or CDMA), the implementation
+MUST support the API.</p>
+<p>Devices MAY implement more than one form of wireless data connectivity.
+Devices MAY implement wired data connectivity (such as Ethernet), but MUST
+nonetheless include at least one form of wireless connectivity, as above.</p>
+
+<a name="section-8.9"></a><h3>8.9. Camera</h3>
+<p>Device implementations MUST include a rear-facing camera. The included
+rear-facing camera:</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>
+<p>Device implementations MUST implement the following behaviors for the
+camera-related APIs:</p>
+<ol>
+<li>If an application has never called
+android.hardware.Camera.Parameters.setPreviewFormat(int), then the device MUST
+use android.hardware.PixelFormat.YCbCr_420_SP for preview data provided to
+application callbacks.</li>
+<li>If an application registers an android.hardware.Camera.PreviewCallback
+instance and the system calls the onPreviewFrame() method when the preview
+format is YCbCr_420_SP, the data in the byte[] passed into onPreviewFrame()
+must further be in the NV21 encoding format. (This is the format used natively
+by the 7k hardware family.) That is, NV21 MUST be the default.</li>
+</ol>
+<p>Device implementations MUST implement the full Camera API included in the
+Android 2.2 SDK documentation [<a href="#resources27">Resources, 27</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.)</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.</p>
+<p>Device implementations MAY include a front-facing camera. However, if
+a device implementation includes a front-facing camera, the camera API as
+implemented on the device MUST NOT use the front-facing camera by default.
+That is, the camera API in Android 2.2 is for rear-facing cameras only, and
+device implementations MUST NOT reuse or overload the API to act on a
+front-facing camera, if one is present. Note that any custom APIs added by
+device implementers to support front-facing cameras MUST abide by sections 3.5
+and 3.6; for instance, if a custom <code>android.hardware.Camera</code> or
+<code>Camera.Parameters</code> subclass is provided to support front-facing
+cameras, it MUST NOT be located in an existing namespace, as described by
+sections 3.5 and 3.6. Note that the inclusion of a front-facing camera does
+not meet the requirement that devices include a rear-facing camera.</p>
+
+<a name="section-8.10"></a><h3>8.10. Accelerometer</h3>
+<p>Device implementations MUST include a 3-axis accelerometer and MUST be able
+to deliver events at 50 Hz or greater. The coordinate system used by the
+accelerometer MUST comply with the Android sensor coordinate system as detailed
+in the Android APIs (see [<a href="#resources28">Resources, 28</a>]).</p>
+
+<a name="section-8.11"></a><h3>8.11. Compass</h3>
+<p>Device implementations MUST include a 3-axis compass and MUST be able to
+deliver events 10 Hz or greater. The coordinate system used by the compass
+MUST comply with the Android sensor coordinate system as defined in the Android
+API (see [<a href="#resources28">Resources, 28</a>]).</p>
+
+<a name="section-8.12"></a><h3>8.12. GPS</h3>
+<p>Device implementations MUST include a GPS receiver, and SHOULD include
+some form of "assisted GPS" technique to minimize GPS lock-on time.</p>
+
+<a name="section-8.13"></a><h3>8.13. Telephony</h3>
+<p>Android 2.2 MAY be used on devices that do not include telephony hardware.
+That is, Android 2.2 is compatible with devices that are not phones.
+However, if a device implementation does include GSM or CDMA telephony, it
+MUST implement the 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>
+<p>See also Section 8.8, Wireless Data Networking.</p>
+
+<a name="section-8.14"></a><h3>8.14. Memory and Storage</h3>
+<p>Device implementations MUST have at least 92MB of memory available to the
+kernel and userspace. The 92MB MUST be in addition to any memory dedicated to
+hardware components such as radio, memory, and so on that is not under the
+kernel's control.</p>
+<p>Device implementations MUST have at least 150MB of non-volatile storage
+available for user data. That is, the <code>/data</code> partition MUST be at
+least 150MB.</p>
+<p>Beyond the requirements above, device implementations SHOULD have at least
+128MB of memory available to kernel and userspace, in addition to any memory
+dedicated to hardware components that is not under the kernel's control.
+Device implementations SHOULD have at least 1GB of non-volatile storage
+available for user data. Note that these higher requirements are planned to
+become hard minimums in a future version of Android. Device implementations are
+strongly encouraged to meet these requirements now, or else they may not be
+eligible for compatibility for a future version of Android.</p>
+
+<a name="section-8.15"></a><h3>8.15. Application Shared Storage</h3>
+<p>Device implementations MUST offer shared storage for applications. The
+shared storage provided MUST be at least 2GB 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.</p>
+<p>Regardless of the form of shared storage used, the shared storage MUST
+implement USB mass storage, as described in Section 8.6. As shipped out of the
+box, the shared storage MUST be mounted with the FAT filesystem.</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 2GB 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 2GB in size or larger,
+formatted as FAT, 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) SHOULD modify the core
+applications such as the media scanner and ContentProvider to transparently
+support files placed in both locations.</p>
+
+<a name="section-8.16"></a><h3>8.16. Bluetooth</h3>
+<p>Device implementations MUST include a Bluetooth transceiver. Device
+implementations MUST enable the RFCOMM-based Bluetooth API as described in the
+SDK documentation [<a href="#resources30">Resources, 30</a>]. Device
+implementations SHOULD implement relevant Bluetooth profiles, such as A2DP,
+AVRCP, OBEX, etc. as appropriate for the device.</p>
+<p>The Compatibility Test Suite includes cases that cover basic operation of
+the Android RFCOMM Bluetooth API. However, since Bluetooth is a communications
+protocol between devices, it cannot be fully tested by unit tests running on a
+single device. Consequently, device implementations MUST also pass the
+human-driven Bluetooth test procedure described in Appendix A.</p>
+
+<a name="section-9"></a><h2>9. Performance Compatibility</h2>
+<p>One of the goals of the Android Compatibility Program is to enable
+consistent application experience to consumers. Compatible implementations
+must ensure not only that applications simply run correctly on the device, but
+that they do so with reasonable performance and overall good user experience.
+Device implementations MUST meet the key performance metrics of an Android 2.2
+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>MMS/SMS: less than 700ms</li>
+<li>AlarmClock: less than 650ms</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-10"></a><h2>10. 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="#resources29">Resources, 29</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-10.1"></a><h3>10.1. Permissions</h3>
+<p>Device implementations MUST support the Android permissions model as
+defined in the Android developer documentation [<a
+href="#resources29">Resources, 29</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-10.2"></a><h3>10.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="#resources29">Resources, 29</a>].</p>
+<a name="section-10.3"></a><h3>10.3. Filesystem Permissions</h3>
+<p>Device implementations MUST support the Android file access permissions
+model as defined in as defined in the Security and Permissions reference [<a
+href="#resources29">Resources, 29</a>].</p>
+<a name="section-10.4"></a><h3>10.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 10.</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-11"></a><h2>11. Compatibility Test Suite</h2>
+<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 2.2. Device implementations MUST pass the latest CTS version
+available at the time the device software is completed.</p>
+
+<a name="section-12"></a><h2>12. 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.
+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 thid-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-13"></a><h2>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>
+
+<a name="appendix-A"></a><h2>Appendix A - Bluetooth Test Procedure</h2>
+<p>The Compatibility Test Suite includes cases that cover basic operation of
+the Android RFCOMM Bluetooth API. However, since Bluetooth is a communications
+protocol between devices, it cannot be fully tested by unit tests running on a
+single device. Consequently, device implementations MUST also pass the
+human-driven Bluetooth test procedure described below.</p>
+<p>The test procedure is based on the BluetoothChat sample app included in the
+Android open-source project tree. The procedure requires two devices:</p>
+<ul>
+<li>a candidate device implementation running the software build to be tested</li>
+<li>a separate device implementation already known to be compatible, and of a
+ model from the device implementation being tested -- that is, a "known
+ good" device implementation</li>
+</ul>
+<p>The test procedure below refers to these devices as the "candidate" and "known
+good" devices, respectively.</p>
+<h3>Setup and Installation</h3>
+<ol>
+<li>Build BluetoothChat.apk via 'make samples' from an Android source code tree.</li>
+<li>Install BluetoothChat.apk on the known-good device.</li>
+<li>Install BluetoothChat.apk on the candidate device.</li>
+</ol>
+<h3>Test Bluetooth Control by Apps</h3>
+<ol>
+<li>Launch BluetoothChat on the candidate device, while Bluetooth is disabled.</li>
+<li>Verify that the candidate device either turns on Bluetooth, or prompts the user with a dialog to turn on Bluetooth.</li>
+</ol>
+<h3>Test Pairing and Communication</h3>
+<ol>
+<li>Launch the Bluetooth Chat app on both devices.</li>
+<li>Make the known-good device discoverable from within BluetoothChat (using the Menu).</li>
+<li>On the candidate device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the known-good device.</li>
+<li>Send 10 or more messages from each device, and verify that the other device receives them correctly.</li>
+<li>Close the BluetoothChat app on both devices by pressing <b>Home</b>.</li>
+<li>Unpair each device from the other, using the device Settings app.</li>
+</ol>
+<h3>Test Pairing and Communication in the Reverse Direction</h3>
+<ol>
+<li>Launch the Bluetooth Chat app on both devices.</li>
+<li>Make the candidate device discoverable from within BluetoothChat (using the Menu).</li>
+<li>On the known-good device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the candidate device.</li>
+<li>Send 10 or messages from each device, and verify that the other device receives them correctly.</li>
+<li>Close the Bluetooth Chat app on both devices by pressing Back repeatedly to get to the Launcher.</li>
+</ol>
+<h3>Test Re-Launches</h3>
+<ol>
+<li>Re-launch the Bluetooth Chat app on both devices.</li>
+<li>Send 10 or messages from each device, and verify that the other device receives them correctly.</li>
+</ol>
+<p>Note: the above tests have some cases which end a test section by using
+Home, and some using Back. These tests are not redundant and are not optional:
+the objective is to verify that the Bluetooth API and stack works correctly
+both when Activities are explicitly terminated (via the user pressing Back,
+which calls finish()), and implicitly sent to background (via the user
+pressing Home.) Each test sequence MUST be performed as described.</p>
+<div id="footerContent">
+<pdf:pagenumber/>
+</div>
+</body>
+</html>
diff --git a/src/compatibility/2.3/android-2.3-cdd.xhtml b/src/compatibility/2.3/android-2.3-cdd.xhtml
new file mode 100644
index 0000000..fd6ed7c
--- /dev/null
+++ b/src/compatibility/2.3/android-2.3-cdd.xhtml
@@ -0,0 +1,1866 @@
+<?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 2.3 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 2.3 Compatibility Definition</h1>
+<!-- <span style="color: red; font-weight: bold;"><h2>DRAFT</h2></span> -->
+<p>Copyright © 2010, 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.3">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/>
+ </div>
+ </div>
+ <a href="#section-3.3">3.3. Native API Compatibility</a><br/>
+ <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. Widgets</a><br/>
+ <a href="#section-3.8.2">3.8.2. Notifications</a><br/>
+ <a href="#section-3.8.3">3.8.3. Search</a><br/>
+ <a href="#section-3.8.4">3.8.4. Toasts</a><br/>
+ <a href="#section-3.8.5">3.8.5. Live Wallpapers</a><br/>
+ </div>
+ </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.1.1">5.1.1. Media Decoders</a><br/>
+ <a href="#section-5.1.2">5.1.2. Media Encoders</a><br/>
+ <a href="#section-5.2">5.2. Audio Recording</a><br/>
+ <a href="#section-5.3">5.3. Audio Latency</a><br/>
+ </div>
+ <a href="#section-6">6. Developer Tool Compatibility</a><br/>
+ <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 Configurations</a><br/>
+ <a href="#section-7.1.2">7.1.2. Display Metrics</a><br/>
+ <a href="#section-7.1.3">7.1.3. Declared Screen Support</a><br/>
+ <a href="#section-7.1.4">7.1.4. Screen Orientation</a><br/>
+ <a href="#section-7.1.5">7.1.5. 3D Graphics Accleration</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/>
+ </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 (WiFi)</a><br/>
+ <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/>
+ </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. Application Shared 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/>
+ </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. Contact Us</a><br/>
+ <a href="#appendix-A">Appendix A - Bluetooth Test Procedure</a><br/>
+</div>
+
+<div style="page-break-before: always;"></div>
+
+<a name="section-1"></a><h2>1. Introduction</h2>
+<p>This document enumerates the requirements that must be met in order for
+mobile phones to be compatible with Android 2.3.</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
+2.3. A "device implementation" or "implementation" is the hardware/software
+solution so developed.</p>
+<p>To be considered compatible with Android 2.3, 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. 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>
+<p>Please note that this Compatibility Definition is issued to correspond with
+the 2.3.3 update to Android, which is API level 10. This Definition obsoletes
+and replaces the Compatibility Definition for Android 2.3 versions prior to
+2.3.3. (That is, versions 2.3.1 and 2.3.2 are obsolete.) Future
+Android-compatible devices running Android 2.3 MUST ship with version 2.3.3 or
+later.</p>
+<a name="section-2"></a><h2>2. Resources</h2>
+<ol>
+<a name="resources01"></a><li>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>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>Android Open Source Project: <a href="http://source.android.com/">http://source.android.com/</a></li>
+<a name="resources04"></a><li>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>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>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>Android 2.3 allowed version strings: <a href="http://source.android.com/compatibility/2.3/versions.html">http://source.android.com/compatibility/2.3/versions.html</a></li>
+<a name="resources08"></a><li>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="resources09"></a><li>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="resources10"></a><li>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="resources11"></a><li>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="resources12"></a><li>HTML5/W3C geolocation API: <a href="http://www.w3.org/TR/geolocation-API/">http://www.w3.org/TR/geolocation-API/</a></li>
+<a name="resources13"></a><li>HTML5/W3C webdatabase API: <a href="http://www.w3.org/TR/webdatabase/">http://www.w3.org/TR/webdatabase/</a></li>
+<a name="resources14"></a><li>HTML5/W3C IndexedDB API: <a href="http://www.w3.org/TR/IndexedDB/">http://www.w3.org/TR/IndexedDB/</a></li>
+<a name="resources15"></a><li>Dalvik Virtual Machine specification: available in the Android source code, at dalvik/docs</li>
+<a name="resources16"></a><li>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="resources17"></a><li>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="resources18"></a><li>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="resources19"></a><li>Status Bar icon style guide: <a href="http://developer.android.com/guide/practices/ui_guidelines/icon_design.html#statusbarstructure">http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure</a></li>
+<a name="resources20"></a><li>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="resources21"></a><li>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="resources22"></a><li>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="resources23"></a><li>Reference tool documentation (for adb, aapt, ddms): <a href="http://developer.android.com/guide/developing/tools/index.html">http://developer.android.com/guide/developing/tools/index.html</a></li>
+<a name="resources24"></a><li>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="resources25"></a><li>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="resources26"></a><li>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="resources27"></a><li>Android 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="resources28"></a><li>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="resources29"></a><li>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="resources30"></a><li>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="resources31"></a><li>Sensor coordinate space: <a href="http://developer.android.com/reference/android/hardware/SensorEvent.html">http://developer.android.com/reference/android/hardware/SensorEvent.html</a></li>
+<a name="resources32"></a><li>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="resources33"></a><li>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="resources34"></a><li>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="resources35"></a><li>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="resources36"></a><li>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="resources37"></a><li>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="resources38"></a><li>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="resources39"></a><li>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="resources40"></a><li>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="resources41"></a><li>android.hardware.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="resources42"></a><li>Android Security and Permissions reference: <a href="http://developer.android.com/guide/topics/security/security.html">http://developer.android.com/guide/topics/security/security.html</a></li>
+<a name="resources43"></a><li>Apps for Android: <a href="http://code.google.com/p/apps-for-android">http://code.google.com/p/apps-for-android</a></li>
+</ol>
+<p>Many of these resources are derived directly or indirectly from the Android
+2.3 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>3. Software</h2>
+<p>The Android platform includes a set of managed APIs, a set of native APIs,
+and a body of so-called "soft" APIs such as the Intent system and
+web-application APIs. This section details the hard and soft APIs that are
+integral to compatibility, as well as certain other relevant technical and
+user interface behaviors. Device implementations MUST comply with all the
+requirements in this section.</p>
+
+<a name="section-3.1"></a><h3>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 2.3 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 Section 7
+for specific requirements for this scenario.</p>
+
+<a name="section-3.2"></a><h3>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. This section details the "soft" APIs
+and system behaviors required for compatibility with Android 2.3. Device
+implementations MUST meet all the requirements presented in this section.</p>
+<a name="section-3.2.1"></a><h4>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 10 lists additional
+requirements related to the Android security model.</p>
+<a name="section-3.2.3"></a><h4>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>android.os.Build.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>android.os.Build.VERSION.SDK</td>
+<td>The version of the currently-executing Android system, in a format
+accessible to third-party application code. For Android 2.3, this field MUST have
+the integer value 9.</td>
+</tr>
+<tr>
+<td>android.os.Build.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>android.os.Build.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>android.os.Build.BRAND</td>
+<td>A value chosen by the device implementer identifying the name of the
+company, organization, individual, etc. who produced the device, in
+human-readable format. A possible use of this field is to indicate the OEM
+and/or carrier who sold 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>android.os.Build.DEVICE</td>
+<td>A value chosen by the device implementer identifying the specific
+configuration or revision of the body (sometimes called "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>android.os.Build.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/mydevice/generic/generic:2.3/ERC77/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>android.os.Build.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>android.os.Build.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>android.os.Build.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>android.os.Build.PRODUCT</td>
+<td>A value chosen by the device implementer containing the development name
+or code name of the device. 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>android.os.Build.TAGS</td>
+<td>A comma-separated list of tags chosen by the device implementer that
+further distinguish 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>android.os.Build.TIME</td>
+<td>A value representing the timestamp of when the build occurred.</td>
+</tr>
+<tr>
+<td>android.os.Build.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>android.os.Build.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>3.2.3. Intent Compatibility</h4>
+<p>Android uses Intents to achieve loosely-coupled integration between
+applications. This section describes requirements related to the Intent
+patterns that MUST be honored by device implementations. 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>3.2.3.1. Core Application Intents</h4>
+<p>The Android upstream project defines a number of core applications, such as
+a phone dialer, calendar, contacts book, 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>Calculator</li>
+<!-- <li>Camera</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 compontent 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>3.2.3.2. Intent Overrides</h4>
+<p>As Android is an extensible platform, device implementers MUST allow each
+Intent pattern referenced in Section 3.2.3.1 to be overridden by third-party
+applications. The upstream Android open source project 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 which
+allows the user to select between multiple applications which all handle the
+same Intent pattern.</p>
+<a name="section-3.2.3.3"></a><h4>3.2.3.3. Intent Namespaces</h4>
+<p>Device implementers 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.* 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.</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>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.3"></a><h3>3.3. Native API Compatibility</h3>
+<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.txt</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</li>
+<li>MUST report only those ABIs documented in the latest version of the
+Android NDK, in the file <code>docs/CPU-ARCH-ABIS.txt</code></li>
+<li>SHOULD be built using the source code and header files available in the
+upstream Android open-source project</li>
+</ul>
+<p>The following native code APIs MUST be available to apps that include
+native code:</p>
+<ul>
+<li>libc (C library)</li>
+<li>libm (math library)</li>
+<li>Minimal support for C++</li>
+<li>JNI interface</li>
+<li>liblog (Android logging)</li>
+<li>libz (Zlib compression)</li>
+<li>libdl (dynamic linker)</li>
+<li>libGLESv1_CM.so (OpenGL ES 1.0)</li>
+<li>libGLESv2.so (OpenGL ES 2.0)</li>
+<li>libEGL.so (native OpenGL surface management)</li>
+<li>libjnigraphics.so</li>
+<li>libOpenSLES.so (Open Sound Library audio 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>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>3.4. Web Compatibility</h3>
+<p>Many developers and applications rely on the behavior of the
+<code>android.webkit.WebView</code> class [<a
+href="#resources08">Resources, 8</a>]
+for their user interfaces, so the WebView implementation must be
+compatible across Android implementations. Similarly, a complete, modern web
+broswer is central to the Android user experience. Device implementations MUST
+include a version of <code>android.webkit.WebView</code> consistent with the
+upstream Android software, and MUST include a modern HTML5-capable browser, as
+described below.</p>
+<a name="section-3.4.1"></a><h4>3.4.1. WebView Compatibility</h4>
+<p>The Android Open Source implementation uses the WebKit rendering engine to
+implement the <code>android.webkit.WebView</code>. 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 WebKit in the WebView
+implementation. Specifically:</p>
+<ul>
+<li>Device implementations' <code>android.webkit.WebView</code>
+implementations MUST be based on the 533.1 WebKit build from the upstream
+Android Open Source tree for Android 2.3. This build includes a specific set
+of functionality and security fixes for the WebView. Device implementers MAY
+include customizations to the WebKit implementation; however, any such
+customizations MUST NOT alter the behavior of the WebView, including rendering
+behavior.</li>
+<li>The user agent string reported by the WebView MUST be in this format:<br/>
+ <code>Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1</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 SHOULD follow the ISO conventions for country code and language, and SHOULD refer to the current configured locale of the device</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>
+ </ul></li>
+</ul>
+<p>The WebView component SHOULD include support for as much of HTML5 [<a
+href="#resources09">Resources, 9</a>] as possible.
+Minimally, device implementations MUST support each of these APIs associated
+with HTML5 in the WebView:</p>
+<ul>
+<li>application cache/offline operation [<a href="#resources10">Resources, 10</a>]</li>
+<li>the <video> tag [<a href="#resources11">Resources, 11</a>]</li>
+<li>geolocation [<a href="#resources12">Resources, 12</a>]</li>
+</ul>
+<p>Additionally, device implementations MUST support the HTML5/W3C webstorage
+API [<a href="#resources13">Resources, 13</a>], and SHOULD support the
+HTML5/W3C IndexedDB API [<a href="#resources14">Resources, 14</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>
+<p>HTML5 APIs, like all JavaScript APIs, MUST be disabled by default in a
+WebView, unless the developer explicitly enables them via the usual Android
+APIs.</p>
+
+<a name="section-3.4.2"></a><h4>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="#resources09">Resources, 9</a>] as possible.
+Minimally, device implementations MUST support each of these APIs associated
+with HTML5:</p>
+<ul>
+<li>application cache/offline operation [<a href="#resources10">Resources, 10</a>]</li>
+<li>the <video> tag [<a href="#resources11">Resources, 11</a>]</li>
+<li>geolocation [<a href="#resources12">Resources, 12</a>]</li>
+</ul>
+<p>Additionally, device implementations MUST support the HTML5/W3C webstorage
+API [<a href="#resources13">Resources, 13</a>], and SHOULD support the
+HTML5/W3C IndexedDB API [<a href="#resources14">Resources, 14</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>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>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>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="#resources15">Resources, 15</a>].</p>
+<p>Device implementations with screens classified as medium- or low-density
+MUST configure Dalvik to allocate at least 16MB of memory to each application.
+Device implementations with screens classified as high-density or
+extra-high-density MUST configure Dalvik to allocate at least 24MB of memory
+to each application. Note that device implementations MAY allocate more memory
+than these figures.</p>
+
+<a name="section-3.8"></a><h3>3.8. User Interface Compatibility</h3>
+<p>The Android platform includes some developer APIs that allow developers to
+hook into the system user interface. Device implementations MUST incorporate
+these standard UI APIs into custom user interfaces they develop, as explained
+below.</p>
+<a name="section-3.8.1"></a><h4>3.8.1. 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="#resources16">Resources, 16</a>].
+The Android Open Source reference release includes a Launcher application that
+includes user interface elements allowing the user to add, view, and remove
+AppWidgets from the home screen.</p>
+<p>Device implementers MAY substitute an alternative to the reference Launcher
+(i.e. home screen). Alternative Launchers SHOULD include built-in support for
+AppWidgets, and expose user interface elements to add, configure, view, and remove
+AppWidgets directly within the Launcher. Alternative Launchers MAY omit these
+user interface elements; however, if they are omitted, the device implementer
+MUST provide a separate application accessible from the Launcher that allows
+users to add, configure, view, and remove AppWidgets.</p>
+<a name="section-3.8.2"></a><h4>3.8.2. Notifications</h4>
+<p>Android includes APIs that allow developers to notify users of notable
+events [<a href="#resources17">Resources, 17</a>]. Device implementers MUST provide support for each
+class of notification so defined; specifically: sounds, vibration, light and
+status bar.</p>
+<p>Additionally, the implementation MUST correctly render all resources
+(icons, sound files, etc.) provided for in the APIs [<a
+href="#resources18">Resources, 18</a>], or in the
+Status Bar icon style guide [<a href="#resources19">Resources, 19</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>
+<a name="section-3.8.3"></a><h4>3.8.3. Search</h4>
+<p>Android includes APIs [<a href="#resources20">Resources, 20</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>
+<p>Device implementations MAY ship alternate search user interfaces, but
+SHOULD include a hard or soft dedicated search button, that can be used at any
+time within any app to invoke the search framework, with the behavior provided
+for in the API documentation.</p>
+<a name="section-3.8.4"></a><h4>3.8.4. Toasts</h4>
+<p>Applications can use the "Toast" API (defined in [<a
+href="#resources21">Resources, 21</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.5"></a><h4>3.8.5. 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="#resources22">Resources, 22</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-4"></a><h2>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="#resources23">Resources, 23</a>].</p>
+<p>Devices implementations MUST NOT extend either the .apk [<a
+href="#resources24">Resources, 24</a>], Android Manifest [<a
+href="#resources25">Resources, 25</a>],
+or Dalvik bytecode [<a href="#resources15">Resources, 15</a>] 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>5. Multimedia Compatibility</h2>
+<p>Device implementations MUST fully implement all multimedia APIs. Device
+implementations MUST include support for all multimedia codecs described
+below, and SHOULD meet the sound processing guidelines described below. 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>5.1. Media Codecs</h3>
+<p>Device implementations MUST support the multimedia codecs as detailed in
+the following sections. 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 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.</p>
+<p>The tables below do not list specific bitrate requirements for
+most video codecs. The reason for this is that in practice, 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>
+<a name="section-5.1.1"></a><h3>5.1.1. Media Decoders</h3>
+<p>Device implementations MUST include an implementation of an decoder for
+each codec and format described in the table below. Note that decoders for
+each of these media types are provided by the upstream Android Open-Source
+Project.</p>
+<table><tbody>
+<tr>
+<td rowspan="11"><b>Audio</b></td>
+</tr>
+<tr>
+<td><b>Name</b></td>
+<td><b>Details</b></td>
+<td><b>File/Container Format</b></td>
+</tr>
+<tr>
+<td>AAC LC/LTP</td>
+<td rowspan="3">Mono/Stereo content in any combination of standard bit rates up to 160 kbps and sampling rates between 8 to 48kHz</td>
+<td rowspan="3">3GPP (.3gp) and MPEG-4 (.mp4, .m4a). No support for raw AAC (.aac)</td>
+</tr>
+<tr>
+<td>HE-AACv1 (AAC+)</td>
+</tr>
+<tr>
+<td>HE-AACv2 (enhanced AAC+)</td>
+</tr>
+<tr>
+<td>AMR-NB</td>
+<td>4.75 to 12.2 kbps sampled @ 8kHz</td>
+<td>3GPP (.3gp)</td>
+</tr>
+<tr>
+<td>AMR-WB</td>
+<td>9 rates from 6.60 kbit/s to 23.85 kbit/s sampled @ 16kHz</td>
+<td>3GPP (.3gp)</td>
+</tr>
+<tr>
+<td>MP3</td>
+<td>Mono/Stereo 8-320Kbps constant (CBR) or variable bit-rate (VBR)</td>
+<td>MP3 (.mp3)</td>
+</tr>
+<tr>
+<td>MIDI</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>Type 0 and 1 (.mid, .xmf, .mxmf). Also RTTTL/RTX (.rtttl, .rtx), OTA (.ota), and iMelody (.imy)</td>
+</tr>
+<tr>
+<td>Ogg Vorbis</td>
+<td> </td>
+<td>Ogg (.ogg)</td>
+</tr>
+<tr>
+<td>PCM</td>
+<td>8- and 16-bit linear PCM (rates up to limit of hardware)</td>
+<td>WAVE (.wav)</td>
+</tr>
+<tr>
+<td rowspan="5"><b>Image</b></td>
+</tr>
+<tr>
+<td>JPEG</td>
+<td>base+progressive</td>
+<td> </td>
+</tr>
+<tr>
+<td>GIF</td>
+<td> </td>
+<td> </td>
+</tr>
+<tr>
+<td>PNG</td>
+<td> </td>
+<td> </td>
+</tr>
+<tr>
+<td>BMP</td>
+<td> </td>
+<td> </td>
+</tr>
+<tr>
+<td rowspan="4"><b>Video</b></td>
+</tr>
+<tr>
+<td>H.263</td>
+<td> </td>
+<td>3GPP (.3gp) files</td>
+</tr>
+<tr>
+<td>H.264</td>
+<td> </td>
+<td>3GPP (.3gp) and MPEG-4 (.mp4) files</td>
+</tr>
+<tr>
+<td>MPEG4 Simple Profile</td>
+<td> </td>
+<td>3GPP (.3gp) file</td>
+</tr>
+</tbody>
+</table>
+
+<a name="section-5.1.2"></a><h3>5.1.2. Media Encoders</h3>
+<p>Device implementations SHOULD include encoders for as many of the media
+formats listed in Section 5.1.1. as possible. However, some encoders do not
+make sense for devices that lack certain optional hardware; for instance,
+an encoder for the H.263 video does not make sense, if the device lacks any
+cameras. Device implementations MUST therefore implement media encoders
+according to the conditions described in the table below.</p>
+<p>See Section 7 for details on the conditions under which hardware may be
+omitted by device implementations.</p>
+<table><tbody>
+<tr>
+<td rowspan="5"><b>Audio</b></td>
+</tr>
+<tr>
+<td><b>Name</b></td>
+<td><b>Details</b></td>
+<td><b>File/Container Format</b></td>
+<td><b>Conditions</b></td>
+</tr>
+<tr>
+<td>AMR-NB</td>
+<td>4.75 to 12.2 kbps sampled @ 8kHz</td>
+<td>3GPP (.3gp)</td>
+<td rowspan="3">Device implementations that include microphone hardware and define
+<code>android.hardware.microphone</code> MUST include encoders for these audio
+formats.</td>
+</tr>
+<tr>
+<td>AMR-WB</td>
+<td>9 rates from 6.60 kbit/s to 23.85 kbit/s sampled @ 16kHz</td>
+<td>3GPP (.3gp)</td>
+</tr>
+<tr>
+<td>AAC LC/LTP</td>
+<td rowspan="1">Mono/Stereo content in any combination of standard bit rates up to 160 kbps and sampling rates between 8 to 48kHz</td>
+<td rowspan="1">3GPP (.3gp) and MPEG-4 (.mp4, .m4a).</td>
+</tr>
+<tr>
+<td rowspan="2"><b>Image</b></td>
+<td>JPEG</td>
+<td>base+progressive</td>
+<td> </td>
+<td rowspan="2">All device implementations MUST include encoders for these
+image formats, as Android 2.3 includes APIs that applications can use to
+programmatically generate files of these types.</td>
+</tr>
+<tr>
+<td>PNG</td>
+<td> </td>
+<td> </td>
+</tr>
+<tr>
+<td><b>Video</b></td>
+<td>H.263</td>
+<td> </td>
+<td>3GPP (.3gp) files</td>
+<td>Device implementations that include camera hardware and define
+either <code>android.hardware.camera</code> or
+<code>android.hardware.camera.front</code> MUST include encoders for these
+video formats.</td>
+</tr>
+</tbody>
+</table>
+<p>In addition to the encoders listed above, device implementations SHOULD include an H.264
+encoder. Note that the Compatibility Definition for a future version is planned
+to change this requirement to "MUST". That is, H.264 encoding is optional in Android
+2.3 but <b>will be required</b> by a future version. Existing and new devices
+that run Android 2.3 are <b>very strongly encouraged to meet
+this requirement in Android 2.3</b>, or they will not be able to attain
+Android compatibility when upgraded to the future version.</p>
+
+<a name="section-5.2"></a><h3>5.2. Audio Recording</h3>
+<p>When an application has used the <code>android.media.AudioRecord</code> API to
+start recording an audio stream, device implementations SHOULD sample and
+record audio with each of these behaviors:</p>
+<ul>
+<li>Noise reduction processing, if present, SHOULD be disabled.</li>
+<li>Automatic gain control, if present, SHOULD be disabled.</li>
+<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 5000 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% from 100 Hz to 4000 Hz at
+ 90 dB SPL input level.</li>
+</ul>
+<p><b>Note:</b> while the requirements outlined above are stated as "SHOULD"
+for Android 2.3, the Compatibility Definition for a future version is planned
+to change these to "MUST". That is, these requirements are optional in Android
+2.3 but <b>will be required</b> by a future version. Existing and new devices
+that run Android 2.3 are <b>very strongly encouraged to meet
+these requirements in Android 2.3</b>, or they will not be able to attain
+Android compatibility when upgraded to the future version.</p>
+
+<a name="section-5.3"></a><h3>5.3. Audio Latency</h3>
+<p>Audio latency is broadly defined as the interval between when an
+application requests an audio playback or record operation, and when the
+device implementation actually begins the operation. Many classes of
+applications rely on short latencies, to achieve real-time effects such sound
+effects or VOIP communication. Device implementations that include microphone
+hardware and declare <code>android.hardware.microphone</code> SHOULD meet all
+audio latency requirements outlined in this section. See Section 7 for
+details on the conditions under which microphone hardware may be omitted by
+device implementations.</p>
+<p>For the purposes of this section:</p>
+<ul>
+<li>"cold output latency" is defined to be the interval between when an
+ application requests audio playback and when sound begins playing, when
+ the audio system has been idle and powered down prior to the request</li>
+<li>"warm output latency" is defined to be the interval between when an
+ application requests audio playback and when sound begins playing, when
+ the audio system has been recently used but is currently idle (that is,
+ silent)</li>
+<li>"continuous output latency" is defined to be the interval between when an
+ application issues a sample to be played and when the speaker physically
+ plays the corresponding sound, while the device is currently playing back
+ audio</li>
+<li>"cold input latency" is defined to be the interval between when an
+ application requests audio recording and when the first sample is
+ delivered to the application via its callback, when the audio system and
+ microphone has been idle and powered down prior to the request</li>
+<li>"continuous input latency" is defined to be when an ambient sound occurs
+ and when the sample corresponding to that sound is delivered to a
+ recording application via its callback, while the device is in recording
+ mode</li>
+</ul>
+<p>Using the above definitions, device implementations SHOULD exhibit each of
+these properties:</p>
+<ul>
+<li>cold output latency of 100 milliseconds or less</li>
+<li>warm output latency of 10 milliseconds or less</li>
+<li>continuous output latency of 45 milliseconds or less</li>
+<li>cold input latency of 100 milliseconds or less</li>
+<li>continuous input latency of 50 milliseconds or less</li>
+</ul>
+<p><b>Note:</b> while the requirements outlined above are stated as "SHOULD"
+for Android 2.3, the Compatibility Definition for a future version is planned
+to change these to "MUST". That is, these requirements are optional in Android
+2.3 but <b>will be required</b> by a future version. Existing and new devices
+that run Android 2.3 are <b>very strongly encouraged to meet
+these requirements in Android 2.3</b>, or they will not be able to attain
+Android compatibility when upgraded to the future version.</p>
+<p>If a device implementation meets the requirements of this section, 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="#resources27">Resources, 27</a>] Conversely, if the device
+implementation does not meet these requirements it MUST NOT report support for
+low-latency audio.</p>
+
+<a name="section-6"></a><h2>6. Developer Tool Compatibility</h2>
+<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="#resources23">Resources, 23</a>]<br/>
+Device implementations MUST support all <code>adb</code> functions as
+documented in the Android SDK. The device-side <code>adb</code> daemon SHOULD
+be inactive by default, but there MUST be a user-accessible mechanism to turn
+on the Android Debug Bridge.</li>
+<li><b>Dalvik Debug Monitor Service (known as ddms)</b> [<a href="#resources23">Resources, 23</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="#resources26">Resources, 26</a>]<br/>
+Device implementations MUST include the Monkey framework, and make it
+available for applications to use.</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, and Windows 7, in both 32-bit and
+64-bit versions.</p>
+
+<a name="section-7"></a><h2>7. Hardware Compatibility</h2>
+<p>Android is intended to enable device implementers to create innovative form
+factors and configurations. At the same time Android developers write
+innovative applications that rely on the various hardware and features
+available through the Android APIs. The requirements in this section strike a
+balance between innovations available to device implementers, and the needs of
+developers to ensure their apps are only available to devices where they will
+run properly.</p>
+<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="#resources27">Resources, 27</a>]</p>
+
+<a name="section-7.1"></a><h3>7.1. Display and Graphics</h3>
+<p>Android 2.3 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="#resources28">Resources, 28</a>]. Devices MUST properly implement these
+APIs and behaviors, as detailed in this section.</p>
+<a name="section-7.1.1"></a><h4>7.1.1. Screen Configurations</h4>
+<p>Device implementations MAY use screens of any pixel dimensions, provided
+that they meet the following requirements:</p>
+<ul>
+<li>screens MUST be at least 2.5 inches in physical diagonal size</li>
+<li>density MUST be at least 100 dpi</li>
+<li>the aspect ratio MUST be between 1.333 (4:3) and 1.779 (16:9)</li>
+<li>the display technology used consists of square pixels</li>
+</ul>
+<p>Device implementations with a screen meeting the requirements above are
+considered compatible, and no additional action is necessary. The Android
+framework implementation automatically computes display characteristics such
+as screen size bucket and density bucket. In the majority of cases, the
+framework decisions are the correct ones. If the default framework
+computations are used, no additional action is necessary. Device implementers
+wishing to change the defaults, or use a screen that does not meet the
+requirements above MUST contact the Android Compatibility Team for guidance,
+as provided for in Section 12.</p>
+<p>The units used by the requirements above 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>
+</ul>
+<p>Device implementations MUST use only displays with a single static
+configuration. That is, device implementations MUST NOT enable multiple
+screen configurations. For instance, since a typical television supports
+multiple resolutions such as 1080p, 720p, and so on, this configuration is not
+compatible with Android 2.3. (However, support for such configurations is
+under investigation and planned for a future version of Android.)</p>
+<a name="section-7.1.2"></a><h4>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="#resources29">Resources, 29</a>].</p>
+<a name="section-7.1.3"></a><h4>7.1.3. Declared Screen Support</h4>
+<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, medium, and large screens, as described in the Android
+SDK documentation.</p>
+<a name="section-7.1.4"></a><h4>7.1.4. Screen Orientation</h4>
+<p>Compatible 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. Devices that cannot be physically rotated MAY meet this requirement
+by "letterboxing" applications that request portrait mode, using only a
+portion of the available display.</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>
+<a name="section-7.1.5"></a><h4>7.1.5. 3D Graphics Acceleration</h4>
+<p>Device implementations MUST support OpenGL ES 1.0, as required by the
+Android 2.3 APIs. For devices that lack 3D acceleration hardware, a software
+implementation of OpenGL ES 1.0 is provided by the upstream Android
+Open-Source Project. Device implementations SHOULD support OpenGL ES 2.0.</p>
+<p>Implementations MAY omit Open GL ES 2.0 support; however if support is
+ommitted, device implementations MUST NOT report as supporting OpenGL ES 2.0.
+Specifically, if a device implementations lacks OpenGL ES 2.0 support:</p>
+<ul>
+<li>the managed APIs (such as via the <code>GLES10.getString()</code> method)
+MUST NOT report support for 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 NOT report support for
+OpenGL ES 2.0.</li>
+</ul>
+<p>Conversely, if a device implementation <i>does</i> support OpenGL ES 2.0,
+it MUST accurately report that support via the routes just listed.</p>
+<p>Note that Android 2.3 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 2.3 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>
+
+<a name="section-7.2"></a><h3>7.2. Input Devices</h3>
+<p>Android 2.3 supports a number of modalities for user input. Device
+implementations MUST support user input devices as provided for in this
+section.</p>
+<a name="section-7.2.1"></a><h4>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 developer.android.com</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="#resources30">Resources, 30</a>] (that is, QWERTY, or 12-key)</li>
+</ul>
+<a name="section-7.2.2"></a><h4>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="#resources30">Resources, 30</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 code 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>7.2.3. Navigation keys</h4>
+<p>The Home, Menu and Back functions are essential to the Android navigation
+paradigm. Device implementations MUST make these functions available to the
+user at all times, regardless of application state. These functions SHOULD be
+implemented via dedicated buttons. They MAY be implemented using software,
+gestures, touch panel, etc., but if so they MUST be always accessible and not
+obscure or interfere with the available application display area.</p>
+<p>Device implementers SHOULD also provide a dedicated search key. Device
+implementers MAY also provide send and end keys for phone calls.</p>
+<a name="section-7.2.4"></a><h4>7.2.4. Touchscreen input</h4>
+<p>Device implementations:</p>
+<ul>
+<li>MUST have a touchscreen</li>
+<li>MAY have either capacitive or resistive touchscreen</li>
+<li>MUST report the value of <code>android.content.res.Configuration</code>
+[<a href="#resources30">Resources, 30</a>]
+reflecting corresponding to the type of the specific touchscreen on the
+device</li>
+<li>SHOULD support fully independently tracked pointers, if the touchscreen supports multiple pointers</li>
+</ul>
+
+<a name="section-7.3"></a><h3>7.3. Sensors</h3>
+<p>Android 2.3 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="#resources27">Resources, 27</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>
+</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>The Android 2.3 APIs introduce 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 2.3 SDK documentation to be a streaming
+sensor.</p>
+<a name="section-7.3.1"></a><h4>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>MUST be able to deliver events at 50 Hz or greater</li>
+<li>MUST comply with the Android sensor coordinate system as detailed
+in the Android APIs (see [<a href="#resources31">Resources, 31</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>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="#resources31">Resources, 31</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>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>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 capable of measuring orientation changes up to 5.5*Pi
+radians/second (that is, approximately 1,000 degrees per second)</li>
+<li>MUST be able to deliver events at 100 Hz or greater</li>
+<li>MUST have 8-bits of accuracy or more</li>
+</ul>
+<a name="section-7.3.5"></a><h4>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>
+</ul>
+<a name="section-7.3.6"></a><h4>7.3.7. Thermometer</h4>
+<p>Device implementations MAY but SHOULD NOT include a thermometer (i.e.
+temperature sensor.) If a device implementation does include a thermometer, it
+MUST measure the temperature of the device CPU. It MUST NOT measure any other
+temperature. (Note that this sensor type is deprecated in the Android 2.3
+APIs.)</p>
+<a name="section-7.3.7"></a><h4>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>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>7.4. Data Connectivity</h3>
+<p>Network connectivity and access to the Internet are vital features of
+Android. Meanwhile, device-to-device interaction adds significant value to
+Android devices and applications. Device implementations MUST meet the
+data connectivity requirements in this section.</p>
+<a name="section-7.4.1"></a><h4>7.4.1. Telephony</h4>
+<p>"Telephony" as used by the Android 2.3 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 2.3 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 2.3 MAY be used on devices that do not include telephony hardware.
+That is, Android 2.3 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>7.4.2. IEEE 802.11 (WiFi)</h4>
+<p>Android 2.3 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>
+<a name="section-7.4.3"></a><h4>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 [<a
+href="#resources32">Resources, 32</a>]. Device implementations SHOULD
+implement relevant Bluetooth profiles, such as A2DP, AVRCP, OBEX, etc. as
+appropriate for the device.</p>
+<p>The Compatibility Test Suite includes cases that cover basic operation of
+the Android RFCOMM Bluetooth API. However, since Bluetooth is a communications
+protocol between devices, it cannot be fully tested by unit tests running on a
+single device. Consequently, device implementations MUST also pass the
+human-driven Bluetooth test procedure described in Appendix A.</p>
+<a name="section-7.4.4"></a><h4>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="#resources27">Resources, 27</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>NfcV (ISO 15693)</li>
+ <li>IsoDep (ISO 14443-4)</li>
+ <li>NFC Forum Tag Types 1, 2, 3, 4 (defined by the NFC Forum)</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="#resources33">Resources, 33</a>]</li>
+</ul></li>
+<li>MUST scan 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.</li>
+</ul>
+<p>(Note that publicly available links are not available for the JIS, ISO, and
+NFC Forum specifications cited above.)</p>
+<p>Additionally, device implementations SHOULD support the following
+widely-deployed MIFARE technologies.</p>
+<ul>
+ <li>MIFARE Classic (NXP MF1S503x [<a href="#resources34">Resources, 34</a>], MF1S703x [<a href="#resources35">Resources, 35</a>])</li>
+ <li>MIFARE Ultralight (NXP MF0ICU1 [<a href="#resources36">Resources, 36</a>], MF0ICU2 [<a href="#resources37">Resources, 37</a>])</li>
+ <li>NDEF on MIFARE Classic (NXP AN130511 [<a href="#resources38">Resources, 38</a>], AN130411 [<a href="#resources39">Resources, 39</a>])</li>
+</ul>
+<p>Note that Android 2.3.3 includes APIs for these MIFARE types. If a
+device implementation supports MIFARE, 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="#resources27">Resources, 27</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="#resources27">Resources, 27</a>], and MUST implement the Android 2.3 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>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 (WiFi).</p>
+<p>Devices MAY implement more than one form of data connectivity.</p>
+
+
+<a name="section-7.5"></a><h3>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>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>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 2.3 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="#resources40">Resources, 40</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 data returned to any "postview" camera callback
+handlers, in the same manner as the camera preview image stream. (If the device
+implementation does not support postview callbacks, 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>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
+android.hardware.Camera.Parameters.setPreviewFormat(int), then the device MUST
+use android.hardware.PixelFormat.YCbCr_420_SP for preview data provided to
+application callbacks.</li>
+<li>If an application registers an android.hardware.Camera.PreviewCallback
+instance and the system calls the onPreviewFrame() method when the preview
+format is YCbCr_420_SP, the data in the byte[] passed into onPreviewFrame()
+must further be in the NV21 encoding format. That is, NV21 MUST be the default.</li>
+<li>Device implementations SHOULD 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. Note that the Compatibility
+Definition for a future version is planned to change this requirement to
+"MUST". That is, YV12 support is optional in Android 2.3 but <b>will be
+required</b> by a future version. Existing and new devices that run Android
+2.3 are <b>very strongly encouraged to meet this requirement in Android
+2.3</b>, or they will not be able to attain Android compatibility when
+upgraded to the future version.</li>
+</ol>
+<p>Device implementations MUST implement the full Camera API included in the
+Android 2.3 SDK documentation [<a href="#resources41">Resources, 41</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.</p>
+<a name="section-7.5.4"></a><h4>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 dimention. That
+is, when the device is held in the landscape orientation, a 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>7.6. Memory and Storage</h3>
+<p>The fundamental function of Android 2.3 is to run applications. Device
+implementations MUST the requirements of this section, to ensure adequate
+storage and memory for applications to run properly.</p>
+<a name="section-7.6.1"></a><h4>7.6.1. Minimum Memory and Storage</h4>
+<p>Device implementations MUST have at least 128MB of memory available to the
+kernel and userspace. The 128MB MUST be in addition to any memory dedicated to
+hardware components such as radio, memory, and so on that is not under the
+kernel's control.</p>
+<p>Device implementations MUST have at least 150MB of non-volatile storage
+available for user data. That is, the <code>/data</code> partition MUST be at
+least 150MB.</p>
+<p>Beyond the requirements above, device implementations SHOULD have at least
+1GB of non-volatile storage available for user data. Note that this higher
+requirement is planned to become a hard minimum in a future version of
+Android. Device implementations are strongly encouraged to meet these
+requirements now, or else they may not be eligible for compatibility for a
+future version of Android.</p>
+<p>The Android APIs include a Download Manager that applications may use to
+download data files. The Download Manager implementation MUST be capable of
+downloading individual files 55MB in size, or larger. The Download Manager
+implementation SHOULD be capable of downloading files 100MB in size, or
+larger.</p>
+<a name="section-7.6.2"></a><h4>7.6.2. Application Shared 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.</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 or Media Transfer Protocol.</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) SHOULD modify the core
+applications such as the media scanner and ContentProvider to transparently
+support files placed in both locations.</p>
+
+<a name="section-7.7"></a><h3>7.7. USB</h3>
+<p>Device implementations:</p>
+<ul>
+<li>MUST implement a USB client, connectable to a USB host with a standard
+USB-A port</li>
+<li>MUST implement the Android Debug Bridge over USB (as described in Section
+7)</li>
+<li>MUST implement the USB mass storage specification, to allow a host
+connected to the device to access the contents of the /sdcard volume </li>
+<li>SHOULD use the micro USB form factor on the device side</li>
+<li>MAY include a non-standard port on the device side, but if so MUST ship
+with a cable capable of connecting the custom pinout to standard USB-A
+port</li>
+</ul>
+
+
+<a name="section-8"></a><h2>8. Performance Compatibility</h2>
+<p>Compatible implementations must ensure not only that applications simply
+run correctly on the device, but that they do so with reasonable performance
+and overall good user experience. Device implementations MUST meet the key
+performance metrics of an Android 2.3 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>MMS/SMS: less than 700ms</li>
+<li>AlarmClock: less than 650ms</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>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="#resources42">Resources, 42</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>9.1. Permissions</h3>
+<p>Device implementations MUST support the Android permissions model as
+defined in the Android developer documentation [<a
+href="#resources42">Resources, 42</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>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="#resources42">Resources, 42</a>].</p>
+<a name="section-9.3"></a><h3>9.3. Filesystem Permissions</h3>
+<p>Device implementations MUST support the Android file access permissions
+model as defined in as defined in the Security and Permissions reference [<a
+href="#resources42">Resources, 42</a>].</p>
+<a name="section-9.4"></a><h3>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-10"></a><h2>10. Software Compatibility Testing</h2>
+<p>The Android Open-Source Project includes various testing tools to verify
+that device implementations are compatible. 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 2.3 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>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 2.3. Device implementations MUST pass the latest CTS version
+available at the time the device software is completed.</p>
+<p>MUST pass the most recent version of the Android Compatibility Test Suite
+(CTS) available at the time of the device implementation's software is
+completed. (The CTS is available as part of the Android Open Source Project [<a
+href="#resources02">Resources, 2</a>].) The CTS tests many, but not all, of the
+components outlined in this document.</p>
+<a name="section-10.2"></a><h3>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 Verfier only by the set of included
+locales, branding, etc. MAY omit the CTS Verifier test.</p>
+<a name="section-10.3"></a><h3>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="#resources43">Resources, 43</a>].</li>
+<li>Replica Island (available in Android Market; only required for device
+ implementations that support with OpenGL ES 2.0)</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>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.
+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>12. 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>
+
+<a name="appendix-A"></a><h2>Appendix A - Bluetooth Test Procedure</h2>
+<p>The Compatibility Test Suite includes cases that cover basic operation of
+the Android RFCOMM Bluetooth API. However, since Bluetooth is a communications
+protocol between devices, it cannot be fully tested by unit tests running on a
+single device. Consequently, device implementations MUST also pass the
+human-operated Bluetooth test procedure described below.</p>
+<p>The test procedure is based on the BluetoothChat sample app included in the
+Android open-source project tree. The procedure requires two devices:</p>
+<ul>
+<li>a candidate device implementation running the software build to be tested</li>
+<li>a separate device implementation already known to be compatible, and of a
+ model from the device implementation being tested -- that is, a "known
+ good" device implementation</li>
+</ul>
+<p>The test procedure below refers to these devices as the "candidate" and "known
+good" devices, respectively.</p>
+<h3>Setup and Installation</h3>
+<ol>
+<li>Build BluetoothChat.apk via 'make samples' from an Android source code tree.</li>
+<li>Install BluetoothChat.apk on the known-good device.</li>
+<li>Install BluetoothChat.apk on the candidate device.</li>
+</ol>
+<h3>Test Bluetooth Control by Apps</h3>
+<ol>
+<li>Launch BluetoothChat on the candidate device, while Bluetooth is disabled.</li>
+<li>Verify that the candidate device either turns on Bluetooth, or prompts the user with a dialog to turn on Bluetooth.</li>
+</ol>
+<h3>Test Pairing and Communication</h3>
+<ol>
+<li>Launch the Bluetooth Chat app on both devices.</li>
+<li>Make the known-good device discoverable from within BluetoothChat (using the Menu).</li>
+<li>On the candidate device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the known-good device.</li>
+<li>Send 10 or more messages from each device, and verify that the other device receives them correctly.</li>
+<li>Close the BluetoothChat app on both devices by pressing <b>Home</b>.</li>
+<li>Unpair each device from the other, using the device Settings app.</li>
+</ol>
+<h3>Test Pairing and Communication in the Reverse Direction</h3>
+<ol>
+<li>Launch the Bluetooth Chat app on both devices.</li>
+<li>Make the candidate device discoverable from within BluetoothChat (using the Menu).</li>
+<li>On the known-good device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the candidate device.</li>
+<li>Send 10 or messages from each device, and verify that the other device receives them correctly.</li>
+<li>Close the Bluetooth Chat app on both devices by pressing Back repeatedly to get to the Launcher.</li>
+</ol>
+<h3>Test Re-Launches</h3>
+<ol>
+<li>Re-launch the Bluetooth Chat app on both devices.</li>
+<li>Send 10 or messages from each device, and verify that the other device receives them correctly.</li>
+</ol>
+<p>Note: the above tests have some cases which end a test section by using
+Home, and some using Back. These tests are not redundant and are not optional:
+the objective is to verify that the Bluetooth API and stack works correctly
+both when Activities are explicitly terminated (via the user pressing Back,
+which calls finish()), and implicitly sent to background (via the user
+pressing Home.) Each test sequence MUST be performed as described.</p>
+<div id="footerContent" xmlns:pdf="http://whatever">
+<pdf:pagenumber/>
+</div>
+</body>
+</html>
diff --git a/src/compatibility/4.0/android-4.0-cdd.xhtml b/src/compatibility/4.0/android-4.0-cdd.xhtml
new file mode 100644
index 0000000..e620230
--- /dev/null
+++ b/src/compatibility/4.0/android-4.0-cdd.xhtml
@@ -0,0 +1,2448 @@
+<?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.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 4.0 Compatibility Definition</h1>
+<!--
+<span style="color: red; font-weight: bold;"><h2>DRAFT 3</h2></span><br/>
+<span style="color: red;">Last updated: November 17, 2012</span>
+-->
+<p>Revision 4<br/>
+Last updated: April 21, 2013
+</p>
+<p>Copyright © 2012, 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/>
+ </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. Widgets</a><br/>
+ <a href="#section-3.8.2">3.8.2. Notifications</a><br/>
+ <a href="#section-3.8.3">3.8.3. Search</a><br/>
+ <a href="#section-3.8.4">3.8.4. Toasts</a><br/>
+ <a href="#section-3.8.5">3.8.5. Themes</a><br/>
+ <a href="#section-3.8.6">3.8.6. Live Wallpapers</a><br/>
+ <a href="#section-3.8.7">3.8.7. Recent Application Display</a><br/>
+ <a href="#section-3.8.8">3.8.8. Input Management Settings</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. Audio Recording</a><br/>
+ <a href="#section-5.4">5.4. Audio Latency</a><br/>
+ <a href="#section-5.5">5.5. Network Protocols</a><br/>
+ </div>
+ <a href="#section-6">6. Developer Tool Compatibility</a><br/>
+ <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 Accleration</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/>
+ </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 (WiFi)</a><br/>
+ <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/>
+ </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. Application Shared 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/>
+ </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. Contact Us</a><br/>
+ <a href="#appendix-A">Appendix A - Bluetooth Test Procedure</a><br/>
+</div>
+
+<div style="page-break-before: always;"></div>
+
+<a name="section-1"></a><h2>1. Introduction</h2>
+<p>This document enumerates the requirements that must be met in order for
+devices to be compatible with Android 4.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="#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.0. A "device implementation" or "implementation" is the hardware/software
+solution so developed.</p>
+<p>To be considered compatible with Android 4.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="#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>2. Resources</h2>
+<ol>
+<a name="resources01"></a><li>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>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>Android Open Source Project: <a href="http://source.android.com/">http://source.android.com/</a></li>
+<a name="resources04"></a><li>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>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>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>Android 4.0 allowed version strings: <a href="http://source.android.com/compatibility/4.0/versions.html">http://source.android.com/compatibility/4.0/versions.html</a></li>
+<a name="resources08"></a><li>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>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>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>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>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>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>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>HTML5/W3C webdatabase API: <a href="http://www.w3.org/TR/webdatabase/">http://www.w3.org/TR/webdatabase/</a></li>
+<a name="resources16"></a><li>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>Dalvik Virtual Machine specification: available in the Android source code, at dalvik/docs</li>
+<a name="resources18"></a><li>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>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>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>Status Bar icon style guide: <a href="http://developer.android.com/guide/practices/ui_guidelines/icon_design.html#statusbarstructure">http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure</a></li>
+<a name="resources22"></a><li>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>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>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>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>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>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>android.app.admin.DevicePolicyManager class: <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>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>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>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>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>Reference tool documentation (for adb, aapt, ddms): <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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>android.hardware.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>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>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>Android Security and Permissions reference: <a href="http://developer.android.com/guide/topics/security/security.html">http://developer.android.com/guide/topics/security/security.html</a></li>
+<a name="resources55"></a><li>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>android.app.DownloadManager class: <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>Android File Transfer: <a href="http://www.android.com/filetransfer">http://www.android.com/filetransfer</a></li>
+<a name="resources58"></a><li>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>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>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="resources61"></a><li>Touch Input Configuration: <a href="http://source.android.com/tech/input/touch-devices.html">http://source.android.com/tech/input/touch-devices.html</a></li>
+</ol>
+
+<p>Many of these resources are derived directly or indirectly from the Android
+4.0 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>3. Software</h2>
+<a name="section-3.1"></a><h3>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 4.0 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>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>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 10 lists additional
+requirements related to the Android security model.</p>
+<a name="section-3.2.3"></a><h4>3.2.3. 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>android.os.Build.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>android.os.Build.VERSION.SDK</td>
+<td>The version of the currently-executing Android system, in a format
+accessible to third-party application code. For Android 4.0.1 - 4.0.2, this
+field MUST have the integer value 14. For Android 4.0.3 or greater, this field
+MUST have the integer value 15.</td>
+</tr>
+<tr>
+<td>android.os.Build.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.0.1 - 4.0.2, this
+field MUST have the integer value 14. For Android 4.0.3 or greater, this field
+MUST have the integer value 15.</td>
+</tr>
+<tr>
+<td>android.os.Build.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>android.os.Build.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>android.os.Build.BRAND</td>
+<td>A value chosen by the device implementer identifying the name of the
+company, organization, individual, etc. who produced the device, in
+human-readable format. A possible use of this field is to indicate the OEM
+and/or carrier who sold 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>android.os.Build.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>android.os.Build.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>android.os.Build.DEVICE</td>
+<td>A value chosen by the device implementer identifying the specific
+configuration or revision of the body (sometimes called "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>android.os.Build.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/mydevice/generic:4.0/IRK77/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>android.os.Build.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>android.os.Build.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>android.os.Build.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>android.os.Build.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>android.os.Build.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>android.os.Build.PRODUCT</td>
+<td>A value chosen by the device implementer containing the development name
+or code name of the product (SKU). 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>android.os.Build.SERIAL</td>
+<td>A hardware serial number, if available. The value of this field MUST be encodable
+as 7-bit ASCII and match the regular expression
+<code>"^([a-zA-Z0-9]{0,20})$"</code>.</td>
+</tr>
+<tr>
+<td>android.os.Build.TAGS</td>
+<td>A comma-separated list of tags chosen by the device implementer that
+further distinguish 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>android.os.Build.TIME</td>
+<td>A value representing the timestamp of when the build occurred.</td>
+</tr>
+<tr>
+<td>android.os.Build.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>android.os.Build.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>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>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 compontent 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>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.2 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 which allows the user to select between multiple
+applications which all handle the same Intent pattern.</p>
+<a name="section-3.2.3.3"></a><h4>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>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.3"></a><h3>3.3. Native API Compatibility</h3>
+<a name="section-3.3.1"></a><h4>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.txt</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</li>
+<li>MUST report only those ABIs documented in the latest version of the
+Android NDK, in the file <code>docs/CPU-ARCH-ABIS.txt</code></li>
+<li>SHOULD be built using the source code and header files available in the
+upstream Android open source project</li>
+</ul>
+<p>The following native code APIs MUST be available to apps that include
+native code:</p>
+<ul>
+<li>libc (C library)</li>
+<li>libm (math library)</li>
+<li>Minimal support for C++</li>
+<li>JNI interface</li>
+<li>liblog (Android logging)</li>
+<li>libz (Zlib compression)</li>
+<li>libdl (dynamic linker)</li>
+<li>libGLESv1_CM.so (OpenGL ES 1.0)</li>
+<li>libGLESv2.so (OpenGL ES 2.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>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>3.4. Web Compatibility</h3>
+<a name="section-3.4.1"></a><h4>3.4.1. WebView Compatibility</h4>
+<p>The Android Open Source implementation uses the WebKit rendering engine to
+implement the <code>android.webkit.WebView</code>. 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 WebKit in the WebView
+implementation. Specifically:</p>
+<ul>
+<li>Device implementations' <code>android.webkit.WebView</code>
+implementations MUST be based on the 534.30 WebKit build from the upstream
+Android Open Source tree for Android 4.0. This build includes a specific set
+of functionality and security fixes for the WebView. Device implementers MAY
+include customizations to the WebKit implementation; however, any such
+customizations MUST NOT alter the behavior of the WebView, including rendering
+behavior.</li>
+<li>The user agent string reported by the WebView MUST be in this format:<br/>
+ <code>Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30</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 SHOULD follow the ISO conventions for country code and language, and SHOULD refer to the current configured locale of the device</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>
+ </ul>
+</li>
+</ul>
+<p>The WebView component 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 in the WebView:</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>
+<p>HTML5 APIs, like all JavaScript APIs, MUST be disabled by default in a
+WebView, unless the developer explicitly enables them via the usual Android
+APIs.</p>
+
+<a name="section-3.4.2"></a><h4>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>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>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>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>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>
+</tbody>
+</table>
+
+<a name="section-3.8"></a><h3>3.8. User Interface Compatibility</h3>
+<a name="section-3.8.1"></a><h4>3.8.1. 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>].
+The Android Open Source reference release includes a Launcher application that
+includes user interface affordances allowing the user to add, view, and remove
+AppWidgets from the home screen.</p>
+<p>Device implementations MAY substitute an alternative to the reference Launcher
+(i.e. home screen). Alternative Launchers SHOULD include built-in support for
+AppWidgets, and expose user interface affordances to add, configure, view, and
+remove AppWidgets directly within the Launcher. Alternative Launchers MAY omit
+these user interface elements; however, if they are omitted, the device
+implementation MUST provide a separate application accessible from the Launcher
+that allows users to add, configure, view, and remove AppWidgets.</p>
+<p>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.</p>
+<a name="section-3.8.2"></a><h4>3.8.2. 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 4.0 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.3"></a><h4>3.8.3. 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.4"></a><h4>3.8.4. 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.5"></a><h4>3.8.5. Themes</h4>
+<p>Android provides "themes" as a mechanism for applications to apply styles
+across an entire Activity or application. Android 3.0 introduced a new "Holo"
+or "holographic" theme 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 4.0 introduces a new "Device Default" theme 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>
+
+<a name="section-3.8.6"></a><h4>3.8.6. 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.7"></a><h4>3.8.7. Recent Application Display</h4>
+<p>The upstream Android 4.0 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 4.0 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.8"></a><h4>3.8.8. Input Management Settings</h4>
+<p>Android 4.0 includes support for Input Management Engines. The Android 4.0
+APIs allow custom app IMEs to specify user-tunable settings. Device
+implementations MUST include a way for the user to access IME settings at all
+times when an IME that provides such user settings is displayed.</p>
+
+<a name="section-3.9"></a><h3>3.9 Device Administration</h3>
+<p>Android 4.0 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>], and SHOULD support
+the full range of device administration policies defined in the Android SDK
+documentation [<a href="#resources27">Resources, 27</a>].</p>
+
+<p>If device implementations do not support the full range of device administration
+policies, they MUST NOT allow device administration applications to be enabled.
+Specifically, if a device does not support all device administration policies,
+the device implementation MUST respond to the
+<code>android.app.admin.DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN</code> intent,
+but MUST dislpay a message notifying the user that the device does not support
+device administration.</p>
+
+<a name="section-3.10"></a><h3>3.10 Accessibility</h3>
+<p>Android 4.0 provides an accessibility layer that helps users with disabilities
+to navigate their devices more easily. In addition, Android 4.0 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>AccessibilityEvent</code>s
+ 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>3.11 Text-to-Speech</h3>
+<p>Android 4.0 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>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>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>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="10">Audio</td>
+<td>AAC LC/LTP</td>
+<td style="text-align: center;">REQUIRED<br/>
+<small>Required for device implementations that include microphone hardware
+and define <code>android.hardware.microphone</code>.</small></td>
+<td style="text-align: center;">REQUIRED</td>
+<td rowspan="3">Mono/Stereo content in any combination of standard bit
+rates up to 160 kbps and sampling rates from 8 to 48kHz</td>
+<td rowspan="3">
+ <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>HE-AACv1 (AAC+)</td>
+<td> </td>
+<td style="text-align: center;">REQUIRED</td>
+</tr>
+
+<tr>
+<td>HE-AACv2 (enhanced AAC+)</td>
+<td> </td>
+<td style="text-align: center;">REQUIRED</td>
+</tr>
+
+<tr>
+<td>AMR-NB</td>
+<td style="text-align: center;">REQUIRED<br/>
+<small>Required for device implementations that include microphone hardware
+and define <code>android.hardware.microphone</code>.</small></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 style="text-align: center;">REQUIRED<br/>
+<small>Required for device implementations that include microphone hardware
+and define <code>android.hardware.microphone</code>.</small></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> </td>
+<td style="text-align: center;">REQUIRED</td>
+<td>8- and 16-bit linear PCM (rates up to limit of hardware)</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="4">Video</td>
+<td>H.263</td>
+<td style="text-align: center;">REQUIRED<br/>
+<small>Required for device implementations that include camera hardware
+and define <code>android.hardware.camera</code> or
+<code>android.hardware.camera.front</code>.</small></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 style="text-align: center;">REQUIRED<br/>
+<small>Required for device implementations that include camera hardware
+and define <code>android.hardware.camera</code> or
+<code>android.hardware.camera.front</code>.</small></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> </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>
+
+</tbody></table>
+
+<a name="section-5.2"></a><h3>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 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 codec</th>
+ <td>H.264 Baseline Profile</td>
+ <td>H.264 Baseline Profile</td>
+ <td>H.264 Baseline Profile</td>
+ </tr>
+ <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>
+
+<a name="section-5.3"></a><h3>5.3. 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% from 100 Hz to 4000 Hz 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><b>Note:</b> while some of the requirements outlined above are stated as "SHOULD"
+for Android 4.0, the Compatibility Definition for a future version is planned
+to change these to "MUST". That is, these requirements are optional in Android
+4.0 but <b>will be required</b> by a future version. Existing and new devices
+that run Android 4.0 are <b>very strongly encouraged to meet
+these requirements in Android 4.0</b>, or they will not be able to attain
+Android compatibility when upgraded to the future version.</p>
+
+<a name="section-5.4"></a><h3>5.4. Audio Latency</h3>
+<p>Audio latency is broadly defined as the interval between when an
+application requests an audio playback or record operation, and when the
+device implementation actually begins the operation. Many classes of
+applications rely on short latencies, to achieve real-time effects such sound
+effects or VOIP communication. Device implementations that include microphone
+hardware and declare <code>android.hardware.microphone</code> SHOULD meet all
+audio latency requirements outlined in this section. See <a href="#section-7">
+Section 7</a> for details on the conditions under which microphone hardware may
+be omitted by device implementations.</p>
+<p>For the purposes of this section:</p>
+<ul>
+<li>"cold output latency" is defined to be the interval between when an
+ application requests audio playback and when sound begins playing, when
+ the audio system has been idle and powered down prior to the request</li>
+<li>"warm output latency" is defined to be the interval between when an
+ application requests audio playback and when sound begins playing, when
+ the audio system has been recently used but is currently idle (that is,
+ silent)</li>
+<li>"continuous output latency" is defined to be the interval between when an
+ application issues a sample to be played and when the speaker physically
+ plays the corresponding sound, while the device is currently playing back
+ audio</li>
+<li>"cold input latency" is defined to be the interval between when an
+ application requests audio recording and when the first sample is
+ delivered to the application via its callback, when the audio system and
+ microphone has been idle and powered down prior to the request</li>
+<li>"continuous input latency" is defined to be when an ambient sound occurs
+ and when the sample corresponding to that sound is delivered to a
+ recording application via its callback, while the device is in recording
+ mode</li>
+</ul>
+<p>Using the above definitions, device implementations SHOULD exhibit each of
+these properties:</p>
+<ul>
+<li>cold output latency of 100 milliseconds or less</li>
+<li>warm output latency of 10 milliseconds or less</li>
+<li>continuous output latency of 45 milliseconds or less</li>
+<li>cold input latency of 100 milliseconds or less</li>
+<li>continuous input latency of 50 milliseconds or less</li>
+</ul>
+<p><b>Note:</b> while the requirements outlined above are stated as "SHOULD"
+for Android 4.0, the Compatibility Definition for a future version is planned
+to change these to "MUST". That is, these requirements are optional in Android
+4.0 but <b>will be required</b> by a future version. Existing and new devices
+that run Android 4.0 are <b>very strongly encouraged to meet
+these requirements in Android 4.0</b>, or they will not be able to attain
+Android compatibility when upgraded to the future version.</p>
+<p>If a device implementation meets the requirements of this section, 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>
+
+<a name="section-5.5"></a><h3>5.5. 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>6. Developer Tool Compatibility</h2>
+<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><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>
+</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, and Windows 7, in both 32-bit and
+64-bit versions.</p>
+
+<a name="section-7"></a><h2>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>7.1. Display and Graphics</h3>
+<p>Android 4.0 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>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
+470 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 between 1.3333 (4:3) and 1.85 (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>
+</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>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>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>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 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 and 2.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 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 2.0.</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 4.0 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 4.0 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 3.0 introduced 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.0, 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 4.0 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>
+
+<a name="section-7.1.5"></a><h4>7.1.5. Legacy Application Compatibility Mode</h4>
+<p>Android 4.0 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>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 or HDMI 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 one or both of 1280x720,
+or 1920x1080 (that is, 720p or 1080p). 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>
+</ul>
+<p>For clarity, device implementations with variable pixel dimensions are
+restricted to 720p or 1080p in Android 4.0, and MUST be configured to report
+screen size and density buckets as noted above.</p>
+
+<a name="section-7.1.7"></a><h4>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.2"></a><h3>7.2. Input Devices</h3>
+<a name="section-7.2.1"></a><h4>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>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 software 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>7.2.3. Navigation keys</h4>
+<p>The Home, Menu 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, gestures, touch panel, etc.
+Android 4.0 supports both implementations.</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>
+ <li>Device implementation MUST present a Menu key to applications when
+ targetSdkVersion <= 10 and SHOULD NOT present a Menu key when the
+ targetSdkVersion > 10.</li>
+</ul>
+
+<a name="section-7.2.4"></a><h4>7.2.4. Touchscreen input</h4>
+<p>Device implementations:</p>
+<ul>
+<li>MUST have a pointer input system of some kind (either mouse-like, or touch)</li>
+<li>MAY have a touchscreen of any modality (such as capacitive or resistive)</li>
+<li>SHOULD support fully independently tracked pointers, if a touchscreen 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 4.0 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="#resources61">Resources, 61</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 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>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="#resources60">Resources, 60</a>] </li>
+<li> MUST report touch event with the action code [<a href="#resources60">Resources, 60</a>] that specifies the state change
+that occurs on the pointer going <code>down</code> or <code>up</code> on the screen [<a href="#resources60">Resources, 60</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="#resources60">Resources, 60</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>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.3">Section 5.3</a></li>
+<li>SHOULD meet the audio latency requirements in <a
+href="section-5.4">Section 5.4</a></li>
+</ul>
+
+<a name="section-7.3"></a><h3>7.3. Sensors</h3>
+<p>Android 4.0 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>The Android 4.0 APIs introduce 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 4.0 SDK documentation to be a streaming
+sensor.</p>
+<a name="section-7.3.1"></a><h4>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>MUST be able to deliver events at 50 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 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>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>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>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>MUST be able to deliver events at 100 Hz or greater</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>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>
+</ul>
+<a name="section-7.3.6"></a><h4>7.3.7. Thermometer</h4>
+<p>Device implementations MAY but SHOULD NOT include a thermometer (i.e.
+temperature sensor.) If a device implementation does include a thermometer, it
+MUST measure the temperature of the device CPU. It MUST NOT measure any other
+temperature. (Note that this sensor type is deprecated in the Android 4.0
+APIs.)</p>
+<a name="section-7.3.7"></a><h4>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>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>7.4. Data Connectivity</h3>
+<a name="section-7.4.1"></a><h4>7.4.1. Telephony</h4>
+<p>"Telephony" as used by the Android 4.0 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 4.0 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 4.0 MAY be used on devices that do not include telephony hardware.
+That is, Android 4.0 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>7.4.2. IEEE 802.11 (WiFi)</h4>
+<p>Android 4.0 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>
+<a name="section-7.4.3"></a><h4>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 [<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>The Compatibility Test Suite includes cases that cover basic operation of
+the Android RFCOMM Bluetooth API. However, since Bluetooth is a communications
+protocol between devices, it cannot be fully tested by unit tests running on a
+single device. Consequently, device implementations MUST also pass the
+human-driven Bluetooth test procedure described in Appendix A.</p>
+<a name="section-7.4.4"></a><h4>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" for Android 4.0, the Compatibility Definition for a future
+ version is planned to change these to "MUST". That is, these stanards are
+ optional in Android 4.0 but <b>will be required</b> in future versions.
+ Existing and new devices that run Android 4.0 are <b>very strongly
+ encouraged to meet these requirements in Android 4.0</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:
+ <ul>
+ <li>MUST implement the SNEP default server. Valid NDEF messages received
+ by the default SNEP server MUST be dispatched to applications using
+ the android.nfc.ACTION_NDEF_DISCOVERED intent. Disabling Android Beam
+ in settings MUST NOT disable dispatch of incoming NDEF message.</li>
+ <li>MUST 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>
+ </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>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="#resources44">Resources, 44</a>])</li>
+ <li>MIFARE Ultralight (NXP MF0ICU1 [<a href="#resources46">Resources, 46</a>],
+ MF0ICU2 [<a href="#resources46">Resources, 46</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 4.0 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 4.0 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>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 (WiFi).</p>
+<p>Devices MAY implement more than one form of data connectivity.</p>
+
+
+<a name="section-7.5"></a><h3>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>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>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 4.0 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>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 decoder 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 4.0 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.</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>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 dimention. 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>7.6. Memory and Storage</h3>
+<a name="section-7.6.1"></a><h4>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 MUST have at least 350MB of non-volatile storage
+available for application private data. That is, the <code>/data</code> partition MUST be at
+least 350MB.</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>7.6.2. Application Shared 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.</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) SHOULD modify the core
+applications such as the media scanner and ContentProvider to transparently
+support files placed in both locations.</p>
+
+<a name="section-7.7"></a><h3>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</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,
+51</a>]</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,
+52</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>8. Performance Compatibility</h2>
+<p>Device implementations MUST meet the key performance metrics of an Android
+4.0 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>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>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>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>9.3. Filesystem Permissions</h3>
+<p>Device implementations MUST support the Android file access permissions
+model as defined in as defined in the Security and Permissions reference [<a
+href="#resources54">Resources, 54</a>].</p>
+<a name="section-9.4"></a><h3>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-10"></a><h2>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 4.0 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>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.0. 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>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 Verfier only by the set of included
+locales, branding, etc. MAY omit the CTS Verifier test.</p>
+<a name="section-10.3"></a><h3>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 Android Market)</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>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>12. 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>
+
+<a name="appendix-A"></a><h2>Appendix A - Bluetooth Test Procedure</h2>
+<p>The Compatibility Test Suite includes cases that cover basic operation of
+the Android RFCOMM Bluetooth API. However, since Bluetooth is a communications
+protocol between devices, it cannot be fully tested by unit tests running on a
+single device. Consequently, device implementations MUST also pass the
+human-operated Bluetooth test procedure described below.</p>
+<p>The test procedure is based on the BluetoothChat sample app included in the
+Android open source project tree. The procedure requires two devices:</p>
+<ul>
+<li>a candidate device implementation running the software build to be tested</li>
+<li>a separate device implementation already known to be compatible, and of a
+ model from the device implementation being tested - that is, a "known
+ good" device implementation</li>
+</ul>
+<p>The test procedure below refers to these devices as the "candidate" and "known
+good" devices, respectively.</p>
+<h3>Setup and Installation</h3>
+<ol>
+<li>Build BluetoothChat.apk via 'make samples' from an Android source code tree.</li>
+<li>Install BluetoothChat.apk on the known-good device.</li>
+<li>Install BluetoothChat.apk on the candidate device.</li>
+</ol>
+<h3>Test Bluetooth Control by Apps</h3>
+<ol>
+<li>Launch BluetoothChat on the candidate device, while Bluetooth is disabled.</li>
+<li>Verify that the candidate device either turns on Bluetooth, or prompts the user with a dialog to turn on Bluetooth.</li>
+</ol>
+<h3>Test Pairing and Communication</h3>
+<ol>
+<li>Launch the Bluetooth Chat app on both devices.</li>
+<li>Make the known-good device discoverable from within BluetoothChat (using the Menu).</li>
+<li>On the candidate device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the known-good device.</li>
+<li>Send 10 or more messages from each device, and verify that the other device receives them correctly.</li>
+<li>Close the BluetoothChat app on both devices by pressing <b>Home</b>.</li>
+<li>Unpair each device from the other, using the device Settings app.</li>
+</ol>
+<h3>Test Pairing and Communication in the Reverse Direction</h3>
+<ol>
+<li>Launch the Bluetooth Chat app on both devices.</li>
+<li>Make the candidate device discoverable from within BluetoothChat (using the Menu).</li>
+<li>On the known-good device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the candidate device.</li>
+<li>Send 10 or messages from each device, and verify that the other device receives them correctly.</li>
+<li>Close the Bluetooth Chat app on both devices by pressing Back repeatedly to get to the Launcher.</li>
+</ol>
+<h3>Test Re-Launches</h3>
+<ol>
+<li>Re-launch the Bluetooth Chat app on both devices.</li>
+<li>Send 10 or messages from each device, and verify that the other device receives them correctly.</li>
+</ol>
+<p>Note: the above tests have some cases which end a test section by using
+Home, and some using Back. These tests are not redundant and are not optional:
+the objective is to verify that the Bluetooth API and stack works correctly
+both when Activities are explicitly terminated (via the user pressing Back,
+which calls finish()), and implicitly sent to background (via the user
+pressing Home.) Each test sequence MUST be performed as described.</p>
+
+<div id="footerContent" xmlns:pdf="http://whatever">
+<pdf:pagenumber/>
+</div>
+</body>
+</html>
diff --git a/src/compatibility/4.2/android-4.2-cdd.xhtml b/src/compatibility/4.2/android-4.2-cdd.xhtml
new file mode 100644
index 0000000..93c492a
--- /dev/null
+++ b/src/compatibility/4.2/android-4.2-cdd.xhtml
@@ -0,0 +1,2646 @@
+<?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.2Compatibility 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.2 Compatibility Definition</h1>
+<!--
+<span style="color: red; font-weight: bold;"><h2>Revision 1</h2></span><br/>
+<span style="color: red;">Last updated: October 17, 2012</span>
+-->
+<p><b><font color="red">Revision 2</font></b><br/>
+Last updated: Feb 17, 2013
+</p>
+<p>Copyright © 2012, 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/>
+ </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. Widgets</a><br/>
+ <a href="#section-3.8.2">3.8.2. Notifications</a><br/>
+ <a href="#section-3.8.3">3.8.3. Search</a><br/>
+ <a href="#section-3.8.4">3.8.4. Toasts</a><br/>
+ <a href="#section-3.8.5">3.8.5. Themes</a><br/>
+ <a href="#section-3.8.6">3.8.6. Live Wallpapers</a><br/>
+ <a href="#section-3.8.7">3.8.7. Recent Application Display</a><br/>
+ <a href="#section-3.8.8">3.8.8. Input Management Settings</a><br/>
+ <a href="#section-3.8.9">3.8.9. Lock and Home Screen Widgets</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/>
+ </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/>
+ </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 Accleration</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/>
+ </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 (WiFi)</a><br/>
+ <div style="margin-left: 2em;">
+ <a href="#section-7.4.2.1">7.4.2.1. WiFi Direct</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/>
+ </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. Application Shared 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/>
+ </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. Contact Us</a><br/>
+ <a href="#appendix-A">Appendix A - Bluetooth Test Procedure</a><br/>
+</div>
+
+<div style="page-break-before: always;"></div>
+
+<a name="section-1"></a><h2>1. Introduction</h2>
+<p>This document enumerates the requirements that must be met in order for
+devices to be compatible with Android 4.2.</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.2. A "device implementation" or "implementation" is the hardware/software
+solution so developed.</p>
+<p>To be considered compatible with Android 4.2, 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>2. Resources</h2>
+<ol>
+<a name="resources01"></a><li>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>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>Android Open Source Project: <a href="http://source.android.com/">http://source.android.com/</a></li>
+<a name="resources04"></a><li>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>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>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>Android 4.2 allowed version strings: <a href="http://source.android.com/compatibility/4.2/versions.html">http://source.android.com/compatibility/4.2/versions.html</a></li>
+<a name="resources08"></a><li>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>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>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>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>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>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>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>HTML5/W3C webdatabase API: <a href="http://www.w3.org/TR/webdatabase/">http://www.w3.org/TR/webdatabase/</a></li>
+<a name="resources16"></a><li>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>Dalvik Virtual Machine specification: available in the Android source code, at dalvik/docs</li>
+<a name="resources18"></a><li>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>Android Security and Permissions reference: <a href="http://developer.android.com/guide/topics/security/security.html">http://developer.android.com/guide/topics/security/security.html</a></li>
+<a name="resources55"></a><li>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>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>Android File Transfer: <a href="http://www.android.com/filetransfer">http://www.android.com/filetransfer</a></li>
+<a name="resources58"></a><li>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>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>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>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>Wifi 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>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>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>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>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>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>Wifi Direct (Wifi 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>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>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>External Storage reference: <a href="http://source.android.com/tech/storage">http://source.android.com/tech/storage</a></li>
+<a name="resources72"></a><li>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>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>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>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>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>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>
+</ol>
+<a name="resources78"></a><li>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>
+<p>Many of these resources are derived directly or indirectly from the Android
+4.2 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>3. Software</h2>
+<a name="section-3.1"></a><h3>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 4.2 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>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>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 10 lists additional
+requirements related to the Android security model.</p>
+<a name="section-3.2.2"></a><h4>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>android.os.Build.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>android.os.Build.VERSION.SDK</td>
+<td>The version of the currently-executing Android system, in a format
+accessible to third-party application code. For Android 4.2, this
+field MUST have the integer value 17.</td>
+</tr>
+<tr>
+<td>android.os.Build.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.2, this
+field MUST have the integer value 17.</td>
+</tr>
+<tr>
+<td>android.os.Build.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>android.os.Build.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>android.os.Build.BRAND</td>
+<td>A value chosen by the device implementer identifying the name of the
+company, organization, individual, etc. who produced the device, in
+human-readable format. A possible use of this field is to indicate the OEM
+and/or carrier who sold 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>android.os.Build.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>android.os.Build.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>android.os.Build.DEVICE</td>
+<td>A value chosen by the device implementer identifying the specific
+configuration or revision of the body (sometimes called "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>android.os.Build.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/mydevice/generic:4.2/JRN53/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>android.os.Build.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>android.os.Build.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>android.os.Build.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>android.os.Build.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>android.os.Build.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>android.os.Build.PRODUCT</td>
+<td>A value chosen by the device implementer containing the development name
+or code name of the product (SKU). 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>android.os.Build.SERIAL</td>
+<td>A hardware serial number, if available. The value of this field MUST be encodable
+as 7-bit ASCII and match the regular expression
+<code>"^([a-zA-Z0-9]{0,20})$"</code>.</td>
+</tr>
+<tr>
+<td>android.os.Build.TAGS</td>
+<td>A comma-separated list of tags chosen by the device implementer that
+further distinguish 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>android.os.Build.TIME</td>
+<td>A value representing the timestamp of when the build occurred.</td>
+</tr>
+<tr>
+<td>android.os.Build.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>android.os.Build.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>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>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 compontent 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>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.2 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 which 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>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>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.3"></a><h3>3.3. Native API Compatibility</h3>
+<a name="section-3.3.1"></a><h4>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</li>
+<li>MUST report only those ABIs documented in the latest version of the
+Android NDK, in the file <code>docs/CPU-ARCH-ABIS.txt</code></li>
+<li>SHOULD be built using the source code and header files available in the
+upstream Android open source project</li>
+</ul>
+<p>The following native code APIs MUST be available to apps that include
+native code:</p>
+<ul>
+<li>libc (C library)</li>
+<li>libm (math library)</li>
+<li>Minimal support for C++</li>
+<li>JNI interface</li>
+<li>liblog (Android logging)</li>
+<li>libz (Zlib compression)</li>
+<li>libdl (dynamic linker)</li>
+<li>libGLESv1_CM.so (OpenGL ES 1.0)</li>
+<li>libGLESv2.so (OpenGL ES 2.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>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>3.4. Web Compatibility</h3>
+<a name="section-3.4.1"></a><h4>3.4.1. WebView Compatibility</h4>
+<p>The Android Open Source implementation uses the WebKit rendering engine to
+implement the <code>android.webkit.WebView</code>. 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 WebKit in the WebView
+implementation. Specifically:</p>
+<ul>
+<li>Device implementations' <code>android.webkit.WebView</code>
+implementations MUST be based on the 534.30 WebKit build from the upstream
+Android Open Source tree for Android 4.2. This build includes a specific set
+of functionality and security fixes for the WebView. Device implementers MAY
+include customizations to the WebKit implementation; however, any such
+customizations MUST NOT alter the behavior of the WebView, including rendering
+behavior.</li>
+<li>The user agent string reported by the WebView MUST be in this format:<br/>
+ <code>Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.2 Mobile Safari/534.30</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 SHOULD follow the ISO conventions for country code and language, and SHOULD refer to the current configured locale of the device</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>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.
+Minimally, device implementations MUST support each of these APIs associated
+with HTML5 in the WebView:</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>
+<p>HTML5 APIs, like all JavaScript APIs, MUST be disabled by default in a
+WebView, unless the developer explicitly enables them via the usual Android
+APIs.</p>
+
+<a name="section-3.4.2"></a><h4>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>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>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>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>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>
+</tbody>
+</table>
+
+<a name="section-3.8"></a><h3>3.8. User Interface Compatibility</h3>
+<a name="section-3.8.1"></a><h4>3.8.1. 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>].
+The Android Open Source reference release includes a Launcher application that
+includes user interface affordances allowing the user to add, view, and remove
+AppWidgets from the home screen.</p>
+<p>Device implementations MAY substitute an alternative to the reference Launcher
+(i.e. home screen). Alternative Launchers SHOULD include built-in support for
+AppWidgets, and expose user interface affordances to add, configure, view, and
+remove AppWidgets directly within the Launcher. Alternative Launchers MAY omit
+these user interface elements; however, if they are omitted, the device
+implementation MUST provide a separate application accessible from the Launcher
+that allows users to add, configure, view, and remove AppWidgets.</p>
+<p>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.</p>
+<p>
+<a name="section-3.8.2"></a><h4>3.8.2. 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 4.2 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.3"></a><h4>3.8.3. 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.4"></a><h4>3.8.4. 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.5"></a><h4>3.8.5. Themes</h4>
+<p>Android provides "themes" as a mechanism for applications to apply styles
+across an entire Activity or application. Android 4.2 includes a "Holo"
+or "holographic" theme 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 4.2 includes a new "Device Default" theme 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>
+
+<a name="section-3.8.6"></a><h4>3.8.6. 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.7"></a><h4>3.8.7. Recent Application Display</h4>
+<p>The upstream Android 4.2 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 4.2 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.8"></a><h4>3.8.8. Input Management Settings</h4>
+<p>Android 4.2 includes support for Input Management Engines. The Android 4.2
+APIs allow custom app IMEs to specify user-tunable settings. Device
+implementations MUST include a way for the user to access IME settings at all
+times when an IME that provides such user settings is displayed.</p>
+
+<a name="section-3.8.9"></a><h4>3.8.9. Lock and Home Screen Widgets</h4>
+<p>Android 4.2 includes support for application widgets that users can embed in the home screen or the lock screen
+(See the App Widget Design Guidelines in the Android SDK documentation [<a href="#resources69">Resources, 69</a>] for details).
+Application widgets allow quick access to application data and services without launching a new activity. Widgets declare support
+for usage on the home screen or the lock screen by declaring the <code>android:widgetCategory</code> manifest tag that tells the system
+where the widget can be placed. Specifically, device implementations MUST meet the following requirements.</p>
+<ul>
+ <li>Device implementations MUST support application widgets on the home screen.</li>
+ <li>Device implementations SHOULD support lock screen. If device implementations include support for lock screen
+ then device implementations MUST support application widgets on the lock screen.</li>
+</ul>
+
+<a name="section-3.8.10"></a><h4>3.8.10. Lock Screen Media Remote Control</h4>
+<p>Android 4.2 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 MUST
+include support for embedding remote controls in the device lock screen.
+</p>
+<a name="section-3.8.11"></a><h4>3.8.11. Dreams</h4>
+<p>Android 4.2 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.9"></a><h3>3.9 Device Administration</h3>
+<p>Android 4.2 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>], and SHOULD support
+the full range of device administration policies defined in the Android SDK
+documentation [<a href="#resources27">Resources, 27</a>].
+</p>
+<p><b>Note:</b> while some of the requirements outlined above are stated as "SHOULD"
+for Android 4.2, device implementations that support lock screen MUST support device policies to manage widgets
+on the lock screen as defined in the Android SDK documentation [<a href="#resources27">Resources, 27</a>].
+</p>
+<p><b>Note:</b> while some of the requirements outlined above are stated as "SHOULD"
+for Android 4.2, the Compatibility Definition for a future version is planned
+to change these to "MUST". That is, these requirements are optional in Android
+4.2 but <b>will be required</b> by a future version. Existing and new devices
+that run Android 4.2 are <b>very strongly encouraged to meet
+these requirements in Android 4.2</b>, or they will not be able to attain
+Android compatibility when upgraded to the future version.</p>
+
+<a name="section-3.10"></a><h3>3.10 Accessibility</h3>
+<p>Android 4.2 provides an accessibility layer that helps users with disabilities
+to navigate their devices more easily. In addition, Android 4.2 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>3.11 Text-to-Speech</h3>
+<p>Android 4.2 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>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>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>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 style="text-align: center;">REQUIRED<br/>
+<small>Required for device implementations that include microphone hardware
+and define <code>android.hardware.microphone</code>.</small></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 style="text-align: center;">REQUIRED<br/>
+<small>Required for device implementations that include microphone hardware
+and define <code>android.hardware.microphone</code>.</small></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 style="text-align: center;">REQUIRED<br/>
+<small>Required for device implementations that include microphone hardware
+and define <code>android.hardware.microphone</code>.</small></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="4">Video</td>
+<td>H.263</td>
+<td style="text-align: center;">REQUIRED<br/>
+<small>Required for device implementations that include camera hardware
+and define <code>android.hardware.camera</code> or
+<code>android.hardware.camera.front</code>.</small></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 style="text-align: center;">REQUIRED<br/>
+<small>Required for device implementations that include camera hardware
+and define <code>android.hardware.camera</code> or
+<code>android.hardware.camera.front</code>.</small></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> </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>
+
+</tbody></table>
+*Note: Only downmix of 5.0/5.1 content is required; recording or rendering more than 2 channels is optional.
+**Note: 16-bit linear PCM capture is mandatory. 8-bit linear PCM capture is not mandatory.
+
+<a name="section-5.2"></a><h3>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 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 codec</th>
+ <td>H.264 Baseline Profile</td>
+ <td>H.264 Baseline Profile</td>
+ <td>H.264 Baseline Profile</td>
+ </tr>
+ <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>
+
+<a name="section-5.3"></a><h3>5.3 Video Decoding</h3>
+<p>Android device implementations SHOULD support the following VP8 video decoding profiles.</p>
+<div style="page-break-before: always;"></div>
+<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>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><b>Note:</b> while some of the requirements outlined above are stated as "SHOULD"
+for Android 4.2, the Compatibility Definition for a future version is planned
+to change these to "MUST". That is, these requirements are optional in Android
+4.2 but <b>will be required</b> by a future version. Existing and new devices
+that run Android 4.2 are <b>very strongly encouraged to meet
+these requirements in Android 4.2</b>, or they will not be able to attain
+Android compatibility when upgraded to the future version.</p>
+
+<a name="section-5.5"></a><h3>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 effects such sound
+effects or VOIP communication.</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>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>6. Developer Tools and Options Compatibility</h2>
+
+<a name="section-6.1"></a><h3>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>
+<p>Android 4.2.2 includes support for secure adb. Secure adb enables adb on known authenticated hosts.
+Existing and new devices that run Android 4.2.2 are <b>very strongly encouraged to meet
+this requirement in Android 4.2</b>, or they will not be able to attain
+Android compatibility when upgraded to the future version.</p>
+<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>6.2 Developer Options</h3>
+<p>Android 4.2 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-7"></a><h2>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>7.1. Display and Graphics</h3>
+<p>Android 4.2 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>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 between 1.3333 (4:3) and 1.85 (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>480 dpi, known as 'xxhdpi'</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>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>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>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 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 and 2.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 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 2.0.</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 4.2 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 4.2 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 4.2 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.2, 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 4.2 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>
+
+<a name="section-7.1.5"></a><h4>7.1.5. Legacy Application Compatibility Mode</h4>
+<p>Android 4.2 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>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 one or both of 1280x720,
+or 1920x1080 (that is, 720p or 1080p). 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>
+</ul>
+<p>For clarity, device implementations with variable pixel dimensions are
+restricted to 720p or 1080p in Android 4.2, and MUST be configured to report
+screen size and density buckets as noted above.</p>
+
+<a name="section-7.1.7"></a><h4>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>7.1.8. External Displays</h4>
+<p>Android 4.2 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.SECURE_FLAG</code>. Specifically, device implementations that declare support for <code>Display.SECURE_FLAG</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>7.2. Input Devices</h3>
+<a name="section-7.2.1"></a><h4>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>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>7.2.3. Navigation keys</h4>
+<p>The Home, Menu 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, gestures, touch panel, etc.
+Android 4.2 supports both implementations.</p>
+
+<p>Android 4.2 includes support for 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.
+This function MAY be implemented via hardware or software keys.</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>
+ <li>Device implementation MUST present a Menu key to applications when
+ targetSdkVersion <= 10 and SHOULD NOT present a Menu key when the
+ targetSdkVersion > 10.</li>
+</ul>
+
+<a name="section-7.2.4"></a><h4>7.2.4. Touchscreen input</h4>
+<p>Device implementations:</p>
+<ul>
+<li>MUST have a pointer input system of some kind (either mouse-like, or
+touch)</li>
+<li>MAY have a touchscreen of any modality (such as capacitive or resistive)</li>
+<li>SHOULD support fully independently tracked pointers, if a touchscreen
+supports multiple pointers</li>
+<li>MUST report the value of <code>android.content.res.Configuration</code>
+[<a href="#resources40">Resources, 39</a>]
+reflecting corresponding to the type of the specific touchscreen on the
+device</li>
+</ul>
+<p>Device implementations MUST report the correct feature corresponding to the
+type of input used. Note that Android 4.2 includes the feature
+<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 include a touchscreen (single-touch or better)
+MUST also report 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
+<code>android.hardware.faketouch</code>.</p>
+<a name="section-7.2.5"></a><h4>7.2.5. 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>7.3. Sensors</h3>
+<p>Android 4.2 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>The Android 4.2 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 4.2 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>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.2, the Compatibility Definition
+for a future version is planned to change these to "MUST". That is, these standards are
+optional in Android 4.2 but <b>will be required</b> in future versions. Existing and
+new devices that run Android 4.2 are <b>very strongly encouraged to meet these requirements
+in Android 4.2</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>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>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>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.2, the Compatibility Definition
+for a future version is planned to change these to "MUST". That is, these standards are
+optional in Android 4.2 but <b>will be required</b> in future versions. Existing and
+new devices that run Android 4.2 are <b>very strongly encouraged to meet these requirements
+in Android 4.2</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>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>7.3.7. Thermometer</h4>
+<p>Device implementations MAY but SHOULD NOT include a thermometer (i.e.
+temperature sensor.) If a device implementation does include a thermometer, it
+MUST measure the temperature of the device CPU. It MUST NOT measure any other
+temperature. (Note that this sensor type is deprecated in the Android 4.2
+APIs.)</p>
+<a name="section-7.3.7"></a><h4>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>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>7.4. Data Connectivity</h3>
+<a name="section-7.4.1"></a><h4>7.4.1. Telephony</h4>
+<p>"Telephony" as used by the Android 4.2 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 4.2 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 4.2 MAY be used on devices that do not include telephony hardware.
+That is, Android 4.2 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>7.4.2. IEEE 802.11 (WiFi)</h4>
+<p>Android 4.2 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 Wifi 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>7.4.2.1. WiFi Direct</h4>
+<p>Device implementations SHOULD include support for Wifi direct (Wifi peer-to-peer).
+If a device implementation does include support for Wifi 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 Wifi direct, then it:</p>
+<ul>
+ <li>MUST support regular Wifi operation</li>
+ <li>SHOULD support concurrent wifi and wifi Direct operation</li>
+</ul>
+
+<a name="section-7.4.3"></a><h4>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 [<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>The Compatibility Test Suite includes cases that cover basic operation of
+the Android RFCOMM Bluetooth API. However, since Bluetooth is a communications
+protocol between devices, it cannot be fully tested by unit tests running on a
+single device. Consequently, device implementations MUST also pass the
+human-driven Bluetooth test procedure described in Appendix A.</p>
+
+<a name="section-7.4.4"></a><h4>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" for Android 4.2, the Compatibility Definition for a future
+ version is planned to change these to "MUST". That is, these standards are
+ optional in Android 4.2 but <b>will be required</b> in future versions.
+ Existing and new devices that run Android 4.2 are <b>very strongly
+ encouraged to meet these requirements in Android 4.2</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 SHOULD use SNEP GET
+ requests for exchanging the handover request / select records over NFC, and it MUST
+ use the Bluetooth Object Push Profile for the actual Bluetooth data transfer.</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>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="#resources44">Resources, 44</a>])</li>
+ <li>MIFARE Ultralight (NXP MF0ICU1 [<a href="#resources46">Resources, 46</a>],
+ MF0ICU2 [<a href="#resources46">Resources, 46</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 4.2 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 4.2 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>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 (WiFi).</p>
+<p>Devices MAY implement more than one form of data connectivity.</p>
+
+
+<a name="section-7.5"></a><h3>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>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>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 4.2 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>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 4.2 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>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 dimention. 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>7.6. Memory and Storage</h3>
+<a name="section-7.6.1"></a><h4>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 MUST have at least 350MB of non-volatile storage
+available for application private data. That is, the <code>/data</code> partition MUST be at
+least 350MB.</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>7.6.2. Application Shared 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.</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) SHOULD modify the core
+applications such as the media scanner and ContentProvider to transparently
+support files placed in both locations.</p>
+
+<a name="section-7.7"></a><h3>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 4.2 are <b>very strongly encouraged to meet these requirements
+in Android 4.2</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 Android 4.2 are <b>very strongly
+encouraged to meet these requirements in Android 4.2</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 4.2 are <b>very strongly encouraged to meet these requirements in Android 4.2</b>
+so they will be able to upgrade to the future platform releases</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>8. Performance Compatibility</h2>
+<p>Device implementations MUST meet the key performance metrics of an Android
+4.2 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>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>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>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>9.3. Filesystem Permissions</h3>
+<p>Device implementations MUST support the Android file access permissions
+model as defined in as defined in the Security and Permissions reference [<a
+href="#resources54">Resources, 54</a>].</p>
+<a name="section-9.4"></a><h3>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>9.5. Multi-User Support </h3>
+<p>Android 4.2 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>
+</ul>
+</p>
+
+<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. The upstream Android open-source
+project includes an implementation that uses internal device storage for application external storage APIs; device implementations SHOULD use this configuration and software implementation.
+Device implementations that include multiple external storage paths MUST NOT allow Android applications to write to the secondary external storage</p>
+
+<a name="section-9.6"></a><h3>9.6. Premium SMS Warning</h3>
+<p>Android 4.2 includes support for warning users for any outgoing premium SMS message. 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-10"></a><h2>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 4.2 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>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.2. 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>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 Verfier only by the set of included
+locales, branding, etc. MAY omit the CTS Verifier test.</p>
+<a name="section-10.3"></a><h3>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 Android Market)</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>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>12. 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>
+
+<a name="appendix-A"></a><h2>Appendix A - Bluetooth Test Procedure</h2>
+<p>The Compatibility Test Suite includes cases that cover basic operation of
+the Android RFCOMM Bluetooth API. However, since Bluetooth is a communications
+protocol between devices, it cannot be fully tested by unit tests running on a
+single device. Consequently, device implementations MUST also pass the
+human-operated Bluetooth test procedure described below.</p>
+<p>The test procedure is based on the BluetoothChat sample app included in the
+Android open source project tree. The procedure requires two devices:</p>
+<ul>
+<li>a candidate device implementation running the software build to be tested</li>
+<li>a separate device implementation already known to be compatible, and of a
+ model from the device implementation being tested - that is, a "known
+ good" device implementation</li>
+</ul>
+<p>The test procedure below refers to these devices as the "candidate" and "known
+good" devices, respectively.</p>
+<h3>Setup and Installation</h3>
+<ol>
+<li>Build BluetoothChat.apk via 'make samples' from an Android source code tree</li>
+<li>Install BluetoothChat.apk on the known-good device</li>
+<li>Install BluetoothChat.apk on the candidate device</li>
+</ol>
+<h3>Test Bluetooth Control by Apps</h3>
+<ol>
+<li>Launch BluetoothChat on the candidate device, while Bluetooth is disabled</li>
+<li>Verify that the candidate device either turns on Bluetooth, or prompts the user with a dialog to turn on Bluetooth</li>
+</ol>
+<h3>Test Pairing and Communication</h3>
+<ol>
+<li>Launch the Bluetooth Chat app on both devices</li>
+<li>Make the known-good device discoverable from within BluetoothChat (using the Menu)</li>
+<li>On the candidate device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the known-good device</li>
+<li>Send 10 or more messages from each device, and verify that the other device receives them correctly</li>
+<li>Close the BluetoothChat app on both devices by pressing <b>Home</b></li>
+<li>Unpair each device from the other, using the device Settings app</li>
+</ol>
+<h3>Test Pairing and Communication in the Reverse Direction</h3>
+<ol>
+<li>Launch the Bluetooth Chat app on both devices.</li>
+<li>Make the candidate device discoverable from within BluetoothChat (using the Menu).</li>
+<li>On the known-good device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the candidate device.</li>
+<li>Send 10 or messages from each device, and verify that the other device receives them correctly.</li>
+<li>Close the Bluetooth Chat app on both devices by pressing Back repeatedly to get to the Launcher.</li>
+</ol>
+<h3>Test Re-Launches</h3>
+<ol>
+<li>Re-launch the Bluetooth Chat app on both devices.</li>
+<li>Send 10 or messages from each device, and verify that the other device receives them correctly.</li>
+</ol>
+<p>Note: the above tests have some cases which end a test section by using
+Home, and some using Back. These tests are not redundant and are not optional:
+the objective is to verify that the Bluetooth API and stack works correctly
+both when Activities are explicitly terminated (via the user pressing Back,
+which calls finish()), and implicitly sent to background (via the user
+pressing Home.) Each test sequence MUST be performed as described.</p>
+<div id="footerContent" xmlns:pdf="http://whatever">
+<pdf:pagenumber/>
+</div>
+</body>
+</html>
diff --git a/src/compatibility/4.3/android-4.3-cdd.xhtml b/src/compatibility/4.3/android-4.3-cdd.xhtml
new file mode 100644
index 0000000..65ffc5c
--- /dev/null
+++ b/src/compatibility/4.3/android-4.3-cdd.xhtml
@@ -0,0 +1,2661 @@
+<?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.3Compatibility 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.3 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: July 23, 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/>
+ </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/>
+ </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/>
+ </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 (WiFi)</a><br/>
+ <div style="margin-left: 2em;">
+ <a href="#section-7.4.2.1">7.4.2.1. WiFi Direct</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/>
+ </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. Application Shared 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/>
+ </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. Contact Us</a><br/>
+</div>
+
+<div style="page-break-before: always;"></div>
+
+<a name="section-1"></a><h2>1. Introduction</h2>
+<p>This document enumerates the requirements that must be met in order for
+devices to be compatible with Android 4.3.</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.3. A "device implementation" or "implementation" is the hardware/software
+solution so developed.</p>
+<p>To be considered compatible with Android 4.3, 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>2. Resources</h2>
+<ol>
+<a name="resources01"></a><li>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>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>Android Open Source Project: <a href="http://source.android.com/">http://source.android.com/</a></li>
+<a name="resources04"></a><li>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>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>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>Android 4.3 allowed version strings: <a href="http://source.android.com/compatibility/4.3/versions.html">http://source.android.com/compatibility/4.3/versions.html</a></li>
+<a name="resources08"></a><li>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>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>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>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>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>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>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>HTML5/W3C webdatabase API: <a href="http://www.w3.org/TR/webdatabase/">http://www.w3.org/TR/webdatabase/</a></li>
+<a name="resources16"></a><li>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>Dalvik Virtual Machine specification: available in the Android source code, at dalvik/docs</li>
+<a name="resources18"></a><li>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>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>Android Security and Permissions reference: <a href="http://developer.android.com/guide/topics/security/security.html">http://developer.android.com/guide/topics/security/security.html</a></li>
+<a name="resources55"></a><li>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>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>Android File Transfer: <a href="http://www.android.com/filetransfer">http://www.android.com/filetransfer</a></li>
+<a name="resources58"></a><li>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>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>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>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>Wifi 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>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>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>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>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>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>Wifi Direct (Wifi 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>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>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>External Storage reference: <a href="http://source.android.com/tech/storage">http://source.android.com/tech/storage</a></li>
+<a name="resources72"></a><li>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>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>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>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>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>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>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>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>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>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>
+</ol>
+<p>Many of these resources are derived directly or indirectly from the Android
+4.3 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>3. Software</h2>
+<a name="section-3.1"></a><h3>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 4.3 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>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>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>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>android.os.Build.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>android.os.Build.VERSION.SDK</td>
+<td>The version of the currently-executing Android system, in a format
+accessible to third-party application code. For Android 4.3, this
+field MUST have the integer value 18.</td>
+</tr>
+<tr>
+<td>android.os.Build.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.3, this
+field MUST have the integer value 18.</td>
+</tr>
+<tr>
+<td>android.os.Build.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>android.os.Build.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>android.os.Build.BRAND</td>
+<td>A value chosen by the device implementer identifying the name of the
+company, organization, individual, etc. who produced the device, in
+human-readable format. A possible use of this field is to indicate the OEM
+and/or carrier who sold 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>android.os.Build.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>android.os.Build.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>android.os.Build.DEVICE</td>
+<td>A value chosen by the device implementer identifying the specific
+configuration or revision of the body (sometimes called "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>android.os.Build.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/mydevice/generic:4.3/JRN53/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>android.os.Build.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>android.os.Build.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>android.os.Build.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>android.os.Build.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>android.os.Build.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>android.os.Build.PRODUCT</td>
+<td>A value chosen by the device implementer containing the development name
+or code name of the product (SKU). 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>android.os.Build.SERIAL</td>
+<td>A hardware serial number, if available. The value of this field MUST be encodable
+as 7-bit ASCII and match the regular expression
+<code>"^([a-zA-Z0-9]{0,20})$"</code>.</td>
+</tr>
+<tr>
+<td>android.os.Build.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>android.os.Build.TIME</td>
+<td>A value representing the timestamp of when the build occurred.</td>
+</tr>
+<tr>
+<td>android.os.Build.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>android.os.Build.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>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>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>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.2 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>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>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.3"></a><h3>3.3. Native API Compatibility</h3>
+<a name="section-3.3.1"></a><h4>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</li>
+<li>MUST report only those ABIs documented in the latest version of the
+Android NDK, in the file <code>docs/CPU-ARCH-ABIS.txt</code></li>
+<li>SHOULD be built using the source code and header files available in the
+upstream Android Open Source Project</li>
+</ul>
+<p>The following native code APIs MUST be available to apps that include
+native code:</p>
+<ul>
+<li>libc (C library)</li>
+<li>libm (math library)</li>
+<li>Minimal support for C++</li>
+<li>JNI interface</li>
+<li>liblog (Android logging)</li>
+<li>libz (Zlib compression)</li>
+<li>libdl (dynamic linker)</li>
+<li>libGLESv1_CM.so (OpenGL ES 1.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>3.4. Web Compatibility</h3>
+<a name="section-3.4.1"></a><h4>3.4.1. WebView Compatibility</h4>
+<p>The Android Open Source implementation uses the WebKit rendering engine 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 WebKit in the WebView
+implementation. Specifically:</p>
+<ul>
+<li>Device implementations' <code>android.webkit.WebView</code>
+implementations MUST be based on the 534.30 WebKit build from the upstream
+Android Open Source tree for Android 4.3. This build includes a specific set
+of functionality and security fixes for the WebView. Device implementers MAY
+include customizations to the WebKit implementation; however, any such
+customizations MUST NOT alter the behavior of the WebView, including rendering
+behavior.</li>
+<li>The user agent string reported by the WebView MUST be in this format:<br/>
+ <code>Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30</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 SHOULD follow the ISO conventions for country code and language, and SHOULD refer to the current configured locale of the device</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>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.
+Minimally, device implementations MUST support each of these APIs associated
+with HTML5 in the WebView:</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>
+<p>HTML5 APIs, like all JavaScript APIs, MUST be disabled by default in a
+WebView, unless the developer explicitly enables them via the usual Android
+APIs.</p>
+
+<a name="section-3.4.2"></a><h4>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>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>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>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>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>
+</tbody>
+</table>
+
+<a name="section-3.8"></a><h3>3.8. User Interface Compatibility</h3>
+
+<a name="section-3.8.1"></a><h4>3.8.1. Launcher (Home Screen)</h4>
+<p>Android 4.3 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>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>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 4.3 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>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>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>3.8.6. Themes</h4>
+<p>Android provides "themes" as a mechanism for applications to apply styles
+across an entire Activity or application. Android 4.3 includes a "Holo"
+or "holographic" theme 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 4.3 includes a new "Device Default" theme 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>
+
+<a name="section-3.8.7"></a><h4>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>3.8.8. Recent Application Display</h4>
+<p>The upstream Android 4.3 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 4.3 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>3.8.9. Input Management </h4>
+<p>Android 4.3 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>3.8.10. Lock Screen Media Remote Control</h4>
+<p>Android 4.3 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>3.8.11. Dreams</h4>
+<p>Android 4.3 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.9"></a><h3>3.9 Device Administration</h3>
+<p>Android 4.3 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>
+
+<a name="section-3.10"></a><h3>3.10 Accessibility</h3>
+<p>Android 4.3 provides an accessibility layer that helps users with disabilities
+to navigate their devices more easily. In addition, Android 4.3 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>3.11 Text-to-Speech</h3>
+<p>Android 4.3 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>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>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>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="4">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>
+
+</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>
+</ul>
+
+<a name="section-5.2"></a><h3>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>5.3 Video Decoding</h3>
+<p>Android device implementations SHOULD support the following VP8 and H.264 video decoding 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>8 Mbps</td>
+ <td>20 Mbps</td>
+ </tr>
+ </tbody>
+</table>
+
+<a name="section-5.4"></a><h3>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><b>Note:</b> while some of the requirements outlined above are stated as "SHOULD"
+for 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.3 but <b>will be required</b> by a future version. Existing and new devices
+that run Android 4.3 are <b>very strongly encouraged to meet
+these requirements in Android 4.3</b>, or they will not be able to attain
+Android compatibility when upgraded to the future version.</p>
+
+<a name="section-5.5"></a><h3>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>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>6. Developer Tools and Options Compatibility</h2>
+
+<a name="section-6.1"></a><h3>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 4.3 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>6.2 Developer Options</h3>
+<p>Android 4.3 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-7"></a><h2>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>7.1. Display and Graphics</h3>
+<p>Android 4.3 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>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 between 1.3333 (4:3) and 1.85 (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>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>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>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>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 4.3 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 4.3 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 4.3 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.3, 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 4.3 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 4.3 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>7.1.5. Legacy Application Compatibility Mode</h4>
+<p>Android 4.3 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>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 one or both of 1280x720,
+or 1920x1080 (that is, 720p or 1080p). 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>
+</ul>
+<p>For clarity, device implementations with variable pixel dimensions are
+restricted to 720p or 1080p in Android 4.3, and MUST be configured to report
+screen size and density buckets as noted above.</p>
+
+<a name="section-7.1.7"></a><h4>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>7.1.8. External Displays</h4>
+<p>Android 4.3 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>7.2. Input Devices</h3>
+<a name="section-7.2.1"></a><h4>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>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>7.2.3. Navigation keys</h4>
+<p>The Home, Menu 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, gestures, touch panel, etc.
+Android 4.3 supports both implementations.</p>
+
+<p>Android 4.3 includes support for 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.
+This function MAY be implemented via hardware or software keys.</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>
+ <li>Device implementation MUST present a Menu key to applications when
+ targetSdkVersion <= 10 and SHOULD NOT present a Menu key when the
+ targetSdkVersion > 10.</li>
+</ul>
+<a name="section-7.2.4"></a><h4>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 4.3 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>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>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>7.3. Sensors</h3>
+<p>Android 4.3 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>The Android 4.3 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 4.3 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>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.3, the Compatibility Definition
+for a future version is planned to change these to "MUST". That is, these standards are
+optional in Android 4.3 but <b>will be required</b> in future versions. Existing and
+new devices that run Android 4.3 are <b>very strongly encouraged to meet these requirements
+in Android 4.3</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>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>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>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.3, the Compatibility Definition
+for a future version is planned to change these to "MUST". That is, these standards are
+optional in Android 4.3 but <b>will be required</b> in future versions. Existing and
+new devices that run Android 4.3 are <b>very strongly encouraged to meet these requirements
+in Android 4.3</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>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>7.3.6. Thermometer</h4>
+<p>Device implementations MAY but SHOULD NOT include a thermometer (i.e.
+temperature sensor.) If a device implementation does include a thermometer, it
+MUST measure the temperature of the device CPU. It MUST NOT measure any other
+temperature. (Note that this sensor type is deprecated in the Android 4.3
+APIs.)</p>
+<a name="section-7.3.7"></a><h4>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>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>7.4. Data Connectivity</h3>
+<a name="section-7.4.1"></a><h4>7.4.1. Telephony</h4>
+<p>"Telephony" as used by the Android 4.3 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 4.3 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 4.3 MAY be used on devices that do not include telephony hardware.
+That is, Android 4.3 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>7.4.2. IEEE 802.11 (WiFi)</h4>
+<p>Android 4.3 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 Wifi 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>7.4.2.1. WiFi Direct</h4>
+<p>Device implementations SHOULD include support for Wifi direct (Wifi peer-to-peer).
+If a device implementation does include support for Wifi 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 Wifi direct, then it:</p>
+<ul>
+ <li>MUST support regular Wifi operation</li>
+ <li>SHOULD support concurrent wifi and wifi Direct operation</li>
+</ul>
+
+<a name="section-7.4.3"></a><h4>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>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" for Android 4.3, the Compatibility Definition for a future
+ version is planned to change these to "MUST". That is, these standards are
+ optional in Android 4.3 but <b>will be required</b> in future versions.
+ Existing and new devices that run Android 4.3 are <b>very strongly
+ encouraged to meet these requirements in Android 4.3</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 SHOULD use SNEP GET
+ requests for exchanging the handover request / select records over NFC, and it MUST
+ use the Bluetooth Object Push Profile for the actual Bluetooth data transfer.</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>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 4.3 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 4.3 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>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 (WiFi).</p>
+<p>Devices MAY implement more than one form of data connectivity.</p>
+
+
+<a name="section-7.5"></a><h3>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>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>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 4.3 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>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 4.3 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>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>7.6. Memory and Storage</h3>
+<a name="section-7.6.1"></a><h4>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 MUST have at least 512MB of non-volatile storage available
+for application private data. That is, the <code>/data</code> partition MUST be at
+least 512MB. Device implementations that run Android 4.3 are <b>very strongly encouraged to
+have at least 1GB 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>7.6.2. Application Shared 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.</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) SHOULD modify the core
+applications such as the media scanner and ContentProvider to transparently
+support files placed in both locations.</p>
+
+<a name="section-7.7"></a><h3>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 4.3 are <b>very strongly encouraged to meet these requirements
+in Android 4.3</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 Android 4.3 are <b>very strongly
+encouraged to meet these requirements in Android 4.3</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 4.3 are <b>very strongly encouraged to meet these requirements in Android 4.3</b>
+so they will be able to upgrade to the future platform releases</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>8. Performance Compatibility</h2>
+<p>Device implementations MUST meet the key performance metrics of an Android
+4.3 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>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>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>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>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>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>9.5. Multi-User Support </h3>
+<p>Android 4.3 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 4.3 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. The upstream Android Open Source
+Project includes an implementation that uses internal device storage for application external storage APIs; device implementations SHOULD use this configuration and software implementation.
+Device implementations that include multiple external storage paths MUST NOT allow Android applications to write to the secondary external storage.</p>
+
+<a name="section-9.6"></a><h3>9.6. Premium SMS Warning</h3>
+<p>Android 4.3 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>9.7. Kernel Security Features</h3>
+<p>The Android Sandbox in Android 4.3 includes features that can use the SELinux
+mandatory access control system (MAC) and other security features in the Linux kernel.
+Device implementations MUST support SELinux MAC. Note that the upstream Android Open Source
+Project provides an implementation that satisfies this requirement.</p>
+
+<p>SELinux or any security features implemented below the Android framework MUST maintain
+compatibility with existing applications. These features SHOULD be invisible to users and developers.
+These features SHOULD NOT be user or developer configurable. 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. To ensure continued compatibility the
+reference implementation allows the use of SELinux in a permissive mode and supports dynamic policy updates
+without requiring a system image update. Device implementations using SELinux MUST support this permissive
+mode, support dynamic policy updates and log any policy violations without breaking applications or affecting
+system behavior. Implementations using SELinux SHOULD load policy from <code>/sepolicy</code> file on the device.
+The upstream Android Open Source Project provides an implementation that satisfies this requirement.
+Device implementations SHOULD use the reference implementation in the Android Open Source Project, and
+device implementations MUST be compatible with the upstream Android Open Source Project.</p>
+
+<a name="section-10"></a><h2>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 4.3 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>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.3. 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>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>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>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>12. 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>