Android Compatibility Definition Document changelog

Android 15

May 2, 2025

5. Multimedia Compatibility

  • 5.6. Audio Latency:

    See revision

    The following table defines the requirements for RTL for Handheld device implementations as defined in 2.2.1 that declare android.hardware.audio.output and android.hardware.microphone.

    Device and Declarations RTL (ms) MAD (ms) Loopback Paths
    Handheld 250 30 speaker/mic, analog 3.5mm (if supported), USB (if supported)
    >= MPC_T (14) MPC_T (13) 80 15 at least one path
    FEATURE_AUDIO_LOW_LATENCY 50 10 at least one path
    FEATURE_AUDIO_PRO 25 5 at least one path
    FEATURE_AUDIO_PRO 20 5 analog (if supported)
    FEATURE_AUDIO_PRO 25 5 USB (if analog not supported)

    The following table defines the requirements for TTL for Handheld device implementations as defined in 2.2.1 that declare android.hardware.audio.output and android.hardware.microphone.

    Device and Declarations TTL (ms)
    Handheld 250
    >= MPC_T (14) MPC_T (13) 80
    MPC_S (13) MPC_S (12) 100
    FEATURE_AUDIO_PRO 80

9. Security Model Compatibility

  • 9.9.3. Encryption Methods:

    See revision

    • [C-1-2] MUST only allow access to Credential Encrypted (CE) storage after the user has unlocked the device by supplying their credentials (eg. password, pin, pattern or fingerprint) and the ACTION_USER_UNLOCKED message is broadcasted.

    • [C-1-2] MUST NOT allow access to Credential Encrypted (CE) storage until both:

      • The user unlocks the device using a primary authentication method (such as password, pattern, or PIN).
      • The ACTION_USER_UNLOCKED message is broadcasted.

December 2, 2024

2. Device Types

  • 2.2.7.1. Hardware:

    See revision

    • [5.1/H-1-2] MUST support 6 instances of 8-bit (SDR) hardware video decoder sessions (AVC, HEVC, VP9, AV1, or later) in any codec combination running concurrently with 3 sessions at 1080p resolution@30 fps and 3 sessions at 4K resolution@30fps. For all sessions, there MUST NOT be more than 1 frame dropped per second. AV1 codecs are only required to support 1080p resolution, but are still required to support 6 instances at 1080p30fps.

    • [5.1/H-1-4] MUST support 6 instances of 8-bit (SDR) hardware video encoder sessions (AVC, HEVC, VP9, AV1, or later) in any codec combination running concurrently with 4 sessions at 1080p resolution@30 fps and 2 sessions at 4K resolution@30fps. For all sessions, there MUST NOT be more than 1 frame dropped per second. AV1 codecs are only required to support 1080p resolution, but are still required to support 6 instances at 1080p30fps.

    • [5.1/H-1-6] MUST support 6 instances of 8-bit (SDR) hardware video decoder and hardware video encoder sessions (AVC, HEVC, VP9, AV1, or later) in any codec combination running concurrently with 3 sessions at 4K@30fps resolution, out of which at most 2 are encoder sessions and 3 sessions at 1080p resolution. For all sessions, there MUST NOT be more than 1 frame dropped per second. AV1 codecs are only required to support 1080p resolution, but are still required to support 6 instances at 1080p30fps.

    • [5.1/H-1-19] MUST support 3 instances of 10-bit (HDR) hardware video decoder and hardware video encoder sessions (AVC, HEVC, VP9, AV1, or later) in any codec combination running concurrently at 4K@30fps resolution out of which at most 1 is an encoder session, which could be configured in RGBA_1010102 input format through a GL surface. For all sessions, there MUST NOT be more than 1 frame dropped per second. HDR metadata generation by the encoder is not required if encoding from the GL surface. AV1 codec sessions are only required to support 1080p resolution even when this requirement calls for 4K.

    • [5.1/H-1-9] MUST support 2 instances of secure hardware video decoder sessions (AVC, HEVC, VP9, AV1, or later) in any codec combination running concurrently at 1080p resolution@30 fps for both 8-bit (SDR) and 10-bit HDR content. For all sessions, there MUST NOT be more than 1 frame dropped per second.

    • [5.1/H-1-10] MUST support 3 instances of non-secure hardware video decoder sessions together with 1 instance of secure hardware video decoder session (4 instances total) (AVC, HEVC, VP9, AV1, or later) in any codec combination running concurrently with 3 sessions at 4K resolution@30fps which includes one secure decoder session and 1 nn-secure session at 1080p resolution@30fps where at most 2 sessions can be in 10-bit HDR. For all sessions, there MUST NOT be more than 1 frame dropped per second. AV1 codec sessions are only required to support 1080p resolution even when this requirement calls for 4K.

  • 2.5.1. Hardware:

    See revision

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

7. Hardware Compatibility

  • 7.4.2. IEEE 802.11 (Wi-Fi):

    See revision

    • [C-1-4] MUST support mDNS and MUST NOT filter mDNS packets (224.0.0.251 or ff02::fb) at any time of operation, including when the screen is not in an active state, unless the multicast lock is not held and the packets are filtered by APF. The packets are not required to satisfy any mDNS operations currently requested by applications through the NsdManager APIs. However, the device MAY filter mDNS packets if doing so is necessary to stay within power consumption ranges required by regulatory requirements applicable to the target market.

9. Security Model Compatibility

September 3, 2024

