Android 兼容性定义文档变更日志

安卓 13

2022 年 10 月 19 日

2. 设备类型

• 2.2.3 软件

  见修订

  如果手持设备实现未在锁定任务模式下运行，当内容被复制到剪贴板时，它们：

  • [3.8.17/H-1-1] 必须向用户提供数据已复制到剪贴板的确认信息（例如，缩略图或“内容已复制”的警告）。此外，如果剪贴板数据将跨设备同步，请在此处包括指示。

3. 软件

• 3.2.3.5。有条件的申请意向

  见修订

  如果设备实现的设置应用程序使用活动嵌入实现了拆分功能，那么它们：

  • [C-17-1] 必须有一个 Activity 在拆分功能打开时处理Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY意图。 Activity 必须受android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK保护，并且它必须启动从Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI解析的 Intent 活动。

  如果设备实现支持VoiceInteractionService并且一次安装了多个使用此 API 的应用程序，则它们：

  • [C-18-1]必须遵守android.settings.ACTION_VOICE_INPUT_SETTINGS意图，以显示用于语音输入和辅助的默认应用设置菜单。

• 3.4.1 网页视图兼容性

  见修订

  • [C-1-4]必须在与实例化 WebView 的应用程序不同的进程中呈现提供的内容或远程 URL 内容。具体来说，单独的渲染器进程必须拥有较低的权限，作为单独的用户 ID 运行，无法访问应用程序的数据目录，无法直接访问网络，并且只能通过 Binder 访问最低要求的系统服务。 WebView 的 AOSP 实现满足了这个要求。

7. 硬件兼容性

• 7.4.2 IEEE 802.11（Wi-Fi）

  见修订

  如果设备实现支持 IEEE 802.11 标准中定义的 Wi-Fi 省电模式，则：

  • [C-3-1] 必须每当应用通过WifiManager.createWifiLock()和WifiManager.WifiLock.acquire()获取WIFI_MODE_FULL_HIGH_PERF锁或WIFI_MODE_FULL_LOW_LATENCY锁时，应关闭 Wi-Fi 省电模式

• 7.4.3 蓝牙

  见修订

  如果设备实现包括对低功耗蓝牙 (BLE) 的支持，则它们：

  • [C-3-5] 必须实施不超过 15 分钟的可解析私有地址 (RPA) 超时，并在超时时轮换地址，以在设备主动使用 BLE 进行扫描或广告时保护用户隐私。为了防止定时攻击，超时间隔也必须在 5 到 15 分钟之间随机分配。

• 7.5.5 相机方向

  见修订

  如果设备实现具有前置或后置摄像头，则此类摄像头：

  • [C-1-1] 必须调整方向，使相机的长尺寸与屏幕的长尺寸对齐。也就是说，当设备以横向放置时，相机必须以横向拍摄图像。无论设备的自然方向如何，这都适用；也就是说，它适用于横向主设备以及纵向主设备。

  满足以下所有条件的设备不受上述要求的约束：

  • 该设备采用可变几何屏幕，例如可折叠或铰链式显示器。
  • 当设备的折叠或铰链状态发生变化时，设备会在纵向主要方向和横向主要方向（或反之亦然）之间切换。

9. 安全模型兼容性

• 9.11 密钥和凭证

  见修订

  当设备实现支持安全锁屏时，它：

  • [C-1-6] 必须支持 IKeymasterDevice 4.0、 IKeymasterDevice 4.1、IKeyMintDevice 版本 1 或 IKeyMintDevice 版本 2。

• 9.17 安卓虚拟化框架

  见修订

  如果设备实现了对 Android 虚拟化框架 API ( android.system.virtualmachine.* ) 的支持，则 Android 主机：

  • [C-1-3] 不得修改、省略或替换上游 Android 开源项目 (AOSP) 中提供的系统/sepolicy 中存在的 neverallow 规则，并且该政策必须使用所有存在的 neverallow 规则进行编译。

  如果设备实现了对 Android 虚拟化框架 API ( android.system.virtualmachine.* ) 的支持，则任何受保护的虚拟机实例：

  • [C-2-4] 不得修改、省略或替换上游 Android 开源项目 (AOSP) 中提供的 system/sepolicy/microdroid 中存在的 neverallow 规则。

  如果设备实现了对 Android 虚拟化框架 API 的支持，那么对于密钥管理：

  • [C-6-2] 必须正确执行 DICE，即提供正确的值。但它可能不必达到那种详细程度。

2022 年 8 月 15 日

2. 设备类型

• 2.2.1 硬件：硬件要求更改如下。

  • 输入设备：

    见修订

    手持设备实现：

    • [ 7.2 .3/H-0-5] 当返回手势开始或按下返回按钮 ( KEYCODE_BACK ) 时，必须在当前聚焦窗口上调用OnBackInvokedCallback.onBackStarted() 。
    • [ 7.2 .3/H-0-6] 必须在提交后退手势或释放后退按钮 (UP) 时调用OnBackInvokedCallback.onBackInvoked() 。
    • [ 7.2 .3/H-0-7] 当返回手势未提交或KEYCODE_BACK事件被取消时，必须调用OnBackInvokedCallback.onBackCancelled() 。

    如果设备通过声明PackageManager.FEATURE_WIFI_AWARE支持 WiFi 邻居感知网络 (NAN) 协议，并通过声明PackageManager.FEATURE_WIFI_RTT支持 Wi-Fi 位置（Wi-Fi 往返时间 - RTT），那么它们：

    • [ 7.4 .2.5/H-1-1] 必须在第 68 个百分位（根据累积分布函数计算）在 160 MHz 带宽时准确报告范围在 +/-1 米以内，在 80 MHz 带宽时在 +/-2 米范围内在第 68 个百分位，+/-4 米，40 MHz 带宽，第 68 个百分位，+/-8 米，20 MHz 带宽，第 68 个百分位，距离为 10 cm、1 m、3 m 和 5 m，如通过WifiRttManager#startRanging Android API观察。

    • [ 7.4 .2.5/H-SR] 强烈建议在 160 MHz 带宽的第 90 个百分位（根据累积分布函数计算）在 +/-1 米内准确报告范围，在 80 MHz 时为 +/-2 米通过WifiRttManager#startRanging Android API观察，第 90 个百分位数的带宽，第 90 个百分位数的 40 MHz 带宽 +/-4 米，第 90 个百分位数的 20 MHz 带宽 +/-8 米，距离为 10 厘米。

    强烈建议遵循存在校准要求中指定的测量设置步骤。

  • 音频延迟：

    见修订

    如果手持设备实现声明了android.hardware.audio.output和android.hardware.microphone ，它们：

    • [ 5.6 /H-1-1] 必须具有500的平均连续往返延迟800 5 次测量的毫秒或更少，平均绝对偏差小于50 100 ms，通过以下数据路径：“扬声器到麦克风”、3.5 毫米环回适配器（如果支持）、USB 环回（如果支持）。至少一个支持的路径。

    • [ 5.6 /H-1-1] 在扬声器到麦克风数据路径上的至少 5 次测量中，平均点击音延迟必须为 500 毫秒或更短。

  • 触觉输入：

    见修订

    如果手持设备实现包括至少一个触觉执行器，则它们：

    • [ 7.10 /H]* 不应使用偏心旋转质量 (ERM) 触觉致动器（振动器）。
    • [ 7.10 /H]* 应将执行器放置在通常用手握住或触摸设备的位置附近。
    • [ 7.10 /H]* 应在android.view.HapticFeedbackConstants中实现清晰触觉的所有公共常量，即（CLOCK_TICK、CONTEXT_CLICK、KEYBOARD_PRESS、KEYBOARD_RELEASE、KEYBOARD_TAP、LONG_PRESS、TEXT_HANDLE_MOVE、VIRTUAL_KEY、VIRTUAL_KEY_RELEASE、CONFIRM、REJECT、GESTURE_START）和
    • [ 7.10 /H]* 应在android.os.VibrationEffect中实现清晰触觉的所有公共常量，即（EFFECT_TICK、EFFECT_CLICK、EFFECT_HEAVY_CLICK 和 EFFECT_DOUBLE_CLICK），以及在android.os.VibrationEffect.Composition中实现丰富触觉的所有可行公共PRIMITIVE_*常量，即(PRIMITIVE_CLICK 和 PRIMITIVE_TICK) （点击、滴答、LOW_TICK、QUICK_FALL、QUICK_RISE、SLOW_RISE、旋转、THUD）。这些原语中的一些，例如 LOW_TICK 和 SPIN 可能仅在振动器可以支持相对较低的频率时才可行。

    • [7.10/H]* 应遵循将android.view.HapticFeedbackConstants中的公共常量映射到推荐的android.os.VibrationEffect常量的指导，以及相应的振幅关系。

    • [ 7.10 /H]* 应该使用这些链接的触觉常量映射。

    • [ 7.10 /H]* 应验证公共android.os.Vibrator.hasAmplitudeControl() API 的结果是否正确反映了振动器的功能。

    • [ 7.10 /H]* 应该通过运行android.os.Vibrator.hasAmplitudeControl()来验证振幅可扩展性的能力。

    如果手持设备实现包括至少一个线性谐振执行器，则它们：

    • [ 7.10 /H]* 应在纵向的 X 轴（左右）上移动触觉致动器。

    • [ 7.10 /H]* 应该验证并在需要时更新不支持原语的回退配置，如常量实施指南中所述。

    • [7.10/H]* 应提供后备支持以降低此处所述的失败风险。

