Android 16 Compatibility Definition — Changes Only

If handheld device implementations declare support of any 64-bit ABI (with or without any 32-bit ABI) and return false for ActivityManager.isLowRamDevice(), they:

• [7.1.4.2/H-2-1] MUST support Vulkan 1.1.

An app's Live Update Notification can be promoted when the app meets all the promotion characteristics. Such notification is described as Promoted Live Update Notification in this document. Handheld device implementations MUST prominently display Promoted Live Update Notification per the following requirements.

If Handheld device implementations declare API level 36.1 or greater, they:

• [3.8.3.1/H-0-1] MUST display a Promoted Live Update Notification in a prominent place on the lockscreen.

• [3.8.3.1/H-0-12] MUST display at the top of the notification stack Heads Up Notification and above colorized notifications (where setColorized is true) when the Promoted Live Update Notification is displayed among other notifications.

  • MAY determine the order sequence of Promoted Live Update Notifications displayed within notification shade and lock screen when more than one app is eligible for Promoted Live Update Notification.

• [3.8.3.1/H-0-2] MUST display a Promoted Live Update Notification in the expanded state.

• [3.8.3.1/H-0-3] MUST NOT provide a user-affordance to collapse the expanded notification above.

• [3.8.3.1/H-0-4] MUST display the basic styles (bold, italic, and underline) of text content in a Promoted Live Update Notification, as provided by StyleSpan or UnderlineSpan.

• [3.8.3.1/H-0-5] MUST display only standard action objects (via Notification.Action), and MUST hide non-standard action objects such as input boxes, reply buttons, and contextual actions (via addRemoteInput() and setContextual()) in a Promoted Live Update Notification, even when the notification contains them.

• [3.8.3.1/H-0-6] MUST display a Compact Representation, also referred to as Status Chip in the SDK documentation, for a Promoted Live Update Notification that MUST include Notification.getSmallIcon().

  • [3.8.3.1/H-0-7] Other fields are optional for the Compact Representation, but whenever the compact representation can be expanded, MUST display Notification.getShortCriticalText() if present, or Notification.when if Notification.getShortCriticalText isn't present.

  • [3.8.3.1/H-0-8] When more than one Promoted Live Update notifications are present, MUST display at least one of them in the status bar as a Compact Representation.

  • [3.8.3.1/H-0-9] MUST either show the associated notification (preferred) or open the associated app (via Notification.contentIntent), when the user taps on the Compact Representation.

  • [3.8.3.1/H-0-13] MUST display all the same content in the associated notification as the one that is available in the notification shade.

• [3.8.3.1/H-0-10] MUST provide a user affordance to disable and enable the promoted display of individual app's notifications.

• [3.8.3.1/H-0-11] MUST correctly render all Live Update Notifications, including but not limited to non-promoted Live Update Notifications that don't or only partially meet the promotion characteristics. Such non-promoted notifications MUST be displayed in a non-promoted state.

• [7.1.1.1/A-0-3] MUST support GPU composition of graphic buffers at least as large as the highest resolution of any built-in display.

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.

If Automotive device implementations claim support for high dynamic range displays through Configuration.isScreenHdr(), they:

• [7.1.4.5/A-1-1] MUST advertise support for the EGL_EXT_gl_colorspace_bt2020_pq, EGL_EXT_surface_SMPTE2086_metadata, EGL_EXT_surface_CTA861_3_metadata, VK_EXT_swapchain_colorspace, and VK_EXT_hdr_metadata extensions.

Automotive device implementations:

• [7.1.4.6/A-0-1] MUST report whether the device supports the GPU profiling capability via a system property graphics.gpu.profiler.support.

If Automotive device implementations declare support via a system property graphics.gpu.profiler.support, they:

• [7.1.4.6/A-1-1] MUST report as output a protobuf trace that complies with the schema for GPU counters and GPU RenderStages defined in the Perfetto documentation.

• [7.1.4.6/A-1-2] MUST report conformant values for the device's GPU counters following the gpu counter trace packet proto.

• [7.1.4.6/A-1-3] MUST report conformant values for the device's GPU RenderStages following the render stage trace packet proto.

• [7.1.4.6/A-1-4] MUST report a GPU Frequency tracepoint as specified by the format: power/gpu_frequency.

Automotive device implementations:

• [7.1.5/A-0-1] MUST include support for legacy app compatibility mode as implemented by the upstream Android open source code. That is, device implementations MUST NOT alter the triggers or thresholds at which compatibility mode is activated, and MUST NOT alter the behavior of the compatibility mode itself.

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

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

If Automotive device implementations include a USB port supporting host mode, they:

• [7.7.2/A-1-1] MUST implement the USB audio class as described in the Android SDK documentation.

When the AudioManager.getDevices() API is called while the USB peripheral is connected, it:

• [7.8.2.2/A-1-1] MUST list a device of type AudioDeviceInfo.TYPE_USB_HEADSET and role isSink() if the USB audio terminal type field is 0x0302.

• [7.8.2.2/A-1-2] MUST list a device of type AudioDeviceInfo.TYPE_USB_HEADSET and role isSink() if the USB audio terminal type field is 0x0402.

• [7.8.2.2/A-1-3] MUST list a device of type AudioDeviceInfo.TYPE_USB_HEADSET and role isSink() if the USB audio terminal type field is 0x0603.

• [7.8.2.2/A-1-4] MUST list a device of type AudioDeviceInfo.TYPE_USB_HEADSET and role isSink() if the USB audio terminal type field is 0x0400.

• [3.2.3.1/A-0-2] MUST have an app that handles the ACTION_GET_CONTENT, ACTION_OPEN_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE, and ACTION_CREATE_DOCUMENT intents as described in the SDK documents, and provide the user affordance to access the document provider data by using DocumentsProvider API.

If Automotive device implementation's settings application implements a split functionality, using activity embedding, they:

• [3.2.3.1/A-1-1] MUST have an activity that handles the Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY intent when split functionality is on. The Activity MUST be protected by android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK, and it MUST start the activity of the Intent parsed from Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI.

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

• [7.4.1.2/A-1-1] MUST declare the feature flag android.software.telecom.

• [7.4.1.2/A-1-2] MUST implement the telecom framework.

• [8.1/A-0-1] Consistent frame latency. Inconsistent frame latency or a delay to render frames MUST NOT happen more often than 5 frames in a second, and SHOULD be below 1 frame in a second.

• [8.1/A-0-2] User interface latency. Device implementations MUST ensure low latency user experience by scrolling a list of 10K list entries as defined by the Android Compatibility Test Suite (CTS) in less than 36 seconds.

• [8.1/A-0-3] Task switching. When multiple apps have been launched, re-launching an already-running application after it has been launched MUST take less than 1 second.

• [8.2/A-0-2] MUST ensure a sequential write performance of at least 5 MB/s.

• [8.2/A-0-3] MUST ensure a random write performance of at least 0.5 MB/s.

• [8.2/A-0-4] MUST ensure a sequential read performance of at least 15 MB/s.

• [8.2/A-0-5] MUST ensure a random read performance of at least 3.5 MB/s.

If Automotive device implementations return android.os.Build.VERSION_CODES.U or greater for android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS, they:

• [8.2/A-1-1] MUST ensure a sequential write performance of at least 150 MB/s.

• [8.2/A-1-2] MUST ensure a random write performance of at least 10 MB/s.

• [8.2/A-1-3] MUST ensure a sequential read performance of at least 250 MB/s.

• [8.2/A-1-4] MUST ensure a random read performance of at least 100 MB/s.

• [8.2/A-1-5] MUST ensure a parallel sequential read and write performance with 2x read and 1x write performance of at least 50 MB/s.

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