2. Device Types

  • 2.2.1. Hardware:

    See revision

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

    Start new requirements for 15

    Handheld device implementations that include support for Bluetooth LE:

    • [7.4.3/H-SR-1] Are STRONGLY RECOMMENDED to support Bluetooth LE Data Packet Length Extension.

    End new requirements

    See revision

    If handheld device implementations include a USB port supporting with a controller operating in peripheral mode, they:

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

    See revision

    If For Handheld device implementations that declare android.hardware.audio.output and android.hardware.microphone, they: see the RTL and TTL requirements in section 5.6.

    • [5.6/H-1-1] MUST have a Mean Continuous Round-Trip latency of 300 milliseconds or less over 5 measurements, with a Mean Absolute Deviation less than 30ms, over the following data paths: "speaker to microphone", 3.5 mm loopback adapter (if supported), USB loopback (if supported).

    • [5.6/H-1-2] MUST have an average Tap-to-tone latency of 300 milliseconds or less over at least 5 measurements over the speaker to microphone data path.

  • 2.2.5. Security Model:

    See revision

    Device implementations MUST declare support for android.software.credentials and:

    • [9/H-0-2] MUST honor the android.settings.CREDENTIAL_PROVIDER intent to allow selection of a preferred provider for the Credential Manager. This provider will be enabled for Autofill and will also be the default location to save new credentials entered through the Credential Manager.

    • [9/H-0-3] MUST support at least 2 concurrent credential providers and provide a user affordance in the Setting app to enable or disable providers.

    End new requirements

    See revision

    • [9.11/H-0-5] MUST support key attestation where the attestation signing key is protected by secure hardware and signing is performed in secure hardware. The attestation signing keys MUST be shared across large enough number of devices to prevent the keys prevented from being used as permanent device identifiers. One way of meeting this requirement is to share the same attestation key unless at least 100,000 units of a given SKU are produced. If more than 100,000 units of an SKU are produced, a different key MAY be used for each 100,000 units.

    See revision

    Restricted settings

    Restricted Settings provides a user with visible warnings and solicits user confirmation in order to grant permissions for each application that is either:

    • Being installed after being downloaded through an application (for example, a messaging application or a browser) other than an "app store" application identified by PackageManager as PACKAGE_DOWNLOADED_FILE.
    • Being installed from a local file (for example, the application was sideloaded) identified by PackageManager as PACKAGE_SOURCE_LOCAL_FILE.

    For any of the Enforced Permissions and their associated identifiers listed below:

    • Alarms and reminders: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
    • All file access: AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
    • Display over other apps: AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
    • Install unknown apps: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
    • Manage media: AppOpsManager.OPSTR_MANAGE_MEDIA
    • Modify system settings: AppOpsManager.OPSTR_WRITE_SETTINGS
    • Picture-in-picture: AppOpsManager.OPSTR_PICTURE_IN_PICTURE
    • Turn screen on: AppOpsManager.OPSTR_TURN_SCREEN_ON
    • Full-screen notifications: AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
    • Wi-Fi control: AppOpsManager.OPSTR_CHANGE_WIFI_STATE
    • Accessibility: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
    • Notification listener: AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
    • Usage access: AppOpsManager.OPSTR_GET_USAGE_STATS
    • Device admin: Manifest.permission.BIND_DEVICE_ADMIN
    • Do not disturb: Manifest.permission.MANAGE_NOTIFICATIONS

    Such applications are labeled "Covered Applications" for the requirements listed in this section.

    Device implementations:

    • [9.8/H-0-1] MUST implement Restricted Settings as outlined above for the following:

      • Special permissions
        • Accessibility (AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE)
        • Notification listener (AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS)
        • Device admin apps (Manifest.permission.BIND_DEVICE_ADMIN)
        • Display over other apps (AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW)
        • Usage access (AppOpsManager.OPSTR_GET_USAGE_STATS)
      • Roles (Default apps)
        • Dialer (RoleManager.ROLE_DIALER)
        • SMS (RoleManager.ROLE_SMS)
      • Runtime permissions
        • SMS runtime (Manifest.permission_group.SMS)

    • [9.8/H-0-2] MUST enable Restricted Settings as the default and are STRONGLY RECOMMENDED to not have any user affordance which allows a user to disable Restricted Settings for all applications.

    • [9.8/H-0-3] MUST ensure user confirmation is obtained for each Covered Application before any of the Enforced Permissions can be granted.

    • [9.8/H-0-4] MUST only allow user confirmation to enable restricted settings to be obtained from the Covered Application's AppInfo page, using the EnhancedConfirmationManager API.

    • [9.8/H-0-5] Are STRONGLY RECOMMENDED to integrate with and call EnhancedConfirmationManager for all special permissions, to dynamically determine if they are a restricted setting.

      • Alarms and reminders: AppOpsManager.OPSTR_SCHEDULE_EXACT_ALARM
      • All file access: AppOpsManager.OPSTR_MANAGE_EXTERNAL_STORAGE
      • Display over other apps: AppOpsManager.OPSTR_SYSTEM_ALERT_WINDOW
      • Install unknown apps: AppOpsManager.OPSTR_REQUEST_INSTALL_PACKAGES
      • Manage media: AppOpsManager.OPSTR_MANAGE_MEDIA
      • Modify system settings: AppOpsManager.OPSTR_WRITE_SETTINGS
      • Picture-in-picture: AppOpsManager.OPSTR_PICTURE_IN_PICTURE
      • Turn screen on: AppOpsManager.OPSTR_TURN_SCREEN_ON
      • Full-screen notifications: AppOpsManager.OPSTR_USE_FULL_SCREEN_INTENT
      • Wi-Fi control: AppOpsManager.OPSTR_CHANGE_WIFI_STATE
      • Accessibility: AppOpsManager.OPSTR_BIND_ACCESSIBILITY_SERVICE
      • Notification listener: AppOpsManager.OPSTR_ACCESS_NOTIFICATIONS
      • Usage access: AppOpsManager.OPSTR_GET_USAGE_STATS
      • Device admin: Manifest.permission.BIND_DEVICE_ADMIN
      • Do not disturb: Manifest.permission.MANAGE_NOTIFICATIONS

    End new requirements

    See revision

    Verified Boot is a feature that ensures the integrity of the device software. If device implementations support the feature, they:

    • [9.10/H-1-1] MUST verify all read-only partitions mounted during the Android boot sequence, and the VBMeta digest must include all these verified partitions in its calculation.

    End new requirements

  • 2.2.6. Developer Tools and Options Compatibility:

    See revision

    Handheld device implementations (* Not applicable for Tablet):

    • Perfetto
      • [6.1/H-0-2]* MUST expose a /system/bin/perfetto binary to the shell user which cmdline complies with the perfetto documentation.
      • [6.1/H-0-3]* The perfetto binary MUST accept as input a protobuf config that complies with the schema defined in the perfetto documentation.
      • [6.1/H-0-4]* The perfetto binary MUST write as output a protobuf trace that complies with the schema defined in the perfetto documentation.
      • [6.1/H-0-5]* MUST provide, through the perfetto binary, at least the data sources described in the perfetto documentation.
      • [6.1/H-0-6]* The perfetto traced daemon MUST be enabled by default (system property persist.traced.enable).

  • 2.2.7.1. Media:

    See revision

    If Handheld device implementations return android.os.Build.VERSION_CODES.V for android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, they:

    See revision

    • [5.1/H-1-2] MUST support 6 instances of 8-bit (SDR) hardware video decoder sessions (AVC, HEVC, VP9, AV1, or later) in any codec combination running concurrently with 3 sessions at 1080p resolution@30 fps and 3 sessions at 4k resolution@30fps, unless AV1. For all sessions, there MUST NOT be more than 1 frame dropped per second. AV1 codecs are only required to support 1080p resolution, but are still required to support 6 instances at 1080p30fps.

    See revision

    • [5.1/H-1-4] MUST support 6 instances of 8-bit (SDR) hardware video encoder sessions (AVC, HEVC, VP9, AV1, or later) in any codec combination running concurrently with 4 sessions at 1080p resolution@30 fps and 2 sessions at 4k resolution@30fps, unless AV1. For all sessions, there MUST NOT be more than 1 frame dropped per second. AV1 codecs are only required to support 1080p resolution, but are still required to support 6 instances at 1080p30fps.

    See revision

    • [5.1/H-1-6] MUST support 6 instances of 8-bit (SDR) hardware video decoder and hardware video encoder sessions (AVC, HEVC, VP9, AV1, or later) in any codec combination running concurrently with 3 sessions at 4K@30fps resolution (unless AV1), out of which at most 2 are encoder sessions and 3 sessions at 1080p resolution. For all sessions, there MUST NOT be more than 1 frame dropped per second. AV1 codecs are only required to support 1080p resolution, but are still required to support 6 instances at 1080p30fps.

    See revision

    • [5.1/H-1-19] MUST support 3 instances of 10-bit (HDR) hardware video decoder and hardware video encoder sessions (AVC, HEVC, VP9, AV1, or later) in any codec combination running concurrently at 4K@30fps resolution (unless AV1) out of which at most 1 is an encoder session, which could be configured in RGBA_1010102 input format through a GL surface. For all sessions, there MUST NOT be more than 1 frame dropped per second. HDR metadata generation by the encoder is not required if encoding from the GL surface. AV1 codec sessions are only required to support 1080p resolution even when this requirement calls for 4K.

    See revision

    • [5.1/H-1-9] MUST support 2 instances of secure hardware video decoder sessions (AVC, HEVC, VP9, AV1, or later) in any codec combination running concurrently at 4k resolution@30 fps (unless AV1) for both 8-bit (SDR) and 10-bit HDR content. For all sessions, there MUST NOT be more than 1 frame dropped per second. AV1 codec sessions are only required to support 1080p resolution even when this requirement calls for 4K.

    See revision

    • [5.1/H-1-10] MUST support 3 instances of non-secure hardware video decoder sessions together with 1 instance of secure hardware video decoder session (4 instances total) (AVC, HEVC, VP9, AV1, or later) in any codec combination running concurrently with 3 sessions at 4K resolution@30fps (unless AV1) which includes one secure decoder session and 1 nn-secure session at 1080p resolution@30fps where at most 2 sessions can be in 10-bit HDR. For all sessions, there MUST NOT be more than 1 frame dropped per second. AV1 codec sessions are only required to support 1080p resolution even when this requirement calls for 4K.

    See revision

    • [5.1/H-1-14] MUST support AV1 hardware decoder Main 10, Level 4.1 and film grain with film grain effect over GPU composition.

    See revision

    • [5.1/H-1-21] MUST support FEATURE_DynamicColorAspect for all hardware video decoders (AVC, HEVC, VP9, AV1, or later). Note: This means applications can update the color aspects of the video content during the decoding session. Decoders that support 10-bit and 8-bit content MUST support dynamically switching between 8- and 10-bit content in Surface mode. Decoders that support HDR transfer function MUST support dynamically switching between SDR and HDR content.

    End new requirements

    See revision

    • [5.1/H-1-22] MUST support encoding, decoding, GPU-editing and displaying video content in portrait aspect ratio regardless of the rotation metadata for the largest Camera supported resolution or 4K whichever is less. Note: this includes HDR profiles if codec supports HDR. AV1 codecs are only required to support 1080p resolution. This requirement is only for hardware codecs, GPU and the DPU.

    End new requirements

    See revision

    • [5.6/H-1-4] MUST support >= 4 channel USB audio devices. (This is used by DJ controllers for previewing songs.)

    See revision

    • [5.1/H-1-20] MUST support the Feature_HdrEditing feature for all hardware AV1 and HEVC encoders present on the device at 4K resolution or the largest Camera-supported resolution, whichever is less.

    End new requirements

    See revision

    If Handheld device implementations return android.os.Build.VERSION_CODES.V for android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS and they include support for a hardware AVC or HEVC encoder, they:

  • 2.2.7.2. Camera:

    See revision

    If Handheld device implementations return android.os.Build.VERSION_CODES.V for android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, they:

    See revision

    • [7.5/H-1-1] MUST have a primary rear facing camera with a resolution of at least 12 megapixels supporting video capture at 4k@30fps, 1080p@60fps, and 720p@60fps. The primary rear-facing camera is the rear-facing camera with the lowest camera ID.

    See revision

    • [7.5/H-1-18] MUST support JPEG_R for the primary rear and primary front cameras.
    • [7.5/H-1-19] MUST support CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION for 1080p HLG10 preview with maximum-size 16:9 aspect ratio JPEG, and for 720p HLG10 preview with maximum-size 16:9 aspect ratio JPEG stream combinations for the primary rear camera.
    • [7.5/H-1-20] MUST by default output JPEG_R for the primary rear and primary front cameras in the native camera app.

    End new requirements

  • 2.2.7.3. Hardware:

    See revision

    If Handheld device implementations return android.os.Build.VERSION_CODES.V for android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, they:

    See revision

    • [7.1.1.3/H-2-1] MUST have screen density of at least 400 dpi if the device's screen width is < 600 dp.

    See revision

  • 2.2.7.4. Performance:

    See revision

    If Handheld device implementations return android.os.Build.VERSION_CODES.V for android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, they:

  • 2.2.7.5. Graphics:

    See revision

    If Handheld device implementations return android.os.Build.VERSION_CODES.V for android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, they:

    End new requirements

  • 2.3.3. Software:

    See revision

    Television device implementations:

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

    See revision

    The Android Television Input Framework (TIF) simplifies the delivery of live content to Android Television devices. TIF provides a standard API to create input modules that control Android Television devices.

    Television device implementations:

    • [3/T-0-2] MUST declare the platform feature android.software.live_tv.
    • [3/T-0-3] MUST support all TIF APIs such that an application which uses these APIs and the third-party TIF-based inputs service can be installed and used on the device.

    The Android Television Tuner Framework (TF) unifies the handling of live content from Tuner with streaming content from IP on Android Television devices. The Turner Framework provides a standard API to create input services that use Android Television Tuner.

    If device implementations support Tuner, they:

    • [3/T-1-1] MUST support all Tuner Framework APIs such that an application which uses these APIs can be installed and used on the device.

    End new requirements

  • 2.3.5. Security Model:

    See revision

    • [9.11/T-0-4] MUST support key attestation where the attestation signing key is protected by secure hardware and signing is performed in secure hardware. The attestation signing keys MUST be shared across large enough number of devices to prevent the keys prevented from being used as permanent device identifiers. One way of meeting this requirement is to share the same attestation key unless at least 100,000 units of a given SKU are produced. If more than 100,000 units of an SKU are produced, a different key MAY be used for each 100,000 units.

  • 2.3.6. Developer Tools and Options Compatibility:

    See revision

    • [6.1/T-0-5] The perfetto traced daemon MUST be enabled by default (system property persist.traced.enable).

    End new requirements

  • 2.5.1. Hardware:

    See revision

    If Automotive device implementations support Concurrent Multi-user (where multiple Android users can interact with the device concurrently, each using their own display when config_multiuserVisibleBackgroundUsers is enabled), they:

    • [7.1.1.1/A-1-1] MUST have a separate screen of at least 6 inches in physical diagonal size for each occupant zone for the main display. This should be tagged as CarOccupantZoneManager.DISPLAY_TYPE_MAIN for each occupant zone.
    • [7.1.1.1/A-1-2] MUST have a screen size layout of at least 750 dp x 480 dp for each main display.

    End new requirements

    See revision

    End new requirements

    See revision

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

    See revision

    If Automotive device implementations support Concurrent Multi-user (where multiple Android users can interact with the device concurrently, each using their own display when config_multiuserVisibleBackgroundUsers is enabled), they:

    • [7.3/A-1-1] MUST set the NIGHT_MODE flag value consistently with the dashboard day/night mode across all displays, including the rear seat displays.

    End new requirements

    See revision

    • [7.4.3/A-SR-1] Are STRONGLY RECOMMENDED to support Message Access Profile (MAP) if the device has the driver occupant zone.

    See revision

    If Automotive device implementations support Concurrent Multi-user (where multiple Android users can interact with the device concurrently, each using their own display when config_multiuserVisibleBackgroundUsers is enabled), they:

    • [7.4.3/A-1-1] MUST be independent and NOT interfere with other users' BT experience.

    End new requirements

    See revision

    If Automotive device implementations support Concurrent Multi-user (where multiple Android users can interact with the device concurrently, each using their own display when config_multiuserVisibleBackgroundUsers is enabled), they:

    • [7.6.1/A-1-1] MUST have, on a single AAOS instance, at least 4 GB for each concurrent Android user of non-volatile storage available for application private data (/data partition).

    End new requirements

    See revision

    • [7.6.1/A-2-1] The memory available to the kernel and userspace MUST be at least 816 MB per main display if any of the following densities are used:

      • 280 dpi 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 944 MB per main display 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 1280 MB per main display if any of the following densities are used:

      • 400 dpi 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 1824 MB per main display if any of the following densities are used:

      • 560 dpi or higher on small/normal screens
      • 400 dpi or higher on large screens
      • xhdpi or higher on extra large screens

    See revision

    If Automotive device implementations support Concurrent Multi-user (where multiple Android users can interact with the device concurrently, each using their own display when config_multiuserVisibleBackgroundUsers is enabled), they:

    • [7.8.2/A-1-1] MUST have an audio output device for each main display for concurrent multiple user systems.
    • [7.8.2/A-1-2] MUST have a Driver audio zone covering the global cabin speaker. The front passenger zone can share the driver's audio zone or can have its own audio output.

    End new requirements

  • 2.5.2. Multimedia:

    See revision

    If Automotive device implementations support Concurrent Multi-user (where multiple Android users can interact with the device concurrently, each using their own display when config_multiuserVisibleBackgroundUsers is enabled), they:

    • [5.5.3/A-1-1] MUST define identical volume curves for all audio output streams mapping to the same volume-group as defined in the car audio configuration file.

    End new requirements

  • 2.5.3. Software:

    See revision

    • [3.8/A-0-1] MUST NOT allow full secondary users who are not the current foreground user to launch activities and have access to UI on any displays.

    If Automotive device implementations support Concurrent Multi-user (where multiple Android users can interact with the device concurrently, each using their own display when config_multiuserVisibleBackgroundUsers is enabled), for full secondary users that aren't the current foreground user but have UI access to the display, they:

    End new requirements

  • 2.5.5. Security Model:

    See revision

    • [9.11/A-0-4] MUST support key attestation where the attestation signing key is protected by secure hardware and signing is performed in secure hardware. The attestation signing keys MUST be shared across large enough number of devices to prevent the keys prevented from being used as permanent device identifiers. One way of meeting this requirement is to share the same attestation key unless at least 100,000 units of a given SKU are produced. If more than 100,000 units of an SKU are produced, a different key MAY be used for each 100,000 units.

  • 2.5.6. Developer Tools and Options Compatibility:

    See revision

    • [6.1/A-0-5] The perfetto traced daemon MUST be enabled by default (system property persist.traced.enable).

    End new requirements

  • 2.6.1. Hardware:

    See revision

    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.

