Table of Contents

1. Introduction

2. Device Types

2.1 Device Configurations

3. Software

3.1. Managed API Compatibility

3.2. Soft API Compatibility

3.2.1. Permissions

3.2.2. Build Parameters

3.2.3. Intent Compatibility

3.2.3.1. Core Application Intents

3.2.3.2. Intent Overrides

3.2.3.3. Intent Namespaces

3.2.3.4. Broadcast Intents

3.2.3.5. Default App Settings

3.3. Native API Compatibility

3.3.1. Application Binary Interfaces

3.3.2. 32-bit ARM Native Code Compatibility

3.4. Web Compatibility

3.4.1. WebView Compatibility

3.4.2. Browser Compatibility

3.5. API Behavioral Compatibility

3.6. API Namespaces

3.7. Runtime Compatibility

3.8. User Interface Compatibility

3.8.1. Launcher (Home Screen)

3.8.2. Widgets

3.8.3. Notifications

3.8.4. Search

3.8.5. Toasts

3.8.6. Themes

3.8.7. Live Wallpapers

3.8.8. Activity Switching

3.8.9. Input Management

3.8.10. Lock Screen Media Control

3.8.11. Dreams

3.8.12. Location

3.8.13. Unicode and Font

3.9. Device Administration

3.9.1 Device Provisioning

3.9.1.1 Device Owner provisioning

3.9.1.2 Managed profile provisioning

3.9.2. Managed Profile Support

3.10. Accessibility

3.11. Text-to-Speech

3.12. TV Input Framework

3.12.1. TV App

3.12.1.1. Electronic Program Guide

3.12.1.2. Navigation

3.12.1.3. TV input app linking

4. Application Packaging Compatibility

5. Multimedia Compatibility

5.1. Media Codecs

5.1.1. Audio Codecs

5.1.2. Image Codecs

5.1.3. Video Codecs

5.2. Video Encoding

5.3. Video Decoding

5.4. Audio Recording

5.4.1. Raw Audio Capture

5.4.2. Capture for Voice Recognition

5.4.3. Capture for Rerouting of Playback

5.5. Audio Playback

5.5.1. Raw Audio Playback

5.5.2. Audio Effects

5.5.3. Audio Output Volume

5.6. Audio Latency

5.7. Network Protocols

5.8. Secure Media

5.9. Musical Instrument Digital Interface (MIDI)

5.10. Professional Audio

6. Developer Tools and Options Compatibility

6.1. Developer Tools

6.2. Developer Options

7. Hardware Compatibility

7.1. Display and Graphics

7.1.1. Screen Configuration

7.1.1.1. Screen Size

7.1.1.2. Screen Aspect Ratio

7.1.1.3. Screen Density

7.1.2. Display Metrics

7.1.3. Screen Orientation

7.1.4. 2D and 3D Graphics Acceleration

7.1.5. Legacy Application Compatibility Mode

7.1.6. Screen Technology

7.1.7. Secondary Displays

7.2. Input Devices

7.2.1. Keyboard

7.2.2. Non-touch Navigation

7.2.3. Navigation Keys

7.2.4. Touchscreen Input

7.2.5. Fake Touch Input

7.2.6. Game Controller Support

7.2.6.1. Button Mappings

7.2.7. Remote Control

7.3. Sensors

7.3.1. Accelerometer

7.3.2. Magnetometer

7.3.3. GPS

7.3.4. Gyroscope

7.3.5. Barometer

7.3.6. Thermometer

7.3.7. Photometer

7.3.8. Proximity Sensor

7.3.9. High Fidelity Sensors

7.3.10. Fingerprint Sensor

7.4. Data Connectivity

7.4.1. Telephony

7.4.2. IEEE 802.11 (Wi-Fi)

7.4.2.1. Wi-Fi Direct

7.4.2.2. Wi-Fi Tunneled Direct Link Setup

7.4.3. Bluetooth

7.4.4. Near-Field Communications

7.4.5. Minimum Network Capability

7.4.6. Sync Settings

7.5. Cameras

7.5.1. Rear-Facing Camera

7.5.2. Front-Facing Camera

7.5.3. External Camera

7.5.4. Camera API Behavior

7.5.5. Camera Orientation

7.6. Memory and Storage

7.6.1. Minimum Memory and Storage

7.6.2. Application Shared Storage

7.6.3. Adoptable Storage

7.7. USB

7.8. Audio

7.8.1. Microphone

7.8.2. Audio Output

7.8.2.1. Analog Audio Ports

7.8.3. Near-Ultrasound

8. Performance Compatibility

8.1. User Experience Consistency

8.2. File I/O Access Performance

8.3. Power-Saving Modes

8.4. Power Consumption Accounting

9. Security Model Compatibility

9.1. Permissions

9.2. UID and Process Isolation

9.3. Filesystem Permissions

9.4. Alternate Execution Environments

9.5. Multi-User Support

9.6. Premium SMS Warning

9.7. Kernel Security Features

9.8. Privacy

9.9. Full-Disk Encryption

9.10. Verified Boot

9.11. Keys and Credentials

9.12. Data Deletion

10. Software Compatibility Testing

10.1. Compatibility Test Suite

10.2. CTS Verifier

11. Updatable Software

12. Document Changelog

13. Contact Us

14. Resources

1. Introduction

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

The use of “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” is per the IETF standard defined in RFC2119 [Resources, 1].

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

To be considered compatible with Android ANDROID_VERSION, device implementations MUST meet the requirements presented in this Compatibility Definition, including any documents incorporated via reference.

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

For this reason, the Android Open Source Project [Resources, 2] is both the reference and preferred implementation of Android. Device implementers are STRONGLY 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 listed in section 14 are derived directly or indirectly from the Android SDK, and will be functionally identical to the information in that SDK’s documentation. For any case where this Compatibility Definition or the Compatibility Test Suite disagrees with the SDK documentation, the SDK documentation is considered authoritative. Any technical details provided in the references included in section 14 are considered by inclusion to be part of this Compatibility Definition.

2. Device Types

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

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

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

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

Android Automotive implementation refers to a vehicle head unit running Android as an operating system for part or all of the system and/or infotainment functionality. Android Automotive implementations: