Android Compatibility Definition Document changelog

Android 14

November 20, 2023

2. Device Types

  • 2.2.1. Hardware:

    See revision

    If Handheld device implementations declare support of any 64-bit ABI (with or without any 32-bit ABI):

  • 2.2.7.2. Camera:

    See revision

    • [7.5/H-1-13] MUST support LOGICAL_MULTI_CAMERA capability for the primary rear-facing camera if there are more than 1 RGB rear-facing cameras.

  • 2.3.2. Multimedia:

    See revision

    • [5.8/T-0-1] MUST set the HDMI output mode to the highest resolution for the chosen SDR or HDR format that works with 50Hz or 60Hz refresh rate for the external display.

      MUST set the HDMI output mode to select the maximum resolution that can be supported with either a 50Hz or 60Hz refresh rate.

  • 2.4.5. Security Model:

    See revision

    • [9/W-0-1] MUST declare the android.hardware.security.model.compatible feature.

6. Developer Tools and Options Compatibility

  • 6.1. Developer Tools:

    See revision

    • [C-0-12] MUST write a LMK_KILL_OCCURRED_FIELD_NUMBER Atom to the

    See revision

    • [C-0-13] MUST implement the shell command dumpsys gpu --gpuwork to display

9. Security Model Compatibility

  • 9.7. Security Features:

    See revision

    If device implementations use a Linux kernel that is capable of supporting SELinux, they:

    See revision

    If device implementations use kernel other than Linux or Linux without SELinux, they:

October 4, 2023

