Android 5.1 Compatibility Definition

1. Introduction

This document enumerates the requirements that must be met in order for devices to be compatible with Android 5.1.

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 or organization developing a hardware/software solution running Android 5.1. A “device implementation” or “implementation is the hardware/software solution so developed.

To be considered compatible with Android 5.1, device implementations MUST meet the requirements presented in this Compatibility Definition, including any documents incorporated 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 ensure compatibility with existing implementations.

For this reason, the Android Open Source Project [Resources, 2] is both the reference and preferred implementation of Android. Device implementers are strongly encouraged to base their implementations to the greatest extent possible on the “upstream” source code available from the Android Open Source Project. While some components can hypothetically be replaced with alternate implementations this practice is strongly discouraged, as passing the software tests will become substantially more difficult. It is the implementer’s responsibility to ensure full behavioral compatibility with the standard Android implementation, including and beyond the Compatibility Test Suite. Finally, note that certain component substitutions and modifications are explicitly forbidden by this document.

Many of the resources listed in section 14 are derived directly or indirectly from the Android SDK, and will be functionally identical to the information in that SDK’s documentation. For any case where this Compatibility Definition or the Compatibility Test Suite disagrees with the SDK documentation, the SDK documentation is considered authoritative. Any technical details provided in the references included in section 14 are considered by inclusion to be part of this Compatibility Definition.

2. Device Types

While the Android Open Source Project has been used in the implementation of a variety of device types and form factors, many aspects of the architecture and compatibility requirements were optimized for handheld devices. Starting from Android 5.0, the Android Open Source Project aims to embrace a wider variety of device types as described in this section.

Android Handheld device refers to an Android device implementation that is typically used by holding it in the hand, such as mp3 players, phones, and tablets. Android Handheld device implementations:

• MUST have a touchscreen embedded in the device.
• MUST have a power source that provides mobility, such as a battery.

Android Television device refers to an Android device implementation that is an entertainment interface for consuming digital media, movies, games, apps, and/or live TV for users sitting about ten feet away (a “lean back” or “10-foot user interface”). Android Television devices:

• MUST have an embedded screen OR include a video output port, such as VGA, HDMI, or a wireless port for display.
• MUST declare the features android.software.leanback and android.hardware.type.television [Resources, 3].

Android Watch device refers to an Android device implementation intended to be worn on the body, perhaps on the wrist, and:

• MUST have a screen with the physical diagonal length in the range from 1.1 to 2.5 inches.
• MUST declare the feature android.hardware.type.watch.
• MUST support uiMode = UI_MODE_TYPE_WATCH [Resources, 4].

Android Automotive implementation refers to a vehicle head unit running Android as an operating system for part or all of the system and/or infotainment functionality. Android Automotive implementations MUST support uiMode = UI_MODE_TYPE_CAR [Resources, 111].

All Android device implementations that do not fit into any of the above device types still MUST meet all requirements in this document to be Android 5.1 compatible, unless the requirement is explicitly described to be only applicable to a specific Android device type from above.

2.1 Device Configurations

This is a summary of major differences in hardware configuration by device type. (Empty cells denote a “MAY”). Not all configurations are covered in this table; see relevant hardware sections for more detail.

Category	Feature	Section	Handheld	Television	Watch	Automotive	Other
Input	D-pad	7.2.2. Non-touch Navigation		MUST
	Touchscreen	7.2.4. Touchscreen input	MUST		MUST		SHOULD
	Microphone	7.8.1. Microphone	MUST	SHOULD	MUST	MUST	SHOULD
Sensors	Accelerometer	7.3.1 Accelerometer	SHOULD		SHOULD		SHOULD
	GPS	7.3.3. GPS	SHOULD			SHOULD
Connectivity	Wi-Fi	7.4.2. IEEE 802.11	SHOULD	MUST		SHOULD	SHOULD
	Wi-Fi Direct	7.4.2.1. Wi-Fi Direct	SHOULD	SHOULD			SHOULD
	Bluetooth	7.4.3. Bluetooth	SHOULD	MUST	MUST	MUST	SHOULD
	Bluetooth Low Energy	7.4.3. Bluetooth	SHOULD	MUST	SHOULD	SHOULD	SHOULD
	USB peripheral/host mode	7.7. USB	SHOULD			SHOULD	SHOULD
