Android 4.2 Cdd

Android 4.2 Compatibility DefinitionRevision 2Last updated: Feb 17, 2013

Copyright 2012, Google Inc. All rights [email protected]

Table of Contents1. Introduction2. Resources3. Software

3.1. Managed API Compatibility3.2. Soft API Compatibility

3.2.1. Permissions3.2.2. Build Parameters3.2.3. Intent Compatibility

3.2.3.1. Core Application Intents3.2.3.2. Intent Overrides3.2.3.3. Intent Namespaces3.2.3.4. Broadcast Intents

3.3. Native API Compatibility3.3.1 Application Binary Interfaces

3.4. Web Compatibility3.4.1. WebView Compatibility3.4.2. Browser Compatibility

3.5. API Behavioral Compatibility3.6. API Namespaces3.7. Virtual Machine Compatibility3.8. User Interface Compatibility

3.8.1. Widgets3.8.2. Notifications3.8.3. Search3.8.4. Toasts3.8.5. Themes3.8.6. Live Wallpapers3.8.7. Recent Application Display3.8.8. Input Management Settings3.8.9. Lock and Home Screen Widgets3.8.10. Lock Screen Media Remote Control3.8.11. Dreams

3.9 Device Administration3.10 Accessibility3.11 Text-to-Speech

4. Application Packaging Compatibility5. Multimedia Compatibility

5.1. Media Codecs5.2. Video Encoding5.3. Video Decoding5.4. Audio Recording5.5. Audio Latency5.6. Network Protocols

6. Developer Tools and Options Compatibility6.1. Developer Tools6.2. Developer Options

7. Hardware Compatibility7.1. Display and Graphics

7.1.1. Screen Configuration7.1.2. Display Metrics7.1.3. Screen Orientation7.1.4. 2D and 3D Graphics Accleration7.1.5. Legacy Application Compatibility Mode7.1.6. Screen Types7.1.7. Screen Technology7.1.8. External Displays

7.2. Input Devices7.2.1. Keyboard7.2.2. Non-touch Navigation

7.2.3. Navigation keys7.2.4. Touchscreen input

7.3. Sensors7.3.1. Accelerometer7.3.2. Magnetometer7.3.3. GPS7.3.4. Gyroscope7.3.5. Barometer7.3.6. Thermometer7.3.7. Photometer7.3.8. Proximity Sensor

7.4. Data Connectivity7.4.1. Telephony7.4.2. IEEE 802.11 (WiFi)

7.4.2.1. WiFi Direct7.4.3. Bluetooth7.4.4. Near-Field Communications7.4.5. Minimum Network Capability

7.5. Cameras7.5.1. Rear-Facing Camera7.5.2. Front-Facing Camera7.5.3. Camera API Behavior7.5.4. Camera Orientation

7.6. Memory and Storage7.6.1. Minimum Memory and Storage7.6.2. Application Shared Storage

7.7. USB8. Performance Compatibility9. Security Model Compatibility

9.1. Permissions9.2. UID and Process Isolation9.3. Filesystem Permissions9.4. Alternate Execution Environments9.5. Multi-User Support9.6. Premium SMS Warning

10. Software Compatibility Testing10.1. Compatibility Test Suite10.2. CTS Verifier10.3. Reference Applications

11. Updatable Software12. Contact UsAppendix A - Bluetooth Test Procedure

1. IntroductionThis document enumerates the requirements that must be met in order for devices tobe compatible with Android 4.2.

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[Resources, 1].

As used in this document, a "device implementer" or "implementer" is a person ororganization developing a hardware/software solution running Android 4.2. A"device implementation" or "implementation" is the hardware/software solution sodeveloped.

To be considered compatible with Android 4.2, device implementations MUST meetthe requirements presented in this Compatibility Definition, including any documentsincorporated via reference.

Where this definition or the software tests described in Section 10 is silent,ambiguous, or incomplete, it is the responsibility of the device implementer to ensurecompatibility with existing implementations.

For this reason, the Android Open Source Project [Resources, 3] is both thereference and preferred implementation of Android. Device implementers arestrongly encouraged to base their implementations to the greatest extent possible onthe "upstream" source code available from the Android Open Source Project. Whilesome components can hypothetically be replaced with alternate implementationsthis practice is strongly discouraged, as passing the software tests will becomesubstantially more difficult. It is the implementer's responsibility to ensure fullbehavioral compatibility with the standard Android implementation, including andbeyond the Compatibility Test Suite. Finally, note that certain componentsubstitutions and modifications are explicitly forbidden by this document.

2. Resources1. IETF RFC2119 Requirement Levels: http://www.ietf.org/rfc/rfc2119.txt2. Android Compatibility Program Overview:

http://source.android.com/compatibility/index.html3. Android Open Source Project: http://source.android.com/4. API definitions and documentation:

http://developer.android.com/reference/packages.html5. Android Permissions reference:

http://developer.android.com/reference/android/Manifest.permission.html6. android.os.Build reference:

http://developer.android.com/reference/android/os/Build.html7. Android 4.2 allowed version strings:

http://source.android.com/compatibility/4.2/versions.html8. Renderscript:

http://developer.android.com/guide/topics/graphics/renderscript.html9. Hardware Acceleration:

http://developer.android.com/guide/topics/graphics/hardware-accel.html10. android.webkit.WebView class:

http://developer.android.com/reference/android/webkit/WebView.html11. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/12. HTML5 offline capabilities: http://dev.w3.org/html5/spec/Overview.html#offline13. HTML5 video tag: http://dev.w3.org/html5/spec/Overview.html#video14. HTML5/W3C geolocation API: http://www.w3.org/TR/geolocation-API/15. HTML5/W3C webdatabase API: http://www.w3.org/TR/webdatabase/16. HTML5/W3C IndexedDB API: http://www.w3.org/TR/IndexedDB/17. Dalvik Virtual Machine specification: available in the Android source code, at

dalvik/docs18. AppWidgets:

http://developer.android.com/guide/practices/ui_guidelines/widget_design.html19. Notifications:

http://developer.android.com/guide/topics/ui/notifiers/notifications.html20. Application Resources: http://code.google.com/android/reference/available-

resources.html21. Status Bar icon style guide:

http://developer.android.com/guide/practices/ui_guidelines/icon_design_status_bar.html22. Search Manager:

http://developer.android.com/reference/android/app/SearchManager.html23. Toasts: http://developer.android.com/reference/android/widget/Toast.html24. Themes: http://developer.android.com/guide/topics/ui/themes.html

25. R.style class: http://developer.android.com/reference/android/R.style.html26. Live Wallpapers: http://developer.android.com/resources/articles/live-

wallpapers.html27. Android Device Administration:

http://developer.android.com/guide/topics/admin/device-admin.html28. DevicePolicyManager reference:

http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html29. Android Accessibility Service APIs:

http://developer.android.com/reference/android/accessibilityservice/package-summary.html

30. Android Accessibility APIs:http://developer.android.com/reference/android/view/accessibility/package-summary.html

31. Eyes Free project: http://code.google.com/p/eyes-free32. Text-To-Speech APIs:

http://developer.android.com/reference/android/speech/tts/package-summary.html

33. Reference tool documentation (for adb, aapt, ddms, systrace):http://developer.android.com/guide/developing/tools/index.html

34. Android apk file description:http://developer.android.com/guide/topics/fundamentals.html

35. Manifest files: http://developer.android.com/guide/topics/manifest/manifest-intro.html

36. Monkey testing tool:http://developer.android.com/guide/developing/tools/monkey.html

37. Android android.content.pm.PackageManager class and Hardware FeaturesList:http://developer.android.com/reference/android/content/pm/PackageManager.html

38. Supporting Multiple Screens:http://developer.android.com/guide/practices/screens_support.html

39. android.util.DisplayMetrics:http://developer.android.com/reference/android/util/DisplayMetrics.html

40. android.content.res.Configuration:http://developer.android.com/reference/android/content/res/Configuration.html

41. android.hardware.SensorEvent:http://developer.android.com/reference/android/hardware/SensorEvent.html

42. Bluetooth API:http://developer.android.com/reference/android/bluetooth/package-summary.html

43. NDEF Push Protocol: http://source.android.com/compatibility/ndef-push-protocol.pdf

44. MIFARE MF1S503X:http://www.nxp.com/documents/data_sheet/MF1S503x.pdf

45. MIFARE MF1S703X:http://www.nxp.com/documents/data_sheet/MF1S703x.pdf

46. MIFARE MF0ICU1: http://www.nxp.com/documents/data_sheet/MF0ICU1.pdf47. MIFARE MF0ICU2:

http://www.nxp.com/documents/short_data_sheet/MF0ICU2_SDS.pdf48. MIFARE AN130511:

http://www.nxp.com/documents/application_note/AN130511.pdf49. MIFARE AN130411:

http://www.nxp.com/documents/application_note/AN130411.pdf50. Camera orientation API:

http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)51. Camera:

http://developer.android.com/reference/android/hardware/Camera.html52. Android Open Accessories:

http://developer.android.com/guide/topics/usb/accessory.html53. USB Host API: http://developer.android.com/guide/topics/usb/host.html54. Android Security and Permissions reference:

http://developer.android.com/guide/topics/security/security.html55. Apps for Android: http://code.google.com/p/apps-for-android56. Android DownloadManager:

http://developer.android.com/reference/android/app/DownloadManager.html57. Android File Transfer: http://www.android.com/filetransfer58. Android Media Formats: http://developer.android.com/guide/appendix/media-

formats.html59. HTTP Live Streaming Draft Protocol: http://tools.ietf.org/html/draft-pantos-http-

live-streaming-0360. NFC Connection Handover: http://www.nfc-

forum.org/specs/spec_list/#conn_handover61. Bluetooth Secure Simple Pairing Using NFC: http://www.nfc-

forum.org/resources/AppDocs/NFCForum_AD_BTSSP_1_0.pdf62. Wifi Multicast API:

http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html63. Action Assist:

http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST64. USB Charging Specification:

http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf65. Android Beam: http://developer.android.com/guide/topics/nfc/nfc.html66. Android USB Audio:

http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO67. Android NFC Sharing Settings:

http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS68. Wifi Direct (Wifi P2P):

http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html69. Lock and Home Screen Widget:

http://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html70. UserManager reference:

http://developer.android.com/reference/android/os/UserManager.html71. External Storage reference: http://source.android.com/tech/storage72. External Storage APIs:

http://developer.android.com/reference/android/os/Environment.html73. SMS Short Code: http://en.wikipedia.org/wiki/Short_code74. Media Remote Control Client:

http://developer.android.com/reference/android/media/RemoteControlClient.html75. Display Manager:

http://developer.android.com/reference/android/hardware/display/DisplayManager.html76. Dreams:

http://developer.android.com/reference/android/service/dreams/DreamService.html77. Android Application Development-Related Settings:

http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

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. Inany cases where this Compatibility Definition or the Compatibility Test Suitedisagrees with the SDK documentation, the SDK documentation is consideredauthoritative. Any technical details provided in the references included above areconsidered by inclusion to be part of this Compatibility Definition.

3. Software3.1. Managed API CompatibilityThe managed (Dalvik-based) execution environment is the primary vehicle forAndroid applications. The Android application programming interface (API) is the setof Android platform interfaces exposed to applications running in the managed VMenvironment. Device implementations MUST provide complete implementations,including all documented behaviors, of any documented API exposed by theAndroid 4.2 SDK [Resources, 4].

Device implementations MUST NOT omit any managed APIs, alter API interfaces orsignatures, deviate from the documented behavior, or include no-ops, except wherespecifically allowed by this Compatibility Definition.

This Compatibility Definition permits some types of hardware for which Androidincludes APIs to be omitted by device implementations. In such cases, the APIsMUST still be present and behave in a reasonable way. See Section 7 for specificrequirements for this scenario.

3.2. Soft API CompatibilityIn addition to the managed APIs from Section 3.1, Android also includes a significantruntime-only "soft" API, in the form of such things such as Intents, permissions, andsimilar aspects of Android applications that cannot be enforced at applicationcompile time.

3.2.1. Permissions

Device implementers MUST support and enforce all permission constants asdocumented by the Permission reference page [Resources, 5]. Note that Section 10lists additional requirements related to the Android security model.

3.2.2. Build Parameters

The Android APIs include a number of constants on the android.os.Build class

[Resources, 6] that are intended to describe the current device. To provideconsistent, meaningful values across device implementations, the table belowincludes additional restrictions on the formats of these values to which deviceimplementations MUST conform.

Parameter Comments

android.os.Build.VERSION.RELEASE The version of the currently-executing Android system, in human-readable format. This field MUST haveone of the string values defined in [Resources, 7].

android.os.Build.VERSION.SDK The version of the currently-executing Android system, in a format accessible to third-party applicationcode. For Android 4.2, this field MUST have the integer value 17.

android.os.Build.VERSION.SDK_INT The version of the currently-executing Android system, in a format accessible to third-party applicationcode. For Android 4.2, this field MUST have the integer value 17.

android.os.Build.VERSION.INCREMENTAL

A value chosen by the device implementer designating the specific build of the currently-executingAndroid system, in human-readable format. This value MUST NOT be re-used for different builds madeavailable to end users. A typical use of this field is to indicate which build number or source-controlchange identifier was used to generate the build. There are no requirements on the specific format of thisfield, except that it MUST NOT be null or the empty string ("").

android.os.Build.BOARD

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 boardpowering the device. The value of this field MUST be encodable as 7-bit ASCII and match the regularexpression "^[a-zA-Z0-9.,_-]+$".

android.os.Build.BRAND

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 theOEM and/or carrier who sold the device. The value of this field MUST be encodable as 7-bit ASCII andmatch the regular expression "^[a-zA-Z0-9.,_-]+$".

android.os.Build.CPU_ABI The name of the instruction set (CPU type + ABI convention) of native code. See Section 3.3: Native APICompatibility.

android.os.Build.CPU_ABI2 The name of the second instruction set (CPU type + ABI convention) of native code. See Section 3.3:Native API Compatibility.

android.os.Build.DEVICEA 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-bitASCII and match the regular expression "^[a-zA-Z0-9.,_-]+$".

android.os.Build.FINGERPRINT

A string that uniquely identifies this build. It SHOULD be reasonably human-readable. It MUST follow thistemplate: $(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)For example: acme/mydevice/generic:4.2/JRN53/3359:userdebug/test-keysThe fingerprint MUST NOT include whitespace characters. If other fields included in the template abovehave whitespace characters, they MUST be replaced in the build fingerprint with another character, suchas the underscore ("_") character. The value of this field MUST be encodable as 7-bit ASCII.

android.os.Build.HARDWAREThe name of the hardware (from the kernel command line or /proc). It SHOULD be reasonably human-readable. The value of this field MUST be encodable as 7-bit ASCII and match the regular expression"^[a-zA-Z0-9.,_-]+$".

android.os.Build.HOST A string that uniquely identifies the host the build was built on, in human readable format. There are norequirements on the specific format of this field, except that it MUST NOT be null or the empty string ("").

android.os.Build.ID

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 valuesufficiently meaningful for end users to distinguish between software builds. The value of this field MUSTbe encodable as 7-bit ASCII and match the regular expression "^[a-zA-Z0-9.,_-]+$".

android.os.Build.MANUFACTURER The trade name of the Original Equipment Manufacturer (OEM) of the product. There are no requirementson the specific format of this field, except that it MUST NOT be null or the empty string ("").

android.os.Build.MODELA 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 areno requirements on the specific format of this field, except that it MUST NOT be null or the empty string("").

android.os.Build.PRODUCT

A value chosen by the device implementer containing the development name or code name of theproduct (SKU). MUST be human-readable, but is not necessarily intended for view by end users. Thevalue of this field MUST be encodable as 7-bit ASCII and match the regular expression "^[a-zA-Z0-9.,_-]+$".

android.os.Build.SERIAL A hardware serial number, if available. The value of this field MUST be encodable as 7-bit ASCII andmatch the regular expression "^([a-zA-Z0-9]{0,20})$".

android.os.Build.TAGSA comma-separated list of tags chosen by the device implementer that further distinguish the build. Forexample, "unsigned,debug". The value of this field MUST be encodable as 7-bit ASCII and match the

regular expression "^[a-zA-Z0-9.,_-]+$".android.os.Build.TIME A value representing the timestamp of when the build occurred.

android.os.Build.TYPE

A value chosen by the device implementer specifying the runtime configuration of the build. This fieldSHOULD 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 theregular expression "^[a-zA-Z0-9.,_-]+$".

android.os.Build.USER A name or user ID of the user (or automated user) that generated the build. There are no requirements onthe specific format of this field, except that it MUST NOT be null or the empty string ("").

3.2.3. Intent Compatibility

Device implementations MUST honor Android's loose-coupling Intent system, asdescribed in the sections below. By "honored", it is meant that the deviceimplementer MUST provide an Android Activity or Service that specifies a matchingIntent filter and binds to and implements correct behavior for each specified Intentpattern.

3.2.3.1. Core Application Intents

The Android upstream project defines a number of core applications, such ascontacts, calendar, photo gallery, music player, and so on. Device implementersMAY replace these applications with alternative versions.

However, any such alternative versions MUST honor the same Intent patternsprovided by the upstream project. For example, if a device contains an alternativemusic player, it must still honor the Intent pattern issued by third-party applications topick a song.

The following applications are considered core Android system applications:

Desk ClockBrowserCalendarContactsGalleryGlobalSearchLauncherMusicSettings

The core Android system applications include various Activity, or Servicecomponents that are considered "public". That is, the attribute "android:exported"may be absent, or may have the value "true".

For every Activity or Service defined in one of the core Android system apps that isnot marked as non-public via an android:exported attribute with the value "false",device implementations MUST include a compontent of the same type implementingthe same Intent filter patterns as the core Android system app.

In other words, a device implementation MAY replace core Android system apps;however, if it does, the device implementation MUST support all Intent patternsdefined by each core Android system app being replaced.

3.2.3.2. Intent Overrides