3. Software

  • 3.1. Managed API Compatibility:

    See revision

    • [C-0-8] MUST NOT support installing applications targeting an API level less than 23 24.

  • 3.3.1. Application Binary Interfaces:

    See revision

    • [C-0-6] MUST report, via the above parameters, a subset of the following list of ABIs and MUST NOT report any ABI not on the list.

  • 3.8.3.4. Sensitive Notification Protection:

    See revision

    Sensitive notification information includes content such as one-time passwords, one-time confirmation codes, and similar authentication or reset codes that can appear in notifications to users.

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

    • [C-1-1] MUST redact sensitive notification information from being passed to notification listeners, unless the listener service is one of:

      • System signed apps with a uid < 10000
      • System UI
      • Shell
      • Designated Companion Device App (defined by CompanionDeviceManager)
      • SYSTEM_AUTOMOTIVE_PROJECTION role
      • SYSTEM_NOTIFICATION_INTELLIGENCE role
      • HOME role

    The AOSP implementation of NotificationAssistantServices exemplifies and meets these requirements. See android.ext.services.notification for an example.

    End new requirements

  • 3.8.14. Multi-windows:

    See revision

    If device implementations include more than one Android-compatible display areas and make such areas available to apps, they:

    • [C-4-1] MUST support multi-window mode.

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

    • [C-5-1] MUST implement the correct version of the Window Manager Extensions API level as described in WindowManager Extensions.

    End new requirements

  • 3.9. Device Administration:

    See revision

    Android includes features that allow security-aware applications enable device policy controller 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 Device Policy Manager APIs.

    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.

  • 3.9.1.1. Device owner provisioning:

    See revision

    • [C-1-2] MUST show an appropriate disclosure notice (such as referenced in AOSP) and obtain affirmative consent from the end user prior to an app being set as Device Owner, unless the device is programmatically configured for Retail Demo Mode prior to on-screen, end-user interaction. If device implementations declare android.software.device_admin, but also include a proprietary device 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 has been 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".

    • [C-2-3] MUST NOT hard code the consent or prevent the use of other device owner apps.

  • 3.9.1.2. Managed profile provisioning:

    See revision

    • [C-1-2] The managed profile provisioning process (the flow initiated by the DPC using the android.app.action.PROVISION_MANAGED_PROFILE) or by the platform), consent screen and user experience MUST align with the AOSP implementation.

  • 3.12. TV Input Framework:

    See revision

    The Android Television Input Framework (TIF) simplifies the delivery of live content to Android Television devices. TIF provides a standard API to create input modules that control Android Television devices.

    If device implementations support TIF, they:

    • [C-1-1] MUST declare the platform feature android.software.live_tv.
    • [C-1-2] MUST support all TIF APIs such that an application which uses these APIs and the third-party TIF-based inputs service can be installed and used on the device.

  • 3.16. Companion Device Pairing:

    See revision

    • [C-1-3] MUST provide user affordances for the user to select/confirm a companion device is present and operational, which MUST use the same message as implemented in AOSP without addition or modification.

  • 3.19. Language Settings:

    See revision

    Device implementations:

    • [C-0-1] MUST NOT provide any user affordance to select gender-specific language treatment for languages that do not support gender specific translations. See grammatical resources for more information.

    End new requirements