• [9.8/A-1-1] MUST make sure the query detection service can only transmit data to the System, ContentCaptureService, or on-device speech recognition service (created by SpeechRecognizer#createOnDeviceSpeechRecognizer()).

• [9.8/A-1-2] MUST NOT allow any audio or video information to be transmitted out of the VisualQueryDetectionService, except to ContentCaptureService or on-device speech recognition service.

• [9.8/A-1-3] MUST display a user notice in System UI when the device detects user intent to engage with the Digital Assistant Application (such as by detecting user presence via camera).

• [9.8/A-1-4] MUST display a microphone indicator and display the detected user query in the UI immediately after the user query is detected.

• [9.8/A-1-5] MUST NOT allow a user-installable application to provide the visual query detection service.

• [C-SR-2] Are STRONGLY RECOMMENDED to implement offload playback for AAC, MP3, OPUS, and PCM formats.

HDR Display Requirements

If device implementations receive buffer content encoded with ADATASPACE_TRANSFER_HLG, and that content is sent to the display through SurfaceControl.Transaction#setBuffer, they:

• [C-8-1] MUST follow the graphics white recommendation in BT. 2408-7, and only display that content to be at most greater than 4.926 times of SDR content.

Device implementations that declare the system property sensor.barometer.high_quality.implemented:

• [C-2-1] MUST report pressure measurements in the range of 300 hPa to 1100 hPa, with an absolute accuracy of +/- 1 hPa.

• [C-2-2] MUST have a relative accuracy of 0.15 hPa over a 100 hPa range, equivalent to ~1 m accuracy over ~1000 m change at sea level.

• [C-2-3] MUST be stable within +/- 0.5 hPa when the user taps, presses, or squeezes the device.

• [C-2-4] MUST be stable within +/- 0.15 hPa when the user walks with the device in hand or in pocket.

• [C-2-5] MUST NOT be smoothed with a time constant of more than 300 ms for activations above 5 Hz, and smoothing MUST NOT leak across sensor activations.

• [C-2-6] MUST be stable within +/- 0.15 hPa when exposed to day-to-day lighting and radio frequencies introduced by common sources such as Bluetooth, cellular connection, or Wi-Fi.

To help provide a differentiated experience, device implementations MAY include additional sensors not covered by Android or Wear OS, which preloaded apps may access.

For such sensors, the sensor ID:

• [C-0-1] MUST be higher than 65536.

If the custom sensor is intended for health or fitness related purposes, it:

• [C-0-2] MUST be protected by either a platform permission or system permission.

If device implementations declare FEATURE_BLUETOOTH_LE_CHANNEL_SOUNDING, they:

• [C-11-1] MUST report the hardware feature flag android.hardware.bluetooth_le.channel_sounding.

• [C-11-2] MUST report the range accurately to within +/- 0.5 m at the 90th percentile, as calculated with the Cumulative Distribution Function, at the distance of 1 m.

If device implementations include at least one camera, and the pre-installed camera application handles the intents MediaStore.ACTION_MOTION_PHOTO_CAPTURE or MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE, they:

• [C-1-4] MUST ensure that when handling these intents, the pre-installed camera app removes the user location in the image metadata before sending it to receiving applications that don't have ACCESS_FINE_LOCATION.

• [C-1-5] MUST ensure that the returned motion photo uses the Motion Photo format 1.0 specification.

If devices include data sensors exposing health-related biometrics such as heart rate or skin temperature, those biometrics:

• [C-0-16] MUST be guarded by platform permissions from android.permission-group.HEALTH, if there's a corresponding permission in HealthPermissions.

• [C-0-17] MUST, if no platform permission matches the desired data type, be guarded by a custom system permission. (For example, ELECTROCARDIOGRAM.)

If device implementations create the additional user profile discussed above, they include at least one camera, and the pre-installed camera application handles the intents MediaStore.ACTION_MOTION_PHOTO_CAPTURE or MediaStore.ACTION_MOTION_PHOTO_CAPTURE_SECURE, they:

• [C-5-1] MUST allow applications of the primary user to handle these intents originating from that additional user profile.

Device implementations declaring API level 36.1 or greater:

• MAY include support for a developer verifier service to certify that applications originate from a known developer.

Device implementations declaring API level 36.1 or greater and configure a developer verifier by defining config_developerVerificationServiceProviderPackageName in config.xml:

• [9.18/C-1-1] MUST invoke the configured android.content.pm.verify.developer.DeveloperVerifierService for every application package installation, which includes both new installations and updates to existing applications.

Device implementations declaring API level 36.1 or greater:

• MAY also configure a delegate for setting the active policy by defining config_developerVerificationPolicyDelegatePackageName in config.xml.

If a developer verifier is configured, device implementations:

• [9.18/C-2-1] MUST only allow the developer verifier or its configured delegate to set the installation policy as defined in android.content.pm.PackageInstaller.

If a verifier is invoked as part of a package installation session, device implementations:

• [9.18/C-3-1] MUST prevent the installation of an application package if:

  • The installation fails the developer identity verification.
  • The developer verification policy for the installation session is set to any value other than DEVELOPER_VERIFICATION_POLICY_NONE.
  • Unless either 9.18/C-3-2 or 9.18/C-3-3 apply.

• [9.18/C-3-2] MUST NOT prevent the installation of an application package regardless of policy or verification status when:

  • The package is installed via the Android Debug Bridge (ADB).
  • The package is the configured developer verifier or its installer.

• [9.18/C-3-3] MUST NOT prevent the installation of an application package when all following conditions are met:

  • Policy is set to DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_WARN or DEVELOPER_VERIFICATION_POLICY_BLOCK_FAIL_OPEN.
  • The verification is reported as incomplete.
  • The installer indicates the user explicitly requested the installation continue by reporting DEVELOPER_VERIFICATION_USER_RESPONSE_INSTALL_ANYWAY.

• MAY allow the installation of an application package regardless of policy or verification status for installations initiated by the device owner on a managed device or the profile owner on a managed profile, but it's STRONGLY RECOMMENDED to prevent installations as outlined in 9.18/C-3-1.