Output	Speaker and/or Audio output ports	7.8.2. Audio Output	MUST	MUST		MUST	MUST

3. Software

3.1. Managed API Compatibility

The managed Dalvik bytecode execution environment is the primary vehicle for Android applications. The Android application programming interface (API) is the set of Android platform interfaces exposed to applications running in the managed runtime environment. Device implementations MUST provide complete implementations, including all documented behaviors, of any documented API exposed by the Android SDK [Resources, 5] or any API decorated with the “@SystemApi” marker in the upstream Android source code.

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.

This Compatibility Definition permits some types of hardware for which Android includes APIs to be omitted by device implementations. In such cases, the APIs MUST still be present and behave in a reasonable way. See section 7 for specific requirements for this scenario.

3.2. Soft API Compatibility

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 as intents, permissions, and similar aspects of Android applications that cannot be enforced at application compile time.

3.2.1. Permissions

Device implementers MUST support and enforce all permission constants as documented by the Permission reference page [Resources, 6]. Note that section 9 lists 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, 7] 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.

Parameter	Details
VERSION.RELEASE	The version of the currently-executing Android system, in human-readable format. This field MUST have one of the string values defined in [Resources, 8].
VERSION.SDK	The version of the currently-executing Android system, in a format accessible to third-party application code. For Android 5.1, this field MUST have the integer value 22.
VERSION.SDK_INT	The version of the currently-executing Android system, in a format accessible to third-party application code. For Android 5.1, this field MUST have the integer value 22.
VERSION.INCREMENTAL	A value chosen by the device implementer designating the specific build of the currently-executing Android system, in human-readable format. This value MUST NOT be reused for different builds made available to end users. A typical use of this field is to indicate which build number or source-control change identifier was used to generate the build. There are no requirements on the specific format of this field, except that it MUST NOT be null or the empty string ("").
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 board powering the device. The value of this field MUST be encodable as 7-bit ASCII and match the regular expression “^[a-zA-Z0-9_-]+$”.
BRAND	A value reflecting the brand name associated with the device as known to the end users. MUST be in human-readable format and SHOULD represent the manufacturer of the device or the company brand under which the device is marketed. The value of this field MUST be encodable as 7-bit ASCII and match the regular expression “^[a-zA-Z0-9_-]+$”.
SUPPORTED_ABIS	The name of the instruction set (CPU type + ABI convention) of native code. See section 3.3. Native API Compatibility.
SUPPORTED_32_BIT_ABIS	The name of the instruction set (CPU type + ABI convention) of native code. See section 3.3. Native API Compatibility.
SUPPORTED_64_BIT_ABIS	The name of the second instruction set (CPU type + ABI convention) of native code. See section 3.3. Native API Compatibility.
CPU_ABI	The name of the instruction set (CPU type + ABI convention) of native code. See section 3.3. Native API Compatibility.
CPU_ABI2	The name of the second instruction set (CPU type + ABI convention) of native code. See section 3.3. Native API Compatibility.
DEVICE	A value chosen by the device implementer containing the development name or code name identifying the configuration of the hardware features and industrial design of the device. The value of this field MUST be encodable as 7-bit ASCII and match the regular expression “^[a-zA-Z0-9_-]+$”.
FINGERPRINT	A string that uniquely identifies this build. It SHOULD be reasonably human-readable. It MUST follow this template: $(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) For example: acme/myproduct/mydevice:5.1/LMYXX/3359:userdebug/test-keys The fingerprint MUST NOT include whitespace characters. If other fields included in the template above have whitespace characters, they MUST be replaced in the build fingerprint with another character, such as the underscore ("_") character. The value of this field MUST be encodable as 7-bit ASCII.
HARDWARE	The name of the hardware (from the kernel command line or /proc). It SHOULD be reasonably human-readable. The value of this field MUST be encodable as 7-bit ASCII and match the regular expression “^[a-zA-Z0-9_-]+$”.
HOST	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 ("").
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 value sufficiently meaningful for end users to distinguish between software builds. The value of this field MUST be encodable as 7-bit ASCII and match the regular expression “^[a-zA-Z0-9._-]+$”.
MANUFACTURER	The trade name of the Original Equipment Manufacturer (OEM) of the product. There are no requirements on the specific format of this field, except that it MUST NOT be null or the empty string ("").
MODEL	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 ("").
PRODUCT	A value chosen by the device implementer containing the development name or code name of the specific product (SKU) that MUST be unique within the same brand. MUST be human-readable, but is not necessarily intended for view by end users. The value of this field MUST be encodable as 7-bit ASCII and match the regular expression “^[a-zA-Z0-9_-]+$”.
SERIAL	A hardware serial number, which MUST be available. The value of this field MUST be encodable as 7-bit ASCII and match the regular expression “^([a-zA-Z0-9]{6,20})$”.
TAGS	A comma-separated list of tags chosen by the device implementer that further distinguishes the build. This field MUST have one of the values corresponding to the three typical Android platform signing configurations: release-keys, dev-keys, test-keys.
TIME	A value representing the timestamp of when the build occurred.
TYPE	A value chosen by the device implementer specifying the runtime configuration of the build. This field MUST have one of the values corresponding to the three typical Android runtime configurations: user, userdebug, or eng.
USER	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 ("").