5. Multimedia Compatibility

  • 5.3.8. Dolby Vision:

    See revision

    • [C-1-2] MUST properly display Dolby Vision content either on the device screen or on an external display attached via a standard video output port (e.g., HDMI).

  • 5.5.2. Audio Effects:

    See revision

    • [C-1-4] MUST support audio effects with floating-point input and output, when the effect results are returned to the framework audio pipeline. This refers to typical insert or aux effects such as the equalizer. Equivalent behavior is strongly recommended when the effect results are not visible by the framework audio pipeline (such as, post-processing or offloaded effects).

    See revision

    • [C-1-5] MUST make sure that audio effects support multiple channels up to the mixer channel count also known as FCC_LIMIT, when the effect results are returned to the framework audio pipeline. This refers to typical insert or aux effects, but excludes special effects such as downmix, upmix, spatialization effects which change the channel count. Equivalent behavior is recommended when the effects are not visible by the framework audio pipeline (such as, post-processing or offloaded effects).

  • 5.6. Audio Latency:

    See revision

    • [C-1-1] The output timestamp returned by AudioTrack.getTimestamp and AAudioStream_getTimestamp is accurate to +/- 2 ms.

    See revision

    • [C-1-4] The calculated round-trip latencies based on input and output timestamps returned by AAudioStream_getTimestamp MUST be within 200 msec of the measured round trip latency for AAUDIO_PERFORMANCE_MODE_NONE and AAUDIO_PERFORMANCE_MODE_LOW_LATENCY for speakers, wired and wireless headsets.

    End new requirements

    See revision

    If device implementations declare android.hardware.audio.output they are STRONGLY RECOMMENDED to meet or exceed the following requirements:

    • [C-SR-1] Cold output latency of 100 milliseconds or less over the speaker data path.

    • [C-SR-2] Tap-to-tone latency of 80 milliseconds or less.

    • [C-SR-4] The calculated round-trip latencies based on input and output timestamps returned by AAudioStream_getTimestamp are STRONGLY RECOMMENDED to be within 30 msec of the measured round trip latency for AAUDIO_PERFORMANCE_MODE_NONE and AAUDIO_PERFORMANCE_MODE_LOW_LATENCY for speakers, wired and wireless headsets.

    See revision

    If device implementations meet the above requirements, after any initial calibration, when using the AAudio native audio API, for continuous output latency and cold output latency over at least one supported audio output device, they are:

    See revision

    If device implementations do not meet the requirements for low-latency audio via the AAudio native audio API, they:

    • [C-2-1] MUST NOT report support for low-latency audio.

    See revision

    • [C-3-1] Limit the error in input timestamps, as returned by AudioRecord.getTimestamp or AAudioStream_getTimestamp, to +/- 2 ms. "Error" here means the deviation from the correct value.

    See revision

    If device implementations include android.hardware.microphone, they are STRONGLY RECOMMENDED to meet these input audio requirements:

    • [C-SR-8] Cold input latency of 100 milliseconds or less over the microphone data path.
    • [C-SR-11] Limit the error in input timestamps, as returned by AudioRecord.getTimestamp or AAudioStream_getTimestamp, to +/- 1 ms.

    See revision

    If device implementations declare android.hardware.audio.output and android.hardware.microphone, they:

    • [C-SR-12] Are STRONGLY RECOMMENDED to have a Mean Continuous Round-Trip Latency of 50 milliseconds or less over 5 measurements, with a Mean Absolute Deviation less than 10 msec, over at least one supported path.

    See revision

    The following table defines the requirements for RTL for Handheld device implementations as defined in 2.2.1 that declare android.hardware.audio.output and android.hardware.microphone.

    Device and Declarations RTL (ms) MAD (ms) Loopback Paths
    Handheld 250 30 speaker/mic, analog 3.5mm (if supported), USB (if supported)
    >= MPC_T (14) 80 15 at least one path
    FEATURE_AUDIO_LOW_LATENCY 50 10 at least one path
    FEATURE_AUDIO_PRO 25 5 at least one path
    FEATURE_AUDIO_PRO 20 5 analog (if supported)
    FEATURE_AUDIO_PRO 25 5 USB (if analog not supported)

    End new requirements

    See revision

    The following table defines the requirements for TTL for Handheld device implementations as defined in 2.2.1 that declare android.hardware.audio.output and android.hardware.microphone.

    Device and Declarations TTL (ms)
    Handheld 250
    >= MPC_T (14) 80
    MPC_S (13) 100
    FEATURE_AUDIO_PRO 80

    End new requirements

    See revision

    If device implementations include support for spatial audio with head tracking and declare the PackageManager.FEATURE_AUDIO_SPATIAL_HEADTRACKING_LOW_LATENCY flag, they:

    • [C-4-1] MUST exhibit a maximum head-tracking to audio-update latency of 300ms.

    End new requirements

  • 5.10. Professional Audio:

    See revision

    • [C-1-2] MUST have the continuous round-trip audio latency, meet the latency requirements for FEATURE_AUDIO_PRO as defined in section 5.6 Audio Latency of 25 milliseconds or less over at least one supported path.

    See revision

    • [C-1-5] MUST meet latencies and USB audio latency requirements using the AAudio native audio API and AAUDIO_PERFORMANCE_MODE_LOW_LATENCY.

    See revision

    • [C-1-8] MUST have an average Tap-to-tone latency of 80 milliseconds or less over at least 5 measurements over the speaker to microphone data path.
    • [C-SR-1] Are STRONGLY RECOMMENDED to meet latencies as defined in section 5.6 Audio Latency, of 20 milliseconds or less, over 5 measurements with a Mean Absolute Deviation less than 5 milliseconds over the speaker to microphone path.
    • [C-SR-2] Are STRONGLY RECOMMENDED to meet the Pro Audio requirements for continuous round-trip audio latency, cold input latency and cold output latency and USB audio requirements using the AAudio native audio API over the MMAP path.
    • [C-SR-3] Are STRONGLY RECOMMENDED to provide a consistent level of CPU performance while audio is active and CPU load is varying. This should be tested using the Android app SynthMark. SynthMark uses a software synthesizer running on a simulated audio framework that measures system performance. See the SynthMark documentation for an explanation of the benchmarks. The SynthMark app needs to be run using the "Automated Test" option and achieve the following results:
      • voicemark.90 >= 32 voices
      • latencymark.fixed.little <= 15 msec
      • latencymark.dynamic.little <= 50 msec
    • SHOULD minimize audio clock inaccuracy and drift relative to standard time.
    • SHOULD minimize audio clock drift relative to the CPU CLOCK_MONOTONIC when both are active.
    • SHOULD minimize audio latency over on-device transducers.
    • SHOULD minimize audio latency over USB digital audio.
    • SHOULD document audio latency measurements over all paths.
    • SHOULD minimize jitter in audio buffer completion callback entry times, as this affects usable percentage of full CPU bandwidth by the callback.
    • SHOULD provide zero audio glitches under normal use at reported latency.
    • SHOULD provide zero inter-channel latency difference.
    • SHOULD minimize MIDI mean latency over all transports.
    • SHOULD minimize MIDI latency variability under load (jitter) over all transports.
    • SHOULD provide accurate MIDI timestamps over all transports.
    • SHOULD minimize audio signal noise over on-device transducers, including the period immediately after cold start.
    • SHOULD provide zero audio clock difference between the input and output sides of corresponding end-points, when both are active. Examples of corresponding end-points include the on-device microphone and speaker, or the audio jack input and output.
    • SHOULD handle audio buffer completion callbacks for the input and output sides of corresponding end-points on the same thread when both are active, and enter the output callback immediately after the return from the input callback. Or if it is not feasible to handle the callbacks on the same thread, then enter the output callback shortly after entering the input callback to permit the application to have a consistent timing of the input and output sides.
    • SHOULD minimize the phase difference between HAL audio buffering for the input and output sides of corresponding end-points.
    • SHOULD minimize touch latency.
    • SHOULD minimize touch latency variability under load (jitter).

    See revision

    If device implementations meet all of the above requirements, they:

    See revision

    • [C-2-1] MUST have a mean Continuous Round-trip Audio Latency, as defined in section 5.6 Audio Latency, of 20 milliseconds or less, over 5 measurements with a Mean Absolute Deviation less than 5 milliseconds over the audio jack path using an Audio Loopback Dongle.

    See revision

    See revision

    • [C-3-2] MUST have a mean Continuous Round-trip Audio Latency of 25 milliseconds or less, over 5 measurements with a Mean Absolute Deviation less than 5 milliseconds over the USB host mode port using USB audio class. (This can be measured using a USB-3.5mm adapter and an Audio Loopback Dongle, or using a USB audio interface with patch cables connecting the inputs to outputs).
    • [C-SR-6] Are STRONGLY RECOMMENDED to support simultaneous I/O up to 8 channels each direction, 96 kHz sample rate, and 24-bit or 32-bit depth, when used with USB audio peripherals that also support these requirements.
    • [C-SR-7] Are STRONGLY RECOMMENDED to meet this group of requirements using the AAudio native audio API over the MMAP path.

    See revision

    If device implementations include an HDMI port, they:

    • SHOULD support output in stereo and eight channels at 20-bit or 24-bit depth and 192 kHz without bit-depth loss or resampling, in at least one configuration.

