Google is committed to advancing racial equity for Black communities. See how.

1. Introduction

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

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.

As used in this document, a “device implementer” or “implementer” is a person or organization developing a hardware/software solution running Android 8.0. A “device implementation” or “implementation is the hardware/software solution so developed.

To be considered compatible with Android 8.0, 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 is both the reference and preferred implementation of Android. Device implementers are STRONGLY RECOMMENDED 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, it is STRONGLY RECOMMENDED to not follow this practice, 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 linked to in this document are derived directly or indirectly from the Android SDK and will be functionally identical to the information in that SDK’s documentation. In any cases where this Compatibility Definition or the Compatibility Test Suite disagrees with the SDK documentation, the SDK documentation is considered authoritative. Any technical details provided in the linked resources throughout this document are considered by inclusion to be part of this Compatibility Definition.

1.1 Document Structure

1.1.1. Requirements by Device Type

Section 2 contains all of the requirements that apply to a specific device type. Each subsection of Section 2 is dedicated to a specific device type.

All the other requirements, that universally apply to any Android device implementations, are listed in the sections after Section 2. These requirements are referenced as "Core Requirements" in this document.

1.1.2. Requirement ID

Requirement ID is assigned for MUST requirements.

The ID is assigned for MUST requirements only.

STRONGLY RECOMMENDED requirements are marked as [SR] but ID is not assigned.

The ID consists of : Device Type ID - Condition ID - Requirement ID (e.g. C-0-1).

Each ID is defined as below:

Device Type ID (see more on 2. Device Types C: Core (Requirements that are applied to any Android device implementations) H: Android Handheld device T: Android Television device A: Android Automotive implementation Tab: Android Tablet implementation

Condition ID When the requirement is unconditional, this ID is set as 0. When the requirement is conditional, 1 is assinged for the 1st condition and the number increments by 1 within the same section and the same device type.

Requirement ID This ID starts from 1 and increments by 1 within the same section and the same condition.



1.1.3. Requirement ID in Section 2

The Requirement ID in Section 2 starts with the corresponding section ID that is followed by the Requirement ID described above.

The ID in Section 2 consists of : Section ID / Device Type ID - Condition ID - Requirement ID (e.g. 7.4.3/A-0-1).

2. Device Types

While the Android Open Source Project provides a software stack that can be used for a variety of device types and form factors, there are a few device types that have a relatively better established application distribution ecosystem.

This section describes those device types, and additional requirements and recommendations applicable for each device type.

All Android device implementations that do not fit into any of the described device types MUST still meet all requirements in the other sections of this Compatibility Definition.

2.1 Device Configurations

For the major differences in hardware configuration by device type, see the device-specific requirements that follow in this section.

2.2. Handheld Requirements

An Android Handheld device refers to an Android device implementation that is typically used by holding it in the hand, such as an mp3 player, phone, or tablet.

Android device implementations are classified as a Handheld if they meet all the following criteria:

Have a power source that provides mobility, such as a battery.

Have a physical diagonal screen size in the range of 2.5 to 8 inches.

The additional requirements in the rest of this section are specific to Android Handheld device implementations.

Note: Requirements that do not apply to Android Tablet devices are marked with an *.

2.2.1. Hardware

Handheld device implementations:

[7.1.1.1/H-0-1] MUST have a screen at least 2.5 inches in physical diagonal size.

[7.1.1.3/H-SR] Are STRONGLY RECOMMENDED to provide users an affordance to change the display size.(Screen Density)

[7.1.5/H-0-1] MUST include support for legacy application compatibility mode as implemented by the upstream Android open source code. That is, device implementations MUST NOT alter the triggers or thresholds at which compatibility mode is activated, and MUST NOT alter the behavior of the compatibility mode itself.

[7.2.1/H-0-1] MUST include support for third-party Input Method Editor (IME) applications.

[7.2.3/H-0-1] MUST provide the Home, Recents, and Back functions.

[7.2.3/H-0-2] MUST send both the normal and long press event of the Back function ( KEYCODE_BACK ) to the foreground application.

) to the foreground application. [7.2.4/H-0-1] MUST support touchscreen input.

[7.3.1/H-SR] Are STRONGLY RECOMMENDED to include a 3-axis accelerometer.

If Handheld device implementations include a 3-axis accelerometer, they:

[7.3.1/H-1-1] MUST be able to report events up to a frequency of at least 100 Hz.

If Handheld device implementations include a gyroscope, they:

[7.3.4/H-1-1] MUST be able to report events up to a frequency of at least 100 Hz.

Handheld device implementations that can make a voice call and indicate any value other than PHONE_TYPE_NONE in getPhoneType :

[7.3.8/H] SHOULD include a proximity sensor.

Handheld device implementations:

[7.3.12/H-SR] Are RECOMMENDED to support pose sensor with 6 degrees of freedom.

[7.4.3/H]SHOULD include support for Bluetooth and Bluetooth LE.

If Handheld device implementations include a metered connection, they:

[7.4.7/H-1-1] MUST provide the data saver mode.

Handheld device implementations:

[7.6.1/H-0-1] MUST have at least 4GB of non-volatile storage available for application private data (a.k.a. "/data" partition).

[7.6.1/H-0-2] MUST return “true” for ActivityManager.isLowRamDevice() when there is less than 1GB of memory available to the kernel and userspace.

If Handheld device implementations are 32-bit:

[7.6.1/H-1-1] The memory available to the kernel and userspace MUST be at least 512MB if any of the following densities are used: 280dpi or lower on small/normal screens * ldpi or lower on extra large screens mdpi or lower on large screens

[7.6.1/H-2-1] The memory available to the kernel and userspace MUST be at least 608MB if any of the following densities are used: xhdpi or higher on small/normal screens * hdpi or higher on large screens mdpi or higher on extra large screens

[7.6.1/H-3-1] The memory available to the kernel and userspace MUST be at least 896MB if any of the following densities are used: 400dpi or higher on small/normal screens * xhdpi or higher on large screens tvdpi or higher on extra large screens

[7.6.1/H-4-1] The memory available to the kernel and userspace MUST be at least 1344MB if any of the following densities are used: 560dpi or higher on small/normal screens * 400dpi or higher on large screens xhdpi or higher on extra large screens



If Handheld device implementations are 64-bit:

[7.6.1/H-5-1] The memory available to the kernel and userspace MUST be at least 816MB if any of the following densities are used: 280dpi or lower on small/normal screens * ldpi or lower on extra large screens mdpi or lower on large screens

[7.6.1/H-6-1] The memory available to the kernel and userspace MUST be at least 944MB if any of the following densities are used: xhdpi or higher on small/normal screens * hdpi or higher on large screens mdpi or higher on extra large screens

[7.6.1/H-7-1] The memory available to the kernel and userspace MUST be at least 1280MB if any of the following densities are used: 400dpi or higher on small/normal screens * xhdpi or higher on large screens tvdpi or higher on extra large screens

[7.6.1/H-8-1] The memory available to the kernel and userspace MUST be at least 1824MB if any of the following densities are used: 560dpi or higher on small/normal screens * 400dpi or higher on large screens xhdpi or higher on extra large screens



Note that the "memory available to the kernel and userspace" above refers to the memory space provided in addition to any memory already dedicated to hardware components such as radio, video, and so on that are not under the kernel’s control on device implementations.

Handheld device implementations:

[7.6.2/H-0-1] MUST NOT provide an application shared storage smaller than 1 GiB.

[7.7.1/H] SHOULD include a USB port supporting peripheral mode.

If handheld device implementations include a USB port supporting peripheral mode, they:

[7.7.1/H-1-1] MUST implement the Android Open Accessory (AOA) API.

Handheld device implementations:

[7.8.1/H-0-1] MUST include a microphone.

[7.8.2/H-0-1] MUST have an audio output and declare android.hardware.audio.output .

If Handheld device implementations include support for the VR mode, they:

[7.9.1/H-1-1] MUST declare the android.software.vr.mode feature.

If device implementations declare android.software.vr.mode feature, they:

[7.9.1/H-2-1] MUST include an application implementing android.service.vr.VrListenerService that can be enabled by VR applications via android.app.Activity#setVrModeEnabled .

If Handheld device implementations are capable of meeting all the requirements to declare the android.hardware.vr.high_performance feature flag, they:

[7.9.2/-1-1] MUST declare the android.hardware.vr.high_performance feature flag.

2.2.2. Multimedia

Handheld device implementations MUST support the following audio encoding:

[5.1.1/H-0-1] AMR-NB

[5.1.1/H-0-2] AMR-WB

[5.1.1/H-0-3] MPEG-4 AAC Profile (AAC LC)

[5.1.1/H-0-4] MPEG-4 HE AAC Profile (AAC+)

[5.1.1/H-0-5] AAC ELD (enhanced low delay AAC)

Handheld device implementations MUST support the following audio decoding:

Handheld device implementations MUST support the following video encoding and make it available to third-party applications:

Handheld device implementations MUST support the following video decoding:

2.2.3. Software

Handheld device implementations:

[3.4.1/H-0-1] MUST provide a complete implementation of the android.webkit.Webview API.

API. [3.4.2/H-0-1] MUST include a standalone Browser application for general user web browsing.

[3.8.1/H-SR] Are STRONGLY RECOMMENDED to implement a default launcher that supports in-app pinning of shortcuts and widgets.

[3.8.1/H-SR] Are STRONGLY RECOMMENDED to implement a default launcher that provides quick access to the additional shortcuts provided by third-party apps through the ShortcutManager API.

[3.8.1/H-SR] Are STRONGLY RECOMMENDED to include a default launcher app that shows badges for the app icons.

[3.8.2/H-SR] Are STRONGLY RECOMMENDED to support third-party app widgets.

[3.8.3/H-0-1] MUST allow third-party apps to notify users of notable events through the Notification and NotificationManager API classes.

and API classes. [3.8.3/H-0-2] MUST support rich notifications.

[3.8.3/H-0-3] MUST support heads-up notifications.

[3.8.3/H-0-4] MUST include a notification shade, providing the user the ability to directly control (e.g. reply, snooze, dismiss, block) the notifications through user affordance such as action buttons or the control panel as implemented in the AOSP.

[3.8.4/H-SR] Are STRONGLY RECOMMENDED to implement an assistant on the device to handle the Assist action.

If Android Handheld device implementations support a lock screen, they:

[3.8.10/H-1-1] MUST display the Lock screen Notifications including the Media Notification Template.

If Handheld device implementations support a secure lock screen, they:

[3.9/H-1-1] MUST implement the full range of device administration policies defined in the Android SDK documentation.

Handheld device implementations:

[3.10/H-0-1] MUST support third-party accessibility services.

[3.10/H-SR] Are STRONGLY RECOMMENDED to preload accessibility services on the device comparable with or exceeding functionality of the Switch Access and TalkBack (for languages supported by the preloaded Text-to-speech engine) accessibility services as provided in the talkback open source project.

[3.11/H-0-1] MUST support installation of third-party TTS engines.

[3.11/H-SR] Are STRONGLY RECOMMENDED to include a TTS engine supporting the languages available on the device.

[3.13/H-SR] Are STRONGLY RECOMMENDED to include a Quick Settings UI component.

If Android handheld device implementations declare FEATURE_BLUETOOTH or FEATURE_WIFI support, they:

[3.15/H-1-1] MUST support the companion device pairing feature.

2.2.4. Performance and Power

[8.1/H-0-1] Consistent frame latency . Inconsistent frame latency or a delay to render frames MUST NOT happen more often than 5 frames in a second, and SHOULD be below 1 frames in a second.

. Inconsistent frame latency or a delay to render frames MUST NOT happen more often than 5 frames in a second, and SHOULD be below 1 frames in a second. [8.1/H-0-2] User interface latency . Device implementations MUST ensure low latency user experience by scrolling a list of 10K list entries as defined by the Android Compatibility Test Suite (CTS) in less than 36 secs.

. Device implementations MUST ensure low latency user experience by scrolling a list of 10K list entries as defined by the Android Compatibility Test Suite (CTS) in less than 36 secs. [8.1/H-0-3] Task switching. When multiple applications have been launched, re-launching an already-running application after it has been launched MUST take less than 1 second.

Handheld device implementations:

[8.2/H-0-1] MUST ensure a sequential write performance of at least 5 MB/s.

[8.2/H-0-2] MUST ensure a random write performance of at least 0.5 MB/s.

[8.2/H-0-3] MUST ensure a sequential read performance of at least 15 MB/s.

[8.2/H-0-4] MUST ensure a random read performance of at least 3.5 MB/s.

[8.3/H-0-1] All Apps exempted from App Standby and Doze power-saving modes MUST be made visible to the end user.

[8.3/H-0-2] The triggering, maintenance, wakeup algorithms and the use of global system settings of App Standby and Doze power-saving modes MUST not deviate from the Android Open Source Project.

Handheld device implementations:

[8.4/H-0-1] MUST provide a per-component power profile that defines the current consumption value for each hardware component and the approximate battery drain caused by the components over time as documented in the Android Open Source Project site.

[8.4/H-0-2] MUST report all power consumption values in milliampere hours (mAh).

[8.4/H-0-3] MUST report CPU power consumption per each process's UID. The Android Open Source Project meets the requirement through the uid_cputime kernel module implementation.

kernel module implementation. [8.4/H-0-4] MUST make this power usage available via the adb shell dumpsys batterystats shell command to the app developer.

shell command to the app developer. [8.4/H] SHOULD be attributed to the hardware component itself if unable to attribute hardware component power usage to an application.

If Handheld device implementations include a screen or video output, they:

[8.4/H-1-1] MUST honor the android.intent.action.POWER_USAGE_SUMMARY intent and display a settings menu that shows this power usage.

2.2.5. Security Model

Handheld device implementations:

[9.1/H-0-1] MUST allow third-party apps to access the usage statistics via the android.permission.PACKAGE_USAGE_STATS permission and provide a user-accessible mechanism to grant or revoke access to such apps in response to the android.settings.ACTION_USAGE_ACCESS_SETTINGS intent.

2.3. Television Requirements

An 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 device implementations are classified as a Television if they meet all the following criteria:

Have provided a mechanism to remotely control the rendered user interface on the display that might sit ten feet away from the user.

Have an embedded screen display with the diagonal length larger than 24 inches OR include a video output port, such as VGA, HDMI, DisplayPort or a wireless port for display.

The additional requirements in the rest of this section are specific to Android Television device implementations.

2.3.1. Hardware

Television device implementations:

[7.2.2/T-0-1] MUST support D-pad.

[7.2.3/T-0-1] MUST provide the Home and Back functions.

[7.2.3/T-0-2] MUST send both the normal and long press event of the Back function ( KEYCODE_BACK ) to the foreground application.

) to the foreground application. [7.2.6.1/T-0-1] MUST include support for game controllers and declare the android.hardware.gamepad feature flag.

feature flag. [7.2.7/T] SHOULD provide a remote control from which users can access non-touch navigation and core navigation keys inputs.

If Television device implementations include a gyroscope, they:

[7.3.4/T-1-1] MUST be able to report events up to a frequency of at least 100 Hz.

Television device implementations:

[7.4.3/T-0-1] MUST support Bluetooth and Bluetooth LE.

[7.6.1/T-0-1] MUST have at least 4GB of non-volatile storage available for application private data (a.k.a. "/data" partition).

If TV device implementations are 32-bit:

[7.6.1/T-1-1] The memory available to the kernel and userspace MUST be at least 896MB if any of the following densities are used: 400dpi or higher on small/normal screens xhdpi or higher on large screens tvdpi or higher on extra large screens



If TV device implementations are 64-bit:

[7.6.1/T-2-1] The memory available to the kernel and userspace MUST be at least 1280MB if any of the following densities are used: 400dpi or higher on small/normal screens xhdpi or higher on large screens tvdpi or higher on extra large screens



Note that the "memory available to the kernel and userspace" above refers to the memory space provided in addition to any memory already dedicated to hardware components such as radio, video, and so on that are not under the kernel’s control on device implementations.

Television device implementations:

[7.8.1/T] SHOULD include a microphone.

[7.8.2/T-0-1] MUST have an audio output and declare android.hardware.audio.output .

2.3.2. Multimedia

Television device implementations MUST support the following audio encoding:

[5.1/T-0-1] MPEG-4 AAC Profile (AAC LC)

[5.1/T-0-2] MPEG-4 HE AAC Profile (AAC+)

[5.1/T-0-3] AAC ELD (enhanced low delay AAC)

Television device implementations MUST support the following video encoding:

Television device implementations:

[5.2.2/T-SR] Are STRONGLY RECOMMENDED to support H.264 encoding of 720p and 1080p resolution videos.

[5.22/T-SR] Are STRONGLY RECOMMENDED to support H.264 encoding of 1080p resolution video at 30 frame-per-second (fps).

Television device implementations MUST support the following video decoding:

Television device implementations are STRONGLY RECOMMENDED to support the following video decoding:

If Television device implementations support H.264 decoders, they:

[5.3.4/T-1-1] MUST support High Profile Level 4.2 and the HD 1080p (at 60 fps) decoding profile.