3.2.3. Intent Compatibility

Device implementations MUST honor Android’s loose-coupling intent system, as described in the sections below. By“honored ” it is meant that the device implementer MUST provide an Android Activity or Service that specifies a matching intent filter that binds to and implements correct behavior for each specified intent pattern.

3.2.3.1. Core Application Intents

Android intents allow application components to request functionality from other Android components. The Android upstream project includes a list of applications considered core Android applications, which implements several intent patterns to perform common actions. The core Android applications are:

• Desk Clock
• Browser
• Calendar
• Contacts
• Gallery
• GlobalSearch
• Launcher
• Music
• Settings

Device implementations SHOULD include the core Android applications as appropriate but MUST include a component implementing the same intent patterns defined by all the “public” Activity or Service components of these core Android applications. Note that Activity or Service components are considered “public” when the attribute android:exported is absent or has the value true.

3.2.3.2. Intent Overrides

As Android is an extensible platform, device implementations MUST allow each intent pattern referenced in section 3.2.3.1 to be overridden by third-party applications. The upstream Android open source implementation allows this by default; device implementers MUST NOT attach special privileges to system applications' use of these intent patterns, or prevent third-party applications from binding to and assuming control of these patterns. This prohibition specifically includes but is not limited to disabling the“Chooser” user interface that allows the user to select between multiple applications that all handle the same intent pattern.