6. Developer Tools and Options Compatibility

  • 6.1. Developer Tools:

    See revision

    • [C-0-2] MUST support adb as documented in the Android SDK and the shell commands provided in the AOSP, which can be used by app developers, including dumpsys, cmd stats, and Simpleperf.

    See revision

    • [C-0-10] MUST record, without omission, and make the following events accessible and available to the cmd stats shell command and the StatsManager System API class.
      • ActivityForegroundStateChanged
      • AnomalyDetected
      • AppBreadcrumbReported
      • AppCrashOccurred
      • AppStartOccurred
      • BatteryLevelChanged
      • BatterySaverModeStateChanged
      • BleScanResultReceived
      • BleScanStateChanged
      • ChargingStateChanged
      • DeviceIdleModeStateChanged
      • ForegroundServiceStateChanged
      • GpsScanStateChanged
      • InputDeviceUsageReported
      • JobStateChanged
      • KeyboardConfigured
      • KeyboardSystemsEventReported
      • PluggedStateChanged
      • ScheduledJobStateChanged
      • ScreenStateChanged
      • SyncStateChanged
      • SystemElapsedRealtime
      • TouchpadUsage
      • UidProcessStateChanged
      • WakelockStateChanged
      • WakeupAlarmOccurred
      • WifiLockStateChanged
      • WifiMulticastLockStateChanged
      • WifiScanStateChanged