[5.3.4/T-1-2] MUST be capable of decoding videos with both HD profiles as indicated in the following table and encoded with either the Baseline Profile, Main Profile, or the High Profile Level 4.2

If Television device implementations support H.265 codec and the HD 1080p decoding profile, they:

[5.3.5/T-1-1] MUST support the Main Profile Level 4.1 Main tier.

[5.3.5/T-SR] Are STRONGLY RECOMMENDED to support 60 fps video frame rate for HD 1080p.

If Television device implementations support H.265 codec and the UHD decoding profile, then:

[5.3.5/T-2-1] The codec MUST support Main10 Level 5 Main Tier profile.

If Television device implementations support VP8 codec, they:

[5.3.6/T-1-1] MUST support the HD 1080p60 decoding profile.

If Television device implementations support VP8 codec and support 720p, they:

[5.3.6/T-2-1] MUST support the HD 720p60 decoding profile.

If Television device implementations support VP9 codec and the UHD video decoding, they:

[5.3.7/T-1-1] MUST support 8-bit color depth and SHOULD support VP9 Profile 2 (10-bit).

If Television device implementations support VP9 codec, the 1080p profile and VP9 hardware decoding, they:

[5.3.7/T-2-1] MUST support 60 fps for 1080p.

Television device implementations:

[5.8/T-SR] Are STRONGLY RECOMMENDED to support simultaneous decoding of secure streams. At minimum, simultaneous decoding of two steams is STRONGLY RECOMMENDED.

If device implementations are Android Television devices and support 4K resolution, they:

[5.8/T-1-1] MUST support HDCP 2.2 for all wired external displays.

If Television device implementations don't support 4K resolution, they:

[5.8/T-2-1] MUST support HDCP 1.4 for all wired external displays.

Television device implementations:

[5.5.3/T-0-1] MUST include support for system Master Volume and digital audio output volume attenuation on supported outputs, except for compressed audio passthrough output (where no audio decoding is done on the device).

2.3.3. Software

Television device implementations:

[3/T-0-1] MUST declare the features android.software.leanback and android.hardware.type.television .

and . [3.4.1/T-0-1] MUST provide a complete implementation of the android.webkit.Webview API.

If Android Television device implementations support a lock screen,they:

[3.8.10/T-1-1] MUST display the Lock screen Notifications including the Media Notification Template.

Television device implementations:

[3.8.14/T-SR] Are STRONGLY RECOMMENDED to support picture-in-picture (PIP) mode multi-window.

[3.10/T-0-1] MUST support third-party accessibility services.

[3.10/T-SR] Are STRONGLY RECOMMENDED to preload accessibility services on the device comparable with or exceeding functionality of the Switch Access and TalkBack (for languages supported by the preloaded Text-to-speech engine) accessibility services as provided in the talkback open source project.

If Television device implementations report the feature android.hardware.audio.output , they:

[3.11/T-SR] Are STRONGLY RECOMMENDED to include a TTS engine supporting the languages available on the device.

[3.11/T-1-1] MUST support installation of third-party TTS engines.

Television device implementations:

[3.12/T-0-1] MUST support TV Input Framework.

2.2.4. Performance and Power

[8.1/T-0-1] Consistent frame latency . Inconsistent frame latency or a delay to render frames MUST NOT happen more often than 5 frames in a second, and SHOULD be below 1 frames in a second.

. Inconsistent frame latency or a delay to render frames MUST NOT happen more often than 5 frames in a second, and SHOULD be below 1 frames in a second. [8.2/T-0-1] MUST ensure a sequential write performance of at least 5MB/s.

[8.2/T-0-2] MUST ensure a random write performance of at least 0.5MB/s.

[8.2/T-0-3] MUST ensure a sequential read performance of at least 15MB/s.

[8.2/T-0-4] MUST ensure a random read performance of at least 3.5MB/s.

[8.3/T-0-1] All apps exempted from App Standby and Doze power-saving modes MUST be made visible to the end user.

[8.3/T-0-2] The triggering, maintenance, wakeup algorithms and use of global system settings of App Standby and Doze power-saving modes MUST not deviate from the Android Open Source Project.

Television device implementations:

[8.4/T-0-1] MUST provide a per-component power profile that defines the current consumption value for each hardware component and the approximate battery drain caused by the components over time as documented in the Android Open Source Project site.

[8.4/T-0-2] MUST report all power consumption values in milliampere hours (mAh).

[8.4/T-0-3] MUST report CPU power consumption per each process's UID. The Android Open Source Project meets the requirement through the uid_cputime kernel module implementation.

kernel module implementation. [8.4/T] SHOULD be attributed to the hardware component itself if unable to attribute hardware component power usage to an application.

[8.4/T-0-4] MUST make this power usage available via the adb shell dumpsys batterystats shell command to the app developer.

2.4. Watch Requirements

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

Android device implementations are classified as a Watch if they meet all the following criteria:

Have a screen with the physical diagonal length in the range from 1.1 to 2.5 inches.

Have a mechanism provided to be worn on the body.

The additional requirements in the rest of this section are specific to Android Watch device implementations.

2.4.1. Hardware

Watch device implementations:

[7.1.1.1/W-0-1] MUST have a screen with the physical diagonal size in the range from 1.1 to 2.5 inches.

[7.2.3/W-0-1] MUST have the Home function available to the user, and the Back function except for when it is in UI_MODE_TYPE_WATCH .

[7.2.4/W-0-1] MUST support touchscreen input.

[7.3.1/W-SR] Are STRONGLY RECOMMENDED to include a 3-axis accelerometer.

[7.4.3/W-0-1] MUST support Bluetooth.

[7.6.1/W-0-1] MUST have at least 1GB of non-volatile storage available for application private data (a.k.a. "/data" partition)

[7.6.1/W-0-2] MUST have at least 416MB memory available to the kernel and userspace.

[7.8.1/W-0-1] MUST include a microphone.

[7.8.2/W] MAY but SHOULD NOT have audio output.

2.4.2. Multimedia

No additional requirements.

2.4.3. Software

Watch device implementations:

[3/W-0-1] MUST declare the feature android.hardware.type.watch .

. [3/W-0-2] MUST support uiMode = UI_MODE_TYPE_WATCH.

Watch device implementations:

[3.8.4/W-SR] Are STRONGLY RECOMMENDED to implement an assistant on the device to handle the Assist action.

Watch device implementations that declare the android.hardware.audio.output feature flag:

[3.10/W-1-1] MUST support third-party accessibility services.

[3.10/W-SR] Are STRONGLY RECOMMENDED to preload accessibility services on the device comparable with or exceeding functionality of the Switch Access and TalkBack (for languages supported by the preloaded Text-to-speech engine) accessibility services as provided in the talkback open source project.

If Watch device implementations report the feature android.hardware.audio.output, they:

[3.11/W-SR] Are STRONGLY RECOMMENDED to include a TTS engine supporting the languages available on the device.

[3.11/W-0-1] MUST support installation of third-party TTS engines.

2.5. Automotive Requirements

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 device implementations are classified as an Automotive if they declare the feature android.hardware.type.automotive or meet all the following criteria.

Are embedded as part of, or pluggable to, an automotive vehicle.

Are using a screen in the driver's seat row as the primary display.

The additional requirements in the rest of this section are specific to Android Automotive device implementations.

2.5.1. Hardware

Automotive device implementations:

[7.1.1.1/A-0-1] MUST have a screen at least 6 inches in physical diagonal size.

[7.1.1.1/A-0-2] MUST have a screen size layout of at least 750 dp x 480 dp.

[7.2.3/A-0-1] MUST provide the Home function and MAY provide Back and Recent functions.

[7.2.3/A-0-2] MUST send both the normal and long press event of the Back function ( KEYCODE_BACK ) to the foreground application.

[7.3.1/A-SR] Are STRONGLY RECOMMENDED to include a 3-axis accelerometer.

If Automotive device implementations include a 3-axis accelerometer, they:

[7.3.1/A-1-1] MUST be able to report events up to a frequency of at least 100 Hz.

[7.3.1/A-1-2] MUST comply with the Android car sensor coordinate system.

If Automotive device implementations include a GPS/GNSS receiver and report the capability to applications through the android.hardware.location.gps feature flag:

[7.3.3/A-1-1] GNSS technology generation MUST be the year "2017" or newer.

If Automotive device implementations include a gyroscope, they:

[7.3.4/A-1-1] MUST be able to report events up to a frequency of at least 100 Hz.

Automotive device implementations:

[7.3.11/A] SHOULD provide current gear as SENSOR_TYPE_GEAR .

Automotive device implementations:

[7.3.11.2/A-0-1] MUST support day/night mode defined as SENSOR_TYPE_NIGHT .