However, device implementations MAY provide default activities for specific URI patterns (eg. http://play.google.com) if the default activity provides a more specific filter for the data URI. For example, an intent filter specifying the data URI “http://www.android.com” is more specific than the browser filter for“http://”. Device implementations MUST provide a user interface for users to modify the default activity for intents.

3.2.3.3. Intent Namespaces

Device implementations MUST NOT include any Android component that honors any new intent or broadcast intent patterns using an ACTION, CATEGORY, or other key string in the android.* or com.android.* namespace. Device implementers MUST NOT include any Android components that honor any new intent or broadcast intent patterns using an ACTION, CATEGORY, or other key string in a package space belonging to another organization. Device implementers MUST NOT alter or extend any of the intent patterns used by the core apps listed in section 3.2.3.1. Device implementations MAY include intent patterns using namespaces clearly and obviously associated with their own organization. This prohibition is analogous to that specified for Java language classes in section 3.6.

3.2.3.4. Broadcast Intents

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.

3.2.3.5. Default App Settings

Android includes settings that provide users an easy way to select their default applications, for example for Home screen or SMS. Where it makes sense, device implementations MUST provide a similar settings menu and be compatible with the intent filter pattern and API methods described in the SDK documentation as below.

Device implementations:

• MUST honor the android.settings.HOME_SETTINGS intent to show a default app settings menu for Home Screen, if the device implementation reports android.software.home_screen [Resources, 10]
• MUST provide a settings menu that will call the android.provider.Telephony.ACTION_CHANGE_DEFAULT intent to show a dialog to change the default SMS application, if the device implementation reports android.hardware.telephony [Resources, 9]
• MUST honor the android.settings.NFC_PAYMENT_SETTINGS intent to show a default app settings menu for Tap and Pay, if the device implementation reports android.hardware.nfc.hce [Resources, 10]

3.3. Native API Compatibility

3.3.1. Application Binary Interfaces

Managed Dalvik bytecode can call into native code provided in the application .apk file as an ELF .so file compiled for the appropriate device hardware architecture. As native code is highly dependent on the underlying processor technology, Android defines a number of Application Binary Interfaces (ABIs) in the Android NDK. Device implementations MUST be compatible with one or more defined ABIs, and MUST implement compatibility with the Android NDK, as below.

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

• MUST include support for code running in the managed environment to call into 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 below
• MUST support the equivalent 32-bit ABI if any 64-bit ABI is supported
• MUST accurately report the native Application Binary Interface (ABI) supported by the device, via the android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS, and android.os.Build.SUPPORTED_64_BIT_ABIS parameters, each a comma separated list of ABIs ordered from the most to the least preferred one
• MUST report, via the above parameters, only those ABIs documented in the latest version of the Android NDK, “NDK Programmer’s Guide | ABI Management” in docs/ directory
• SHOULD be built using the source code and header files available in the upstream 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 interface
• liblog (Android logging)
• libz (Zlib compression)
• libdl (dynamic linker)
• libGLESv1_CM.so (OpenGL ES 1.x)
• libGLESv2.so (OpenGL ES 2.0)
• libGLESv3.so (OpenGL ES 3.x)
• libEGL.so (native OpenGL surface management)
• libjnigraphics.so
• libOpenSLES.so (OpenSL ES 1.0.1 audio support)
• libOpenMAXAL.so (OpenMAX AL 1.0.1 support)
• libandroid.so (native Android activity support)
• libmediandk.so (native media APIs support)
• Support for OpenGL, as described below

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

Note that device implementations MUST include libGLESv3.so and it MUST symlink (symbolic link) to libGLESv2.so. in turn, MUST export all the OpenGL ES 3.1 and Android Extension Pack [Resources, 11] function symbols as defined in the NDK release android-21. Although all the symbols must be present, only the corresponding functions for OpenGL ES versions and extensions actually supported by the device must be fully implemented.

Native code compatibility is challenging. For this reason, device implementers are very strongly encouraged to use the implementations of the libraries listed above from the upstream Android Open Source Project.

3.3.2. 32-bit ARM Native Code Compatibility

The ARMv8 architecture deprecates several CPU operations, including some operations used in existing native code. On 64-bit ARM devices, the following deprecated operations MUST remain available to 32-bit native ARM code, either through native CPU support or through software emulation:

• SWP and SWPB instructions
• SETEND instruction
• CP15ISB, CP15DSB, and CP15DMB barrier operations

Legacy versions of the Android NDK used /proc/cpuinfo to discover CPU features from 32-bit ARM native code. For compatibility with applications built using this NDK, devices MUST include the following lines in /proc/cpuinfo when it is read by 32-bit ARM applications:

• "Features: ", followed by a list of any optional ARMv7 CPU features supported by the device
• "CPU architecture: ", followed by an integer describing the device's highest supported ARM architecture (e.g., "8" for ARMv8 devices)

These requirements only apply when /proc/cpuinfo is read by 32-bit ARM applications. Devices SHOULD not alter /proc/cpuinfo when read by 64-bit ARM or non-ARM applications.

3.4. Web Compatibility

3.4.1. WebView Compatibility

The platform feature android.software.webview MUST be reported on any device that provides a complete implementation of the android.webkit.WebView API, and MUST NOT be reported on devices without a complete implementation of the API. The Android Open Source implementation uses code from the Chromium Project to implement the android.webkit.WebView [Resources, 12]. Because it is not feasible to develop a comprehensive test suite for a web rendering system, device implementers MUST use the specific upstream build of Chromium in the WebView implementation. Specifically:

• Device android.webkit.WebView implementations MUST be based on the Chromium build from the upstream Android Open Source Project for Android 5.1. This build includes a specific set of functionality and security fixes for the WebView [Resources, 13].
• The user agent string reported by the WebView MUST be in this format:

  Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD)$(WEBVIEW)) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

  • The value of the $(VERSION) string MUST be the same as the value for android.os.Build.VERSION.RELEASE.
  • The $(WEBVIEW) string MAY be omitted, but if included MUST be "; wv" to note that this is a webview
  • The value of the $(MODEL) string MUST be the same as the value for android.os.Build.MODEL.
  • The value of the $(BUILD) string MUST be the same as the value for android.os.Build.ID.
  • The value of the $(CHROMIUM_VER) string MUST be the version of Chromium in the upstream Android Open Source Project.
  • Device implementations MAY omit Mobile in the user agent string.

The WebView component SHOULD include support for as many HTML5 features as possible and if it supports the feature SHOULD conform to the HTML5 specification [Resources, 14].

3.4.2. Browser Compatibility

The standalone Browser MAY be based on a browser technology other than WebKit. However, even if an alternate Browser application is used, the android.webkit.WebView component provided to third-party applications MUST be based on WebKit, as described in section 3.4.1.

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

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 [Resources, 14] as possible. Minimally, device implementations MUST support each of these APIs associated with HTML5:

• application cache/offline operation [Resources, 15]
• the <video> tag [Resources, 16]
• geolocation [Resources, 17]

Additionally, device implementations MUST support the HTML5/W3C webstorage API [Resources, 18], and SHOULD support the HTML5/W3C IndexedDB API [Resources, 19]. Note that as the web development standards bodies are transitioning to favor IndexedDB over webstorage, IndexedDB is expected to become a required component in a future version of Android.

3.5. API Behavioral Compatibility

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 [Resources, 2]. Some specific areas of compatibility are:

• Devices MUST NOT change the behavior or semantics of a standard intent.
• Devices MUST NOT alter the lifecycle or lifecycle semantics of a particular type 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) tests significant portions of the platform for behavioral compatibility, but not all. It is the responsibility of the implementer to ensure behavioral compatibility with the Android Open Source Project. For this reason, device implementers SHOULD use the source code available via the Android Open Source Project where possible, rather than re-implement significant parts of the system.

3.6. API Namespaces

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:

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

Prohibited modifications include:

• 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.
• 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 as classes or interfaces, or fields or methods to existing classes or interfaces) to the 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 the namespaces noted above. Device implementers MAY make internal-only modifications, but those modifications MUST NOT be advertised or otherwise exposed to developers.

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

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.

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.

3.7. Runtime Compatibility

Device implementations MUST support the full Dalvik Executable (DEX) format and Dalvik bytecode specification and semantics [Resources, 20]. Device implementers SHOULD use ART, the reference upstream implementation of the Dalvik Executable Format, and the reference implementation’s package management system.

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

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

Screen Layout	Screen Density	Minimum Application Memory
small/normal	120 dpi (ldpi)	32MB
	160 dpi (mdpi)
	213 dpi (tvdpi)	48MB
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (xhdpi)	80MB
	400 dpi (400dpi)	96MB
	480 dpi (xxhdpi)	128MB
	560 dpi (560dpi)	192MB
	640 dpi (xxxhdpi)	256MB
large	120 dpi (ldpi)	32MB
	160 dpi (mdpi)	48MB
	213 dpi (tvdpi)	80MB
	240 dpi (hdpi)
	280 dpi (280dpi)	96MB
	320 dpi (xhdpi)	128MB
	400 dpi (400dpi)	192MB
	480 dpi (xxhdpi)	256MB
	560 dpi (560dpi)	384MB
	640 dpi (xxxhdpi)	512MB