2. Device Types

  • 2.2. Handheld Requirements:

    See revision

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

    • Have a physical diagonal screen size in the range of 4 inches 3.3 inches (or 2.5 inches for device implementations which shipped on API level 29 or earlier) to 8 inches.

    Start new requirements

    • Have a touchscreen input interface.

  • 2.2.1. Hardware:

    See revision

    Handheld device implementations:

    • [7.1.1.1/H-0-1] MUST have at least one Android-compatible display that meets all requirements described on this document. display that measures at least 2.2” on the short edge and 3.4” on the long edge.

    If Handheld device implementations support software screen rotation, they:

    • [7.1.1.1/H-1-1]* MUST make the logical screen that is made available for third party applications be at least 2 inches on the short edge(s) and 2.7 inches on the long edge(s). Devices that shipped on Android API level 29 or earlier MAY be exempted from this requirement.

    If Handheld device implementations do not support software screen rotation, they:

    • [7.1.1.1/H-2-1]* MUST make the logical screen that is made available for third party applications be at least 2.7 inches on the short edge(s). Devices that shipped on Android API level 29 or earlier MAY be exempted from this requirement.

    Start new requirements

    • [7.1.1.1/H-0-3]* MUST map each UI_MODE_NORMAL display made available for third party applications onto an unobstructed physical display area that is at least 2.2” inches on the short edge and 3.4” inches on the long edge.

    • [7.1.1.3/H-0-1]* MUST set the value of DENSITY_DEVICE_STABLE to be 92% or greater than the actual, physical density of the corresponding display.

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

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

    If Handheld device implementations include at least one haptic actuator, they:

    If Handheld device implementations include at least one general purpose 7.10 linear resonant actuator, they:

    • [7.10/H] SHOULD position the placement of the actuator near the location where the device is typically held or touched by hands.

    • [7.10/H] SHOULD move the haptic actuator in the X-axis (left-right) of the device’s natural portrait orientation.

    If Handheld device implementations have a general purpose haptic actuator which is X-axis linear resonant actuator (LRA), they:

    • [7.10/H] SHOULD have the resonant frequency of the X-axis LRA be under 200 Hz.

  • 2.2.2. Multimedia:

    See revision

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

    • [5.2/H-0-3] AV1

    Handheld device implementations MUST support the following video decoding formats and make them available to third-party applications:

    • [5.3/H-0-6] AV1

  • 2.2.3. Software:

    See revision

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

    • [3.8.3/H-1-1] MUST implement the screen pinning behavior and provide the user with a settings menu to toggle the feature.

    If Handheld device implementations include support for ControlsProviderService and Control APIs and allow third-party applications to publish device controls, then they:

    If device implementations allow users to place calls of any sort, they

  • 2.2.4. Performance and Power:

    See revision

    Handheld device implementations:

    • [8.5/H-0-1] MUST provide a user affordance in the Settings menu to see all apps with either active foreground services or user-initiated jobs, including the duration of each of these services since it started as described in the SDK document. and the ability to stop an app that is running a foreground service or a user-initiated job.with the ability to stop an app that is running a foreground service and display all apps that have active foreground services and the duration of each of these services since it started as described in the SDK document.
      • Some apps MAY be exempted from being stopped or being listed in such a user affordance as described in the SDK document.

    • [8.5/H-0-2]MUST provide a user affordance to stop an app that is running a foreground service or a user-initiated job.

  • 2.2.5. Security Model:

    See revision

    If device implementations declare support for android.hardware.telephony, they:

    • [9.5/H-1-1] MUST NOT set UserManager.isHeadlessSystemUserMode to true.

    If device implementations have a secure lock screen and include one or more trust agent, which implements the TrustAgentService System API, they:

    • [9.11.1/H-1-1] MUST challenge the user for one of the recommended primary authentication methods (eg: PIN, pattern, password) more frequently than once every 72 hours.

    If Handheld device implementations set UserManager.isHeadlessSystemUserMode to true, they

    • [9.5/H-4-1] MUST NOT include support for eUICCs, nor for eSIMs with calling capability.
    • [9.5/H-4-2] MUST NOT declare support for android.hardware.telephony.

    If Handheld device implementations support the System API HotwordDetectionService or a another mechanism for hotword detection without mic access indication, they:

    • [9.8/H-1-1] MUST make sure the hotword detection service can only transmit data to the System, ContentCaptureService, or on-device speech recognition service created by SpeechRecognizer#createOnDeviceSpeechRecognizer().
    • [9.8/H-1-6] MUST NOT allow more than 100 bytes of data (excluding audio streams) to be transmitted out of the hotword detection service on each successful hotword result.

    • [9.8/H-1-15] MUST ensure that audio streams provided on successful hotword results are transmitted one-way from the hotword detection service to the voice interaction service.

    If device implementations include an application that uses the System API HotwordDetectionService, or similar mechanism for hotword detection without mic usage indication, the application:

    • [9.8/H-2-3] MUST NOT transmit from the hotword detection service, audio data, data that can be used to reconstruct (wholly or partially) the audio, or audio contents unrelated to the hotword itself, except to the ContentCaptureService or on-device speech recognition service.

    If Handheld device implementations support the System API VisualQueryDetectionService or another mechanism for query detection without mic and/or camera access indication, they:

    • [9.8/H-3-1] MUST make sure the query detection service can only transmit data to the System, or ContentCaptureService, or on-device speech recognition service (created by SpeechRecognizer#createOnDeviceSpeechRecognizer()).
    • [9.8/H-3-2] MUST NOT allow any audio or video information to be transmitted out of the VisualQueryDetectionService, except to ContentCaptureService or on-device speech recognition service.
    • [9.8/H-3-3] MUST display a user notice in System UI when device detects user intent to engage with the Digital Assistant Application (e.g by detecting user presence via camera).
    • [9.8/H-3-4] MUST display a microphone indicator and display the detected user query in the UI right after the user query is detected.
    • [9.8/H-3-5] MUST NOT allow a user-installable application to provide the visual query detection service.

  • 2.2.7.1. Media:

    See revision

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

    Start new requirements

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

    • [5.1/H-1-1] MUST advertise the maximum number of hardware video decoder sessions that can be run concurrently in any codec combination via the CodecCapabilities.getMaxSupportedInstances() and VideoCapabilities.getSupportedPerformancePoints() methods.
    • [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. AV1 codecs are only required to support 1080p resolution, but are still required to support 6 instances at 1080p30fps.
    • [5.1/H-1-3] MUST advertise the maximum number of hardware video encoder sessions that can be run concurrently in any codec combination via the CodecCapabilities.getMaxSupportedInstances() and VideoCapabilities.getSupportedPerformancePoints() methods.
    • [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. AV1 codecs are only required to support 1080p resolution, but are still required to support 6 instances at 1080p30fps.
    • [5.1/H-1-5] MUST advertise the maximum number of hardware video encoder and decoder sessions that can be run concurrently in any codec combination via the CodecCapabilities.getMaxSupportedInstances() and VideoCapabilities.getSupportedPerformancePoints() methods.
    • [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. 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 (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. 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-7] MUST have a codec initialization latency of 40 ms or less for a 1080p or smaller video encoding session for all hardware video encoders when under load. Load here is defined as a concurrent 1080p to 720p video-only transcoding session using hardware video codecs together with the 1080p audio-video recording initialization. For Dolby vision codec, the codec initialization latency MUST be 50 ms or less.
    • [5.1/H-1-8] MUST have a codec initialization latency of 30 ms or less for a 128 kbps or lower bitrate audio encoding session for all audio encoders when under load. Load here is defined as a concurrent 1080p to 720p video-only transcoding session using hardware video codecs together with the 1080p audio-video recording initialization.
    • [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. AV1 codec sessions are only required to support 1080p resolution even when this requirement calls for 4K.
    • [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@30 fps (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. AV1 codec sessions are only required to support 1080p resolution even when this requirement calls for 4K.
    • [5.1/H-1-11] MUST support a secure decoder for every hardware AVC, HEVC, VP9 or AV1 decoder on the device.
    • [5.1/H-1-12] MUST have a codec initialization latency of 40 ms or less for a 1080p or smaller video decoding session for all hardware video decoders when under load. Load here is defined as a concurrent 1080p to 720p video-only transcoding session using hardware video codecs together with the 1080p audio-video playback initialization. For Dolby vision codec, the codec initialization latency MUST be 50 ms or less.
    • [5.1/H-1-13] MUST have a codec initialization latency of 30 ms or less for a 128 kbps or lower bitrate audio decoding session for all audio decoders when under load. Load here is defined as a concurrent 1080p to 720p video-only transcoding session using hardware video codecs together with the 1080p audio-video playback initialization.
    • [5.1/H-1-14] MUST support AV1 hardware decoder Main 10, Level 4.1 and film grain.
    • [5.1/H-1-15] MUST have at least 1 hardware video decoder supporting 4K60.
    • [5.1/H-1-16] MUST have at least 1 hardware video encoder supporting 4K60.
    • [5.3/H-1-1] MUST NOT drop more than 1 frame in 10 seconds (i.e less than 0.167 percent frame drop) for a 4K 60 fps video session under load.
    • [5.3/H-1-2] MUST NOT drop more than 1 frame in 10 seconds during a video resolution change in a 60 fps video session under load for a 4K session.
    • [5.6/H-1-1] MUST have a tap-to-tone latency of 80 milliseconds or less using the CTS Verifier tap-to-tone test.
    • [5.6/H-1-2] MUST have a round-trip audio latency of 80 milliseconds or less over at least one supported data path.
    • [5.6/H-1-3] MUST support >=24-bit audio for stereo output over 3.5 mm audio jacks if present and over USB audio if supported through the entire data path for low latency and streaming configurations. For the low latency configuration, AAudio should be used by the app in low-latency callback mode. For the streaming configuration, a Java AudioTrack should be used by the app. In both the low latency and streaming configurations, the HAL output sink should accept either AUDIO_FORMAT_PCM_24_BIT, AUDIO_FORMAT_PCM_24_BIT_PACKED, AUDIO_FORMAT_PCM_32_BIT or AUDIO_FORMAT_PCM_FLOAT for its target output format.
    • [5.6/H-1-4] MUST support >=4 channel USB audio devices (This is used by DJ controllers for previewing songs.)
    • [5.6/H-1-5] MUST support class compliant MIDI devices and declare the MIDI feature flag.
    • [5.6/H-1-9] MUST support at least 12 channel mixing. This implies the capability to open an AudioTrack with 7.1.4 channel mask and properly spatialise or downmix all channels to stereo.
    • [5.6/H-SR] Are STRONGLY RECOMMENDED to support 24 channel mixing with at least support for 9.1.6 and 22.2 channel masks.
    • [5.7/H-1-2] MUST support MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL with the below content decryption capabilities.
    Minimum Sample size 4 MiB
    Minimum Number of Subsamples - H264 or HEVC 32
    Minimum Number of Subsamples - VP9 9
    Minimum Number of Subsamples - AV1 288
    Minimum subsample buffer size 1 MiB
    Minimum Generic crypto buffer size 500 KiB
    Minimum Number of concurrent sessions 30
    Minimum Number of keys per session 20
    Minimum Total Number of Keys (all sessions) 80
    Minimum Total Number of DRM Keys (all sessions) 6
    Message Size 16 KiB
    Decrypted Frames per Second 60 fps
    • [5.1/H-1-17] MUST have at least 1 hardware image decoder supporting AVIF Baseline Profile.
    • [5.1/H-1-18] MUST support AV1 encoder which can encode up to 480p resolution at 30fps and 1Mbps.
    • [5.12/H-1-1] MUST [5.12/H-SR] Are Strongly Recommended to support support the Feature_HdrEditing feature for all hardware AV1 and HEVC encoders present on the device.
    • [5.12/H-1-2] MUST support RGBA_1010102 color format for all hardware AV1 and HEVC encoders present on the device.
    • [5.12/H-1-3] MUST advertise support for the EXT_YUV_target extension to sample from YUV textures in both 8 and 10-bits.
    • [7.1.4/H-1-1] MUST have at least 6 hardware overlays in the Data processing unit (DPU) Hardware composer (HWC), with at least 2 of them capable of displaying 10-bit video content.

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

    • [5.2/H-2-1] MUST meet the minimum quality target defined by the video encoder rate-distortion curves for hardware AVC and HEVC codecs, as defined in the forthcoming documentation.

  • 2.2.7.2. Camera:

    See revision

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

    • [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. The primary rear-facing camera is the rear-facing camera with the lowest camera ID.
    • [7.5/H-1-2] MUST have a primary front facing camera with a resolution of at least 6 megapixels and support video capture at 1080p@30fps. The primary front-facing camera is the front-facing camera with the lowest camera ID.
    • [7.5/H-1-3] MUST support android.info.supportedHardwareLevel property as FULL or better for both primary cameras.
    • [7.5/H-1-4] MUST support CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME for both primary cameras.
    • [7.5/H-1-5] MUST have camera2 JPEG capture latency < 1000 900 ms for 1080p resolution as measured by the CTS camera PerformanceTest under ITS lighting conditions (3000K) for both primary cameras.
    • [7.5/H-1-6] MUST have camera2 startup latency (open camera to first preview frame) < 500 ms as measured by the CTS camera PerformanceTest under ITS lighting conditions (3000K) for both primary cameras.
    • [7.5/H-1-8] MUST support CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW and android.graphics.ImageFormat.RAW_SENSOR for the primary back camera.
    • [7.5/H-1-9] MUST have a rear-facing primary camera supporting 720p or 1080p @ 240fps.
    • [7.5/H-1-10] MUST have min ZOOM_RATIO < 1.0 for the primary cameras if there is an ultrawide RGB camera facing the same direction.
    • [7.5/H-1-11] MUST implement concurrent front-back streaming on primary cameras.
    • [7.5/H-1-12] MUST support CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION for both primary front and primary back camera.
    • [7.5/H-1-13] MUST support LOGICAL_MULTI_CAMERA capability for the primary cameras if there are greater than 1 RGB cameras facing the same direction.
    • [7.5/H-1-14] MUST support STREAM_USE_CASE capability for both primary front and primary back camera.
    • [7.5/H-1-15] MUST support Bokeh & Night mode extensions via both CameraX and Camera2 extensions for primary cameras.
    • [7.5/H-1-16] MUST support DYNAMIC_RANGE_TEN_BIT capability for the primary cameras.
    • [7.5/H-1-17] MUST support CONTROL_SCENE_MODE_FACE_PRIORITY and face detection (STATISTICS_FACE_DETECT_MODE_SIMPLE or STATISTICS_FACE_DETECT_MODE_FULL) for the primary cameras.

  • 2.2.7.3. Hardware:

    See revision

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

    • [7.1.1.1/H-2-1] MUST have screen resolution of at least 1080p.
    • [7.1.1.3/H-2-1] MUST have screen density of at least 400 dpi.
    • [7.1.1.3/H-3-1] MUST have a HDR display supporting at least 1000 nits average.
    • [7.6.1/H-2-1] MUST have at least 8 GB of physical memory.

  • 2.2.7.4. Performance:

    See revision

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

    • [8.2/H-1-1] MUST ensure a sequential write performance of at least 150 MB/s.
    • [8.2/H-1-2] MUST ensure a random write performance of at least 10 MB/s.
    • [8.2/H-1-3] MUST ensure a sequential read performance of at least 250 MB/s.
    • [8.2/H-1-4] MUST ensure a random read performance of at least 100 MB/s.
    • [8.2/H-1-5] MUST ensure a parallel sequential read and write performance with 2x read and 1x write performance of at least 50 MB/s.

  • 2.3.2. Multimedia:

    See revision

    Television device implementations MUST support the following video encoding formats and make them available to third-party applications:

    • [5.2/T-0-3] AV1

    Television device implementations MUST support the following video decoding formats and make them available to third-party applications:

  • 2.4.5. Security Model:

    See revision

    If device implementations have a secure lock screen and include one or more trust agent, which implements the TrustAgentService System API, they:

    • [9.11.1/W-1-1] MUST challenge the user for one of the recommended primary authentication methods (eg: PIN, pattern, password) more frequently than once every 72 hours.

  • 2.5.1. Hardware:

    See revision

    If device implementations include support for AM/FM broadcast radio and expose the functionality to any application, they:

    • [7.4.10/A-0-1] MUST declare support for FEATURE_BROADCAST_RADIO.

    An exterior view camera is a camera that images scenes outside of the device implementation, like the rearview camera.

    Automotive device implementations:

    • SHOULD include one or more exterior view cameras.

    If Automotive device implementations include an exterior view camera, for such a camera, they:

    • [7.5/A-1-1] MUST NOT have exterior view cameras accessible via the Android Camera APIs, unless they comply with camera core requirements.
    • [7.5/A-SR-1] Are STRONGLY RECOMMENDED not to rotate or horizontally mirror the camera preview.
    • [7.5/A-SR-2] Are STRONGLY RECOMMENDED to have a resolution of at least 1.3 megapixels.
    • SHOULD have either fixed-focus or EDOF (extended depth of field) hardware.
    • MAY have either hardware auto-focus or software auto-focus implemented in the camera driver.

    If automotive device implementations include one or more exterior view cameras, and load Exterior View System (EVS) service, then for such a camera, they:

    • [7.5/A-2-1] MUST NOT rotate or horizontally mirror the camera preview.

    Automotive device implementations:

    • MAY include one or more cameras that are available to third party applications.

    If automotive device implementations include at least one camera and make it available to third party applications then, they:

    • [7.5/A-3-1] MUST report the feature flag android.hardware.camera.any.
    • [7.5/A-3-2] MUST not declare the camera as a system camera.
    • MAY support external cameras described in section 7.5.3.
    • MAY include features (such as auto-focus, etc.) available to rear-facing cameras as described in section 7.5.1.

    A rear-facing camera means a world-facing camera which can be located at any place on the vehicle and is facing the outside of the vehicle cabin; that is, it images scenes on the far side of the vehicle body, like the rear-view camera.

    A front-facing camera means a user-facing camera which can be located at any place on the vehicle and is facing inside of the vehicle cabin; that is it images the user, such as for video conferencing and similar applications.

    Automotive device implementations:

    • [7.5/A-SR-1] Are STRONGLY RECOMMENDED to include one or more world-facing cameras.
    • MAY include one or more user-facing cameras.
    • [7.5/A-SR-2] Are STRONGLY RECOMMENDED to support concurrent streaming of multiple cameras.

    If Automotive device implementations include at least one camera which is world-facing then, for such a camera, they:

    • [7.5/A-1-1] MUST be oriented so that the long dimension of the camera aligns with the X-Y plane of Android automotive sensor axes.
    • [7.5/A-SR-3] Are STRONGLY RECOMMENDED to have either fixed-focus or EDOF (Extended Depth of Field) hardware.
    • [7.5/A-1-2] MUST have the primary world-facing camera as the world-facing camera with the lowest camera ID.

    If Automotive device implementations include at least one camera which is user-facing then, for such a camera:

    • [7.5/A-2-1] The primary user-facing camera MUST be the user-facing camera with the lowest camera ID.
    • MAY be oriented so that the long dimension of the camera aligns with the X-Y plane of Android automotive sensor axes.

    If Automotive device implementations include a camera which is accessible via either android.hardware.Camera or android.hardware.camera2 API, then they:

    • [7.5/A-3-1] MUST comply with the core camera requirements in section 7.5.

    If Automotive device implementations include a camera which is not accessible via either android.hardware.Camera or android.hardware.camera2 API, then they:

    • [7.5/A-4-1] MUST be accessible via Extended View System service.

    If Automotive device implementations include one or more cameras accessible via Extended View System Service, for such a camera, they:

    • [7.5/A-5-1] MUST NOT rotate or horizontally mirror the camera preview.
    • [7.5/A-SR-4] Are STRONGLY RECOMMENDED to have a resolution of at least 1.3 megapixel.

    If automotive device implementations include one or more cameras which are accessible via both Extended View System Service and android.hardware.Camera or android.hardware.Camera2 API then, for such a camera, they:

    • [7.5/A-6-1] MUST report the same Camera ID.

    If Automotive device implementations provide a proprietary camera API, they:

  • 2.5.3. Software:

    See revision

    Automotive device implementations:

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

  • 2.5.5. Security Model:

    See revision

    If Automotive device implementations declare android.hardware.microphone, they:

    • [9.8.2/A-1-1] MUST display the microphone indicator when an app is accessing audio data from the microphone, but not when the microphone is only accessed by HotwordDetectionService, SOURCE_HOTWORD, ContentCaptureService or apps holding the roles called out in section 9.1 with CDD identifier [C-4-X].
    • [9.8.2/A-1-2] MUST not hide the microphone indicator for system apps that have visible user interfaces or direct user interaction.
    • [9.8.2/A-1-3] MUST provide a user affordance to toggle the microphone in the Settings app.

    If Automotive device implementations declare android.hardware.camera.any, then they:

    • [9.8.2/A-2-1] MUST display the camera indicator when an app is accessing live camera data, but not when the camera is only being accessed by app(s) holding the roles as defined called out in Section 9.1 Permissions with CDD identifier [C-4-X][C-3-X].

    • [9.8.2/A-2-3] MUST provide a user affordance to toggle the camera in the Settings app.
    • [9.8.2/A-2-4] MUST display Recent and Active apps using camera as returned from PermissionManager.getIndicatorAppOpUsageData(), along with any attribution messages associated with them.

    If device implementations have a secure lock screen and include one or more trust agent, which implements the TrustAgentService System API, they:

    • [9.11.1/A-1-1] MUST challenge the user for one of the recommended primary authentication methods (eg: PIN, pattern, password) more frequently than once every 336 hours.

3. Software

  • 3.1. Managed API Compatibility:

    See revision

    Device implementations:

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

  • 3.2.3.5. Conditional Application Intents:

    See revision

    If device implementations report android.hardware.nfc.uicc or android.hardware.nfc.ese, they:

  • 3.3.1. Application Binary Interfaces:

    See revision

    Device implementations:

    • [C-0-12] MUST export function symbols for the core Vulkan 1.0 Vulkan 1.1 function symbols, 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.

  • 3.8.6. Themes:

    See revision

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

    • [C-1-5] MUST generate dynamic color tonal palettes using color theme styles enumerated in the Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES documentation (see android.theme.customization.theme_styles), namely TONAL_SPOT, VIBRANT, EXPRESSIVE, SPRITZ, RAINBOW, FRUIT_SALAD, andMONOCHROMATIC.

  • 3.8.8. Activity Switching:

    See revision

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

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

  • 3.9.2 Managed Profile Support:

    See revision

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

    • [C-1-10] MUST ensure that the screenshot data is saved in the work profile storage when a screenshot is captured with a topActivity window that has focus (the one the user interacted with last among all activities) and belongs to a work profile app.
    • [C-1-11] MUST NOT capture any other screen content (system bar, notifications or any personal profile content) except for the work profile application window/windows when saving a screenshot to the work profile (to ensure that personal profile data is not saved in the work profile).

  • 3.9.5 Device Policy Resolution Framework: New section

    See revision

    If device implementations report android.software.device_admin or android.software.managed_users, then they:

    • [C-1-1] MUST resolve device policy conflicts as documented in the AOSP documentation.

5. Multimedia Compatibility

  • 5.1.4. Image Encoding:

    See revision

    Device implementations MUST support encoding the following image encoding:

    • [C-0-4] AVIF
      • Devices must support BITRATE_MODE_CQ and Baseline Profile.

  • 5.1.5. Image Decoding:

    See revision

    Device implementations MUST support decoding the following image encoding:

    [C-0-7] AVIF (Baseline Profile)

  • 5.1.6. Image Codecs Details:

    See revision

    Format/Codec Details Supported File Types/Container Formats
    JPEG Base+progressive JPEG (.jpg)
    GIF GIF (.gif)
    PNG PNG (.png)
    BMP BMP (.bmp)
    WebP WebP (.webp)
    Raw ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
    HEIF Image, Image collection, Image sequence HEIF (.heif), HEIC (.heic)
    AVIF (Baseline Profile) Image, Image collection, Image sequence Baseline Profile HEIF container (.avif)

  • 5.1.8. Video Codecs List:

    See revision

    Format/Codec Details File Types/Container Formats to be supported
    H.263
    • 3GPP (.3gp)
    • MPEG-4 (.mp4)
    • Matroska (.mkv, decode only)
    H.264 AVC See section 5.2 and 5.3 for details
    • 3GPP (.3gp)
    • MPEG-4 (.mp4)
    • MPEG-2 TS (.ts, not seekable)
    • Matroska (.mkv, decode only)
    H.265 HEVC See section 5.3 for details
    • MPEG-4 (.mp4)
    • Matroska (.mkv, decode only)
    MPEG-2 Main Profile
    • MPEG2-TS (.ts, not seekable)
    • MPEG-4 (.mp4, decode only)
    • Matroska (.mkv, decode only)
    MPEG-4 SP
    • 3GPP (.3gp)
    • MPEG-4 (.mp4)
    • Matroska (.mkv, decode only)
    VP8 See section 5.2 and 5.3 for details
    VP9 See section 5.3 for details
    AV1 See section 5.2 and section 5.3 for details
    • MPEG-4 (.mp4)
    • Matroska (.mkv, decode only)

  • 5.1.10. Media Codec Characterization:

    See revision

    If device implementations support video codecs:

    • [C-2-1] All video codecs MUST publish achievable frame rate data for the following sizes if supported by the codec:
    SD (low quality) SD (high quality) HD 720p HD 1080p UHD
    Video resolution
    • 176 x 144 px (H263, MPEG2, MPEG4)
    • 352 x 288 px (MPEG4 encoder, H263, MPEG2)
    • 320 x 180 px (VP8, VP8)
    • 320 x 240 px (other)
    • 704 x 576 px (H263)
    • 640 x 360 px (VP8, VP9)
    • 640 x 480 px (MPEG4 encoder)
    • 720 x 480 px (other, AV1)
    • 1408 x 1152 px (H263)
    • 1280 x 720 px (other, AV1)
    1920 x 1080 px (other than MPEG4, AV1) 3840 x 2160 px (HEVC, VP9, AV1)

  • 5.2. Video Encoding:

    See revision

    If device implementations support any video encoder and make it available to third-party apps, they:

    • SHOULD NOT be, over two sliding windows, more than 15% over the bitrate between intraframe (I-frame) intervals.
    • SHOULD NOT be more than 100% over the bitrate over a sliding window of 1 second.

    If device implementations support any video encoder and make it available to third-party apps, and set the
    MediaFormat.KEY_BITRATE_MODE to BITRATE_MODE_VBR so that the encoder operates in Variable bitrate mode, then, as long as it does not impact the minimum quality floor, the encoded bitrate :

    • [C-5-1] MUST SHOULD NOT be, over one sliding window, more than 15% over the bitrate between intraframe (I-frame) intervals.
    • [C-5-2] MUST SHOULD NOT be more than 100% over the bitrate over a sliding window of 1 second.

    If device implementations support any video encoder and make it available to third-party apps and set the MediaFormat.KEY_BITRATE_MODE to BITRATE_MODE_CBR so the encoder operates in constant bitrate mode, then the encoded bitrate:

    • [C-6-1] MUST [C-SR-2] is STRONGLY RECOMMENDED to NOT be more than 15% over the target bitrate over a sliding window of 1 second.

  • 5.2.1. H.263:

    See revision

    If device implementations support H.263 encoders and make it available to third-party apps, they:

    • [C-1-1] MUST support QCIF resolution (176 x 144) using Baseline Profile Level 45. SQCIF resolution is optional.
    • SHOULD support dynamically configurable bitrates for the supported encoder.

  • 5.2.5. H.265:

    See revision

    If device implementations support H.265 codec, they:

    • [C-1-1] MUST support Main Profile Level 3 up to 512 x 512 resolution.
    • SHOULD support the HD encoding profiles as indicated in the following table.
    • [C-SR-1] are STRONGLY RECOMMENDED to support the 720 x 480 SD profile and the HD encoding profiles as indicated in the following table if there is a hardware encoder.

  • 5.2.6. AV1: new section

    See revision

    If device implementations support AV1 codec then, they:

    • [C-1-1] MUST support Main Profile including 8-bit and 10-bit content.
    • [C-1-2] MUST publish performance data i.e. report performance data via the getSupportedFrameRatesFor() or getSupportedPerformancePoints() APIs for supported resolutions in the table below.

    • [C-1-3] MUST accept HDR metadata and output it to the bitstream

    If AV1 encoder is hardware accelerated, then it:

    • [C-2-1] MUST support up to and including HD1080p encoding profile from the table below:
    SD HD 720p HD 1080p UHD
    Video resolution 720 x 480 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 px
    Video frame rate 30 fps 30 fps 30 fps 30 fps
    Video bitrate 5 Mbps 8 Mbps 16 Mbps 50 Mbps

  • 5.3.2. H.263:

    See revision

    If device implementations support H.263 decoders, they:

    • [C-1-1] MUST support Baseline Profile Level 30 (CIF, QCIF and SQCIF resolutions @ 30fps 384kbps) and Level 45 (QCIF and SQCIF resolutions @ 30fps 128kbps).

  • 5.3.9. AV1:

    See revision

    If device implementations support AV1 codec, they:

    • [C-1-1] MUST support Profile 0 including 10-bit content.

    If device implementations support AV1 codec and make it available to third-party applications, they:

    • [C-1-1] MUST support Main Profile including 8-bit and 10-bit content.

    If device implementations provide support for AV1 codec with a hardware accelerated decoder then they:

    • [C-2-1] MUST be able to decode at least HD 720p video decoding profiles from the table below when the height reported by Display.getSupportedModes() method is equal or greater than 720p.
    • [C-2-2] MUST be able to decode at least HD 1080p video decoding profiles from the table below when the height reported by Display.getSupportedModes() method is equal or greater than 1080p.
    SD HD 720p HD 1080p UHD
    Video resolution 720 x 480 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 px
    Video frame rate 30 fps 30 fps 30 fps 30 fps
    Video bitrate 5 Mbps 8 Mbps 16 Mbps 50 Mbps

    If device implementations support HDR Profile through the Media APIs, then they:

    • [C-3-1] MUST support extracting and outputting HDR metadata from the bitstream and/or container.
    • [C-3-2] MUST properly display HDR content on the device screen or on a standard video output port (for example, HDMI).

  • 5.4.2. Capture for Voice Recognition:

    See revision

    If device implementations declare android.hardware.microphone, they:

    • SHOULD set audio input sensitivity such that a 1000 Hz sinusoidal tone source played at 90 dB Sound Pressure Level (SPL) (measured at a distance of 30 cm from next to the microphone) yields an ideal response of RMS 2500 within a range of 1770 and 3530 for 16 bit-samples (or -22.35 db ±3dB Full Scale for floating point/double precision samples) for each and every microphone used to record the voice recognition audio source.

  • 5.5.2. Audio Effects:

    See revision

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

    • [C-1-4] MUST support audio effects with floating-point input and output.
    • [C-1-5] MUST make sure that audio effects support multiple channels up to the mixer channel count also known as FCC_LIMIT.

  • 5.6. Audio Latency:

    See revision

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

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

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

7. Hardware Compatibility

  • 7.1. Display and Graphics:

    See revision

    Android includes facilities that automatically adjust application assets and UI layouts appropriately for the device to ensure that third-party applications run well on a variety of hardware configurations. variety of hardware displays and configurations. An Android-compatible display is a display screen that implements all of the behaviors and APIs described in Android Developers - Screen compatibility overview, this section (7.1) and its subsections, as well as any additional device-type specific behaviors documented in section 2 of this CDD. On the Android-compatible display(s) where all third-party Android-compatible applications can run, device implementations MUST properly implement these APIs and behaviors, as detailed in this section.

    Start new requirements

    Device implementations:

    • [C-0-1] MUST, by default, render third party applications only onto Android-compatible displays.

    The units referenced by the requirements in this section are defined as follows:

    • physical diagonal size. The distance in inches between two opposing corners of the illuminated portion of the display.
    • dots per inch (dpi)density. The number of pixels encompassed by a linear horizontal or vertical span of 1”, expressed as pixels per inch (ppi or dpi). Where dpi ppi and dpi values are listed, both horizontal and vertical dpi must fall within the listed range.
    • aspect ratio. The ratio of the pixels of the longer dimension to the shorter dimension of the screen. For example, a display of 480x854 pixels would be 854/480 = 1.779, or roughly “16:9”.
    • density-independent pixel (dp). The A virtual pixel unit normalized to a 160 dpi screen screen density of 160. For some density d, and a number of pixels p, the number of density-independent pixels dp, is calculated as: pixels = dps * (density/160) dp = (160 / d) * p .

  • 7.1.1.1. Screen Size and Shape:

    See revision

    If device implementations support screens capable of the UI_MODE_TYPE_NORMAL size configuration and include Android-compatible use physical display(s) with rounded corners to render these screens, they:

    • [C-1-1] MUST ensure that at least one of the following requirements is met for each such display:
    • The radius of the rounded corners is less than or equal to 38 dp.
    • When a 15 dp by 15 dp box is anchored at each corner of the logical display, at least one pixel of each box is visible on the screen.

    • SHOULD include user affordance to switch to the display mode with the rectangular corners.

    Start new requirements

    If device implementations are only capable of NO_KEYS keyboard configuration, and intend to report support for the UI_MODE_TYPE_NORMAL ui mode configuration, they:

    • [C-4-1] MUST have a layout size, excluding any display cutouts, of at least 596 dp x 384 dp or greater.

    If device implementations include an Android-compatible display(s) that is foldable, or includes a folding hinge between multiple display panels and makes such display(s) available to render third-party apps, they:

    If device implementations include an Android-compatible display(s) that is foldable, or includes a folding hinge between multiple display panels and if the hinge or fold crosses a fullscreen application window, they:

    • [C-3-1] MUST report the position, bounds and state of hinge or fold through extensions or sidecar APIs to the application.

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

  • 7.1.1.2. Screen Aspect Ratio: removed

  • 7.1.1.3. Screen Density:

    See revision

    Device Implementations:

    • [C-0-1] By default, device implementations MUST report only one of the Android framework densities that are listed on DisplayMetrics through the DENSITY_DEVICE_STABLE API and this value must be a static value for each physical display MUST NOT change at any time; however, However the device MAY report a different arbitrary density DisplayMetrics.density according to the display configuration changes made by the user (for example, display size) set after initial boot.

    • Device implementations SHOULD define the standard Android framework density that is numerically closest to the physical density of the screen, unless that logical density pushes the reported screen size below the minimum supported. If the standard Android framework density that is numerically closest to the physical density results in a screen size that is smaller than the smallest supported compatible screen size (320 dp width), device implementations SHOULD report the next lowest standard Android framework density.

    Start new requirements

    • SHOULD define the standard Android framework density that is numerically closest to the physical density of the screen, or a value that would map to the same equivalent angular field-of-view measurements of a handheld device.

    If device implementations provide there is an affordance to change the display size of the device , they:

    • [C-1-1] The display size MUST NOT be scaled any MUST NOT scale the display larger than 1.5 times DENSITY_DEVICE_STABLE native density or produce an effective minimum screen dimension smaller than 320dp (equivalent to resource qualifier sw320dp), whichever comes first.
    • [C-1-2] Display size MUST NOT be scaled any MUST NOT scale the display smaller than 0.85 times the DENSITY_DEVICE_STABLE native density.

  • 7.1.4.2 Vulkan:

    See revision

    If device implementations include support for Vulkan 1.0 or higher, they:

    • [C-1-3] MUST fully implement the Vulkan 1.0 Vulkan 1.1 APIs for each enumerated VkPhysicalDevice.

    • [C-1-5] MUST NOT enumerate layers provided by libraries outside of the application package, or provide other ways of tracing or intercepting the Vulkan API, unless the application has the android:debuggable attribute set as true or the metadata com.android.graphics.injectLayers.enable set to true .

    • SHOULD support VkPhysicalDeviceProtectedMemoryFeatures and VK_EXT_global_priority.

    • [C-SR-5] Are STRONGLY RECOMMENDED to support VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory and VK_EXT_global_priority.

    • [C-SR-6] Are STRONGLY RECOMMENDED to use SkiaVk with HWUI.

    If device implementations include support for Vulkan 1.1 and declare any of the Vulkan feature flags described here , they:

    • [C-SR-7] Are STRONGLY RECOMMENDED to make the VK_KHR_external_fence_fd extension available to third-party applications and enable the application to export fence payload to and import fence payload from POSIX file descriptors as described here.

  • 7.3.10. Biometric Sensors:

    See revision

    If device implementations have multiple biometric sensors, they:

    • [C-7-1] MUST, when a biometric is in lockout (i.e. the biometric is disabled until the user unlocks with primary authentication) or time-bound lockout (i.e. the biometric is temporarily disabled until the user waits for a time interval) due to too many failed attempts, also lock out all other biometrics of a lower biometric class. In the case of time-bound lockout, the backoff time for biometric verification MUST be the maximum backoff time of all biometrics in time-bound lockout.

    • [C-SR-12] Are STRONGLY RECOMMENDED, when a biometric is in lockout (i.e. the biometric is disabled until the user unlocks with primary authentication) or time-bound lockout (i.e. the biometric is temporarily disabled until the user waits for a time interval) due to too many failed attempts, to also lock out all other biometrics of the same biometric class. In the case of time-bound lockout, the backoff time for biometric verification is STRONGLY RECOMMENDED to be the maximum backoff time of all biometrics in time-bound lockout.

    • [C-7-2] MUST challenge the user for the recommended primary authentication (eg: PIN, pattern, password) to reset the lockout counter for a biometric being locked out. Class 3 biometrics MAY be allowed to reset the lockout counter for a locked biometric of the same or lower class. Class 2 or Class 1 biometrics MUST NOT be allowed to complete a reset lockout operation for any biometrics.

    If device implementations wish to treat a biometric sensor as Class 1 (formerly Convenience), they:

    • [C-1-12] MUST have a spoof and imposter acceptance rate not higher than 40% per presentation attack instrument (PAI) species, as measured by the Android Biometrics Test Protocols.

    • [C-SR-13] Are STRONGLY RECOMMENDED to have a spoof and imposter acceptance rate not higher than 30% per presentation attack instrument (PAI) species, as measured by the Android Biometrics Test Protocols.

    • [C-SR-14] Are STRONGLY RECOMMENDED to disclose the biometric class of the biometric sensor and the corresponding risks of enabling it.

    • [C-SR-17] Are STRONGLY RECOMMENDED to implement the new AIDL interfaces (such as, IFace.aidl and IFingerprint.aidl).

    If device implementations wish to treat a biometric sensor as Class 2 (formerly Weak), they:

    • [C-SR-15] Are STRONGLY RECOMMENDED to have a spoof and imposter acceptance rate not higher than 20% per presentation attack instrument (PAI) species, as measured by the Android Biometrics Test Protocols.

    • [C-2-3] MUST perform the biometric matching in an isolated execution environment outside Android user or kernel space, such as the Trusted Execution Environment (TEE), or on a chip with a secure channel to the isolated execution environment or on Protected Virtual Machine that meets requirements in Section 9.17.
    • [C-2-4] MUST have all identifiable data encrypted and cryptographically authenticated such that they cannot be acquired, read or altered outside of the isolated execution environment or a chip with a secure channel to the isolated execution environment as documented in the implementation guidelines on the Android Open Source Project site or a Protected Virtual Machine controlled by hypervisor that meets requirements in Section 9.17.
    • [C-2-5] For camera based biometrics, while biometric based authentication or enrollment is happening:
      • MUST operate the camera in a mode that prevents camera frames from being read or altered outside the isolated execution environment or a chip with a secure channel to the isolated execution environment or a Protected Virtual Machine controlled by hypervisor that meets requirements in Section 9.17.
      • For RGB single-camera solutions, the camera frames CAN be readable outside the isolated execution environment to support operations such as preview for enrollment, but MUST still NOT be alterable.
    • [C-2-7] MUST NOT allow unencrypted access to identifiable biometric data or any data derived from it (such as embeddings) to the Application Processor outside the context of the TEE or the Protected Virtual Machine controlled by hypervisor that meets requirements in Section 9.17. Upgrading devices launched on Android version 9 or earlier are not exempted from C-2-7.

    If device implementations wish to treat a biometric sensor as Class 3 (formerly Strong), they:

    • [C-SR-16] Are STRONGLY RECOMMENDED to have a spoof and imposter acceptance rate not higher than 7% per presentation attack instrument (PAI) species, as measured by the Android Biometrics Test Protocols.

  • 7.3.13. IEEE 802.1.15.4 (UWB):

    See revision

    If device implementations include support for 802.1.15.4 and expose the functionality to a third-party application, they:

    • [C-1-2] MUST report the hardware feature flag android.hardware.uwb.
    • [C-1-3] MUST support all the following configuration sets (pre-defined combinations of FIRA UCI parameters) defined in the AOSP implementation.
      • CONFIG_ID_1: FiRa-defined unicast STATIC STS DS-TWR ranging, deferred mode, ranging interval 240 ms.
      • CONFIG_ID_2: FiRa-defined one-to-many STATIC STS DS-TWR ranging, deferred mode, ranging interval 200 ms. Typical use case: smart phone interacts with many smart devices.
      • CONFIG_ID_3: Same as CONFIG_ID_1, except Angle-of-arrival (AoA) data is not reported.
      • CONFIG_ID_4: Same as CONFIG_ID_1, except P-STS security mode is enabled.
      • CONFIG_ID_5: Same as CONFIG_ID_2, except P-STS security mode is enabled.
      • CONFIG_ID_6: Same as CONFIG_ID_3, except P-STS security mode is enabled.
      • CONFIG_ID_7: Same as CONFIG_ID_2, except P-STS individual controlee key mode is enabled.
    • [C-1-4] MUST provide a user affordance to allow the user to toggle the UWB radio on/off state.
    • [C-1-5] MUST enforce that apps using UWB radio hold the UWB_RANGING permission (under the NEARBY_DEVICES permission group).

    Passing the relevant conformance and certification tests defined by standard organizations, including FIRA, CCC and CSA helps ensure 802.1.15.4 functions correctly.

  • 7.4.1. Telephony:

    See revision

    “Telephony” as used by the Android APIs and this document refers specifically to hardware related to placing voice calls and sending SMS messages , or establishing mobile data via a mobile (e.g. GSM, CDMA, LTE, NR)GSM or CDMA network. A device supporting “Telephony” may choose to offer some or all of the call, messaging and data services as fits the product.

    via a GSM or CDMA network. While these voice calls may or may not be packet-switched,they are for the purposes of Android considered independent of any data connectivity that may be implemented using the same network. In other words,the Android “telephony” functionality and APIs refer specifically to voice calls and SMS. For instance, device implementations that cannot place calls or send/receive SMS messages are not considered a telephony device, regardless of whether they use a cellular network for data connectivity.

  • 7.4.2. IEEE 802.11 (Wi-Fi):

    See revision

    If device implementations include support for 802.11 and expose the functionality to a third-party application, they:

    • [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. For Android Television device implementations, even when in standby power states.

  • 7.4.3. Bluetooth:

    See revision

    If device implementations declare FEATURE_BLUETOOTH_LE, they:

    • [C-SR-2] Are STRONGLY RECOMMENDED to measure and compensate for Rx offset to ensure the median BLE RSSI is -60dBm +/-10 dB at 1m distance from a reference device transmitting at ADVERTISE_TX_POWER_HIGH, where devices are oriented such that they are on 'parallel planes' with screens facing the same direction.
    • [C-SR-3] Are STRONGLY RECOMMENDED to measure and compensate for Tx offset to ensure the median BLE RSSI is -60dBm +/-10 dB when scanning from a reference device positioned at 1m distance and transmitting at ADVERTISE_TX_POWER_HIGH, where devices are oriented such that they are on 'parallel planes' with screens facing the same direction.

    • [C-10-3] MUST measure and compensate for Rx offset to ensure the median BLE RSSI is -55dBm +/-10 dB at 1m distance from a reference device transmitting at ADVERTISE_TX_POWER_HIGH.
    • [C-10-4] MUST measure and compensate for Tx offset to ensure the median BLE RSSI is -55dBm +/-10 dB when scanning from a reference device positioned at 1m distance and transmitting at ADVERTISE_TX_POWER_HIGH.

    If device implementations support Bluetooth version 5.0, then they:

    • [C-SR-4] Are STRONGLY RECOMMENDED to provide support for:
    • LE 2M PHY
    • LE Codec PHY
    • LE Advertising Extension
    • Periodic advertising
    • At least 10 advertisement sets
    • At least 8 LE concurrent connections. Each connection can be in either connection topology roles.
    • LE Link Layer Privacy
    • A "resolving list" size of at least 8 entries

  • 7.4.9. UWB:

    See revision

    • [C-1-7] MUST ensure that the median of the distance measurements at 1m from the reference device is within [0.75m, 1.25m], where ground truth distance is measured from the top edge of the DUT. held face up and tilted 45 degrees.

  • 7.5.1. Rear-Facing Camera:

    See revision

    A rear-facing camera is a camera located on the side of the device opposite the display; that is, it images scenes on the far side of the device, like a traditional camera.

    A rear-facing camera is a world-facing camera that images scenes on the far side of the device, like a traditional camera; on handheld devices, that is a camera located on the side of the device opposite the display.

  • 7.5.2. Front-Facing Camera:

    See revision

    A front-facing camera is a camera located on the same side of the device as the display; that is, a camera typically used to image the user, such as for video conferencing and similar applications.

    A front-facing camera is a user-facing camera that is typically used to image the user, such as for video conferencing and similar applications; on handheld devices, that is a camera located on the same side of the device as the display.

  • 7.5.3. External Camera:

    See revision

    An external camera is a camera that can be physically attached or detached from the device implementation at any time and can face any direction; such as USB cameras.

  • 7.5.4. Camera API Behavior:

    See revision

    Device implementations MUST implement the following behaviors for the camera-related APIs, for all available cameras. Device implementations:

    • [C-SR-1] For devices with multiple RGB cameras in close proximity and facing in the same direction, it is STRONGLY RECOMMENDED to support a logical camera device that lists capability CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA, consisting of all of the RGB cameras facing that direction as physical sub-devices.

  • 7.5.5. Camera Orientation:

    See revision

    Devices that fulfill all of the following criteria are exempt from the requirement above:

    • Device implementations that are not capable of being rotated by the user such as automotive devices.

  • 7.10. Haptics:

    See revision

    Devices intended to be hand-held or worn may include a general purpose haptic actuator, available to applications for purposes including getting attention through ringtones, alarms, notifications, as well as general touch feedback.

    If device implementations DO NOT include such a general purpose haptic actuator, they:

    • [7.10/C] MUST return false for Vibrator.hasVibrator().

    If device implementations DO include at least one such general purpose haptic actuator, they:

    If device implementations follow the haptic constants mapping, they:

    See Section 2.2.1 for device-specific requirements.

9. Security Model Compatibility

  • 9.1. Permissions:

    See revision

    Device implementations:

    • [C-0-4] MUST have one and only one implementation of both user interfaces.

    If device implementations pre-install any packages that hold any of the System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence, or System Visual Intelligence roles, the packages:

    • [C-4-1] MUST fulfill all requirements outlined for device implementations in sections "9.8.6 Content Capture" "9.8.6 OS-level and ambient data and 9.8.15 Sandboxed API implementations".

    • [C-4-2] MUST NOT have android.permission.INTERNET permission. This is stricter than the STRONGLY RECOMMENDED listed in section 9.8.6.
    • [C-4-3] MUST NOT bind to other apps, except for the following system apps: Bluetooth, Contacts, Media, Telephony, SystemUI, and components providing Internet APIs. This is stricter than the STRONGLY RECOMMENDED listed in section 9.8.6.

    If device implementations include a default application to support the VoiceInteractionService they:

    • [C-5-1] MUST NOT grant ACCESS_FINE_LOCATION as the default for that application.

  • 9.5. Multi-User Support:

    See revision

    If device implementations create the additional user profile discussed above, then they:

    • [C-4-5] MUST visually distinguish the dual instance application icons when the icons are presented to users.
    • [C-4-6] MUST provide a user-affordance to delete entire clone profile data.
    • [C-4-7] MUST uninstall all Clone apps, delete the private app data directories and their content, and delete Clone profile data, when the user chooses to delete entire Clone profile data.
    • SHOULD prompt the user to delete entire Clone Profile data when the last clone app is deleted.
    • [C-4-8] MUST inform the user that app data will be deleted when the clone application is uninstalled, or provide an option to users to keep app data when the application is uninstalled from the device.
    • [C-4-9] MUST delete the private app data directories and their content, when the user chooses to delete the data during uninstall.

    • [C-4-14] MUST have separate permission and storage management for the applications running in this additional profile

    • [C-4-5] MUST only allow applications in the additional profile that have a launcher activity to access contacts that are already accessible to the parent user profile.

  • 9.7. Security Features:

    See revision

    A Memory Safety technology is a technology that mitigates at least the following classes of bugs with a high (> 90%) probability in applications that use the android:memtagMode manifest option:

    • heap buffer overflow
    • use after free
    • double free
    • wild free (free of a non-malloc pointer)

    Device implementations:

    • [C-SR-15] Are STRONGLY RECOMMENDED to set ro.arm64.memtag.bootctl_supported.

    If device implementations set the system property ro.arm64.memtag.bootctl_supported to true, they:

    • [C-3-1] MUST allow the system property arm64.memtag.bootctl to accept a comma-separated list of the following values, with the desired effect applied on the next subsequent reboot:

      • memtag: a Memory Safety technology as defined above is enabled
      • memtag-once: a Memory Safety technology as defined above is transiently enabled, and is automatically disabled upon, next reboot
      • memtag-off: a Memory Safety technology as defined above is disabled
    • [C-3-2] MUST allow the shell user to set arm64.memtag.bootctl.

    • [C-3-3] MUST allow any process to read arm64.memtag.bootctl.

    • [C-3-4] MUST set arm64.memtag.bootctl to the currently requested state upon boot, it MUST also update the property, if the device implementation allows to modify the state without changing the system property.

    • [C-SR-16] Are STRONGLY RECOMMENDED to show a Developer Setting that sets memtag-once and reboots the device. With a compatible bootloader, the Android Open Source Project meets the above requirements through the MTE bootloader protocol.

    • [C-SR-17] Are STRONGLY RECOMMENDED to show a Setting in the Security Settings menu that allows the user to enable memtag.

  • 9.8.2. Recording:

    See revision

    Device implementations:

    • [C-0-2] MUST display a user warning and obtain explicit user consent allowing any sensitive information that is displayed on the user’s screen to be capturedenabled that includes exactly the same message as AOSP whenever each and every time a session to capture the screen casting or screen recording is enabled started via the MediaProjection.createVirtualDisplay(), VirtualDeviceManager.createVirtualDisplay(), or proprietary APIs. MUST NOT provide users an affordance to disable future display of the user consent.

    • [C-SR-1] Are STRONGLY RECOMMENDED to display a user warning which is exactly the same message as implemented in AOSP but CAN be altered as long as the message clearly warns the user that any sensitive information on the user’s screen is captured.

    • [C-0-4] MUST NOT provide users an affordance to disable future prompts of the user consent to capture the screen, unless the session is started by a system app that the user has allowed to associate() with the android.app.role.COMPANION_DEVICE_APP_STREAMING or the android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING device profile.

  • 9.8.6. OS-level and ambient data: This section was renamed from Content Capture and App Search to OS-level and ambient data.

    See revision

    Android, through the System APIs ContentCaptureService, AugmentedAutofillService, AppSearchGlobalManager.query, or by other proprietary means, supports a mechanism for device implementations to capture the following application data interactions between the applications and the user sensitive data:

    • Any screen or other data sent via the AugmentedAutofillService to the system.
    • Any screen or other data accessible via Content Capture API.
    • Any screen or other data accessible via FieldClassificationService API
    • Any application data passed to the system via the AppSearchManager API and accessible via AppSearchGlobalManager.query.

    • Any other events that an application provides to the system via the Content Capture API or or AppSearchManager API a similarly capable Android and proprietary API.

    • Audio data obtained as a result of using SpeechRecognizer#onDeviceSpeechRecognizer() by the Speech Recognizer Implementation.
    • Audio data obtained in background (continuously) through AudioRecord, SoundTrigger or other Audio APIs, and not resulting in a user-visible indicator
    • Camera data obtained in background (continuously) through CameraManager or other Camera APIs, and not resulting in a user-visible indicator

    If device implementations capture any of the data above, they:

    • [C-1-3] MUST only send all such data and the log off the device using a privacy-preserving mechanism, except with explicit user consent every time the data is shared. The privacy-preserving mechanism is defined as “those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users”, to prevent any per-user data being introspectable (e.g., implemented using a differential privacy technology such as RAPPOR).

    • [C-1-5] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.6 Content Capture OS-level and ambient data), except with explicit user consent every time it is shared. Unless such functionality is built as an Android SDK API (AmbientContext, HotwordDetectionService).

    • [C-1-6] MUST provide user affordance to erase such data that the ContentCaptureService implementation or the proprietary means collects if when the data is stored in any form on the device. If the user chooses to erase the data, MUST remove all collected historical data.

    • [C-SR-3] Are STRONGLY RECOMMENDED to be implemented with Android SDK API or a similar OEM-owned open-source repository; and / or be performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementations).

    Android, through SpeechRecognizer#onDeviceSpeechRecognizer() provides ability to perform speech recognition on the device, without involving the network. Any implementation of on-device SpeechRecognizer MUST follow the policies outlined in this section.

  • 9.8.10. Connectivity Bug Report:

    See revision

    If device implementations declare the android.hardware.telephony feature flag, they:

    • [C-1-4] Reports generated using BUGREPORT_MODE_TELEPHONY MUST contain at least the following information:
      • SubscriptionManagerService dump

  • 9.8.14. Credential Manager: Removed

  • 9.8.15. Sandboxed API Implementations: New section

    See revision

    Android, through a set of delegate APIs provides a mechanism to process secure OS-level and ambient data. Such processing can be delegated to a preinstalled apk with privileged access and reduced communication capabilities, known as a Sandboxed API Implementation.

    Any Sandboxed API implementation:

    • [C-0-1] MUST NOT request the INTERNET permission.
    • [C-0-2] MUST only access the internet through structured APIs backed by publicly available open-source implementations using privacy-preserving mechanisms, or indirectly via Android SDK APIs. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (e.g., implemented using a differential privacy technology such as RAPPOR).
    • [C-0-3] MUST keep the services separate from other system components (e.g. not binding the service or sharing process IDs) except for the following:
      • Telephony, Contacts, System UI, and Media
    • [C-0-4] MUST NOT allow users to replace the services with a user-installable application or service
    • [C-0-5] MUST only allow the preinstalled services to capture such data. Unless the replacement capability is built into AOSP (e.g. for Digital Assistant Apps).
    • [C-0-6] MUST NOT allow any apps other than the preinstalled services mechanism to be able to capture such data. Unless such capture capability is implemented with an Android SDK API.
    • [C-0-7] MUST provide user affordance to disable the services.
    • [C-0-8] MUST NOT omit user affordance to manage Android permissions that are held by the services and follow the Android permissions model as described in Section 9.1. Permission.

  • 9.8.16. Continuous Audio and Camera data: New section

    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:

    • [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as per section 9.8.2 Recording), unless:
    • [C-SR-1] Is STRONGLY RECOMMENDED to require user consent for every functionality utilizing such data, and be disabled by default.
    • [C-SR-2] STRONGLY RECOMMENDED to apply the same treatment (i.e. follow the restrictions outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, 9.8.15 Sandboxed API implementations, and 9.8.16 Continuous Audio and Camera data) to Camera data coming from a remote wearable device.

    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:

    • [C-1-1] MUST indicate to the remote wearable device to display an additional indicator there.

    If devices provide capability to engage with a Digital Assistant Application without the assigned keyword (either handling generic user queries, or analyzing user presence through camera):

    • [C-2-1] MUST ensure such implementation is provided by a package holding the android.app.role.ASSISTANT role.
    • [C-2-2] MUST ensure such implementation utilizes HotwordDetectionService and/or VisualQueryDetectionService Android APIs.

  • 9.8.17. Telemetry: New section

    See revision

    Android stores system and app logs using StatsLog APIs. These logs are managed via StatsManager APIs which can be used by privileged system applications.

    StatsManager also provides a way to collect data categorized as privacy sensitive from devices with a privacy preserving mechanism. In particular, StatsManager::query API provides the ability to query restricted metric categories defined in StatsLog.

    Any implementation querying and collecting restricted metrics from StatsManager:

    • [C-0-1] MUST be the sole application/implementation on the device and hold the READ_RESTRICTED_STATS permission.
    • [C-0-2] MUST only send telemetry data and the log of the device using a privacy-preserving mechanism. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (e.g., implemented using a differential privacy technology such as RAPPOR).
    • [C-0-3] MUST NOT associate such data with any user identity (such as Account) on the device.
    • [C-0-4] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.17 Privacy-preserving Telemetry).
    • [C-0-5] MUST provide a user affordance to enable/disable privacy-preserving telemetry collection, use, and sharing.
    • [C-0-6] MUST provide user affordance to erase such data that the implementation collects if the data is stored in any form on the device. If the user chose to erase the data, MUST remove all data currently stored on the device.
    • [C-0-7] MUST disclose underlying privacy-preserving protocol implementation in an open source repository.
    • [C-0-8 ]MUST enforce data egress policies in this section to gate collection of data in restricted metric categories defined in StatsLog.

  • 9.10. Device Integrity:

    See revision

    Device implementations

    If device implementations have the ability to verify file content on the per-page basis, then they:

    • [C-0-3 C-2-1] support cryptographically verifying file content against a trusted key without reading the whole file.

    • [C-0-4 C-2-2] MUST NOT allow the read requests on a protected file to succeed when the read content do not verify against a trusted key is not verified per [C-2-1] above.

    • [C-2-4] MUST return file checksum in O(1) for enabled files.

  • 9.11. Keys and Credentials:

    See revision

    The Android Keystore System allows app developers to store cryptographic keys in a container and use them in cryptographic operations through the KeyChain API or the Keystore API. Device implementations:

    • [C-0-3] MUST limit the number of failed primary authentication attempts.
    • [C-SR-2] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.

    If device implementations add or modify the authentication methods to unlock the lock screen if based on a known secret and use a new authentication method to be treated as a secure way to lock the screen, then:

    • [C-SR-3] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
    • [C-2-1] A PIN of a length less than 6 digits MUST NOT allow automatic entry without user interaction to avoid revealing the PIN length.

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

    See revision

    Device implementations:

    • [C-0-1] MUST limit the number of failed primary authentication attempts.
    • [C-SR-5] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.

    If device implementations set a numerical PIN as the recommended primary authentication method, then:

    • [C-SR-6] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
    • [C-SR-7] A PIN of a length less than 6 digits is STRONGLY RECOMMENDED NOT to allow automatic entry without user interaction to avoid revealing the PIN length.

    If device implementations have a secure lock screen and include one or more trust agent, which implements the TrustAgentService System API, they:

    [C-7-8] The user MUST be challenged for one of the recommended primary authentication (eg: PIN, pattern, password) methods at least once every 72 hours or less unless the safety of the user (e.g. driver distraction) is of concern.

    If device implementations allow applications to create secondary virtual displays and support associated input events such as via VirtualDeviceManager and the displays are not marked with VIRTUAL_DISPLAY_FLAG_SECURE, they:

    [C-13-10] MUST disable installation of apps initiated from virtual devices.

  • 9.17. Android Virtualization Framework:

    See revision

    If the device implements support for the Android Virtualization Framework APIs (android.system.virtualmachine.*), the Android host:

    • [C-1-1] MUST support all the APIs defined by the android.system.virtualmachine package.
    • [C-1-2] MUST NOT modify the Android SELinux and permission model for the management of Protected Virtual Machines (pVM).

    • [C-1-3] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow rules present.

    • [C-1-4] MUST only allow platform signed code & privileged appsMUST NOT allow untrusted code (e.g. 3p apps) to create and run a Protected Virtual Machine pVM . Note: This might change in future Android releases.

    • [C-1-5] MUST NOT allow a Protected Virtual Machine pVM to execute code that is not part of the factory image or their updates. Anything that is not covered by Android Verified Boot (e.g. files downloaded from the Internet or sideloaded) MUST NOT be allowed to be run in a Protected Virtual Machine .

    • [C-1-5] MUST only allow a non-debuggable pVM to execute code from the factory image or their platform updates which also includes any updates to privileged apps.

    If the device implements support for the Android Virtualization Framework APIs (android.system.virtualmachine.*), then any Protected Virtual Machine pVM instance:

    • [C-2-1] MUST be able to run all operating systems available in the virtualization APEX in a Protected Virtual Machine pVM .
    • [C-2-2] MUST NOT allow a Protected Virtual Machine pVM to run an operating system that is not signed by the device implementor or OS vendor.
    • [C-2-3] MUST NOT allow a Protected Virtual Machine pVM to execute data as code (e.g. SELinux neverallow execmem).

    • [C-2-4] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy/microdroid provided in the upstream Android Open Source Project (AOSP).

    • [C-2-5] MUST implement Protected Virtual Machine pVM defense-in-depth mechanisms (e.g. SELinux for pVMs) even for non-Microdroid operating systems.
    • [C-2-6] MUST ensure that the pVM fails firmware refuses to boot if it cannot verify the initial images that the VM will run cannot be verified. The verification MUST be done inside the VM.
    • [C-2-7] MUST ensure that the pVM fails firmware refuses to boot if the integrity of the instance.img is compromised.

    If the device implements support for the Android Virtualization Framework APIs (android.system.virtualmachine.*), then the hypervisor:

    • [C-3-1] MUST ensure that memory pages exclusively owned by a VM (either pVM or host VM) are accessible only to the virtual machine itself or the hypervisor, not by other virtual machines - either protected or non-protected. MUST NOT allow any pVM to have access to a page belonging to another entity (i.e. other pVM or hypervisor), unless explicitly shared by the page owner. This includes the host VM. This applies to both CPU and DMA accesses.
    • [C-3-2] MUST wipe a page after it is used by a pVM and before it is returned to the host (e.g. the pVM is destroyed).
    • [C-3-3SR-1] Is STRONGLY RECOMMENDED to ensure MUST ensure that that the pVM firmware is loaded and executed prior to any code in a pVM.
    • [C-3-4] MUST ensure that each VM derives a per-VM secret which {Boot Certificate Chain (BCC) and Compound Device Identifier (CDIs) provided to a pVM instance can only be derived by that particular VMinstance and changes upon factory reset and OTA.

    If the device implements support for the Android Virtualization Framework APIs, then across all areas:

    • [C-4-1] MUST NOT provide functionality to a pVM that allows bypassing the Android Security Model.

    If the device implements support for the Android Virtualization Framework APIs, then:

    • [C-5-1] MUST be capable to support Isolated Compilation but may disable Isolated Compilation feature on the device shipment of an ART runtime update.

    If the device implements support for the Android Virtualization Framework APIs, then for Key Management:

    • [C-6-1] MUST root DICE chain at a point that the user cannot modify, even on unlocked devices. (To ensure it cannot be spoofed).

    • [C-SR-26-2] Is STRONGLY RECOMMENDED to use DICE as the per-VM secret derivation mechanism. MUST do DICE properly i.e. provide the correct values.

Back to top