Docs: Adding source files for older PDFs to ease diffing
Bug: 18341319
Change-Id: I074181c486b6d338f4ab5c5dde5f76c2afb6142a
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>