Android 8.0 Compatibility Definition

1 Compatibility DefinitionAndroid updated: May 1, 2018 Copyright 2017, Google Inc. All rights Document Requirements by Device Requirement Requirement ID in Section 22. Device Device Handheld Performance and Security Television Performance and Watch Automotive Performance and Security Tablet Hardware3. Managed API Android Soft API Build Intent Core Application Intent Intent Broadcast Default App Activities on secondary Native API Application Binary 32-bit ARM Native Code Web WebView Browser API Behavioral API Runtime User Interface Launcher (Home Screen) Presentation of Notification Listener DND (Do not Disturb) Alerts and Live Activity Input Lock Screen Media Screen savers (previously Dreams) LocationTable of ContentsPage 2 of Unicode and Device Device Device owner Managed profile Managed Profile TV Input TV Electronic Program TV input app Time TV Quick Media Instant Companion Device Pairing4.

2 Application Packaging Compatibility5. Multimedia Media Audio Audio Audio Codecs Image Image Image Codecs Video Video Codecs Video Video (HEVC) Audio Raw Audio Capture for Voice Capture for Rerouting of Audio Raw Audio Audio Audio Output Audio Network Secure Musical Instrument Digital Interface(MIDI) Professional Capture for Unprocessed6. Developer Tools and Developer Developer Options7. Hardware Display and Screen Screen Screen Aspect Screen Display MetricsPage 3 of Screen 2D and 3D Graphics OpenGL 2D Graphics Wide-gamut Legacy Application Screen Secondary Input Non-touch Navigation Touchscreen Fake Touch Game Controller Button Remote Proximity High Fidelity Fingerprint Android Automotive-only Current Day Night Driving Wheel Pose Data Number Blocking IEEE (Wi-Fi)

3 Wi-Fi Wi-Fi Tunneled Direct Link Wi-Fi Wi-Fi Near-Field Minimum Network Sync Data Rear-Facing Front-Facing External Camera API Camera Memory and Minimum Memory and Application Shared Adoptable USB peripheral USB host Audio Analog Audio Virtual RealityPage 4 of Virtual Reality Virtual Reality High Performance8. Performance and User Experience File I/O Access Power-Saving Power Consumption Consistent Performance9. Security Model UID and Process Filesystem Alternate Execution Multi-User Premium SMS Kernel Security Usage Network Data Storage Direct File Based Full Disk Device Keys and Secure Lock Data Safe Boot Automotive Vehicle SystemIsolation10. Software Compatibility Compatibility Test CTS Verifier11.

4 Updatable Software12. Document Changelog Viewing Tips13. Contact UsPage 5 of 1181. IntroductionThis document enumerates the requirements that must be met in order for devices to be compatiblewith Android 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 organizationdeveloping a hardware/software solution running Android A device implementation or implementation is the hardware/software solution so be considered compatible with Android , device implementations MUST meet the requirementspresented in this Compatibility Definition , including any documents incorporated via this Definition or the software tests described in section 10 is silent, ambiguous, orincomplete, it is the responsibility of the device implementer to ensure Compatibility with this reason, the Android Open Source Project is both the reference and preferred implementationof Android .

5 Device implementers are STRONGLY RECOMMENDED to base their implementations tothe greatest extent possible on the upstream source code available from the Android Open SourceProject. While some components can hypothetically be replaced with alternate implementations, it isSTRONGLY RECOMMENDED to not follow this practice, as passing the software tests will becomesubstantially more difficult. It is the implementer s responsibility to ensure full behavioralcompatibility with the standard Android implementation, including and beyond the Compatibility TestSuite. Finally, note that certain component substitutions and modifications are explicitly forbidden bythis of the resources linked to in this document are derived directly or indirectly from the AndroidSDK and will be functionally identical to the information in that SDK s documentation.

6 In any caseswhere this Compatibility Definition or the Compatibility Test Suite disagrees with the SDKdocumentation, the SDK documentation is considered authoritative. Any technical details provided inthe linked resources throughout this document are considered by inclusion to be part of thisCompatibility Document Requirements by Device TypeSection 2 contains all of the requirements that apply to a specific device type. Each subsection ofSection 2 is dedicated to a specific device the other requirements, that universally apply to any Android device implementations, are listed inthe sections after Section 2 . These requirements are referenced as "Core Requirements" in Requirement IDRequirement ID is assigned for MUST ID is assigned for MUST requirements RECOMMENDED requirements are marked as [SR] but ID is not ID consists of : Device Type ID - Condition ID - Requirement ID ( C-0-1).

7 Each ID is defined as below:Device Type ID (see more on 2. Device TypesC: Core (Requirements that are applied to any Android devicePage 6 of 118implementations)H: Android Handheld deviceT: Android Television deviceA: Android Automotive implementationTab: Android Tablet implementationCondition IDWhen the requirement is unconditional, this ID is set as the requirement is conditional, 1 is assinged for the 1st condition andthe number increments by 1 within the same section and the same IDThis ID starts from 1 and increments by 1 within the same section and thesame Requirement ID in Section 2 The Requirement ID in Section 2 starts with the corresponding section ID that is followed by theRequirement ID described ID in Section 2 consists of : Section ID / Device Type ID - Condition ID - RequirementID ( ).)

8 2. Device TypesWhile the Android Open Source Project provides a software stack that can be used for a variety ofdevice types and form factors, there are a few device types that have a relatively better establishedapplication distribution section describes those device types, and additional requirements and recommendationsapplicable for each device Android device implementations that do not fit into any of the described device types MUST stillmeet all requirements in the other sections of this Compatibility Device ConfigurationsFor the major differences in hardware configuration by device type, see the device-specificrequirements that follow in this Handheld RequirementsAn Android Handheld device refers to an Android device implementation that is typically used byholding it in the hand.

9 Such as an mp3 player, phone, or device implementations are classified as a Handheld if they meet all the following criteria:Have a power source that provides mobility, such as a a physical diagonal screen size in the range of to 8 additional requirements in the rest of this section are specific to Android Handheld : Requirements that do not apply to Android Tablet devices are marked with an *. HardwarePage 7 of 118 Handheld device implementations:[ . ] MUST have a screen at least inches in physical diagonal size.[ . ] Are STRONGLY RECOMMENDED to provide users an affordance tochange the display size.(Screen Density)[ .5/H-0-1] MUST include support for legacy application Compatibility mode asimplemented by the upstream Android open source code. That is, device implementationsMUST NOT alter the triggers or thresholds at which Compatibility mode is activated, andMUST NOT alter the behavior of the Compatibility mode itself.

10 [ .1/H-0-1] MUST include support for third-party Input Method Editor (IME)applications.[ .3/H-0-1] MUST provide the Home, Recents, and Back functions.[ .3/H-0-2] MUST send both the normal and long press event of the Back function (KEYCODE_BACK ) to the foreground application.[ .4/H-0-1] MUST support touchscreen input.[ .1/H-SR] Are STRONGLY RECOMMENDED to include a 3-axis Handheld device implementations include a 3-axis accelerometer, they:[ .1/H-1-1] MUST be able to report events up to a frequency of at least 100 Handheld device implementations include a gyroscope, they:[ .4/H-1-1] MUST be able to report events up to a frequency of at least 100 device implementations that can make a voice call and indicate any value other thanPHONE_TYPE_NONE in getPhoneType :[ .8/H] SHOULD include a proximity device implementations:[.]