• 2.2.3 软件：

  • 授权简单的设备控制：

    见修订

    • [ 3.8 .16/H-1-5] 必须提供一种方式，让用户可以通过ControlsProviderService和Control Control.isAuthRequired API 从第三方应用程序注册的控件中选择退出应用程序指定的 auth-trivial 设备控件。

  • 媒体样式通知：

    见修订

    如果手持设备实现支持MediaStyle 通知，则它们：

    • [3.8.3.1/H-1-SR] 强烈建议提供从系统 UI 访问的用户功能（例如“输出切换器”），允许用户在适当的可用媒体路由（例如蓝牙设备和提供给MediaRouter2Manager的路由）之间切换当应用发布带有MediaSession 令牌的MediaStyle 通知时。

• 2.2.4 性能和功率：对运行前台服务的应用程序的新要求。

  见修订

  手持设备实现：

  • [ 8.5 /H-0-1] 必须在“设置”菜单中为用户提供停止正在运行前台服务的应用程序并显示所有具有活动前台服务的应用程序以及每项服务的持续时间的能力按照SDK 文档中的描述启动。
    • 如SDK 文档中所述，某些应用程序可以免于停止或列在此类用户可供性中。

• 2.2.7.1 媒体：手持设备要求媒体部分更新如下：

  见修订

  如果手持设备实现为android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS返回android.os.Build.VERSION_CODES.T ，那么它们：

  • [5.1/H-1-1] 必须通告可通过CodecCapabilities.getMaxSupportedInstances()和VideoCapabilities.getSupportedPerformancePoints()方法在任何编解码器组合中同时运行的硬件视频解码器会话的最大数量。
  • [5.1/H-1-2] 必须在以 1080p 分辨率@30 fps 同时运行的任何编解码器组合中支持 6 个硬件视频解码器会话实例（AVC、HEVC、VP9、AV1 或更高版本）。
  • [5.1/H-1-3] 必须通告可通过CodecCapabilities.getMaxSupportedInstances()和VideoCapabilities.getSupportedPerformancePoints()方法在任何编解码器组合中同时运行的硬件视频编码器会话的最大数量。
  • [5.1/H-1-4] 必须在以 1080p 分辨率@30fps 同时运行的任何编解码器组合中支持 6 个硬件视频编码器会话实例（AVC、HEVC、VP9、AV1 或更高版本）。
  • [5.1/H-1-5] 必须通告可通过CodecCapabilities.getMaxSupportedInstances()和VideoCapabilities.getSupportedPerformancePoints()方法在任何编解码器组合中同时运行的硬件视频编码器和解码器会话的最大数量。
  • [5.1/H-1-6] 必须支持以 1080p@30fps 分辨率同时运行的任何编解码器组合中的 6 个硬件视频解码器和硬件视频编码器会话实例（AVC、HEVC、VP9、AV1 或更高版本）。
  • [5.1/H-1-7] 在负载下，所有硬件视频编码器的 1080p 或更小视频编码会话的编解码器初始化延迟必须不超过 40 毫秒。此处的加载定义为并发的 1080p 到 720p 纯视频转码会话，使用硬件视频编解码器以及 1080p 音频-视频录制初始化。
  • [5.1/H-1-8] 在负载下，所有音频编码器的 128 kbps 或更低比特率音频编码会话的编解码器初始化延迟必须为 30 毫秒或更短。此处的加载定义为并发的 1080p 到 720p 纯视频转码会话，使用硬件视频编解码器以及 1080p 音频-视频录制初始化。
  • [5.1/H-1-9] 必须在以 1080p 分辨率@30 fps 同时运行的任何编解码器组合中支持 2 个安全硬件视频解码器会话实例（AVC、HEVC、VP9、AV1 或更高版本）。
  • [5.1/H-1-10] 必须在任何编解码器中支持 3 个非安全硬件视频解码器会话实例和 1 个安全硬件视频解码器会话实例（总共 4 个实例）（AVC、HEVC、VP9、AV1 或更高版本）组合以 1080p 分辨率@30fps 同时运行。
  • [5.1/ H-1-11] 必须支持设备上每个硬件 AVC、HEVC、VP9 或 AV1 解码器的安全解码器。
  • [5.1/H-1-12] 视频解码器初始化延迟必须不超过 40 毫秒。
  • [5.1/H-1-13] 音频解码器初始化延迟必须不超过 30 毫秒。
  • [5.1/H-1-14] 必须支持 AV1 硬件解码器 Main 10，Level 4.1。
  • [5.1/H-SR] 强烈推荐支持 AV1 硬件解码器的 Film Grain。
  • [5.1/H-1-15] 必须至少有 1 个支持 4K60 的硬件视频解码器。
  • [5.1/H-1-16] 必须至少有 1 个支持 4K60 的硬件视频编码器。
  • [5.3/H-1-1] 负载下的 1080p 60 fps 视频会话在 10 秒内丢帧不得超过 1 帧（即丢帧率小于 0.167%）。负载定义为使用硬件视频编解码器的并发 1080p 到 720p 纯视频转码会话，以及 128 kbps AAC 音频播放。
  • [5.3/H-1-2] 在加载 60 fps 视频会话的视频分辨率更改期间，10 秒内丢帧不得超过 1 帧。负载定义为使用硬件视频编解码器的并发 1080p 到 720p 纯视频转码会话，以及 128 kbps AAC 音频播放。
  • [5.6/H-1-1] 使用 OboeTester 按键音测试或 CTS Verifier 按键音测试时，按键音延迟必须为 80 毫秒或更短。
  • [5.6/H-1-2] 在至少一个受支持的数据路径上，往返音频延迟必须为 80 毫秒或更短。
  • [5.6/H-1-3] 必须支持 >=24 位音频，通过 3.5 毫米音频插孔（如果存在）和 USB 音频（如果通过整个数据路径支持低延迟和流式传输配置）进行立体声输出。对于低延迟配置，应用程序应在低延迟回调模式下使用 AAudio。对于流配置，应用程序应使用 Java AudioTrack。在低延迟和流式配置中，HAL 输出接收器应接受AUDIO_FORMAT_PCM_24_BIT 、 AUDIO_FORMAT_PCM_24_BIT_PACKED 、 AUDIO_FORMAT_PCM_32_BIT或AUDIO_FORMAT_PCM_FLOAT作为其目标输出格式。
  • [5.6/H-1-4] 必须支持 >=4 声道 USB 音频设备（DJ 控制器使用它来预览歌曲。）
  • [5.6/H-1-5] 必须支持类兼容 MIDI 设备并声明 MIDI 功能标志。
  • [5.7/H-1-2] 必须支持具有以下内容解密功能的MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL 。

  最小样本量	4 字节
  最小子样本数 - H264 或 HEVC	32
  最小子样本数 - VP9	9
  最小子样本数 - AV1	288
  最小子样本缓冲区大小	1 字节
  最小通用加密缓冲区大小	500 KB
  最小并发会话数	30
  每个会话的最小密钥数	20
  最小键总数（所有会话）	80
  DRM 密钥的最小总数（所有会话）	6个
  邮件大小	16 KB
  每秒解密帧数	60 帧/秒

• 2.2.7.2 相机：更新媒体性能等级相机要求。

  见修订

  如果手持设备实现为android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS返回android.os.Build.VERSION_CODES.T ，那么它们：

  • [7.5/H-1-1] 必须有一个主后置摄像头，分辨率至少为 12 兆像素，支持 4k@30fps 的视频捕获。主后置摄像头是摄像头 ID 最小的后置摄像头。
  • [7.5/H-1-2] 必须有一个主前置摄像头，分辨率至少为 5 百万像素，并支持 1080p@30fps 的视频捕获。主前置摄像头是摄像头 ID 最小的前置摄像头。
  • [7.5/H-1-3] 必须支持两个主摄像头的android.info.supportedHardwareLevel属性为FULL或更好。
  • [7.5/H-1-4] 必须支持两个主摄像头的CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME 。
  • [7.5/H-1-5] 对于 1080p 分辨率，两个主摄像头在 ITS 照明条件 (3000K) 下通过 CTS 摄像头性能测试测得的摄像头 2 JPEG 捕获延迟必须小于 1000 毫秒。
  • [7.5/H-1-6] 两个主摄像头在 ITS 照明条件 (3000K) 下通过 CTS 摄像头性能测试测得的摄像头 2 启动延迟（打开摄像头到第一个预览帧）必须小于 500 毫秒。
  • [7.5/H-1-8] 主后置摄像头必须支持CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW和android.graphics.ImageFormat.RAW_SENSOR 。
  • [7.5/H-1-9] 必须具有支持 720p 或 1080p @ 240fps 的后置主摄像头。
  • [7.5/H-1-10] 如果超宽 RGB 摄像头面向同一方向，则主摄像头的最小 ZOOM_RATIO 必须 < 1.0。
  • [7.5/H-1-11] 必须在主摄像头上实现并发的前后流。
  • [7.5/H-1-12] 必须支持主前置摄像头和主后置摄像头的CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION 。
  • [7.5/H-1-13] 如果有超过 1 个 RGB 相机面向同一方向，则必须支持主相机的LOGICAL_MULTI_CAMERA功能。
  • [7.5/H-1-14] 必须支持主前置摄像头和主后置摄像头的STREAM_USE_CASE功能。

