Android 14
June 26, 2024
2. Device Types
-
See revision
- [7.6.1/H-1-1] MUST only support a single ABI (either 64-bit only or 32-bit only).
See revision
Start new requirements
If handheld device implementations include support for Vulkan, they:
- [7.1.4.2/H-1-1] MUST satisfy the requirements specified by the Android Baseline 2021 profile.
-
See revision
Start new requirements
If Watch device implementations include support for Vulkan, they:
- [7.1.4.2/W-1-1] MUST satisfy the requirements specified by the Android Baseline 2021 profile.
-
See revision
Start new requirements
If Automotive device implementations include support for Vulkan, they:
- [7.1.4.2/A-1-1] MUST satisfy the requirements specified by the Android Baseline 2021 profile.
3. Software
-
For the ODM_SKU parameter:
See revision
The value of this field MUST be encodable as 7-bit ASCII and match the regular expression
^([0-9A-Za-z.,_-]+)$
.
5. Multimedia Compatibility
-
Added details for the Vorbis format/codec:
See revision
Decoding: Support for mono, stereo, 5.0 and 5.1 content with sampling rates of 8000, 12000, 16000, 24000, and 48000 Hz.
Encoding: Support for mono and stereo content with sampling rates of 8000, 12000, 16000, 24000, and 48000 Hz.
7. Hardware Compatibility
-
See revision
- [C-1-13] MUST satisfy the requirements specified by the Android Baseline 2021 profile.
-
Removal of:
See revision
- SHOULD NOT implement AOAv2 audio documented in the Android Open Accessory Protocol 2.0 documentation. AOAv2 audio is deprecated as of Android version 8.0 (API level 26).
9. Security Model Compatibility
-
Renumbered [C-SR-1] to [C-SR-7] to remove duplicate content,and removed [C-SR-8]:
See revision
[C-SR-1] STRONGLY RECOMMENDED to keep kernel data which is written only during initialization marked read-only after initialization (e.g.
__ro_after_init
).[C-SR-2] Are STRONGLY RECOMMENDED to randomize the layout of the kernel code and memory, and to avoid exposures that would compromise the randomization (e.g.
CONFIG_RANDOMIZE_BASE
with bootloader entropy via the/chosen/kaslr-seed Device Tree node
orEFI_RNG_PROTOCOL
).[C-SR-3] Are STRONGLY RECOMMENDED to enable control flow integrity (CFI) in the kernel to provide additional protection against code-reuse attacks (e.g.
CONFIG_CFI_CLANG
andCONFIG_SHADOW_CALL_STACK
).[C-SR-4] Are STRONGLY RECOMMENDED not to disable Control-Flow Integrity (CFI), Shadow Call Stack (SCS) or Integer Overflow Sanitization (IntSan) on components that have it enabled.
[C-SR-5] Are STRONGLY RECOMMENDED to enable CFI, SCS, and IntSan for any additional security-sensitive userspace components as explained in CFI and IntSan.
[C-SR-6] Are STRONGLY RECOMMENDED to enable stack initialization in the kernel to prevent uses of uninitialized local variables (
CONFIG_INIT_STACK_ALL
orCONFIG_INIT_STACK_ALL_ZERO
). Also, device implementations SHOULD NOT assume the value used by the compiler to initialize the locals.[C-SR-7] Are STRONGLY RECOMMENDED to enable heap initialization in the kernel to prevent uses of uninitialized heap allocations (
CONFIG_INIT_ON_ALLOC_DEFAULT_ON
) and they SHOULD NOT assume the value used by the kernel to initialize those allocations.
-
See revision
- [C-1-6] MUST support one of the following:
- IKeymasterDevice 3.0,
- IKeymasterDevice 4.0,
- IKeymasterDevice 4.1,
- IKeyMintDevice version 1, or
- IKeyMintDevice version 2.
- [C-1-6] MUST support one of the following:
9.11.1. Secure Lock Screen, Authentication and Virtual Devices:
See revision
- [C-8-3] They MUST NOT expose an API for use by third-party apps to change the lock state.
See revision
- [C-12-4] MUST call
TrustManagerService.revokeTrust()
- After a maximum of 24 hours from granting trust, or
- After an 8 hour idle window, or
- If the implementations are not using cryptographically secure and accurate ranging as defined in [C-12-5], when the underlying connection to the proximate physical device is lost.
- [C-12-5] Implementations relying on secure and accurate ranging to meet the
requirements of [C-12-4] MUST use one of the following solutions:
- Implementations using UWB:
- MUST meet the conformance, certification, accuracy, and calibration requirements for UWB described in 7.4.9.
- MUST use one of the P-STS security modes listed in 7.4.9.
- Implementations using Wi-Fi Neighborhood Awareness Networking (NAN):
- MUST meet the accuracy requirements in 2.2.1 [7.4.2.5/H-SR-1], use the 160 MHz bandwidth (or higher), and follow the measurement setup steps specified in Presence Calibration.
- MUST use Secure LTF as defined in IEEE 802.11az.
- Implementations using UWB:
April 8, 2024
2. Device Types
-
See revision
Start new requirements
If Handheld device implementations declare
FEATURE_BLUETOOTH_LE
, they:- [7.4.3/H-1-3] MUST measure and compensate for Rx
offset to ensure the median BLE RSSI is -50dBm +/-15 dB at 1m distance from
a reference device transmitting at
ADVERTISE_TX_POWER_HIGH
. - [7.4.3/H-1-4] MUST measure and compensate for Tx
offset to ensure the median BLE RSSI is -50dBm +/-15 dB when scanning from a
reference device positioned at 1m distance and transmitting at
ADVERTISE_TX_POWER_HIGH
.
- [7.4.3/H-1-3] MUST measure and compensate for Rx
offset to ensure the median BLE RSSI is -50dBm +/-15 dB at 1m distance from
a reference device transmitting at
-
See revision
If Handheld device implementations support the System API
HotwordDetectionService
or another mechanism for hotword detection without mic access indication, they:- [9.8/H-1-6] MUST NOT allow more than 100 bytes of data to be transmitted out of the hotword detection service on each successful hotword result except for audio data passed through HotwordAudioStream.
See revision
Change [9.8/H-1-13] to:
- [9.8/H-SR-3] Are STRONGLY RECOMMENDED to restart the process hosting the hotword detection service at least once every hour or every 30 hardware-trigger events, whichever comes first.
See revision
Removed requirements [9.8.2/H-4-3], [9.8.2/H-4-4], [9.8.2/H-5-3].
-
See revision
If Handheld device implementations return
android.os.Build.VERSION_CODES.U
forandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, then they:- [7.5/H-1-3] MUST support
android.info.supportedHardwareLevel
property asFULL
or better for back primary andLIMITED
or better for front primary camera.
- [7.5/H-1-3] MUST support
-
See revision
If Television device implementations do not have a built in display, but instead support an external display connected via HDMI, they:
- [5.8/T-0-1] MUST set the HDMI
output mode to the highest resolution for the chosen pixel format that works
with 50Hz or 60Hz refresh rate for the external display, depending on the video
refresh rate for the region the device is sold in.
MUST set the HDMI output mode to select the maximum resolution that can be supported with either a 50Hz or 60Hz refresh rate.
- [5.8/T-0-1] MUST set the HDMI
output mode to the highest resolution for the chosen pixel format that works
with 50Hz or 60Hz refresh rate for the external display, depending on the video
refresh rate for the region the device is sold in.
3. Software
3.5.1. Application Restriction:
See revision
- Removed requirement [C-1-9]
5. Multimedia Compatibility
-
See revision
If device implementations declare support for the Dolby Vision decoder through
HDR_TYPE_DOLBY_VISION
, they:- [C-1-3] MUST set the track ID of backward-compatible base-layer(s) (if present) to be the same as the combined Dolby Vision layer's track ID.
7. Hardware Compatibility
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 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:
- When
a 15an 18 dp by1518 dp box is anchored at each corner of the logical display, at least one pixel of each box is visible on the screen.
- When
- [C-1-1] MUST ensure that at least one of the following requirements
is met for each such display:
-
See revision
Reinstated the following requirements:
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.
See revision
Moved requirements [C-10-3] and [C-10-4] to 2.2.1. Hardware.
- [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
.
November 20, 2023
2. Device Types
-
See revision
If Handheld device implementations declare support of any 64-bit ABI (with or without any 32-bit ABI):
-
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.
- [7.5/H-1-13] MUST support
-
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.
-
See revision
- [9/W-0-1] MUST declare the
android.hardware.security.model.compatible feature
.
- [9/W-0-1] MUST declare the
6. Developer Tools and Options Compatibility
-
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
- [C-0-12] MUST write a
9. Security Model Compatibility
-
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
-
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.
- Have a physical diagonal screen size in the range of
4 inches
-
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
andandroid.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:
- [7.10/H]* SHOULD NOT use an eccentric rotating mass (ERM) haptic actuator (vibrator).
- [7.10/H]* SHOULD implement all public constants for clear haptics in android.view.HapticFeedbackConstants namely (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, LONG_PRESS, TEXT_HANDLE_MOVE, VIRTUAL_KEY, VIRTUAL_KEY_RELEASE, CONFIRM, REJECT, GESTURE_START and GESTURE_END).
- [7.10/H]* SHOULD implement all public constants for
clear haptics
in android.os.VibrationEffect
namely (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK and
EFFECT_DOUBLE_CLICK) and all feasible public
PRIMITIVE_*
constants for rich haptics in android.os.VibrationEffect.Composition namely (CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD). Some of these primitives, such as LOW_TICK and SPIN may only be feasible if the vibrator can support relatively low frequencies. - [7.10/H]* SHOULD follow the guidance for mapping public constants in android.view.HapticFeedbackConstants to the recommended android.os.VibrationEffect constants, with the corresponding amplitude relationships.
- [7.10/H]* SHOULD follow quality assessment for createOneShot() and createWaveform() APIs.
- [7.10/H]* SHOULD verify that the result of the public android.os.Vibrator.hasAmplitudeControl() API correctly reflects their vibrator’s capabilities.
- [7.10/H]* SHOULD position the placement of the actuator near the location where the device is typically held or touched by hands.
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
portraitorientation.
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.
- [7.1.1.1/H-0-1] MUST have at least one
-
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
-
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
andControl
APIs and allow third-party applications to publish device controls, then they:- [3.8.16/H-1-6] Device implementations
MUST accurately render the user affordance as follows:
- If the device has set
config_supportsMultiWindow=true
and the app declares the metadataMETA_DATA_PANEL_ACTIVITY
in theControlsProviderService
declaration, including the ComponentName of a valid activity (as defined by the API), then the app MUST embed said activity in this user affordance. - If the app does not declare metadata
META_DATA_PANEL_ACTIVITY
, then it MUST render the specified fields as provided by theControlsProviderService
API as well as any specified fields provided by the Control APIs.
- If the device has set
- [3.8.16/H-1-7] If the app declares the metadata
META_DATA_PANEL_ACTIVITY
, it MUST pass the value of the setting defined in [3.8.16/H-1-5] usingEXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS
when launching the embedded activity.
If device implementations allow users to place calls of any sort, they
- [7.4.1.2/H-0-1] MUST declare the feature flag
android.software.telecom
. - [7.4.1.2/H-0-2] MUST implement the telecom framework.
-
See revision
Handheld device implementations:
- [8.5/H-0-1] MUST provide
a user affordance
in the Settings menuto 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-1] MUST provide
a user affordance
- [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.
See revision
If device implementations declare support for android.hardware.telephony
,
they:
- [9.5/H-1-1] MUST NOT set
UserManager.isHeadlessSystemUserMode
totrue
.
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
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 bySpeechRecognizer#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 bySpeechRecognizer#createOnDeviceSpeechRecognizer()
). - [9.8/H-3-2] MUST NOT allow any audio or video information to be transmitted
out of the
VisualQueryDetectionService
, except toContentCaptureService
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.
See revision
If Handheld device implementations return android.os.Build.VERSION_CODES.T
for android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
, then they:
- MUST meet the media requirements listed in Android 13 CDD section 2.2.7.1.
Start new requirements
If Handheld device implementations returnandroid.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()
andVideoCapabilities.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()
andVideoCapabilities.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()
andVideoCapabilities.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
orAUDIO_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 theFeature_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.
See revision
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
900ms 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
andandroid.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.
See revision
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.
See revision
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.
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:
- [5.3.2/T-0-7] AV1
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.
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 forFEATURE_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:
- [7.5/A-7-1] MUST implement such a camera API using
android.hardware.camera2
API or Extended View System API.
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.
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 outin Section 9.1 Permissions with CDD identifier [C-4-X][C-3-X].
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
orandroid.hardware.nfc.ese
, they:- [C-19-1] MUST implement the NfcAdapter.ACTION_TRANSACTION_DETECTED Intent API (as “EVT_TRANSACTION” defined by the GSM Association technical specification TS.26 - NFC Handset Requirements).
3.3.1. Application Binary Interfaces:
See revision
Device implementations:
- [C-0-12] MUST export function symbols for the core
Vulkan 1.0Vulkan 1.1 function symbols, as well as theVK_KHR_surface
,VK_KHR_android_surface
,VK_KHR_swapchain
,VK_KHR_maintenance1
, andVK_KHR_get_physical_device_properties2
extensions through thelibvulkan.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.
- [C-0-12] MUST export function symbols for the core
-
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 (seeandroid.theme.customization.theme_styles
), namelyTONAL_SPOT
,VIBRANT
,EXPRESSIVE
,SPRITZ
,RAINBOW
,FRUIT_SALAD
, andMONOCHROMATIC
.
- [C-1-5] MUST generate dynamic color tonal palettes using color theme styles
enumerated in the
-
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).
- [C-1-10] MUST ensure that the screenshot data is saved in the work profile
storage when a screenshot is captured with a
3.9.5 Device Policy Resolution Framework: New section
See revision
If device implementations report
android.software.device_admin
orandroid.software.managed_users
, then they:- [C-1-1] MUST resolve device policy conflicts as documented in the AOSP documentation.
5. Multimedia Compatibility
-
See revision
Device implementations MUST support encoding the following image encoding:
- [C-0-4] AVIF
- Devices must support
BITRATE_MODE_CQ
and Baseline Profile.
- Devices must support
- [C-0-4] AVIF
-
See revision
Device implementations MUST support decoding the following image encoding:
[C-0-7] AVIF (Baseline Profile)
-
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) -
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 - WebM (.webm)
- Matroska (.mkv)
VP9 See section 5.3 for details - WebM (.webm)
- Matroska (.mkv)
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) -
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
toBITRATE_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] MUSTSHOULD NOT be, over one sliding window, more than 15% over the bitrate between intraframe (I-frame) intervals.[C-5-2] MUSTSHOULD 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
toBITRATE_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.
-
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.
-
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()
orgetSupportedPerformancePoints()
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 -
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).
-
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 fromnext 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.
- SHOULD set audio input sensitivity such that a 1000 Hz sinusoidal tone source
played at 90 dB Sound Pressure Level (SPL) (measured
-
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.
-
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 forAAUDIO_PERFORMANCE_MODE_NONE
andAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
for speakers, wired and wireless headsets.
- [C-SR-4] The output timestamp returned by
AudioTrack.getTimestamp
and
7. Hardware Compatibility
-
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). Wheredpippi 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).
TheA virtual pixel unit normalized to a160 dpi screenscreen 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 andinclude Android-compatibleuse 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 theUI_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:
- [C-2-1] MUST implement the latest available stable version of the extensions API or the stable version of sidecar API to be used by Window Manager Jetpack library.
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
-
See revision
Device Implementations:
- [C-0-1]
By default, device implementationsMUST reportonlyone of the Android framework densities that are listed onDisplayMetrics
through theDENSITY_DEVICE_STABLE
API and this value must be a static value for each physical displayMUST NOT change at any time; however,However the device MAY report a differentarbitrary densityDisplayMetrics.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 isan affordance to change the display size of the device , they:- [C-1-1]
The display size MUST NOT be scaled anyMUST NOT scale the display larger than 1.5 timesDENSITY_DEVICE_STABLE
native densityor 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 anyMUST NOT scale the display smaller than 0.85 times theDENSITY_DEVICE_STABLE
native density.
- [C-0-1]
-
See revision
If device implementations include support for Vulkan
1.0 or higher, they:[C-1-3] MUST fully implement the
Vulkan 1.0Vulkan 1.1 APIs for each enumeratedVkPhysicalDevice
.[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 astrue
or the metadatacom.android.graphics.injectLayers.enable
set totrue
.
- SHOULD support
VkPhysicalDeviceProtectedMemoryFeatures
andVK_EXT_global_priority
.
- [C-1-13] MUST satisfy the requirements specified by the Android Baseline 2021 profile.
[C-SR-5] Are STRONGLY RECOMMENDED to support
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
andVK_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.
-
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
andIFingerprint.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),
oron 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 unicastSTATIC STS DS-TWR
ranging, deferred mode, ranging interval 240 ms.CONFIG_ID_2
: FiRa-defined one-to-manySTATIC STS DS-TWR
ranging, deferred mode, ranging interval 200 ms. Typical use case: smart phone interacts with many smart devices.CONFIG_ID_3
: Same asCONFIG_ID_1
, except Angle-of-arrival (AoA) data is not reported.CONFIG_ID_4
: Same asCONFIG_ID_1
, except P-STS security mode is enabled.CONFIG_ID_5
: Same asCONFIG_ID_2
, except P-STS security mode is enabled.CONFIG_ID_6
: Same asCONFIG_ID_3
, except P-STS security mode is enabled.CONFIG_ID_7
: Same asCONFIG_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 theNEARBY_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.
- [C-1-2] MUST report the hardware feature flag
-
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. -
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.
- [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
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
- [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
-
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.
- [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.
-
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.
-
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.
-
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.
-
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.
- [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
-
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.
-
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:
- [C-1-1] MUST return true for
Vibrator.hasVibrator()
. - SHOULD NOT use an eccentric rotating mass (ERM) haptic actuator (vibrator).
- SHOULD implement all public constants for clear haptics
in
android.view.HapticFeedbackConstants
namely (CLOCK_TICK
,CONTEXT_CLICK
,KEYBOARD_PRESS
,KEYBOARD_RELEASE
,KEYBOARD_TAP
,LONG_PRESS
,TEXT_HANDLE_MOVE
,VIRTUAL_KEY
,VIRTUAL_KEY_RELEASE
,CONFIRM
,REJECT
,GESTURE_START
andGESTURE_END
). - SHOULD implement all public constants for clear haptics
in
android.os.VibrationEffect
namely (EFFECT_TICK
,EFFECT_CLICK
,EFFECT_HEAVY_CLICK
andEFFECT_DOUBLE_CLICK
) and all feasible publicPRIMITIVE_*
constants for rich haptics inandroid.os.VibrationEffect.Composition
namely (CLICK
,TICK
,LOW_TICK
,QUICK_FALL
,QUICK_RISE
,SLOW_RISE
,SPIN
,THUD
). Some of these primitives, such asLOW_TICK
andSPIN
may only be feasible if the vibrator can support relatively low frequencies. - SHOULD follow the guidance for mapping public constants
in
android.view.HapticFeedbackConstants
to the recommendedandroid.os.VibrationEffect
constants, with the corresponding amplitude relationships. - SHOULD use these linked haptic constants mappings.
- SHOULD follow quality assessment
for
createOneShot()
andcreateWaveform()
APIs. - SHOULD verify that the result of the public
android.os.Vibrator.hasAmplitudeControl()
API correctly reflects their vibrator’s capabilities. - SHOULD verify the capabilities for amplitude scalability by running
android.os.Vibrator.hasAmplitudeControl()
.
If device implementations follow the haptic constants mapping, they:
- SHOULD verify the implementation status by running
android.os.Vibrator.areAllEffectsSupported()
andandroid.os.Vibrator.arePrimitivesSupported()
APIs. - SHOULD perform a quality assessment for haptic constants.
- SHOULD verify and update if needed the fallback configuration for unsupported primitives as described in the implementation guidance for constants.
- SHOULD provide fallback support to mitigate the risk of failure as described here.
See Section 2.2.1 for device-specific requirements.
- [7.10/C] MUST return false for
9. Security Model Compatibility
-
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.
-
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-1] MUST allow the below intents originating from the additional profile to be handled by applications of the primary user on the device:
Intent.ACTION_VIEW
Intent.ACTION_SENDTO
Intent.ACTION_SEND
Intent.ACTION_EDIT
Intent.ACTION_INSERT
Intent.ACTION_INSERT_OR_EDIT
Intent.ACTION_SEND_MULTIPLE
Intent.ACTION_PICK
Intent.ACTION_GET_CONTENT
MediaStore.ACTION_IMAGE_CAPTURE
MediaStore.ACTION_VIDEO_CAPTURE
[C-4-2] MUST inherit all device policy user restrictions and selected non-user restrictions(list below) applied on the primary user of the device to this additional user profile.
[C-4-3] MUST only allow writing contacts from this additional profile via the following intents:
[C-4-4] MUST NOT have contact syncs running for applications running in this additional user profile.
- [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.
-
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 enabledmemtag-once
: a Memory Safety technology as defined above is transiently enabled, and is automatically disabled upon, next rebootmemtag-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
.
-
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
captured
enabled that includes exactly the same message as AOSPwhenevereach and every time a session to capture the screencasting or screen recordingisenabledstarted via theMediaProjection.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 theandroid.app.role.COMPANION_DEVICE_APP_STREAMING
or theandroid.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING
device profile.
- [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
captured
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
, supports a mechanism for device implementations to capture the followingContentCaptureService
,AugmentedAutofillService
,AppSearchGlobalManager.query
, or by other proprietary meansapplication data interactions between the applications and the usersensitive 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 viaAppSearchGlobalManager.query
.
- Any other events that an application provides to the system via the
Content Capture
API or orAppSearchManager
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 logoff 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 asRAPPOR
).[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 CaptureOS-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
implementation or the proprietary means collectsContentCaptureService
ifwhen 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.- Any screen or other data sent via the
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
- [C-1-4] Reports generated using
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:
- This access is performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementation), through a package holding one or more of the following roles: System UI Intelligence, System Ambient Audio Intelligence, System Audio Intelligence, System Notification Intelligence, System Text Intelligence, or System Visual Intelligence.
- The access is performed through a sandbox, implemented and
enforced via mechanisms in AOSP (
HotwordDetectionService
,WearableSensingService
,VisualQueryDetector
). - Audio access is performed for assistive purposes by the Digital
Assistant application, supplying
SOURCE_HOTWORD
as an audio source. - The access is performed by the system and implemented with open-source code.
- [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/orVisualQueryDetectionService
Android APIs.
- [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as
per section 9.8.2 Recording), unless:
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.
- [C-0-1] MUST be the sole application/implementation on the device and hold
the
-
See revision
Device implementationsIf device implementations have the ability to verify file content on the per-page basis, then they:
[
C-0-3C-2-1] support cryptographically verifying file contentagainst a trusted keywithout reading the whole file.[
C-0-4C-2-2] MUST NOT allow the read requests on a protected file to succeed when the read contentdo not verify against a trusted keyis not verified per [C-2-1] above.
- [C-2-4] MUST return file checksum in O(1) for enabled files.
-
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 apps
MUST NOT allow untrusted code (e.g. 3p apps)to create and run aProtected Virtual MachinepVM . Note: This might change in future Android releases.
- [C-1-5] MUST NOT allow a
Protected Virtual MachinepVM 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 anyProtected Virtual MachinepVM instance:- [C-2-1] MUST be able to run all operating systems available in the
virtualization APEX in a
Protected Virtual MachinepVM . - [C-2-2] MUST NOT allow a
Protected Virtual MachinepVM 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 MachinepVM 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 MachinepVM 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 refusesto boot ifit cannot verify the initialimages 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 refusesto 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 ensureMUST ensurethat 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 instancecan 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-2
6-2] Is STRONGLY RECOMMENDED to use DICE as the per-VM secret derivation mechanism.MUST do DICE properly i.e. provide the correct values.
- [C-1-1] MUST support all the APIs defined by the