. [7.3.11.2/A-0-2] The value of the SENSOR_TYPE_NIGHT flag MUST be consistent with dashboard day/night mode and SHOULD be based on ambient light sensor input.

flag MUST be consistent with dashboard day/night mode and SHOULD be based on ambient light sensor input. The underlying ambient light sensor MAY be the same as Photometer.

[7.3.11.3/A-0-1] MUST support driving status defined as SENSOR_TYPE_DRIVING_STATUS , with a default value of DRIVE_STATUS_UNRESTRICTED when the vehicle is fully stopped and parked. It is the responsibility of device manufacturers to configure SENSOR_TYPE_DRIVING_STATUS in compliance with all laws and regulations that apply to markets where the product is shipping.

[7.3.11.4/A-0-1] MUST provide vehicle speed defined as SENSOR_TYPE_CAR_SPEED .

[7.4.3/A-0-1] MUST support Bluetooth and SHOULD support Bluetooth LE.

[7.4.3/A-0-2] Android Automotive implementations MUST support the following Bluetooth profiles: Phone calling over Hands-Free Profile (HFP). Media playback over Audio Distribution Profile (A2DP). Media playback control over Remote Control Profile (AVRCP). Contact sharing using the Phone Book Access Profile (PBAP).

[7.4.3/A] SHOULD support Message Access Profile (MAP).

[7.4.5/A] SHOULD include support for cellular network based data connectivity.

[7.6.1/A-0-1] MUST have at least 4GB of non-volatile storage available for application private data (a.k.a. "/data" partition).

If Automotive device implementations are 32-bit:

[7.6.1/A-1-1] The memory available to the kernel and userspace MUST be at least 512MB if any of the following densities are used: 280dpi or lower on small/normal screens ldpi or lower on extra large screens mdpi or lower on large screens

[7.6.1/A-1-2] The memory available to the kernel and userspace MUST be at least 608MB if any of the following densities are used: xhdpi or higher on small/normal screens hdpi or higher on large screens mdpi or higher on extra large screens

[7.6.1/A-1-3] The memory available to the kernel and userspace MUST be at least 896MB if any of the following densities are used: 400dpi or higher on small/normal screens xhdpi or higher on large screens tvdpi or higher on extra large screens

[7.6.1/A-1-4] The memory available to the kernel and userspace MUST be at least 1344MB if any of the following densities are used: 560dpi or higher on small/normal screens 400dpi or higher on large screens xhdpi or higher on extra large screens



If Automotive device implementations are 64-bit:

[7.6.1/A-2-1] The memory available to the kernel and userspace MUST be at least 816MB if any of the following densities are used: 280dpi or lower on small/normal screens ldpi or lower on extra large screens mdpi or lower on large screens

[7.6.1/A-2-2] The memory available to the kernel and userspace MUST be at least 944MB if any of the following densities are used: xhdpi or higher on small/normal screens hdpi or higher on large screens mdpi or higher on extra large screens

[7.6.1/A-2-3] The memory available to the kernel and userspace MUST be at least 1280MB if any of the following densities are used: 400dpi or higher on small/normal screens xhdpi or higher on large screens tvdpi or higher on extra large screens

[7.6.1/A-2-4] The memory available to the kernel and userspace MUST be at least 1824MB if any of the following densities are used: 560dpi or higher on small/normal screens 400dpi or higher on large screens xhdpi or higher on extra large screens



Note that the "memory available to the kernel and userspace" above refers to the memory space provided in addition to any memory already dedicated to hardware components such as radio, video, and so on that are not under the kernel’s control on device implementations.

Automotive device implementations:

[7.7.1/A] SHOULD include a USB port supporting peripheral mode.

Automotive device implementations:

[7.8.1/A-0-1] MUST include a microphone.

Automotive device implementations:

[7.8.2/A-0-1] MUST have an audio output and declare android.hardware.audio.output .

2.5.2. Multimedia

Automotive device implementations MUST support the following audio encoding:

[5.1/A-0-1] MPEG-4 AAC Profile (AAC LC)

[5.1/A-0-2] MPEG-4 HE AAC Profile (AAC+)

[5.1/A-0-3] AAC ELD (enhanced low delay AAC)

Automotive device implementations MUST support the following video encoding:

Automotive device implementations MUST support the following video decoding:

Automotive device implementations are STRONGLY RECOMMENDED to support the following video decoding:

2.5.3. Software

Automotive device implementations:

[3/A-0-1] MUST declare the feature android.hardware.type.automotive .

. [3/A-0-2] MUST support uiMode = UI_MODE_TYPE_CAR.

[3/A-0-3] Android Automotive implementations MUST support all public APIs in the android.car.* namespace.

[3.4.1/A-0-1] MUST provide a complete implementation of the android.webkit.Webview API.

[3.8.3/A-0-1] MUST display notifications that use the Notification.CarExtender API when requested by third-party applications.

[3.8.4/A-0-1] MUST implement an assistant on the device to handle the Assist action.

[3.14/A-0-1] MUST include a UI framework to support third-party apps using the media APIs as described in section 3.14.

2.2.4. Performance and Power

Automotive device implementations:

[8.3/A-0-1] All Apps exempted from App Standby and Doze power-saving modes MUST be made visible to the end user.

[8.3/A-0-2] The triggering, maintenance, wakeup algorithms and the use of global system settings of App Standby and Doze power-saving modes MUST not deviate from the Android Open Source Project.

[8.4/A-0-1] MUST provide a per-component power profile that defines the current consumption value for each hardware component and the approximate battery drain caused by the components over time as documented in the Android Open Source Project site.

[8.4/A-0-2] MUST report all power consumption values in milliampere hours (mAh).

[8.4/A-0-3] MUST report CPU power consumption per each process's UID. The Android Open Source Project meets the requirement through the uid_cputime kernel module implementation.

kernel module implementation. [8.4/A] SHOULD be attributed to the hardware component itself if unable to attribute hardware component power usage to an application.

[8.4/A-0-4] MUST make this power usage available via the adb shell dumpsys batterystats shell command to the app developer.

2.2.5. Security Model

If Automotive device implementations include multiple users, they:

[9.5/A-1-1] MUST include a guest account that allows all functions provided by the vehicle system without requiring a user to log in.

Automotive device implementations:

[9.14/A-0-1] MUST gatekeep messages from Android framework vehicle subsystems, e.g., whitelisting permitted message types and message sources.

[9.14/A-0-2] MUST watchdog against denial of service attacks from the Android framework or third-party apps. This guards against malicious software flooding the vehicle network with traffic, which may lead to malfunctioning vehicle subsystems.

2.6. Tablet Requirements

An Android Tablet device refers to an Android device implementation that is typically used by holding in both hands and not in a clamshell form-factor.

Android device implementations are classified as a Tablet if they meet all the following criteria:

Have a power source that provides mobility, such as a battery.

Have a physical diagonal screen size in the range of 7 to 18 inches.

Tablet device implementations have similar requirements to handheld device implementations. The exceptions are in indicated by and * in that section and noted for reference in this section.

2.4.1. Hardware

Screen Size

[7.1.1.1/Tab-0-1] MUST have a screen in the range of 7 to 18 inches.

Minimum Memory and Storage (Section 7.6.1)

The screen densities listed for small/normal screens in the handheld requirements are not applicable to tablets.

USB peripheral mode (Section 7.7.1)

If tablet device implementations include a USB port supporting peripheral mode, they:

[7.7.1/Tab]MAY implement the Android Open Accessory (AOA) API.

Virtual Reality Mode (Section 7.9.1)

Virtual Reality High Performance (Section 7.9.2)

Virtual reality requirements are not applicable to tablets.

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.

[C-0-1] Device implementations MUST provide complete implementations, including all documented behaviors, of any documented API exposed by the Android SDK or any API decorated with the “@SystemApi” marker in the upstream Android source code.

[C-0-2] Device implementations MUST support/preserve all classes, methods, and associated elements marked by the TestApi annotation (@TestApi).

[C-0-3] 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.

[C-0-4] Device implementations MUST still keep the APIs present and behave in a reasonable way, even when some hardware features for which Android includes APIs are omitted. See section 7 for specific requirements for this scenario.

3.1.1. Android Extensions

Android includes the support of extending the managed APIs while keeping the same API level version.

[C-0-1] Android device implementations MUST preload the AOSP implementation of both the shared library ExtShared and services ExtServices with versions higher than or equal to the minimum versions allowed per each API level. For example, Android 7.0 device implementations, running API level 24 MUST include at least version 1.

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

[C-0-1] Device implementers MUST support and enforce all permission constants as documented by the Permission reference page. 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 that are intended to describe the current device.