As Android is an extensible platform, device implementations MUST allow eachIntent pattern referenced in Section 3.2.3.2 to be overridden by third-partyapplications. The upstream Android open source implementation allows this bydefault; device implementers MUST NOT attach special privileges to systemapplications' use of these Intent patterns, or prevent third-party applications frombinding to and assuming control of these patterns. This prohibition specificallyincludes but is not limited to disabling the "Chooser" user interface which allows theuser to select between multiple applications which all handle the same Intentpattern.

However, device implementations MAY provide default activities for specific URIpatterns (eg. http://play.google.com) if the default activity provides a more specificfilter 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://". Deviceimplementations MUST provide a user interface for users to modify the defaultactivity for intents.

3.2.3.3. Intent Namespaces

Device implementations MUST NOT include any Android component that honorsany new Intent or Broadcast Intent patterns using an ACTION, CATEGORY, or otherkey string in the android.* or com.android.* namespace. Device implementers MUSTNOT include any Android components that honor any new Intent or Broadcast Intentpatterns using an ACTION, CATEGORY, or other key string in a package spacebelonging to another organization. Device implementers MUST NOT alter or extendany of the Intent patterns used by the core apps listed in Section 3.2.3.1. Deviceimplementations MAY include Intent patterns using namespaces clearly andobviously associated with their own organization.

This prohibition is analogous to that specified for Java language classes in Section3.6.

3.2.3.4. Broadcast Intents

Third-party applications rely on the platform to broadcast certain Intents to notifythem of changes in the hardware or software environment. Android-compatibledevices MUST broadcast the public broadcast Intents in response to appropriatesystem events. Broadcast Intents are described in the SDK documentation.

3.3. Native API Compatibility3.3.1 Application Binary Interfaces

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 hardwarearchitecture. As native code is highly dependent on the underlying processortechnology, Android defines a number of Application Binary Interfaces (ABIs) in theAndroid NDK, in the file docs/CPU-ARCH-ABIS.html. If a device implementation iscompatible with one or more defined ABIs, it SHOULD implement compatibility withthe Android NDK, as below.

If a device implementation includes support for an Android ABI, it:

MUST include support for code running in the managed environment to callinto native code, using the standard Java Native Interface (JNI) semantics.MUST be source-compatible (i.e. header compatible) and binary-compatible(for the ABI) with each required library in the list belowMUST accurately report the native Application Binary Interface (ABI) supportedby the device, via the android.os.Build.CPU_ABI APIMUST report only those ABIs documented in the latest version of the AndroidNDK, in the file docs/CPU-ARCH-ABIS.txtSHOULD be built using the source code and header files available in theupstream Android open source project

The following native code APIs MUST be available to apps that include native code:

libc (C library)libm (math library)Minimal support for C++JNI interfaceliblog (Android logging)libz (Zlib compression)libdl (dynamic linker)libGLESv1_CM.so (OpenGL ES 1.0)libGLESv2.so (OpenGL ES 2.0)libEGL.so (native OpenGL surface management)libjnigraphics.solibOpenSLES.so (OpenSL ES 1.0.1 audio support)libOpenMAXAL.so (OpenMAX AL 1.0.1 support)libandroid.so (native Android activity support)Support for OpenGL, as described below

Note that future releases of the Android NDK may introduce support for additionalABIs. If a device implementation is not compatible with an existing predefined ABI, itMUST NOT report support for any ABI at all.

Native code compatibility is challenging. For this reason, it should be repeated thatdevice implementers are VERY strongly encouraged to use the upstreamimplementations of the libraries listed above to help ensure compatibility.

3.4. Web Compatibility3.4.1. WebView Compatibility

The Android Open Source implementation uses the WebKit rendering engine toimplement the android.webkit.WebView. Because it is not feasible to develop acomprehensive test suite for a web rendering system, device implementers MUSTuse the specific upstream build of WebKit in the WebView implementation.Specifically:

Device implementations' android.webkit.WebView implementations MUST bebased on the 534.30 WebKit build from the upstream Android Open Sourcetree for Android 4.2. This build includes a specific set of functionality andsecurity fixes for the WebView. Device implementers MAY includecustomizations to the WebKit implementation; however, any suchcustomizations MUST NOT alter the behavior of the WebView, includingrendering behavior.The user agent string reported by the WebView MUST be in this format:Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL)Build/$(BUILD)) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.2Mobile Safari/534.30

The value of the $(VERSION) string MUST be the same as the value forandroid.os.Build.VERSION.RELEASEThe value of the $(LOCALE) string SHOULD follow the ISO conventionsfor country code and language, and SHOULD refer to the currentconfigured locale of the deviceThe value of the $(MODEL) string MUST be the same as the value forandroid.os.Build.MODELThe value of the $(BUILD) string MUST be the same as the value forandroid.os.Build.IDDevice implementations MAY omit Mobile in the user agent string

The WebView component SHOULD include support for as much of HTML5[Resources, 11] as possible. Minimally, device implementations MUST support eachof these APIs associated with HTML5 in the WebView:

application cache/offline operation [Resources, 12]the tag [Resources, 13]geolocation [Resources, 14]

Additionally, device implementations MUST support the HTML5/W3C webstorageAPI [Resources, 15], and SHOULD support the HTML5/W3C IndexedDB API[Resources, 16]. Note that as the web development standards bodies aretransitioning to favor IndexedDB over webstorage, IndexedDB is expected tobecome a required component in a future version of Android.

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.

3.4.2. Browser Compatibility

Device implementations MUST include a standalone Browser application forgeneral user web browsing. The standalone Browser MAY be based on a browsertechnology other than WebKit. However, even if an alternate Browser application isused, the android.webkit.WebView component provided to third-party applicationsMUST be based on WebKit, as described in Section 3.4.1.

Implementations MAY ship a custom user agent string in the standalone Browserapplication.

The standalone Browser application (whether based on the upstream WebKitBrowser application or a third-party replacement) SHOULD include support for asmuch of HTML5 [Resources, 11] as possible. Minimally, device implementationsMUST support each of these APIs associated with HTML5:

application cache/offline operation [Resources, 12]the tag [Resources, 13]geolocation [Resources, 14]

Additionally, device implementations MUST support the HTML5/W3C webstorageAPI [Resources, 15], and SHOULD support the HTML5/W3C IndexedDB API[Resources, 16]. Note that as the web development standards bodies aretransitioning to favor IndexedDB over webstorage, IndexedDB is expected tobecome a required component in a future version of Android.

3.5. API Behavioral CompatibilityThe behaviors of each of the API types (managed, soft, native, and web) must beconsistent with the preferred implementation of the upstream Android open source

project [Resources, 3]. Some specific areas of compatibility are:

Devices MUST NOT change the behavior or semantics of a standard IntentDevices MUST NOT alter the lifecycle or lifecycle semantics of a particulartype of system component (such as Service, Activity, ContentProvider, etc.)Devices MUST NOT change the semantics of a standard permission

The above list is not comprehensive. The Compatibility Test Suite (CTS) testssignificant portions of the platform for behavioral compatibility, but not all. It is theresponsibility of the implementer to ensure behavioral compatibility with the AndroidOpen Source Project. For this reason, device implementers SHOULD use thesource code available via the Android Open Source Project where possible, ratherthan re-implement significant parts of the system.

3.6. API NamespacesAndroid follows the package and class namespace conventions defined by the Javaprogramming language. To ensure compatibility with third-party applications, deviceimplementers MUST NOT make any prohibited modifications (see below) to thesepackage namespaces:

java.*javax.*sun.*android.*com.android.*

Prohibited modifications include:

Device implementations MUST NOT modify the publicly exposed APIs on theAndroid platform by changing any method or class signatures, or by removingclasses or class fields.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.Device implementers MUST NOT add any publicly exposed elements (such asclasses or interfaces, or fields or methods to existing classes or interfaces) tothe APIs above.

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 thenamespaces noted above. Device implementers MAY make internal-onlymodifications, but those modifications MUST NOT be advertised or otherwiseexposed to developers.

Device implementers MAY add custom APIs, but any such APIs MUST NOT be in anamespace owned by or referring to another organization. For instance, deviceimplementers MUST NOT add APIs to the com.google.* or similar namespace; onlyGoogle may do so. Similarly, Google MUST NOT add APIs to other companies'namespaces. Additionally, if a device implementation includes custom APIs outsidethe standard Android namespace, those APIs MUST be packaged in an Androidshared library so that only apps that explicitly use them (via the mechanism) are affected by the increased memory usage of such APIs.

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 forcontributing changes and code, according to the information on that site.

Note that the restrictions above correspond to standard conventions for naming APIsin the Java programming language; this section simply aims to reinforce thoseconventions and make them binding through inclusion in this compatibility definition.

3.7. Virtual Machine CompatibilityDevice implementations MUST support the full Dalvik Executable (DEX) bytecodespecification and Dalvik Virtual Machine semantics [Resources, 17].

Device implementations MUST configure Dalvik to allocate memory in accordancewith the upstream Android platform, and as specified by the following table. (SeeSection 7.1.1 for screen size and screen density definitions.)

Note that memory values specified below are considered minimum values, anddevice implementations MAY allocate more memory per application.

Screen Size Screen Density Application Memorysmall / normal / large ldpi / mdpi 16MBsmall / normal / large tvdpi / hdpi 32MBsmall / normal / large xhdpi 64MBxlarge mdpi 32MBxlarge tvdpi / hdpi 64MBxlarge xhdpi 128MB

3.8. User Interface Compatibility3.8.1. Widgets

Android defines a component type and corresponding API and lifecycle that allowsapplications to expose an "AppWidget" to the end user [Resources, 18]. The AndroidOpen Source reference release includes a Launcher application that includes userinterface affordances allowing the user to add, view, and remove AppWidgets fromthe home screen.

Device implementations MAY substitute an alternative to the reference Launcher(i.e. home screen). Alternative Launchers SHOULD include built-in support forAppWidgets, and expose user interface affordances to add, configure, view, andremove AppWidgets directly within the Launcher. Alternative Launchers MAY omitthese user interface elements; however, if they are omitted, the deviceimplementation MUST provide a separate application accessible from the Launcherthat allows users to add, configure, view, and remove AppWidgets.

Device implementations MUST be capable of rendering widgets that are 4 x 4 in thestandard grid size. (See the App Widget Design Guidelines in the Android SDKdocumentation [Resources, 18] for details.

3.8.2. Notifications

Android includes APIs that allow developers to notify users of notable events[Resources, 19], using hardware and software features of the device.

Some APIs allow applications to perform notifications or attract attention usinghardware, specifically sound, vibration, and light. Device implementations MUSTsupport notifications that use hardware features, as described in the SDKdocumentation, and to the extent possible with the device implementation hardware.For instance, if a device implementation includes a vibrator, it MUST correctlyimplement the vibration APIs. If a device implementation lacks hardware, thecorresponding APIs MUST be implemented as no-ops. Note that this behavior isfurther detailed in Section 7.

Additionally, the implementation MUST correctly render all resources (icons, soundfiles, etc.) provided for in the APIs [Resources, 20], or in the Status/System Bar iconstyle guide [Resources, 21]. Device implementers MAY provide an alternative userexperience for notifications than that provided by the reference Android OpenSource implementation; however, such alternative notification systems MUSTsupport existing notification resources, as above.

Android 4.2 includes support for rich notifications, such as interactive Views forongoing notifications. Device implementations MUST properly display and executerich notifications, as documented in the Android APIs.

3.8.3. Search

Android includes APIs [Resources, 22] that allow developers to incorporate searchinto their applications, and expose their application's data into the global systemsearch. Generally speaking, this functionality consists of a single, system-wide userinterface that allows users to enter queries, displays suggestions as users type, anddisplays results. The Android APIs allow developers to reuse this interface toprovide search within their own apps, and allow developers to supply results to thecommon global search user interface.

Device implementations MUST include a single, shared, system-wide search userinterface capable of real-time suggestions in response to user input. Deviceimplementations MUST implement the APIs that allow developers to reuse this userinterface to provide search within their own applications. Device implementationsMUST implement the APIs that allow third-party applications to add suggestions tothe search box when it is run in global search mode. If no third-party applications areinstalled that make use of this functionality, the default behavior SHOULD be to

display web search engine results and suggestions.

3.8.4. Toasts

Applications can use the "Toast" API (defined in [Resources, 23]) to display shortnon-modal strings to the end user, that disappear after a brief period of time. Deviceimplementations MUST display Toasts from applications to end users in some high-visibility manner.

3.8.5. Themes

Android provides "themes" as a mechanism for applications to apply styles acrossan 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 tomatch the Holo theme look and feel as defined by the Android SDK [Resources, 24].Device implementations MUST NOT alter any of the Holo theme attributes exposedto applications [Resources, 25].

Android 4.2 includes a new "Device Default" theme as a set of defined styles forapplication developers to use if they want to match the look and feel of the devicetheme as defined by the device implementer. Device implementations MAY modifythe DeviceDefault theme attributes exposed to applications [Resources, 25].

3.8.6. Live Wallpapers

Android defines a component type and corresponding API and lifecycle that allowsapplications to expose one or more "Live Wallpapers" to the end user [Resources,26]. Live Wallpapers are animations, patterns, or similar images with limited inputcapabilities that display as a wallpaper, behind other applications.

Hardware is considered capable of reliably running live wallpapers if it can run alllive wallpapers, with no limitations on functionality, at a reasonable framerate withno adverse affects on other applications. If limitations in the hardware causewallpapers and/or applications to crash, malfunction, consume excessive CPU orbattery power, or run at unacceptably low frame rates, the hardware is consideredincapable of running live wallpaper. As an example, some live wallpapers may usean Open GL 1.0 or 2.0 context to render their content. Live wallpaper will not runreliably on hardware that does not support multiple OpenGL contexts because thelive wallpaper use of an OpenGL context may conflict with other applications thatalso use an OpenGL context.

Device implementations capable of running live wallpapers reliably as describedabove SHOULD implement live wallpapers. Device implementations determined tonot run live wallpapers reliably as described above MUST NOT implement livewallpapers.

3.8.7. Recent Application Display

The upstream Android 4.2 source code includes a user interface for displayingrecent applications using a thumbnail image of the application's graphical state atthe moment the user last left the application. Device implementations MAY alter oreliminate this user interface; however, a future version of Android is planned to makemore extensive use of this functionality. Device implementations are stronglyencouraged 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 afuture version of Android.

3.8.8. Input Management Settings

Android 4.2 includes support for Input Management Engines. The Android 4.2 APIsallow custom app IMEs to specify user-tunable settings. Device implementationsMUST include a way for the user to access IME settings at all times when an IMEthat provides such user settings is displayed.

3.8.9. Lock and Home Screen Widgets

Android 4.2 includes support for application widgets that users can embed in thehome screen or the lock screen (See the App Widget Design Guidelines in theAndroid SDK documentation [Resources, 69] for details). Application widgets allowquick access to application data and services without launching a new activity.Widgets declare support for usage on the home screen or the lock screen bydeclaring the android:widgetCategory manifest tag that tells the system where thewidget can be placed. Specifically, device implementations MUST meet thefollowing requirements.

Device implementations MUST support application widgets on the homescreen.Device implementations SHOULD support lock screen. If deviceimplementations include support for lock screen then device implementationsMUST support application widgets on the lock screen.

3.8.10. Lock Screen Media Remote Control

Android 4.2 includes support for Remote Control API that lets media applicationsintegrate with playback controls that are displayed in a remote view like the devicelock screen[Resources, 74]. Device implementations MUST include support forembedding remote controls in the device lock screen.

3.8.11. Dreams

Android 4.2 includes support for interactive screensavers called Dreams[Resources, 76]. Dreams allows users to interact with applications when a chargingdevice is idle, or docked in a desk dock. Device implementations MUST includesupport for Dreams and provide a settings option for users to configure Dreams.

3.9 Device AdministrationAndroid 4.2 includes features that allow security-aware applications to performdevice administration functions at the system level, such as enforcing passwordpolicies or performing remote wipe, through the Android Device Administration API[Resources, 27]. Device implementations MUST provide an implementation of theDevicePolicyManager class [Resources, 28], and SHOULD support the full range ofdevice administration policies defined in the Android SDK documentation[Resources, 27].

Note: while some of the requirements outlined above are stated as "SHOULD" forAndroid 4.2, device implementations that support lock screen MUST support devicepolicies to manage widgets on the lock screen as defined in the Android SDKdocumentation [Resources, 27].

Note: while some of the requirements outlined above are stated as "SHOULD" forAndroid 4.2, the Compatibility Definition for a future version is planned to changethese to "MUST". That is, these requirements are optional in Android 4.2 but will berequired by a future version. Existing and new devices that run Android 4.2 are verystrongly encouraged to meet these requirements in Android 4.2, or they will notbe able to attain Android compatibility when upgraded to the future version.

3.10 AccessibilityAndroid 4.2 provides an accessibility layer that helps users with disabilities tonavigate their devices more easily. In addition, Android 4.2 provides platform APIsthat enable accessibility service implementations to receive callbacks for user andsystem events and generate alternate feedback mechanisms, such as text-to-speech, haptic feedback, and trackball/d-pad navigation [Resources, 29]. Deviceimplementations MUST provide an implementation of the Android accessibilityframework consistent with the default Android implementation. Specifically, deviceimplementations MUST meet the following requirements.

Device implementations MUST support third party accessibility serviceimplementations through the android.accessibilityservice APIs [Resources,30].Device implementations MUST generate AccessibilityEvents and deliverthese events to all registered AccessibilityService implementations in amanner consistent with the default Android implementation.Device implementations MUST provide a user-accessible mechanism toenable and disable accessibility services, and MUST display this interface inresponse to the android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGSintent.

Additionally, device implementations SHOULD provide an implementation of anaccessibility service on the device, and SHOULD provide a mechanism for users toenable the accessibility service during device setup. An open sourceimplementation of an accessibility service is available from the Eyes Free project[Resources, 31].

3.11 Text-to-SpeechAndroid 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 [Resources, 32]. Device implementations MUST meet these requirementsrelated to the Android TTS framework:

Device implementations MUST support the Android TTS framework APIs andSHOULD include a TTS engine supporting the languages available on thedevice. Note that the upstream Android open source software includes a full-featured TTS engine implementation.Device implementations MUST support installation of third-party TTS engines.Device implementations MUST provide a user-accessible interface that allowsusers to select a TTS engine for use at the system level.

4. Application Packaging CompatibilityDevice implementations MUST install and run Android ".apk" files as generated bythe "aapt" tool included in the official Android SDK [Resources, 33].

Devices implementations MUST NOT extend either the .apk [Resources, 34],Android Manifest [Resources, 35], Dalvik bytecode [Resources, 17], or renderscriptbytecode formats in such a way that would prevent those files from installing andrunning correctly on other compatible devices. Device implementers SHOULD usethe reference upstream implementation of Dalvik, and the referenceimplementation's package management system.

5. Multimedia CompatibilityDevice implementations MUST include at least one form of audio output, such asspeakers, headphone jack, external speaker connection, etc.

5.1. Media CodecsDevice implementations MUST support the core media formats specified in theAndroid SDK documentation [Resources, 58] except where explicitly permitted inthis document. Specifically, device implementations MUST support the mediaformats, encoders, decoders, file types and container formats defined in the tablesbelow. All of these codecs are provided as software implementations in the preferredAndroid implementation from the Android Open Source Project.

Please note that neither Google nor the Open Handset Alliance make anyrepresentation that these codecs are unencumbered by third-party patents.Those intending to use this source code in hardware or software products areadvised that implementations of this code, including in open source softwareor shareware, may require patent licenses from the relevant patent holders.

Note that these tables do not list specific bitrate requirements for most video codecsbecause current device hardware does not necessarily support bitrates that mapexactly to the required bitrates specified by the relevant standards. Instead, deviceimplementations SHOULD support the highest bitrate practical on the hardware, upto the limits defined by the specifications.

Type Format /Codec Encoder Decoder DetailsFile Type(s) /

Container Formats

Audio

MPEG-4AAC Profile(AAC LC)

REQUIREDRequired for device implementations

that include microphone hardwareand define

android.hardware.microphone.

REQUIRED

Support formono/stereo/5.0/5.1*content withstandard samplingrates from 8 to 48kHz. 3GPP (.3gp)

MPEG-4(.mp4, .m4a)ADTS rawAAC (.aac,decode inAndroid3.1+,encode inAndroid4.0+, ADIFnotsupported)MPEG-TS(.ts, notseekable,Android3.0+)

MPEG-4 HEAAC Profile(AAC+)

REQUIRED for deviceimplementations that includemicrophone hardware anddefineandroid.hardware.microphone

REQUIRED

Support formono/stereo/5.0/5.1*content withstandard samplingrates from 16 to 48kHz.

MPEG-4 HEAAC v2Profile(enhancedAAC+)

REQUIRED

Support formono/stereo/5.0/5.1*content withstandard samplingrates from 16 to 48kHz.

MPEG-4AudioObject TypeER AACELD(EnhancedLow DelayAAC)

REQUIRED for deviceimplementations that includemicrophone hardware anddefineandroid.hardware.microphone

REQUIRED

Support formono/stereo contentwith standardsampling rates from16 to 48 kHz.

AMR-NB




REQUIRED 4.75 to 12.2 kbpssampled @ 8kHz 3GPP (.3gp)

AMR-WB




REQUIRED9 rates from 6.60kbit/s to 23.85 kbit/ssampled @ 16kHz

3GPP (.3gp)

FLAC REQUIRED(Android 3.1+)

Mono/Stereo (nomultichannel).Sample rates up to48 kHz (but up to44.1 kHz isrecommended ondevices with 44.1kHz output, as the48 to 44.1 kHzdownsampler doesnot include a low-pass filter). 16-bitrecommended; nodither applied for 24-bit.

FLAC (.flac) only

MP3 REQUIREDMono/Stereo 8-320Kbps constant(CBR) or variablebit-rate (VBR)

MP3 (.mp3)

MIDI REQUIRED

MIDI Type 0 and 1.DLS Version 1 and2. XMF and MobileXMF. Support forringtone formatsRTTTL/RTX, OTA,and iMelody

Type 0 and1 (.mid,.xmf, .mxmf)RTTTL/RTX(.rtttl, .rtx)OTA (.ota)iMelody(.imy)

Vorbis REQUIRED Ogg (.ogg)Matroska(.mkv)

PCM/WAVE REQUIRED REQUIRED

8-bit and 16-bitlinear PCM** (ratesup to limit ofhardware).DevicesMUST supportsampling rates forraw PCM recordingat 8000,16000 and44100 Hzfrequencies

WAVE (.wav)

Image

JPEG REQUIRED REQUIRED Base+progressive JPEG (.jpg)GIF REQUIRED GIF (.gif)PNG REQUIRED REQUIRED PNG (.png)BMP REQUIRED BMP (.bmp)WEBP REQUIRED REQUIRED WebP (.webp)

Video

H.263


that include camera hardware anddefine android.hardware.camera

orandroid.hardware.camera.front.

REQUIRED 3GPP (.3gp)MPEG-4(.mp4)

H.264 AVC


that include camera hardware anddefine android.hardware.camera

orandroid.hardware.camera.front.

REQUIRED Baseline Profile(BP)

3GPP (.3gp)MPEG-4(.mp4)MPEG-TS(.ts, AACaudio only,notseekable,Android3.0+)

MPEG-4 SP REQUIRED 3GPP (.3gp)

VP8 REQUIRED

(Android2.3.3+)

WebM (.webm)and Matroska(.mkv, Android4.0+)

*Note: Only downmix of 5.0/5.1 content is required; recording or rendering more than2 channels is optional. **Note: 16-bit linear PCM capture is mandatory. 8-bit linearPCM capture is not mandatory.

5.2 Video EncodingAndroid device implementations that include a rear-facing camera and declareandroid.hardware.camera SHOULD support the following video encoding profiles.

SD (Low quality) SD (High quality) HD (When supported byhardware)

Video codec H.264 BaselineProfileH.264 BaselineProfile H.264 Baseline Profile

Videoresolution 176 x 144 px 480 x 360 px 1280 x 720 px

Video framerate 12 fps 30 fps 30 fps

Video bitrate 56 Kbps 500 Kbps orhigher 2 Mbps or higher

Audio codec AAC-LC AAC-LC AAC-LCAudio

channels 1 (mono) 2 (stereo) 2 (stereo)

Audio bitrate 24 Kbps 128 Kbps 192 Kbps

5.3 Video DecodingAndroid device implementations SHOULD support the following VP8 videodecoding profiles.

SD (Lowquality)SD (Highquality)

HD 720p (When supported by

hardware)

HD 1080p (When supported by

hardware)Video

resolution320 x180 px

640 x 360px 1280 x 720 px 1920 x 1080 px

Videoframe rate 30 fps 30 fps 30 fps 30 fps

Videobitrate 800 Kbps 2 Mbps 8 Mbps 20 Mbps

5.4. Audio RecordingWhen an application has used the android.media.AudioRecord API to startrecording an audio stream, device implementations that include microphonehardware and declare android.hardware.microphone MUST sample and recordaudio with each of these behaviors:

The device SHOULD exhibit approximately flat amplitude versus frequencycharacteristics; specifically, 3 dB, from 100 Hz to 4000 HzAudio 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.PCM amplitude levels SHOULD linearly track input SPL changes over at leasta 30 dB range from -18 dB to +12 dB re 90 dB SPL at the microphone.Total harmonic distortion SHOULD be less than 1% for 1Khz at 90 dB SPLinput level.

In addition to the above recording specifications, when an application has startedrecording an audio stream using theandroid.media.MediaRecorder.AudioSource.VOICE_RECOGNITION audio source:

Noise reduction processing, if present, MUST be disabled.Automatic gain control, if present, MUST be disabled.

Note: while some of the requirements outlined above are stated as "SHOULD" forAndroid 4.2, the Compatibility Definition for a future version is planned to changethese to "MUST". That is, these requirements are optional in Android 4.2 but will berequired by a future version. Existing and new devices that run Android 4.2 are verystrongly encouraged to meet these requirements in Android 4.2, or they will notbe able to attain Android compatibility when upgraded to the future version.

5.5. Audio LatencyAudio latency is the time delay as an audio signal passes through a system. Manyclasses of applications rely on short latencies, to achieve real-time effects suchsound effects or VOIP communication.

For the purposes of this section:

"output latency" is defined as the interval between when an application writesa frame of PCM-coded data and when the corresponding sound can be heardby an external listener or observed by a transducer"cold output latency" is defined as the output latency for the first frame, whenthe audio output system has been idle and powered down prior to the request"continuous output latency" is defined as the output latency for subsequentframes, after the device is already playing audio"input latency" is the interval between when an external sound is presented tothe device and when an application reads the corresponding frame of PCM-coded data"cold input latency" is defined as the sum of lost input time and the inputlatency for the first frame, when the audio input system has been idle andpowered down prior to the request"continuous input latency" is defined as the input latency for subsequentframes, while the device is already capturing audio"OpenSL ES PCM buffer queue API" is the set of PCM-related OpenSL ESAPIs within Android NDK; see NDK_root/docs/opensles/index.html

Per Section 5, all compatible device implementations MUST include at least oneform of audio output. Device implementations SHOULD meet or exceed these outputlatency requirements:

cold output latency of 100 milliseconds or lesscontinuous output latency of 45 milliseconds or less

If a device implementation meets the requirements of this section after any initialcalibration when using the OpenSL ES PCM buffer queue API, for continuous outputlatency and cold output latency over at least one supported audio output device, itMAY report support for low-latency audio, by reporting the feature"android.hardware.audio.low-latency" via the android.content.pm.PackageManagerclass. [Resources, 37] Conversely, if the device implementation does not meet theserequirements it MUST NOT report support for low-latency audio.

Per Section 7.2.5, microphone hardware may be omitted by device implementations.

Device implementations that include microphone hardware and declareandroid.hardware.microphone SHOULD meet these input audio latencyrequirements:

cold input latency of 100 milliseconds or lesscontinuous input latency of 50 milliseconds or less

5.6. Network ProtocolsDevices MUST support the media network protocols for audio and video playbackas specified in the Android SDK documentation [Resources, 58]. Specifically,devices MUST support the following media network protocols:

RTSP (RTP, SDP)HTTP(S) progressive streamingHTTP(S) Live Streaming draft protocol, Version 3 [Resources, 59]

6. Developer Tools and OptionsCompatibility6.1 Developer ToolsDevice implementations MUST support the Android Developer Tools provided in theAndroid SDK. Specifically, Android-compatible devices MUST be compatible with:

Android Debug Bridge (known as adb) [Resources, 33]Device implementations MUST support all adb functions as documented in theAndroid SDK. The device-side adb daemon MUST be inactive by default, andthere MUST be a user-accessible mechanism to turn on the Android DebugBridge.

Android 4.2.2 includes support for secure adb. Secure adb enables adb onknown authenticated hosts. Existing and new devices that run Android 4.2.2are very strongly encouraged to meet this requirement in Android 4.2, orthey will not be able to attain Android compatibility when upgraded to the futureversion.

Dalvik Debug Monitor Service (known as ddms) [Resources, 33]Device implementations MUST support all ddms features as documented in theAndroid SDK. As ddms uses adb, support for ddms SHOULD be inactive bydefault, but MUST be supported whenever the user has activated the AndroidDebug Bridge, as above.Monkey [Resources, 36]Device implementations MUST include the Monkey framework, and make itavailable for applications to use.SysTrace [Resources, 33]Device implementations MUST support systrace tool as documented in theAndroid SDK. Systrace must be inactive by default, and there MUST be a user-accessible mechanism to turn on Systrace.

Most Linux-based systems and Apple Macintosh systems recognize Androiddevices using the standard Android SDK tools, without additional support; howeverMicrosoft Windows systems typically require a driver for new Android devices. (Forinstance, new vendor IDs and sometimes new device IDs require custom USBdrivers for Windows systems.) If a device implementation is unrecognized by the adbtool as provided in the standard Android SDK, device implementers MUST provideWindows drivers allowing developers to connect to the device using the adbprotocol. These drivers MUST be provided for Windows XP, Windows Vista,Windows 7, and Windows 8, in both 32-bit and 64-bit versions.

6.2 Developer OptionsAndroid 4.2 includes support for developers to configure application development-related settings. Device implementations MUST honor the

android.settings.APPLICATION_DEVELOPMENT_SETTINGS intent to showapplication development-related settings [Resources, 77]. The upstream Androidimplementation hides the Developer Options menu by default, and enables users tolaunch Developer Options after pressing seven (7) times on the Settings > AboutDevice > Build Number menu item. Device implementations MUST provide aconsistent experience for Developer Options. Specifically, device implementationsMUST hide Developer Options by default and MUST provide a mechanism toenable Developer Options that is consistent with the upstream Androidimplementation.

7. Hardware CompatibilityIf a device includes a particular hardware component that has a corresponding APIfor third-party developers, the device implementation MUST implement that API asdescribed in the Android SDK documentation. If an API in the SDK interacts with ahardware component that is stated to be optional and the device implementationdoes not possess that component:

complete class definitions (as documented by the SDK) for the component'sAPIs MUST still be presentthe API's behaviors MUST be implemented as no-ops in some reasonablefashionAPI methods MUST return null values where permitted by the SDKdocumentationAPI methods MUST return no-op implementations of classes where null valuesare not permitted by the SDK documentationAPI methods MUST NOT throw exceptions not documented by the SDKdocumentation

A typical example of a scenario where these requirements apply is the telephonyAPI: even on non-phone devices, these APIs must be implemented as reasonableno-ops.

Device implementations MUST accurately report accurate hardware configurationinformation via the getSystemAvailableFeatures() and hasSystemFeature(String)methods on the android.content.pm.PackageManager class. [Resources, 37]

7.1. Display and GraphicsAndroid 4.2 includes facilities that automatically adjust application assets and UIlayouts appropriately for the device, to ensure that third-party applications run wellon a variety of hardware configurations [Resources, 38]. Devices MUST properlyimplement these APIs and behaviors, as detailed in this section.

The units referenced by the requirements in this section are defined as follows:

"Physical diagonal size" is the distance in inches between two opposingcorners of the illuminated portion of the display."dpi" (meaning "dots per inch") is the number of pixels encompassed by alinear horizontal or vertical span of 1". Where dpi values are listed, bothhorizontal and vertical dpi must fall within the range."Aspect ratio" is the ratio of the longer dimension of the screen to the shorterdimension. For example, a display of 480x854 pixels would be 854 / 480 =1.779, or roughly "16:9".A "density-independent pixel" or ("dp") is the virtual pixel unit normalized to a160 dpi screen, calculated as: pixels = dps * (density / 160).

7.1.1. Screen Configuration

Screen Size

The Android UI framework supports a variety of different screen sizes, and allowsapplications to query the device screen size (aka "screen layout") viaandroid.content.res.Configuration.screenLayout with theSCREENLAYOUT_SIZE_MASK. Device implementations MUST report the correct screensize as defined in the Android SDK documentation [Resources, 38] and determinedby the upstream Android platform. Specifically, device implementations must reportthe correct screen size according to the following logical density-independent pixel(dp) screen dimensions.

Devices MUST have screen sizes of at least 426 dp x 320 dp ('small')Devices that report screen size 'normal' MUST have screen sizes of at least480 dp x 320 dpDevices that report screen size 'large' MUST have screen sizes of at least 640dp x 480 dp

Devices that report screen size 'xlarge' MUST have screen sizes of at least960 dp x 720 dp

In addition, devices MUST have screen sizes of at least 2.5 inches in physicaldiagonal size.

Devices MUST NOT change their reported screen size at any time.

Applications optionally indicate which screen sizes they support via the attribute in the AndroidManifest.xml file. Device implementations MUSTcorrectly honor applications' stated support for small, normal, large, and xlargescreens, as described in the Android SDK documentation.

Screen Aspect Ratio

The aspect ratio MUST be between 1.3333 (4:3) and 1.85 (16:9).

Screen Density

The Android UI framework defines a set of standard logical densities to helpapplication developers target application resources. Device implementations MUSTreport one of the following logical Android framework densities through theandroid.util.DisplayMetrics APIs, and MUST execute applications at thisstandard density.

120 dpi, known as 'ldpi'160 dpi, known as 'mdpi'213 dpi, known as 'tvdpi'240 dpi, known as 'hdpi'320 dpi, known as 'xhdpi'480 dpi, known as 'xxhdpi'

Device implementations SHOULD define the standard Android framework densitythat is numerically closest to the physical density of the screen, unless that logicaldensity pushes the reported screen size below the minimum supported. If thestandard Android framework density that is numerically closest to the physicaldensity results in a screen size that is smaller than the smallest supportedcompatible screen size (320 dp width), device implementations SHOULD report thenext lowest standard Android framework density.

7.1.2. Display Metrics

Device implementations MUST report correct values for all display metrics defined inandroid.util.DisplayMetrics [Resources, 39].

7.1.3. Screen Orientation

Devices MUST support dynamic orientation by applications to either portrait orlandscape screen orientation. That is, the device must respect the application'srequest for a specific screen orientation. Device implementations MAY select eitherportrait or landscape orientation as the default.

Devices MUST report the correct value for the device's current orientation, wheneverqueried via the android.content.res.Configuration.orientation,android.view.Display.getOrientation(), or other APIs.

Devices MUST NOT change the reported screen size or density when changingorientation.

Devices MUST report which screen orientations they support (android.hardware.screen.portrait and/or android.hardware.screen.landscape)and MUST report at least one supported orientation. For example, a device with afixed-orientation landscape screen, such as a television or laptop, MUST only reportandroid.hardware.screen.landscape.

7.1.4. 2D and 3D Graphics Acceleration

Device implementations MUST support both OpenGL ES 1.0 and 2.0, as embodiedand detailed in the Android SDK documentations. Device implementations MUSTalso support Android Renderscript, as detailed in the Android SDK documentation[Resources, 8].

Device implementations MUST also correctly identify themselves as supportingOpenGL ES 1.0 and 2.0. That is:

The managed APIs (such as via the GLES10.getString() method) MUSTreport support for OpenGL ES 1.0 and 2.0

The native C/C++ OpenGL APIs (that is, those available to apps vialibGLES_v1CM.so, libGLES_v2.so, or libEGL.so) MUST report support forOpenGL ES 1.0 and 2.0.

Device implementations MAY implement any desired OpenGL ES extensions.However, device implementations MUST report via the OpenGL ES managed andnative APIs all extension strings that they do support, and conversely MUST NOTreport extension strings that they do not support.

Note that Android 4.2 includes support for applications to optionally specify that theyrequire specific OpenGL texture compression formats. These formats are typicallyvendor-specific. Device implementations are not required by Android 4.2 toimplement any specific texture compression format. However, they SHOULDaccurately report any texture compression formats that they do support, via thegetString() method in the OpenGL API.

Android 4.2 includes a mechanism for applications to declare that they wanted toenable hardware acceleration for 2D graphics at the Application, Activity, Window orView level through the use of a manifest tag android:hardwareAccelerated or directAPI calls [Resources, 9].

In Android 4.2, device implementations MUST enable hardware acceleration bydefault, and MUST disable hardware acceleration if the developer so requests bysetting android:hardwareAccelerated="false" or disabling hardware accelerationdirectly through the Android View APIs.

In addition, device implementations MUST exhibit behavior consistent with theAndroid SDK documentation on hardware acceleration [Resources, 9].

Android 4.2 includes a TextureView object that lets developers directly integratehardware-accelerated OpenGL ES textures as rendering targets in a UI hierarchy.Device implementations MUST support the TextureView API, and MUST exhibitconsistent behavior with the upstream Android implementation.

7.1.5. Legacy Application Compatibility Mode

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 legacyapplications not developed for old versions of Android that pre-date screen-sizeindependence. Device implementations MUST include support for legacyapplication compatibility mode as implemented by the upstream Android opensource code. That is, device implementations MUST NOT alter the triggers orthresholds at which compatibility mode is activated, and MUST NOT alter thebehavior of the compatibility mode itself.

7.1.6. Screen Types

Device implementation screens are classified as one of two types:

Fixed-pixel display implementations: the screen is a single panel that supportsonly a single pixel width and height. Typically the screen is physicallyintegrated with the device. Examples include mobile phones, tablets, and soon.Variable-pixel display implementations: the device implementation either hasno embedded screen and includes a video output port such as VGA, HDMI ora wireless port for display, or has an embedded screen that can change pixeldimensions. Examples include televisions, set-top boxes, and so on.

Fixed-Pixel Device Implementations

Fixed-pixel device implementations MAY use screens of any pixel dimensions,provided that they meet the requirements defined this Compatibility Definition.

Fixed-pixel implementations MAY include a video output port for use with anexternal display. However, if that display is ever used for running apps, the deviceMUST meet the following requirements:

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.The device MUST report the same logical density as the fixed-pixel display.The device MUST report screen dimensions that are the same as, or veryclose to, the fixed-pixel display.

For example, a tablet that is 7" diagonal size with a 1024x600 pixel resolution isconsidered a fixed-pixel large mdpi display implementation. If it contains a videooutput 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, regardlessof whether the fixed-pixel display or video output port is in use.

Variable-Pixel Device Implementations

Variable-pixel device implementations MUST support one or both of 1280x720, or1920x1080 (that is, 720p or 1080p). Device implementations with variable-pixeldisplays MUST NOT support any other screen configuration or mode. Deviceimplementations with variable-pixel screens MAY change screen configuration ormode at runtime or boot-time. For example, a user of a set-top box may replace a720p display with a 1080p display, and the device implementation may adjustaccordingly.

Additionally, variable-pixel device implementations MUST report the followingconfiguration buckets for these pixel dimensions:

1280x720 (also known as 720p): 'large' screen size, 'tvdpi' (213 dpi) density1920x1080 (also known as 1080p): 'large' screen size, 'xhdpi' (320 dpi) density

For clarity, device implementations with variable pixel dimensions are restricted to720p or 1080p in Android 4.2, and MUST be configured to report screen size anddensity buckets as noted above.

7.1.7. Screen Technology

The Android platform includes APIs that allow applications to render rich graphics tothe display. Devices MUST support all of these APIs as defined by the Android SDKunless specifically allowed in this document. Specifically:

Devices MUST support displays capable of rendering 16-bit color graphicsand SHOULD support displays capable of 24-bit color graphics.Devices MUST support displays capable of rendering animations.The display technology used MUST have a pixel aspect ratio (PAR) between0.9 and 1.1. That is, the pixel aspect ratio MUST be near square (1.0) with a10% tolerance.

7.1.8. External Displays

Android 4.2 includes support for secondary display to enable media sharingcapabilities and developer APIs for accessing external displays. If a device supportsan external display either via a wired, wireless or an embedded additional displayconnection then the device implementation MUST implement the display managerAPI as described in the Android SDK documentation [Resources, 75]. Deviceimplementations that support secure video output and are capable of supportingsecure surfaces MUST declare support for Display.SECURE_FLAG. Specifically,device implementations that declare support for Display.SECURE_FLAG, MUSTsupport HDCP 2.x or higher for Miracast wireless displays or HDCP 1.2 or higherfor wired displays. The upstream Android open source implementation includessupport for wireless (Miracast) and wired (HDMI) displays that satisfies thisrequirement.

7.2. Input Devices7.2.1. Keyboard

Device implementations:

MUST include support for the Input Management Framework (which allowsthird party developers to create Input Management Engines - i.e. soft keyboard)as detailed at http://developer.android.comMUST provide at least one soft keyboard implementation (regardless ofwhether a hard keyboard is present)MAY include additional soft keyboard implementationsMAY include a hardware keyboardMUST NOT include a hardware keyboard that does not match one of theformats specified in android.content.res.Configuration.keyboard[Resources, 40] (that is, QWERTY, or 12-key)

7.2.2. Non-touch Navigation


MAY omit a non-touch navigation option (that is, may omit a trackball, d-pad, orwheel)MUST report the correct value forandroid.content.res.Configuration.navigation [Resources, 40]

MUST provide a reasonable alternative user interface mechanism for theselection and editing of text, compatible with Input Management Engines. Theupstream Android open source implementation includes a selectionmechanism suitable for use with devices that lack non-touch navigation inputs.

7.2.3. Navigation keys

The Home, Menu and Back functions are essential to the Android navigationparadigm. Device implementations MUST make these functions available to theuser at all times when running applications. These functions MAY be implementedvia dedicated physical buttons (such as mechanical or capacitive touch buttons), orMAY be implemented using dedicated software keys, gestures, touch panel, etc.Android 4.2 supports both implementations.

Android 4.2 includes support for assist action [Resources, 63]. Deviceimplementations MUST make the assist action available to the user at all timeswhen running applications. This function MAY be implemented via hardware orsoftware keys.

Device implementations MAY use a distinct portion of the screen to display thenavigation keys, but if so, MUST meet these requirements:

Device implementation navigation keys MUST use a distinct portion of thescreen, not available to applications, and MUST NOT obscure or otherwiseinterfere with the portion of the screen available to applications.Device implementations MUST make available a portion of the display toapplications that meets the requirements defined in Section 7.1.1.Device implementations MUST display the navigation keys when applicationsdo not specify a system UI mode, or specify SYSTEM_UI_FLAG_VISIBLE.Device implementations MUST present the navigation keys in an unobtrusive"low profile" (eg. dimmed) mode when applications specifySYSTEM_UI_FLAG_LOW_PROFILE.Device implementations MUST hide the navigation keys when applicationsspecify SYSTEM_UI_FLAG_HIDE_NAVIGATION.Device implementation MUST present a Menu key to applications whentargetSdkVersion 10.

7.2.4. Touchscreen input


MUST have a pointer input system of some kind (either mouse-like, or touch)MAY have a touchscreen of any modality (such as capacitive or resistive)SHOULD support fully independently tracked pointers, if a touchscreensupports multiple pointersMUST report the value of android.content.res.Configuration [Resources,39] reflecting corresponding to the type of the specific touchscreen on thedevice

Device implementations MUST report the correct feature corresponding to the typeof input used. Note that Android 4.2 includes the featureandroid.hardware.faketouch, which corresponds to a high-fidelity non-touch (that is,pointer-based) input device such as a mouse or trackpad that can adequatelyemulate touch-based input (including basic gesture support), and indicates that thedevice supports an emulated subset of touchscreen functionality. Deviceimplementations that include a touchscreen (single-touch or better) MUST alsoreport android.hardware.faketouch. Device implementations that do not include atouchscreen (and rely on a pointer device only) MUST NOT report any touchscreenfeature, and MUST report only android.hardware.faketouch.

7.2.5. Microphone

Device implementations MAY omit a microphone. However, if a deviceimplementation omits a microphone, it MUST NOT report theandroid.hardware.microphone feature constant, and must implement the audiorecording API as no-ops, per Section 7. Conversely, device implementations that dopossess a microphone:

MUST report the android.hardware.microphone feature constantSHOULD meet the audio quality requirements in Section 5.4SHOULD meet the audio latency requirements in Section 5.5

7.3. Sensors

Android 4.2 includes APIs for accessing a variety of sensor types. Devicesimplementations generally MAY omit these sensors, as provided for in the followingsubsections. If a device includes a particular sensor type that has a correspondingAPI for third-party developers, the device implementation MUST implement that APIas described in the Android SDK documentation. For example, deviceimplementations:

MUST accurately report the presence or absence of sensors per theandroid.content.pm.PackageManager class. [Resources, 37]MUST return an accurate list of supported sensors via theSensorManager.getSensorList() and similar methodsMUST behave reasonably for all other sensor APIs (for example, by returningtrue or false as appropriate when applications attempt to register listeners, notcalling sensor listeners when the corresponding sensors are not present; etc.)MUST report all sensor measurements using the relevant International Systemof Units (i.e. metric) values for each sensor type as defined in the Android SDKdocumentation [Resources, 41]

The list above is not comprehensive; the documented behavior of the Android SDKis to be considered authoritative.

Some sensor types are synthetic, meaning they can be derived from data providedby one or more other sensors. (Examples include the orientation sensor, and thelinear acceleration sensor.) Device implementations SHOULD implement thesesensor types, when they include the prerequisite physical sensors.

The Android 4.2 includes a notion of a "streaming" sensor, which is one that returnsdata continuously, rather than only when the data changes. Device implementationsMUST continuously provide periodic data samples for any API indicated by theAndroid 4.2 SDK documentation to be a streaming sensor. Note that the deviceimplementations MUST ensure that the sensor stream must not prevent the deviceCPU from entering a suspend state or waking up from a suspend state.

7.3.1. Accelerometer

Device implementations SHOULD include a 3-axis accelerometer. If a deviceimplementation does include a 3-axis accelerometer, it:

SHOULD be able to deliver events at 120 Hz or greater. Note that while theaccelerometer frequency above is stated as "SHOULD" for Android 4.2, theCompatibility Definition for a future version is planned to change these to"MUST". That is, these standards are optional in Android 4.2 but will berequired in future versions. Existing and new devices that run Android 4.2 arevery strongly encouraged to meet these requirements in Android 4.2 sothey will be able to upgrade to the future platform releasesMUST comply with the Android sensor coordinate system as detailed in theAndroid APIs (see [Resources, 41])MUST be capable of measuring from freefall up to twice gravity (2g) or more onany three-dimensional vectorMUST have 8-bits of accuracy or moreMUST have a standard deviation no greater than 0.05 m/s^2

7.3.2. Magnetometer

Device implementations SHOULD include a 3-axis magnetometer (i.e. compass.) Ifa device does include a 3-axis magnetometer, it:

MUST be able to deliver events at 10 Hz or greaterMUST comply with the Android sensor coordinate system as detailed in theAndroid APIs (see [Resources, 41]).MUST be capable of sampling a range of field strengths adequate to cover thegeomagnetic fieldMUST have 8-bits of accuracy or moreMUST have a standard deviation no greater than 0.5 T

7.3.3. GPS

Device implementations SHOULD include a GPS receiver. If a deviceimplementation does include a GPS receiver, it SHOULD include some form of"assisted GPS" technique to minimize GPS lock-on time.

7.3.4. Gyroscope

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:

MUST be temperature compensatedMUST be capable of measuring orientation changes up to 5.5*Piradians/second (that is, approximately 1,000 degrees per second)SHOULD be able to deliver events at 200 Hz or greater. Note that while thegyroscope frequency above is stated as "SHOULD" for Android 4.2, theCompatibility Definition for a future version is planned to change these to"MUST". That is, these standards are optional in Android 4.2 but will berequired in future versions. Existing and new devices that run Android 4.2 arevery strongly encouraged to meet these requirements in Android 4.2 sothey will be able to upgrade to the future platform releasesMUST have 12-bits of accuracy or moreMUST have a variance no greater than 1e-7 rad^2 / s^2 per Hz (variance perHz, or rad^2 / s). The variance is allowed to vary with the sampling rate, butmust be constrained by this value. In other words, if you measure the varianceof the gyro at 1 Hz sampling rate it should be no greater than 1e-7 rad^2/s^2.MUST have timestamps as close to when the hardware event happened aspossible. The constant latency must be removed.

7.3.5. Barometer

Device implementations MAY include a barometer (i.e. ambient air pressure sensor.)If a device implementation includes a barometer, it:

MUST be able to deliver events at 5 Hz or greaterMUST have adequate precision to enable estimating altitudeMUST be temperature compensated

7.3.7. Thermometer

Device implementations MAY but SHOULD NOT include a thermometer (i.e.temperature sensor.) If a device implementation does include a thermometer, itMUST measure the temperature of the device CPU. It MUST NOT measure anyother temperature. (Note that this sensor type is deprecated in the Android 4.2 APIs.)

7.3.7. Photometer

Device implementations MAY include a photometer (i.e. ambient light sensor.)

7.3.8. Proximity Sensor

Device implementations MAY include a proximity sensor. If a device implementationdoes include a proximity sensor, it MUST measure the proximity of an object in thesame direction as the screen. That is, the proximity sensor MUST be oriented todetect objects close to the screen, as the primary intent of this sensor type is todetect a phone in use by the user. If a device implementation includes a proximitysensor with any other orientation, it MUST NOT be accessible through this API. If adevice implementation has a proximity sensor, it MUST be have 1-bit of accuracy ormore.

7.4. Data Connectivity7.4.1. Telephony

"Telephony" as used by the Android 4.2 APIs and this document refers specificallyto hardware related to placing voice calls and sending SMS messages via a GSM orCDMA network. While these voice calls may or may not be packet-switched, theyare for the purposes of Android 4.2 considered independent of any data connectivitythat may be implemented using the same network. In other words, the Android"telephony" functionality and APIs refer specifically to voice calls and SMS; forinstance, device implementations that cannot place calls or send/receive SMSmessages MUST NOT report the "android.hardware.telephony" feature or any sub-features, regardless of whether they use a cellular network for data connectivity.

Android 4.2 MAY be used on devices that do not include telephony hardware. Thatis, Android 4.2 is compatible with devices that are not phones. However, if a deviceimplementation does include GSM or CDMA telephony, it MUST implement fullsupport for the API for that technology. Device implementations that do not includetelephony hardware MUST implement the full APIs as no-ops.

7.4.2. IEEE 802.11 (WiFi)

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, itMUST implement the corresponding Android API.

Device implementations MUST implement the multicast API as described in theSDK documentation [Resources, 62]. Device implementations that do include Wifisupport MUST support multicast DNS (mDNS). Device implementations MUST notfilter mDNS packets (224.0.0.251) at any time of operation including when thescreen is not in an active state.

7.4.2.1. WiFi Direct

Device implementations SHOULD include support for Wifi direct (Wifi peer-to-peer).If a device implementation does include support for Wifi direct, it MUST implementthe corresponding Android API as described in the SDK documentation [Resources,68]. If a device implementation includes support for Wifi direct, then it:

MUST support regular Wifi operationSHOULD support concurrent wifi and wifi Direct operation

7.4.3. Bluetooth

Device implementations SHOULD include a Bluetooth transceiver. Deviceimplementations that do include a Bluetooth transceiver MUST enable theRFCOMM-based Bluetooth API as described in the SDK documentation[Resources, 42]. Device implementations SHOULD implement relevant Bluetoothprofiles, such as A2DP, AVRCP, OBEX, etc. as appropriate for the device.

The Compatibility Test Suite includes cases that cover basic operation of theAndroid RFCOMM Bluetooth API. However, since Bluetooth is a communicationsprotocol between devices, it cannot be fully tested by unit tests running on a singledevice. Consequently, device implementations MUST also pass the human-drivenBluetooth test procedure described in Appendix A.

7.4.4. Near-Field Communications

Device implementations SHOULD include a transceiver and related hardware forNear-Field Communications (NFC). If a device implementation does include NFChardware, then it:

MUST report the android.hardware.nfc feature from theandroid.content.pm.PackageManager.hasSystemFeature() method.[Resources, 37]MUST be capable of reading and writing NDEF messages via the followingNFC standards:

MUST be capable of acting as an NFC Forum reader/writer (as definedby the NFC Forum technical specification NFCForum-TS-DigitalProtocol-1.0) via the following NFC standards:

NfcA (ISO14443-3A)NfcB (ISO14443-3B)NfcF (JIS 6319-4)IsoDep (ISO 14443-4)NFC Forum Tag Types 1, 2, 3, 4 (defined by the NFC Forum)

SHOULD be capable of reading and writing NDEF messages via the followingNFC standards. Note that while the NFC standards below are stated as"SHOULD" for Android 4.2, the Compatibility Definition for a future version isplanned to change these to "MUST". That is, these standards are optional inAndroid 4.2 but will be required in future versions. Existing and new devicesthat run Android 4.2 are very strongly encouraged to meet theserequirements in Android 4.2 so they will be able to upgrade to the futureplatform releases.

NfcV (ISO 15693)MUST be capable of transmitting and receiving data via the following peer-to-peer standards and protocols:

ISO 18092LLCP 1.0

Android 4.2 Cdd

Documents

Transcript of Android 4.2 Cdd