xlarge	120 dpi (ldpi)	48MB
	160 dpi (mdpi)	80MB
	213 dpi (tvdpi)	96MB
	240 dpi (hdpi)
	280 dpi (280dpi)	144MB
	320 dpi (xhdpi)	192MB
	400 dpi (400dpi)	288MB
	480 dpi (xxhdpi)	384MB
	560 dpi (560dpi)	576MB
	640 dpi (xxxhdpi)	768MB

3.8. User Interface Compatibility

3.8.1. Launcher (Home Screen)

Android includes a launcher application (home screen) and support for third-party applications to replace the device launcher (home screen). Device implementations that allow third-party applications to replace the device home screen MUST declare the platform feature android.software.home_screen.

3.8.2. Widgets

Android defines a component type and corresponding API and lifecycle that allows applications to expose an “AppWidget” to the end user [Resources, 21] a feature that is strongly RECOMMENDED to be supported on Handheld Device implementations. Device implementations that support embedding widgets on the home screen MUST meet the following requirements and declare support for platform feature android.software.app_widgets.

• Device launchers MUST include built-in support for AppWidgets, and expose user interface affordances to add, configure, view, and remove AppWidgets directly within the Launcher.
• Device implementations MUST be capable of rendering widgets that are 4 x 4 in the standard grid size. See the App Widget Design Guidelines in the Android SDK documentation [Resources, 21] for details.
• Device implementations that include support for lock screen MAY support application widgets on the lock screen.

3.8.3. Notifications

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

Some APIs allow applications to perform notifications or attract attention using hardware—specifically sound, vibration, and light. Device implementations MUST support notifications that use hardware features, as described in the SDK documentation, and to the extent possible with the device implementation hardware. For instance, if a device implementation includes a vibrator, it MUST correctly implement the vibration APIs. If a device implementation lacks hardware, the corresponding APIs MUST be implemented as no-ops. This behavior is further detailed in section 7.

Additionally, the implementation MUST correctly render all resources (icons, animation files etc.) provided for in the APIs [Resources, 23], or in the Status/System Bar icon style guide [Resources, 24], which in the case of an Android Television device includes the possibility to not display the notifications. 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.

Android includes support for various notifications, such as:

• Rich notifications. Interactive Views for ongoing notifications.
• Heads-up notifications. Interactive Views users can act on or dismiss without leaving the current app.
• Lockscreen notifications. Notifications shown over a lock screen with granular control on visibility.

Android device implementations, when such notifications are made visible, MUST properly execute Rich and Heads-up notifications and include the title/name, icon, text as documented in the Android APIs [Resources, 25].

Android includes Notification Listener Service APIs that allow apps (once explicitly enabled by the user) to receive a copy of all notifications as they are posted or updated. Device implementations MUST correctly and promptly send notifications in their entirety to all such installed and user-enabled listener services, including any and all metadata attached to the Notification object.

3.8.4. Search

Android includes APIs [Resources, 26] 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.

Android device implementations SHOULD include global search, a single, shared, system-wide search user interface capable of real-time suggestions in response to user input. Device implementations SHOULD implement the APIs that allow developers to reuse this user interface to provide search within their own applications. Device implementations that implement the global search interface MUST implement the APIs that allow third-party applications to add suggestions to the search box when it is run in global search mode. If no third-party applications are installed that make use of this functionality, the default behavior SHOULD be to display web search engine results and suggestions.

3.8.5. Toasts

Applications can use the “Toast” API to display short non-modal strings to the end user, that disappear after a brief period of time [Resources, 27]. Device implementations MUST display Toasts from applications to end users in some high-visibility manner.

3.8.6. Themes

Android provides “themes” as a mechanism for applications to apply styles across an entire Activity or application.

Android includes a “Holo” theme family as a set of defined styles for application developers to use if they want to match the Holo theme look and feel as defined by the Android SDK [Resources, 28]. Device implementations MUST NOT alter any of the Holo theme attributes exposed to applications [Resources, 29].