• 2.2.7.3 硬件：更新硬件的媒体性能等级要求。

  见修订

  如果手持设备实现为android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS返回android.os.Build.VERSION_CODES.T ，那么它们：

  • [7.1.1.1/H-2-1] 屏幕分辨率必须至少为 1080p。
  • [7.1.1.3/H-2-1] 屏幕密度必须至少为 400 dpi。
  • [7.6.1/H-2-1] 必须至少有 8 GB 的物理内存。

• 2.2.7.4 性能：更新媒体性能类的性能。

  见修订

  如果手持设备实现为android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS返回android.os.Build.VERSION_CODES.T ，那么它们：

  • [8.2/H-1-1] 必须确保至少 125 MB/s 的顺序写入性能。
  • [8.2/H-1-2] 必须确保至少 10 MB/s 的随机写入性能。
  • [8.2/H-1-3] 必须确保至少 250 MB/s 的顺序读取性能。
  • [8.2/H-1-4] 必须确保至少 40 MB/s 的随机读取性能。

• 2.5.1 硬件：更新三轴加速度计和三轴陀螺仪要求，以及外视摄像头要求。

  见修订

  汽车设备实现：

  • [ 7.3 .1/A-0-4] 必须符合 Android汽车传感器坐标系。
  • [ 7.3 /A-SR] 强烈建议包括 3 轴加速度计和 3 轴陀螺仪。
  • [ 7.3 /A-SR] 强烈建议实施和报告TYPE_HEADING传感器。

  如果汽车设备实现包括加速度计，则它们：

  • [ 7.3 .1 /A-1-1] 必须能够以至少 100 Hz 的频率报告事件。

  如果设备实现包括 3 轴加速度计，则：

  • [ 7.3 .1/A-SR] 强烈建议为有限轴加速度计实施复合传感器。

  如果汽车设备实现包括少于 3 个轴的加速度计，则它们：

  • [ 7.3 .1/A-1-3] 必须实施并报告TYPE_ACCELEROMETER_LIMITED_AXES传感器。
  • [ 7.3 .1/A-1-4] 必须实施并报告TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED传感器。

  如果汽车设备实现包括陀螺仪，则它们：

  • [ 7.3 .4/A-2-1] 必须能够以至少 100 Hz 的频率报告事件。
  • [ 7.3 .4/A-2-3] 必须能够测量高达每秒 250 度的方向变化。
  • [ 7.3 .4/A-SR] 强烈建议将陀螺仪的测量范围配置为 +/-250dps，以尽可能提高分辨率。

  如果汽车设备实现包括 3 轴陀螺仪，则它们：

  • [ 7.3 .4/A-SR] 强烈建议为有限轴陀螺仪实施复合传感器。

  如果汽车设备实现包括少于 3 轴的陀螺仪，则它们：

  • [ 7.3 .4/A-4-1] 必须实施并报告TYPE_GYROSCOPE_LIMITED_AXES传感器。
  • [ 7.3 .4/A-4-2] 必须实施并报告TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED传感器。

  如果汽车设备实现包含TYPE_HEADING传感器，则它们：

  • [ 7.3 .4/A-4-3] 必须能够以至少 1 Hz 的频率报告事件。
  • [ 7.3 .4/A-SR] 强烈建议报告频率至少为 10 Hz 的事件。
  • 应该参考真北。
  • 即使在车辆静止时也应该可用。
  • 分辨率至少应为 1 度。

  外视摄像头是一种对设备实现之外的场景进行成像的摄像头，例如后视摄像头行车记录仪.

  如果汽车设备实现包括外部摄像头，对于此类摄像头，它们：

  • [ 7.5 .5/A-SR] 强烈建议调整方向，使相机的长尺寸与地平线对齐。

  • 应支持Android 同步框架。

  • 可以在相机驱动程序中实现硬件自动对焦或软件自动对焦。

  如果汽车设备实现包括一个或多个外视摄像头，并加载外视系统 (EVS) 服务，那么对于此类摄像头，它们：

  • [ 7.5 /A-2-1] 不得旋转或水平镜像相机预览。

  汽车设备实现：

  • 可以包括一个或多个可供第三方应用程序使用的相机。

  如果汽车设备实现包括至少一个摄像头并使其可供第三方应用程序使用，则它们：

  • [ 7.5 /A-3-1] 必须报告功能标志android.hardware.camera.any 。
  • [ 7.5 /A-3-2] 不得将相机声明为系统相机。
  • 可以支持第 7.5.3 节中描述的外部摄像头。
  • 可以包括第 7.5.1 节中所述的后置摄像头可用的功能（例如自动对焦等）。

• 2.5.5 安全模型：对汽车设备摄像头权限的新要求。

  见修订

  如果 Automotive 设备实现声明了android.hardware.camera.any ，那么它们：

  • [ 9.8.2 /A-2-1] 必须在应用程序访问实时摄像头数据时显示摄像头指示器，但当摄像头仅由具有第 9.1 节 CDD 权限中所述角色的应用程序访问时不显示标识符 [C-3-X]。

  • [ 9.8.2 /A-2-2] 不得为具有可见用户界面或直接用户交互的系统应用程序隐藏摄像头指示器。

• 2.6.1 平板电脑要求 - 硬件：更新平板电脑屏幕尺寸要求。

  见修订

  Android 平板电脑设备是指通常满足以下所有条件的 Android 设备实现：

  • 屏幕显示尺寸大于 7 英寸且小于 18 英寸，对角线测量。

  屏幕尺寸

  • [ 7.1 .1.1/Tab-0-1] 屏幕必须在 7 到 18 英寸之间。

3. 软件

• 3.2.2 构建参数：更新了getSerial()中的 ASCII 字符。

  见修订

  • [C-0-1] 为了在设备实现中提供一致、有意义的值，下表包含对这些值的格式的额外限制，设备实现必须遵守这些格式。

  范围	细节
  获取序列号()	必须（是或返回）硬件序列号，该序列号必须在具有相同型号和制造商的设备之间可用且唯一。该字段的值必须可编码为 7 位 ASCII，并匹配正则表达式“^[a-zA-Z0-9]+$” 。

• 3.2.3.5 条件应用意图：更新条件应用意图的要求。

  见修订

  如果设备实现包括大型显示器（通常具有 600dp+ 的显示宽度和高度）并支持拆分功能，则它们：

  • [C-17-1] 必须有一个 Activity 在拆分功能打开时处理Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY意图。 Activity 必须受android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK保护，并且它必须启动从Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI解析的 Intent 活动。

• 3.5.1 应用限制：更新应用限制。

  见修订

  如果设备实现实施专有机制来限制应用程序（例如，更改或限制 SDK 中描述的 API 行为）并且该机制比受限应用程序待机桶更严格，则它们：

  • [C-1-1] 必须允许用户查看受限应用列表。
  • [C-1-2] 必须让用户能够在每个应用上打开/关闭所有这些专有限制。
  • [C-1-3] 不得在没有不良系统健康行为证据的情况下自动应用这些专有限制，但可以在检测到不良系统健康行为（例如唤醒锁卡住、长时间运行的服务和其他标准）时对应用应用限制。标准可以由设备实施者确定，但必须与应用对系统健康的影响相关。其他非纯粹与系统健康相关的标准，例如应用程序在市场上缺乏受欢迎程度，不得用作标准。
  • [C-1-4] 不得在用户手动关闭应用限制后自动对应用应用这些专有限制，并且可以建议用户应用这些专有限制。

  • [C-1-5] 如果这些专有限制自动应用于应用，则必须通知用户。此类信息必须在应用这些专有限制之前的 24 小时内提供。

  • [C-1-6] 必须为来自应用的任何 API 调用的ActivityManager.isBackgroundRestricted()方法返回 true。

  • [C-1-7] 不得限制用户明确使用的最靠前的前台应用。

  • [C-1-8] 必须在用户开始明确使用应用时暂停对应用的这些专有限制，使其成为顶级前台应用。

  • [C-1-9] 必须通过 UsageStats 报告所有这些专有限制事件。

  • [C-1-10] 必须提供明确的公开文件或网站，说明如何应用专有限制。本文档或网站必须可从 Android SDK 文档链接，并且必须包括：

    • 专有限制的触发条件。
    • 可以限制应用程序的内容和方式。
    • 应用程序如何免除此类限制。
    • 如果应用程序支持对用户可以安装的应用程序进行此类豁免，则应用程序如何请求豁免专有限制。

  如果某个应用程序预装在设备上并且用户从未明确使用超过 30 天，则 [C-1-3] [C-1-5] 免除。

• 3.8.1 启动器（主屏幕） ：更新以支持monochrome/adaptive-icon 。

  见修订

  如果设备实现支持单色图标，则这些图标：

  • [C-6-1] 必须仅在用户明确启用它们时使用（例如通过“设置”或壁纸选择器菜单）。