7. Hardware Compatibility

  • 7.1.1.1. Screen Size and Shape:

    See revision

    If device implementations include one or more Android-compatible display areas that are foldable, or include a folding hinge between multiple Android-compatible display panel areas and make such display areas available to applications, they:

    • [C-4-1] MUST implement the correct version of the Window Manager Extensions API level as described in WindowManager Extensions.

  • 7.1.4.1. OpenGL ES:

    See revision

    See revision

    • [C-SR-1] Are STRONGLY RECOMMENDED to support OpenGL ES 3.1.

  • 7.1.4.2. Vulkan:

    See revision

    If device implementations include support for Vulkan, then they:

    • [C-SR-8] Are STRONGLY RECOMMENDED to not modify the Vulkan loader.
    • [C-1-14] MUST NOT enumerate Vulkan Device extensions of type "KHR", "GOOGLE", or "ANDROID" unless these extensions are included in the android.software.vulkan.deqp.level feature flag.

    End new requirements

  • 7.3.10. Biometric Sensors:

    See revision

    • [C-4-4] MUST allow applications to add custom content to BiometricPrompt using the PromptContentView content display formats. The content display formats MUST NOT be extended to allow imagery, links, interactive content, or other forms of media that are not already part of the BiometricPrompt API. Stylistic adjustments that do not alter, obscure, or truncate this content can be made (such as changing position, padding, margins, and typography).

    End new requirements

    See revision

    • [C-1-5] MUST completely remove all identifiable biometric data for a user when the user's account is removed (including via a factory reset) or when the recommended primary authentication (e.g. PIN, pattern, password) is removed.

    See revision

    • [C-1-7] MUST challenge the user for the recommended primary authentication (such as PIN, pattern, password) once every 24 hours or less. Note: Upgrading devices launched on Android version 9 or earlier MUST challenge the user for the recommended primary authentication (such as, PIN, pattern, password) once every 72 hours or less.

    See revision

    • [C-1-8] MUST challenge the user for the recommended primary authentication (such as PIN, pattern, password) or Class 3 (STRONG) biometric after one of the following:
      • a 4-hour idle timeout period, OR
      • 3 failed biometric authentication attempts.
      • The idle timeout period and the failed authentication count is reset after any successful confirmation of the device credentials. Note: Upgrading devices launched on Android version 9 or earlier MAY be exempted from C-1-8.

    See revision

    • [C-1-15] MUST allow users to remove single or multiple biometrics enrollments.

    End new requirements

  • 7.4.2. IEEE 802.11 (Wi-Fi):

    See revision

    • [C-1-4] MUST support multicast DNS (mDNS) and MUST NOT filter mDNS packets (224.0.0.251 or ff02::fb) at any time of operation, including when the screen is not in an active state, unless dropping or filtering these packets is necessary to stay within power consumption ranges required by regulatory requirements applicable to the target market.

    See revision

    • [C-1-4] MUST support mDNS and MUST NOT filter mDNS packets (224.0.0.251 or ff02::fb) at any time of operation, including when the screen is not in an active state, unless the multicast lock is not held and the packets are filtered by APF. The packets are not required to satisfy any mDNS operations currently requested by applications through the NsdManager APIs. However, the device MAY filter mDNS packets if doing so is necessary to stay within power consumption ranges required by regulatory requirements applicable to the target market.

    End new requirements