Android includes a “Material” theme family as a set of defined styles for application developers to use if they want to match the design theme’s look and feel across the wide variety of different Android device types. Device implementations MUST support the “Material” theme family and MUST NOT alter any of the Material theme attributes or their assets exposed to applications [Resources, 30].

Android also includes a “Device Default” theme family as a set of defined styles for application developers to use if they want to match the look and feel of the device theme as defined by the device implementer. Device implementations MAY modify the Device Default theme attributes exposed to applications [Resources, 29].

Android supports a new variant theme with translucent system bars, which allows application developers to fill the area behind the status and navigation bar with their app content. To enable a consistent developer experience in this configuration, it is important the status bar icon style is maintained across different device implementations. Therefore, Android device implementations MUST use white for system status icons (such as signal strength and battery level) and notifications issued by the system, unless the icon is indicating a problematic status [Resources, 29].

3.8.7. Live Wallpapers

Android defines a component type and corresponding API and lifecycle that allows applications to expose one or more “Live Wallpapers” to the end user [Resources, 31]. Live wallpapers are animations, patterns, or similar images with limited input capabilities that display as a wallpaper, behind other applications.

Hardware is considered capable of reliably running live wallpapers if it can run all live wallpapers, with no limitations on functionality, at a reasonable frame rate with no adverse effects on other applications. If limitations in the hardware cause wallpapers and/or applications to crash, malfunction, consume excessive CPU or battery power, or run at unacceptably low frame rates, the hardware is considered incapable of running live wallpaper. As an example, some live wallpapers may use an OpenGL 2.0 or 3.x context to render their content. Live wallpaper will not run reliably on hardware that does not support multiple OpenGL contexts because the live wallpaper use of an OpenGL context may conflict with other applications that also use an OpenGL context.

Device implementations capable of running live wallpapers reliably as described above SHOULD implement live wallpapers, and when implemented MUST report the platform feature flag android.software.live_wallpaper.

3.8.8. Activity Switching

The upstream Android source code includes the overview screen [Resources, 32], a system-level user interface for task switching and displaying recently accessed activities and tasks using a thumbnail image of the application’s graphical state at the moment the user last left the application. Device implementations including the recents function navigation key as detailed in section 7.2.3, MAY alter the interface but MUST meet the following requirements:

• MUST display affiliated recents as a group that moves together.
• MUST support at least up to 20 displayed activities.
• SHOULD at least display the title of 4 activities at a time.
• SHOULD display highlight color, icon, screen title in recents.
• MUST implement the screen pinning behavior [Resources, 33] and provide the user with a settings menu to toggle the feature.
• SHOULD display a closing affordance ("x") but MAY delay this until user interacts with screens.

Device implementations are STRONGLY ENCOURAGED to use the upstream Android user interface (or a similar thumbnail-based interface) for the overview screen.

3.8.9. Input Management

Android includes support for Input Management and support for third-party input method editors [Resources, 34]. Device implementations that allow users to use third-party input methods on the device MUST declare the platform feature android.software.input_methods and support IME APIs as defined in the Android SDK documentation.

Device implementations that declare the android.software.input_methods feature MUST provide a user-accessible mechanism to add and configure third-party input methods. Device implementations MUST display the settings interface in response to the android.settings.INPUT_METHOD_SETTINGS intent.

3.8.10. Lock Screen Media Control

The Remote Control Client API is deprecated from Android 5.0 in favor of the Media Notification Template that allows media applications to integrate with playback controls that are displayed on the lock screen [Resources, 35]. Device implementations that support a lock screen, unless an Android Automotive or Watch implementation, MUST display the Lockscreen Notifications including the Media Notification Template.

3.8.11. Dreams

Android includes support for interactive screensavers called Dreams [Resources, 36]. Dreams allows users to interact with applications when a device connected to a power source is idle or docked in a desk dock. Android Watch devices MAY implement Dreams, but other types of device implementations SHOULD include support for Dreams and provide a settings option for users to configure Dreams in response to the android.settings.DREAM_SETTINGS intent.

3.8.12. Location

When a device has a hardware sensor (e.g. GPS) that is capable of providing the location coordinates, location modes MUST be displayed in the Location menu within Settings [