• 3.8.2 小部件：更新到启动器中存在的第三方应用程序小部件。

  见修订

  如果设备实现支持第三方应用小部件，则它们：

  • [C-1-2] 必须包含对 AppWidget 的内置支持，并公开用户界面可供性以添加、配置、查看和删除 AppWidget直接在启动器中。

• 3.8.3.1 通知的呈现：澄清提示通知的定义。

  见修订

  Heads up notifications 是当它们独立于用户所在的表面而出现时呈现给用户的通知。

• 3.8.3.3 DND（请勿打扰）/优先模式：更新以在 DND（请勿打扰）要求中包含优先模式。

  见修订

  3.8.3.3. DND（请勿打扰） /优先模式

  如果设备实现支持 DND 功能（也称为优先模式），则它们：

• 3.8.6 主题：对动态色调调色板的新要求。

  见修订

  如果设备实现包括屏幕或视频输出，则：

  • [C-1-4] 必须按照Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES的 AOSP 文档中的规定生成动态色调调色板（请参阅android.theme.customization.system_palette和android.theme.customization.theme_style ）。

  • [C-1-5] 必须使用Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES文档（请参阅android.theme.customization.theme_styles ）中列举的颜色主题样式生成动态色调调色板，即TONAL_SPOT 、 VIBRANT 、 EXPRESSIVE 、 SPRITZ 、 RAINBOW 、 FRUIT_SALAD 。

    “源颜色”用于在与android.theme.customization.system_palette一起发送时生成动态色调调色板（如Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES中所述）。

  • [C-1-6] 必须具有 5 或更大的CAM16色度值。

    • 应通过com.android.systemui.monet.ColorScheme#getSeedColors从壁纸派生，它提供多种有效的源颜色以供选择。

    • 如果提供的颜色均不满足上述源颜色要求，则应使用值0xFF1B6EF3 。

• 3.8.17 剪贴板：添加了剪贴板上内容的新要求部分。

  见修订

  3.8.17.剪贴板

  设备实现：

  • [C-0-1] 不得将剪贴板数据发送到任何组件、活动、服务或通过任何网络连接，除非有明确的用户操作（例如，按下叠加层上的按钮）， 9.8.6 内容中提到的服务除外捕获和应用程序搜索。

  如果设备实现在将内容复制到任何ClipData项目的剪贴板时生成用户可见的预览，其中ClipData.getDescription().getExtras()包含android.content.extra.IS_SENSITIVE ，它们：

  • [C-1-1] 必须遮盖用户可见的预览

  AOSP 参考实现满足这些剪贴板要求。

• 3.9.1.1 设备所有者配置：更新设备所有者配置要求。

  见修订

  如果设备实现声明了android.software.device_admin ，它们：

  • [C-1-1] 必须支持将 Device Policy Client (DPC) 注册为Device Owner 应用，如下所述：
    • 当设备实现既没有配置用户也没有配置用户数据时，它：
      • [C-1-5] 如果设备通过该功能声明近场通信 (NFC) 支持，则必须将 DPC 应用注册为设备所有者应用，或者允许 DPC 应用选择成为设备所有者还是配置文件所有者标记android.hardware.nfc并接收包含 MIME 类型MIME_TYPE_PROVISIONING_NFC的记录的 NFC 消息。
      • [C-1-8] 必须在触发设备所有者配置后发送ACTION_GET_PROVISIONING_MODE Intent，以便 DPC 应用可以根据android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES的值选择是成为设备所有者还是配置文件所有者，除非it can be determined from context that there is only one valid option. (such as for NFC based provisioning where Profile Owner provisioning is not supported).
      • [C-1-9] MUST send the ACTION_ADMIN_POLICY_COMPLIANCE intent to the Device Owner app if a Device Owner is established during provisioning regardless of the provisioning method used. The user must not be able to proceed in the Setup Wizard until the Device Owner app finishes.
    • When the device implementation has users or user data, it:
      • [C-1-7] MUST not enroll any DPC application as the Device Owner App any more.
  • [C-1-2] MUST show an appropriate disclosure notice (such as referenced in AOSP ) and obtain affirmative consent from the end user prior to an app being set as Device Owner, unless the device is programmatically configured for retail demo mode prior to on-screen, end-user interaction. require some affirmative action before or during the provisioning process to consent to an app being set as Device Owner. Consent can be via user action or by some programmatic means but appropriate disclosure notice (as referenced in AOSP) MUST be shown before device owner provisioning is initiated. Also, the programmatic device owner consent mechanism used (by enterprises) for device owner provisioning MUST NOT interfere with the Out-Of-Box Experience for non-enterprise use.
  • [C-1-3] MUST NOT hard code the consent or prevent the use of other device owner apps.

  If device implementations declare android.software.device_admin , but also include a proprietary Device Owner device management solution and provide a mechanism to promote an application configured in their solution as a "Device Owner equivalent" to the standard "Device Owner" as recognized by the standard Android DevicePolicyManager APIs, they:

  • [C-2-1] MUST have a process in place to verify that the specific app being promoted belongs to a legitimate enterprise device management solution and has been configured in the proprietary solution to have the rights equivalent as a "Device Owner".
  • [C-2-2] MUST show the same AOSP Device Owner consent disclosure as the flow initiated by android.app.action.PROVISION_MANAGED_DEVICE prior to enrolling the DPC application as "Device Owner".
  • [C-2-3] MUST NOT hard code the consent or prevent the use of other device owner apps.
  • MAY have user data on the device prior to enrolling the DPC application as "Device Owner".

• 3.9.4 Device Management Role Requirements : Added a section for Device Management Role Requirements.

  See revision

  3.9.4 Device Policy Management Role Requirements

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

  • [C-1-1] MUST support the device policy management role as defined in section 9.1 . The application that holds the device policy management role MAY be defined by setting config_devicePolicyManagement to the package name. The package name MUST be followed by : and the signing certificate unless the application is preloaded.

  If a package name is not defined for config_devicePolicyManagement as described above:

  • [C-2-1] Device implementations MUST support provisioning without a device policy management role holder application ( AOSP provides a reference implementation ).

  If a package name is defined for config_devicePolicyManagement as described above:

  • [C-3-1] The application MUST be installed on all profiles for a user .
  • [C-3-2] Device implementations MAY define an application that updates the device policy management role holder before provisioning by setting config_devicePolicyManagementUpdater .

  If a package name is defined for config_devicePolicyManagementUpdater as described above:

  • [C-4-1] The application MUST be preinstalled on the device.
  • [C-4-2] The application MUST implement an intent filter which resolves android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER .

• 3.18 Contacts : Adding information for new contacts.

  See revision

  Default account for new contacts: Contacts Provider provides APIs to manage the setting of the default account when creating a new contact.

  If device implementations preload a contacts app, then the pre-loaded contacts app:

  • [C-2-1] MUST handle the intent ContactsContract.Settings.ACTION_SET_DEFAULT_ACCOUNT to launch a UI for account selection and save the setting to Contacts Provider when an account is selected.

  • [C-2-2] MUST honor the default account setting when handling Intent.ACTION_INSERT and Intent.ACTION_INSERT_OR_EDIT for the ContactsContracts.Contacts.CONTENT_TYPE and ContactsContract.RawContacts.CONTENT_TYPE by initially selecting the account.

4. Application Packaging Compatibility

• 4. Application Packaging Compatibility : Updates to APK Signature Scheme version.

  See revision

  Device implementations:

  • [C-0-2] MUST support verifying “.apk” files using the APK Signature Scheme v3.1 , APK Signature Scheme v3 , APK Signature Scheme v2 and JAR signing .

  • [C-0-9] MUST support verifying .apk files using the APK Signature Scheme v4 and APK Signature Scheme v4.1 .

5. Multimedia Compatibility

• 5.1.2 Audio Decoding : Added new requirements for decoders capable of outputting mutli-channel audio.

  See revision

  If device implementations support the decoding of AAC input buffers of multichannel streams (ie more than two channels) to PCM through the default AAC audio decoder in the android.media.MediaCodec API, then the following MUST be supported:

  • [C-7-1] MUST be able to be configured by the application using the decoding with the key KEY_MAX_OUTPUT_CHANNEL_COUNT to control whether the content is downmixed to stereo (when using a value of 2) or is output using the native number of channels (when using a value equal or greater to that number). For instance a value of 6 or greater would configure a decoder to output 6 channels when fed 5.1 content.
  • [C-7-2] When decoding, the decoder MUST advertise the channel mask being used on the output format with the KEY_CHANNEL_MASK key, using the android.media.AudioFormat constants (example: CHANNEL_OUT_5POINT1 ).

  If device implementations support audio decoders other than the default AAC audio decoder and are capable of outputting multi-channel audio (ie more than 2 channels) when fed compressed multi-channel content, then:

  • [C-SR] The decoder is STRONGLY RECOMMENDED to be able to be configured by the application using the decoding with the key KEY_MAX_OUTPUT_CHANNEL_COUNT to control whether the content is downmixed to stereo (when using a value of 2) or is output using the native number of channels (when using a value equal or greater to that number). For instance a value of 6 or greater would configure a decoder to output 6 channels when fed 5.1 content.
  • [C-SR] When decoding, the decoder is STRONGLY RECOMMENDED to advertise the channel mask being used on the output format with the KEY_CHANNEL_MASK key, using the android.media.AudioFormat constants (example: CHANNEL_OUT_5POINT1 ).

• 5.4.1 Raw Audio Capture and Microphone Information : Updates to supported audio sources for audio input streams.

  See revision

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

  • [C-1-1] MUST allow capture of raw audio content with the following characteristics for any AudioRecord or AAudio INPUT stream that is opened successfully. At a minimum, the following characteristics MUST be supported :

    • Format: Linear PCM, 16-bit
    • Sampling rates: 8000, 11025, 16000, 44100, 48000 Hz
    • Channels: Mono
    • Audio Sources: DEFAULT , MIC , CAMCORDER , VOICE_RECOGNITION , VOICE_COMMUNICATION , UNPROCESSED , or VOICE_PERFORMANCE . This also applies to the equivalent Input Presets in AAudio , for example, AAUDIO_INPUT_PRESET_CAMCORDER .
    • [C-1-4] MUST honor the MicrophoneInfo API and properly fill in information for the available microphones on device accessible to the third-party applications via the AudioManager.getMicrophones() API, for active AudioRecord using MediaRecorder.AudioSources DEFAULT , MIC , CAMCORDER , VOICE_RECOGNITION , VOICE_COMMUNICATION , UNPROCESSED , or VOICE_PERFORMANCE . and the currently active microphones which are accessible to the third party applications via the AudioRecord.getActiveMicrophones() and MediaRecorder.getActiveMicrophones() APIs.

• 5.4.2 Capture for Voice Recognition : Updated requirements for voice recognition audio stream and added requirements for microphone gain levels.

  See revision

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

  • SHOULD record the voice recognition audio stream with approximately flat amplitude versus frequency characteristics: specifically, ±3 dB, from 100 Hz to 4000 Hz.
  • SHOULD record the voice recognition audio stream with input sensitivity set such that a 90 dB sound power level (SPL) source at 1000 Hz yields RMS of 2500 for 16-bit samples.

  • SHOULD exhibit approximately flat amplitude-versus-frequency characteristics in the mid-frequency range: specifically ±3dB from 100 Hz to 4000 Hz for each and every microphone used to record the voice recognition audio source.
  • [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the low frequency range: specifically from ±20 dB from 30 Hz to 100 Hz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
  • [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the high frequency range: specifically from ±30 dB from 4000 Hz to 22 KHz compared to the mid-frequency range 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 next to the microphone) yields an ideal response of RMS 2500 within a range of 1770 and 3530 for 16 bit-samples (or -22.35 db ±3dB Full Scale for floating point/double precision samples) for each and every microphone used to record the voice recognition audio source.

• 5.4.6 Microphone Gain Levels : Moved requirements for Microphone Gain Levels to section 5.4.2.

  See revision

  5.4.6. Microphone Gain Levels [Moved to 5.4.2]

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

  • SHOULD exhibit approximately flat amplitude-versus-frequency characteristics in the mid-frequency range: specifically ±3dB from 100 Hz to 4000 Hz for each and every microphone used to record the voice recognition audio source.
  • [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the low frequency range: specifically from ±20 dB from 5 Hz to 100 Hz compared to the mid-frequency range for each and every microphone used to record the voice recognition audio source.
  • [C-SR] are STRONGLY RECOMMENDED to exhibit amplitude levels in the high frequency range: specifically from ±30 dB from 4000 Hz to 22 KHz compared to the mid-frequency range 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) yields a response with RMS of 2500 for 16 bit-samples (or -22.35 dB Full Scale for floating point/double precision samples) for each and every microphone used to record the voice recognition audio source.

• 5.5.4 Audio Offload : Updates to the audio offload playback requirements.

  See revision

  If device implementations support audio offload playback , they:

  • [C-SR] Are STRONGLY RECOMMENDED to trim the played gapless audio content between two clips with the same format when specified by the AudioTrack gapless API and the media container for MediaPlayer.

• 5.6 Audio Latency : Updates to the audio latency requirements.

  See revision

  For the purposes of this section, use the following definitions:

  • cold output jitter . The variability among separate measurements of cold output latency values.
  • cold input jitter . The variability among separate measurements of cold input latency values.

  If device implementations declare android.hardware.audio.output , they MUST meet or exceed the following requirements:

  • [C-1-2] Cold output latency of 500 milliseconds or less.
  • [C-1-3] Opening an output stream using AAudioStreamBuilder_openStream() MUST take less than 1000 milliseconds.

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

  • [C-SR] Cold output latency of 100 milliseconds or less over the speaker data path. Existing and new devices that run this version of Android are VERY STRONGLY RECOMMENDED to meet these requirements now. In a future platform release, we will require Cold output latency of 200 ms or less as a MUST.
  • [C-SR] Minimize the cold output jitter.

  If device implementations include android.hardware.microphone , they MUST meet these input audio requirements:

  • [C-3-2] Cold input latency of 500 milliseconds or less.
  • [C-3-3] Opening an input stream using AAudioStreamBuilder_openStream() MUST take less than 1000 milliseconds.

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

  • [C-SR] Cold input latency of 100 milliseconds or less over the microphone data path. Existing and new devices that run this version of Android are VERY STRONGLY RECOMMENDED to meet these requirements now. In a future platform release we will require Cold input latency of 200 ms or less as a MUST.

  • [C-SR] Continuous input latency of 30 milliseconds or less.
  • [C-SR] Minimize the cold input jitter.

• 5.10 Professional Audio : Updates to audio latency requirements for professional audio support.

  See revision

  If device implementations report support for feature android.hardware.audio.pro via the android.content.pm.PackageManager class, they:

  • [C-1-2] MUST have the continuous round-trip audio latency, as defined in section 5.6 Audio Latency of 25 milliseconds or less and SHOULD be 10 milliseconds or less over at least one supported path.
  • [C-1-5] MUST meet latencies and USB audio requirements using the AAudio native audio API and AAUDIO_PERFORMANCE_MODE_LOW_LATENCY .
  • [C-1-8] MUST have an average Tap-to-tone latency of 80 milliseconds or less over at least 5 measurements over the speaker to microphone data path.
  • [C-SR] Are STRONGLY RECOMMENDED to provide a consistent level of CPU performance while audio is active and CPU load is varying. This should be tested using the Android app SynthMark . SynthMark uses a software synthesizer running on a simulated audio framework that measures system performance. See the SynthMark documentation for an explanation of the benchmarks. The SynthMark app needs to be run using the “Automated Test” option and achieve the following results: * voicemark.90 >= 32 voices * latencymark.fixed.little <= 15 msec * latencymark.dynamic.little <= 50 msec
  • SHOULD have a latency from touch input to audio output of less than or equal to 40 ms.

  If device implementations include a 4 conductor 3.5mm audio jack, they:

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

• 5.12 HDR Video : Added a new section for HDR Video requirements.

6. Developer Tools and Options Compatibility

• 6.1 Developer Tools : Updates to connectivity and GPU Kernel requirements.

  See revision

  If device implementations support adb connections to a host machine via Wi-Fi or Ethernet , they:

  • [C-4-1] MUST have the AdbManager#isAdbWifiSupported() method return true .

  If device implementations support adb connections to a host machine via Wi-Fi or Ethernet , and includes at least one camera, they:

  • [C-5-1] MUST have the AdbManager#isAdbWifiQrSupported() method return true .

  • GPU work information

    Device implementations:

    • [C-6-1] MUST implement the shell command dumpsys gpu --gpuwork to display the aggregated GPU work data returned by the power/gpu_work_period kernel tracepoint, or display no data if the tracepoint is not supported. The AOSP implementation is frameworks/native/services/gpuservice/gpuwork/ .

7. Hardware Compatibility

• 7.1.4.1 OpenGL ES : Update to recommended extensions.

  See revision

  If device implementations support any of the OpenGL ES versions, they:

  • SHOULD support the EGL_IMG_context_priority and EGL_EXT_protected_content extensions.

• 7.1.4.2 Vulkan : Updates to version supported for Vulkan.

  See revision

  If device implementations support OpenGL ES 3.1, they:

  • [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.3 . Vulkan 1.1
  • MUST NOT support a Vulkan Variant version (ie the variant part of the Vulkan core version MUST be zero).

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

  • [SR] Are STRONGLY RECOMMENDED to include support for Vulkan 1.3 . Vulkan 1.1

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

  • SHOULD support VkPhysicalDeviceProtectedMemoryFeatures and VK_EXT_global_priority .
  • [C-1-12] MUST NOT enumerate support for the VK_KHR_performance_query extension.
  • [C-SR] Are STRONGLY RECOMMENDED to satisfy the requirements specified by the Android Baseline 2021 profile.

• 7.2.3 Navigation Keys :

  See revision

  Device implementations:

  • [C-SR] Are STRONGLY RECOMMENDED to provide all navigation functions as cancellable. 'Cancellable' is defined as the user's ability to prevent the navigation function from executing (eg going home, going back, etc.) if the swipe is not released past a certain threshold.

  If the back navigation function is provided and the user cancels the Back gesture, then:

  • [C-8-1] OnBackInvokedCallback.onBackCancelled() MUST be called.
  • [C-8-2] OnBackInvokedCallback.onBackInvoked() MUST NOT be called.
  • [C-8-3] KEYCODE_BACK event MUST NOT be dispatched.

  If the back navigation function is provided but the foreground application does NOT have an OnBackInvokedCallback registered, then:

  • The system SHOULD provide an animation for the foreground application that suggests that the user is going back, as provided in AOSP.

  If device implementations provide support for the system API setNavBarMode to allow any system app with android.permission.STATUS_BAR permission to set the navigation bar mode, then they:

  • [C-9-1] MUST provide support for kid-friendly icons or button-based navigation as provided in the AOSP code.

• 7.3.1 Accelerometer : Updates to sensor requirements for accelerometers.

  See revision

  If device implementations include an accelerometer, a 3-axis accelerometer, they:

  • [C-1-2] MUST implement and report TYPE_ACCELEROMETER sensor.
  • [SR] are STRONGLY RECOMMENDED to implement the TYPE_SIGNIFICANT_MOTION composite sensor.
  • [SR] are STRONGLY RECOMMENDED to implement and report TYPE_ACCELEROMETER_UNCALIBRATED sensor. Android devices are STRONGLY RECOMMENDED to meet this requirement so they will be able to upgrade to the future platform release where this might become REQUIRED.
  • SHOULD implement the TYPE_SIGNIFICANT_MOTION , TYPE_TILT_DETECTOR , TYPE_STEP_DETECTOR , TYPE_STEP_COUNTER composite sensors as described in the Android SDK document.

  If device implementations include a 3-axis accelerometer, they:

  • [C-2-1] MUST implement and report TYPE_ACCELEROMETER sensor.
  • [C-SR] Are STRONGLY RECOMMENDED to implement the TYPE_SIGNIFICANT_MOTION composite sensor.
  • [C-SR] Are STRONGLY RECOMMENDED to implement and report TYPE_ACCELEROMETER_UNCALIBRATED sensor. Android devices are STRONGLY RECOMMENDED to meet this requirement so they will be able to upgrade to the future platform release where this might become REQUIRED.
  • SHOULD implement the TYPE_SIGNIFICANT_MOTION , TYPE_TILT_DETECTOR , TYPE_STEP_DETECTOR , TYPE_STEP_COUNTER composite sensors as described in the Android SDK document.

  If device implementations include an accelerometer with less than 3 axes, they:

  • [C-3-1] MUST implement and report TYPE_ACCELEROMETER_LIMITED_AXES sensor.
  • [C-SR] Are STRONGLY_RECOMMENDED to implement and report TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED sensor.

  If device implementations include a 3-axis accelerometer and any of the TYPE_SIGNIFICANT_MOTION , TYPE_TILT_DETECTOR , TYPE_STEP_DETECTOR , TYPE_STEP_COUNTER composite sensors are implemented:

  • [C-4-1] The sum of their power consumption MUST always be less than 4 mW.

  If device implementations include a 3-axis accelerometer and a 3-axis gyroscope sensor, they:

  • [C-5-1] MUST implement the TYPE_GRAVITY and TYPE_LINEAR_ACCELERATION composite sensors.

  If device implementations include a 3-axis accelerometer, a 3-axis gyroscope sensor, and a magnetometer sensor, they:

  • [C-6-1] MUST implement a TYPE_ROTATION_VECTOR composite sensor.

• 7.3.4 Gyroscopes : Updates to sensor requirements for gyroscopes.

  See revision

  If device implementations include a gyroscope, they:

  • [C-1-1] MUST be able to report events up to a frequency of at least 50 Hz.
  • [C-1-4] MUST have a resolution of 12-bits or more.
  • [C-1-5] MUST be temperature compensated.
  • [C-1-6] MUST be calibrated and compensated while in use, and preserve the compensation parameters between device reboots.
  • [C-1-7] MUST have a variance no greater than 1e-7 rad^2 / s^2 per Hz (variance per Hz, or rad^2 / s). The variance is allowed to vary with the sampling rate, but MUST be constrained by this value. In other words, if you measure the variance of the gyro at 1 Hz sampling rate it SHOULD be no greater than 1e-7 rad^2/s^2.
  • [C-SR] Calibration error is STRONGLY RECOMMENDED to be less than 0.01 rad/s when device is stationary at room temperature.
  • [C-SR] Are STRONGLY RECOMMENDED to have a resolution of 16-bits or more.
  • SHOULD report events up to at least 200 Hz.

  If device implementations include a 3-axis gyroscope, they:

  • [C-2-1] MUST implement the TYPE_GYROSCOPE sensor.

  If device implementations include a gyroscope with less than 3 axes, they:

  • [C-3-1] MUST implement and report TYPE_GYROSCOPE_LIMITED_AXES sensor.
  • [C-SR] Are STRONGLY_RECOMMENDED to implement and report TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED sensor.

  If device implementations include a 3-axis gyroscope, an accelerometer sensor and a magnetometer sensor, they:

  • [C-4-1] MUST implement a TYPE_ROTATION_VECTOR composite sensor.

  If device implementations include a 3-axis accelerometer and a 3-axis gyroscope sensor, they:

  • [C-5-1] MUST implement the TYPE_GRAVITY and TYPE_LINEAR_ACCELERATION composite sensors.

• 7.3.10 Biometric Sensors : Updates to sensor requirements for biometric sensors.

  See revision

  Biometric sensors can be classified as Class 3 (formerly Strong ), Class 2 (formerly Weak ), or Class 1 (formerly Convenience ) based on their spoof and imposter acceptance rates, and on the security of the biometric pipeline. This classification determines the capabilities the biometric sensor has to interface with the platform and with third-party applications. Sensors need to meet additional requirements as detailed below if they wish to be classified as either Class 1 , Class 2 or Class 3 . Sensors are classified as Class 1 by default, and need to meet additional requirements as detailed below if they wish to be classified as either Class 2 or Class 3 . Both Class 2 and Class 3 biometrics get additional capabilities as detailed below.

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

  • [C-1-11] MUST have a spoof and imposter acceptance rate not higher than 30%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 30%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 40%, as measured by the Android Biometrics Test Protocols.

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

  • [C-2-2] MUST have a spoof and imposter acceptance rate not higher than 20%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 20%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 30%, as measured by the Android Biometrics Test Protocols .

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

  • [C-3-3] MUST have a spoof and imposter acceptance rate not higher than 7%, with (1) a spoof and imposter acceptance rate for Level A presentation attack instrument (PAI) species not higher than 7%, and (2) a spoof and imposter acceptance rate of Level B PAI species not higher than 20%, as measured by the Android Biometrics Test Protocols .

• 7.3.13 IEEE 802.1.15.4 (UWB) : Added a new requirements section for UWB.

  See revision

  7.3.13. IEEE 802.1.15.4 (UWB)

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

  • [C-1-1] MUST implement the corresponding Android API in android.uwb.
  • [C-1-2] MUST report the hardware feature flag android.hardware.uwb.
  • [C-1-3] MUST support all the relevant UWB profiles defined in Android implementation.
  • [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 UWB_RANGING permission (under NEARBY_DEVICES permission group).
  • [C-1-6] Are STRONGLY RECOMMENDED to pass the relevant conformance and certification tests defined by standard organizations, including FIRA , CCC and CSA .

• 7.4.1 Telephony : Updates to telephony requirements for GSM and CDMA telephony, and cellular usage settings.

  See revision

  If device implementations support eUICCs or eSIMs/embedded SIMs and include a proprietary mechanism to make eSIM functionality available for third-party developers, they:

  • [C-3-1] MUST declare the android.hardware.telephony.euicc feature flag. provide a complete implementation of the EuiccManager API .

  If device implementations include GSM or CDMA telephony, then:

  • [C-6-1] The SmsManager#sendTextMessage and SmsManager#sendMultipartTextMessage MUST result in corresponding calls to CarrierMessagingService for providing text messaging functionality. SmsManager#sendMultimediaMessage and SmsManager#downloadMultimediaMessage MUST result in corresponding calls to CarrierMessagingService for providing multimedia messaging functionality.
  • [C-6-2] The application designated by android.provider.Telephony.Sms#getDefaultSmsPackage MUST use SmsManager APIs when sending and receiving SMS and MMS messages. The AOSP reference implementation in packages/apps/Messaging meets this requirement.
  • [C-6-3] The application which responds to Intent#ACTION_DIAL MUST support entry of arbitrary dialer codes formatted as *#*#CODE#*#* and trigger a corresponding TelephonyManager#ACTION_SECRET_CODE broadcast.
  • [C-6-4] The application which responds to Intent#ACTION_DIAL MUST use VoicemailContract.Voicemails#TRANSCRIPTION to display visual voicemail transcription to users if it supports visual voicemail transcriptions.
  • [C-6-5] MUST represent all SubscriptionInfo with equivalent group UUIDs as a single subscription in all user-visible affordances that display and control SIM card information. Examples of such affordances include settings interfaces that match Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS or EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS .
  • [C-6-6] MUST NOT display or allow control of any SubscriptionInfo with a non-null group UUID and opportunistic bit in any user-visible affordances that allow configuration or control of SIM card settings.

  If the device device implementations include GSM or CDMA telephony and provide a system status bar, then:

  • [C-6-7] MUST select a representative active subscription for a given group UUID to display to the user in any affordances that provide SIM status information. Examples of such affordances include the status bar cellular signal icon or quick settings tile.
  • [C-SR] It is STRONGLY RECOMMENDED that the representative subscription is chosen to be the active data subscription unless the device is in a voice call, during which it is STRONGLY RECOMMENDED that the representative subscription is the active voice subscription.

  If device implementations include GSM or CDMA telephony, then:

  • [C-6-8] MUST be capable of opening and concurrently utilizing the maximum number of logical channels (20 in total) for each UICC per ETSI TS 102 221.
  • [C-6-10] MUST NOT apply any of the following behaviors to active carrier apps (as designated by TelephonyManager#getCarrierServicePackageName ) automatically or without explicit user confirmation:
    • Revoke or limit network access
    • Revoke permissions
    • Restrict background or foreground app execution beyond the existing power management features included in AOSP
    • Disable or uninstall the app

  If device device implementations include GSM or CDMA telephony and all active, non-opportunistic subscriptions that share a group UUID are disabled, physically removed from the device, or marked opportunistic, then the device:

  • [C-7-1] MUST automatically disable all remaining active opportunistic subscriptions in the same group.

  If device implementations include GSM telephony but not CDMA telephony, they:

  • [C-8-1] MUST NOT declare PackageManager#FEATURE_TELEPHONY_CDMA .
  • [C-8-2] MUST throw an IllegalArgumentException upon attempts to set any 3GPP2 network types in preferred or allowed network type bitmasks.
  • [C-8-3] MUST return an empty string from TelephonyManager#getMeid .

  If the device implementations support eUICCs with multiple ports and profiles, they:

  • [C-11-1] MUST declare the android.hardware.telephony.euicc.mep feature flag.

• 7.4.1.1 Number Blocking Compatibility : Updates to the number blocking requirements.

  See revision

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

  • [C-1-4] MUST NOT write to the platform call log provider for a blocked call.

  • [C-1-4] MUST write to the platform call log provider for a blocked call and MUST filter calls with BLOCKED_TYPE out of the default call log view in the pre-installed dialer app.
  • SHOULD provide a user affordance to show blocked calls in the pre-installed dialer app.

• 7.4.1.3 Cellular NAT-T Keepalive Offload : New section for Cellular NAT-T Keepalive Offload.

  See revision

  7.4.1.3. Cellular NAT-T Keepalive Offload

  Device implementations:

  • SHOULD include support for Cellular keepalive offload.

  If device implementations include support for Cellular keepalive offload and exposes the functionality to third-party apps, they:

  • [C-1-1] MUST support the SocketKeepAlive API.
  • [C-1-2] MUST support at least one concurrent keepalive slot over cellular.
  • [C-1-3] MUST support as many concurrent cellular keepalive slots as are supported by the Cellular Radio HAL.
  • [C-SR] Are STRONGLY RECOMMENDED to support at least three cellular keepalive slots per radio instance.

  If device implementations do not include support for cellular keepalive offload, they:

  • [C-2-1] MUST return ERROR_UNSUPPORTED.

• 7.4.2.5 Wi-Fi Location (Wi-Fi Round Trip Time - RTT) : Updates to Wi-Fi location accuracy.

  See revision

  If device implementations include support for Wi-Fi Location and expose the functionality to third-party apps, then they:

  • [C-1-4] MUST be accurate to within 2 meters at 80 MHz bandwidth at the 68th percentile (as calculated with the Cumulative Distribution Function).
  • [C-SR] Are STRONGLY RECOMMENDED to report it accurately to within 1.5 meters at 80 MHz bandwidth at the 68th percentile (as calculated with the Cumulative Distribution Function).

• 7.4.2.6 Wi-Fi Keepalive Offload : Updated to add cellular keepalive offload requirements.

  See revision

  Device implementations:

  • SHOULD include support for Wi-Fi keepalive offload.

  If device implementations include support for Wi-Fi keepalive offload and expose the functionality to third-party apps, they:

  • [C-1-1] MUST support the SocketKeepAlive API.
  • [C-1-2] MUST support at least three concurrent keepalive slots over Wi-Fi
    and at least one keepalive slot over cellular.

  If device implementations do not include support for Wi-Fi keepalive offload, they:

  • [C-2-1] MUST return ERROR_UNSUPPORTED .

• 7.4.2.9 Trust On First Use (TOFU) : Added Trust on First Use requirements section.

  See revision

  7.4.2.9 Trust On First Use (TOFU)

  If device implementations support Trust on first usage (TOFU) and allow the user to define WPA/WPA2/WPA3-Enterprise configurations, then they:

  • [C-4-1] MUST provide the user an option to select to use TOFU.

• 7.4.3 Bluetooth : Update to Bluetooth requirements.

  See revision

  If device implementations support Bluetooth Audio profile, they:

  • SHOULD support Advanced Audio Codecs and Bluetooth Audio Codecs (eg LDAC) with A2DP.

  If device implementations return true for the BluetoothAdapter.isLeAudioSupported() API, then they:

  • [C-7-1] MUST support unicast client.
  • [C-7-2] MUST support 2M PHY.
  • [C-7-3] MUST support LE Extended advertising.
  • [C-7-4] MUST support at least 2 CIS connections in a CIG.
  • [C-7-5] MUST enable BAP unicast client, CSIP set coordinator, MCP server, VCP controller, CCP server simultaneously.
  • [C-SR] Are STRONGLY RECOMMENDED to enable HAP unicast client.

  If device implementations return true for the BluetoothAdapter.isLeAudioBroadcastSourceSupported() API, then they:

  • [C-8-1] MUST support at least 2 BIS links in a BIG.
  • [C-8-2] MUST enable BAP broadcast source, BAP broadcast assistant simultaneously.
  • [C-8-3] MUST support LE Periodic advertising.

  If device implementations return true for the BluetoothAdapter.isLeAudioBroadcastAssistantSupported() API, then they:

  • [C-9-1] MUST support PAST (Periodic Advertising Sync Transfer).
  • [C-9-2] MUST support LE Periodic advertising.

  If device implementations declare FEATURE_BLUETOOTH_LE , they:

  • [C-10-1] MUST have RSSI measurements be within +/-9dB for 95% of the measurements at 1m distance from a reference device transmitting at ADVERTISE_TX_POWER_HIGH in line of sight environment.
  • [C-10-2] MUST include Rx/Tx corrections to reduce per-channel deviations so that the measurements on each of the 3 channels, on each of the antennas (if multiple are used), are within +/-3dB of one another for 95% of the measurements.
  • [C-SR] 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] 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.

  It is STRONGLY RECOMMENDED to follow the measurement setup steps specified in Presence Calibration Requirements .

  If device implementations support Bluetooth version 5.0, then they:

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

• 7.4.9 UWB : Added a requirements section for UWB hardware.

  See revision

  7.4.9. UWB

  If device implementations report support for feature android.hardware.uwb via the android.content.pm.PackageManager class, then they:

  • [C-1-1] MUST ensure the distance measurements are within +/-15 cm for 95% of the measurements in the line of sight environment at 1m distance in a non-reflective chamber.
  • [C-1-2] 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.

  It is STRONGLY RECOMMENDED to follow the measurement setup steps specified in Presence Calibration Requirements .

• 7.5 Cameras : Updates to the requirements for HDR 10-bit output capability.

  See revision

  If device implementations support HDR 10-bit output capability, then they:

  • [C-2-1] MUST support at least the HLG HDR profile for every camera device that supports 10-bit output.
  • [C-2-2] MUST support 10-bit output for either the primary rear-facing or the primary front-facing camera.
  • [C-SR] Are STRONGLY RECOMMENDED to support 10-bit output for both primary cameras.
  • [C-2-3] MUST support the same HDR profiles for all BACKWARD_COMPATIBLE-capable physical sub-cameras of a logical camera, and the logical camera itself.

  For Logical camera devices which support 10-bit HDR that implement the android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO API, they:

  • [C-3-1] MUST support switching between all the backwards-compatible physical cameras via the CONTROL_ZOOM_RATIO control on the logical camera.

• 7.7.2 USB Host Mode : Revisions for dual role ports.

  See revision

  If device implementations include a USB port supporting host mode and USB Type-C, they:

  • [C-4-1] MUST implement Dual Role Port functionality as defined by the USB Type-C specification (section 4.5.1.3.3). For Dual Role Ports, On devices that include a 3.5mm audio jack, the USB sink detection (host mode) MAY be off by default but it MUST be possible for the user to enable it.

• 7.11 Media Performance Class : Updated to include Android T.

  See revision

  If device implementations return non-zero value for android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS , they:

  • [C-1-3] MUST meet all requirements for "Media Performance Class" described in section 2.2.7 .

  In other words, media performance class in Android T is only defined for handheld devices at version T, S or R.

  See section 2.2.7 for device-specific requirements.

9. Security Model Compatibility

• 9.1 Permissions : Extend accepted paths for permissions allowlists for preinstalled apps to APEX files.

  See revision

  • [C-0-2] Permissions with a protectionLevel of PROTECTION_FLAG_PRIVILEGED MUST only be granted to apps preinstalled in the privileged path(s) of the system image (as well as APEX files ) and be within the subset of the explicitly allowlisted permissions for each app. The AOSP implementation meets this requirement by reading and honoring the allowlisted permissions for each app from the files in the etc/permissions/ path and using the system/priv-app path as the privileged path.

• 9.7 Security Features : Updates to initialization requirements to maintain kernel integrity.

  See revision

  Kernel integrity and self-protection features are integral to Android security. Device implementations:

  • [C-SR] Are STRONGLY RECOMMENDED to enable stack initialization in the kernel to prevent uses of uninitialized local variables ( CONFIG_INIT_STACK_ALL or CONFIG_INIT_STACK_ALL_ZERO ). Also, device implementations SHOULD NOT assume the value used by the compiler to initialize the locals.

• 9.8.7 Privacy — Clipboard Access : Automatically clear clipboard data after 60 minutes following a cut/copy/paste activity to protect user privacy.

  See revision

  Device implementations:

  • [C-0-1] MUST NOT return a clipped data from the clipboard (eg via the ClipboardManager API) unless the 3rd-party app is the default IME or is the app that currently has focus.
  • [C-0-2] MUST clear clipboard data at most 60 minutes after it has last been placed in a clipboard or read from a clipboard.

• 9.11 Keys and Credentials : Updates to the secure lock screen requirements, including the addition of ECDH and 3DES to crypto algorithms.

  See revision

  When the device implementation supports a secure lock screen, it:

  • [C-1-2] MUST have implementations of RSA, AES, ECDSA, ECDH (if IKeyMintDevice is supported), 3DES, and HMAC cryptographic algorithms and MD5, SHA1, and SHA-2 family hash functions to properly support the Android Keystore system's supported algorithms in an area that is securely isolated from the code running on the kernel and above. Secure isolation MUST block all potential mechanisms by which kernel or userspace code might access the internal state of the isolated environment, including DMA. The upstream Android Open Source Project (AOSP) meets this requirement by using the Trusty implementation, but another ARM TrustZone-based solution or a third-party reviewed secure implementation of a proper hypervisor-based isolation are alternative options.

• 9.11.1 Secure Lock Screen, Authentication, and Virtual Devices : Added requirements section for virtual devices and authentication transfers.

  See revision

  If device implementations add or modify the authentication methods to unlock the lock screen and a new authentication method is based on a physical token or the location:

  • [C-6-3] The user MUST be challenged for one of the recommended primary authentication methods (egPIN, pattern, password) at least once every 4 hours or less. When a physical token meets the requirements for TrustAgent implementations in CX, timeout restrictions defined in C-9-5 apply instead.

  If device implementations allow applications to create secondary virtual displays and do not support associated input events, such as via VirtualDeviceManager , they:

  • [C-9-1] MUST lock these secondary virtual display(s) when the device's default display is locked, and unlock these secondary virtual display(s) when the device's default display is unlocked.

  If device implementations allow applications to create secondary virtual displays and support associated input events, such as via VirtualDeviceManager , they:

  • [C-10-1] MUST support separate lock states per virtual device
  • [C-10-2] MUST disconnect all virtual devices upon idle timeout
  • [C-10-3] MUST have an idle timeout
  • [C-10-4] MUST lock all displays when the user initiates a lockdown , including via the lockdown user affordance required for handheld devices (see Section 2.2.5[9.11/H-1-2] )
  • [C-10-5] MUST have separate virtual device instances per user
  • [C-10-6] MUST disable the creation of associated input events via VirtualDeviceManager when indicated by DevicePolicyManager.setNearbyAppStreamingPolicy
  • [C-10-7] MUST use a separate clipboard solely for each virtual device (or disable the clipboard for virtual devices)
  • [C-10-11] MUST disable authentication UI on virtual devices, including knowledge factor entry and biometric prompt
  • [C-10-12] MUST restrict intents initiated from a virtual device to display only on the same virtual device
  • [C-10-13] MUST not use a virtual device lock state as user authentication authorization with the Android Keystore System. See KeyGenParameterSpec.Builder.setUserAuthentication* .

  When device implementations allow the user to transfer the primary authentication knowledge-factor from a source device to a target device, such as for initial setup of the target device, they:

  • [C-11-1] MUST encrypt the knowledge-factor with protection guarantees similar to those described in the Google Cloud Key Vault Service security whitepaper when transferring the knowledge-factor from the source device to the target device such that the knowledge-factor cannot be remotely decrypted or used to remotely unlock either device.
  • [C-11-2] MUST, on the source device , ask the user to confirm the knowledge-factor of the source device before transferring the knowledge-factor to the target device.
  • [C-11-3] MUST, on a target device lacking any set primary authentication knowledge-factor, ask the user to confirm a transferred knowledge-factor on the target device before setting that knowledge-factor as the primary authentication knowledge-factor for the target device and before making available any data transferred from a source device.

  If device implementations have a secure lock screen and include one or more trust agents, which call the TrustAgentService.grantTrust() System API with the FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE flag they:

  • [C-12-1] MUST only call grantTrust() with the flag when connected to a proximate physical device with a lockscreen of its own, and when the user has authenticated their identity against that lockscreen. Proximate devices can use on-wrist or on-body detection mechanisms after a one-time user unlock to satisfy the user authentication requirement.
  • [C-12-2] MUST put the device implementation into the TrustState.TRUSTABLE state when the screen is turned off (such as via a button press or display time out) and the TrustAgent has not revoked trust. The AOSP satisfies this requirement.
  • [C-12-3] MUST only move the device from TrustState.TRUSTABLE to the TrustState.TRUSTED state if the TrustAgent is still granting trust based on the requirements in C-12-1.
  • [C-12-4] MUST call TrustManagerService.revokeTrust() after a maximum of 24 hours from granting trust, an 8 hour idle window, or when the underlying connection to the proximate physical device is lost.

  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-8] MUST block activities with the attribute android:canDisplayOnRemoteDevices or the meta-data android.activity.can_display_on_remote_devices set to false from being started on the virtualdevice.
  • [C-13-9] MUST block activities which do not explicitly enable streaming and which indicate they show sensitive content, including via SurfaceView#setSecure, FLAG_SECURE, or SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS, from being started on the virtual device.
  • [C-13-10] MUST disable installation of apps initiated from virtual devices.

• 9.11.2 Strongbox : Making insider attack resistance (IAR) a necessary requirement.

  See revision

  To validate compliance with [C-1-3] through [C-1-9], device implementations:

  • [C-SR] are STRONGLY RECOMMENDED to provide insider attack resistance (IAR), which means that an insider with access to firmware signing keys cannot produce firmware that causes the StrongBox to leak secrets, to bypass functional security requirements or otherwise enable access to sensitive user data. The recommended way to implement IAR is to allow firmware updates only when the primary user password is provided via the IAuthSecret HAL. IAR will become a MUST requirement in Android 14 (AOSP experimental).

• 9.11.3 Identity Credential : Added information about the Identity Credential system reference implementation.

  See revision

  The Identity Credential System is defined and achieved by implementing all APIs in the android.security.identity.* package. These APIs allows app developers to store and retrieve user identity documents. Device implementations:

  The upstream Android Open Source Project provides a reference implementation of a trusted application ( libeic ) that can be used to implement the Identity Credential system.

• 9.11.4 ID Attestation : Added a section for ID attestation requirement.

  See revision

  9.11.4. ID Attestation

  Device implementations MUST support ID attestation .

• 9.17 Android Virtualization Framework : Added a requirements section for Android Virtualization Framework.

  See revision

  9.17. Android Virtualization Framework

  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.
  • [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 NOT allow untrusted code (eg 3p apps) to create and run a Protected Virtual Machine. Note: This might change in future Android releases.
  • [C-1-5] MUST NOT allow a Protected Virtual Machine to execute code that is not part of the factory image or their updates. Anything that is not covered by Android Verified Boot (eg files downloaded from the Internet or sideloaded) MUST NOT be allowed to be run in a Protected Virtual Machine.

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

  • [C-2-1] MUST be able to run all operating systems available in the virtualization APEX in a Protected Virtual Machine.
  • [C-2-2] MUST NOT allow a Protected Virtual Machine to run an operating system that is not signed by the device implementor or OS vendor.
  • [C-2-3] MUST NOT allow a Protected Virtual Machine to execute data as code (eg SELinux neverallow execmem).
  • [C-2-4] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy/microdroid provided in the upstream Android Open Source Project (AOSP).
  • [C-2-5] MUST implement Protected Virtual Machine defense-in-depth mechanisms (eg SELinux for pVMs) even for non-Microdroid operating systems.
  • [C-2-6] MUST ensure that the pVM firmware refuses to boot if it cannot verify the initial image.
  • [C-2-7] MUST ensure that the pVM firmware refuses to boot if the integrity of the instance.img is compromised.

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

  • [C-3-1] MUST NOT allow any pVM to have access to a page belonging to another entity (ie 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 VM and before it is returned to the host (eg the pVM is destroyed).
  • [C-3-3] MUST ensure that the pVM firmware is loaded and executed prior to any code in a pVM.
  • [C-3-4] MUST ensure that BCC and CDIs provided to a pVM instance can only be derived by that particular instance.

  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 support Isolated Compilation 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-6-2] MUST do DICE properly ie provide the correct values. But it might not have to go to that level of detail.

Back to top