[C-0-1] 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 8.0. VERSION.SDK The version of the currently-executing Android system, in a format accessible to third-party application code. For Android 8.0, this field MUST have the integer value 8.0_INT. VERSION.SDK_INT The version of the currently-executing Android system, in a format accessible to third-party application code. For Android 8.0, this field MUST have the integer value 8.0_INT. 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_-]+$”. This device name MUST NOT change during the lifetime of the product. 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:8.0/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 (""). This field MUST NOT change during the lifetime of the product. 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 (""). This field MUST NOT change during the lifetime of the product. 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_-]+$”. This product name MUST NOT change during the lifetime of the product. SERIAL A hardware serial number, which MUST be available and unique across devices with the same MODEL and MANUFACTURER. 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 (""). SECURITY_PATCH A value indicating the security patch level of a build. It MUST signify that the build is not in any way vulnerable to any of the issues described up through the designated Android Public Security Bulletin. It MUST be in the format [YYYY-MM-DD], matching a defined string documented in the Android Public Security Bulletin or in the Android Security Advisory, for example "2015-11-01". BASE_OS A value representing the FINGERPRINT parameter of the build that is otherwise identical to this build except for the patches provided in the Android Public Security Bulletin. It MUST report the correct value and if such a build does not exist, report an empty string (""). BOOTLOADER A value chosen by the device implementer identifying the specific internal bootloader version used in the device, in human-readable format. The value of this field MUST be encodable as 7-bit ASCII and match the regular expression “^[a-zA-Z0-9._-]+$”. getRadioVersion() MUST (be or return) a value chosen by the device implementer identifying the specific internal radio/modem version used in the device, in human-readable format. If a device does not have any internal radio/modem it MUST return NULL. The value of this field MUST be encodable as 7-bit ASCII and match the regular expression “^[a-zA-Z0-9._-,]+$”.

3.2.3. Intent Compatibility

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.

[C-0-1] Device implementations MUST include these application, service components, or at least a handler, for all the public intent filter patterns defined by the following core Android applications in AOSP: Desk Clock Browser Calendar Contacts Gallery GlobalSearch Launcher Music Settings



3.2.3.2. Intent Resolution

[C-0-1] 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.

[C-0-2] Dvice 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.

[C-0-3] Device implementations MUST provide a user interface for users to modify the default activity for intents.

However, device implementations MAY provide default activities for specific URI patterns (e.g. http://play.google.com) when the default activity provides a more specific attribute for the data URI. For example, an intent filter pattern specifying the data URI “http://www.android.com” is more specific than the browser's core intent pattern for “http://”.

Android also includes a mechanism for third-party apps to declare an authoritative default app linking behavior for certain types of web URI intents. When such authoritative declarations are defined in an app's intent filter patterns, device implementations:

[C-0-4] MUST attempt to validate any intent filters by performing the validation steps defined in the Digital Asset Links specification as implemented by the Package Manager in the upstream Android Open Source Project.

[C-0-5] MUST attempt validation of the intent filters during the installation of the application and set all successfully validated URI intent filters as default app handlers for their URIs.

MAY set specific URI intent filters as default app handlers for their URIs, if they are successfully verified but other candidate URI filters fail verification. If a device implementation does this, it MUST provide the user appropriate per-URI pattern overrides in the settings menu.

MUST provide the user with per-app App Links controls in Settings as follows: [C-0-6] The user MUST be able to override holistically the default app links behavior for an app to be: always open, always ask, or never open, which must apply to all candidate URI intent filters equally. [C-0-7] The user MUST be able to see a list of the candidate URI intent filters. The device implementation MAY provide the user with the ability to override specific candidate URI intent filters that were successfully verified, on a per-intent filter basis. [C-0-8] The device implementation MUST provide users with the ability to view and override specific candidate URI intent filters if the device implementation lets some candidate URI intent filters succeed verification while some others can fail.



3.2.3.3. Intent Namespaces

[C-0-1] 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.

[C-0-2] 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.

[C-0-3] 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.

Device implementations:

[C-0-1] MUST broadcast the public broadcast intents in response to appropriate system events as described in the SDK documentation. Note that this requirement is not conflicting with section 3.5 as the limitation for background applications are also 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.

If device implementations report android.software.home_screen , they:

[C-1-1] MUST honor the android.settings.HOME_SETTINGS intent to show a default app settings menu for Home Screen.

If device implementations report android.hardware.telephony , they:

[C-2-1] 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 device implementations report android.hardware.nfc.hce , they:

[C-3-1] MUST honor the android.settings.NFC_PAYMENT_SETTINGS intent to show a default app settings menu for Tap and Pay.

If device implementations report android.hardware.telephony , they:

[C-4-1] MUST honor the android.telecom.action.CHANGE_DEFAULT_DIALER intent to show a dialog to allow the user to change the default Phone application.

If device implementations support the VoiceInteractionService, they:

[C-5-1] MUST honor the android.settings.ACTION_VOICE_INPUT_SETTINGS intent to show a default app settings menu for voice input and assist.

3.2.4. Activities on secondary displays

If device implementations allow launching normal Android Activities on secondary displays, they:

[C-1-1] MUST set the android.software.activities_on_secondary_displays feature flag.

feature flag. [C-1-2] MUST guarantee API compatibility similar to an activity running on the primary display.

[C-1-3] MUST land the new activity on the same display as the activity that launched it, when the new activity is launched without specifying a target display via the ActivityOptions.setLaunchDisplayId() API.

API. [C-1-4] MUST destory all activities, when a display with the Display.FLAG_PRIVATE flag is removed.

flag is removed. [C-1-5] MUST resize accordingly all activities on a VirtualDisplay if the display itself is resized.

if the display itself is resized. MAY show an IME (input method editor, a user control that enables users to enter text) on the primary display, when a text input field becomes focused on a secondary display.

SHOULD implement the input focus on the secondary display independently of the primary display, when touch or key inputs are supported.

SHOULD have android.content.res.Configuration which corresponds to that display in order to be displayed, operate correctly, and maintain compatibility if an activity is launched on secondary display.

If device implementations allow launching normal Android Activities on secondary displays and primary and secondary displays have different android.util.DisplayMetrics:

[C-2-1] Non-resizeable activities (that have resizeableActivity=false in AndroidManifest.xml ) and apps targeting API level 23 or lower MUST NOT be allowed on secondary displays.

If device implementations allow launching normal Android Activities on secondary displays and a secondary display has the android.view.Display.FLAG_PRIVATE flag:

[C-3-1] Only the owner of that display, system, and activities that are already on that display MUST be able to launch to it. Everyone can launch to a display that has android.view.Display.FLAG_PUBLIC flag.

3.3. Native API Compatibility

Native code compatibility is challenging. For this reason, device implementers are:

[SR] STRONGLY RECOMMENDED to use the implementations of the libraries listed below from the upstream Android Open Source Project.

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:

[C-0-1] MUST be compatible with one or more defined ABIs and implement compatibility with the Android NDK.

[C-0-2] MUST include support for code running in the managed environment to call into native code, using the standard Java Native Interface (JNI) semantics.

[C-0-3] MUST be source-compatible (i.e. header-compatible) and binary-compatible (for the ABI) with each required library in the list below.

[C-0-4] MUST support the equivalent 32-bit ABI if any 64-bit ABI is supported.

[C-0-5] 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.

, , and parameters, each a comma separated list of ABIs ordered from the most to the least preferred one. [C-0-6] MUST report, via the above parameters, only those ABIs documented and described in the latest version of the Android NDK ABI Management documentation, and MUST include support for the Advanced SIMD (a.k.a. NEON) extension.

[C-0-7] MUST make all the following libraries, providing native APIs, available to apps that include native code: libaaudio.so (AAudio native audio support) libandroid.so (native Android activity support) libc (C library) libcamera2ndk.so libdl (dynamic linker) libEGL.so (native OpenGL surface management) libGLESv1_CM.so (OpenGL ES 1.x) libGLESv2.so (OpenGL ES 2.0) libGLESv3.so (OpenGL ES 3.x) libicui18n.so libicuuc.so libjnigraphics.so liblog (Android logging) libmediandk.so (native media APIs support) libm (math library) libOpenMAXAL.so (OpenMAX AL 1.0.1 support) libOpenSLES.so (OpenSL ES 1.0.1 audio support) libRS.so libstdc++ (Minimal support for C++) libvulkan.so (Vulkan) libz (Zlib compression) JNI interface

[C-0-8] MUST NOT add or remove the public functions for the native libraries listed above.

[C-0-9] MUST list additional non-AOSP libraries exposed directly to third-party apps in /vendor/etc/public.libraries.txt .

. [C-0-10] MUST NOT expose any other native libraries, implemented and provided in AOSP as system libraries, to third-party apps targeting API level 24 or higher as they are reserved.

[C-0-11] MUST export all the OpenGL ES 3.1 and Android Extension Pack function symbols, as defined in the NDK, through the libGLESv3.so library. Note that while all the symbols MUST be present, section 7.1.4.1 describes in more detail the requirements for when the full implementation of each corresponding functions are expected.

library. Note that while all the symbols MUST be present, section 7.1.4.1 describes in more detail the requirements for when the full implementation of each corresponding functions are expected. [C-0-12] MUST export function symbols for the core Vulkan 1.0 function symobls, as well as the VK_KHR_surface , VK_KHR_android_surface , VK_KHR_swapchain , VK_KHR_maintenance1 , and VK_KHR_get_physical_device_properties2 extensions through the libvulkan.so library. Note that while all the symbols MUST be present, section 7.1.4.2 describes in more detail the requirements for when the full implementation of each corresponding functions are expected.

, , , , and extensions through the library. Note that while all the symbols MUST be present, section 7.1.4.2 describes in more detail the requirements for when the full implementation of each corresponding functions are expected. SHOULD be built using the source code and header files available in the upstream Android Open Source Project

Note that future releases of the Android NDK may introduce support for additional ABIs.

3.3.2. 32-bit ARM Native Code Compatibility

If device implementations are 64-bit ARM devices, then:

[C-1-1] Although the ARMv8 architecture deprecates several CPU operations, including some operations used in existing native code, 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



If device implementations include a 32-bit ARM ABI, they:

[C-2-1] MUST include the following lines in /proc/cpuinfo when it is read by 32-bit ARM applications to ensure compatibility with applications built using legacy versions of Android NDK. 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).