9. Security Model Compatibility

  • 9.1. Permissions:

    See revision

    • [C-SR-1] Permissions with a protectionLevel of PROTECTION_SIGNATURE are STRONGLY RECOMMENDED to only be granted to either:

      • Apps preinstalled on the system image (as well as APEX files).
      • Apps allowlisted with allowed permissions if they are not included in the system image.

    End new requirements

  • 9.7. Security Features:

    See revision

    If a device declares android.hardware.telephony, supports the radio capability CAPABILITY_USES_ALLOWED_NETWORK_TYPES_BITMASK, and includes a cellular modem that supports 2G connections, the device implementation:

    End new requirements

  • 9.8.2. Recording:

    See revision

    Device implementations:

    • [C-0-7] MUST NOT record, project, or cast sensitive information such as:

    End new requirements

  • 9.8.16. Continuous Audio and Camera data:

    See revision

    In addition to requirements outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, and 9.8.15 Sandboxed API implementations, implementations that make use of Audio data obtained in background (continuously) through AudioRecord, SoundTrigger or other Audio APIs OR Camera data obtained in background (continuously) through CameraManager or other Camera APIs:

    If device implementations capture any of the data as described in 9.8.2 or section 9.8.6, and if such implementations make use of Audio data obtained in background (continuously) through AudioRecord, SoundTrigger, or other Audio APIs OR Camera data obtained in background (continuously) through CameraManager or other Camera APIs, they:

    End new requirements

    See revision

    If the Camera data is supplied from a remote wearable device and accessed in an unencrypted form outside Android OS, sandboxed implementation or a sandboxed functionality built by WearableSensingManager, then they:

    If device implementations receive Camera or Microphone data from a remote wearable device and the data is accessed in an unencrypted form outside of Android OS, sandboxed implementation or a sandboxed functionality built by WearableSensingManager, they:

    End new requirements

  • 9.10. Device Integrity:

    See revision

    • [C-SR-1] If there are multiple discrete chips in the device (e.g. radio, specialized image processor), the boot process of each of those chips is STRONGLY RECOMMENDED to verify every stage upon booting.

    • [C-1-14] MUST verify the signature at least once per boot for allow listed packages that are listed as require-strict-signature in system config.

    End new requirements

    See revision

    If device implementations are already launched without supporting C-1-8 through C-1-11 on an earlier version of Android and cannot add support for these requirements with a system software update, they MAY be exempted from the requirements.

    See revision

    Device implementations:

    If device implementations support the Android Protected Confirmation API they:

    • [C-3-1] MUST report true for the ConfirmationPrompt.isSupported() API.

    • [C-3-2] MUST ensure that code running in the Android OS including its kernel, malicious or otherwise, cannot generate a positive response without user interaction.

    • [C-3-3] MUST ensure that the user has been able to review and approve the prompted message even in the event that the Android OS, including its kernel, is compromised.

  • 9.11. Keys and Credentials:

    See revision

    • [C-1-4] MUST support key attestation where the attestation signing key is protected by secure hardware and signing is performed in secure hardware. The attestation signing keys MUST be shared across large enough number of devices to prevent the keys prevented from being used as permanent device identifiers.

  • 9.11.1. Secure Lock Screen, Authentication and Virtual Devices:

    See revision

    • [C-10-6] MUST disable the creation of associated input events via VirtualDeviceManager when indicated by app streaming as indicated by DevicePolicyManager.setNearbyAppStreamingPolicy.

    See revision

    • [C-10-7] MUST either:
      • Disable clipboard usage
      • Enable a separate clipboard for each device that supports clipboards

    End new requirements

    • [C-10-7] MUST use a separate clipboard solely for each virtual device (or disable the clipboard for virtual devices)

    See revision

    • [C-10-12] MUST restrict intents initiated from a virtual device to display only on the same virtual device

    See revision

    • [C-10-14] MUST provide a user affordance to enable clipboard sharing between devices prior to sharing clipboard data between physical and virtual devices if the device is implementing a shared clipboard.
    • [C-10-15] MUST show notifications when clipboard data is accessed across devices, and MUST make content inaccessible after one minute measured from the initial sharing time.

    End new requirements

    See revision

    • [C-13-9] MUST block activities which do not explicitly enable streaming and which indicate they show sensitive content, including via SurfaceView#setSecure, and FLAG_SECURE, or SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS, from being started on the virtual device.

  • 9.11.2. StrongBox:

    See revision

  • 9.17. Android Virtualization Framework:

    See revision

    See section 9.17. Android Virtualization Framework.

Back to top