SHOULD not alter /proc/cpuinfo when read by 64-bit ARM or non-ARM applications.

3.4. Web Compatibility

3.4.1. WebView Compatibility

If device implementations provide a complete implementation of the android.webkit.Webview API, they:

[C-1-1] MUST report android.software.webview .

. [C-1-2] MUST use the Chromium Project build from the upstream Android Open Source Project on the Android 8.0 branch for the implementation of the android.webkit.WebView API.

API. [C-1-3] The user agent string reported by the WebView MUST be in this format: Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv) 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 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.

3.4.2. Browser Compatibility

If device implementations include a standalone Browser application for general web browsing, they:

[C-1-1] MUST support each of these APIs associated with HTML5: application cache/offline operation <video> tag geolocation

[C-1-2] MUST support the HTML5/W3C webstorage API and SHOULD support the HTML5/W3C IndexedDB API. 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.

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

SHOULD implement support for as much of HTML5 as possible on the standalone Browser application (whether based on the upstream WebKit Browser application or a third-party replacement).

However, If device implementations do not include a standalone Browser application, they:

[C-2-1] MUST still support the public intent patterns as described in section 3.2.3.1.

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. Some specific areas of compatibility are:

[C-0-1] Devices MUST NOT change the behavior or semantics of a standard intent.

[C-0-2] Devices MUST NOT alter the lifecycle or lifecycle semantics of a particular type of system component (such as Service, Activity, ContentProvider, etc.).

[C-0-3] Devices MUST NOT change the semantics of a standard permission.

Devices MUST NOT alter the limitations enforced on background applications. More specifically, for background apps: [C-0-4] they MUST stop executing callbacks that are registered by the app to receive outputs from the GnssMeasurement and GnssNavigationMessage . [C-0-5] they MUST rate-limit the frequency of updates that are provided to the app through the LocationManager API class or the WifiManager.startScan() method. [C-0-6] if the app is targeting API level 25 or higher, they MUST NOT allow to register broadcast receivers for the implicit broadcasts of standard Android intents in the app's manifest, unless the broadcast intent requires a "signature" or "signatureOrSystem" protectionLevel permission or are on the exemption list . [C-0-7] if the app is targeting API level 25 or higher, they MUST stop the app's background services, just as if the app had called the services' stopSelf() method, unless the app is placed on a temporary whitelist to handle a task that's visible to the user. [C-0-8] if the app is targeting API level 25 or higher, they MUST release the wakelocks the app holds.



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.*

That is, they:

[C-0-1] 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.

[C-0-2] MUST NOT add any publicly exposed elements (such as classes or interfaces, or fields or methods to existing classes or interfaces) or Test or System APIs to the APIs in the above namespaces. A “publicly exposed element” is any construct that is not decorated with the “@hide” marker as used in the upstream Android source code.

Device implementers MAY modify the underlying implementation of the APIs, but such modifications:

[C-0-3] MUST NOT impact the stated behavior and Java-language signature of any publicly exposed APIs.

[C-0-4] MUST NOT be advertised or otherwise exposed to developers.

However, device implementers MAY add custom APIs outside the standard Android namespace, but the custom APIs:

[C-0-5] 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.

or similar namespace: only Google may do so. Similarly, Google MUST NOT add APIs to other companies' namespaces. [C-0-6] 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:

[C-0-1] MUST support the full Dalvik Executable (DEX) format and Dalvik bytecode specification and semantics.

[C-0-2] 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.)

SHOULD use Android RunTime (ART), the reference upstream implementation of the Dalvik Executable Format, and the reference implementation’s package management system.

SHOULD run fuzz tests under various modes of execution and target architectures to assure the stability of the runtime. Refer to JFuzz and DexFuzz in the Android Open Source Project website.

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 Android Watch 120 dpi (ldpi) 32MB 160 dpi (mdpi) 213 dpi (tvdpi) 240 dpi (hdpi) 36MB 280 dpi (280dpi) 320 dpi (xhdpi) 48MB 360 dpi (360dpi) 400 dpi (400dpi) 56MB 420 dpi (420dpi) 64MB 480 dpi (xxhdpi) 88MB 560 dpi (560dpi) 112MB 640 dpi (xxxhdpi) 154MB small/normal 120 dpi (ldpi) 32MB 160 dpi (mdpi) 213 dpi (tvdpi) 48MB 240 dpi (hdpi) 280 dpi (280dpi) 320 dpi (xhdpi) 80MB 360 dpi (360dpi) 400 dpi (400dpi) 96MB 420 dpi (420dpi) 112MB 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 360 dpi (360dpi) 160MB 400 dpi (400dpi) 192MB 420 dpi (420dpi) 228MB 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 360 dpi (360dpi) 240MB 400 dpi (400dpi) 288MB 420 dpi (420dpi) 336MB 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).

If device implementations allow third-party applications to replace the device home screen, they:

[C-1-1] MUST declare the platform feature android.software.home_screen .

. [C-1-2] MUST return the AdaptiveIconDrawable object when the third party application use <adaptive-icon> tag to provide their icon, and the PackageManager methods to retrieve icons are called.

If device implementations include a default launcher that supports in-app pinning of shortcuts, they:

[C-2-1] MUST report true for ShortcutManager.isRequestPinShortcutSupported() .

for . [C-2-2] MUST have user affordance asking the user before adding a shortcut requested by apps via the ShortcutManager.requestPinShortcut() API method.

Conversely, if device implementations do not support in-app pinning, they:

[C-3-1] MUST report false for ShortcutManager.isRequestPinShortcutSupported() and AppWidgetManager.html#isRequestPinAppWidgetSupported() .

If device implementations implement a default launcher that provides quick access to the additional shortcuts provided by third-party apps through the ShortcutManager API, they:

[C-4-1] MUST support all documented shortcut features (e.g. static and dynamic shortcuts, pinning shortcuts) and fully implement the APIs of the ShortcutManager API class.

If device implementations include a default launcher app that shows badges for the app icons, they:

[C-5-1] MUST respect the NotificationChannel.setShowBadge() API method. In other words, show a visual affordance associated with the app icon if the value is set as true , and do not show any app icon badging scheme when all of the app's notification channels have set the value as false .

API method. In other words, show a visual affordance associated with the app icon if the value is set as , and do not show any app icon badging scheme when all of the app's notification channels have set the value as . MAY override the app icon badges with their proprietary badging scheme when third-party applications indicate support of the proprietary badging scheme through the use of proprietary APIs, but SHOULD use the resources and values provided through the notification badges APIs described in the SDK , such as the Notification.Builder.setNumber() and the Notification.Builder.setBadgeIconType() API.

3.8.2. Widgets

Android supports third-party app widgets by defining a component type and corresponding API and lifecycle that allows applications to expose an “AppWidget” to the end user.

If device implementations support third-party app widgets, they:

[C-1-1] MUST declare support for platform feature android.software.app_widgets.

[C-1-2] MUST include built-in support for AppWidgets and expose user interface affordances to add, configure, view, and remove AppWidgets directly within the Launcher.

[C-1-3] 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 for details.

MAY support application widgets on the lock screen.

If device implementations support third-party app widgets and in-app pinning of shortcuts, they:

[C-2-1] MUST report true for AppWidgetManager.html.isRequestPinAppWidgetSupported() .

for . [C-2-2] MUST have user affordance asking the user before adding a shortcut requested by apps via the AppWidgetManager.requestPinAppWidget() API method.

3.8.3. Notifications

Android includes Notification and NotificationManager APIs that allow third-party app developers to notify users of notable events and attract users' attention using the hardware components (e.g. sound, vibration and light) and software features (e.g. notification shade, system bar) of the device.

3.8.3.1. Presentation of Notifications

If device implementations allow third party apps to notify users of notable events, they:

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

[C-1-2] MUST correctly render all resources (icons, animation files etc.) provided for in the APIs, or in the Status/System Bar icon style guide, although they MAY provide an alternative user experience for notifications than that provided by the reference Android Open Source implementation.

[C-1-3] MUST honor and implement properly the behaviors described for the APIs to update, remove and group notifications.

[C-1-4] MUST provide the full behavior of the NotificationChannel API documented in the SDK.

[C-1-5] MUST provide a user affordance to block and modify a certain third-party app's notification per each channel and app package level.

[C-1-6] MUST also provide a user affordance to display deleted notification channels.

SHOULD support rich notifications.

SHOULD present some higher priority notifications as heads-up notifications.

SHOULD have user affordance to snooze notifications.

MAY only manage the visibility and timing of when third-party apps can notify users of notable events to mitigate safety issues such as driver distraction.

If device implementations support rich notifications, they:

[C-2-1] MUST use the exact resources as provided through the Notification.Style API class and its subclasses for the presented resource elements.

API class and its subclasses for the presented resource elements. SHOULD present each and every resource element (e.g. icon, title and summary text) defined in the Notification.Style API class and its subclasses.

If device impelementations support heads-up notifications: they:

[C-3-1] MUST use the heads-up notification view and resources as described in the Notification.Builder API class when heads-up notifications are presented.

3.8.3.2. Notification Listener Service

Android includes the NotificationListenerService 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:

[C-0-1] MUST correctly and promptly update notifications in their entirety to all such installed and user-enabled listener services, including any and all metadata attached to the Notification object.

[C-0-2] MUST respect the snoozeNotification() API call, and dismiss the notification and make a callback after the snooze duration that is set in the API call.

If device implementations have a user affordance to snooze notifications, they:

[C-1-1] MUST reflect the snoozed notification status properly through the standard APIs such as NotificationListenerService.getSnoozedNotifications() .

. [C-1-2] MUST make this user affordance available to snooze notifications from each installed third-party app's, unless they are from persistent/foreground services.

3.8.3.3. DND (Do not Disturb)

If device implementations support the DND feature, they:

[C-1-1] MUST implement an activity that would respond to the intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS, which for implementations with UI_MODE_TYPE_NORMAL it MUST be an activity where the user can grant or deny the app access to DND policy configurations.

[C-1-2] MUST, for when the device implementation has provided a means for the user to grant or deny third-party apps to access the DND policy configuration, display Automatic DND rules created by applications alongside the user-created and pre-defined rules.

[C-1-3] MUST honor the suppressedVisualEffects values passed along the NotificationManager.Policy and if an app has set any of the SUPPRESSED_EFFECT_SCREEN_OFF or SUPPRESSED_EFFECT_SCREEN_ON flags, it SHOULD indicate to the user that the visual effects are suppressed in the DND settings menu.

3.8.4. Search

Android includes APIs 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.

If device implementations implement the global search interface, they:

[C-1-1] 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 the global search:

The default behavior SHOULD be to display web search engine results and suggestions.

Android also includes the Assist APIs to allow applications to elect how much information of the current context is shared with the assistant on the device.

If device implementations support the Assist action, they:

[C-2-1] MUST indicate clearly to the end user when the context is shared, by either: Each time the assist app accesses the context, displaying a white light around the edges of the screen that meet or exceed the duration and brightness of the Android Open Source Project implementation. For the preinstalled assist app, providing a user affordance less than two navigations away from the default voice input and assistant app settings menu, and only sharing the context when the assist app is explicitly invoked by the user through a hotword or assist navigation key input.

[C-2-2] The designated interaction to launch the assist app as described in section 7.2.3 MUST launch the user-selected assist app, in other words the app that implements VoiceInteractionService , or an activity handling the ACTION_ASSIST intent.

, or an activity handling the intent. [C-SR] STRONGLY RECOMMENDED to use long press on HOME key as this designated interaction.

3.8.5. Alerts and 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, and use the TYPE_APPLICATION_OVERLAY window type API to display alert windows as an overlay over other apps.

If device implementations include a screen or video output, they:

[C-1-1] MUST provide a user affordance to block an app from displaying alert windows that use the TYPE_APPLICATION_OVERLAY . The AOSP implementation meets this requirement by having controls in the notification shade.

[C-1-2] MUST honor the Toast API and display Toasts from applications to end users in some highly visible 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” and "Material" 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.

If device implementations include a screen or video output, they:

[C-1-1] MUST NOT alter any of the Holo theme attributes exposed to applications.

[C-1-2] MUST support the “Material” theme family and MUST NOT alter any of the Material theme attributes or their assets exposed to applications.

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.

Android supports a 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.

If device implementations include a system status bar, they:

[C-2-1] 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 or an app requests a light status bar using the SYSTEM_UI_FLAG_LIGHT_STATUS_BAR flag.

[C-2-2] Android device implementations MUST change the color of the system status icons to black (for details, refer to R.style) when an app requests a light status bar.

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. 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.

If device implementations implement live wallpapers, they:

[C-1-1] MUST report the platform feature flag android.software.live_wallpaper.

3.8.8. Activity Switching

The upstream Android source code includes the overview screen, 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.

If device implementations including the recents function navigation key as detailed in section 7.2.3 alter the interface, they:

[C-1-1] MUST support at least up to 20 displayed activities.

SHOULD at least display the title of 4 activities at a time.

[C-1-2] MUST implement the screen pinning behavior and provide the user with a settings menu to toggle the feature.

SHOULD display highlight color, icon, screen title in recents.

SHOULD display a closing affordance ("x") but MAY delay this until user interacts with screens.

SHOULD implement a shortcut to switch easily to the previous activity

SHOULD trigger the fast-switch action between the two most recently used apps, when the recents function key is tapped twice.

SHOULD trigger the split-screen multiwindow-mode, if supported, when the recents functions key is long pressed.

MAY display affiliated recents as a group that moves together.

[C-SR] Device implementations are STRONGLY RECOMMENDED 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.

If device implementations allow users to use third-party input methods on the device, they:

[C-1-1] MUST declare the platform feature android.software.input_methods and support IME APIs as defined in the Android SDK documentation.

[C-1-2] MUST provide a user-accessible mechanism to add and configure third-party input methods in response to the android.settings.INPUT_METHOD_SETTINGS intent.

If device implementations declare the android.software.autofill feature flag, they:

[C-2-1] MUST fully implement the AutofillService and AutofillManager APIs and honor the android.settings.REQUEST_SET_AUTOFILL_SERVICE intent to show a default app settings menu to enable and disable autofill and change the default autofill service for the user.

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.

3.8.11. Screen savers (previously Dreams)

Android includes support for interactivescreensavers, previously referred to as Dreams. Screen savers allow 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 screen savers, but other types of device implementations SHOULD include support for screen savers and provide a settings option for users toconfigure screen savers in response to the android.settings.DREAM_SETTINGS intent.

3.8.12. Location

If device implementations include a hardware sensor (e.g. GPS) that is capable of providing the location coordinates:

[C-1-1] location modes MUST be displayed in the Location menu within Settings.

3.8.13. Unicode and Font

Android includes support for the emoji characters defined in Unicode 10.0.

If device implementations include a screen or video output, they:

[C-1-1] MUST be capable of rendering these emoji characters in color glyph.

[C-1-2] MUST include support for: Roboto 2 font with different weights—sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light for the languages available on the device. Full Unicode 7.0 coverage of Latin, Greek, and Cyrillic, including the Latin Extended A, B, C, and D ranges, and all glyphs in the currency symbols block of Unicode 7.0.

SHOULD support the skin tone and diverse family emojis as specified in the Unicode Technical Report #51.

If device implementations include an IME, they:

SHOULD provide an input method to the user for these emoji characters.

3.8.14. Multi-windows

If device implementations have the capability to display multiple activities at the same time, they:

[C-1-1] MUST implement such multi-window mode(s) in accordance with the application behaviors and APIs described in the Android SDK multi-window mode support documentation and meet the following requirements:

[C-1-2] Applications can indicate whether they are capable of operating in multi-window mode in the AndroidManifest.xml file, either explicitly via setting the android:resizeableActivity attribute to true or implicitly by having the targetSdkVersion > 24. Apps that explicitly set this attribute to false in their manifest MUST NOT be launched in multi-window mode. Older apps with targetSdkVersion < 24 that did not set this android:resizeableActivity attribute MAY be launched in multi-window mode, but the system MUST provide warning that the app may not work as expected in multi-window mode.

file, either explicitly via setting the attribute to or implicitly by having the targetSdkVersion > 24. Apps that explicitly set this attribute to in their manifest MUST NOT be launched in multi-window mode. Older apps with targetSdkVersion < 24 that did not set this attribute MAY be launched in multi-window mode, but the system MUST provide warning that the app may not work as expected in multi-window mode. [C-1-3] MUST NOT offer split-screen or freeform mode if the screen height < 440 dp and the screen width < 440 dp.

Device implementations with screen size xlarge SHOULD support freeform mode.

If device implementations support multi-window mode(s), and the split screen mode, they:

[C-2-1] MUST preload a resizeable launcher as the default.

[C-2-2] MUST crop the docked activity of a split-screen multi-window but SHOULD show some content of it, if the Launcher app is the focused window.

[C-2-3] MUST honor the declared AndroidManifestLayout_minWidth and AndroidManifestLayout_minHeight values of the third-party launcher application and not override these values in the course of showing some content of the docked activity.

If device implementations support multi-window mode(s) and Picture-in-Picture multi-window mode, they:

[C-3-1] MUST launch activities in picture-in-picture multi-window mode when the app is: * Targeting API level 26 or higher and declares android:supportsPictureInPicture * Targeting API level 25 or lower and declares both android:resizeableActivity and android:supportsPictureInPicture .

* Targeting API level 25 or lower and declares both and . [C-3-2] MUST expose the actions in their SystemUI as specified by the current PIP activity through the setActions() API.

API. [C-3-3] MUST support aspect ratios greater than or equal to 1:2.39 and less than or equal to 2.39:1, as specified by the PIP activity through the setAspectRatio() API.

API. [C-3-4] MUST use KeyEvent.KEYCODE_WINDOW to control the PIP window; if PIP mode is not implemented, the key MUST be available to the foreground activity.

to control the PIP window; if PIP mode is not implemented, the key MUST be available to the foreground activity. [C-3-5] MUST provide a user affordance to block an app from displaying in PIP mode; the AOSP implementation meets this requirement by having controls in the notification shade.

[C-3-6] MUST allocate minimum width and height of 108 dp for the PIP window and minimum width of 240 dp and height of 135 dp for the PIP window when the Configuration.uiMode is configured as UI_MODE_TYPE_TELEVISION

3.9. Device Administration

Android includes features that allow security-aware applications to perform device administration functions at the system level, such as enforcing password policies or performing remote wipe, through the Android Device Administration API].

If device implementations implement the full range of device administration policies defined in the Android SDK documentation, they:

[C-1-1] MUST declare android.software.device_admin .

. [C-1-2] MUST support device owner provisioning as described in section 3.9.1 and section 3.9.1.1.

[C-1-3] MUST declare the support of manged profiles via the android.software.managed_users feature flag, except for when the device is configured so that it would report itself as a low RAM device or so that it allocate internal (non-removable) storage as shared storage.

3.9.1 Device Provisioning

3.9.1.1 Device owner provisioning

If device implementations declare android.software.device_admin , they:

[C-1-1] MUST support enrolling a Device Policy Client (DPC) as a Device Owner app as described below: When the device implementation has no user data is configured yet, it: [C-1-3] MUST report true for DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) . [C-1-4] MUST enroll the DPC application as the Device Owner app in response to the intent action android.app.action.PROVISION_MANAGED_DEVICE . [C-1-5] MUST enroll the DPC application as the Device Owner app if the device declares Near-Field Communications (NFC) support via the feature flag android.hardware.nfc and receives an NFC message containing a record with MIME type MIME_TYPE_PROVISIONING_NFC . When the device implementation has user data, it: [C-1-6] MUST report false for the DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) . [C-1-7] MUST not enroll any DPC application as the Device Owner App any more.

[C-1-2] MUST NOT set an application (including pre-installed app) as the Device Owner app without explicit consent or action from the user or the administrator of the device.

If device implementations declare android.software.device_admin , but also include a proprietary Device Owner management solution and provide a mechanism to promote an application configured in their solution as a "Device Owner equivalent" to the standard "Device Owner" as recognized by the standard Android DevicePolicyManager APIs, they:

[C-2-1] MUST have a process in place to verify that the specific app being promoted belongs to a legitimate enterprise device management solution and it has been already configured in the proprietary solution to have the rights equivalent as a "Device Owner".

[C-2-2] MUST show the same AOSP Device Owner consent disclosure as the flow initiated by android.app.action.PROVISION_MANAGED_DEVICE prior to enrolling the DPC application as "Device Owner".

prior to enrolling the DPC application as "Device Owner". MAY have user data on the device prior to enrolling the DPC application as "Device Owner".

3.9.1.2 Managed profile provisioning

If device implementations declare android.software.managed_users , they:

[C-1-1] MUST implement the APIs allowing a Device Policy Controller (DPC) application to become the owner of a new Managed Profile.

[C-1-2] The managed profile provisioning process (the flow initiated by android.app.action.PROVISION_MANAGED_PROFILE) users experience MUST align with the AOSP implementation.

[C-1-3] MUST provide the following user affordances within the Settings to indicate to the user when a particular system function has been disabled by the Device Policy Controller (DPC): A consistent icon or other user affordance (for example the upstream AOSP info icon) to represent when a particular setting is restricted by a Device Admin. A short explanation message, as provided by the Device Admin via the setShortSupportMessage . The DPC application’s icon.



3.9.2 Managed Profile Support

If device implementations declare android.software.managed_users , they:

[C-1-1] MUST support managed profiles via the android.app.admin.DevicePolicyManager APIs.

APIs. [C-1-2] MUST allow one and only one managed profile to be created.

[C-1-3] MUST use an icon badge (similar to the AOSP upstream work badge) to represent the managed applications and widgets and other badged UI elements like Recents & Notifications.

[C-1-4] MUST display a notification icon (similar to the AOSP upstream work badge) to indicate when user is within a managed profile application.

[C-1-5] MUST display a toast indicating that the user is in the managed profile if and when the device wakes up (ACTION_USER_PRESENT) and the foreground application is within the managed profile.

[C-1-6] Where a managed profile exists, MUST show a visual affordance in the Intent 'Chooser' to allow the user to forward the intent from the managed profile to the primary user or vice versa, if enabled by the Device Policy Controller.

[C-1-7] Where a managed profile exists, MUST expose the following user affordances for both the primary user and the managed profile: Separate accounting for battery, location, mobile data and storage usage for the primary user and managed profile. Independent management of VPN Applications installed within the primary user or managed profile. Independent management of applications installed within the primary user or managed profile. Independent management of accounts within the primary user or managed profile.

[C-1-8] MUST ensure the preinstalled dialer, contacts and messaging applications can search for and look up caller information from the managed profile (if one exists) alongside those from the primary profile, if the Device Policy Controller permits it.

[C-1-9] MUST ensure that it satisfies all the security requirements applicable for a device with multiple users enabled (seesection 9.5), even though the managed profile is not counted as another user in addition to the primary user.

[C-1-10] MUST support the ability to specify a separate lock screen meeting the following requirements to grant access to apps running in a managed profile. Device implementations MUST honor the DevicePolicyManager.ACTION_SET_NEW_PASSWORD intent and show an interface to configure a separate lock screen credential for the managed profile. The lock screen credentials of the managed profile MUST use the same credential storage and management mechanisms as the parent profile, as documented on the Android Open Source Project Site The DPC password policies MUST apply to only the managed profile's lock screen credentials unless called upon the DevicePolicyManager instance returned by getParentProfileInstance.

When contacts from the managed profile are displayed in the preinstalled call log, in-call UI, in-progress and missed-call notifications, contacts and messaging apps they SHOULD be badged with the same badge used to indicate managed profile applications.

3.10. Accessibility

Android provides an accessibility layer that helps users with disabilities to navigate their devices more easily. In addition, Android provides platform APIs that enable accessibility service implementations to receive callbacks for user and system events and generate alternate feedback mechanisms, such as text-to-speech, haptic feedback, and trackball/d-pad navigation.

If device implementations support third-party accessibility services, they:

[C-1-1] MUST provide an implementation of the Android accessibility framework as described in th