Android 14 兼容性定义

1. 简介

本文档枚举了设备必须满足哪些要求才能与 Android 14 兼容。

本文档按照 RFC2119 中定义的 IETF 标准使用“必须”“不得”“必需”“会”“不会”“应”“不应”“建议”“可以”和“可选”字样。

在本文档中，“设备实现者”或“实现者”指的是运行 Android 14 的硬件/软件解决方案的开发人员或组织。“设备实现”或“实现”指的是所开发的硬件/软件解决方案。

设备实现必须满足此兼容性定义文档（包括以参考资料的形式纳入的任何文档）中列出的要求，才会被视为与 Android 14 兼容。

本定义或第 10 节中所述的软件测试如有未提及、含糊不清或不完整之处，设备实现者需负责确保与现有实现兼容。

因此，Android 开源项目既是参考 Android 实现，也是首选 Android 实现。强烈建议设备实现者尽可能使其实现基于 Android 开源项目提供的“上游”源代码。虽然从理论上来说某些组件可以替换为备用实现，但强烈建议不要这样做，否则通过软件测试的难度会大大增加。实现者需负责确保行为与标准 Android 实现（包括兼容性测试套件及其他内容）完全兼容。最后请注意，本文档明确禁止替换和修改某些组件。

本文档中链接到的许多资源都直接或间接来自 Android SDK，并且与该 SDK 的文档中包含的信息作用相同。如果本兼容性定义文档或兼容性测试套件与 SDK 文档有任何不一致的情况，均以 SDK 文档为准。本文档中链接到的资源内提供的所有技术详细信息都被视为本兼容性定义文档的一部分。

1.1 文档结构

1.1.1. 针对各种设备类型的要求

第 2 节中包含适用于特定设备类型的所有要求。第 2 节中的每个小节均分别针对一种特定设备类型。

第 2 节之后的各节中列出了普遍适用于所有 Android 设备实现的所有其他要求。本文档中将这些要求称为“核心要求”。

1.1.2. 要求 ID

“必须”满足的要求都被分配了要求 ID。

  • 仅“必须”满足的要求被分配了 ID。
  • “强烈建议”满足的要求带有 [SR] 标记，但未被分配 ID。
  • ID 由以下部分构成：设备类型 ID - 条件 ID - 要求 ID（例如 C-0-1）。

每个 ID 的定义如下：

  • 设备类型 ID（如需了解详情，请参阅 2. 设备类型）
    • C：核心（适用于所有 Android 设备实现的要求）
    • H：Android 手持设备
    • T：Android TV 设备
    • A：Android Automotive 实现
    • W：Android Watch 实现
    • Tab：Android 平板电脑实现
  • 条件 ID
    • 如果要求是无条件的，此 ID 会被设置为 0。
    • 如果要求是有条件的，在同一节的同一设备类型下，第 1 个条件分配到的 ID 为 1，后续条件分配到的 ID 依次递增 1。
  • 要求 ID
    • 在同一节的同一条件下，第 1 项要求的 ID 为 1，后续要求的 ID 则依次递增 1。

1.1.3. 第 2 节中的要求 ID

第 2 节中的要求 ID 包含两个部分。第一个部分对应于如上所述的小节 ID。第二个部分标识外形规格和特定于外形规格的要求。

小节 ID 后跟上述要求 ID。

  • 第 2 节中的 ID 由以下部分构成：小节 ID/设备类型 ID - 条件 ID - 要求 ID（例如 7.4.3/A-0-1）。

2. 设备类型

Android 开源项目提供了一个可用于各种设备类型和外形规格的软件堆栈。为了保护设备的安全性，软件堆栈（包括任何替代操作系统或备用内核实现）应在第 9 节以及本 CDD 其他部分所述的安全环境中执行。有些设备类型具有相对来说更为完善的应用分发生态系统。

本节介绍了这些设备类型，以及适用于每种设备类型的额外要求和建议。

不属于任何所述设备类型的所有 Android 设备实现仍必须满足本兼容性定义文档其他各节中的所有要求。

2.1 设备配置

如需了解各种设备类型在硬件配置方面的主要区别，请参阅本节中随后介绍的设备特定要求。

2.2. 手持设备相关要求

Android 手持设备指的是一种 Android 设备实现，通常拿在手中使用，例如 mp3 播放器、手机或平板电脑。

满足以下所有条件的 Android 设备实现可归类为手持设备：

  • 具有能够使设备实现移动性的电源，例如电池。
  • 屏幕的物理对角线尺寸介于 4 英寸3.3 英寸（对于搭载 API 级别 29 或更低级别的设备实现，则为 2.5 英寸）到 8 英寸之间。
  • 具有触摸屏输入界面。

本节其余部分中的附加要求针对的是 Android 手持设备实现。

注意：不适用于 Android 平板电脑设备的要求带有 * 标记。

2.2.1. 硬件

手持设备实现：

  • [7.1.1.1/H-0-1] 必须具有至少一个满足本文档中所述的全部要求的短边尺寸至少为 2.2 英寸，长边尺寸至少为 3.4 英寸的 Android 兼容屏幕。

  • [7.1.1.3/H-SR-1] 强烈建议为用户提供一种用于更改显示大小（屏幕密度）的方式。

  • [7.1.1.1/H-0-2] 必须支持图形缓冲区的 GPU 合成，其大小至少与任何内置屏幕的最高分辨率一样大。

新要求开始

  • [7.1.1.1/H-0-3]* 必须将提供给第三方应用的每个 UI_MODE_NORMAL 屏幕映射到一个无遮挡的实体屏幕区域，该区域的短边至少为 2.2 英寸，长边至少为 3.4 英寸。

  • [7.1.1.3/H-0-1]* 必须将 DENSITY_DEVICE_STABLE 的值设置为 92% 或大于相应屏幕的实际物理密度。

新要求结束

如果手持设备实现支持软件屏幕旋转，则：

  • [7.1.1.1/H-1-1]* 必须使提供给第三方应用的逻辑屏幕的短边尺寸至少为 5.1 厘米（2 英寸），长边尺寸至少为 6.9 厘米（2.7 英寸）。 搭载 Android API 级别 29 或更低版本的设备可以免于遵守此要求。

如果手持设备实现不支持软件屏幕旋转，则：

  • [7.1.1.1/H-2-1]* 提供给第三方应用的逻辑屏幕的短边尺寸必须至少为 2.7 英寸。搭载 Android API 级别 29 或更低版本的设备可以免于遵守此要求。

如果手持设备实现通过 Configuration.isScreenHdr() 声明支持高动态范围屏幕，则：

  • [7.1.4.5/H-1-1] 必须通告对 EGL_EXT_gl_colorspace_bt2020_pq、EGL_EXT_surface_SMPTE2086_metadata、EGL_EXT_surface_CTA861_3_metadata、VK_EXT_swapchain_colorspace 和 VK_EXT_hdr_metadata 扩展的支持。

手持设备实现：

  • [7.1.4.6/H-0-1] 必须通过系统属性 graphics.gpu.profiler.support 报告设备是否支持 GPU 性能剖析功能。

如果手持设备实现通过系统属性 graphics.gpu.profiler.support 声明支持，则：

手持设备实现：

  • [7.1.5/H-0-1] 必须支持上游 Android 开放源代码所实现的旧版应用兼容模式。也就是说，设备实现不得更改启用兼容模式的触发条件或阈值，也不得更改兼容模式本身的行为。
  • [7.2.1/H-0-1] 必须支持第三方输入法 (IME) 应用。
  • [7.2.3/H-0-2] 必须将“返回”功能 (KEYCODE_BACK) 的常规按下事件和长按事件都发送到前台应用。上述事件不得被系统占用，且可从 Android 设备外部触发（例如，连接到 Android 设备的外部硬件键盘）。
  • [7.2.3/H-0-3] 必须在提供主屏幕的所有 Android 兼容屏幕上提供“主屏幕”功能。
  • [7.2.3/H-0-4] 必须在所有 Android 兼容屏幕上提供“返回”功能，并至少在其中一个 Android 兼容屏幕上提供“最近用过”功能。
  • [7.2.4/H-0-1] 必须支持触摸屏输入。
  • [7.2.4/H-SR-1] 强烈建议启动用户选择的辅助应用（也就是实现 VoiceInteractionService 的应用）或在长按 KEYCODE_MEDIA_PLAY_PAUSE 或 KEYCODE_HEADSETHOOK 时负责处理 ACTION_ASSIST 的 activity（如果前台 activity 不处理上述长按事件）。
  • [7.3.1/H-SR-1] 强烈建议包含 3 轴加速度计。

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

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

如果手持设备实现包含 GPS/GNSS 接收器，并且通过 android.hardware.location.gps 功能标志向应用报告该功能，则：

  • [7.3.3/H-2-1] 必须在发现 GNSS 测量结果后立即报告，即使尚未报告通过 GPS/GNSS 计算出的位置信息也是如此。
  • [7.3.3/H-2-2] 必须报告 GNSS 伪距和伪距率，确保在确定位置之后，在露天条件下，当设备处于静止状态或以小于 0.2 m/s² 的加速度移动时，至少在 95% 的情况下能够计算出 20 米以内的位置以及 0.2 m/s 以内的速度。

如果手持设备实现包含 3 轴陀螺仪，则：

  • [7.3.4/H-3-1] 必须能够以至少 100 Hz 的频率报告事件。
  • [7.3.4/H-3-2] 必须能够测量高达 1,000 度/秒的方向变化。

如果手持设备实现可以进行语音通话，并且在 getPhoneType 中指出了 PHONE_TYPE_NONE 以外的任何其他值，则：

  • [7.3.8/H] 应包含近程传感器。

手持设备实现：

  • [7.3.11/H-SR-1] 强烈建议支持具有 6 个自由度的姿势传感器。
  • [7.4.3/H] 应支持蓝牙和蓝牙 LE。

如果设备通过声明 PackageManager.FEATURE_WIFI_AWARE 支持 Wi-Fi 近邻感知网络 (NAN) 协议，及通过声明 PackageManager.FEATURE_WIFI_RTT 支持 Wi-Fi 位置信息（Wi-Fi 往返时间 - RTT），则：

  • [7.4.2.5/H-1-1] 根据通过 WifiRttManager#startRanging Android API 观察到的测距结果，对于在 10 厘米、1 米、3 米和 5 米的距离上进行的测量，报告范围时必须在 160 MHz 带宽的第 68 个百分位处精确到 +/-1 米以内（使用累积分布函数计算得出）；在 80 MHz 带宽的第 68 个百分位处精确到 +/-2 米以内；在 40 MHz 带宽的第 68 个百分位处精确到 +/-4 米以内；在 20 MHz 带宽的第 68 个百分位处精确到 +/-8 米以内。

  • [7.4.2.5/H-SR-1] 根据通过 WifiRttManager#startRanging Android API 观察到的测距结果，对于在 10 厘米的距离上进行的测量，报告范围时强烈建议在 160 MHz 带宽的第 90 个百分位处精确到 +/-1 米以内（使用累积分布函数计算得出）；在 80 MHz 带宽的第 90 个百分位处精确到 +/-2 米以内；在 40 MHz 带宽的第 90 个百分位处精确到 +/-4 米以内；在 20 MHz 带宽的第 90 个百分位处精确到 +/-8 米以内。

强烈建议遵循距离测量校准中指定的测量设置步骤。

新要求开始

如果手持设备实现声明 FEATURE_BLUETOOTH_LE，则：

  • [7.4.3/H-1-3] 必须测量并补偿 Rx 偏移，以确保在与以 ADVERTISE_TX_POWER_HIGH 进行传输的参考设备相距 1 米时，BLE RSSI 中位数为 -50dBm +/-15 dB。
  • [7.4.3/H-1-4] 必须测量并补偿 Tx 偏移，以确保从相距 1 米且以 ADVERTISE_TX_POWER_HIGH 进行传输的参考设备扫描时，BLE RSSI 中位数为 -50dBm +/-15 dB。

新要求结束

如果手持设备实现包含按流量计费的网络连接，则：

  • [7.4.7/H-1-1] 必须提供流量节省程序模式。

如果手持设备实现包含使用 CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA 列出功能的逻辑摄像头设备，则：

  • [7.5.4/H-1-1] 必须默认具有常规视野范围 (FOV)，且该范围必须在 50 度到 95 度之间。

手持设备实现：

  • [7.6.1/H-0-1] 必须有至少 4 GB 的非易失性存储空间可用于存储应用专属数据（该空间也称为“/data”分区）。
  • [7.6.1/H-0-2] 可供内核和用户空间使用的内存少于 1 GB 时，必须针对 ActivityManager.isLowRamDevice() 返回“true”。

如果手持设备实现声明仅支持 32 位 ABI，则：

  • [7.6.1/H-1-1] 如果默认屏幕使用最高可达 qHD 的帧缓冲区分辨率（例如 FWVGA），可供内核和用户空间使用的内存必须至少为 416 MB。

  • [7.6.1/H-2-1] 如果默认屏幕使用最高可达 HD+ 的帧缓冲区分辨率（例如 HD、WSVGA），可供内核和用户空间使用的内存必须至少为 592 MB。

  • [7.6.1/H-3-1] 如果默认屏幕使用最高可达 FHD 的帧缓冲区分辨率（例如 WSXGA+），可供内核和用户空间使用的内存必须至少为 896 MB。

  • [7.6.1/H-4-1] 如果默认屏幕使用最高可达 QHD 的帧缓冲区分辨率（例如 QWXGA），可供内核和用户空间使用的内存必须至少为 1,344 MB。

如果手持设备实现声明支持任何 64 位 ABI（无论是否支持任何 32 位 ABI），则：

  • [7.6.1/H-5-1] 如果默认屏幕使用最高可达 qHD 的帧缓冲区分辨率（例如 FWVGA），可供内核和用户空间使用的内存必须至少为 816 MB。

  • [7.6.1/H-6-1] 如果默认屏幕使用最高可达 HD+ 的帧缓冲区分辨率（例如 HD、WSVGA），可供内核和用户空间使用的内存必须至少为 944 MB。

  • [7.6.1/H-7-1] 如果默认屏幕使用最高可达 FHD 的帧缓冲区分辨率（例如 WSXGA+），可供内核和用户空间使用的内存必须至少为 1,280 MB。

  • [7.6.1/H-8-1] 如果默认屏幕使用最高可达 QHD 的帧缓冲区分辨率（例如 QWXGA），可供内核和用户空间使用的内存必须至少为 1,824 MB。

请注意，上文提到的“可供内核和用户空间使用的内存”是指除了已专门用于硬件组件（例如设备实现上的无线装置、视频组件，以及其他不受内核控制的组件）的所有内存之外，另行提供的内存空间。

如果手持设备实现包含的可供内核和用户空间使用的内存不超过 1 GB，则：

  • [7.6.1/H-9-1] 必须声明功能标志 android.hardware.ram.low。
  • [7.6.1/H-9-2] 必须有至少 1.1 GB 的非易失性存储空间可用于存储应用专属数据（该空间也称为“/data”分区）。

如果手持设备实现包含的可供内核和用户空间使用的内存超过 1 GB，则：

  • [7.6.1/H-10-1] 必须有至少 4 GB 的非易失性存储空间可用于存储应用专属数据（该空间也称为“/data”分区）。
  • 应声明功能标志 android.hardware.ram.normal。

如果手持设备实现包含的可供内核和用户空间使用的内存大于或等于 2 GB 且小于 4 GB，则：

  • [7.6.1/H-SR-1] 强烈建议仅支持 32 位用户空间（应用和系统代码）

如果手持设备实现包含的可供内核和用户空间使用的内存小于 2 GB，则：

  • [7.6.1/H-1-1] 必须仅支持 32 位 ABI。

手持设备实现：

  • [7.6.2/H-0-1] 必须提供不小于 1 GiB 的应用共享存储空间。
  • [7.7.1/H] 应包含支持外围设备模式的 USB 端口。

如果手持设备实现包含支持外围设备模式的 USB 端口，则：

  • [7.7.1/H-1-1] 必须实现 Android Open Accessory (AOA) API。

如果手持设备实现包含支持主机模式的 USB 端口，则：

手持设备实现：

  • [7.8.1/H-0-1] 必须包含麦克风。
  • [7.8.2/H-0-1] 必须具有音频输出机制，并声明 android.hardware.audio.output。

如果手持设备实现能够满足关于支持 VR 模式的所有性能要求且支持 VR 模式，则：

  • [7.9.1/H-1-1] 必须声明 android.hardware.vr.high_performance 功能标志。
  • [7.9.1/H-1-2] 必须包含用于实现 android.service.vr.VrListenerService（可以由 VR 应用通过 android.app.Activity#setVrModeEnabled 启用）的应用。

如果手持设备实现包含一个或多个支持主机模式和实现（USB 音频类）的 USB-C 端口，则除了要满足第 7.7.2 节中的要求外，还：

  • [7.8.2.2/H-1-1] 必须提供 HID 代码的以下软件映射：
功能 映射 上下文 行为
A HID 用法页：0x0C
HID 用法：0x0CD
内核键：KEY_PLAYPAUSE
Android 键：KEYCODE_MEDIA_PLAY_PAUSE		 媒体播放 输入：短按
输出：播放或暂停
输入：长按
输出：启动语音指令
如果设备锁定或其屏幕关闭，发送：android.speech.action.VOICE_SEARCH_HANDS_FREE，否则发送 android.speech.RecognizerIntent.ACTION_WEB_SEARCH
来电 输入：短按
输出：接听来电
输入：长按
输出：拒接来电
当前通话 输入：短按
输出：结束通话
输入：长按
输出：将麦克风静音或取消静音
B HID 用途页：0x0C
HID 用途：0x0E9
内核按键：KEY_VOLUMEUP
Android 按键：VOLUME_UP		 媒体播放、当前通话 输入：短按或长按
输出：调高系统或耳机的音量
C HID 用途页：0x0C
HID 用途：0x0EA
内核按键：KEY_VOLUMEDOWN
Android 按键：VOLUME_DOWN		 媒体播放、当前通话 输入：短按或长按
输出：调低系统或耳机的音量
D HID 用途页：0x0C
HID 用途：0x0CF
内核按键：KEY_VOICECOMMAND
Android 按键：KEYCODE_VOICE_ASSIST		 所有。可在任何情况下触发。 输入：短按或长按
输出：启动语音指令
  • [7.8.2.2/H-1-2] 必须在插头插入时触发 ACTION_HEADSET_PLUG，但只能在正确枚举 USB 音频接口和端点之后才能触发，以便识别已连接终端的类型。

在检测到 USB 音频终端类型 0x0302 时：

  • [7.8.2.2/H-2-1] 必须广播 intent ACTION_HEADSET_PLUG，并将“麦克风”extra 设置为 0。

在检测到 USB 音频终端类型 0x0402 时：

  • [7.8.2.2/H-3-1] 必须广播 intent ACTION_HEADSET_PLUG，并将“麦克风”extra 设置为 1。

在连接 USB 外围设备期间调用 API AudioManager.getDevices() 时：

  • [7.8.2.2/H-4-1] 如果 USB 音频终端类型字段为 0x0302，则必须列出设备类型 AudioDeviceInfo.TYPE_USB_HEADSET 和角色 isSink()。

  • [7.8.2.2/H-4-2] 如果 USB 音频终端类型字段为 0x0402，则必须列出设备类型 AudioDeviceInfo.TYPE_USB_HEADSET 和角色 isSink()。

  • [7.8.2.2/H-4-3] 如果 USB 音频终端类型字段为 0x0402，则必须列出设备类型 AudioDeviceInfo.TYPE_USB_HEADSET 和角色 isSource()。

  • [7.8.2.2/H-4-4] 如果 USB 音频终端类型字段为 0x603，则必须列出设备类型 AudioDeviceInfo.TYPE_USB_DEVICE 和角色 isSink()。

  • [7.8.2.2/H-4-5] 如果 USB 音频终端类型字段为 0x604，则必须列出设备类型 AudioDeviceInfo.TYPE_USB_DEVICE 和角色 isSource()。

  • [7.8.2.2/H-4-6] 如果 USB 音频终端类型字段为 0x400，则必须列出设备类型 AudioDeviceInfo.TYPE_USB_DEVICE 和角色 isSink()。

  • [7.8.2.2/H-4-7] 如果 USB 音频终端类型字段为 0x400，则必须列出设备类型 AudioDeviceInfo.TYPE_USB_DEVICE 和角色 isSource()。

  • [7.8.2.2/H-SR-1] 强烈建议在连接 USB-C 音频外围设备后的 1,000 毫秒内枚举 USB 描述符、识别终端类型并广播 intent ACTION_HEADSET_PLUG。

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

  • [5.6/H-1-1] 在以下数据路径上的 5 次测量中，平均连续往返延迟时间不得超过 300 毫秒，平均绝对偏差低于 30 毫秒：“扬声器到麦克风”、3.5 毫米环回适配器（如果支持）、USB 回环（如果支持）。

  • [5.6/H-1-2] 在扬声器到麦克风数据路径上的至少 5 次测量中，平均点按与发声间延迟时间不得超过 300 毫秒。

如果手持设备实现包含至少一个触感致动器，则：

线性共振致动器 (LRA) 是一种单质量弹簧系统，它有一个主共振频率，质量沿所需运动方向转移。

如果手持设备实现包含至少一个通用 7.10 线性共振致动器，则：

新要求开始

  • [7.10/H] 应将致动器放置在通常手持或触摸设备的位置附近。

新要求结束

  • [7.10/H] 应沿设备的自然纵向屏幕方向的 X 轴（左右）移动触感反馈致动器。

如果手持设备实现包含通用触感反馈致动器（即 X 轴线性共振致动器 [LRA]），则：

  • [7.10/H] 应将 X 轴 LRA 的共振频率设置为低于 200 Hz。

如果手持设备实现遵循触感常量映射，则：

2.2.2. 多媒体

手持设备实现必须支持以下音频编码和解码格式，并使其可供第三方应用使用：

  • [5.1/H-0-1] AMR-NB
  • [5.1/H-0-2] AMR-WB
  • [5.1/H-0-3] MPEG-4 AAC Profile (AAC LC)
  • [5.1/H-0-4] MPEG-4 HE AAC Profile (AAC+)
  • [5.1/H-0-5] AAC ELD（增强型低延迟 AAC）

手持设备实现必须支持以下视频编码格式，并使其可供第三方应用使用：

  • [5.2/H-0-1] H.264 AVC
  • [5.2/H-0-2] VP8

新要求开始

  • [5.2/H-0-3] AV1

新要求结束

手持设备实现必须支持以下视频解码格式，并使其可供第三方应用使用：

  • [5.3/H-0-1] H.264 AVC
  • [5.3/H-0-2] H.265 HEVC
  • [5.3/H-0-3] MPEG-4 SP
  • [5.3/H-0-4] VP8
  • [5.3/H-0-5] VP9

新要求开始

  • [5.3/H-0-6] AV1

新要求结束

2.2.3. 软件

手持设备实现：

  • [3.2.3.1/H-0-1] 必须包含用于处理 ACTION_GET_CONTENT、ACTION_OPEN_DOCUMENT、ACTION_OPEN_DOCUMENT_TREE 和 ACTION_CREATE_DOCUMENT intent（如 SDK 文档中所述）的应用，并提供一种方式，让用户能够使用 DocumentsProvider API 访问文档提供程序数据。
  • [3.2.3.1/H-0-2]* 对于此处列出的以下应用 intent 所定义的所有公共 intent 过滤器模式，必须用 intent 处理程序预加载一个或多个应用或服务组件。
  • [3.2.3.1/H-SR-1] 强烈建议预加载一个可以通过处理 ACTION_SENDTO、ACTION_SEND 或 ACTION_SEND_MULTIPLE intent 来发送电子邮件的电子邮件应用。
  • [3.4.1/H-0-1] 必须提供 android.webkit.Webview API 的完整实现。
  • [3.4.2/H-0-1] 必须包含独立的浏览器应用，以供用户进行一般的网页浏览。
  • [3.8.1/H-SR-1] 强烈建议实现一个支持在应用内固定快捷方式、widget 和 widgetFeatures 的默认启动器。
  • [3.8.1/H-SR-2] 强烈建议实现一个可让用户快速访问第三方应用通过 ShortcutManager API 提供的其他快捷方式的默认启动器。
  • [3.8.1/H-SR-3] 强烈建议包含一个会为应用图标显示标记的默认启动器应用。
  • [3.8.2/H-SR-1] 强烈建议支持第三方应用 widget。
  • [3.8.3/H-0-1] 必须允许第三方应用通过 Notification 和 NotificationManager API 类向用户发出关于重要事件的通知。
  • [3.8.3/H-0-2] 必须支持内容丰富的通知。
  • [3.8.3/H-0-3] 必须支持浮动通知。
  • [3.8.3/H-0-4] 必须包含通知栏，以便用户能够通过相应方式（例如 AOSP 中实现的操作按钮或控制台）直接控制通知（例如回复、暂停、关闭和屏蔽通知）。
  • [3.8.3/H-0-5] 必须在通知栏显示通过 RemoteInput.Builder setChoices() 提供的选项。
  • [3.8.3/H-SR-1] 强烈建议在无需用户额外互动的情况下在通知栏显示通过 RemoteInput.Builder setChoices() 提供的第一个选项。
  • [3.8.3/H-SR-2] 强烈建议在用户展开通知栏中的所有通知时在通知栏显示通过 RemoteInput.Builder setChoices() 提供的所有选项。
  • [3.8.3.1/H-SR-1] 强烈建议显示用于按照 Notification.Remoteinput.Builder.setChoices 显示的回复将 Notification.Action.Builder.setContextual 设置为 true 的操作。
  • [3.8.4/H-SR-1] 强烈建议在设备上实现一个辅助程序来处理辅助操作。

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

  • [3.8 .3.1/H-SR-2] 强烈建议提供一种可通过系统界面访问的方式（例如“输出切换器”），让用户能够在应用发布带有 MediaSession 令牌 的 MediaStyle 通知时，在相应的可用媒体路由（例如蓝牙设备和提供给 MediaRouter2Manager 的路由）之间切换。

新要求开始

如果设备实现包含“最近用过”功能导航键（第 7.2.3 节中对此进行了详细说明），并且要更改该界面，则：

  • [3.8.3/H-1-1] 必须实现屏幕固定行为，并向用户提供用于开启/关闭该功能的设置菜单。

新要求结束

如果手持设备实现支持辅助操作，则：

  • [3.8.4/H-SR-2] 强烈建议将长按 HOME 键用作启动辅助应用的指定互动方式（如第 7.2.3 节中所述）。必须启动用户选择的辅助应用（也就是实现 VoiceInteractionService 的应用）或负责处理 ACTION_ASSIST intent 的 activity。

如果手持设备实现支持 conversation notifications 并将它们归入一个单独的部分（既非提醒通知也非静默非对话通知），则：

  • [3.8.4/H-1-1]* 必须在非对话通知（正在运行的前台服务通知和 importance:high 通知除外）之前显示对话通知。

如果 Android 手持设备实现支持锁定屏幕，则：

  • [3.8.10/H-1-1] 必须显示包含媒体通知模板的锁定屏幕通知。

如果手持设备实现支持安全锁定屏幕，则：

  • [3.9/H-1-1] 必须实现 Android SDK 文档中定义的所有设备管理政策。

如果手持设备实现支持 ControlsProviderService API 和 Control API 并允许第三方应用发布设备控制器，则：

  • [3.8.16/H-1-1] 必须声明功能标志 android.software.controls 并将其设置为 true。
  • [3.8.16/H-1-2] 必须提供一种方式，让用户能够从第三方应用通过 ControlsProviderService API 和 Control API 注册的控件中添加、修改、选择和运行用户喜爱的设备控制器。
  • [3.8.16/H-1-3] 必须在默认启动器的三次互动期间让用户能够使用这种方式。

  • [3.8.16/H-1-4] 必须在这种方式中准确呈现每个通过 ControlsProviderService API 提供控件的第三方应用的名称和图标，以及 Control API 提供的任何指定字段。

  • [3.8.16/H-1-5] 必须提供一种用户功能，用于从第三方应用通过 ControlsProviderService 和 ControlControl.isAuthRequired API 注册的控件中选择停用应用指定的 auth-trivial 设备控件。

新要求开始

新要求结束

反过来，如果手持设备实现不实现此类控件，则：

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

  • [3.8.17/H-1-1] 必须提供向用户表明数据已复制到剪贴板的确认信息（例如，注明“已复制内容”的缩略图或提醒）。此外，请在此处添加指明剪贴板数据是否会在设备间同步的信息。

手持设备实现：

  • [3.10/H-0-1] 必须支持第三方无障碍服务。
  • [3.10/H-SR-1] 强烈建议在设备上预加载无障碍服务，并且这些服务的功能要与 TalkBack 开源项目中提供的开关控制和 TalkBack（适用于预安装的文字转语音引擎支持的语言）无障碍服务的功能相当或更胜一筹。
  • [3.11/H-0-1] 必须支持安装第三方 TTS 引擎。
  • [3.11/H-SR-1] 强烈建议包含支持设备上可用语言的 TTS 引擎。
  • [3.13/H-SR-1] 强烈建议包含快捷设置界面组件。

如果 Android 手持设备实现声明支持 FEATURE_BLUETOOTH 或 FEATURE_WIFI，则：

  • [3.16/H-1-1] 必须支持配套设备配对功能。

如果导航功能是作为基于手势的屏幕上操作提供的，则：

  • [7.2.3/H]“主屏幕”功能的手势识别区域从屏幕底部开始的高度不得高于 32 dp。

如果手持设备实现将导航功能作为从屏幕左右边缘任何位置执行的手势来提供，则：

  • [7.2.3/H-0-1] 导航功能的手势区域每一侧的宽度必须小于 40 dp。手势区域宽度应默认为 24 dp。

如果手持设备实现支持安全锁定屏幕，且可供内核和用户空间使用的内存大于或等于 2 GB，则：

  • [3.9/H-1-2] 必须通过 android.software.managed_users 功能标志声明支持受管理资料。

如果 Android 手持设备实现通过 android.hardware.camera.any 声明支持摄像头，则：

如果设备实现的“设置”应用通过 activity 嵌入实现分屏功能，则：

新要求开始

如果设备实现允许用户拨打任何类型的电话，则：

新要求结束

2.2.4. 性能与功耗

  • [8.1/H-0-1] 一致的帧延迟。帧延迟或帧渲染延迟不一致的发生频率不得超过每秒 5 帧，并且应低于每秒 1 帧。
  • [8.1/H-0-2] 界面延迟。设备实现必须确保实现低延迟用户体验，具体方式是确保滚动完包含 10K 个列表条目的列表（具体定义详见 Android 兼容性测试套件 [CTS]）所用的时间不超过 36 秒。
  • [8.1/H-0-3] 任务切换。 在启动了多个应用的情况下，如果重新启动已启动且已在运行的应用，所用时间不得超过 1 秒。

手持设备实现：

  • [8.2/H-0-1] 必须确保顺序写入性能至少为 5 MB/s。
  • [8.2/H-0-2] 必须确保随机写入性能至少为 0.5 MB/s。
  • [8.2/H-0-3] 必须确保顺序读取性能至少为 15 MB/s。
  • [8.2/H-0-4] 必须确保随机读取性能至少为 3.5 MB/s。

如果手持设备实现中的某些功能可改进 AOSP 中的设备电源管理或可扩展 AOSP 中的功能，则：

  • [8.3/H-1-1] 必须提供一种方式，让用户能够启用和停用省电模式。
  • [8.3/H-1-2] 必须提供一种方式，让用户能够查看免于进入应用待机模式和低电耗模式的所有应用。

手持设备实现：

  • [8.4/H-0-1] 必须提供一个关于各组件功耗的配置文件，其中要定义每种硬件组件的电耗值以及组件在一段时间内大概消耗的电量（如 Android 开源项目网站上所述）。
  • [8.4/H-0-2] 必须以毫安小时 (mAh) 为单位报告所有功耗值。
  • [8.4/H-0-3] 必须按每个进程的 UID 报告 CPU 功耗。Android 开源项目通过 uid_cputime 内核模块实现来满足此要求。
  • [8.4/H-0-4] 必须能让应用开发者通过 adb shell dumpsys batterystats shell 命令查看此功耗。
  • [8.4/H] 如果无法将硬件组件的功耗归于某个应用，应将其归于硬件组件本身。

如果手持设备实现包含屏幕或视频输出机制，则：

手持设备实现：

  • [8.5/H-0-1] 必须在“设置”菜单中提供一种方式，让用户能够查看含有处于活动状态的前台服务或用户发起作业的所有应用，包括其中每项服务自启动以来的时长（如 SDK 文档中所述）。并且能够停止在运行前台服务或用户发起作业的应用。能够停止在运行前台服务的应用，并显示含有处于活动状态的前台服务的所有应用，以及其中每项服务自启动以来的时长（如 SDK 文档中所述）。
    • 如 SDK 文档中所述，某些应用可免于在此类用户功能中停止或列出。

新要求开始

  • [8.5/H-0-2] 必须提供一种方式，让用户能够停止在运行前台服务或用户发起作业的应用。

新要求结束

2.2.5. 安全模型

手持设备实现：

  • [9/H-0-1] 必须声明 android.hardware.security.model.compatible 功能。
  • [9.1/H-0-1] 必须允许第三方应用通过 android.permission.PACKAGE_USAGE_STATS 权限访问使用情况统计信息，并能够响应 android.settings.ACTION_USAGE_ACCESS_SETTINGS intent 提供一种可供用户使用的机制，让用户能够为此类应用授予或撤消该访问权限。

新要求开始

如果设备实现声明支持 android.hardware.telephony，则：

  • [9.5/H-1-1] 不得将 UserManager.isHeadlessSystemUserMode 设置为 true。

新要求结束

手持设备实现：

  • [9.11/H-0-2] 必须通过隔离的执行环境备份密钥存储区实现。
  • [9.11/H-0-3] 必须具有 RSA、AES、ECDSA 和 HMAC 加密算法以及 MD5、SHA1 和 SHA-2 系列哈希函数的实现，以便在与内核上及更上面运行的代码安全隔离的区域中正确支持 Android Keystore 系统支持的算法。安全隔离必须能够阻止内核或用户空间代码可能会借以获取隔离环境内部状态的所有潜在机制，包括 DMA。上游 Android 开源项目 (AOSP) 通过使用 Trusty 实现来满足此要求，但也可以使用其他基于 ARM TrustZone 的解决方案，或使用经过第三方审核的基于 Hypervisor 的适当隔离方法的安全实现。
  • [9.11/H-0-4] 必须在隔离的执行环境中执行锁定屏幕身份验证，并且只有在成功通过验证后，才允许使用与身份验证绑定的密钥。锁定屏幕凭据的存储方式必须只允许隔离的执行环境执行锁屏身份验证。上游 Android 开源项目提供了可用于满足此要求的 Gatekeeper 硬件抽象层 (HAL) 和 Trusty。
  • [9.11/H-0-5] 如果认证签名密钥有安全硬件保护，并且签名是在安全硬件中进行，必须支持密钥认证。认证签名密钥必须在足够多的设备之间共享，以防止此类密钥被用作设备标识符。如需满足此要求，可以采用的一种方法是共享相同的认证密钥，除非生成了至少 10 万个单元的给定 SKU。如果生成了超过 10 万个单元的 SKU，可以针对每 10 万个单元使用一个不同的密钥。

请注意，如果设备实现已搭载较低 Android 版本，则此类设备无需满足具有由隔离的执行环境支持的密钥库并支持密钥认证这一要求，除非它声明了 android.hardware.fingerprint 功能（该功能需要受隔离的执行环境支持的密钥库）。

如果手持设备实现支持安全锁定屏幕，则：

  • [9.11/H-1-1] 必须允许用户选择最短的休眠超时，即从解锁状态到锁定状态的过渡时间不得超过 15 秒。
  • [9.11/H-1-2] 必须提供一种方式，让用户能够隐藏通知并停用所有身份验证方法（9.11.1 安全锁定屏幕中所述的主要身份验证方法除外）。AOSP 满足锁定模式的要求。

新要求开始

如果设备实现包含安全锁定屏幕，并且包含一个或多个实现 TrustAgentService 系统 API 的可信代理，则：

  • [9.11.1/H-1-1] 必须至少每隔 72 小时要求用户通过建议的主要身份验证方法之一（例如 PIN 码、图案、密码）验证身份。

新要求结束

如果手持设备实现包含多位用户，并且未声明 android.hardware.telephony 功能标志，则：

  • [9.5/H-2-1] 必须支持受限资料，此类资料可让设备所有者管理设备上的其他用户以及他们可以使用的功能。借助受限资料，设备所有者可以快速设置供其他用户使用的单独环境，同时还能在可于这些环境中运行的应用内管理更精细的限制。

如果手持设备实现包含多位用户，并声明 android.hardware.telephony 功能标志，则：

  • [9.5/H-3-1] 不得支持受限资料，但必须与用于允许/禁止其他用户访问语音通话和短信的控件的 AOSP 实现保持一致。

新要求开始

如果手持设备实现将 UserManager.isHeadlessSystemUserMode 设置为 true，则：

  • [9.5/H-4-1] 不得支持 eUICC，也不得支持具有通话功能的 eSIM 卡。
  • [9.5/H-4-2] 不得声明支持 android.hardware.telephony。

新要求结束

Android 通过系统 API VoiceInteractionService 支持一种始终开启的安全启动指令检测机制，而无需指示麦克风使用权限和始终开启的查询检测功能，无需指示麦克风或摄像头使用权限。

如果手持设备实现支持系统 API HotwordDetectionService 或其他启动指令检测机制，而无需指示麦克风使用权限指示，则：

  • [9.8/H-1-1] 必须确保启动指令检测服务只能向系统、ContentCaptureService或 SpeechRecognizer#createOnDeviceSpeechRecognizer() 创建的设备端语音识别服务传输数据。
  • [9.8/H-1-2] 必须确保启动指令检测服务只能通过 HotwordDetectionServiceAPI 将麦克风音频数据或其衍生数据传输到系统服务器，或通过 ContentCaptureManager API 将此类数据传输到 ContentCaptureService。
  • [9.8/H-1-3] 对于单个硬件触发的启动指令检测服务请求，不得提供超过 30 秒的麦克风音频。
  • [9.8/H-1-4] 对于单个启动指令检测服务请求，不得提供超过 8 秒的缓冲麦克风音频。
  • [9.8/H-1-5] 不得向语音互动服务或类似实体提供超过 30 秒的缓冲麦克风音频。
  • [9.8/H-1-6] 对于每项成功的启动指令结果，不得从启动指令检测服务传输超过 100 个字节的数据，但通过 HotwordAudioStream 传递的音频数据除外。
  • [9.8/H-1-7] 对于每项未通过的启动指令结果，不得从启动指令检测服务传输超过 5 位的数据。
  • [9.8/H-1-8] 只能在系统服务器发出启动指令验证请求时，从启动指令检测服务传输数据。
  • [9.8/H-1-9] 不得借助用户可安装的应用提供启动指令检测服务。
  • [9.8/H-1-10] 不得在界面中呈现有关启动指令检测服务使用麦克风的定量数据。
  • [9.8/H-1-11] 必须记录启动指令检测服务在每次传输中包含的字节数，以确保安全研究人员能够进行检查。
  • [9.8/H-1-12] 必须支持一种调试模式，该模式会记录启动指令检测服务每次传输的原始内容，以确保安全研究人员能够进行检查。
  • [9.8/H-1-14] 当成功的启动指令结果传输到语音互动服务或类似实体之后，必须按照第 9.8.2 节中所述显示麦克风指示标志。

新要求开始

  • [9.8/H-1-15] 必须确保在成功启动指令结果中提供的音频串流从启动指令检测服务单向传输到语音交互服务。

新要求结束

  • [9.8/H-SR-1] 强烈建议在将应用设为启动指令检测服务提供程序之前，先通知用户。
  • [9.8/H-SR-2] 强烈建议禁止从启动指令检测服务传输非结构化数据。
  • [9.8/H-SR-3] 强烈建议至少每小时或每 30 个硬件触发事件（以较早者为准）重启托管启动指令检测服务的进程。

如果设备实现包含使用系统 API HotwordDetectionService 或类似启动指令检测机制的应用，而无需指示麦克风的使用，则该应用：

  • [9.8/H-2-1] 对于支持的每个启动指令短语，必须向用户提供明确通知。
  • [9.8/H-2-2] 不得通过启动指令检测服务保留原始音频数据或其衍生数据。
  • [9.8/H-2-3] 不得从启动指令检测服务传输音频数据、可用于（全部或部分）重构音频的数据或与启动指令本身无关的音频内容，但传输至 ContentCaptureService 或设备端语音识别服务的情况除外。

新要求开始

如果手持设备实现支持系统 API VisualQueryDetectionService 或其他查询检测机制，而无需指示麦克风和/或摄像头使用权限，则：

  • [9.8/H-3-1] 必须确保查询检测服务只能将数据传输到系统、ContentCaptureService 或设备端语音识别服务（由 SpeechRecognizer#createOnDeviceSpeechRecognizer() 创建）。
  • [9.8/H-3-2] 不得允许将任何音频或视频信息传输到 VisualQueryDetectionService 之外（传输到 ContentCaptureService 或设备端语音识别服务的情况除外）。
  • [9.8/H-3-3] 当设备检测到用户有意与数字助理应用互动时（例如通过摄像头检测用户活跃状态），必须在系统界面中显示用户通知。
  • [9.8/H-3-4] 在检测到用户查询后，必须立即显示麦克风指示标志，并在界面中显示检测到的用户查询。
  • [9.8/H-3-5] 不得允许用户可安装的应用提供可视化查询检测服务。

新要求结束

如果手持设备实现声明 android.hardware.microphone，则：

  • [9.8.2/H-4-1] 在应用从麦克风访问音频数据时，必须显示麦克风指示标志，但如果仅 HotwordDetectionService、SOURCE_HOTWORD、ContentCaptureService 或拥有第 9.1 节中使用 CDD 标识符 [C-4-X] 所列的角色的应用访问麦克风，则无需显示麦克风指示标志。
  • [9.8.2/H-4-2] 必须根据 PermissionManager.getIndicatorAppOpUsageData() 返回的内容显示使用麦克风的“最近用过”和“使用中”应用列表，以及与此类应用相关联的所有归因信息。

如果手持设备实现声明 android.hardware.camera.any，则：

  • [9.8.2/H-5-1] 在应用从摄像头访问实时数据时，必须显示摄像头指示标志，但如果仅拥有第 9.1 节中使用 CDD 标识符 [C-4-X] 所列角色的应用访问摄像头，则无需显示摄像头指示标志。
  • [9.8.2/H-5-2] 必须根据 PermissionManager.getIndicatorAppOpUsageData() 返回的内容显示使用摄像头的“最近用过”和“使用中”应用，以及与此类应用相关联的所有归因信息。

2.2.6. 开发者工具和选项兼容性

手持设备实现（* 不适用于平板电脑）：

  • [6.1/H-0-1]* 必须支持 shell 命令 cmd testharness。

手持设备实现（* 不适用于平板电脑）：

  • Perfetto
    • [6.1/H-0-2]* 必须向 shell 用户公开 /system/bin/perfetto 二进制文件，且 cmdline 符合 perfetto 文档要求。
    • [6.1/H-0-3]* perfetto 二进制文件必须接受符合 perfetto 文档中定义的架构的 protobuf 配置作为输入。
    • [6.1/H-0-4]* perfetto 二进制文件必须写入符合 perfetto 文档中定义的架构的 protobuf 轨迹作为输出。
    • [6.1/H-0-5]* 必须通过 perfetto 二进制文件至少提供 perfetto 文档中所述的数据源。
    • [6.1/H-0-6]* 必须默认启用 perfetto 跟踪守护程序（系统属性 persist.traced.enable）。

2.2.7. 手持设备媒体性能等级

有关媒体性能等级的定义，请参阅第 7.11 节。

2.2.7.1. 媒体

如果手持设备实现针对 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 返回 android.os.Build.VERSION_CODES.T，则：

新要求开始

如果手持设备实现针对 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 返回 android.os.Build.VERSION_CODES.U，则：

  • [5.1/H-1-1] 必须通过 CodecCapabilities.getMaxSupportedInstances() 和 VideoCapabilities.getSupportedPerformancePoints() 方法通告可以采用任何编解码器组合形式并行运行的硬件视频解码器会话的数量上限。
  • [5.1/H-1-2] 必须支持 6 个 8 位 (SDR) 硬件视频解码器会话实例（AVC、HEVC、VP9、AV1 或更高版本）采用任何编解码器组合形式并行运行，其中 3 个会话采用 1080p@30fps 分辨率，3 个会话采用 4K@30fps 分辨率，AV1 除外。AV1 编解码器仅需要支持 1080p 分辨率，但仍需要支持 6 个分辨率为 1080p30fps 的实例。
  • [5.1/H-1-3] 必须通过 CodecCapabilities.getMaxSupportedInstances() 和 VideoCapabilities.getSupportedPerformancePoints() 方法通告可以采用任何编解码器组合形式并行运行的硬件视频编码器会话的数量上限。
  • [5.1/H-1-4] 必须支持 6 个 8 位 (SDR) 硬件视频编码器会话实例（AVC、HEVC、VP9、AV1 或更高版本）采用任何编解码器组合形式并行运行，其中 4 个会话采用 1080p@30fps 分辨率，2 个会话采用 4K@30fps 分辨率，AV1 除外。AV1 编解码器仅需要支持 1080p 分辨率，但仍需要支持 6 个分辨率为 1080p30fps 的实例。
  • [5.1/H-1-5] 必须通过 CodecCapabilities.getMaxSupportedInstances() 和 VideoCapabilities.getSupportedPerformancePoints() 方法通告可以采用任何编解码器组合形式并行运行的硬件视频编码器和解码器会话的数量上限。
  • [5.1/H-1-6] 必须支持 6 个 8 位 (SDR) 硬件视频解码器和硬件视频编码器会话实例（AVC、HEVC、VP9、AV1 或更高版本）采用任何编解码器组合形式并行运行，其中 3 个会话采用 4K@30fps 分辨率（AV1 除外），最多有 2 个是编码器会话，3 个会话采用 1080p 分辨率。AV1 编解码器仅需要支持 1080p 分辨率，但仍需要支持 6 个分辨率为 1080p30fps 的实例。
  • [5.1/H-1-19] 必须支持 3 个 10 位 (HDR) 硬件视频解码器和硬件视频编码器会话实例（AVC、HEVC、VP9、AV1 或更高版本）采用任何编解码器组合形式并行运行，并且均采用 4K@30fps 分辨率（AV1 除外），其中最多有 1 个编码器会话，该会话可通过 GL Surface 以 RGBA_1010102 输入格式进行配置。如果从 GL Surface 进行编码，则无需由编码器生成 HDR 元数据。AV1 编解码器会话仅需要支持 1080p 分辨率，即使要求支持 4K 也是如此。
  • [5.1/H-1-7] 当所有硬件视频编码器处于负载状态时，对于分辨率不超过 1080p 的视频编码会话，编解码器初始化延迟时间不得超过 40 毫秒。此处的负载定义为使用硬件视频编解码器和 1080p 音频和视频录制初始化的并行 1080p 至 720p 纯视频转码会话。 对于杜比视界编解码器，编解码器初始化延迟时间不得超过 50 毫秒。
  • [5.1/H-1-8] 当所有音频编码器处于负载状态时，对于比特率不超过 128 kbps 的音频编码会话，编解码器初始化延迟时间不得超过 30 毫秒。此处的负载定义为使用硬件视频编解码器和 1080p 音频和视频录制初始化的并行 1080p 至 720p 纯视频转码会话。
  • [5.1/H-1-9] 必须支持 2 个安全硬件视频解码器会话实例（AVC、HEVC、VP9、AV1 或更高版本）采用任何编解码器组合形式并行运行，并且 8 位 (SDR) 内容和 10 位 HDR 内容均采用 4k@30fps 分辨率（AV1 除外）。AV1 编解码器会话仅需要支持 1080p 分辨率，即使要求支持 4K 也是如此。
  • [5.1/H-1-10] 必须支持 3 个非安全硬件视频解码器会话实例与 1 个安全硬件视频解码器会话实例（共 4 个实例，AVC、HEVC、VP9、AV1 或更高版本）采用任何编解码器组合形式并行运行，其中 3 个会话采用 4K@30fps 分辨率（AV1 除外）（包括 1 个安全解码器会话），1 个非安全会话采用 1080p@30fps 分辨率（其中最多有 2 个会话可以采用 10 位 HDR）。AV1 编解码器会话仅需要支持 1080p 分辨率，即使要求支持 4K 也是如此。
  • [5.1/H-1-11] 设备上的每种硬件 AVC、HEVC、VP9 或 AV1 解码器都必须支持一种安全解码器。
  • [5.1/H-1-12] 当所有硬件视频解码器处于负载状态时，对于分辨率不超过 1080p 的视频解码会话，编解码器初始化延迟时间不得超过 40 毫秒。此处的负载定义为使用硬件视频编解码器和 1080p 音频和视频播放初始化的并行 1080p 至 720p 纯视频转码会话。对于杜比视界编解码器，编解码器初始化延迟时间不得超过 50 毫秒。
  • [5.1/H-1-13] 当所有音频解码器处于负载状态时，对于比特率不超过 128 kbps 的音频解码会话，编解码器初始化延迟时间不得超过 30 毫秒。此处的负载定义为使用硬件视频编解码器和 1080p 音频和视频播放初始化的并行 1080p 至 720p 纯视频转码会话。
  • [5.1/H-1-14] 必须支持 AV1 硬件解码器 Main 10，Level 4.1 和胶片颗粒。
  • [5.1/H-1-15] 必须至少有 1 种支持 4K60 的硬件视频解码器。
  • [5.1/H-1-16] 必须至少有 1 种支持 4K60 的硬件视频编码器。
  • [5.3/H-1-1] 当处于负载状态时，对于 4K@60fps 视频会话，在 10 秒内不得丢弃超过 1 帧（即丢帧率小于 0.167%）。
  • [5.3/H-1-2] 当处于 4K 会话负载状态时，在 60fps 视频会话中更改视频分辨率期间，在 10 秒内不得丢弃超过 1 帧。
  • [5.6/H-1-1] 使用 CTS 验证程序点按与发声间测试时，点按与发声间延迟时间不得超过 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.6/H-1-9] 必须支持至少 12 个声道混音。这意味着能够打开具有 7.1.4 声道掩码的 AudioTrack，并且能够正确地将所有声道空间化或缩混到立体声。
  • [5.6/H-SR] 强烈建议支持 24 个声道混音，并且至少支持 9.1.6 和 22.2 声道掩码。
  • [5.7/H-1-2] 必须支持具有以下内容解密功能的 MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL。
采样规模下限 4 MiB
下采样数量下限 - H264 或 HEVC 32
下采样数量下限 - VP9 9
下采样数量下限 - AV1 288
下采样缓冲区空间下限 1 MiB
通用加密缓冲区空间下限 500 KiB
并发会话数量下限 30
每次会话的密钥数量下限 20
密钥总数下限（所有会话） 80
DRM 密钥总数下限（所有会话） 6
信息大小 16 KiB
每秒解密帧数 60 fps
  • [5.1/H-1-17] 必须至少有 1 个支持 AVIF 基准配置文件的硬件图像解码器。
  • [5.1/H-1-18] 必须支持 AV1 编码器，该编码器能够以 30fps 和 1Mbps 的速率进行编码（分辨率高达 480p）。
  • [5.12/H-1-1] 必须[5.12/H-SR] 强烈建议设备上存在的所有硬件 AV1 和 HEVC 编码器都支持 Feature_HdrEditing 功能。
  • [5.12/H-1-2] 设备上存在的所有硬件 AV1 和 HEVC 编码器都必须支持 RGBA_1010102 颜色格式。
  • [5.12/H-1-3] 必须通告支持 EXT_YUV_target 扩展，才能在 8 位和 10 位的 YUV 纹理中采样。
  • [7.1.4/H-1-1] 数据处理单元 (DPU) 硬件混合渲染器 (HWC) 中必须至少有 6 个硬件叠加层，其中至少 2 个应能显示 10 位视频内容。

如果手持设备实现针对 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 返回 android.os.Build.VERSION_CODES.U，并且支持硬件 AVC 或 HEVC 编码器，则：

新要求结束

2.2.7.2. 摄像头

如果手持设备实现针对 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 返回 android.os.Build.VERSION_CODES.T，则：

新要求开始

如果手持设备实现针对 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 返回 android.os.Build.VERSION_CODES.U，则：

  • [7.5/H-1-1] 必须具有一个主后置摄像头，该摄像头的分辨率至少为 1200 万像素，支持以 4k@30fps 拍摄视频。主后置摄像头是具有最低摄像头 ID 的后置摄像头。
  • [7.5/H-1-2] 必须具有一个主前置摄像头，该摄像头的分辨率至少为 600 万像素，支持以 1080p@30fps 拍摄视频。主前置摄像头是具有最低摄像头 ID 的前置摄像头。
  • [7.5/H-1-3] 必须支持将 android.info.supportedHardwareLevel 属性设为 FULL 或更优值（对于后置主摄像头）和 LIMITED 或更优值（对于前置主摄像头）。
  • [7.5/H-1-4] 必须支持为这两种主摄像头提供 CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME。
  • [7.5/H-1-5] 根据 CTS 摄像头性能测试在 ITS 照明条件 (3000K) 下对这两种主摄像头的测量，对于 1080p 分辨率，摄像头 2 的 JPEG 拍摄延迟时间必须小于 1000 900毫秒。
  • [7.5/H-1-6] 根据 CTS 摄像头性能测试在 ITS 照明条件 (3000K) 下对这两种主摄像头的测量，摄像头 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] 如有多个后置 RGB 摄像头，后置主摄像头必须支持 LOGICAL_MULTI_CAMERA 功能。
  • [7.5/H-1-14] 主前置摄像头和主后置摄像头都必须支持 STREAM_USE_CASE 功能。
  • [7.5/H-1-15] 必须通过主摄像头的 CameraX 和 Camera2 扩展来支持焦外成像和夜间模式扩展。
  • [7.5/H-1-16] 必须支持主摄像头的 DYNAMIC_RANGE_TEN_BIT 功能。
  • [7.5/H-1-17] 必须支持主摄像头的 CONTROL_SCENE_MODE_FACE_PRIORITY 和人脸检测（STATISTICS_FACE_DETECT_MODE_SIMPLE 或 STATISTICS_FACE_DETECT_MODE_FULL）。

新要求结束

2.2.7.3. 硬件

如果手持设备实现针对 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 返回 android.os.Build.VERSION_CODES.T，则：

新要求开始

如果手持设备实现针对 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 返回 android.os.Build.VERSION_CODES.U，则：

  • [7.1.1.1/H-2-1] 屏幕分辨率必须至少为 1080p。
  • [7.1.1.3/H-2-1] 屏幕密度必须至少为 400 dpi。
  • [7.1.1.3/H-3-1] 必须具有平均至少支持 1,000 尼特的 HDR 显示屏。
  • [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，则：

新要求开始

如果手持设备实现针对 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 返回 android.os.Build.VERSION_CODES.U，则：

  • [8.2/H-1-1] 必须确保顺序写入性能至少为 150 MB/s。
  • [8.2/H-1-2] 必须确保随机写入性能至少为 10 MB/s。
  • [8.2/H-1-3] 必须确保顺序读取性能至少为 250 MB/s。
  • [8.2/H-1-4] 必须确保随机读取性能至少为 100 MB/s。
  • [8.2/H-1-5] 必须确保具有 2 倍读取和 1 倍写入性能的并行顺序读写性能至少为 50 MB/s。

新要求结束

2.3. TV 设备相关要求

Android TV 设备指的是一种 Android 设备实现，适合用户坐在约 10 英尺远的距离处观看电视节目的娱乐界面（“提供大屏幕娱乐体验的界面”或“距离 10 英尺观看的界面”），可供用户观看数字媒体、影片、电视直播，玩游戏和/或使用应用。

满足以下所有条件的 Android 设备实现可归类为 TV 设备：

  • 提供了可远程控制屏幕（可能距用户 10 英尺远）上呈现的界面的机制。
  • 具有对角线长度超过 24 英寸的嵌入式屏幕，或包含视频输出端口，例如用于连接屏幕的 VGA、HDMI、DisplayPort 或无线端口。

本节其余部分中的附加要求针对的是 Android TV 设备实现。

2.3.1. 硬件

TV 设备实现：

  • [7.2.2/T-0-1] 必须支持方向键。
  • [7.2.3/T-0-1] 必须提供“主屏幕”和“返回”功能。
  • [7.2.3/T-0-2] 必须将“返回”功能 (KEYCODE_BACK) 的常规按下事件和长按事件都发送到前台应用。
  • [7.2.6.1/T-0-1] 必须支持游戏控制器，并声明 android.hardware.gamepad 功能标志。
  • [7.2.7/T] 应提供可让用户使用非触摸导航和核心导航键输入功能的遥控器。

如果 TV 设备实现包含 3 轴陀螺仪，则：

  • [7.3.4/T-1-1] 必须能够以至少 100 Hz 的频率报告事件。
  • [7.3.4/T-1-2] 必须能够测量高达 1,000 度/秒的方向变化。

TV 设备实现：

  • [7.4.3/T-0-1] 必须支持蓝牙和蓝牙 LE。
  • [7.6.1/T-0-1] 必须有至少 4 GB 的非易失性存储空间可用于存储应用专属数据（该空间也称为“/data”分区）。

如果 TV 设备实现包含支持主机模式的 USB 端口，则：

  • [7.5.3/T-1-1] 必须支持通过此 USB 端口连接但无需保持连接的外接摄像头。

如果 TV 设备实现是 32 位：

  • [7.6.1/T-1-1] 如果使用了以下任何密度，可供内核和用户空间使用的内存必须至少为 896 MB：

    • 400dpi 或更高（小屏幕/普通屏幕）
    • xhdpi 或更高（大屏幕）
    • tvdpi 或更高（超大屏幕）

如果 TV 设备实现是 64 位：

  • [7.6.1/T-2-1] 如果使用了以下任何密度，可供内核和用户空间使用的内存必须至少为 1,280 MB：

    • 400dpi 或更高（小屏幕/普通屏幕）
    • xhdpi 或更高（大屏幕）
    • tvdpi 或更高（超大屏幕）

请注意，上文提到的“可供内核和用户空间使用的内存”是指除了已专门用于硬件组件（例如设备实现上的无线装置、视频组件，以及其他不受内核控制的组件）的所有内存之外，另行提供的内存空间。

TV 设备实现：

  • [7.8.1/T] 应包含麦克风。
  • [7.8.2/T-0-1] 必须具有音频输出机制，并声明 android.hardware.audio.output。

2.3.2. 多媒体

TV 设备实现必须支持以下音频编码和解码格式，并使其可供第三方应用使用：

  • [5.1/T-0-1] MPEG-4 AAC Profile (AAC LC)
  • [5.1/T-0-2] MPEG-4 HE AAC Profile (AAC+)
  • [5.1/T-0-3] AAC ELD（增强型低延迟 AAC）

TV 设备实现必须支持以下视频编码格式，并使其可供第三方应用使用：

  • [5.2/T-0-1] H.264
  • [5.2/T-0-2] VP8

新要求开始

  • [5.2/T-0-3] AV1

新要求结束

TV 设备实现：

  • [5.2.2/T-SR-1] 强烈建议支持以 30 帧/秒的帧速率对分辨率为 720p 和 1080p 的视频进行 H.264 编码。

TV 设备实现必须支持以下视频解码格式，并使其可供第三方应用使用：

新要求开始

新要求结束

TV 设备实现必须支持以标准的视频帧速率进行 MPEG-2 解码（第 5.3.1 节中对此进行了详细说明），且视频的分辨率不得高于：

  • [5.3.1/T-1-1] 高清 1080p，29.97 帧/秒，Main Profile High Level。
  • [5.3.1/T-1-2] 高清 1080i，59.94 帧/秒，Main Profile High Level。它们必须对隔行扫描的 MPEG-2 视频进行去除隔行扫描处理，并使其可供第三方应用使用。

TV 设备实现必须支持以标准的视频帧速率进行 H.264 解码（第 5.3.4 节中对此进行了详细说明），视频的分辨率不得高于：

  • [5.3.4/T-1-1] 高清 1080p，60 帧/秒，Baseline Profile
  • [5.3.4/T-1-2] 高清 1080p，60 帧/秒，Main Profile
  • [5.3.4/T-1-3] 高清 1080p，60 帧/秒，High Profile Level 4.2

配备 H.265 硬件解码器的 TV 设备实现必须支持以标准的视频帧速率进行 H.265 解码（第 5.3.5 节中对此进行了详细说明），视频的分辨率不得高于：

  • [5.3.5/T-1-1] 高清 1080p，60 帧/秒，Main Profile Level 4.1

如果配备 H.265 硬件解码器的 TV 设备实现支持 H.265 解码和超高清解码配置文件，则：

  • [5.3.5/T-2-1] 必须以 60 帧/秒的帧速率支持超高清解码配置文件和 Main10 Level 5 Main Tier 配置文件

TV 设备实现必须支持以标准的视频帧速率进行 VP8 解码（第 5.3.6 节中对此进行了详细说明），视频的分辨率不得高于：

  • [5.3.6/T-1-1] 高清 1080p，60 帧/秒解码配置文件

配备 VP9 硬件解码器的 TV 设备实现必须支持以标准的视频帧速率进行 VP9 解码（第 5.3.7 节中对此进行了详细说明），视频的分辨率不得高于：

  • [5.3.7/T-1-1] 高清 1080p，60 帧/秒，profile 0（8 位色深）

如果配备 VP9 硬件解码器的 TV 设备实现支持 VP9 解码和超高清解码配置文件，则：

  • [5.3.7/T-2-1] 必须以每秒 60 帧的速率支持超高清解码配置文件和 profile 0（8 位色深）。
  • [5.3.7/T-SR1] 强烈建议以每秒 60 帧的速率支持超高清解码配置文件和 profile 2（10 位色深）。

TV 设备实现：

  • [5.5/T-0-1] 必须支持在支持的输出装置上进行系统主音量和数字音频输出音量衰减，使用压缩音频透传输出装置时（在这种情况下，设备上不会进行任何音频解码）除外。

如果 TV 设备实现没有内置屏幕但支持通过 HDMI 连接的外接屏幕，则：

  • [5.8/T-0-1] 必须将 HDMI 输出模式设置为所选像素格式的最高分辨率，该格式适用于外部显示屏的 50 Hz 或 60 Hz 刷新率，具体取决于设备出售地的视频刷新率。 必须将 HDMI 输出模式设置为选择 50 Hz 或 60 Hz 刷新率可支持的最高分辨率。
  • [5.8/T-SR-1] 强烈建议提供用户可配置的 HDMI 刷新率选择器。
  • [5.8] 应将 HDMI 输出模式刷新率设置为 50 Hz 或 60 Hz，具体取决于出售设备的地区的视频刷新率。

如果 TV 设备实现没有内置屏幕但支持通过 HDMI 连接的外接屏幕，则：

  • [5.8/T-1-1] 必须支持 HDCP 2.2。

如果 TV 设备实现不支持超高清解码但支持通过 HDMI 连接的外接屏幕，则：

  • [5.8/T-2-1] 必须支持 HDCP 1.4。

2.3.3. 软件

TV 设备实现：

  • [3/T-0-1] 必须声明 android.software.leanback 和 android.hardware.type.television 功能。
  • [3.2.3.1/T-0-1] 对于此处列出的以下应用 intent 所定义的所有公共 intent 过滤器模式，必须用 intent 处理程序预加载一个或多个应用或服务组件。
  • [3.4.1/T-0-1] 必须提供 android.webkit.Webview API 的完整实现。

如果 Android TV 设备实现支持锁定屏幕，则：

  • [3.8.10/T-1-1] 必须显示包含媒体通知模板的锁定屏幕通知。

TV 设备实现：

  • [3.8.14/T-SR-1] 强烈建议支持画中画 (PIP) 多窗口模式。
  • [3.10/T-0-1] 必须支持第三方无障碍服务。
  • [3.10/T-SR-1] 强烈建议在设备上预加载无障碍服务，并且这些服务的功能要与 TalkBack 开源项目中提供的开关控制和 TalkBack（适用于预安装的文字转语音引擎支持的语言）无障碍服务的功能相当或更胜一筹。

如果 TV 设备实现报告 android.hardware.audio.output 功能，则：

  • [3.11/T-SR-1] 强烈建议包含支持设备上可用语言的 TTS 引擎。
  • [3.11/T-1-1] 必须支持安装第三方 TTS 引擎。

TV 设备实现：

  • [3.12/T-0-1] 必须支持 TV 输入框架。

2.3.4. 性能与功耗

  • [8.1/T-0-1] 一致的帧延迟。帧延迟或帧渲染延迟不一致的发生频率不得超过每秒 5 帧，并且应低于每秒 1 帧。
  • [8.2/T-0-1] 必须确保顺序写入性能至少为 5 MB/s。
  • [8.2/T-0-2] 必须确保随机写入性能至少为 0.5 MB/s。
  • [8.2/T-0-3] 必须确保顺序读取性能至少为 15 MB/s。
  • [8.2/T-0-4] 必须确保随机读取性能至少为 3.5 MB/s。

如果 TV 设备实现中的某些功能可改进 AOSP 中的设备电源管理或可扩展 AOSP 中的功能，则：

  • [8.3/T-1-1] 必须提供一种方式，让用户能够启用和停用省电模式。

如果 TV 设备实现没有电池，则：

如果 TV 设备实现有电池，则：

  • [8.3/T-1-3] 必须提供一种方式，让用户能够查看免于进入应用待机模式和低电耗模式的所有应用。

TV 设备实现：

  • [8.4/T-0-1] 必须提供一个关于各组件功耗的配置文件，其中要定义每种硬件组件的电耗值以及组件在一段时间内大概消耗的电量（如 Android 开源项目网站上所述）。
  • [8.4/T-0-2] 必须以毫安小时 (mAh) 为单位报告所有功耗值。
  • [8.4/T-0-3] 必须按每个进程的 UID 报告 CPU 功耗。Android 开源项目通过 uid_cputime 内核模块实现来满足此要求。
  • [8.4/T] 如果无法将硬件组件的功耗归于某个应用，应将其归于硬件组件本身。
  • [8.4/T-0-4] 必须能让应用开发者通过 adb shell dumpsys batterystats shell 命令查看此功耗。

2.3.5. 安全模型

TV 设备实现：

  • [9/T-0-1] 必须声明 android.hardware.security.model.compatible 功能。
  • [9.11/T-0-1] 必须通过隔离的执行环境备份密钥存储区实现。
  • [9.11/T-0-2] 必须具有 RSA、AES、ECDSA 和 HMAC 加密算法以及 MD5、SHA1 和 SHA-2 系列哈希函数的实现，以便在与内核上及更上面运行的代码安全隔离的区域中正确支持 Android Keystore 系统支持的算法。安全隔离必须能够阻止内核或用户空间代码可能会借以获取隔离环境内部状态的所有潜在机制，包括 DMA。上游 Android 开源项目 (AOSP) 通过使用 Trusty 实现来满足此要求，但也可以使用其他基于 ARM TrustZone 的解决方案，或使用经过第三方审核的基于 Hypervisor 的适当隔离方法的安全实现。
  • [9.11/T-0-3] 必须在隔离的执行环境中执行锁定屏幕身份验证，并且只有在成功通过验证后，才允许使用与身份验证绑定的密钥。锁定屏幕凭据的存储方式必须只允许隔离的执行环境执行锁屏身份验证。上游 Android 开源项目提供了可用于满足此要求的 Gatekeeper 硬件抽象层 (HAL) 和 Trusty。
  • [9.11/T-0-4] 如果认证签名密钥有安全硬件保护，并且签名是在安全硬件中进行，必须支持密钥认证。认证签名密钥必须在足够多的设备之间共享，以防止此类密钥被用作设备标识符。如需满足此要求，可以采用的一种方法是共享相同的认证密钥，除非生成了至少 10 万个单元的给定 SKU。如果生成了超过 10 万个单元的 SKU，可以针对每 10 万个单元使用一个不同的密钥。

请注意，如果设备实现已搭载较低 Android 版本，则此类设备无需满足具有由隔离的执行环境支持的密钥库并支持密钥认证这一要求，除非它声明了 android.hardware.fingerprint 功能（该功能需要受隔离的执行环境支持的密钥库）。

如果 TV 设备实现支持安全锁定屏幕，则：

  • [9.11/T-1-1] 必须允许用户为从解锁状态到锁定状态的过渡时间选择休眠超时，允许的最短超时时间为 15 秒。

如果 TV 设备实现包含多位用户，并且未声明 android.hardware.telephony 功能标志，则：

  • [9.5/T-2-1] 必须支持受限资料，此类资料可让设备所有者管理设备上的其他用户以及他们可以使用的功能。借助受限资料，设备所有者可以快速设置供其他用户使用的单独环境，同时还能在可于这些环境中运行的应用内管理更精细的限制。

如果 TV 设备实现包含多位用户，并声明 android.hardware.telephony 功能标志，则：

  • [9.5/T-3-1] 不得支持受限资料，但必须与用于允许/禁止其他用户访问语音通话和短信的控件的 AOSP 实现保持一致。

如果 TV 设备实现声明 android.hardware.microphone，则：

  • [9.8.2/T-4-1] 在应用从麦克风访问音频数据时，必须显示麦克风指示标志，但如果仅 HotwordDetectionService、SOURCE_HOTWORD、ContentCaptureService 或拥有“第 9.1 节 - 权限”中使用 CDD 标识符 [C-3-X] 所列角色的应用访问麦克风，则无需显示麦克风指示标志。
  • [9.8.2/T-4-2] 对于具有可见界面或直接用户互动的系统应用，不得隐藏麦克风指示标志。

如果 TV 设备实现声明 android.hardware.camera.any，则：

  • [9.8.2/T-5-1] 在应用从摄像头访问实时数据时，必须显示摄像头指示标志，但如果仅拥有“第 9.1 节 - 权限”中使用 CDD 标识符 [C-3-X] 所列角色的应用访问摄像头，则无需显示摄像头指示标志。
  • [9.8.2/T-5-2] 对于具有可见界面或直接用户互动的系统应用，不得隐藏摄像头指示标志。

2.3.6. 开发者工具和选项兼容性

TV 设备实现：

  • Perfetto
    • [6.1/T-0-1] 必须向 shell 用户公开 /system/bin/perfetto 二进制文件，且 cmdline 符合 perfetto 文档要求。
    • [6.1/T-0-2] perfetto 二进制文件必须接受符合 perfetto 文档中定义的架构的 protobuf 配置作为输入。
    • [6.1/T-0-3] perfetto 二进制文件必须写入符合 perfetto 文档中定义的架构的 protobuf 轨迹作为输出。
    • [6.1/T-0-4] 必须通过 perfetto 二进制文件至少提供 perfetto 文档中所述的数据源。

2.4. Watch 设备相关要求

Android Watch 设备指的是一种应穿戴在身上（也许是戴在手腕上）的 Android 设备实现。

满足以下所有条件的 Android 设备实现可归类为 Watch 设备：

  • 具有物理对角线长度介于 1.1 到 2.5 英寸之间的屏幕。
  • 具有旨在方便穿戴在身上的机制。

本节其余部分中的附加要求针对的是 Android Watch 设备实现。

2.4.1. 硬件

Watch 设备实现：

  • [7.1.1.1/W-0-1] 必须具有物理对角线尺寸介于 1.1 到 2.5 英寸之间的屏幕。

  • [7.2.3/W-0-1] 必须为用户提供“主屏幕”功能，还必须提供“返回”功能（处于 UI_MODE_TYPE_WATCH 模式时除外）。

  • [7.2.4/W-0-1] 必须支持触摸屏输入。

  • [7.3.1/W-SR-1] 强烈建议包含 3 轴加速计。

如果 Watch 设备实现包含 GPS/GNSS 接收器，并且通过 android.hardware.location.gps 功能标志向应用报告该功能，则：

  • [7.3.3/W-1-1] 必须在发现 GNSS 测量结果后立即报告，即使尚未报告通过 GPS/GNSS 计算出的位置信息也是如此。
  • [7.3.3/W-1-2] 必须报告 GNSS 伪距和伪距率，以便在确定位置之后，在露天条件下，当设备处于静止状态或以小于 0.2 m/s² 的加速度移动时，至少在 95% 的情况下能够计算出 20 米以内的位置以及 0.2 m/s 以内的速度。

如果 Watch 设备实现包含 3 轴陀螺仪，则：

  • [7.3.4/W-2-1] 必须能够测量高达 1,000 度/秒的方向变化。

Watch 设备实现：

  • [7.4.3/W-0-1] 必须支持蓝牙。

  • [7.6.1/W-0-1] 必须有至少 1 GB 的非易失性存储空间可用于存储应用专属数据（该空间也称为“/data”分区）。

  • [7.6.1/W-0-2] 必须有至少 416 MB 的内存可供内核和用户空间使用。

  • [7.8.1/W-0-1] 必须包含麦克风。

  • [7.8.2/W] 可以包含音频输出机制。

2.4.2. 多媒体

没有额外要求。

2.4.3. 软件

Watch 设备实现：

  • [3/W-0-1] 必须声明 android.hardware.type.watch 功能。
  • [3/W-0-2] 必须支持 uiMode = UI_MODE_TYPE_WATCH。
  • [3.2.3.1/W-0-1] 对于此处列出的以下应用 intent 所定义的所有公共 intent 过滤器模式，必须用 intent 处理程序预加载一个或多个应用或服务组件。

Watch 设备实现：

  • [3.8.4/W-SR-1] 强烈建议在设备上实现一个辅助程序来处理辅助操作。

声明 android.hardware.audio.output 功能标志的 Watch 设备实现：

  • [3.10/W-1-1] 必须支持第三方无障碍服务。
  • [3.10/W-SR-1] 强烈建议在设备上预加载无障碍服务，并且这些服务的功能要与 TalkBack 开源项目中提供的开关控制和 TalkBack（适用于预安装的文字转语音引擎支持的语言）无障碍服务的功能相当或更胜一筹。

如果 Watch 设备实现报告 android.hardware.audio.output 功能，则：

  • [3.11/W-SR-1] 强烈建议包含支持设备上可用语言的 TTS 引擎。

  • [3.11/W-0-1] 必须支持安装第三方 TTS 引擎。

2.4.4. 性能与功耗

如果 Watch 设备实现中的某些功能可改进 AOSP 中的设备电源管理或可扩展 AOSP 中的功能，则：

  • [8.3/W-SR-1] 强烈建议提供一种方式，让用户能够查看免于进入节能模式（应用待机模式和低电耗模式）的所有应用。
  • [8.3/W-SR-2] 强烈建议提供一种方式，让用户能够启用和停用省电模式。

Watch 设备实现：

  • [8.4/W-0-1] 必须提供一个关于各组件功耗的配置文件，其中要定义每种硬件组件的电耗值以及组件在一段时间内大概消耗的电量（如 Android 开源项目网站上所述）。
  • [8.4/W-0-2] 必须以毫安小时 (mAh) 为单位报告所有功耗值。
  • [8.4/W-0-3] 必须按每个进程的 UID 报告 CPU 功耗。Android 开源项目通过 uid_cputime 内核模块实现来满足此要求。
  • [8.4/W-0-4] 必须能让应用开发者通过 adb shell dumpsys batterystats shell 命令查看此功耗。
  • [8.4/W] 如果无法将硬件组件的功耗归于某个应用，应将其归于硬件组件本身。

2.4.5. 安全模型

Watch 设备实现：

  • [9/W-0-1] 必须声明 android.hardware.security.model.compatible 功能。

如果 Watch 设备实现包含多位用户，并且未声明 android.hardware.telephony 功能标志，则：

  • [9.5/W-1-1] 必须支持受限资料，此类资料可让设备所有者管理设备上的其他用户以及他们可以使用的功能。借助受限资料，设备所有者可以快速设置供其他用户使用的单独环境，同时还能在可于这些环境中运行的应用内管理更精细的限制。

如果 Watch 设备实现包含多位用户，并声明 android.hardware.telephony 功能标志，则：

  • [9.5/W-2-1] 不得支持受限资料，但必须与用于允许/禁止其他用户访问语音通话和短信的控件的 AOSP 实现保持一致。

新要求开始

如果设备实现包含安全锁定屏幕，并且包含一个或多个实现 TrustAgentService 系统 API 的可信代理，则：

  • [9.11.1/W-1-1] 必须至少每隔 72 小时要求用户通过建议的主要身份验证方法之一（例如 PIN 码、图案、密码）验证身份。

新要求结束

2.5. Automotive 设备相关要求

Android Automotive 实现指的是一种汽车音响主机，运行 Android 操作系统来实现部分或全部的系统功能和/或信息娱乐功能。

声明 android.hardware.type.automotive 功能或满足以下所有条件的 Android 设备实现可归类为 Automotive 设备。

  • 作为部件嵌入到车辆上或可插入到车辆上。
  • 使用驾驶侧的屏幕作为主要显示屏。

本节其余部分中的附加要求针对的是 Android Automotive 设备实现。

2.5.1. 硬件

Automotive 设备实现：

  • [7.1.1.1/A-0-1] 必须具有物理对角线尺寸至少为 15.2 厘米（6 英寸）的屏幕。
  • [7.1.1.1/A-0-2] 屏幕尺寸布局必须至少为 750 dp x 480 dp。
  • [7.2.3/A-0-1] 必须提供“主屏幕”功能，并且可以提供“返回”和“最近”功能。
  • [7.2.3/A-0-2] 必须将“返回”功能 (KEYCODE_BACK) 的常规按下事件和长按事件都发送到前台应用。
  • [7.3/A-0-1] 必须实现并报告 GEAR_SELECTION、NIGHT_MODE、PERF_VEHICLE_SPEED 和 PARKING_BRAKE_ON。
  • [7.3/A-0-2] NIGHT_MODE 标志的值必须与信息中心的日间/夜间模式一致，并且应基于环境光传感器输入。底层环境光传感器可以与光度计使用同一个传感器。
  • [7.3/A-0-3] 必须针对所提供的每个传感器提供传感器额外信息字段 TYPE_SENSOR_PLACEMENT（作为 SensorAdditionalInfo 的一部分）。
  • [7.3/A-SR1] 可能会通过将 GPS/GNSS 与其他传感器融合，对位置进行航位推算。如果对位置进行航位推算，则强烈建议实现并报告所使用的相应传感器类型和/或车辆属性 ID。

  • [7.3/A-0-4] 通过 LocationManager#requestLocationUpdates() 请求的位置信息不得与地图匹配。

  • [7.3.1/A-0-4] 必须遵从 Android 汽车传感器坐标系。

  • [7.3/A-SR-1] 强烈建议包含 3 轴加速度计和 3 轴陀螺仪。

  • [7.3/A-SR-2] 强烈建议实现并报告 TYPE_HEADING 传感器。

如果 Automotive 设备实现支持 OpenGL ES 3.1，则：

  • [7.1.4.1/A-0-1] 必须声明 OpenGL ES 3.1 或更高版本。
  • [7.1.4.1/A-0-2] 必须支持 Vulkan 1.1。
  • [7.1.4.1/A-0-3] 必须包含 Vulkan 加载程序并导出所有符号。

如果 Automotive 设备实现包含加速度计，则：

  • [7.3.1/A-1-1] 报告事件能够达到的最高频率必须至少为 100 Hz。

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

  • [7.3.1/A-SR-1] 强烈建议针对有限轴加速度计实现复合传感器。

如果 Automotive 设备实现包含轴数少于 3 的加速度计，则：

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

如果 Automotive 设备实现包含陀螺仪，则：

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

如果 Automotive 设备实现包含 3 轴陀螺仪，则：

  • [7.3.4/A-SR-2] 强烈建议针对有限轴陀螺仪实现复合传感器。

如果 Automotive 设备实现包含轴数少于 3 的陀螺仪，则：

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

如果 Automotive 设备实现包含 GPS/GNSS 接收器，但不包含基于移动网络的数据连接，则：

  • [7.3.3/A-3-1] 必须在第一次开启 GPS/GNSS 接收器时或在 4 天或更长时间后的 60 秒内确定位置。
  • [7.3.3/A-3-2] 对于其他所有位置请求（即，不是第一次或者 4 天或更长时间以后的请求)，必须符合 7.3.3/C-1-2 和 7.3.3/C-1-6 中所述的首次定位时间标准。没有基于移动网络的数据连接的车辆通常可以满足7.3.3/C-1-2 要求，方法是使用接收器上计算出的 GNSS 轨道预测，或使用最近一次的已知车辆位置以及在位置精确度满足 7.3.3/C-1-3 的前提下执行 60 秒航位推算的能力，或者两者相结合。

如果 Automotive 设备实现包含 TYPE_HEADING 传感器，则：

  • [7.3.4/A-4-3] 报告事件能够达到的最高频率必须至少为 1 Hz。
  • [7.3.4/A-SR-3] 强烈建议报告事件达到的最高频率至少为 10 Hz。
  • 应参照正北方向。
  • 即使车辆静止时，也应保持可用。
  • 分辨率应至少为 1 度。

Automotive 设备实现：

  • [7.4.3/A-0-1] 必须支持蓝牙，并且应支持蓝牙 LE。
  • [7.4.3/A-0-2] Android Automotive 实现必须支持以下蓝牙配置文件：
    • 通过免触摸操作配置文件 (HFP) 拨打电话。
    • 通过音频分发配置文件 (A2DP) 播放媒体。
    • 通过远程控制配置文件 (AVRCP) 控制媒体播放。
    • 使用电话簿访问配置文件 (PBAP) 分享联系人信息。

  • [7.4.3/A-SR-1] 强烈建议支持消息访问配置文件 (MAP)。

  • [7.4.5/A] 应支持基于移动网络的数据连接。

  • [7.4.5/A] 可以针对应可供系统应用使用的网络使用系统 API NetworkCapabilities#NET_CAPABILITY_OEM_PAID 常量。

新要求开始

如果设备实现支持 AM/FM 广播无线装置，并将该功能提供给所有应用使用，则：

  • [7.4.10/A-0-1] 必须声明支持 FEATURE_BROADCAST_RADIO。

新要求结束

外景摄像头是一种用来拍摄设备实现外部场景的摄像头（如后视摄像头）。

Automotive 设备实现：

  • 应包含一个或多个外景摄像头。

如果 Automotive 设备实现包含一个外景摄像头，则对于此类摄像头，这类实现：

  • [7.5/A-1-1] 不得有可通过 Android Camera API 访问的外景摄像头，除非它们符合摄像头核心要求。

  • [7.5/A-SR-1] 强烈建议不要旋转或水平镜像摄像头预览。

  • [7.5/A-SR-2] 强烈建议分辨率至少为 130 万像素。

  • 应具有固定焦距硬件或 EDOF（扩展景深）硬件。

  • 可以在摄像头驱动程序中实现硬件自动对焦或软件自动对焦。

如果 Automotive 设备实现包含一个或多个外景摄像头，并加载外景系统 (EVS) 服务，则对于此类摄像头，这类实现：

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

Automotive 设备实现：

  • 可以包含一个或多个可供第三方应用使用的摄像头。

如果车载设备实现包含至少一个摄像头，并使其可供第三方应用使用，则：

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

新要求开始

后置摄像头是指朝向外面的摄像头，可以位于车辆的任何位置，并朝向车厢的外部；也就是说，与传统摄像头一样，它拍摄的是背向车身一侧的景物。

前置摄像头是指朝向用户的摄像头，可以位于车辆的任何位置，并朝向车厢的内部；也就是说，它拍摄的是用户，例如用于视频会议和类似应用的摄像头。

Automotive 设备实现：

  • [7.5/A-SR-1] 强烈建议包含一个或多个朝向外面的摄像头。
  • 可以包含一个或多个朝向用户的摄像头。
  • [7.5/A-SR-2] 强烈建议支持对多个摄像头进行并发流式传输。

如果 Automotive 设备实现至少包含一个朝向外面的摄像头，对于此类摄像头，则：

  • [7.5/A-1-1] 必须朝向正确方向，以便摄像头的长度方向与 Android Automotive 传感器坐标轴的 X-Y 平面对齐。
  • [7.5/A-SR-3] 强烈建议采用固定焦距硬件或 EDOF（扩展景深）硬件。
  • [7.5/A-1-2] 必须将主要的朝向外面的摄像头作为摄像头 ID 值最小的朝向外面的摄像头。

如果 Automotive 设备实现至少包含一个朝向用户的摄像头，对于此类摄像头，则：

  • [7.5/A-2-1] 主要的朝向用户的摄像头必须是摄像头 ID 值最小的朝向用户的摄像头。
  • 可以朝向正确方向，以便摄像头的长度方向与 Android Automotive 传感器坐标轴的 X-Y 平面对齐。

如果 Automotive 设备实现包含可通过 android.hardware.Camera 或 android.hardware.camera2 API 访问的摄像头，对于此类摄像头，则：

  • [7.5/A-3-1] 必须遵守第 7.5 节中的核心摄像头要求。

如果 Automotive 设备实现包含无法通过 android.hardware.Camera 或 android.hardware.camera2 API 访问的摄像头，对于此类摄像头，则：

  • [7.5/A-4-1] 必须可通过增强型视觉系统服务访问。

如果 Automotive 设备实现包含一个或多个可通过增强型视觉系统服务访问的摄像头，对于此类摄像头，则：

  • [7.5/A-5-1] 不得旋转或水平镜像摄像头预览。
  • [7.5/A-SR-4] 强烈建议分辨率至少为 130 万像素。

如果 Automotive 设备实现包含一个或多个可通过增强型视觉系统服务与 android.hardware.Camera 或 android.hardware.Camera2 API 访问的摄像头，对于此类摄像头，则：

  • [7.5/A-6-1] 必须报告相同的摄像头 ID。

如果 Automotive 设备实现提供专有摄像头 API，则：

新要求结束

Automotive 设备实现：

  • [7.6.1/A-0-1] 必须有至少 4 GB 的非易失性存储空间可用于存储应用专属数据（该空间也称为“/data”分区）。

  • [7.6.1/A] 应格式化数据分区以提升闪存的性能和使用寿命（例如采用 f2fs 文件系统）。

如果 Automotive 设备实现通过一部分内部（不可移动）存储设备来提供共享的外部存储空间，则：

  • [7.6.1/A-SR-1] 强烈建议减少对外部存储空间执行操作所需的 I/O 开销（例如使用 SDCardFS）。

如果 Automotive 设备实现是 64 位：

  • [7.6.1/A-2-1] 如果使用了以下任何密度，可供内核和用户空间使用的内存必须至少为 816 MB：

    • 280dpi 或更低（小屏幕/普通屏幕）
    • ldpi 或更低（超大屏幕）
    • mdpi 或更低（大屏幕）

  • [7.6.1/A-2-2] 如果使用了以下任何密度，可供内核和用户空间使用的内存必须至少为 944 MB：

    • xhdpi 或更高（小屏幕/普通屏幕）
    • hdpi 或更高（大屏幕）
    • mdpi 或更高（超大屏幕）

  • [7.6.1/A-2-3] 如果使用了以下任何密度，可供内核和用户空间使用的内存必须至少为 1,280 MB：

    • 400dpi 或更高（小屏幕/普通屏幕）
    • xhdpi 或更高（大屏幕）
    • tvdpi 或更高（超大屏幕）

  • [7.6.1/A-2-4] 如果使用了以下任何密度，可供内核和用户空间使用的内存必须至少为 1,824 MB：

    • 560dpi 或更高（小屏幕/普通屏幕）
    • 400dpi 或更高（大屏幕）
    • xhdpi 或更高（超大屏幕）

请注意，上文提到的“可供内核和用户空间使用的内存”是指除了已专门用于硬件组件（例如设备实现上的无线装置、视频组件，以及其他不受内核控制的组件）的所有内存之外，另行提供的内存空间。

Automotive 设备实现：

  • [7.7.1/A] 应包含支持外围设备模式的 USB 端口。

Automotive 设备实现：

  • [7.8.1/A-0-1] 必须包含麦克风。

Automotive 设备实现：

  • [7.8.2/A-0-1] 必须具有音频输出机制，并声明 android.hardware.audio.output。

2.5.2. 多媒体

Automotive 设备实现必须支持以下音频编码和解码格式，并使其可供第三方应用使用：

  • [5.1/A-0-1] MPEG-4 AAC Profile (AAC LC)
  • [5.1/A-0-2] MPEG-4 HE AAC Profile (AAC+)
  • [5.1/A-0-3] AAC ELD（增强型低延迟 AAC）

Automotive 设备实现必须支持以下视频编码格式，并使其可供第三方应用使用：

  • [5.2/A-0-1] H.264 AVC
  • [5.2/A-0-2] VP8

Automotive 设备实现必须支持以下视频解码格式，并使其可供第三方应用使用：

  • [5.3/A-0-1] H.264 AVC
  • [5.3/A-0-2] MPEG-4 SP
  • [5.3/A-0-3] VP8
  • [5.3/A-0-4] VP9

强烈建议 Automotive 设备实现支持以下视频解码：

  • [5.3/A-SR-1] H.265 HEVC

2.5.3. 软件

Automotive 设备实现：

  • [3/A-0-1] 必须声明 android.hardware.type.automotive 功能。

  • [3/A-0-2] 必须支持 uiMode = UI_MODE_TYPE_CAR。

  • [3/A-0-3] 必须支持 android.car.* 命名空间中的所有公共 API。

如果 Automotive 设备实现通过 android.car.VehiclePropertyIds 使用 android.car.CarPropertyManager 提供专有 API，则：

  • [3/A-1-1] 不得为系统应用使用这些属性的情况附加特殊权限，也不得阻止第三方应用使用这些属性。
  • [3/A-1-2] 不得复制 SDK 中已有的车辆属性。

Automotive 设备实现：

  • [3.2.1/A-0-1] 必须支持并强制执行“Automotive 权限”参考页面中所述的所有权限常量。

  • [3.2.3.1/A-0-1] 对于此处列出的以下应用 intent 所定义的所有公共 intent 过滤器模式，必须用 intent 处理程序预加载一个或多个应用或服务组件。

  • [3.4.1/A-0-1] 必须提供 android.webkit.Webview API 的完整实现。

新要求开始

  • [3.8/A-0-1] 不得允许非当前前台用户的完全次要用户在任何屏幕上启动 activity 和访问界面。

新要求结束

如果 Automotive 设备实现包含按键通话按钮，则：

  • [3.8.4/A-1-1] 必须将短按按键通话按钮用作启动用户选择的辅助应用（也就是实现 VoiceInteractionService 的应用）的指定互动。

Automotive 设备实现：

如果 Automotive 设备实现支持用户 HAL 属性，则：

Automotive 设备实现：

如果 Automotive 设备实现包含默认启动器应用，则：

Automotive 设备实现：

  • [3.8/A] 可通过限制应用请求来限制进入全屏模式的功能（如 immersive documentation 中所述）。
  • [3.8/A] 可始终保持状态栏和导航栏可见。
  • [3.8/A] 可通过限制应用请求来限制更改系统界面元素背后颜色的功能，以确保这些元素始终清晰可见。

2.5.4. 性能与功耗

Automotive 设备实现：

  • [8.2/A-0-1] 必须按每个进程的 UID 报告读取和写入非易失性存储空间的字节数，以便开发者通过系统 API android.car.storagemonitoring.CarStorageMonitoringManager 获取统计信息。Android 开源项目通过 uid_sys_stats 内核模块来满足此要求。
  • [8.3/A-1-3] 必须支持车库模式。
  • [8.3/A] 每次驾车后应该处于车库模式至少 15 分钟，除非：
    • 电池电量耗尽。
    • 未安排空闲作业。
    • 驾驶员退出“车库模式”。
  • [8.4/A-0-1] 必须提供一个关于各组件功耗的配置文件，其中要定义每种硬件组件的电耗值以及组件在一段时间内大概消耗的电量（如 Android 开源项目网站上所述）。
  • [8.4/A-0-2] 必须以毫安小时 (mAh) 为单位报告所有功耗值。
  • [8.4/A-0-3] 必须按每个进程的 UID 报告 CPU 功耗。Android 开源项目通过 uid_cputime 内核模块实现来满足此要求。
  • [8.4/A] 如果无法将硬件组件的功耗归于某个应用，应将其归于硬件组件本身。
  • [8.4/A-0-4] 必须能让应用开发者通过 adb shell dumpsys batterystats shell 命令查看此功耗。

2.5.5. 安全模型

如果 Automotive 设备实现支持多个用户，则：

新要求开始

如果 Automotive 设备实现声明 android.hardware.microphone，则：

  • [9.8.2/A-1-1] 在应用从麦克风访问音频数据时，必须显示麦克风指示标志，但如果仅 HotwordDetectionService、SOURCE_HOTWORD、ContentCaptureService 或拥有第 9.1 节中使用 CDD 标识符 [C-4-X] 所列的角色的应用访问麦克风，则无需显示麦克风指示标志。
  • [9.8.2/A-1-2] 对于具有可见界面或直接用户互动的系统应用，不得隐藏麦克风指示标志。
  • [9.8.2/A-1-3] 必须提供一种方式，让用户能够在“设置”应用中切换麦克风。

新要求结束

如果 Automotive 设备实现声明 android.hardware.camera.any，则：

  • [9.8.2/A-2-1] 在应用从摄像头访问实时数据时，必须显示摄像头指示标志，但如果仅拥有“第 9.1 节 - 权限”中使用 CDD 标识符 [C-4-X][C-3-X] 所定义所列角色的应用访问摄像头，则无需显示摄像头指示标志。
  • [9.8.2/A-2-2] 对于具有可见界面或直接用户互动的系统应用，不得隐藏摄像头指示标志。

新要求开始

  • [9.8.2/A-2-3] 必须提供一种方式，让用户能够在“设置”应用中切换摄像头。
  • [9.8.2/A-2-4] 必须根据 PermissionManager.getIndicatorAppOpUsageData() 返回的内容显示使用摄像头的“最近用过”和“使用中”应用，以及与此类应用相关联的所有归因信息。

新要求结束

Automotive 设备实现：

  • [9/A-0-1] 必须声明 android.hardware.security.model.compatible 功能。
  • [9.11/A-0-1] 必须通过隔离的执行环境备份密钥存储区实现。
  • [9.11/A-0-2] 必须具有 RSA、AES、ECDSA 和 HMAC 加密算法以及 MD5、SHA1 和 SHA-2 系列哈希函数的实现，以便在与内核上及更上面运行的代码安全隔离的区域中正确支持 Android Keystore 系统支持的算法。安全隔离必须能够阻止内核或用户空间代码可能会借以获取隔离环境内部状态的所有潜在机制，包括 DMA。上游 Android 开源项目 (AOSP) 通过使用 Trusty 实现来满足此要求，但也可以使用其他基于 ARM TrustZone 的解决方案，或使用经过第三方审核的基于 Hypervisor 的适当隔离方法的安全实现。
  • [9.11/A-0-3] 必须在隔离的执行环境中执行锁定屏幕身份验证，并且只有在成功通过验证后，才允许使用与身份验证绑定的密钥。锁定屏幕凭据的存储方式必须只允许隔离的执行环境执行锁屏身份验证。上游 Android 开源项目提供了可用于满足此要求的 Gatekeeper 硬件抽象层 (HAL) 和 Trusty。
  • [9.11/A-0-4] 如果认证签名密钥有安全硬件保护，并且签名是在安全硬件中进行，必须支持密钥认证。认证签名密钥必须在足够多的设备之间共享，以防止此类密钥被用作设备标识符。如需满足此要求，可以采用的一种方法是共享相同的认证密钥，除非生成了至少 10 万个单元的给定 SKU。如果生成了超过 10 万个单元的 SKU，可以针对每 10 万个单元使用一个不同的密钥。

请注意，如果设备实现已搭载较低 Android 版本，则此类设备无需满足具有由隔离的执行环境支持的密钥库并支持密钥认证这一要求，除非它声明了 android.hardware.fingerprint 功能（该功能需要受隔离的执行环境支持的密钥库）。

Automotive 设备实现：

  • [9.14/A-0-1] 必须对来自 Android 框架车载子系统的消息进行把关，例如将允许的消息类型和消息来源列入许可名单。
  • [9.14/A-0-2] 必须监控来自 Android 框架或第三方应用的拒绝服务攻击。这是为了防范恶意软件利用流量对车载网络进行泛洪攻击，此类攻击可能会导致车载子系统无法正常运行。

2.5.6. 开发者工具和选项兼容性

Automotive 设备实现：

  • Perfetto
    • [6.1/A-0-1] 必须向 shell 用户公开 /system/bin/perfetto 二进制文件，且 cmdline 符合 perfetto 文档要求。
    • [6.1/A-0-2] perfetto 二进制文件必须接受符合 perfetto 文档中定义的架构的 protobuf 配置作为输入。
    • [6.1/A-0-3] perfetto 二进制文件必须写入符合 perfetto 文档中定义的架构的 protobuf 轨迹作为输出。
    • [6.1/A-0-4] 必须通过 perfetto 二进制文件至少提供 perfetto 文档中所述的数据源。

2.6. 平板电脑设备相关要求

Android 平板电脑设备指的是一种 Android 设备实现，通常符合以下所有条件：

  • 拿在双手中使用。
  • 没有翻盖式或可转换配置。
  • 与设备配合使用的实体键盘实现通过标准连接（例如 USB 和蓝牙）连接。

  • 具有能够使设备实现移动性的电源，例如电池。

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

平板电脑设备实现需要满足的要求与手持设备实现需要满足的要求类似。对于两者的不同之处，手持设备实现要求的相应章节中已使用 * 指明，本节中也提供了相应备注以供参考。

2.6.1. 硬件

陀螺仪

如果平板电脑设备实现包含 3 轴陀螺仪，则：

  • [7.3.4/Tab-1-1] 必须能够测量高达 1,000 度/秒的方向变化。

最小内存和存储空间（第 7.6.1 节）

手持设备相关要求中为小屏幕/普通屏幕列出的屏幕密度不适用于平板电脑。

USB 外围设备模式（第 7.7.1 节）

如果平板电脑设备实现包含支持外围设备模式的 USB 端口，则：

  • [7.7.1/Tab] 可以实现 Android Open Accessory (AOA) API。

虚拟实境模式（第 7.9.1 节）

虚拟实境高性能（第 7.9.2 节）

针对虚拟现实的要求不适用于平板电脑。

2.6.2. 安全模型

密钥和凭据（第 9.11 节）

请参阅第 [9.11] 节。

如果平板电脑设备实现包含多位用户，并且未声明 android.hardware.telephony 功能标志，则：

  • [9.5/T-1-1] 必须支持受限资料，此类资料可让设备所有者管理设备上的其他用户以及他们可以使用的功能。借助受限资料，设备所有者可以快速设置供其他用户使用的单独环境，同时还能在可于这些环境中运行的应用内管理更精细的限制。

如果平板电脑设备实现包含多位用户，并声明 android.hardware.telephony 功能标志，则：

  • [9.5/T-2-1] 不得支持受限资料，但必须与用于允许/禁止其他用户访问语音通话和短信的控件的 AOSP 实现保持一致。

2.6.2. 软件

  • [3.2.3.1/Tab-0-1] 对于此处列出的以下应用 intent 所定义的所有公共 intent 过滤器模式，必须用 intent 处理程序预加载一个或多个应用或服务组件。

3. 软件

3.1. 受管理 API 兼容性

受管理 Dalvik 字节码执行环境是 Android 应用所需的主要容器。Android 应用编程接口 (API) 是一组 Android 平台接口，可供在受管理运行时环境中运行的应用使用。

设备实现：

  • [C-0-1] 必须提供以下 API 的完整实现（包括所有载述的行为）：Android SDK 中所述的所有 API，或上游 Android 源代码中所有带“@SystemApi”标记的 API。

  • [C-0-2] 必须支持/保留所有标有 TestApi 注记 (@TestApi) 的类、方法和关联的元素。

  • [C-0-3] 除非本兼容性定义中明确许可，否则不得省略任何受管理 API，不得更改 API 接口或签名，不得违背载述的行为，也不得包含空操作。

  • [C-0-4] 必须仍保留 API 并使其采取合理的行为方式，即使 Android 包含的 API 所对应的某些硬件功能被省略也是如此。如需了解针对这种情况的具体要求，请参阅第 7 节。

  • [C-0-5] 不得允许第三方应用使用非 SDK 接口，这些接口在位于 AOSP 的启动类路径中的 Java 语言软件包中被定义为方法和字段，且不属于公共 SDK 的一部分。这包含带 @hide 注解但不带 @SystemAPI 的 API（如 SDK 文档中所述）以及私有和软件包私有类成员。

  • [C-0-6] 必须在通过 prebuilts/runtime/appcompat/hiddenapi-flags.csv 路径下的临时和拒绝名单标志为 AOSP 中相应的 API 级别分支提供的相同受限列表中随附每个非 SDK 接口。

  • [C-0-7] 必须支持签名配置动态更新机制，以便通过在任何 APK 中嵌入签名配置，使用 AOSP 中现有的公钥从受限列表中移除非 SDK 接口。

    不过：

    • 如果隐藏 API 不存在或在设备实现中以其他方式实现，则可以将隐藏 API 移入拒绝名单或从所有受限列表中将其省略。
    • 如果 AOSP 中尚没有某个隐藏 API，则可以将该隐藏 API 添加到任一受限列表中。

新要求开始

  • [C-0-8] 不得支持安装目标 API 级别低于 23 的应用。

新要求结束

3.1.1. Android 扩展

Android 支持通过更新某个 API 级别的扩展版本来扩展该 API 级别的受管理 API Surface。如果所提供的 API 级别存在扩展，android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) API 会返回该 apiLevel 的扩展版本。

Android 设备实现：

  • [C-0-1] 必须预加载 ExtShared 共享库和 ExtServices 服务（版本不低于每个 API 级别所允许的最低版本）的 AOSP 实现。例如，运行 API 24 级的 Android 7.0 设备实现包含的版本必须至少为 1。

  • [C-0-2] 必须仅返回已由 AOSP 定义的有效扩展版本号。

  • [C-0-3] 必须按照第 3.1 节中的要求，以支持其他受管理 API 的方式支持由 android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) 返回的扩展版本所定义的所有 API。

3.1.2. Android 库

由于已废弃 Apache HTTP 客户端，设备实现：

  • [C-0-1] 不得将 org.apache.http.legacy 库放入启动类路径。
  • [C-0-2] 必须仅在应用满足以下某一项条件时才将 org.apache.http.legacy 库添加到应用类路径中：
    • 以 API 级别 28 或更低级别为目标。
    • 通过将 <uses-library> 的 android:name 属性设置为 org.apache.http.legacy，在清单中声明它需要该库。

AOSP 实现满足上述要求。

3.2. 软 API 兼容性

除了第 3.1 节中的受管理 API 之外，Android 还包含一个非常重要的运行时专用“软”API，该 API 采用 intent、权限，以及 Android 应用的类似方面（它们在应用编译期间无法被强制执行）等形式。

3.2.1. 权限

  • [C-0-1] 设备实现必须支持并强制执行“权限”参考页面中所述的所有权限常量。请注意，第 9 节列出了与 Android 安全模型相关的其他要求。

3.2.2. build 参数

Android API 在 android.os.Build 类中包含一些用于描述当前设备的常量。

  • [C-0-1] 为了在各种设备实现之间提供一致且有意义的值，下表中列出了针对这些值的格式的一些额外限制，设备实现必须遵从这些限制。
参数 详细信息
VERSION.RELEASE 当前正在执行的 Android 系统的版本，采用人类可读懂的格式。此字段的值必须是允许的 Android 14 版本字符串中定义的字符串值之一。
VERSION.SDK 当前正在执行的 Android 系统的版本，采用第三方应用代码可访问的格式。对于 Android 14，此字段必须为整数值 14_INT。
VERSION.SDK_INT 当前正在执行的 Android 系统的版本，采用第三方应用代码可访问的格式。对于 Android 14，此字段必须为整数值 14_INT。
VERSION.INCREMENTAL 由设备实现者选择的值，用于指定当前正在执行的 Android 系统的具体 build，采用人类可读懂的格式。此值不得重复用于提供给最终用户的不同 build。此字段的一个典型用途是，指示用于生成 build 的 build 号或源代码控制更改标识符。此字段的值必须可编码为可打印的 7 位 ASCII 值，并与正则表达式“^[^ :\/~]+$”匹配。
BOARD 由设备实现者选择的值，用于标识设备所使用的具体内部硬件，采用人类可读懂的格式。此字段的一个可能用途是指明设备主板的具体修订版本。此字段的值必须可编码为 7 位的 ASCII 值，并与正则表达式“^[a-zA-Z0-9_-]+$”匹配。
BRAND 该值用于指明与设备关联的品牌名称，即最终用户所熟知的设备品牌名称。必须采用人类可读懂的格式，并且应表示设备的制造商或设备在营销时所冠的公司品牌。此字段的值必须可编码为 7 位的 ASCII 值，并与正则表达式“^[a-zA-Z0-9_-]+$”匹配。
SUPPORTED_ABIS 原生代码指令集的名称（CPU 类型 + ABI 惯例）。请参阅第 3.3 节 - 原生 API 兼容性。
SUPPORTED_32_BIT_ABIS 原生代码指令集的名称（CPU 类型 + ABI 惯例）。请参阅第 3.3 节 - 原生 API 兼容性。
SUPPORTED_64_BIT_ABIS 原生代码第二个指令集的名称（CPU 类型 + ABI 惯例）。请参阅第 3.3 节 - 原生 API 兼容性。
CPU_ABI 原生代码指令集的名称（CPU 类型 + ABI 惯例）。请参阅第 3.3 节 - 原生 API 兼容性。
CPU_ABI2 原生代码第二个指令集的名称（CPU 类型 + ABI 惯例）。请参阅第 3.3 节 - 原生 API 兼容性。
DEVICE 由设备实现者选择的值，其中包含开发者名称或代码名称，用于标识设备的硬件功能和工业设计配置。此字段的值必须可编码为 7 位的 ASCII 值，并与正则表达式“^[a-zA-Z0-9_-]+$”匹配。此设备名称在产品的生命周期内不得更改。
FINGERPRINT 该字符串用于标识相应 build，具有唯一性，应采用人类可读懂的格式，且必须遵循以下模板：

$(BRAND)/$(PRODUCT)/
    $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS)

例如：

acme/myproduct/
    mydevice:14/LMYXX/3359:userdebug/test-keys

该指纹不得包含空格。此字段的值必须可编码为 7 位的 ASCII 值。
HARDWARE 硬件的名称（来自内核命令行或 /proc），应采用人类可读懂的格式。此字段的值必须可编码为 7 位的 ASCII 值，并与正则表达式“^[a-zA-Z0-9_-]+$”匹配。
HOST 一个唯一标识构建相应 build 时所用主机的字符串，采用人类可读懂的格式。此字段不得为 null，也不得为空字符串 ("")，除此之外，对此字段的具体格式没有任何要求。
ID 由设备实现者选择的标识符，用于指特定版本，采用人类可读懂的格式。此字段可与 android.os.Build.VERSION.INCREMENTAL 相同，但应是对最终用户来说有充分意义的值，以便他们区分各软件 build。此字段的值必须可编码为 7 位的 ASCII 值，并与正则表达式“^[a-zA-Z0-9._-]+$”匹配。
MANUFACTURER 产品的原始设备制造商 (OEM) 的商号。此字段不得为 null，也不得为空字符串 ("")，除此之外，对该字段的具体格式没有任何其他要求。此字段在商品的生命周期内不得更改。
SOC_MANUFACTURER 商品中使用的主系统芯片 (SOC) 的制造商的商号。同一 SOC 制造商的设备应使用相同的常量值。请向 SOC 制造商询问要使用的正确常量。此字段的值必须可编码为 7 位的 ASCII 值，并与正则表达式“^([0-9A-Za-z ]+)”匹配，不得以空格开头或结尾，也不得等于“未知”。此字段在商品的生命周期内不得更改。
SOC_MODEL 商品中使用的主系统芯片 (SOC) 的型号名称。同一 SOC 型号的设备应使用相同的常量值。请向 SOC 制造商询问要使用的正确常量。此字段的值必须可编码为 7 位的 ASCII 值，并与正则表达式“([0-9A-Za-z ._/+-]+)$”匹配，不得以空格开头或结尾，也不得等于“未知”。此字段在商品的生命周期内不得更改。
MODEL 由设备实现者选择的值，其中包含最终用户所熟知的设备名称。此名称应与销售设备并出售给最终用户时所使用的名称相同。此字段不得为 null，也不得为空字符串 ("")，除此之外，对该字段的具体格式没有任何其他要求。此字段在商品的生命周期内不得更改。
PRODUCT 由设备实现者选择的值，其中包含具体产品 (SKU) 的开发名称或代号，在同一品牌中必须是独一无二的。必须采用人类可读懂的格式，但不一定可供最终用户查看。此字段的值必须可编码为 7 位的 ASCII 值，并与正则表达式“^[a-zA-Z0-9_-]+$”匹配。此商品名称在产品的生命周期内不得更改。
ODM_SKU 由设备实现者选择的可选值，其中包含 SKU（库存单元），用于跟踪设备的专用配置，例如，设备售出时随附的所有外围设备。 此字段的值必须可编码为 7 位的 ASCII 值，并与正则表达式“[0-9A-Za-z.,_-])”匹配。
SERIAL 必须返回“UNKNOWN”。
TAGS 由设备实现者选择的一系列标记（用于进一步区分 build），各个标记之间以英文逗号分隔。标记必须可编码为 7 位的 ASCII 值，并与正则表达式“^[a-zA-Z0-9._-]+”匹配，而且其值必须是与以下三种典型 Android 平台签名配置对应的值之一：release-keys、dev-keys 和 test-keys。
TIME 该值用于表示生成相应 build 时的时间戳。
TYPE 由设备实现者选择的值，用于指定相应 build 的运行时配置。此字段的值必须是与以下三种典型 Android 运行时配置对应的值之一：user、userdebug 或 eng。
USER 一个生成相应 build 的用户（或自动用户）的名称或 ID。此字段不得为 null，也不得为空字符串 ("")，除此之外，对此字段的具体格式没有任何要求。
SECURITY_PATCH 该值用于指明相应 build 的安全补丁级别。它必须表明相应 build 在任何方面都不容易受到指定的 Android 公共安全公告中所述的任何问题的影响。它必须采用 [YYYY-MM-DD] 格式，并且与 Android 公共安全公告或 Android 安全建议中载述的已定义字符串匹配，例如“2015-11-01”。
BASE_OS 该值表示以下 build 的 FINGERPRINT 参数：除了 Android 公共安全公告中提供的补丁以外，与相应 build 完全相同的 build。它必须报告正确的值，如果这样的 build 不存在，则报告一个空字符串 ("")。
BOOTLOADER 由设备实现者选择的值，用于标识设备所使用的具体内部引导加载程序版本，采用人类可读懂的格式。此字段的值必须可编码为 7 位的 ASCII 值，并与正则表达式“^[a-zA-Z0-9._-]+$”匹配。
getRadioVersion() 必须是或必须返回由设备实现者选择的值，该值用于标识设备使用的具体内部无线装置/调制解调器版本，采用人类可读懂的格式。如果设备没有任何内部无线装置/调制解调器，系统必须返回 NULL。此字段的值必须可编码为 7 位的 ASCII 值，并与正则表达式“^[a-zA-Z0-9._-,]+$”匹配。
getSerial() 必须（是或返回）硬件序列号；如果有多款 MODEL 和 MANUFACTURER 相同的设备，必须为其提供硬件序列号，并且提供的硬件序列号在这些设备中必须是唯一的。此字段的值必须可编码为 7 位的 ASCII 值，并与正则表达式“^[a-zA-Z0-9]+$”匹配。

3.2.3. intent 兼容性

3.2.3.1. 常见应用 intent

通过 Android intent，应用组件可以请求其他 Android 组件的功能。Android 上游项目包含一系列应用，这些应用可实现多种 intent 模式来执行常见操作。

设备实现：

  • [C-SR-1] 对于此处列出的以下应用 intent 所定义的所有公共 intent 过滤器模式，强烈建议用 intent 处理程序预加载一个或多个应用或服务组件，并提供执行方式，即满足开发者对这些常见应用 intent 的期望（如 SDK 中所述）。

请参阅第 2 节，了解每种设备类型的强制性应用 intent。

3.2.3.2. intent 解析

  • [C-0-1] 由于 Android 是一个可扩展的平台，因此设备实现必须允许第三方应用替换第 3.2.3.1 节中提到的每种 intent 模式（“设置”除外）。上游 Android 开放源代码实现默认允许这么做。

  • [C-0-2] 设备实现者不得为系统应用使用这些 intent 模式的情况附加特殊权限，也不得阻止第三方应用绑定到这些模式以及取得对这些模式的控制权。具体来说，此项规定包括但不限于停用“选择器”界面（用户可通过该界面在多个均可处理相同 intent 模式的应用之间进行选择）。

  • [C-0-3] 设备实现必须提供一个界面来供用户修改 intent 的默认 activity。

  • 不过，当默认 activity 为数据 URI 提供更具体的属性时，设备实现可以为特定 URI 模式（例如 http://play.google.com）提供默认 activity。例如，与针对“http://”的浏览器核心 intent 模式相比，指定数据 URI“http://www.android.com”的 intent 过滤器模式更为具体。

Android 还包含可让第三方应用为某些类型的网页 URI intent 声明权威性默认应用链接行为的机制。如果此类权威声明是在某个应用的 intent 过滤器模式中定义的，设备实现：

  • [C-0-4] 必须尝试执行 Digital Asset Links 规范（由上游 Android 开源项目中的软件包管理器实现）中定义的验证步骤，来验证所有 intent 过滤器。
  • [C-0-5] 必须在应用安装期间尝试验证 intent 过滤器，并将所有成功通过验证的 URI intent 过滤器设置为其 URI 的默认应用处理程序。
  • 可以将特定 URI intent 过滤器设为其 URI 的默认应用处理程序，但前提是这些过滤器成功通过验证，而其他候选 URI 过滤器未通过验证。如果设备实现进行此项设置，必须在设置菜单中按 URI 向用户提供适当的模式替换。
  • 必须在“设置”中按应用向用户提供应用链接控制，如下所述：
    • [C-0-6] 用户必须能够整体替换默认应用链接行为，以便应用始终开启、始终询问或永不开启，这必须同样适用于所有候选 URI intent 过滤器。
    • [C-0-7] 用户必须能够查看候选 URI intent 过滤器列表。
    • 设备实现可以按 intent 过滤器提供相应的功能，使用户能够替换成功通过验证的特定候选 URI intent 过滤器。
    • [C-0-8] 如果设备实现允许只有部分（而非全部）候选 URI intent 过滤器成功通过验证，则设备实现必须使用户能够查看和替换特定候选 URI intent 过滤器。
3.2.3.3. intent 命名空间
  • [C-0-1] 设备实现不得包含任何符合以下条件的 Android 组件：遵从任何使用 ACTION、CATEGORY 或使用 android.* 或 com.android.* 命名空间中其他键字符串的新 intent 模式或广播 intent 模式。
  • [C-0-2] 设备实现者不得添加任何符合以下条件的 Android 组件：遵从任何使用 ACTION、CATEGORY 或使用属于其他组织的软件包空间中其他键字符串的新 intent 模式或广播 intent 模式。
  • [C-0-3] 设备实现者不得更改或扩展第 3.2.3.1 节中列出的任何 intent 模式。
  • 设备实现可以包含所用命名空间明显与其所属组织关联的 intent 模式。此项规定类似于第 3.6 节中针对 Java 语言类的规定。
3.2.3.4. 广播 intent

第三方应用依赖平台广播某些 intent 来获悉硬件或软件环境中发生的变化。

设备实现：

  • [C-0-1] 必须广播此处列出的公共广播 intent，以响应相应的系统事件（如 SDK 文档中所述）。请注意，此要求与第 3.5 节并不冲突，因为针对后台应用的限制在 SDK 文档中也有相应说明。此外，某些广播 intent 在硬件支持方面是有条件的，如果设备支持必要的硬件，就必须广播相应 intent 并提供符合 SDK 文档的行为。
3.2.3.5. 有条件应用 intent

Android 包含可让用户轻松选择默认应用（例如选择默认的主屏幕应用或短信应用）的设置。

在适当的情况下，设备实现必须提供类似的设置菜单，并与 SDK 文档中所述的 intent 过滤器模式和 API 方法兼容（详见下文）。

如果设备实现报告 android.software.home_screen，则：

如果设备实现报告 android.hardware.telephony.calling，则：

如果设备实现报告 android.hardware.nfc.hce，则：

如果设备实现报告 android.hardware.nfc，则：

如果设备实现报告 android.hardware.bluetooth，则：

如果设备实现支持 DND 功能，则：

  • [C-6-1] 必须实现会响应 ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS intent 的 activity；对于设置为 UI_MODE_TYPE_NORMAL 的实现，它必须是用户可用于授权或拒绝应用访问 DND 政策配置的 activity。

如果设备实现允许用户在设备上使用第三方输入法，则：

如果设备实现支持第三方无障碍服务，则：

  • [C-8-1] 必须遵从 android.settings.ACCESSIBILITY_SETTINGS intent 以提供一种可供用户使用的机制，以便他们启用和停用第三方无障碍服务以及预加载的无障碍服务。

如果设备实现支持 Wi-Fi Easy Connect，并使该功能可供第三方应用使用，则：

如果设备实现提供流量节省程序模式，则：* [C-10-1] 必须在设置中提供一个界面来处理 Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS intent，以便用户向白名单中添加应用或从中移除应用。

如果设备实现未提供流量节省程序模式，则：

如果设备实现通过 android.hardware.camera.any 声明支持摄像头，则：

如果设备实现报告 android.software.device_admin，则：

如果设备实现声明 android.software.autofill 功能标志，则：

如果设备实现包含预安装的应用，或者希望允许第三方应用访问使用情况统计信息，则：

  • [C-SR-2] 强烈建议能够响应 android.settings.ACTION_USAGE_ACCESS_SETTINGS intent 提供一种可供用户使用的机制，以便他们为声明 android.permission.PACKAGE_USAGE_STATS 权限的应用授予或撤消对使用情况统计信息的访问权限。

如果设备实现打算禁止所有应用（包括预安装的应用）访问使用情况统计信息，则：

如果设备实现呈现与“设置”中 AutofillService_passwordsActivity 指定的 activity 的关联，或通过类似机制呈现与用户密码的关联，则：

  • [C-16-1] 必须呈现有关所有已安装的自动填充服务的此类关联。

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

如果设备实现报告 android.hardware.audio.output 功能，则：

  • [C-SR-3] 强烈建议遵从 android.intent.action.TTS_SERVICE、android.speech.tts.engine.INSTALL_TTS_DATA 和 android.speech.tts.engine.GET_SAMPLE_TEXT intent，并借助一项 activity 为这些 intent 提供执行方式（如此处的 SDK 中所述）。

Android 支持互动式屏保（之前称为 Dream）。当接通电源的设备处于闲置状态或放在桌面基座中时，屏保让用户能够与应用互动。设备实现：

  • 应支持屏保，并且应能够响应 android.settings.DREAM_SETTINGS intent 为用户提供用于配置屏保的设置选项。

新要求开始

如果设备实现报告 android.hardware.nfc.uicc 或 android.hardware.nfc.ese，则：

新要求结束

3.2.4. 辅助/多屏幕上的 activity

如果设备实现允许在多个屏幕上启动常规 Android activity，则：

  • [C-1-1] 必须设置 android.software.activities_on_secondary_displays 功能标志。
  • [C-1-2] 必须保证 API 兼容性与在主要屏幕上运行的 activity 类似。
  • [C-1-3] 如果某个 activity 在启动新的 activity 时没有通过 ActivityOptions.setLaunchDisplayId() API 指定目标屏幕，则必须在前者所在的屏幕上启动后者。
  • [C-1-4] 当带有 Display.FLAG_PRIVATE 标志的显示屏被移除后，必须销毁所有 activity。
  • [C-1-5] 当使用安全锁定屏幕锁定设备时，必须安全地隐藏所有屏幕上的内容，除非应用选择使用 Activity#setShowWhenLocked() API 将内容显示在锁定屏幕上层。
  • 如果 activity 是在辅助显示屏上启动的，则应具有与该屏幕对应的 android.content.res.Configuration，以便能够显示内容、正确操作以及保持兼容性。

如果设备实现允许在辅助显示屏上启动常规 Android activity，并且辅助显示屏具有 android.view.Display.FLAG_PRIVATE 标志，则：

  • [C-3-1] 只有该屏幕的所有者、系统以及已经存在于该屏幕上的 activity 能够在该屏幕上启动 activity。每个人都可以在具有 android.view.Display.FLAG_PUBLIC 标志的显示屏上启动 activity。

3.3. 原生 API 兼容性

实现原生代码兼容性是一项颇具挑战性的任务。因此，对于设备实现者：

  • [C-SR-1] 强烈建议使用上游 Android 开源项目中的下列库的实现。

3.3.1. 应用二进制接口

受管理 Dalvik 字节码可以调用应用 .apk 文件中提供的原生代码，以便作为针对相应设备硬件架构编译的 ELF .so 文件。由于原生代码高度依赖底层处理器技术，因此 Android 在 Android NDK 中定义了一些应用二进制接口 (ABI)。

设备实现：

  • [C-0-1] 必须与一个或多个已定义的 Android NDK ABI 兼容。
  • [C-0-2] 必须支持在受管理环境中运行的代码使用标准 Java 原生接口 (JNI) 语义调用原生代码。
  • [C-0-3] 必须与以下列表中每个必需的库保持源代码兼容（即标头兼容）和二进制兼容（适用于 ABI）。
  • [C-0-5] 必须通过 android.os.Build.SUPPORTED_ABIS、android.os.Build.SUPPORTED_32_BIT_ABIS 和 android.os.Build.SUPPORTED_64_BIT_ABIS 参数准确报告设备支持的原生应用二进制接口 (ABI)，其中每个参数报告的都是一个以英文逗号分隔的 ABI 列表，列表中的条目按偏好程度从高到低排序。

  • [C-0-6] 必须（通过上述参数）报告以下 ABI 列表的子集，不得报告列表中没有的 ABI。

  • [C-0-7] 必须使以下所有提供原生 API 的库可供包含原生代码的应用使用：

    • libaaudio.so（AAudio 原生音频支持）
    • libamidi.so（原生 MIDI 支持，如果如第 5.9 节中所述来声明 android.software.midi 功能）
    • libandroid.so（原生 Android activity 支持）
    • libc（C 库）
    • libcamera2ndk.so
    • libdl（动态链接器）
    • libEGL.so（原生 OpenGL Surface 管理）
    • libGLESv1_CM.so (OpenGL ES 1.x)
    • libGLESv2.so (OpenGL ES 2.0)
    • libGLESv3.so (OpenGL ES 3.x)
    • libicui18n.so
    • libicuuc.so
    • libjnigraphics.so
    • liblog（Android 日志记录）
    • libmediandk.so（原生媒体 API 支持）
    • libm（数学库）
    • libneuralnetworks.so (Neural Networks API)
    • libOpenMAXAL.s（OpenMAX AL 1.0.1 支持）
    • libOpenSLES.so（OpenSL ES 1.0.1 音频支持）
    • libRS.so
    • libstdc++（至少必须支持 C++ 中的这个库）
    • libvulkan.so (Vulkan)
    • libz（Zlib 压缩）
    • JNI 接口

  • [C-0-8] 不得添加或移除上述原生库的公共函数。

  • [C-0-9] 必须在 /vendor/etc/public.libraries.txt 中列出直接提供给第三方应用使用的其他非 AOSP 库。

  • [C-0-10] 在 AOSP 中作为系统库实现和提供的任何其他原生库均为保留库，不得将其提供给目标 API 级别为 24 或更高级别的第三方应用使用。

  • [C-0-11] 必须通过 libGLESv3.so 库导出所有 OpenGL ES 3.1 和 Android Extension Pack 函数符号（具体定义请参见 NDK）。请注意，所有这些符号都必须存在。第 7.1.4.1 节中更详细地介绍了关于何时需要完整实现每个对应函数方面的要求。

  • [C-0-12] 必须通过 libvulkan.so 库导出核心 Vulkan 1.0Vulkan 1.1 函数的函数符号以及 VK_KHR_surface、VK_KHR_android_surface、VK_KHR_swapchain、VK_KHR_maintenance1 和 VK_KHR_get_physical_device_properties2 扩展。请注意，所有这些符号都必须存在。第 7.1.4.2 节更详细地介绍了关于何时需要完整实现每个对应函数方面的要求。

  • 应使用上游 Android 开源项目中的源代码和头文件进行构建。

请注意，未来版本的 Android 可能会支持更多 ABI。

3.3.2. 32 位 ARM 原生代码兼容性

如果设备实现报告支持 armeabi ABI，则：

  • [C-3-1] 还必须支持 armeabi-v7a 并报告其支持情况，因为 armeabi 仅用于向后兼容旧版应用。

如果设备实现报告支持 armeabi-v7a ABI，对于使用此 ABI 的应用：

  • [C-2-1] 必须在 /proc/cpuinfo 中添加以下行，且不应更改同一设备上的值，即使由其他 ABI 读取时也是如此。

    • Features:，后跟设备支持的所有可选 ARMv7 CPU 功能的列表。
    • CPU architecture:，后跟一个整数，用于描述设备支持的最高 ARM 架构（例如，对于 ARMv8 设备，该整数为“8”）。

  • [C-2-2] 必须始终使以下操作可执行，即使在 ARMv8 架构上实现 ABI（通过原生 CPU 支持或软件模拟）也是如此：

    • SWP 和 SWPB 指令。
    • CP15ISB、CP15DSB 和 CP15DMB 屏障操作。

  • [C-2-3] 必须支持高级 SIMD（也称为 NEON）扩展。

3.4. Web 兼容性

3.4.1. WebView 兼容性

如果设备实现提供 android.webkit.Webview API 的完整实现，则：

  • [C-1-1] 必须报告 android.software.webview。
  • [C-1-2] 必须使用 Android 14 分支上的上游 Android 开源项目中的 Chromium 项目 build 来实现 android.webkit.WebView API。

  • [C-1-3] WebView 报告的用户代理字符串必须采用以下格式：

    Mozilla/5.0 (Linux; Android $(VERSION); [$(MODEL)] [Build/$(BUILD)]; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36

    • $(VERSION) 字符串的值必须与 android.os.Build.VERSION.RELEASE 的值相同。
    • $(MODEL) 字符串可以为空，但如果不为空，则其值必须与 android.os.Build.MODEL 的值相同。
    • “Build/$(BUILD)”可以省略，但如果存在，$(BUILD) 字符串的值必须与 android.os.Build.ID 的值相同。
    • $(CHROMIUM_VER) 字符串的值必须是上游 Android 开源项目中的 Chromium 的版本。
    • 设备实现可以在用户代理字符串中省略 Mobile。

  • WebView 组件应支持尽可能多的 HTML5 功能；如果它支持此类功能，则应符合 HTML5 规范。

  • [C-1-4] 必须在与实例化 WebView 的应用不同的进程中渲染提供的内容或远程网址内容。具体而言，单独的渲染程序进程必须保持更低的权限、作为单独的用户 ID 运行、无法访问应用的数据目录、无法直接访问网络且只能通过 Binder 访问要求最低的系统服务。WebView 的 AOSP 实现符合此要求。

请注意，如果设备实现为 32 位或声明功能标志 android.hardware.ram.low，则不受 C-1-3 限制。

3.4.2. 浏览器兼容性

如果设备实现包含独立的浏览器应用，以供用户进行一般的网页浏览，则：

  • [C-1-1] 必须支持以下与 HTML5 相关联的每个 API：
  • [C-1-2] 必须支持 HTML5/W3C webstorage API，并且应支持 HTML5/W3C IndexedDB API。请注意，随着网页开发标准制定机构逐渐转变为青睐 IndexedDB 胜过 webstorage，IndexedDB 预计在未来版本的 Android 中会成为必需的组件。
  • 可以在独立的浏览器应用中附带自定义用户代理字符串。
  • 应在独立的浏览器应用（无论是基于上游 WebKit 浏览器应用，还是基于第三方替代应用）中支持尽可能多的 HTML5 功能。

不过，如果设备实现不包含独立的浏览器应用，则：

  • [C-2-1] 必须仍支持第 3.2.3.1 节中所述的公共 intent 模式。

3.5. API 行为兼容性

设备实现：

  • [C-0-9] 必须确保将 API 行为兼容性应用于所有安装式应用，除非应用受到限制（如第 3.5.1 节中所述）。
  • [C-0-10] 不得实现仅为设备实现者所选的应用确保 API 行为兼容性的许可名单方法。

每种 API（受管理 API、软 API、原生 API 和 Web API）的行为都必须与上游 Android 开源项目的首选实现一致。兼容性的一些具体方面如下：

  • [C-0-1] 设备不得更改标准 intent 的行为或语义。
  • [C-0-2] 设备不得更改特定类型的系统组件（例如 Service、activity、ContentProvider 等）的生命周期或生命周期语义。
  • [C-0-3] 设备不得更改标准权限的语义。
  • 设备不得更改对后台应用实施的限制。 更具体地说，对于后台应用：
    • [C-0-4] 设备必须停止执行应用为接收 GnssMeasurement 和 GnssNavigationMessage 的输出而注册的回调。
    • [C-0-5] 设备必须通过 LocationManager API 类或 WifiManager.startScan() 方法限制为应用提供更新的频率。
    • [C-0-6] 如果应用的目标 API 级别为 25 或更高，则设备不得允许在应用清单中注册广播接收器来接收标准 Android intent 的隐式广播，除非广播 intent 要求 "signature" 或 "signatureOrSystem" protectionLevel 权限，或位于豁免列表中。
    • [C-0-7] 如果应用以 API 级别 25 或更高级别为目标，设备必须停止应用的后台服务，就像应用已调用这些服务的 stopSelf() 方法一样，除非应用被列入临时许可名单中，以便处理用户可见的某项任务。
    • [C-0-8] 如果应用以 API 级别 25 或更高级别为目标，设备必须解除应用的唤醒锁定。
  • [C-0-11] 设备必须按指定顺序且使用指定名称（由 Provider.getName() 返回）和类将以下安全提供程序作为 Security.getProviders() 方法的前 7 个数组值返回，除非应用已通过 insertProviderAt() 或 removeProvider() 修改了列表。设备可以在以下指定的提供程序列表之后返回其他提供程序。
    1. AndroidNSSP - android.security.net.config.NetworkSecurityConfigProvider
    2. AndroidOpenSSL - com.android.org.conscrypt.OpenSSLProvider
    3. CertPathProvider - sun.security.provider.CertPathProvider
    4. AndroidKeyStoreBCWorkaround - android.security.keystore.AndroidKeyStoreBCWorkaroundProvider
    5. BC - com.android.org.bouncycastle.jce.provider.BouncyCastleProvider
    6. HarmonyJSSE - com.android.org.conscrypt.JSSEProvider
    7. AndroidKeyStore - android.security.keystore.AndroidKeyStoreProvider

上述列表并不详尽。兼容性测试套件 (CTS) 用于测试平台重要部分的行为兼容性，而不是测试整个平台的行为兼容性。实现者需负责确保与 Android 开源项目保持行为兼容。为此，设备实现者应尽可能使用通过 Android 开源项目获得的源代码，而不是重新实现系统的重要部分。

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-10] 必须提供清楚明确的公开文档或网站，用于说明专有限制的应用方式。必须可从 Android SDK 文档链接到此文档或网站；并且必须包含：

    • 专有限制的触发条件。
    • 从何方面及以何方式限制应用。
    • 如何使应用免受此类限制。
    • 如果相应限制支持豁免用户可安装的应用，应用可以如何申请豁免受到这些专有限制。

如果某个应用已预装在设备上，并且用户已有超过 30 天时间未明确使用该应用，则豁免遵守 [C-1-3]、[C-1-5]。

如果设备实现扩展 AOSP 中实现的应用限制，则：

  • [C-2-1] 必须遵循本文档中所述的实现方式。

3.5.2. 应用休眠

如果设备实现包含 AOSP 中包含的应用休眠或扩展 AOSP 中包含的功能，则：

  • [C-1-1] 必须满足第 3.5.1 节（[C-1-6] 和 [C-1-3] 除外）中的所有要求。
  • [C-1-2] 必须仅在有证据证明用户在一段时间内未使用该应用时，才能对该用户的应用应用限制。强烈建议将此持续时间设置为一个月或更长时间。必须通过 UsageStats#getLastTimeVisible() API 的显式用户互动或任何会导致应用退出强行停止状态的内容（包括服务绑定、content provider 绑定和显式广播等）定义使用情况，这将由新的 API UsageStats#getLastTimeAnyComponentUsed() 进行跟踪。
  • [C-1-3] 必须仅在有证据证明任何用户在一段时间内未使用该软件包时，才能应用影响所有设备用户的限制。强烈建议将此持续时间设置为一个月或更长时间。
  • [C-1-4] 不得呈现无法响应 activity intent、服务绑定、内容提供程序请求或显式广播的应用。

AOSP 中的应用休眠满足上述要求。

3.6. API 命名空间

Android 遵循 Java 编程语言定义的软件包和类命名空间惯例。为了确保与第三方应用兼容，设备实现者不得对以下软件包命名空间进行任何禁止的修改（见下文）：

  • java.*
  • javax.*
  • sun.*
  • android.*
  • androidx.*
  • com.android.*

也就是说，他们：

  • [C-0-1] 不得通过更改任何方法或类签名或者通过移除类或类字段的方式，修改 Android 平台上公开提供的 API。
  • [C-0-2] 不得向上述命名空间中的 API 添加任何已公开元素（例如类或接口，或现有类或接口的字段或方法）、测试 API 或系统 API。“已公开元素”是指在上游 Android 源代码中使用时不带“@hide”标记的任何构造。

设备实现者可以修改 API 的底层实现，但此类修改：

  • [C-0-3] 不得影响任何已公开 API 的既定行为和 Java 语言签名。
  • [C-0-4] 不得向开发者通告或以其他方式向开发者公开这些修改。

不过，设备实现者可以在标准 Android 命名空间以外添加自定义 API，但这些自定义 API：

  • [C-0-5] 不得位于归其他组织所有或提及其他组织的命名空间内。例如，设备实现者不得向 com.google.* 或类似命名空间添加 API：只有 Google 可以在此类命名空间内添加 API。同样，Google 也不得向其他公司的命名空间添加 API。
  • [C-0-6] 必须打包到 Android 共享库中，以便只有明确使用它们的应用（通过 <uses-library> 机制）会受到此类 API 内存用量增加的影响。

设备实现者可以在 NDK API 以外添加原生语言的自定义 API，但自定义 API：

  • [C-1-1] 不得位于 NDK 库或由此处所述的其他组织拥有的库中。

如果设备实现者提议改善上述某个软件包命名空间（例如向现有 API 添加实用的新功能，或添加新的 API），实现者应访问 source.android.com，并按照该网站上的信息开始贡献更改和代码。

请注意，上述限制对应于 Java 编程语言中命名 API 的标准惯例；本节只是为了强调这些惯例，并通过将其纳入本兼容性定义来使其具有约束力。

3.7. 运行时兼容性

设备实现：

  • [C-0-1] 必须支持完整的 Dalvik 可执行文件 (DEX) 格式以及 Dalvik 字节码规范和语义。

  • [C-0-2] 必须将 Dalvik 运行时配置为根据上游 Android 平台来分配内存，如下表所示。（有关屏幕尺寸和屏幕密度定义，请参阅第 7.1.1 节。）

  • 应使用 Android 运行时 (ART)、Dalvik 可执行文件格式的参考上游实现，以及该参考实现的软件包管理系统。

  • 应在执行和定位架构的多种模式下运行模糊测试，以确保运行时的稳定性。请参阅 Android 开源项目网站上的 JFuzz 和 DexFuzz。

请注意，下面指定的内存值被视为最小值，设备实现可以为每个应用分配更多内存。

屏幕布局 屏幕密度 最小应用内存
Android Watch 120 dpi (ldpi) 32 MB
140 dpi (140dpi)
160 dpi (mdpi)
180 dpi (180dpi)
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi) 36 MB
240 dpi (hdpi)
280 dpi (280dpi)
320 dpi (xhdpi) 48 MB
360 dpi (360dpi)
400 dpi (400dpi) 56 MB
420 dpi (420dpi) 64 MB
480 dpi (xxhdpi) 88 MB
560 dpi (560dpi) 112 MB
640 dpi (xxxhdpi) 154 MB
小/普通 120 dpi (ldpi) 32 MB
140 dpi (140dpi)
160 dpi (mdpi)
180 dpi (180dpi) 48 MB
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi)
240 dpi (hdpi)
280 dpi (280dpi)
320 dpi (xhdpi) 80 MB
360 dpi (360dpi)
400 dpi (400dpi) 96 MB
420 dpi (420dpi) 112 MB
480 dpi (xxhdpi) 128MB
560 dpi (560dpi) 192MB
640 dpi (xxxhdpi) 256 MB
大 120 dpi (ldpi) 32 MB
140 dpi (140dpi) 48 MB
160 dpi (mdpi)
180 dpi (180dpi) 80 MB
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi)
240 dpi (hdpi)
280 dpi (280dpi) 96MB
320 dpi (xhdpi) 128 MB
360 dpi (360dpi) 160 MB
400 dpi (400dpi) 192MB
420 dpi (420dpi) 228 MB
480 dpi (xxhdpi) 256 MB
560 dpi (560dpi) 384MB
640 dpi (xxxhdpi) 512MB
特大 120 dpi (ldpi) 48 MB
140 dpi (140dpi) 80 MB
160 dpi (mdpi)
180 dpi (180dpi) 96 MB
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi)
240 dpi (hdpi)
280 dpi (280dpi) 144MB
320 dpi (xhdpi) 192MB
360 dpi (360dpi) 240 MB
400 dpi (400dpi) 288 MB
420 dpi (420dpi) 336 MB
480 dpi (xxhdpi) 384MB
560 dpi (560dpi) 576 MB
640 dpi (xxxhdpi) 768 MB

3.8. 界面兼容性

3.8.1. 启动器（主屏幕）

Android 包含一个启动器应用（主屏幕），并且支持第三方应用更换设备启动器（主屏幕）。

如果设备实现允许第三方应用更换设备主屏幕，则：

  • [C-1-1] 必须声明平台功能 android.software.home_screen。
  • [C-1-2] 在第三方应用使用 <adaptive-icon> 标记提供其图标，并且系统调用用于检索图标的 PackageManager 方法的情况下，必须返回 AdaptiveIconDrawable 对象。

如果设备实现包含支持应用内固定快捷方式的默认启动器，则：

反之，如果设备实现不支持应用内固定快捷方式，则：

如果设备实现已实现一个可让用户快速访问第三方应用通过 ShortcutManager API 提供的其他快捷方式的默认启动器，则：

  • [C-4-1] 必须支持载述的所有快捷方式功能（例如静态和动态快捷方式、固定快捷方式），并完整实现 ShortcutManager API 类的 API。

如果设备实现包含会为应用图标显示标记的默认启动器应用，则：

  • [C-5-1] 必须遵从 NotificationChannel.setShowBadge() API 方法。 也就是说，如果相应值被设置为 true，则显示与应用图标关联的可见标记；如果应用的所有通知渠道均将相应值设置为 false，则不显示任何应用图标标记方案。
  • 如果第三方应用指明通过使用专有 API 支持专有标记方案，则可以使用专有标记方案替换应用图标标记，但应使用通过 SDK 中所述的通知标记 API（例如 Notification.Builder.setNumber() 和 Notification.Builder.setBadgeIconType() API）提供的资源和值。

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

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

3.8.2. widget

Android 定义了一种组件类型以及对应的 API 和生命周期，以便应用向最终用户提供 AppWidget，因此 Android 支持第三方应用 widget。

如果设备实现支持第三方应用 widget，则：

  • [C-1-1] 必须声明支持平台功能 android.software.app_widgets。

  • [C-1-2] 必须包含对 AppWidget 的内置支持，并提供用于添加、配置、查看和移除 AppWidget 的界面方式

  • [C-1-3] 必须能够呈现标准网格大小为 4 x 4 的 widget。有关详细信息，请参阅 Android SDK 文档中的应用 widget 设计准则。

  • 可以支持位于锁定屏幕上的应用 widget。

如果设备实现支持第三方应用 widget 和应用内固定快捷方式，则：

3.8.3. 通知

Android 包含 Notification 和 NotificationManager API，以便第三方应用开发者使用设备的硬件组件（例如声音、振动和指示灯组件）和软件功能（例如通知栏、系统栏）向用户通知重要事件以及吸引用户的注意力。

3.8.3.1. 通知的呈现方式

如果设备实现允许第三方应用向用户通知重要事件，则：

  • [C-1-1] 必须支持使用硬件功能的通知（如 SDK 文档中所述），并尽可能提供相关的设备实现硬件。例如，如果设备实现包含振动器，必须正确实现振动 API。如果设备实现缺少硬件，必须将对应 API 实现为空操作。第 7 节中对此行为进行了进一步的详细说明。
  • [C-1-2] 必须正确呈现 API 或状态栏/系统栏图标样式指南中提供的所有资源（图标、动画文件等），不过，它们可以针对通知提供替代用户体验，而不使用参考 Android 开源实现所提供的体验。
  • [C-1-3] 必须遵从并正确实现为 API 描述的行为，以便更新、移除通知以及对通知进行分组。
  • [C-1-4] 必须提供 SDK 中所述的 NotificationChannel API 的完整行为。
  • [C-1-5] 必须提供一种方式，让用户能够按每个渠道和应用软件包级别屏蔽和修改特定第三方应用的通知。
  • [C-1-6] 还必须提供一种方式，让用户能够查看已删除的通知渠道。

  • [C-1-7] 必须在无需用户额外互动的情况下正确呈现通过 Notification.MessagingStyle 提供的所有资源（图片、贴纸和图标等）以及通知文本。例如，必须显示所有资源，包括通过 setGroupConversation 设置的群组对话中通过 android.app.Person 提供的图标。

  • [C-SR-1] 强烈建议提供一种方式，让用户能够控制向已获得通知监听器权限的应用公开的通知。必须达到一定的精细度，确保用户能够针对每个此类通知监听器控制与该监听器桥接的通知类型。类型必须包含“对话通知”“提醒通知”“静默通知”和“持续显示的重要通知”。

  • [C-SR-2] 强烈建议提供一种方式，让用户能够指定要在通知任何特定通知监听器时排除的应用。

  • [C-SR-3] 强烈建议自动呈现一种方式，让用户能够在多次忽略特定第三方应用的通知后按每个渠道和应用软件包级别屏蔽该通知。

  • 应支持内容丰富的通知。

  • 应以浮动通知的形式显示某些优先级较高的通知。

  • 应具有可让用户暂停通知的方式。

  • 只能管理是否以及何时显示第三方应用针对重要事件向用户发出的通知，以避免安全问题（例如分散驾驶员的注意力）。

Android 11 引入了对对话通知的支持，此类通知使用 MessagingStyle 并提供已发布的 People 快捷方式 ID。

设备实现：

如果设备实现支持 conversation notifications 并且应用为 bubbles 提供了必需的数据，则：

  • [C-SR-5] 强烈建议将此对话显示为对话泡。 AOSP 实现满足默认系统界面、设置和启动器的这些要求。

如果设备实现支持内容丰富的通知，则：

  • [C-2-1] 对于呈现的资源元素，必须使用通过 Notification.Style API 类及其子类提供的确切资源。
  • 应呈现 Notification.Style API 类及其子类中定义的每个资源元素（例如图标、标题和摘要文本）。

浮动通知是一种与用户所在 Surface 分开，单独向用户呈现的通知。如果设备实现支持浮动通知，则：

  • [C-3-1] 在呈现浮动通知时，必须使用浮动通知视图和资源（如 Notification.Builder API 类中所述）。
  • [C-3-2] 必须在无需用户额外互动的情况下显示通过 Notification.Builder.addAction() 提供的操作以及通知内容（如 SDK 中所述）。
3.8.3.2. 通知监听器服务

Android 包含 NotificationListenerService API，任何通知一经发布或更新，此类 API 便可让应用（用户明确启用后）收到其副本。

设备实现：

  • [C-0-1] 必须正确、及时地将通知完整地更新到所有已安装且用户已启用的此类监听器服务，包括附加到通知对象的所有元数据。
  • [C-0-2] 必须遵从 snoozeNotification() API 调用，并在 API 调用中设置的暂停时长过后关闭通知并执行回调。

如果设备实现具有可让用户暂停通知的方式，则：

  • [C-1-1] 必须通过标准 API（例如 NotificationListenerService.getSnoozedNotifications()）正确反映已暂停通知状态。
  • [C-1-2] 必须使此方式可用于暂停每个已安装的第三方应用发出的通知，除非通知来自常驻/前台服务。
3.8.3.3. DND（勿扰）/优先模式

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

  • [C-1-1] 当设备实现为用户提供了用于授权或拒绝第三方应用访问 DND 政策配置的方式时，必须随同用户创建的规则和预定义的规则一起显示应用创建的自动 DND 规则。
  • [C-1-3] 必须遵从随同 NotificationManager.Policy 传递的 suppressedVisualEffects 值；如果应用已设置 SUPPRESSED_EFFECT_SCREEN_OFF 或 SUPPRESSED_EFFECT_SCREEN_ON 标志，应向用户指明 DND 设置菜单中不会显现视觉效果。

3.8.4. 辅助 API

Android 包含一些辅助 API，以便应用选择与设备上的辅助程序分享多少关于当前上下文的信息。

如果设备实现支持辅助操作，则：

  • [C-2-1] 当分享上下文时，必须通过以下方式之一向最终用户清楚地指明这一点：
    • 每当辅助应用访问上下文时，都在屏幕边缘显示白光，并且其持续时间和亮度达到或超过 Android 开源项目实现的持续时间和亮度。
    • 对于预安装的辅助应用，提供距默认语音输入和辅助应用设置菜单不超过两个导航步骤的用户可见内容，并且仅在用户通过启动指令或辅助导航键输入显式调用辅助应用的情况下才分享上下文。
  • [C-2-2] 用于启动辅助应用的指定互动（如第 7.2.3 节中所述）必须启动用户选择的辅助应用（也就是实现 VoiceInteractionService 的应用）或负责处理 ACTION_ASSIST intent 的 activity。

3.8.5. 提醒和消息框

应用可以使用 Toast API 向最终用户显示简短的非模态字符串（这些字符串会在短暂显示后消失），并使用 TYPE_APPLICATION_OVERLAY 窗口类型 API 使提醒窗口以叠加层的形式显示在其他应用的上方。

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

  • [C-1-1] 必须提供一种方式，让用户能够阻止应用显示使用 TYPE_APPLICATION_OVERLAY 的提醒窗口。AOSP 实现通过在通知栏中提供相应控件来满足此要求。

  • [C-1-2] 必须遵从 Toast API，并以某种非常显眼的方式向最终用户显示来自应用的消息框。

3.8.6. 主题背景

Android 提供“主题”这一机制，以供应用在整个 activity 或应用中应用样式。

Android 包含“Holo”和“Material”主题系列（一组已定义的样式），如果应用开发者希望与 Android SDK 定义的 Holo 主题外观和风格保持一致，可以使用它们。

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

  • [C-1-1] 不得更改任何可供应用使用的 Holo 主题背景属性。
  • [C-1-2] 必须支持“Material”主题系列，并且不得更改任何可供应用使用的 Material 主题属性或其资源。

  • [C-1-3] 对于 Roboto 支持的语言，必须将“sans-serif”字体系列设置为 Roboto 版本 2.x；或者，对于 Roboto 支持的语言，提供一种用户功能，让用户能够将用于“sans-serif”字体系列的字体更改为 Roboto 版本 2.x。

  • [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 和 MONOCHROMATIC。

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

  • [C-1-6] CAM16 色度值不得小于 5。

    • 应通过 com.android.systemui.monet.ColorScheme#getSeedColors 从壁纸衍生，后者提供多种有效的源颜色，您可选择其中一种。

    • 如果提供的颜色都不符合上述源颜色要求，则应使用值 0xFF1B6EF3。

Android 还包含一个“Device Default”主题系列（一组定义的样式），如果应用开发者想要与设备实现者定义的设备主题外观和风格保持一致，可以使用它们。

Android 支持带有半透明系统栏的变体主题，以便应用开发者将其应用内容填充到状态栏和导航栏后面的区域。为了在采用此配置时实现一致的开发者体验，请务必在不同的设备实现之间保持一致的状态栏图标样式。

如果设备实现包含系统状态栏，则：

  • [C-2-1] 必须使用白色来显示系统状态图标（例如信号强度和电池电量）以及系统发出的通知，除非相应图标用于指明有问题状态，或者应用使用 WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS 标志请求使用浅色状态栏。
  • [C-2-2] 当应用请求使用浅色状态栏时，Android 设备实现必须将系统状态图标的颜色更改为黑色（有关详细信息，请参阅 R.style）。

3.8.7. 动态壁纸

Android 定义了一种组件类型以及对应的 API 和生命周期，以便应用向最终用户提供一个或多个动态壁纸。动态壁纸是具备有限输入功能且作为壁纸显示在其他应用之后的动画、图案或类似图片。

如果硬件能够在不限制功能且不会对其他应用造成负面影响的情况下，以合理的帧速率运行所有动态壁纸，则会被视为能够可靠地运行动态壁纸。如果硬件中的限制导致壁纸和/或应用崩溃、无法正常运行、占用过多 CPU/消耗过多电池电量，或者运行时的帧速率低得令人无法接受，相应硬件会被视为无法运行动态壁纸。例如，有些动态壁纸可能会利用 OpenGL 2.0 或 3.x 上下文来呈现其内容。 动态壁纸将无法在不支持多个 OpenGL 上下文的硬件上可靠地运行，因为使用 OpenGL 上下文的动态壁纸可能会与其他同样使用 OpenGL 上下文的应用发生冲突。

  • 如果设备实现能够可靠地运行动态壁纸（如上所述），应实现动态壁纸。

如果设备实现已实现动态壁纸，则：

  • [C-1-1] 必须报告平台功能标志 android.software.live_wallpaper。

3.8.8. activity 切换

上游 Android 源代码包含概览屏幕，该屏幕是一个系统级界面，可用于切换任务，以及使用缩略图（对应于用户上次离开应用时应用的图形状态）显示用户最近访问的 activity 和任务。

如果设备实现包含“最近用过”功能导航键（第 7.2.3 节中对此进行了详细说明），则可以更改该界面。

如果设备实现包含“最近用过”功能导航键（第 7.2.3 节中对此进行了详细说明），并且要更改该界面，则：

  • [C-1-1] 必须支持显示至少 7 个 activity。
  • 一次应至少显示 4 个 activity 的名称。

  • [C-1-2] 必须实现屏幕固定行为，并向用户提供用于开启/关闭该功能的设置菜单。

  • 应在“最近用过”中显示亮显颜色、图标和屏幕标题。
  • 应显示关闭选项 (x)，但可以延迟到用户与屏幕互动之后显示。
  • 应实现一个可让用户轻松切换到前一个 activity 的快捷方式。
  • 当用户点按两次“最近用过”功能键时，应触发在最近用过的两个应用之间进行快速切换。
  • 当用户长按“最近用过”功能键时，应触发分屏多窗口模式（如果支持的话）。
  • 可以将“最近用过”的关联项显示为一组（它们会一起移动）。
  • [C-SR-1] 强烈建议为概览屏幕使用上游 Android 界面（或类似的基于缩略图的界面）。

3.8.9. 输入管理

Android 支持输入管理，并且支持第三方输入法。

如果设备实现允许用户在设备上使用第三方输入法，则：

  • [C-1-1] 必须声明平台功能 android.software.input_methods，并支持 IME API（如 Android SDK 文档中所定义）。

3.8.10. 锁定屏幕媒体控件

Remote Control Client API 从 Android 5.0 开始便被废弃了，取而代之的是可让媒体应用与锁定屏幕上显示的播放控件相集成的媒体通知模板。

3.8.11. 屏保（之前称为 Dreams）

请参阅第 3.2.3.5 节，了解用于配置屏保的设置 intent。

3.8.12. 位置信息

如果设备实现包含能够提供位置坐标的硬件传感器（例如 GPS），则

3.8.13. Unicode 和字体

Android 支持 Unicode 10.0 中定义的表情符号。

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

  • [C-1-1] 必须能够以彩色符号形式呈现这些表情符号。
  • [C-1-2] 必须支持：
    • 对于设备上的可用语言，支持具有以下各种粗细的 Roboto 2 字体：sans-serif-thin、sans-serif-light、sans-serif-medium、sans-serif-black、sans-serif-condensed、sans-serif-condensed-light。
    • Unicode 7.0 中涵盖的所有拉丁语、希腊语和西里尔语字母（包括拉丁语扩展 A、B、C 和 D 系列），以及 Unicode 7.0 的货币符号部分中的所有字形。
  • [C-1-3] 不得移除或修改系统映像中的 NotoColorEmoji.tff。 （可以添加新的表情符号字体以替换 NotoColorEmoji.tff 中的表情符号）
  • 应支持 Unicode 技术报告 #51 中指定的肤色和各种家庭表情符号。

如果设备实现包含 IME，则：

  • 应为用户提供一种可输入这些表情符号的输入法。

Android 支持呈现缅甸字体。缅甸具有多种用于呈现缅甸语言的非 Unicode 兼容字体，通常称为“Zawgyi”。

如果设备实现支持缅甸语，则：

  • [C-2-1] 必须将 Unicode 兼容字体作为呈现文字的默认字体；不得将非 Unicode 兼容字体设为默认字体，除非用户在语言选择器中选择了该字体。
  • [C-2-2] 如果设备支持非 Unicode 兼容字体，则必须支持一种 Unicode 兼容字体和一种非 Unicode 兼容字体。非 Unicode 兼容字体不得移除或覆盖 Unicode 兼容字体。
  • [C-2-3] 除非指定带有脚本代码 Qaag（例如 my-Qaag）的语言代码，否则必须使用非 Unicode 兼容字体呈现文字。不得使用其他任何 ISO 语言代码或区域代码（无论是已分配、未分配还是预留的代码）为缅甸语指定非 Unicode 兼容字体。应用开发者和网页作者可以将 my-Qaag 指定为特定的语言代码，方法与指定其他任何语言代码一样。

3.8.14. 多窗口模式

如果设备实现能够同时显示多个 activity，则：

  • [C-1-1] 必须按照 Android SDK 多窗口模式支持文档中所述的应用行为和 API 实现此类多窗口模式，并满足以下要求：
  • [C-1-2] 必须遵从应用在 AndroidManifest.xml 文件中设置的 android:resizeableActivity（如本 SDK 中所述）。
  • [C-1-3] 如果屏幕高度和宽度均小于 440 dp，不得提供分屏或自由窗口模式。
  • [C-1-4] 在除画中画以外的多窗口模式中，不得将 activity 的大小调整为小于 220 dp。
  • 屏幕尺寸为 xlarge 的设备实现应支持自由窗口模式。

如果设备实现支持多窗口模式和分屏模式，则：

  • [C-2-2] 如果启动器应用是获得焦点的窗口，必须剪裁处于分屏多窗口模式的停靠 activity，但应显示它的部分内容。
  • [C-2-3] 必须遵从第三方启动器应用声明的 AndroidManifestLayout_minWidth 和 AndroidManifestLayout_minHeight 值，并且在显示停靠 activity 的部分内容时不得替换这些值。

如果设备实现支持多窗口模式和画中画多窗口模式，则：

  • [C-3-1] 如果应用符合以下任一条件，则必须在画中画多窗口模式下启动 activity： * 以 API 级别 26 或更高级别为目标，并声明 android:supportsPictureInPicture * 以 API 级别 25 或更低级别为目标，并同时声明 android:resizeableActivity 和 android:supportsPictureInPicture。
  • [C-3-2] 必须在 SystemUI 中公开当前画中画 activity 通过 setActions() API 指定的操作。
  • [C-3-3] 必须支持画中画 activity 通过 setAspectRatio() API 指定的大于等于 1:2.39 且小于等于 2.39:1 的宽高比。
  • [C-3-4] 必须使用 KeyEvent.KEYCODE_WINDOW 控制画中画窗口；如果未实现画中画模式，该键必须可供前台 activity 使用。
  • [C-3-5] 必须提供一种方式，让用户能够阻止应用以画中画模式显示；AOSP 实现通过在通知栏中提供相应控件来满足此要求。

  • [C-3-6] 如果应用未为 AndroidManifestLayout_minWidth 和 AndroidManifestLayout_minHeight 声明任何值，必须为画中画窗口分配以下最小宽度和高度：

    • 如果设备的 Configuration.uiMode 设置为除 UI_MODE_TYPE_TELEVISION 之外的值，必须分配 108 dp 的最小宽度和高度。
    • 如果设备的 Configuration.uiMode 设置为 UI_MODE_TYPE_TELEVISION，必须分配 240 dp 的最小宽度和 135 dp 的最小高度。

3.8.15. 刘海屏

Android 支持刘海屏（如 SDK 文档中所述）。DisplayCutout API 用于定义显示屏边缘上的一块区域；因相应边缘上有刘海区域或曲面区域，这块区域可能无法供应用使用。

如果设备实现包含刘海屏，则：

  • [C-1-5] 如果设备的宽高比为 1.0 (1:1)，就不得包含刘海屏。
  • [C-1-2] 每边的凹口只能有一个。
  • [C-1-3] 必须遵从应用通过 WindowManager.LayoutParams API 设置的刘海屏标志（如 SDK 中所述）。
  • [C-1-4] 必须为 DisplayCutout API 中定义的所有刘海屏指标报告正确的值。

3.8.16. 设备控制器

Android 包含 ControlsProviderService 和 Control API，使第三方应用能够发布设备控制器，以便为用户提供快捷状态和操作。

请参阅第 2_2_3 节，了解设备专属要求。

3.8.17. 剪贴板

设备实现：

  • [C-0-1] 不得在没有明确用户操作（例如按下叠加层中的按钮）的情况下，向任何组件、activity、服务或在任何网络连接中发送剪贴板数据，9.8.6 内容捕获和应用搜索中所述的服务除外。

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

  • [C-1-1] 必须隐去用户可见的预览

AOSP 参考实现满足有关剪贴板的上述要求。

3.9. 设备管理

Android 包含一些可让注重安全的应用在系统级执行设备管理工作的功能，例如通过 Android Device Administration API 强制执行密码政策或执行远程清除。

如果设备实现已实现 Android SDK 文档中定义的所有设备管理政策，则：

  • [C-1-1] 必须声明 android.software.device_admin。
  • [C-1-2] 必须支持设备所有者配置（如第 3.9.1 节和第 3.9.1.1 节中所述）。

3.9.1 设备配置

3.9.1.1 设备所有者配置

如果设备实现声明 android.software.device_admin，则：

  • [C-1-1] 必须支持将 Device Policy Client (DPC) 注册为设备所有者应用，如下所述：
    • 如果设备实现既未配置用户，也未配置用户数据，则：
      • [C-1-5] 如果设备通过功能标志 android.hardware.nfc 声明支持近距离无线通信 (NFC)，并且它收到的 NFC 消息中包含 MIME 类型为 MIME_TYPE_PROVISIONING_NFC 的记录，则必须将 DPC 应用注册为设备所有者应用，或让 DPC 应用能够选择是成为设备所有者应用还是资料所有者应用。
      • [C-1-8] 必须在触发设备所有者配置后发送 ACTION_GET_PROVISIONING_MODE intent，以便 DPC 应用可以选择是成为设备所有者应用还是资料所有者应用（取决于 android.app.extra.PROVISIONING_ALLOWED_PROVISIONING_MODES 的值），除非可以从上下文中确定只有一个有效选项。
      • [C-1-9] 如果在配置期间建立了设备所有者（无论使用何种配置方法），必须向设备所有者应用发送 ACTION_ADMIN_POLICY_COMPLIANCE intent。在设备所有者应用安装完成之前，用户不得在设置向导中继续操作。
    • 如果设备实现有用户或用户数据，则：
      • [C-1-7] 不得再将任何 DPC 应用注册为设备所有者应用。

  • [C-1-2] 必须显示一则适当的披露声明（如 AOSP 中所述），并在将某个应用设为设备所有者应用之前征得最终用户明确同意，除非在最终用户通过屏幕与设备互动前，该设备就已以程序化方式配置为零售演示模式。如果设备实现声明了 android.software.device_admin，但还包含专有的设备管理解决方案，并提供了相应机制来向标准 Android DevicePolicyManager API 识别出的标准“设备所有者”通告在其解决方案中配置为“与设备所有者同等”的应用，则：

  • [C-2-1] 必须部署相应的流程来验证所通告的特定应用属于合法的企业设备管理解决方案，并且已在专有的解决方案中配置为具备与“设备所有者”同等的权利。

  • [C-2-2] 在将 DPC 应用注册为“设备所有者”应用之前，必须先按照 android.app.action.PROVISION_MANAGED_DEVICE 启动的流程显示相同的 AOSP 设备所有者意见征求披露信息。

  • [C-2-3] 不得以硬编码方式编写意见征求机制，也不得阻止使用其他的设备所有者应用。

3.9.1.2 受管理个人资料配置

如果设备实现声明 android.software.managed_users，则：

3.9.2 受管理个人资料支持

如果设备实现声明 android.software.managed_users，则：

  • [C-1-1] 必须通过 android.app.admin.DevicePolicyManager API 支持受管理个人资料。
  • [C-1-2] 必须允许且只允许创建一个受管理个人资料。
  • [C-1-3] 必须使用图标标记（类似于 AOSP 上游工作标记）来表示受管理应用和 widget 以及其他带有标记的界面元素（例如“最近用过”和“通知”）。
  • [C-1-4] 当用户位于受管理资料应用中时，必须显示通知图标（类似于 AOSP 上游工作标记）来指明这一点。
  • [C-1-5] 当设备唤醒 (ACTION_USER_PRESENT) 且前台应用在受管理资料中时，必须显示消息框来指明用户位于受管理资料中。
  • [C-1-6] 如果存在受管理资料，并且该资料已由设备政策控制器启用，则必须在 intent“选择器”中显示可见方式，以便用户将 intent 从受管理资料转发给主要用户，反之亦然。
  • [C-1-7] 如果存在受管理资料，必须针对主要用户和受管理资料提供以下用户可见内容：
    • 分别计算主要用户和受管理资料的耗电量、位置信息、移动流量和存储空间用量。
    • 单独管理安装在主要用户或受管理资料中的 VPN 应用。
    • 单独管理安装在主要用户或受管理资料中的应用。
    • 单独管理主要用户或受管理资料中的账号。
  • [C-1-8] 如果设备政策控制器允许，必须确保预安装的拨号器、通讯录和消息应用可以搜索和查询受管理资料（如果存在）以及主要资料中的来电者信息。
  • [C-1-9] 必须确保满足适用于启用了多用户的设备的所有安全性要求（请参阅第 9.5 节），虽然除了主要用户之外，受管理资料不算作其他用户。

新要求开始

  • [C-1-10] 在使用具有焦点（即用户在所有 activity 中最后一个互动的 activity）且属于工作资料应用的 topActivity 窗口捕获屏幕截图时，必须确保屏幕截图数据保存在工作资料存储空间中。
  • [C-1-11] 在将屏幕截图保存到工作资料时，不得捕获除工作资料应用窗口外的任何其他屏幕内容（系统栏、通知或任何个人资料内容），以确保个人资料数据不会保存在工作资料中。

新要求结束

如果设备实现声明 android.software.managed_users 和 android.software.secure_lock_screen，则：

  • [C-2-1] 必须支持指定满足以下要求的单独锁定屏幕，以便仅向在受管理资料中运行的应用授予访问权限。
  • 当受管理资料中的联系人信息显示在预安装的通话记录、通话界面、进行中和未接来电提醒、通讯录和消息应用中时，它们应带有用于表示受管理资料应用的相同标记。

3.9.3 受管理用户支持

如果设备实现声明 android.software.managed_users，则：

  • [C-1-1] 必须提供一种方式，让用户能够在 isLogoutEnabled 返回 true 时在多用户会话中退出当前用户并切换回主要用户。这种方式必须让用户能够在锁屏的情况下（无需解锁设备）访问。

如果设备实现声明 android.software.device_admin 并提供一种方式，让用户能够在设备上添加其他次要用户，则：

  • [C-SR-1] 在允许将账号添加到新的次要用户中之前，强烈建议按照 android.app.action.PROVISION_MANAGED_DEVICE 启动的流程显示相同的 AOSP 设备所有者意见征求披露信息，以便用户了解设备处于受管理状态。

3.9.4 设备政策管理角色要求

如果设备实现报告 android.software.device_admin 或 android.software.managed_users，则：

  • [C-1-1] 必须支持第 9.1 节中定义的设备政策管理角色。可以通过以下方法来定义持有设备政策管理角色的应用：将 config_devicePolicyManagement 设为软件包名称。除非应用是预加载的，否则软件包名称必须后跟 : 和签名证书。

如果未按上述方法为 config_devicePolicyManagement 定义软件包名称，则：

  • [C-2-1] 设备实现必须支持在不使用设备政策管理角色持有者应用的情况下进行配置（AOSP 提供了参考实现）。

如果按上述方法为 config_devicePolicyManagement 定义了软件包名称，则：

  • [C-3-1] 必须在用户的所有资料上安装相应应用。
  • [C-3-2] 设备实现可以通过设置 config_devicePolicyManagementUpdater 来定义在配置前更新设备政策管理角色持有者的应用。

如果按上述方法为 config_devicePolicyManagementUpdater 定义了软件包名称，则：

  • [C-4-1] 必须在设备上预安装相应应用。
  • [C-4-2] 应用必须实现解析 android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER 的 intent 过滤器。

新要求开始

3.9.5 设备政策解决框架

如果设备实现报告 android.software.device_admin 或 android.software.managed_users，则：

新要求结束

3.10. 无障碍功能

Android 提供了一个无障碍功能层，以便残障用户更轻松地在其设备上进行导航。此外，Android 还提供了一些相应的平台 API，以便无障碍服务实现接收针对用户和系统事件的回调并生成备用反馈机制，例如文字转语音、触感反馈，以及轨迹球/方向键导航。

如果设备实现支持第三方无障碍服务，则：

  • [C-1-1] 必须提供 Android 无障碍功能框架（如无障碍功能 API SDK 文档中所述）的实现。
  • [C-1-2] 必须生成无障碍事件，并将相应的 AccessibilityEvent 提交到所有已注册的 AccessibilityService 实现（如 SDK 中所述）。
  • [C-1-4] 必须提供一种方式，让用户能够控制声明 AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON 的无障碍服务。请注意，对于具有系统导航栏的设备实现，设备实现应允许用户选择系统导航栏中的按钮来控制这些服务。

如果设备实现包含预安装的无障碍服务，则：

  • [C-2-1] 如果数据存储采用文件级加密 (FBE) 方式进行加密，必须将这些预安装的无障碍服务实现为直接启动感知型服务。
  • 应在开箱设置流程中提供一种可让用户启用相关无障碍服务的机制，以及用于调整字体大小、显示区域大小和放大手势的选项。

3.11. 文字转语音

Android 包含一些可让应用使用文字转语音 (TTS) 服务的 API，并允许服务提供商提供 TTS 服务实现。

如果设备实现报告 android.hardware.audio.output 功能，则：

如果设备实现支持安装第三方 TTS 引擎，则：

  • [C-2-1] 必须提供一种方式，让用户能够选择在系统级使用的 TTS 引擎。

3.12. TV 输入框架

Android TV 输入框架 (TIF) 能够简化向 Android TV 设备传输实时内容的过程。TIF 提供了一个标准 API，用于创建可控制 Android TV 设备的输入模块。

如果设备实现支持 TIF，则：

  • [C-1-1] 必须声明平台功能 android.software.live_tv。
  • [C-1-2] 必须支持所有 TIF API，以便用户在设备上安装和使用利用此类 API 和基于 TIF 的第三方输入服务的应用。

3.13. 快捷设置

Android 提供了一个“快捷设置”界面组件，供用户快速进行频繁执行或急需执行的操作。

如果设备实现包含“快捷设置”界面组件，并且支持第三方“快捷设置”，则：

  • [C-1-1] 必须允许用户添加或移除第三方应用通过 quicksettings API 提供的图块。
  • [C-1-2] 不得自动将来自第三方应用的图块直接添加到“快捷设置”中。
  • [C-1-3] 必须随同系统提供的快捷设置图块一起显示由用户添加的来自第三方应用的所有图块。

3.14. 媒体界面

如果设备实现包含通过 MediaBrowser 或 MediaSession 与第三方应用互动的非声控应用（简称应用），应用：

  • [C-1-2] 必须清楚显示通过 getIconBitmap() 或 getIconUri() 获取的图标和通过 getTitle() 获取的标题（如 MediaDescription 中所述）。可缩短标题以遵守安全规定（例如关于防止驾驶员分散注意力的规定）。

  • [C-1-3] 每当显示这个第三方应用提供的内容时，都必须显示此第三方应用的图标。

  • [C-1-4] 必须允许用户与整个 MediaBrowser 层次结构互动。可以限制访问部分层次结构以遵守安全规定（例如关于防止驾驶员分散注意力的规定），但不得根据内容或内容提供方给予优待。

  • [C-1-5] 必须将点按两次 KEYCODE_HEADSETHOOK 或 KEYCODE_MEDIA_PLAY_PAUSE 视为 KEYCODE_MEDIA_NEXT（对于 MediaSession.Callback#onMediaButtonEvent）。

3.15. 免安装应用

如果设备实现支持免安装应用，它们必须满足以下要求：

  • [C-1-1] 对于免安装应用，只能向其授予将 android:protectionLevel 设置为 "instant" 的权限。
  • [C-1-2] 免安装应用不得通过隐式 intent 与安装式应用互动，除非以下某项为 true：
    • 相应组件的 intent 模式过滤器已公开，并且具有 CATEGORY_BROWSABLE
    • 操作是 ACTION_SEND、ACTION_SENDTO 或 ACTION_SEND_MULTIPLE
    • 目标已通过 android:visibleToInstantApps 明确公开
  • [C-1-3] 免安装应用不得与安装式应用明确互动，除非相应组件已通过 android:visibleToInstantApps 公开。
  • [C-1-4] 安装式应用不得查看关于设备上免安装应用的详细信息，除非免安装应用明确关联到安装式应用。

  • 设备实现必须提供以下方式，让用户能够与免安装应用互动。AOSP 满足默认系统界面、设置和启动器的要求。设备实现：

    • [C-1-5] 必须提供一种方式，让用户能够查看并删除为每个应用软件包本地缓存的免安装应用。
    • [C-1-6] 必须提供可在免安装应用于前台运行时收起的持久用户通知。此用户通知必须包含关于免安装应用不需要安装的相关信息，并提供一种方式，可将用户导向“设置”中的应用信息屏幕。对于通过网络 intent 启动的免安装应用，即使用操作设置为 Intent.ACTION_VIEW 的 intent，且网络协议为“http”或“https”，还需要提供一种方式：允许用户不启动免安装应用而使用配置的网络浏览器启动关联链接（如果设备上有浏览器可用）。
    • [C-1-7] 必须允许从“最近用过”功能中访问正在运行的免安装应用（如果设备上提供“最近用过”功能）。

  • [C-1-8] 对于此处的 SDK 中列出的 intent，必须用 intent 处理程序预加载一个或多个应用或服务组件，并使这些 intent 对免安装应用可见。

3.16. 配套设备配对

Android 支持配套设备配对，以便更有效地管理与配套设备的关联，并且提供了可让应用使用此功能的 CompanionDeviceManager API。

如果设备实现支持配套设备配对功能，则：

  • [C-1-1] 必须声明功能标志 FEATURE_COMPANION_DEVICE_SETUP。
  • [C-1-2] 必须确保完整实现 android.companion 软件包内的 API。
  • [C-1-3] 必须提供一种方式，让用户能够选择/确认配套设备是否存在以及是否能够正常运作。

3.17. 重量级应用

如果设备实现声明 FEATURE_CANT_SAVE_STATE 功能，则：

  • [C-1-1] 每次系统中必须只能运行一个指定 cantSaveState 的安装式应用。如果用户在未明确退出的情况下离开此类应用（例如通过按“主屏幕”按钮导致 activity 在系统中仍然处于活动状态，而非按“返回”键使系统中不再有处于活动状态的 activity），设备实现必须在 RAM 中优先运行该应用，就像对待其他需要继续运行的应用一样（例如前台服务）。虽然此类应用在后台运行，但是系统仍然可以对其应用电源管理功能（例如限制 CPU 和网络访问权限）。
  • [C-1-2] 必须提供一个界面，以便用户在启动声明了 cantSaveState 属性的第二个应用时选择不加入常规状态保存/恢复机制的应用。
  • [C-1-3] 不得将政策中的其他更改（例如更改 CPU 性能或更改调度优先级）应用于指定 cantSaveState 的应用。

如果设备实现没有声明 FEATURE_CANT_SAVE_STATE 功能，则：

  • [C-1-1] 必须忽略应用设置的 cantSaveState 属性，且不得基于该属性更改应用行为。

3.18. 通讯录

Android 包含 Contacts Provider API，允许应用管理存储在设备上的联系信息。直接输入到设备上的联系人数据通常会与 Web 服务同步，但数据也可能仅驻留在设备本地。仅存储在设备上的联系人称为本地联系人。

当原始联系人的 ACCOUNT_NAME 和 ACCOUNT_TYPE 列与账号的对应 Account.name 和 Account.type 字段匹配时，RawContact 会与相应账号“关联”或“存储”在相应账号中。

默认本地账号：这是如下原始联系人的账号：仅存储在设备上、不与 AccountManager 中的账号关联，且创建时 ACCOUNT_NAME 和 ACCOUNT_TYPE 列的值为 null。

自定义本地账号：这是如下原始联系人的账号：仅存储在设备上、不与 AccountManager 中的账号关联，且创建时 ACCOUNT_NAME 和 ACCOUNT_TYPE 列的值至少有一个为非 null。

设备实现：

  • [C-SR-1] 强烈建议不要创建自定义本地账号。

如果设备实现使用自定义本地账号，则：

  • [C-1-1] ContactsContract.RawContacts.getLocalAccountName 必须返回自定义本地账号的 ACCOUNT_NAME
  • [C-1-2] ContactsContract.RawContacts.getLocalAccountType 必须返回自定义本地账号的 ACCOUNT_TYPE
  • [C-1-3] 由第三方应用通过默认本地账号插入的原始联系人（即，为 ACCOUNT_NAME 和 ACCOUNT_TYPE 设置 null 值）必须插入自定义本地账号中。
  • [C-1-4] 添加或移除账号时，不得移除插入到自定义本地账号中的原始联系人。
  • [C-1-5] 针对自定义本地账号执行的删除操作必须立即清除原始联系人（就像 CALLER_IS_SYNCADAPTER 参数被设置为 true 一样），即使 CALLER\_IS\_SYNCADAPTER 参数被设置为 false 或未指定也是如此。

4. 应用打包兼容性

设备实现：

  • [C-0-1] 必须能够安装和运行由官方 Android SDK 中包含的“aapt”工具生成的 Android“.apk”文件。

    • 由于上述要求可能不太容易满足，因此建议设备实现使用 AOSP 参考实现中的软件包管理系统。

  • [C-0-2] 必须支持使用 APK 签名方案 v3.1、APK 签名方案 v3、APK 签名方案 v2 和 JAR 签名来验证“.apk”文件。

  • [C-0-3] 扩展 .apk、Android 清单、Dalvik 字节码或 RenderScript 字节码格式时，采用的方式不得导致相应文件无法在其他 Android 兼容设备上正确安装和运行。

  • [C-0-4] 不得允许应用（软件包的当前“录制安装程序”除外）在没有用户确认的情况下静默卸载应用，如 SDK 中关于 DELETE_PACKAGE 权限的部分所述。仅有的两个例外应用是：负责处理 PACKAGE_NEEDS_VERIFICATION intent 的系统软件包验证程序应用和负责处理 ACTION_MANAGE_STORAGE intent 的存储空间管理器应用。

  • [C-0-5] 必须有负责处理 android.settings.MANAGE_UNKNOWN_APP_SOURCES intent 的 activity。

  • [C-0-6] 除非提出安装请求的应用满足以下所有要求，否则不得安装来自未知来源的应用软件包：

    • 必须声明 REQUEST_INSTALL_PACKAGES 权限，或者将 android:targetSdkVersion 设置为 24 或更低。
    • 必须已获得用户授权，能够安装来自未知来源的应用。

  • 应提供一种方式，让用户能够按应用授予/撤消安装来自未知来源的应用的权限；但如果设备实现不希望为用户提供这种选择，则可以选择将该功能实现为空操作，并针对 startActivityForResult() 返回 RESULT_CANCELED。不过，即使在这种情况下，设备实现也应向用户表明为什么没有提供这种选择。

  • [C-0-7] 在已被系统 API PackageManager.setHarmfulAppWarning 标记为“可能有害”的应用中启动某项 activity 之前，必须向用户显示警告对话框，其中的警告字符串是通过同一系统 API PackageManager.setHarmfulAppWarning 提供的。

  • 应提供一种方式，让用户能够在警告对话框中选择卸载或启动应用。

  • [C-0-8] 必须实现对增量文件系统的支持（如此处所述）。

  • [C-0-9] 必须支持使用 APK 签名方案 v4 和 APK 签名方案 v4.1 来验证 .apk 文件。

5. 多媒体兼容性

设备实现：

  • [C-0-1] 必须支持第 5.1 节中针对通过 MediaCodecList 声明的每种编解码器定义的媒体格式、编码器、解码器、文件类型和容器格式。
  • [C-0-2] 必须通过 MediaCodecList 声明并报告对可供第三方应用使用的编码器和解码器的支持情况。
  • [C-0-3] 必须能够正确解码，并向第三方应用通告它可以编码的所有格式。其中包括其编码器生成的所有比特流，以及其 CamcorderProfile 中报告的配置文件。

设备实现：

  • 应力争最大限度地缩短编解码器延迟，也就是说，它们
    • 不应使用和存储输入缓冲区，而仅应在处理之后将其返回。
    • 持有已解码缓冲区的时间不应超过相应标准（例如 SPS）指定的时间。
    • 持有已编码缓冲区的时间不应超过 GOP 结构所要求的时间。

在 Android 开源项目提供的首选 Android 实现中，以下部分中列出的所有编解码器均作为软件实现提供。

请注意，Google 和开放手机联盟 (Open Handset Alliance) 均未做过任何关于这些编解码器中没有第三方专利的声明。打算在硬件或软件产品中使用此源代码的用户请注意，实现此代码（包括在开源软件或共享软件中实现）可能需要获得相关专利持有者的专利许可。

5.1. 媒体编解码器

5.1.1. 音频编码

如需了解详情，请参阅 5.1.3. 音频编解码器详细信息。

如果设备实现声明 android.hardware.microphone，则必须支持以下音频格式编码并使其可供第三方应用使用：

  • [C-1-1] PCM/WAVE
  • [C-1-2] FLAC
  • [C-1-3] Opus

所有音频编码器都必须支持：

5.1.2. 音频解码

如需了解详情，请参阅 5.1.3. 音频编解码器详细信息。

如果设备实现声明支持 android.hardware.audio.output 功能，则必须支持解码以下音频格式：

  • [C-1-1] MPEG-4 AAC Profile (AAC LC)
  • [C-1-2] MPEG-4 HE AAC Profile (AAC+)
  • [C-1-3] MPEG-4 HE AACv2 Profile（增强型 AAC+）
  • [C-1-4] AAC ELD（增强型低延迟 AAC）
  • [C-1-11] xHE-AAC（ISO/IEC 23003-3 Extended HE AAC Profile，包含 USAC Baseline Profile 和 ISO/IEC 23003-4 Dynamic Range Control Profile）
  • [C-1-5] FLAC
  • [C-1-6] MP3
  • [C-1-7] MIDI
  • [C-1-8] Vorbis
  • [C-1-9] PCM/WAVE，包含高达 24 位、192 kHz 采样率和 8 个声道的高分辨率音频格式。请注意，此要求仅适用于解码，并且允许设备在播放阶段降采样和混缩。
  • [C-1-10] Opus

如果设备实现支持通过 android.media.MediaCodec API 中的默认 AAC 音频解码器将多声道音频串流（即超过两个声道）的 AAC 输入缓冲区解码为 PCM，则必须支持以下各项：

  • [C-2-1] 必须在不缩混的情况下进行解码（例如必须将 5.0 AAC 音频串流解码为五声道 PCM，必须将 5.1 AAC 音频串流解码为六声道 PCM）。
  • [C-2-2] 动态范围元数据必须符合 ISO/IEC 14496-3 中“动态范围控制 (DRC)”部分的定义；用于为音频解码器配置动态范围相关行为的 android.media.MediaFormat DRC 键也必须符合该定义。这些 AAC DRC 键是在 API 21 级中引入的，分别为：KEY_AAC_DRC_ATTENUATION_FACTOR、KEY_AAC_DRC_BOOST_FACTOR、KEY_AAC_DRC_HEAVY_COMPRESSION、KEY_AAC_DRC_TARGET_REFERENCE_LEVEL 和 KEY_AAC_ENCODED_TARGET_LEVEL。
  • [C-SR-1] 强烈建议所有 AAC 音频解码器都满足上述 C-2-1 和 C-2-2 要求。

解码 USAC 音频 MPEG-D (ISO/IEC 23003-4) 时：

  • [C-3-1] 必须根据 MPEG-D DRC Dynamic Range Control Profile Level 1 解读和应用音量及 DRC 元数据。
  • [C-3-2] 解码器必须按照通过以下 android.media.MediaFormat 键设置的配置执行操作：KEY_AAC_DRC_TARGET_REFERENCE_LEVEL 和 KEY_AAC_DRC_EFFECT_TYPE。

MPEG-4 AAC、HE AAC 和 HE AACv2 配置文件解码器：

  • 可以通过 ISO/IEC 23003-4 Dynamic Range Control Profile 支持音量和动态范围控制。

如果设备实现支持 ISO/IEC 23003-4 且解码的比特流中存在 ISO/IEC 23003-4 和 ISO/IEC 14496-3 元数据，则：

  • ISO/IEC 23003-4 元数据的优先级应更高。

所有音频解码器都必须支持输出：

如果设备实现支持通过 android.media.MediaCodec API 中的默认 AAC 音频解码器将多声道音频串流（即超过两个声道）的 AAC 输入缓冲区解码为 PCM，则必须支持以下各项：

  • [C-7-1] 必须能够由应用使用解码（通过键 KEY_MAX_OUTPUT_CHANNEL_COUNT）进行配置，以便控制是将内容降混成立体声（使用值 2 时），还是使用原生声道数（使用不低于该数值的值时）进行输出。例如，如果值不低于 6，可将解码器配置为在馈送 5.1 内容时输出 6 声道。
  • [C-7-2] 解码时，解码器必须使用 android.media.AudioFormat 常量（例如：CHANNEL_OUT_5POINT1）通过 KEY_CHANNEL_MASK 键通告对输出格式使用的声道掩码。

如果设备实现支持默认 AAC 音频解码器以外的音频解码器，并且能够在馈送经过压缩的多声道内容时输出多声道音频（即超过 2 声道），则：

  • [C-SR-2] 强烈建议解码器可由应用使用解码（通过键 KEY_MAX_OUTPUT_CHANNEL_COUNT）进行配置，以便控制是将内容降混成立体声（使用值 2 时），还是使用原生声道数（使用不低于该数值的值时）进行输出。例如，如果值不低于 6，可将解码器配置为在馈送 5.1 内容时输出 6 声道。
  • [C-SR-3] 解码时，强烈建议解码器使用 android.media.AudioFormat 常量（例如：CHANNEL_OUT_5POINT1）通过 KEY_CHANNEL_MASK 键通告对输出格式使用的声道掩码。

5.1.3. 音频编解码器详细信息

格式/编解码器 详细信息 支持的文件类型/容器格式
MPEG-4 AAC Profile
(AAC LC)		 支持单声道/立体声/5.0/5.1 内容，标准采样率为 8-48 kHz。
  • 3GPP (.3gp)
  • MPEG-4（.mp4、.m4a）
  • ADTS 原始 AAC（不支持 .aac、ADIF）
  • MPEG-TS（.ts，不可查找，仅适用于解码）
  • Matroska（.mkv，仅适用于解码）
MPEG-4 HE AAC Profile (AAC+) 支持单声道/立体声/5.0/5.1 内容，标准采样率为 16-48 kHz。
  • 3GPP (.3gp)
  • MPEG-4（.mp4、.m4a）
MPEG-4 HE AACv2
Profile（增强型 AAC+）		 支持单声道/立体声/5.0/5.1 内容，标准采样率为 16-48 kHz。
  • 3GPP (.3gp)
  • MPEG-4（.mp4、.m4a）
AAC ELD（增强型低延迟 AAC） 支持单声道/立体声内容，标准采样率为 16-48 kHz。
  • 3GPP (.3gp)
  • MPEG-4（.mp4、.m4a）
USAC 支持单声道/立体声内容，标准采样率为 7.35-48 kHz。 MPEG-4（.mp4、.m4a）
AMR-NB 4.75-12.2 kbps，采样率为 8 kHz 3GPP (.3gp)
AMR-WB 有 9 个比特率（介于 6.60-23.85 kbit/s）可供选择，采样率为 16 kHz（如 AMR-WB、自适应多速率 - 宽带语音编解码器中所定义） 3GPP (.3gp)
FLAC 对于编码器和解码器：必须至少支持单声道和立体声模式。必须支持高达 192 kHz 的采样率；必须支持 16 位和 24 位分辨率。FLAC 24 位音频数据处理必须具有浮点音频配置。
  • FLAC (.flac)
  • MPEG-4（.mp4 和 .m4a，仅适用于解码）
  • Matroska（.mkv，仅适用于解码）
MP3 单声道/立体声 8-320 Kbps 恒定 (CBR) 或可变比特率 (VBR)
  • MP3 (.mp3)
  • MPEG-4（.mp4 和 .m4a，仅适用于解码）
  • Matroska（.mkv，仅适用于解码）
MIDI MIDI 类型 0 和 1。DLS 版本 1 和 2。XMF 和 Mobile XMF。支持铃声格式 RTTTL/RTX、OTA 和 iMelody
  • 类型 0 和 1（.mid、.xmf、.mxmf）
  • RTTTL/RTX（.rtttl、.rtx）
  • iMelody (.imy)
Vorbis
  • Ogg (.ogg)
  • MPEG-4（.mp4 和 .m4a，仅适用于解码）
  • Matroska (.mkv)
  • Webm (.webm)
PCM/WAVE PCM 编解码器必须支持 16 位线性 PCM 和 16 位浮点。WAVE 提取器必须支持 16 位、24 位、32 位线性 PCM 和 32 位浮点（比特率最高可达到硬件上限）。必须支持 8 kHz 至 192 kHz 的采样率。 WAVE (.wav)
Opus 解码：支持单声道、立体声、5.0 和 5.1 内容，采样率为 8000、12000、16000、24000 和 48000 Hz。
编码：支持单声道和立体声内容，采样率为 8000、12000、16000、24000 和 48000 Hz。
  • Ogg (.ogg)
  • MPEG-4（.mp4 和 .m4a，仅适用于解码）
  • Matroska (.mkv)
  • Webm (.webm)

5.1.4. 图像编码

如需了解详情，请参阅 5.1.6. 图像编解码器详细信息。

设备实现必须支持以下图像编码：

  • [C-0-1] JPEG
  • [C-0-2] PNG
  • [C-0-3] WebP

新要求开始

  • [C-0-4] AVIF
    • 设备必须支持 BITRATE_MODE_CQ 和基准配置文件。

新要求结束

如果设备实现支持通过 android.media.MediaCodec 对媒体类型 MIMETYPE_IMAGE_ANDROID_HEIC 进行 HEIC 编码，则：

  • [C-1-1] 必须提供支持 BITRATE_MODE_CQ 比特率控制模式、HEVCProfileMainStill 配置文件和 512 x 512 像素帧尺寸的硬件加速 HEVC 编码器编解码器。

5.1.5. 图像解码

如需了解详情，请参阅 5.1.6. 图像编解码器详细信息。

设备实现必须支持以下图像解码：

  • [C-0-1] JPEG
  • [C-0-2] GIF
  • [C-0-3] PNG
  • [C-0-4] BMP
  • [C-0-5] WebP
  • [C-0-6] Raw
  • [C-0-7] AVIF（基准配置文件）

如果设备实现支持 HEVC 视频解码，则： * [C-1-1] 必须支持 HEIF (HEIC) 图像解码。

支持高位深格式（9+ 位/通道）的图像解码器：

  • [C-2-1] 必须支持输出 8 位等效格式（如果应用发出请求），例如通过 android.graphics.Bitmap 的 ARGB_8888 配置。

5.1.6. 图像编解码器详细信息

格式/编解码器 详细信息 支持的文件类型/容器格式
JPEG 基准式 + 渐进式 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 图像、图像集、图像序列 HEIF (.heif)、HEIC (.heic)
AVIF（基准配置文件） 图像、图像集、图像序列基准配置文件 HEIF 容器 (.avif)

通过 MediaCodec API 公开的图像编码器和解码器

  • [C-1-1] 必须通过 CodecCapabilities 支持 YUV420 8:8:8 灵活颜色格式 (COLOR_FormatYUV420Flexible)。

  • [C-SR-1] 强烈建议支持用于输入 Surface 模式的 RGB888 颜色格式。

  • [C-1-3] 必须至少支持平面或半平面 YUV420 8:8:8 颜色格式之一：COLOR_FormatYUV420PackedPlanar（等同于 COLOR_FormatYUV420Planar）或 COLOR_FormatYUV420PackedSemiPlanar（等同于 COLOR_FormatYUV420SemiPlanar）。强烈建议同时支持二者。

5.1.7. 视频编解码器

  • 为了使网络视频串流和视频会议服务的质量达到可接受的水平，设备实现应使用满足要求的硬件 VP8 编解码器。

如果设备实现包含视频解码器或编码器，则：

  • [C-1-1] 视频编解码器必须支持符合以下条件的输出和输入字节缓冲区大小：能够容纳相应标准和配置规定的最大可行压缩帧和未压缩帧，并且不会过度分配。

  • [C-1-2] 视频编码器和解码器必须通过 CodecCapabilities 支持 YUV420 8:8:8 灵活颜色格式 (COLOR_FormatYUV420Flexible)。

  • [C-1-3] 视频编码器和解码器必须至少支持平面或半平面 YUV420 8:8:8 颜色格式之一：COLOR_FormatYUV420PackedPlanar（等同于 COLOR_FormatYUV420Planar）或 COLOR_FormatYUV420PackedSemiPlanar（等同于 COLOR_FormatYUV420SemiPlanar）。强烈建议同时支持二者。

  • [C-SR-1] 强烈建议视频编码器和解码器至少支持硬件优化平面或半平面 YUV420 8:8:8 颜色格式之一（YV12、NV12、NV21 或等效供应商优化格式）。

  • [C-1-5] 支持高位深格式（9+ 位/通道）的视频解码器必须支持输出 8 位等效格式（如果应用发出请求）。必须通过支持 YUV420 8:8:8 颜色格式来反映这一点（通过 android.media.MediaCodecInfo）。

如果设备实现通过 Display.HdrCapabilities 通告支持 HDR 配置文件，则：

  • [C-2-1] 必须支持解析和处理 HDR 静态元数据。

如果设备实现通过 MediaCodecInfo.CodecCapabilities 类中的 FEATURE_IntraRefresh 通告支持帧内刷新，则：

  • [C-3-1] 必须支持介于 10-60 帧的刷新周期，并且必须在配置的刷新周期的 20% 内准确运行。

除非应用另行指定使用 KEY_COLOR_FORMAT 格式密钥，否则视频解码器实现：

  • [C-4-1] 必须默认为已针对硬件显示进行优化的颜色格式（如果使用 Surface 输出进行配置）。
  • [C-4-2] 必须默认为已针对 CPU 读取进行优化的 YUV420 8:8:8 颜色格式（如果配置为不使用 Surface 输出）。

5.1.8. 视频编解码器列表

格式/编解码器 详细信息 支持的文件类型/容器格式
H.263
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • Matroska（.mkv，仅适用于解码）
H.264 AVC 如需了解详情，请参阅第 5.2 节和第 5.3 节
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • MPEG-2 TS（.ts，不可查找）
  • Matroska（.mkv，仅适用于解码）
H.265 HEVC 如需了解详情，请参阅第 5.3 节
  • MPEG-4 (.mp4)
  • Matroska（.mkv，仅适用于解码）
MPEG-2 Main Profile
  • MPEG2-TS（.ts，不可查找）
  • MPEG-4（.mp4、仅适用于解码）
  • Matroska（.mkv，仅适用于解码）
MPEG-4 SP
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • Matroska（.mkv，仅适用于解码）
VP8 如需了解详情，请参阅第 5.2 节和第 5.3 节
VP9 如需了解详情，请参阅第 5.3 节
AV1 如需了解详情，请参阅第 5.2 节和第 5.3 节
  • MPEG-4 (.mp4)
  • Matroska（.mkv，仅适用于解码）

5.1.9. 媒体编解码器安全

设备实现必须确保符合媒体编解码器安全功能要求（如下所述）。

Android 支持 OMX（跨平台多媒体加速 API），以及 Codec 2.0（低开销多媒体加速 API）。

如果设备实现支持多媒体，则：

  • [C-1-1] 必须像在 Android 开源项目中那样通过 OMX 或 Codec 2.0 API（或二者）支持媒体编解码器，且不禁用或规避安全保护措施。具体说来，这并不意味着每个编解码器都必须使用 OMX 或 Codec 2.0 API，只是意味着至少要支持这些 API 中的一个，而且对可用 API 的支持必须包含现有的安全保护措施。
  • [C-SR-1] 强烈建议支持 Codec 2.0 API。

如果设备实现不支持 Codec 2.0 API，则：

  • [C-2-1] 对于设备支持的每种媒体格式和类型（编码器或解码器），必须包含 Android 开源项目中相应的 OMX 软件编解码器（如果可用）。
  • [C-2-2] 名称以“OMX.google.”开头的编解码器必须基于其 Android 开源项目源代码。
  • [C-SR-2] 强烈建议 OMX 软件编解码器在无法访问除内存映射器之外的硬件驱动程序的编解码器进程中运行。

如果设备实现支持 Codec 2.0 API，则：

  • [C-3-1] 对于设备支持的每种媒体格式和类型（编码器或解码器），必须包含 Android 开源项目中相应的 Codec 2.0 软件编解码器（如果可用）。
  • [C-3-2] 必须在软件编解码器进程中包含 Codec 2.0 软件编解码器（如 Android 开源项目中所提供），以便能够更精细地授予对软件编解码器的访问权限。
  • [C-3-3] 名称以“c2.android.”开头的编解码器必须基于其 Android 开源项目源代码。

5.1.10. 媒体编解码器特征

如果设备实现支持媒体编解码器，则：

  • [C-1-1] 必须通过 MediaCodecInfo API 返回媒体编解码器特征的正确值。

具体而言：

  • [C-1-2] 名称以“OMX.”开头的编解码器必须使用 OMX API，且其名称必须符合 OMX IL 命名准则。
  • [C-1-3] 名称以“c2.”开头的编解码器必须使用 Codec 2.0 API，且其名称必须符合 Android 的 Codec 2.0 命名准则。
  • [C-1-4] 名称以“OMX.google.”或“c2.android.”开头的编解码器不得以供应商或硬件加速为特征。
  • [C-1-5] 在能够访问除内存分配器和映射器以外的硬件驱动程序的编解码器进程（供应商或系统）中运行的编解码器不得以仅限软件为特征。
  • [C-1-6] 不在 Android 开源项目中或不基于该项目中的开源代码的编解码器必须以供应商为特征。
  • [C-1-7] 利用硬件加速的编解码器必须以硬件加速为特征。
  • [C-1-8] 编解码器名称不得具有误导性。例如，名为“解码器”的编解码器必须支持解码，而名为“编码器”的编解码器必须支持编码。名称包含媒体格式的编解码器必须支持这些格式。

如果设备实现支持视频编解码器：

  • [C-2-1] 所有视频编解码器都必须针对以下尺寸发布可实现的帧速率数据（如果编解码器支持的话）：
标清（低画质） 标清（高画质） 高清 720p 高清 1080p 超高清
视频分辨率
  • 176 x 144 像素（H263、MPEG2、MPEG4）
  • 352 x 288 像素（MPEG4 编码器、H263、MPEG2）
  • 320 x 180 像素（VP8、VP8）
  • 320 x 240 像素（其他）
  • 704 x 576 像素 (H263)
  • 640 x 360 像素（VP8、VP9）
  • 640 x 480 像素（MPEG4 编码器）
  • 720 x 480 像素（其他，AV1）
  • 1408 x 1152 像素 (H263)
  • 1280 x 720 像素（其他，AV1）
 1920 x 1080 像素（MPEG4、AV1 除外） 3840 x 2160 像素（HEVC、VP9、AV1）
  • [C-2-2] 具有硬件加速特征的视频编解码器必须发布性能点信息。它们必须各自列出所有支持的标准性能点（在 PerformancePoint API 中列出），除非被其他支持的标准性能点覆盖。
  • 此外，如果它们支持持续视频性能而非列出的标准性能点之一，则应发布扩展性能点。

5.2. 视频编码

如果设备实现支持任何视频编码器，并使其可供第三方应用使用，则：

  • 采用两个滑窗时，比帧内 (I-frame) 间隔之间的比特率高出的幅度不应超过 15%。
  • 比采用一个 1 秒的滑窗时的比特率高出的幅度不应超过 100%。

新要求开始

如果设备实现支持任何视频编码器，使其可供第三方应用使用，
并将 MediaFormat.KEY_BITRATE_MODE 设置为 BITRATE_MODE_VBR，以便编码器在“可变比特率”模式下运行；那么，只要它不会影响最低质量下限，编码比特率便会：

  • [C-5-1] 采用一个滑窗时，比帧内 (I-frame) 间隔之间的比特率高出的幅度不得采用一个滑窗时，比帧内 (I-frame) 间隔之间的比特率高出的幅度不应超过 15%。
  • [C-5-2] 比采用一个 1 秒的滑窗时的比特率高出的幅度不得比采用一个 1 秒的滑窗时的比特率高出的幅度不应超过 100%。

如果设备实现支持任何视频编码器，使其可供第三方应用使用，并将 MediaFormat.KEY_BITRATE_MODE 设置为 BITRATE_MODE_CBR 以便让编码器以恒定比特率模式运行，则编码比特率：

  • [C-6-1] 必须[C-SR-2] 强烈建议比采用一个 1 秒的滑窗时的目标比特率高出的幅度不超过 15%。

新要求结束

如果设备实现包含对角线长度至少为 2.5 英寸的嵌入式屏幕，或包含视频输出端口，或通过 android.hardware.camera.any 功能标志声明支持摄像头，则：

  • [C-1-1] 必须支持至少一个 VP8 或 H.264 视频编码器，并使其可供第三方应用使用。
  • 应同时支持 VP8 和 H.264 视频编码器，并使其可供第三方应用使用。

如果设备实现支持 H.264、VP8、VP9 或 HEVC 视频编码器中的任何一个，并使其可供第三方应用使用，则：

  • [C-2-1] 必须支持可动态配置的比特率。
  • 应支持可变帧速率，在这种情况下，视频编码器应根据输入缓冲区的时间戳来确定瞬时帧时长，并根据该帧时长来分配其位存储分区。

如果设备实现支持 MPEG-4 SP 视频编码器，并使其可供第三方应用使用，则：

  • 应针对支持的编码器支持可动态配置的比特率。

如果设备实现提供硬件加速视频或图像编码器，并且支持一个或多个通过 android.camera API 公开的已连接或可插拔硬件摄像头，则：

  • [C-4-1] 所有硬件加速视频和图像编码器都必须支持从硬件摄像头编码帧。
  • 应支持通过所有视频或图像编码器从硬件摄像头编码帧。

如果设备实现提供 HDR 编码，则：

  • [C-SR-1] 强烈建议为无缝转码 API 提供一个插件，以便从 HDR 格式转换为 SDR 格式。

5.2.1. H.263

如果设备实现支持 H.263 编码器，并使其可供第三方应用使用，则：

  • [C-1-1] 必须使用 Baseline Profile Level 45 支持 QCIF 分辨率 (176 x 144)。SQCIF 分辨率是可选的。
  • 应针对支持的编码器支持可动态配置的比特率。

5.2.2. H.264

如果设备实现支持 H.264 编解码器，则：

  • [C-1-1] 必须支持 Baseline Profile Level 3。不过，可以选择是否支持 ASO（任意 Slice 顺序）、FMO（灵活宏块顺序）和 RS（冗余 Slice）。此外，为了保持与其他 Android 设备兼容，对于基准配置文件，建议编码器不要使用 ASO、FMO 和 RS。
  • [C-1-2] 必须支持下表中的标清视频编码配置文件。
  • 应支持 Main Profile Level 4。
  • 应支持下表中所列的高清视频编码配置文件。

如果设备实现通过媒体 API 报告支持对分辨率为 720p 或 1080p 的视频进行 H.264 编码，则：

  • [C-2-1] 必须支持下表中的编码配置文件。
标清（低画质） 标清（高画质） 高清 720p 高清 1080p
视频分辨率 320 x 240 像素 720 x 480 像素 1280 x 720 像素 1920 x 1080 像素
视频帧速率 20 fps 30 fps 30 fps 30 fps
视频比特率 384 Kbps 2 Mbps 4 Mbps 10 Mbps

5.2.3. VP8

如果设备实现支持 VP8 编解码器，则：

  • [C-1-1] 必须支持标清视频编码配置。
  • 应支持以下高清视频编码配置。
  • [C-1-2] 必须支持写入 Matroska WebM 文件。
  • 应提供满足 WebM 项目 RTC 硬件编码要求的硬件 VP8 编解码器，以确保网络视频串流和视频会议服务的质量达到可接受的水平。

如果设备实现通过媒体 API 报告支持对分辨率为 720p 或 1080p 的视频进行 VP8 编码，则：

  • [C-2-1] 必须支持下表中的编码配置文件。
标清（低画质） 标清（高画质） 高清 720p 高清 1080p
视频分辨率 320 x 180 像素 640 x 360 像素 1280 x 720 像素 1920 x 1080 像素
视频帧速率 30 fps 30 fps 30 fps 30 fps
视频比特率 800 Kbps 2 Mbps 4 Mbps 10 Mbps

5.2.4. VP9

如果设备实现支持 VP9 编解码器，则：

  • [C-1-2] 必须支持 Profile 0 Level 3。
  • [C-1-1] 必须支持写入 Matroska WebM 文件。
  • [C-1-3] 必须生成 CodecPrivate 数据。
  • 应支持下表中所列的高清解码配置。
  • [C-SR-1] 强烈建议支持下表中所列的高清解码配置文件（如果有硬件编码器）。
标清 高清 720p 高清 1080p 超高清
视频分辨率 720 x 480 像素 1280 x 720 像素 1920 x 1080 像素 3840 x 2160 像素
视频帧速率 30 fps 30 fps 30 fps 30 fps
视频比特率 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

如果设备实现声明通过媒体 API 支持 Profile 2 或 Profile 3：

  • 可选择是否支持 12 位格式。

5.2.5. H.265

如果设备实现支持 H.265 编解码器，则：

  • [C-1-1] 必须支持 Main Profile Level 3，分辨率最高为 512 x 512。
  • 应支持下表中所列的高清编码配置文件。
  • [C-SR-1] 如果有硬件编码器的话，强烈建议支持 720 x 480 标清配置文件和高清编码配置文件（如下表所列）。
标清 高清 720p 高清 1080p 超高清
视频分辨率 720 x 480 像素 1280 x 720 像素 1920 x 1080 像素 3840 x 2160 像素
视频帧速率 30 fps 30 fps 30 fps 30 fps
视频比特率 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

新要求开始

5.2.6. AV1

如果设备实现支持 AV1 编解码器，则：

  • [C-1-1] 必须支持 Main Profile，包括 8 位和 10 位内容。

  • [C-1-2] 必须通过 getSupportedFrameRatesFor() 或 getSupportedPerformancePoints() API 针对下表中支持的分辨率发布性能数据（即报告性能数据）。

  • [C-1-3] 必须接受 HDR 元数据并将其输出到比特流

如果 AV1 编码器经过硬件加速，则：

  • [C-2-1] 必须支持下表中不低于 HD1080p 的编码配置文件：
标清 高清 720p 高清 1080p 超高清
视频分辨率 720 x 480 像素 1280 x 720 像素 1920 x 1080 像素 3840 x 2160 像素
视频帧速率 30 fps 30 fps 30 fps 30 fps
视频比特率 5 Mbps 8 Mbps 16 Mbps 50 Mbps

新要求结束

5.3. 视频解码

如果设备实现支持 VP8、VP9、H.264 或 H.265 编解码器，则：

  • [C-1-1] 对于所有 VP8、VP9、H.264 和 H.265 编解码器，都必须支持通过标准 Android API 在同一视频串流内实时进行动态视频分辨率和帧速率切换，并且能够支持设备上每个编解码器所支持的最大分辨率。

5.3.1. MPEG-2

如果设备实现支持 MPEG-2 解码器，则：

  • [C-1-1] 必须支持 Main Profile High Level。

5.3.2. H.263

如果设备实现支持 H.263 解码器，则：

  • [C-1-1] 必须支持 Baseline Profile Level 30（CIF、QCIF 和 SQCIF 分辨率 @30fps 384kbps）和 Level 45（QCIF 和 SQCIF 分辨率 @30fps 128kbps）。

5.3.3. MPEG-4

如果设备实现具有 MPEG-4 解码器，则：

  • [C-1-1] 必须支持 Simple Profile Level 3。

5.3.4. H.264

如果设备实现支持 H.264 解码器，则：

  • [C-1-1] 必须支持 Main Profile Level 3.1 和 Baseline Profile。可以选择是否支持 ASO（任意 Slice 顺序）、FMO（灵活宏块顺序）和 RS（冗余 Slice）。
  • [C-1-2] 必须能够对以下视频进行解码：采用下表中所列的标清配置，且使用 Baseline Profile 和 Main Profile Level 3.1（包括 720p30）编码的视频。
  • 应能够对采用下表中所列高清配置文件的视频进行解码。

如果 Display.getSupportedModes() 方法报告的高度等于或大于视频分辨率，则设备实现：

  • [C-2-1] 必须支持下表中的高清 720p 视频解码配置文件。
  • [C-2-2] 必须支持下表中的高清 1080p 视频解码配置文件。
标清（低画质） 标清（高画质） 高清 720p 高清 1080p
视频分辨率 320 x 240 像素 720 x 480 像素 1280 x 720 像素 1920 x 1080 像素
视频帧速率 30 fps 30 fps 60 fps 30 fps (60 fpsTV)
视频比特率 800 Kbps 2 Mbps 8 Mbps 20 Mbps

5.3.5. H.265 (HEVC)

如果设备实现支持 H.265 编解码器，则：

  • [C-1-1] 必须支持 Main Profile Level 3 Main Tier 和下表中所列的标清视频解码配置文件。
  • 应支持下表中所列的高清解码配置。
  • [C-1-2] 必须支持下表中所列的高清解码配置文件（如果有硬件解码器的话）。

如果 Display.getSupportedModes() 方法报告的高度等于或大于视频分辨率，则：

  • [C-2-1] 设备实现必须至少支持 720、1080 和超高清配置文件的 H.265 或 VP9 解码之一。
标清（低画质） 标清（高画质） 高清 720p 高清 1080p 超高清
视频分辨率 352 x 288 像素 720 x 480 像素 1280 x 720 像素 1920 x 1080 像素 3840 x 2160 像素
视频帧速率 30 fps 30 fps 30 fps 30/60 fps（60 fps采用 H.265 硬件解码的 TV） 60 fps
视频比特率 600 Kbps 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

如果设备实现声明通过媒体 API 支持 HDR 配置文件，则：

  • [C-3-1] 设备实现必须从应用中接受所需的 HDR 元数据，以及支持从比特流和/或容器提取和输出所需的 HDR 元数据。
  • [C-3-2] 设备实现必须在设备屏幕或标准视频输出端口（例如 HDMI）上正确显示 HDR 内容。

5.3.6. VP8

如果设备实现支持 VP8 编解码器，则：

  • [C-1-1] 必须支持下表中的标清解码配置。
  • 应使用满足要求的硬件 VP8 编解码器。
  • 应支持下表中的高清解码配置。

如果 Display.getSupportedModes() 方法报告的高度等于或大于视频分辨率，则：

  • [C-2-1] 设备实现必须支持下表中的 720p 配置文件。
  • [C-2-2] 设备实现必须支持下表中的 1080p 配置文件。
标清（低画质） 标清（高画质） 高清 720p 高清 1080p
视频分辨率 320 x 180 像素 640 x 360 像素 1280 x 720 像素 1920 x 1080 像素
视频帧速率 30 fps 30 fps 30 fps (60 fpsTV) 30 (60 fpsTV)
视频比特率 800 Kbps 2 Mbps 8 Mbps 20 Mbps

5.3.7. VP9

如果设备实现支持 VP9 编解码器，则：

  • [C-1-1] 必须支持下表中所列的标清视频解码配置。
  • 应支持下表中所列的高清解码配置。

如果设备实现支持 VP9 编解码器和硬件解码器，则：

  • [C-2-1] 必须支持下表中所列的高清解码配置文件。

如果 Display.getSupportedModes() 方法报告的高度等于或大于视频分辨率，则：

  • [C-3-1] 设备实现必须至少支持 720、1080 和超高清配置文件的 VP9 或 H.265 解码之一。
标清（低画质） 标清（高画质） 高清 720p 高清 1080p 超高清
视频分辨率 320 x 180 像素 640 x 360 像素 1280 x 720 像素 1920 x 1080 像素 3840 x 2160 像素
视频帧速率 30 fps 30 fps 30 fps 30 fps（60 fps采用 VP9 硬件解码的 TV） 60 fps
视频比特率 600 Kbps 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

如果设备实现声明通过 'CodecProfileLevel' 媒体 API 支持 VP9Profile2 或 VP9Profile3，则：

  • 可选择是否支持 12 位格式。

如果设备实现声明通过媒体 API 支持 HDR 配置文件（VP9Profile2HDR、VP9Profile2HDR10Plus、VP9Profile3HDR 和 VP9Profile3HDR10Plus），则：

  • [C-4-1] 设备实现必须从应用中接受所需的 HDR 元数据（对于所有 HDR 配置文件，应接受 KEY_HDR_STATIC_INFO，而对于 HDR10Plus 配置文件，应接受 'KEY_HDR10_PLUS_INFO'）。它们还必须支持从比特流和/或容器中提取和输出所需的 HDR 元数据。
  • [C-4-2] 设备实现必须在设备屏幕或标准视频输出端口（例如 HDMI）上正确显示 HDR 内容。

5.3.8. 杜比视界

如果设备实现声明通过 HDR_TYPE_DOLBY_VISION 支持杜比视界解码器，则：

  • [C-1-1] 必须提供具有杜比视界功能的提取器。
  • [C-1-2] 必须在设备屏幕或标准视频输出端口（例如 HDMI）上正确显示杜比视界内容。
  • [C-1-3] 必须将向后兼容的基本层（如果存在）的跟踪 ID 设置为与组合式杜比视界层的跟踪 DI 相同。

5.3.9. AV1

如果设备实现支持 AV1 编解码器，则：

  • [C-1-1] 必须支持 Profile 0（其中包含 10 位内容）。

新要求开始

如果设备实现支持 AV1 编解码器，并使其可供第三方应用使用，则：

  • [C-1-1] 必须支持 Main Profile，包括 8 位和 10 位内容。

如果设备实现支持具有硬件加速解码器的 AV1 编解码器，则：

  • [C-2-1] 当 Display.getSupportedModes() 方法报告的高度等于或高于 720p 时，必须能够从下表中解码至少高清 720p 视频解码配置文件。
  • [C-2-2] 当 Display.getSupportedModes() 方法报告的高度等于或高于 1080p 时，必须能够从下表中解码至少高清 1080p 视频解码配置文件。
标清 高清 720p 高清 1080p 超高清
视频分辨率 720 x 480 像素 1280 x 720 像素 1920 x 1080 像素 3840 x 2160 像素
视频帧速率 30 fps 30 fps 30 fps 30 fps
视频比特率 5 Mbps 8 Mbps 16 Mbps 50 Mbps

如果设备实现通过媒体 API 支持 HDR 配置文件，则：

  • [C-3-1] 必须支持从比特流和/或容器中提取和输出 HDR 元数据。
  • [C-3-2] 必须在设备屏幕或标准视频输出端口（例如 HDMI）上正确显示 HDR 内容。

新要求结束

5.4. 录音

虽然从 Android 4.3 开始，本节中所述的一些要求被列为“应”满足的要求，但我们计划在未来版本的兼容性定义文档中将其更改为“必须”满足的要求。强烈建议现有的及新的 Android 设备满足这些被列为“应”满足的要求，否则在升级到未来版本后将无法与 Android 兼容。

5.4.1. 原始音频捕获和麦克风信息

如果设备实现声明 android.hardware.microphone，则：

  • [C-1-1] 必须允许捕获成功打开的任何 AudioRecord 或 AAudio 输入流的原始音频内容。必须至少支持以下特征：

  • 应允许捕获具有以下特征的原始音频内容：

    • 格式：线性 PCM、16 位、24 位
    • 采样率：8000 Hz、11025 Hz、16000 Hz、22050 Hz、24000 Hz、32000 Hz、44100 Hz、48000 Hz
    • 声道：声道数与设备上的麦克风数相同

  • [C-1-2] 必须在不进行升采样的情况下以上述采样率捕获音频内容。

  • [C-1-3] 在进行降采样的情况下以上述采样率捕获音频内容时，必须包含适当的抗混叠滤波器。

  • 应允许以 AM 收音机和 DVD 品质捕获原始音频内容，即具有以下特征的音频内容：

    • 格式：线性 PCM、16 位
    • 采样率：22050 Hz、48000 Hz
    • 声道：立体声

  • [C-1-4] 必须遵从 MicrophoneInfo API，并为使用 MediaRecorder.AudioSources DEFAULT、MIC、CAMCORDER、VOICE_RECOGNITION、VOICE_COMMUNICATION、UNPROCESSED 或 VOICE_PERFORMANCE 的有效 AudioRecord 正确填写设备上可通过 AudioManager.getMicrophones() API 供第三方应用访问的可用麦克风的信息。如果设备实现允许以 AM 收音机和 DVD 品质捕获原始音频内容，则：

  • [C-2-1] 必须在不进行升采样的情况下以高于 16000:22050 或 44100:48000 的任意采样率捕获音频内容。

  • [C-2-2] 对于任何升采样或降采样，必须包含适当的抗混叠滤波器。

5.4.2. 捕获音频串流以进行语音识别

如果设备实现声明 android.hardware.microphone，则：

  • [C-1-1] 必须以 44,100 或 48,000 采样率之一捕获 android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION 音频源。
  • [C-1-2] 在录制来自 AudioSource.VOICE_RECOGNITION 音频源的音频流时，必须默认停用所有降噪音频处理。

  • [C-1-3] 在录制来自 AudioSource.VOICE_RECOGNITION 音频源的音频流时，必须默认停用所有自动增益控制。

  • 对于每个用于对语音识别音频源进行录音的麦克风，在中频范围内应表现出大致平坦的幅频特性，具体来说就是：±3dB (100 Hz - 4000 Hz)。

  • [C-SR-1] 对于每个用于对语音识别音频源进行录音的麦克风，强烈建议在低频范围内表现出适当的振幅等级，具体来说就是：±20 dB (30 Hz - 100 Hz)（与中频范围相比）。

  • [C-SR-2] 对于每个用于对语音识别音频源进行录音的麦克风，强烈建议在高频范围内表现出适当的振幅等级，具体来说就是：±30 dB (4000 Hz - 22 KHz)（与中频范围相比）。

  • 对于每个用于对语音识别音频源进行录音的麦克风，应设置适当的音频输入敏感度，以确保对于 16 位的样本，以 90 dB 声压级 (SPL) 播放（在距离麦克风 30 厘米处麦克风旁边测量）的 1,000 Hz 正弦音调源会产生 RMS 为 2,500（在 1,770 到 3,530 范围内）的理想响应（或对于浮点/双精度样本，为 -22.35 db ±3dB 全标度）。

  • 在录制语音识别音频串流时，如果麦克风上的 SPL 为 90 dB，PCM 振幅级应能够线性跟踪输入 SPL 在至少 30 dB（-18 dB 到 +12 dB）范围内的变化。

  • 在录制语音识别音频流时，如果麦克风上输入 1 kHz 的 90 dB SPL 声音，总谐波畸变率 (THD) 应小于 1%。

如果设备实现声明 android.hardware.microphone 并声明已针对语音识别进行微调的噪音抑制（降噪）技术，则：

  • [C-2-1] 必须允许通过 android.media.audiofx.NoiseSuppressor API 控制此音频效果。
  • [C-2-2] 必须通过 AudioEffect.Descriptor.uuid 字段唯一标识每项噪音抑制技术实现。

5.4.3. 捕获音频串流以进行重定向播放

android.media.MediaRecorder.AudioSource 类包含 REMOTE_SUBMIX 音频源。

如果设备实现同时声明 android.hardware.audio.output 和 android.hardware.microphone，则：

  • [C-1-1] 必须正确实现 REMOTE_SUBMIX 音频源，以便应用使用 android.media.AudioRecord API 录制来自此音频源的音频串流时，可以捕获除以下内容之外的所有音频串流的混音：

    • AudioManager.STREAM_RING
    • AudioManager.STREAM_ALARM
    • AudioManager.STREAM_NOTIFICATION

5.4.4. 回声消除器

如果设备实现声明 android.hardware.microphone，则：

  • 使用 AudioSource.VOICE_COMMUNICATION 捕获音频时，应实现针对语音通信微调并已应用于捕获路径的回声消除器 (AEC) 技术。

如果设备实现提供在选择 AudioSource.VOICE_COMMUNICATION 时插入音频捕获路径中的回声消除器，则：

5.4.5. 并发捕获

如果设备实现声明 android.hardware.microphone，则必须实现并发捕获（如本文档中所述）。具体而言：

  • [C-1-1] 必须允许通过 AudioSource.VOICE_RECOGNITION 捕获的无障碍服务以及至少一个通过任何 AudioSource 捕获的应用对麦克风进行并发访问。
  • [C-1-2] 必须允许通过一个具有助理角色的预安装应用和至少一个通过任何 AudioSource 捕获（AudioSource.VOICE_COMMUNICATION 或 AudioSource.CAMCORDER 除外）的应用对麦克风进行并发访问。
  • [C-1-3] 当一个应用正在通过 AudioSource.VOICE_COMMUNICATION 或 AudioSource.CAMCORDER 捕获音频时，必须阻止任何其他应用（无障碍服务除外）捕获音频。不过，当一个应用正在通过 AudioSource.VOICE_COMMUNICATION 捕获音频时，如果其他应用是具有权限 CAPTURE_AUDIO_OUTPUT 的特权（预安装）应用，可以捕获语音通话。
  • [C-1-4] 如果两个或多个应用同时捕获音频，并且两个应用之上均无界面，最近开始捕获的应用会接收音频。

5.5. 音频播放

Android 支持应用通过音频输出外围设备（如第 7.8.2 节中所定义）播放音频。

5.5.1. 原始音频播放

如果设备实现声明 android.hardware.audio.output，则：

  • [C-1-1] 必须允许播放具有以下特征的原始音频内容：

    • 来源格式：线性 PCM、16 位、8 位、浮点型
    • 声道：单声道、立体声、支持多达 8 声道的有效多声道配置
    • 采样率（以 Hz 为单位）：
      • 8000、11025、16000、22050、24000、32000、44100、48000（声道配置如上所列）
      • 96000（单声道和立体声）

5.5.2. 音效

Android 为设备实现提供音效 API。

如果设备实现声明 android.hardware.audio.output 功能，则：

  • [C-1-1] 必须支持 EFFECT_TYPE_EQUALIZER 和 EFFECT_TYPE_LOUDNESS_ENHANCER 实现，这两种实现可通过 AudioEffect 子类 Equalizer 和 LoudnessEnhancer 进行控制。
  • [C-1-2] 必须支持可视化工具 API 实现（可通过 Visualizer 类进行控制）。
  • [C-1-3] 必须支持 EFFECT_TYPE_DYNAMICS_PROCESSING 实现，该实现可通过 AudioEffect 子类 DynamicsProcessing 进行控制。

新要求开始

  • [C-1-4] 必须支持具有浮点输入和输出的音效。
  • [C-1-5] 必须确保音效支持多声道，且声道数量不超过混音器的声道数量（也称为 FCC_LIMIT）。

新要求结束

  • 应支持 EFFECT_TYPE_BASS_BOOST、EFFECT_TYPE_ENV_REVERB、EFFECT_TYPE_PRESET_REVERB 和 EFFECT_TYPE_VIRTUALIZER 实现（可通过 AudioEffect 子类 BassBoost、EnvironmentalReverb、PresetReverb 和 Virtualizer 进行控制）。
  • [C-SR-1] 强烈建议支持浮点数和多声道效果。

5.5.3. 音频输出音量

Automotive 设备实现：

  • 应允许按每个音频串流单独调整音频音量（使用通过 AudioAttributes 定义的内容类型或用法，以及 android.car.CarAudioManager 中公开定义的车载音频系统用法）。

5.5.4. 音频分流

如果设备实现支持音频分流播放，则：

  • [C-SR-1] 强烈建议在 AudioTrack 无间断 API 和 MediaPlayer 媒体容器指定的情况下，对两个格式相同的剪辑之间播放的无间断音频内容进行剪辑。

5.6. 音频延迟

音频延迟是指音频信号通过系统时的时间延迟。许多类别的应用都依赖于非常短的延迟来实现实时音效。

在本节中，使用以下定义：

  • 输出延迟：从应用写入经过 PCM 编码的数据帧到相应声音在设备内置变频器处的环境中播放出来之间的时间间隔，或者从信号通过端口离开设备到可在外部听到相应声音之间的时间间隔。
  • 冷输出延迟：在收到相应请求之前音频输出系统处于闲置状态且已关闭时，根据时间戳启动输出流与呈现第一帧之间的间隔。
  • 连续输出延迟：设备播放音频后，后续帧的输出延迟。
  • 输入延迟：从环境中发出声音到设备内置变频器处的设备捕获到该声音之间的时间间隔，或者从信号通过端口进入设备到应用读取经过 PCM 编码的数据对应的帧之间的时间间隔。
  • 丢失输入：输入信号中不可用或无法捕获到的初始部分。
  • 冷输入延迟：在收到相应请求之前音频输入系统处于闲置状态且已关闭时，启动输入流与接收第一有效帧之间的间隔。

  • 连续输入延迟：当设备捕获音频时，后续帧的输入延迟时间。

  • 连续往返延迟：连续输入延迟、连续输出延迟，再加一个缓冲期的总和。缓冲期可让应用有时间来处理信号，并有时间来降低输入流和输出流之间的相位差。

  • OpenSL ES PCM 缓冲区队列 API。Android NDK 中的一组与 PCM 相关的 OpenSL ES API。

  • AAudio 原生音频 API：Android NDK 中的一组 AAudio API。

  • 时间戳：信息流中的相对帧位置与该帧在关联端点上进入或离开音频处理管道的大约时间的组合。另请参阅 AudioTimestamp。

  • 干扰：音频信号临时中断或样例值不正确，这通常是由输出设备的缓冲区欠载、输入设备的缓冲区溢出或任何其他数字或模拟噪声源所致。

  • 平均绝对偏差：在一组值中，各个值与总体平均值的偏差的绝对值平均值。

  • 点按与发声间延迟：用户点按屏幕后，扬声器会听到提示音。点按屏幕到扬声器上听到轻击产生的音调之间的时间。

如果设备实现声明 android.hardware.audio.output，则必须满足或超出以下要求：

  • [C-1-1] AudioTrack.getTimestamp 和 AAudioStream_getTimestamp 返回的输出时间戳精确到 +/- 2 毫秒。

  • [C-1-2] 冷输出延迟时间不超过 500 毫秒。

  • [C-1-3] 使用 AAudioStreamBuilder_openStream() 打开输出流所需的时间必须低于 1000 毫秒。

如果设备实现声明 android.hardware.audio.output，强烈建议它们满足或超出以下要求：

  • [C-SR-1] 扬声器数据路径上的冷输出延迟时间不超过 100 毫秒。
  • [C-SR-2] 点按与发声间延迟时间不超过 80 毫秒。

新要求开始

  • [C-SR-4] 对于根据 AAudioStream_getTimestamp 返回的输入和输出时间戳计算得出的往返延迟时间，强烈建议使其与 AAUDIO_PERFORMANCE_MODE_NONE 和 AAUDIO_PERFORMANCE_MODE_LOW_LATENCY 测量的往返延迟时间相差不超过 30 毫秒（针对扬声器、有线耳机和无线耳机）。

新要求结束

使用 AAudio 原生音频 API 时，如果设备实现在经过任何初始校准后满足了上述要求，对于在至少一个受支持音频输出设备上的连续输出延迟和冷输出延迟：

如果设备实现未通过 AAudio 原生音频 API 满足针对低延迟音频的要求，则：

  • [C-2-1] 不得报告对低延迟音频的支持情况。

如果设备实现包含 android.hardware.microphone，则必须满足以下针对输入音频的要求：

  • [C-3-1] 将 AudioRecord.getTimestamp 或 AAudioStream_getTimestamp 返回的输入时间戳中的误差限制在 +/- 2 毫秒内。“误差”在此是指与正确值的偏差。
  • [C-3-2] 冷输入延迟时间不超过 500 毫秒。
  • [C-3-3] 使用 AAudioStreamBuilder_openStream() 打开输入流所需的时间必须低于 1000 毫秒。

如果设备实现包含 android.hardware.microphone，强烈建议它们满足以下针对输入音频的要求：

  • [C-SR-8] 麦克风数据路径上的冷输入延迟时间不超过 100 毫秒。

  • [C-SR-11] 将 AudioRecord.getTimestamp 或 AAudioStream_getTimestamp 返回的输入时间戳中的误差限制在 +/- 1 毫秒内。

如果设备实现声明 android.hardware.audio.output 和 android.hardware.microphone，则：

  • [C-SR-12] 强烈建议在至少一条受支持路径上的 5 次测量的平均连续往返延迟不得超过 50 毫秒，平均绝对偏差低于 10 毫秒。

5.7. 网络协议

设备实现必须支持 Android SDK 文档中指定的适用于音频和视频播放的媒体网络协议。

对于设备实现必须支持的每种编解码器和容器格式，设备实现：

  • [C-1-1] 必须通过 HTTP 和 HTTPS 支持该编解码器或容器。

  • [C-1-2] 必须根据 HTTP Live Streaming 草案协议（第 7 版）支持下方“媒体段格式”表中列出的相应媒体段格式。

  • [C-1-3] 必须支持相应的 RTSP 载荷格式，如下面的 RTSP 表中所示。有关例外情况，请参阅第 5.1 节中的表格脚注。

媒体段格式

段格式 参考文献 必须支持的编解码器
MPEG-2 传输流 ISO 13818 视频编解码器：
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
请参阅第 5.1.8 节，了解有关 H264 AVC、MPEG2-4 SP
和 MPEG-2 的详细信息。

音频编解码器：

  • AAC
请参阅第 5.1.3 节，了解有关 AAC 及其变体的详细信息。
采用 ADTS 框架和 ID3 标记的 AAC ISO 13818-7 请参阅第 5.1.1 节，了解有关 AAC 及其变体的详细信息
WebVTT WebVTT

RTSP（RTP、SDP）

配置文件名称 参考文献 必须支持的编解码器
H264 AVC RFC 6184 请参阅第 5.1.8 节，了解有关 H264 AVC 的详细信息
MP4A-LATM RFC 6416 请参阅第 5.1.3 节，了解有关 AAC 及其变体的详细信息
H263-1998 RFC 3551
RFC 4629
RFC 2190 		请参阅第 5.1.8 节，了解有关 H263 的详细信息
H263-2000 RFC 4629 请参阅第 5.1.8 节，了解有关 H263 的详细信息
AMR RFC 4867 请参阅第 5.1.3 节，了解有关 AMR-NB 的详细信息
AMR-WB RFC 4867 请参阅第 5.1.3 节，了解有关 AMR-WB 的详细信息
MP4V-ES RFC 6416 请参阅第 5.1.8 节，了解有关 MPEG-4 SP 的详细信息
mpeg4-generic RFC 3640 请参阅第 5.1.3 节，了解有关 AAC 及其变体的详细信息
MP2T RFC 2250 请参阅 HTTP Live Streaming 下的 MPEG-2 传输流，了解相关详细信息

5.8. 安全媒体

如果设备实现支持安全视频输出，并且能够支持安全 Surface，则：

  • [C-1-1] 必须声明支持 Display.FLAG_SECURE。

如果设备实现声明支持 Display.FLAG_SECURE，并且支持无线显示协议，则：

  • [C-2-1] 必须采用经过加密的强大机制（例如 HDCP 2.x 或更高版本，适用于通过 Miracast 等无线协议连接的屏幕）来保护链接。

如果设备实现声明支持 Display.FLAG_SECURE，并且支持采用有线方式连接的外部屏幕，则：

  • [C-3-1] 对于通过可供用户使用的有线端口连接的所有外部屏幕，必须支持 HDCP 1.2 或更高版本。

5.9. 乐器数字接口 (MIDI)

如果设备实现通过 android.content.pm.PackageManager 类报告对 android.software.midi 功能的支持情况，则：

  • [C-1-1] 必须在为之提供常规非 MIDI 连接的所有支持 MIDI 的硬件传输方式上支持 MIDI，此类传输方式有：

  • [C-1-2] 必须支持应用间 MIDI 软件传输（虚拟 MIDI 设备）

  • [C-1-3] 必须包含 libamidi.so（原生 MIDI 支持）

  • 应通过 USB 外围设备模式支持 MIDI（第 7.7 节）

5.10. 专业音频

如果设备实现通过 android.content.pm.PackageManager 类报告对 android.hardware.audio.pro 功能的支持情况，则：

  • [C-1-1] 必须报告对 android.hardware.audio.low_latency 功能的支持情况。
  • [C-1-2] 连续往返音频延迟时间（如第 5.6 节 - 音频延迟中定义）在至少一条支持的路径上不得超过 25 毫秒。
  • [C-1-3] 必须包含支持 USB 主机模式和 USB 外围设备模式的 USB 端口。
  • [C-1-4] 必须报告对 android.software.midi 功能的支持情况。
  • [C-1-5] 必须使用 AAudio 原生音频 API 和 AAUDIO_PERFORMANCE_MODE_LOW_LATENCY 来满足延迟时间和 USB 音频方面的要求。
  • [C-1-6] 冷输出延迟时间不得超过 200 毫秒。
  • [C-1-7] 冷输入延迟时间不得超过 200 毫秒。

  • [C-1-8] 在扬声器到麦克风数据路径上的至少 5 次测量中，平均点按与发声间延迟时间不得超过 80 毫秒。

  • [C-SR-1] 强烈建议满足第 5.6 节 - 音频延迟中所定义的延迟要求，即在扬声器到麦克风路径上的 5 次测量的延迟不得超过 20 毫秒，平均绝对偏差低于 5 毫秒。

  • [C-SR-2] 强烈建议在 MMAP 路径上使用 AAudio 原生音频来满足对连续往返音频延迟、冷输入延迟和冷输出延迟的专业音频要求以及 USB 音频要求。

  • [C-SR-3] 强烈建议当音频在播放并且 CPU 负载有变化时，提供水平一致的 CPU 性能。应使用 Android 应用 SynthMark 对此进行测试。SynthMark 会使用在测量系统性能的模拟音频框架上运行的软件合成器。请参阅 SynthMark 文档，了解基准说明。SynthMark 应用需要使用“自动测试”选项运行并获得以下结果：

    • voicemark.90 >= 32 个语音
    • latencymark.fixed.little <= 15 毫秒
    • latencymark.dynamic.little <= 50 毫秒

  • 应最大限度地降低音频时钟相对于标准时间的不准确性和偏差。

  • 应最大限度地降低音频时钟相对于 CPU CLOCK_MONOTONIC 的偏差（当两者皆处于活动状态时）。

  • 应最大限度地缩短在设备内置变频器上的音频延迟。

  • 应最大限度地缩短在 USB 数字音频路径上的音频延迟。

  • 应记录在所有路径上的音频延迟时间测量结果。

  • 应最大限度地降低音频缓冲完成回调输入时间内的抖动，因为此类抖动会影响全 CPU 带宽中可供回调使用的百分比。

  • 在正常使用情况下（符合报告的延迟），不应出现音频干扰。

  • 声道间延迟时间差应为零。

  • 采用各种传输方式时，都应最大限度地缩短 MIDI 平均延迟。

  • 采用各种传输方式时，都应最大限度地降低在有负载状态下的 MIDI 延迟变化（抖动）。

  • 采用各种传输方式时，都应提供准确的 MIDI 时间戳。

  • 应最大限度地降低在设备内置变频器上的音频信号噪声，包括刚完成冷启动后一段时间内的噪声。

  • 相应端点输入侧和输出侧（当两者皆处于活动状态时）之间的音频时钟差应为零。相应端点的示例包括设备上的麦克风和扬声器，或音频插孔输入端和输出端。

  • 应在同一线程上处理相应端点输入侧和输出侧（当两者皆处于活动状态时）的音频缓冲完成回调，并在从输入回调返回后立即进入输出回调。或者，如果在同一线程上处理回调不可行，则应在进入输入回调后很快进入输出回调，以便应用在输入侧和输出侧拥有一致的时间。

  • 应最大限度地减小相应端点输入侧和输出侧 HAL 音频缓冲之间的相位差。

  • 应最大限度地缩短触摸延迟。

  • 应最大限度地降低在有负载状态下的轻触延迟时间变化（抖动）。

如果设备实现满足上述所有要求，则：

如果设备实现包含 4 导体 3.5 毫米音频耳机插孔，则：

如果设备实现省略 4 导体 3.5 毫米音频插孔，并且包含支持 USB 主机模式的 USB 端口，则：

  • [C-3-1] 必须实现 USB 音频类。
  • [C-3-2] 使用 USB 音频类时，在 USB 主机模式端口上的 5 次测量的平均连续往返音频延迟不得超过 25 毫秒，平均绝对偏差低于 5 毫秒。（可以使用 USB-3.5 毫米适配器和音频环回适配器进行测量，也可以使用配备用于连接输入端和输出端的跳线的 USB 音频接口进行测量）。
  • [C-SR-6] 与同样支持这些要求的 USB 音频外围设备结合使用时，强烈建议支持每个方向最多 8 个声道的同时 I/O、96 kHz 采样率和 24 位或 32 位深。
  • [C-SR-7] 强烈建议在 MMAP 路径上使用 AAudio 原生音频 API 来满足这组要求。

如果设备实现包含 HDMI 端口，则：

  • 应在至少一种配置中支持频率为 192 kHz、位深为 20 或 24 的八声道立体声输出，而不丢失位深或重新采样。

5.11. 捕获未处理音频源

Android 支持通过 android.media.MediaRecorder.AudioSource.UNPROCESSED 音频源录制未处理音频。在 OpenSL ES 中，可以使用录制预设 SL_ANDROID_RECORDING_PRESET_UNPROCESSED 来访问这些音频。

如果设备实现打算支持未处理音频源，并使其可供第三方应用使用，则：

  • [C-1-1] 必须通过 android.media.AudioManager 属性 PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED 报告这一支持情况。

  • [C-1-2] 对于每个用于对未处理音频源进行录音的麦克风，在中频范围内必须表现出大致平坦的幅频特性，具体来说就是：±10 dB (100 Hz - 7000 Hz)。

  • [C-1-3] 对于每个用于对未处理音频源进行录音的麦克风，在低频范围内必须表现出适当的振幅等级，具体来说就是：±20 dB (5 Hz - 100 Hz)（与中频范围相比）。

  • [C-1-4] 对于每个用于对未处理音频源进行录音的麦克风，在高频范围内必须表现出适当的振幅等级，具体来说就是：±30 dB (7000 Hz - 22 KHz)（与中频范围相比）。

  • [C-1-5] 对于每个用于对未处理音频源进行录音的麦克风，必须设置适当的音频输入敏感度，以确保对于 16 位的样本，以 94 dB 声压级 (SPL) 播放的 1000 Hz 正弦音调源会产生 RMS 为 520 的响应（或对于浮点/双精度样本，为 -36 dB 全标度）。

  • [C-1-6] 对于每个用于对未处理音频源进行录音的麦克风，信噪比 (SNR) 不得低于 60 dB（SNR 按照 94 dB SPL 和等效 SPL 自噪声之间的差异进行衡量，A 加权）。

  • [C-1-7] 对于每个用于对未处理音频源进行录音的麦克风，在频率为 1 kHZ、输入声压级为 90 dB SPL 时，总谐波畸变率必须小于 1%。

  • [C-1-8] 除了用于将声压级提升到所需范围的声压级倍增器之外，路径中不得有任何其他信号处理机制（例如自动增益控制、高通滤波器或回声消除）。也就是说：

    • [C-1-9] 无论架构中出于任何原因而存在信号处理机制，此类机制都必须处于停用状态，并能够有效避免在信号路径中引入任何延迟。
    • [C-1-10] 虽然路径中允许存在声压级倍增器，但该倍增器不得在信号路径中引入延迟。

所有 SPL 测量都直接在接受测试的麦克风旁进行。对于多麦克风配置，这些要求适用于每个麦克风。

如果设备实现声明 android.hardware.microphone，但不支持未处理音频源，则：

  • [C-2-1] 必须针对 AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) API 方法返回 null，以适当指明不支持未处理音频源。
  • [C-SR-1] 仍强烈建议尽可能多地满足未处理录音来源信号路径方面的要求。

5.12. HDR 视频

如即将发布的文档中所述，Android 13 支持 HDR 技术。

像素格式

如果视频解码器通告支持 COLOR_FormatYUVP010，则：

  • [C-1-1] CPU-read（ImageReader、MediaImage、ByteBuffer）必须支持 P010 格式。在 Android 13 中，对 P010 的要求放宽，允许 Y 平面和 UV 平面使用任意步长。

  • [C-1-2] GPU 必须能够对 P010 输出缓冲区采样（使用 GPU_SAMPLING 分配时）。这样就能按应用进行 GPU 合成和自定义色调映射。

如果视频解码器通告支持 COLOR_Format32bitABGR2101010，则：

  • [C-2-1] 输出 Surface 和 CPU-readable（ByteBuffer 输出）必须支持 RGBA_1010102 格式。

如果视频编码器通告支持 COLOR_FormatYUVP010，则：

  • [C-3-1] 输入 Surface 和 CPU-writeable（ImageWriter、MediaImage、ByteBuffer）输入必须支持 P010 格式。

如果视频编码器通告支持 COLOR_Format32bitABGR2101010，则：

  • [C-4-1] 输入 Surface 和 CPU-writeable（ImageWriter、ByteBuffer）输入必须支持 RGBA_1010102 格式。注意：编码器不需要在不同转换曲线之间转换。

HDR 拍摄要求

对于所有支持 HDR 配置的视频编码器，设备实现：

  • [C-5-1] 不得假设 HDR 元数据是精确的。例如，经过编码后帧的像素可能会高于峰值亮度水平，或者直方图可能无法代表帧。

  • 应聚合 HDR 动态元数据，为编码流生成相应的 HDR 静态元数据，并应在每个编码会话结束时将其输出。

如果设备实现支持使用 CamcorderProfile API 拍摄 HDR 视频，则：

  • [C-6-1] 还必须支持通过 Camera2 API 拍摄 HDR 视频。

  • [C-6-2] 对于支持的每种 HDR 技术，必须至少支持一种硬件加速视频编码器。

  • [C-6-3] 必须至少支持 HLG 拍摄。

  • [C-6-4] 必须支持将 HDR 元数据（如果适用于 HDR 技术）写入捕获的视频文件中。对于 AV1、HEVC 和 DolbyVision，这意味着将元数据添加到编码比特流中。

  • [C-6-5] 必须支持 P010 和 COLOR_FormatYUVP010。

  • [C-6-6] 对于捕获的配置，默认硬件加速解码器必须支持 HDR 到 SDR 色调映射。换言之，如果设备可以拍摄 HDR10+ HEVC，默认的 HEVC 解码器就必须能够解码 SDR 中捕获的视频流。

HDR 编辑要求

如果设备实现包含支持 HDR 编辑的视频编码器，则：

  • 在生成不存在的 HDR 元数据时，应尽量缩短延迟时间；并应妥善处理某些帧存在元数据而其他帧不存在元数据的情况。这些元数据应精确（例如，能代表帧的实际峰值亮度和直方图）。

如果设备实现包含支持 FEATURE_HdrEditing 的编解码器，这些编解码器：

  • [C-7-1] 必须至少支持一个 HDR 配置。

  • [C-7-2] 必须支持该编解码器通告的所有 HDR 配置文件的 FEATURE_HdrEditing。换言之，对于支持的所有使用 HDR 元数据的 HDR 配置文件，设备实现必须支持生成不存在的 HDR 元数据。

  • [C-7-3] 必须针对输入 Surface 和 ByteBuffer 支持以下完全保留 HDR 解码信号的视频编码器输入格式：

    • RGBA_1010102（已在目标转换曲线中），并且必须通告支持 COLOR_Format32bitABGR2101010。

如果设备实现包含支持 FEATURE_HdrEditing 的编解码器，该设备：

  • [C-7-4] 必须通告对 EXT_YUV_target OpenGL 扩展的支持。

6. 开发者工具和选项兼容性

6.1. 开发者工具

设备实现：

  • [C-0-1] 必须支持 Android SDK 中提供的 Android 开发者工具。

  • Android 调试桥 (adb)

    • [C-0-2] 必须支持 adb（如 Android SDK 中所述）和 AOSP 中提供的 shell 命令（可供应用开发者使用，包括 dumpsys cmd stats）
    • [C-0-11] 必须支持 shell 命令 cmd testharness。从没有持久性数据块的早期 Android 版本升级设备实现无需遵守 C-0-11 要求。
    • [C-0-3] 不得更改通过 dumpsys 命令记录的设备系统事件（batterystats、diskstats、fingerprint、graphicsstats、netstats、notification、procstats）的格式或内容。
    • [C-0-10] 记录时不得有任何遗漏，并使以下事件可供 cmd stats shell 命令和 StatsManager 系统 API 类访问和使用。
      • ActivityForegroundStateChanged
      • AnomalyDetected
      • AppBreadcrumbReported
      • AppCrashOccurred
      • AppStartOccurred
      • BatteryLevelChanged
      • BatterySaverModeStateChanged
      • BleScanResultReceived
      • BleScanStateChanged
      • ChargingStateChanged
      • DeviceIdleModeStateChanged
      • ForegroundServiceStateChanged
      • GpsScanStateChanged
      • JobStateChanged
      • PluggedStateChanged
      • ScheduledJobStateChanged
      • ScreenStateChanged
      • SyncStateChanged
      • SystemElapsedRealtime
      • UidProcessStateChanged
      • WakelockStateChanged
      • WakeupAlarmOccurred
      • WifiLockStateChanged
      • WifiMulticastLockStateChanged
      • WifiScanStateChanged
    • [C-0-4] 必须使设备侧 adb 守护程序默认处于停用状态，并有一个可供用户使用的 Android 调试桥开启机制。
    • [C-0-5] 必须支持安全 adb。Android 支持安全 adb。安全 adb 能够在经过身份验证的已知主机上启用 adb。
    • [C-0-6] 必须提供可从宿主机连接 adb 的机制。具体而言：

    如果设备实现没有 USB 端口支持外围设备模式，则：

    • [C-3-1] 必须通过局域网（例如以太网或 Wi-Fi）实现 adb。
    • [C-3-2] 必须提供适用于 Windows 7、8 和 10 的驱动程序，以便开发者使用 adb 协议连接到设备。

    如果设备实现支持通过 Wi-Fi 或以太网连接到宿主机的 adb 连接，则：

    • [C-4-1] 必须使 AdbManager#isAdbWifiSupported() 方法返回 true。

    如果设备实现支持通过 Wi-Fi 或以太网连接到宿主机的 adb 连接，并且至少包含一个摄像头，则：

    • [C-5-1] 必须使 AdbManager#isAdbWifiQrSupported() 方法返回 true。

  • Dalvik 调试监控服务 (ddms)

    • [C-0-7] 必须支持 Android SDK 中所述的所有 ddms 功能。由于 ddms 会使用 adb，因此虽然对 ddms 的支持应默认处于停用状态，但如果用户启用了 Android 调试桥，就必须支持 ddms，如上所述。

  • SysTrace

    • [C-0-9] 必须支持 Android SDK 中所述的 Systrace 工具。Systrace 必须默认处于停用状态，并有一个可供用户使用的 Systrace 开启机制。

  • Perfetto

    • [C-SR-1] 强烈建议向 shell 用户公开 /system/bin/perfetto 二进制文件，且 cmdline 符合 perfetto 文档要求。
    • [C-SR-2] 强烈建议 perfetto 二进制文件接受符合 perfetto 文档中定义的架构的 protobuf 配置作为输入。
    • [C-SR-3] 强烈建议 perfetto 二进制文件写入符合 perfetto 文档中定义的架构的 protobuf 轨迹作为输出。
    • [C-SR-4] 强烈建议通过 perfetto 二进制文件至少提供 perfetto 文档中所述的数据源。

  • 低内存终止守护程序

    • [C-0-12] 当某个应用被低内存终止守护程序终止时，必须向 statsd 日志写入一个 LMK_KILL_OCCURRED_FIELD_NUMBER Atom。

  • 自动化测试框架模式 如果设备实现支持 shell 命令 cmd testharness 并运行 cmd testharness enable，则：

    • [C-2-1] 必须针对 ActivityManager.isRunningInUserTestHarness() 返回 true
    • [C-2-2] 必须实现自动化测试框架模式（如自动化测试框架模式文档中所述）。

  • GPU 工作信息

    设备实现：

    • [C-0-13] 必须实现 shell 命令 dumpsys gpu --gpuwork 以显示由 power/gpu_work_period 内核跟踪点返回的聚合 GPU 工作数据；或者，如果不支持跟踪点，则不显示任何数据。AOSP 实现为 frameworks/native/services/gpuservice/gpuwork/。

如果设备实现通过 android.hardware.vulkan.version 功能标志报告支持 Vulkan 1.0 或更高版本，则：

  • [C-1-1] 必须提供一种方式，让应用开发者能够启用/停用 GPU 调试层。
  • [C-1-2] 必须在启用 GPU 调试层时，在可调试应用的基本目录下的外部工具（并非平台或应用软件包的组成部分）提供的库中枚举层，以支持 vkEnumerateInstanceLayerProperties() 和 vkCreateInstance() API 方法。

6.2. 开发者选项

Android 支持开发者配置与应用开发相关的设置。

设备实现必须提供一致的开发者选项体验，它们：

  • [C-0-1] 必须遵从 android.settings.APPLICATION_DEVELOPMENT_SETTINGS intent，以显示与应用开发相关的设置。上游 Android 实现会默认隐藏“开发者选项”菜单，并允许用户启动该菜单（方法是在设置 > 关于设备 > build 号菜单项上连按七 (7) 次）。
  • [C-0-2] 必须默认隐藏“开发者选项”。
  • [C-0-3] 必须提供一种明确的机制，在启用“开发者选项”方面某个第三方应用的优先级不会高于另一个第三方应用。必须提供描述如何启用“开发者选项”的公开文档或网站。必须可从 Android SDK 文档链接到此文档或网站。
  • 应在启用“开发者选项”且需要考虑用户安全的情况下，向用户显示一直可见的通知。
  • 对于需要考虑用户安全的情况，可以暂时限制访问“开发者选项”菜单（方法是在视觉上隐藏或停用该菜单），以避免分散注意力。

7. 硬件兼容性

如果设备包含的某个硬件组件具有针对第三方开发者的对应 API，则：

  • [C-0-1] 设备实现必须按照 Android SDK 文档中所述实现该 API。

如果 SDK 中的某个 API 需要与某个被规定为可选组件的硬件组件互动，但设备实现不具备该组件，则：

  • [C-0-2] 仍必须提供该组件 API 的完整类定义（如 SDK 中所述）。
  • [C-0-3] 必须以某种合理的方式将该 API 的行为实现为空操作。
  • [C-0-4] 在 SDK 文档允许的情况下，该 API 的方法必须返回 null 值。
  • [C-0-5] 在 SDK 文档不允许 null 值的情况下，该 API 的方法必须返回相应类的空操作实现。
  • [C-0-6] 该 API 的方法不得抛出 SDK 文档中未载述的异常。
  • [C-0-7] 对于相同的 build 指纹，设备实现必须能够始终如一地通过 android.content.pm.PackageManager 类中的 getSystemAvailableFeatures() 和 hasSystemFeature(String) 方法报告准确的硬件配置信息。

这些要求的适用情境的一个典型示例是电话 API：即使在非手机设备上，这些 API 也必须作为合理的空操作来实现。

7.1. 显示和图形

Android 包含一些能够适当地为设备自动调整应用资产和界面布局的方式，以确保第三方应用能够在各种硬件配置各种硬件屏幕和配置上良好地运行。Android 兼容屏幕是指会实现 Android 开发者 - 屏幕兼容性概览、本节 (7.1) 及其子节中描述的所有行为和 API 以及本 CDD 第 2 节中记录的任何其他设备类型特定行为的显示屏。 在所有与 Android 兼容的第三方应用可运行的 Android 兼容屏幕上，设备实现必须正确实现这些 API 和行为（本节中对此进行了详细说明）。

新要求开始

设备实现：

  • [C-0-1] 必须默认仅在与 Android 兼容的屏幕上呈现第三方应用。

新要求结束

本节的要求中提到的单位定义如下：

  • 物理对角线尺寸：屏幕亮显部分的两个对角之间的距离（以英寸为单位）。
  • 每英寸点数 (dpi)密度：1 英寸的线性水平或垂直跨度内包含的像素数，以每英寸像素数（ppi 或 dpi）表示。如果列出了 dpippi 和 dpi 值，则水平 dpi 和垂直 dpi 都必须在列出的范围内。
  • 宽高比：屏幕的长度像素与宽度像素之比。例如，480x854 像素的屏幕的宽高比是 854/480 = 1.779，或约为“16:9”。
  • 密度无关像素 (dp)：按 160 dpi 屏幕160 的屏幕密度标准化的虚拟像素单位。对于某些密度 d 和像素数 p，密度无关像素 dp 的数量的计算公式如下：像素 = dps *（密度/160）dp = (160/d) * p。

7.1.1. 屏幕配置

7.1.1.1. 屏幕尺寸和形状

Android 界面框架支持多种不同的逻辑屏幕布局尺寸，并且允许应用通过 Configuration.screenLayout（使用 SCREENLAYOUT_SIZE_MASK 和 Configuration.smallestScreenWidthDp 参数）查询当前配置的屏幕布局尺寸。

设备实现：

  • [C-0-1] 必须针对 Configuration.screenLayout 报告正确的布局尺寸（如 Android SDK 文档中所定义）。具体而言，设备实现必须报告正确的密度无关像素 (dp) 逻辑屏幕尺寸，如下所述：

    • 如果设备的 Configuration.uiMode 设置为除 UI_MODE_TYPE_WATCH 以外的任何值，并且针对 Configuration.screenLayout 报告的是 small 尺寸，该屏幕尺寸必须至少为 426 dp x 320 dp。
    • 如果设备针对 Configuration.screenLayout 报告的是 normal 尺寸，该屏幕尺寸必须至少为 480 dp x 320 dp。
    • 如果设备针对 Configuration.screenLayout 报告的是 large 尺寸，该屏幕尺寸必须至少为 640 dp x 480 dp。
    • 如果设备针对 Configuration.screenLayout 报告的是 xlarge 尺寸，该屏幕尺寸必须至少为 960 dp x 720 dp。

  • [C-0-2] 必须正确遵从应用通过 AndroidManifest.xml 中的 <supports-screens> 属性声明的屏幕尺寸支持情况（如 Android SDK 文档中所述）。

  • 可具有带圆角的 Android 兼容屏幕。

如果设备实现支持能够使用 UI_MODE_TYPE_NORMAL 尺寸配置的屏幕并包含与 Android 兼容的使用实体圆角屏幕呈现这些屏幕，则：

  • [C-1-1] 对于每个此类屏幕，必须确保至少满足以下某一项要求：

    • 圆角的半径小于或等于 38 dp。
    • 如果逻辑显示屏的每个角上都固定了一个 1518 dp x 1518 dp 框，每个框应至少有 1 个像素在屏幕上可见。

  • 应提供一种方式，让用户能够切换为矩形角显示模式。

新要求开始

如果设备实现只能支持 NO_KEYS 键盘配置，并且打算报告对 UI_MODE_TYPE_NORMAL 界面模式配置的支持，则：

  • [C-4-1] 布局尺寸（不包括刘海屏）不得小于 596 dp x 384 dp。

新要求结束

如果设备实现包含可折叠的 Android 兼容屏幕，或在多个显示面板之间放置了一个折叠合页，并使此类屏幕可用于呈现第三方应用，则：

如果设备实现包含可折叠的 Android 兼容屏幕，或在多个显示面板之间放置了一个折叠合页，并且该合页或折叠边跨越全屏应用窗口，则：

  • [C-3-1] 必须通过扩展或 Sidecar API 向应用报告合页或折叠边的位置、边界和状态。

如需详细了解如何正确实现 Sidecar 或扩展 API，请参阅有关 Window Manager Jetpack 的公开文档。

新要求开始

如果设备实现包含一个或多个可折叠的 Android 兼容显示区域，或在多个与 Android 兼容的显示面板区域之间放置了一个折叠合页，并使此类显示区域可供应用使用，则：

  • [C-4-1] 必须实现正确版本的 Window Manager Extensions API 级别（如 WindowManager 扩展中所述）。

新要求结束

7.1.1.2. 屏幕宽高比

虽然对 Android 兼容屏幕的实体屏幕的屏幕宽高比值没有任何限制，但用于呈现第三方应用的逻辑屏幕的屏幕宽高比（可以根据通过 view.Display API 和 Configuration API 报告的高度值和宽度值推导出来）必须满足以下要求：

  • [C-0-1] 如果设备实现的 Configuration.uiMode 设置为 UI_MODE_TYPE_NORMAL，宽高比必须小于或等于 1.86（约为 16:9），除非应用满足下列某个条件：

  • [C-0-3] 如果设备实现的 Configuration.uiMode 设置为 UI_MODE_TYPE_WATCH，宽高比值必须设置为 1.0 (1:1)。

7.1.1.3. 屏幕密度

Android 界面框架定义了一组标准逻辑密度，以便应用开发者确定要采用的应用资源。

设备实现：

  • [C-0-1] 默认情况下，设备实现必须仅报告通过 DENSITY_DEVICE_STABLE API 在 DisplayMetrics 中列出的其中一种 Android 框架密度，并且此值必须是每个实体屏幕的静态值。在任何时间此值都必须保持不变；不过，不过，设备可以根据初始启动后用户对显示配置（例如显示大小）所做的更改报告不同的任意密度 DisplayMetrics.density。

  • 设备实现应定义数值最接近屏幕物理密度的标准 Android 框架密度，除非该逻辑密度会导致报告的屏幕尺寸低于支持的最小值。如果数值最接近物理密度的标准 Android 框架密度会导致屏幕尺寸小于支持的最小兼容屏幕尺寸（宽度为 320 dp），设备实现应报告下一个最低的标准 Android 框架密度。

新要求开始

  • 应定义数值最接近屏幕物理密度的标准 Android 框架密度，或与手持设备的相同等效角度视野范围测量值相对应的值。

新要求结束

如果设备实现提供有用于一种用于更改设备显示区域大小的方式，则：

  • [C-1-1] 不得将显示区域大小调整为任何显示屏的缩放不得超过 DENSITY_DEVICE_STABLE 原生密度1.5 倍的尺寸，也不得产生小于 320 dp（相当于资源限定尺寸为 sw320dp）的有效最小屏幕尺寸，以先达到者为准。
  • [C-1-2] 不得将显示区域大小调整为任何显示屏的缩放不得小于 DENSITY_DEVICE_STABLE 原生密度0.85 倍的尺寸。
  • 为了确保良好的可用性和一致的字体大小，建议提供以下原生显示缩放比例选项（同时遵守上述限制）
    • 小：0.85 倍
    • 默认值：1 倍（原生显示比例）
    • 大：1.15 倍
    • 较大：1.3 倍
    • 最大：1.45 倍

7.1.2. 显示指标

如果设备实现包含 Android 兼容屏幕或 Android 兼容显示屏幕的视频输出机制，则：

如果设备实现不包含嵌入式屏幕或视频输出机制，则：

  • [C-2-1] 必须报告 Android 兼容屏幕的正确值（如 android.util.DisplayMetrics API 中针对模拟的默认 view.Display 所定义）。

7.1.3. 屏幕方向

设备实现：

  • [C-0-1] 必须报告支持的屏幕方向（android.hardware.screen.portrait 和/或 android.hardware.screen.landscape），并且必须报告至少一个支持的方向。例如，屏幕固定为横向的设备（例如电视或笔记本电脑）应仅报告 android.hardware.screen.landscape。
  • [C-0-2] 每当收到通过 android.content.res.Configuration.orientation、android.view.Display.getOrientation() 或其他 API 提交的查询时，必须报告设备当前方向的正确值。

如果设备实现支持两种屏幕方向，则：

  • [C-1-1] 必须支持按应用动态设置屏幕方向（纵向或横向）。也就是说，设备必须遵从应用对特定屏幕方向的要求。
  • [C-1-2] 更改方向时，不得更改报告的屏幕尺寸或密度。
  • 可以选择纵向或横向作为默认方向。

7.1.4. 2D 和 3D 图形加速

7.1.4.1 OpenGL ES

设备实现：

  • [C-0-1] 必须通过受管理 API（例如通过 GLES10.getString() 方法）和原生 API 正确识别支持的 OpenGL ES 版本（1.1、2.0、3.0、3.1、3.2）。
  • [C-0-2] 对于标识为支持的每个 OpenGL ES 版本，必须支持所有对应的受管理 API 和原生 API。

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

  • [C-1-1] 必须同时支持 OpenGL ES 1.1 和 2.0，Android SDK 文档对此进行了详细阐述。
  • [C-SR-1] 强烈建议支持 OpenGL ES 3.1。
  • 应支持 OpenGL ES 3.2。

OpenGL ES dEQP 测试分为多个测试列表，每个测试列表都有关联的日期/版本号。这些位于 Android 源代码树的 external/deqp/android/cts/main/glesXX-main-YYYY-MM-DD.txt 中。如果设备在自行报告级别上支持 OpenGL ES，则表示它可以通过所有测试列表中这个级别及更早级别的 dEQP 测试。

如果设备实现支持任何 OpenGL ES 版本，则：

  • [C-2-1] 必须通过 OpenGL ES 受管理 API 和原生 API 报告已实现的所有其他 OpenGL ES 扩展；反过来说就是，不得报告不支持的扩展字符串。
  • [C-2-2] 必须支持 EGL_KHR_image、EGL_KHR_image_base、EGL_ANDROID_image_native_buffer、EGL_ANDROID_get_native_client_buffer、EGL_KHR_wait_sync、EGL_KHR_get_all_proc_addresses、EGL_ANDROID_presentation_time、EGL_KHR_swap_buffers_with_damage、EGL_ANDROID_recordable 和 EGL_ANDROID_GLES_layers 扩展。
  • [C-2-3] 必须通过 android.software.opengles.deqp.level 功能标志报告支持的 OpenGL ES dEQP 测试版本上限。
  • [C-2-4] 必须至少支持 android.software.opengles.deqp.level 功能标志中报告的版本 132383489（自 2020 年 3 月 1 日起）。
  • [C-2-5] 对于每个支持的 OpenGL ES 版本，必须通过测试列表中版本 132383489 与 android.software.opengles.deqp.level 功能标志中指定的版本之间的所有 OpenGL ES dEQP 测试。
  • [C-SR-2] 强烈建议支持 EGL_KHR_partial_update 和 OES_EGL_image_external 扩展。

  • 应通过 getString() 方法准确报告支持的所有纹理压缩格式，这些格式通常是针对特定供应商的。

  • 应支持 EGL_IMG_context_priority 和 EGL_EXT_protected_content 扩展。

如果设备实现声明支持 OpenGL ES 3.0、3.1 或 3.2，则：

  • [C-3-1] 除了导出 libGLESv2.so 库中的 OpenGL ES 2.0 函数符号之外，还必须导出这些版本的对应函数符号。
  • [C-SR-3] 强烈建议支持 OES_EGL_image_external_essl3 扩展。

如果设备实现支持 OpenGL ES 3.2，则：

  • [C-4-1] 必须支持整个 OpenGL ES Android Extension Pack。

如果设备实现支持整个 OpenGL ES Android Extension Pack，则：

  • [C-5-1] 必须通过 android.hardware.opengles.aep 功能标志标识此项支持。

如果设备实现通告支持 EGL_KHR_mutable_render_buffer 扩展，则：

  • [C-6-1] 还必须支持 EGL_ANDROID_front_buffer_auto_refresh 扩展。
7.1.4.2 Vulkan

Android 支持 Vulkan。Vulkan 是一个适用于高性能 3D 图形的低开销、跨平台 API。

如果设备实现支持 OpenGL ES 3.1，则：

  • [C-SR-1] 强烈建议支持 Vulkan 1.3。
  • [C-4-1] 不得支持 Vulkan 变体版本（即 Vulkan 核心版本的变体部分必须为零）。

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

  • [C-SR-2] 强烈建议支持 Vulkan 1.3。

Vulkan dEQP 测试分为多个测试列表，每个测试列表都有关联的日期/版本。这些位于 Android 源代码树的 external/deqp/android/cts/main/vk-main-YYYY-MM-DD.txt 中。如果设备在自行报告级别上支持 Vulkan，则表示它可以通过所有测试列表中这个级别及更早级别的 dEQP 测试。

如果设备实现支持 Vulkan 1.0 或更高版本，则：

  • [C-1-1] 必须通过 android.hardware.vulkan.level 和 android.hardware.vulkan.version 功能标志报告正确的整数值。
  • [C-1-2] 必须针对 Vulkan 原生 API vkEnumeratePhysicalDevices() 至少枚举一个 VkPhysicalDevice。
  • [C-1-3] 必须针对枚举的每个 VkPhysicalDevice 完整实现 Vulkan 1.0Vulkan 1.1 API。
  • [C-1-4] 必须通过 Vulkan 原生 API vkEnumerateInstanceLayerProperties() 和 vkEnumerateDeviceLayerProperties() 枚举名为 libVkLayer*.so 的原生库（位于应用包的原生库目录下）中包含的层。
  • [C-1-5] 不得枚举应用软件包外的库提供的层，也不得提供其他方式来跟踪或拦截 Vulkan API，除非应用的 android:debuggable 属性设置为 true 或元数据 com.android.graphics.injectLayers.enable 设置为 true。
  • [C-1-6] 必须通过 Vulkan 原生 API 报告支持的所有扩展字符串；反过来说就是，不得报告无法正确支持的扩展字符串。
  • [C-1-7] 必须支持 VK_KHR_surface、VK_KHR_android_surface、VK_KHR_swapchain 和 VK_KHR_incremental_present 扩展。
  • [C-1-8] 必须通过 android.software.vulkan.deqp.level 功能标志报告支持的 Vulkan dEQP 测试的最高版本。
  • [C-1-9] 必须至少支持 android.software.vulkan.deqp.level 功能标志中报告的版本 132317953（自 2019 年 3 月 1 日起）。
  • [C-1-10] 必须通过测试列表中版本 132317953 与 android.software.vulkan.deqp.level 功能标志中指定的版本之间的所有 Vulkan dEQP 测试。
  • [C-1-11] 不得枚举对 VK_KHR_video_queue、VK_KHR_video_decode_queue 或 VK_KHR_video_encode_queue 扩展的支持情况。
  • [C-SR-3] 强烈建议支持 VK_KHR_driver_properties 和 VK_GOOGLE_display_timing 扩展。

  • 应支持 VkPhysicalDeviceProtectedMemoryFeatures 和 VK_EXT_global_priority。

  • [C-1-12] 不得枚举对 VK_KHR_performance_query 扩展的支持。

新要求开始

新要求结束

新要求开始

  • [C-SR-5] 强烈建议支持 VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory 和 VK_EXT_global_priority。

  • [C-SR-6] 强烈建议将 SkiaVk 与 HWUI 搭配使用。

新要求结束

如果设备实现不支持 Vulkan 1.0，则：

  • [C-2-1] 不得声明任何 Vulkan 功能标志（例如 android.hardware.vulkan.level 和 android.hardware.vulkan.version）。
  • [C-2-2] 不得针对 Vulkan 原生 API vkEnumeratePhysicalDevices() 枚举任何 VkPhysicalDevice。

如果设备实现支持 Vulkan 1.1 并声明此处所述的任一 Vulkan 功能标志，则：

  • [C-3-1] 必须公开对 SYNC_FD 外部信号量和句柄类型以及 VK_ANDROID_external_memory_android_hardware_buffer 扩展的支持情况。

新要求开始

  • [C-SR-7] 强烈建议使 VK_KHR_external_fence_fd 扩展可供第三方应用使用，并允许应用将栅栏载荷导出到 POSIX 文件描述符中以及从 POSIX 文件描述符中导入栅栏载荷，如此处所述。

新要求结束

7.1.4.3 RenderScript
  • [C-0-1] 设备实现必须支持 Android RenderScript（Android SDK 文档中对此进行了详细说明）。
7.1.4.4 2D 图形加速

Android 包含一种机制，可让应用使用清单标记 android:hardwareAccelerated 或直接 API 调用声明希望在应用、activity、窗口或视图级别启用 2D 图形硬件加速。

设备实现：

  • [C-0-1] 必须默认启用硬件加速；如果开发者通过以下方式请求停用硬件加速，设备实现必须将其停用：设置 android:hardwareAccelerated="false”，或直接通过 Android View API 停用硬件加速。
  • [C-0-2] 表现出的行为必须与 Android SDK 文档中关于硬件加速的说明一致。

Android 包含一个 TextureView 对象，可让开发者直接将经过硬件加速的 OpenGL ES 纹理作为呈现目标集成到界面层次结构中。

设备实现：

  • [C-0-3] 必须支持 TextureView API，并且表现出的行为必须与上游 Android 实现一致。
7.1.4.5 广色域屏幕

如果设备实现声明通过 Configuration.isScreenWideColorGamut() 支持广色域屏幕，则：

  • [C-1-1] 必须有颜色经过校准的显示屏。
  • [C-1-2] 必须有色域完整涵盖 CIE 1931 xyY 空间内 sRGB 色域的屏幕。
  • [C-1-3] 必须有色域至少涵盖 CIE 1931 xyY 空间内 90% DCI-P3 色域的屏幕。
  • [C-1-4] 必须支持 OpenGL ES 3.1 或 3.2，并正确报告此项支持。
  • [C-1-5] 必须通告对 EGL_KHR_no_config_context、EGL_EXT_pixel_format_float、EGL_KHR_gl_colorspace、EGL_EXT_gl_colorspace_scrgb、EGL_EXT_gl_colorspace_scrgb_linear、EGL_EXT_gl_colorspace_display_p3、EGL_EXT_gl_colorspace_display_p3_linear 和 EGL_EXT_gl_colorspace_display_p3_passthrough 扩展的支持情况。
  • [C-SR-1] 强烈建议支持 GL_EXT_sRGB。

反之，如果设备实现不支持广色域显示屏，则：

  • [C-2-1] 尽管并未定义屏幕色域，但应涵盖 CIE 1931 xyY 空间内 100% 或更多的 sRGB。

7.1.5. 旧应用兼容模式

Android 指定了一种“兼容模式”，在该模式下，框架能够以与“标准”屏幕尺寸等效的模式（宽度为 320dp）运行，这是为了服务于不是针对旧版 Android（在实现屏幕尺寸独立性之前发布的旧版 Android）开发的旧应用。

7.1.6. 屏幕技术

Android 平台包含一些可让应用在 Android 兼容屏幕上呈现丰富图形的 API。除非本文档中明确许可，否则设备必须支持 Android SDK 定义的所有这些 API。

设备实现的所有 Android 兼容屏幕：

  • [C-0-1] 必须能够呈现 16 位彩色图形。
  • 应支持能够呈现 24 位彩色图形的显示屏。
  • [C-0-2] 必须能够呈现动画。
  • [C-0-3] 像素宽高比 (PAR) 必须介于 0.9 到 1.15 之间。也就是说，像素宽高比必须接近方形 (1.0)，并且公差在 10-15% 的范围内。

7.1.7. 辅助显示屏

Android 支持用于实现媒体共享功能的辅助 Android 兼容屏幕以及用于访问外部屏幕的开发者 API。

如果设备实现支持采用有线、无线或嵌入式附加显示屏连接方式的外接显示屏，则：

  • [C-1-1] 必须实现 DisplayManager 系统服务和 API（如 Android SDK 文档中所述）。

7.2. 输入设备

设备实现：

7.2.1. 键盘

如果设备实现支持第三方输入法 (IME) 应用，则：

设备实现：

  • [C-0-1] 不得包含与 android.content.res.Configuration.keyboard 中指定的任何格式（QWERTY 或 12 键）都不匹配的硬件键盘。
  • 应包含额外的软键盘实现。
  • 可以包含硬件键盘。

7.2.2. 非触摸导航

Android 支持使用方向键、轨迹球和滚轮作为机制进行非触摸导航。

设备实现：

如果设备实现缺少非触摸导航，则：

  • [C-1-1] 必须提供一个与输入管理引擎兼容且合理的替代界面机制，以便用户选择和编辑文字。上游 Android 开放源代码实现包含一种适合在缺少非触摸导航输入法的设备上使用的选择机制。

7.2.3. 导航键

主屏幕、最近用过和返回功能（通常在用户与专用的实体按钮或触摸屏上的单独部分互动后提供）是 Android 导航范式的基本组成部分，因此，设备实现：

  • [C-0-1] 必须提供一种方式，让用户能够启动具有满足以下条件的 activity 的安装式应用：对于 TV 设备实现，<intent-filter> 设置为 ACTION=MAIN 和 CATEGORY=LAUNCHER 或 CATEGORY=LEANBACK_LAUNCHER。“主屏幕”功能应是提供此方式的机制。
  • 应为“最近用过”和“返回”功能提供相应的按钮。

如果提供了“主屏幕”“最近用过”或“返回”功能，则：

  • [C-1-1] 当其中任何功能处于可供访问状态时，都必须可通过单次操作（例如点按、双击或手势）访问。
  • [C-1-2] 必须明确指明各个单次操作会触发哪项功能。常见的指明方式示例包括：在按钮上印制可见图标、在屏幕的导航栏部分显示软件图标，或在开箱设置期间引导用户完成分步演示流程。

设备实现：

  • [C-SR-1] 强烈建议不要为“菜单”功能提供输入机制。因为从 Android 4.0 开始，由于操作栏的出现，“菜单”功能被废弃了。

  • [C-SR-2] 强烈建议将所提供的所有导航功能都设为可取消。“可取消”定义为如果滑动手势未在超出特定阈值的时间后松开，系统就不会执行相应导航功能（例如返回主屏幕、返回等）。

如果设备实现提供“菜单”功能，则：

  • [C-2-1] 当操作溢出菜单弹出窗口不为空且操作栏处于可见状态时，必须显示操作溢出按钮。
  • [C-2-2] 对于在操作栏中选择溢出按钮后显示的操作溢出弹出式窗口，不得修改其位置。但对于在选择“菜单”功能后显示的操作溢出弹出式窗口，可以在屏幕上将其呈现到修改后的位置。

如果设备实现未提供用于实现向后兼容性的“菜单”功能，则：* [C-3-1] 当 targetSdkVersion 小于 10 时，必须使该“菜单”功能可供应用使用（通过实体按钮、软件键或手势）。此“菜单”功能应可供访问，除非与其他导航功能一起隐藏起来。

如果设备实现提供“辅助”功能，则：

  • [C-4-1] 当其他导航键可供访问时，必须使该“辅助”功能可通过单次操作（例如点按、双击或手势）访问。
  • [C-SR-3] 强烈建议将长按“主屏幕”键用作这一指定互动。

如果设备实现使用屏幕上的单独部分来显示导航键，则：

  • [C-5-1] 导航键必须位于屏幕上的单独部分，不能供应用使用，并且不得遮住或以其他方式影响屏幕上可供应用使用的部分。
  • [C-5-2] 如果应用满足第 7.1.1 节中定义的要求，必须将屏幕的一部分提供给它们使用。
  • [C-5-3] 必须遵从应用通过 View.setSystemUiVisibility() API 方法设置的标志，以便屏幕上这个单独的部分（也称为导航栏）能够正确隐藏起来（如 SDK 中所述）。

如果导航功能是作为基于手势的屏幕上操作提供的，则：

如果导航功能是从屏幕当前方向的左右边缘的任何位置提供的：

  • [C-7-1] 导航功能必须为“返回”，并从屏幕当前方向的左右边缘滑动时提供。
  • [C-7-2] 如果在左边缘或右边缘提供自定义可滑动系统面板，必须将其置于屏幕顶部三分之一内，且具有清晰持久的视觉指示，指明拖动它将调用上述面板，因此不是“返回”。用户可以配置系统面板，使其在屏幕边缘的顶部三分之一下面，但系统面板的使用不得超过边缘的三分之一。
  • [C-7-3] 当前台应用设置了 View.SYSTEM_UI_FLAG_IMMERSIVE、View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY、WindowInsetsController.BEHAVIOR_DEFAULT 或 WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE 标志后，从边缘滑动必须像在 AOSP 中实现一样（如 SDK 中所述）。
  • [C-7-4] 当前台应用设置了 View.SYSTEM_UI_FLAG_IMMERSIVE、View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY、WindowInsetsController.BEHAVIOR_DEFAULT 或 WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE 标志后，自定义可滑动系统面板必须隐藏，直到用户调出系统栏（也就是导航和状态栏），就像在 AOSP 中实现一样。

如果提供了返回导航功能，并且用户取消了返回手势，则：

  • [C-8-1] 必须调用 OnBackInvokedCallback.onBackCancelled()。
  • [C-8-2] 不得调用 OnBackInvokedCallback.onBackInvoked()。
  • [C-8-3] 不得分派 KEYCODE_BACK 事件。

如果提供了返回导航功能，但前台应用没有注册 OnBackInvokedCallback，则：

  • 系统应为前台应用提供一个动画，表明用户正在返回，如 AOSP 中所述。

如果设备实现支持系统 API setNavBarMode 以允许任何具有 android.permission.STATUS_BAR 权限的系统应用设置导航栏模式，则：

  • [C-9-1] 必须支持适合儿童的图标或基于按钮的导航（如 AOSP 代码中所提供）。

7.2.4. 触摸屏输入

Android 支持多种指针输入系统，例如触摸屏、触摸板和模拟触控输入设备。基于触摸屏的设备实现会与屏幕相关联，从而让用户感觉像是在直接操控屏幕上的内容。由于用户会直接触摸屏幕，因此系统不需要使用任何额外的方式来指明所操控的对象。

设备实现：

  • 应具有某种指针输入系统（类似于鼠标的输入系统或触摸式输入系统）。
  • 应支持完全独立跟踪的指针。

如果设备实现在 Android 兼容主屏幕上包含触摸屏（单点触控或更好的触摸屏），则：

  • [C-1-1] 必须针对 Configuration.touchscreen API 字段报告 TOUCHSCREEN_FINGER。
  • [C-1-2] 必须报告 android.hardware.touchscreen 和 android.hardware.faketouch 功能标志。

如果设备实现在 Android 兼容主屏幕上包含可以跟踪多个单点触控的触摸屏，则：

  • [C-2-1] 必须报告与设备上的具体触摸屏类型对应的适当功能标志 android.hardware.touchscreen.multitouch、android.hardware.touchscreen.multitouch.distinct 和 android.hardware.touchscreen.multitouch.jazzhand。

如果设备实现依赖于不直接触摸屏幕的鼠标或轨迹球等外部输入设备，以便在 Android 兼容主屏幕上进行输入，并满足第 7.2.5 节中的模拟触摸要求，则：

  • [C-3-1] 不得报告任何以 android.hardware.touchscreen 开头的功能标志。
  • [C-3-2] 只能报告 android.hardware.faketouch。
  • [C-3-3] 必须针对 Configuration.touchscreen API 字段报告 TOUCHSCREEN_NOTOUCH。

7.2.5. 模拟触摸输入

模拟触摸界面会提供一个能够模拟部分触摸屏功能的用户输入系统。例如，驱动屏幕光标的鼠标或遥控器能够模拟触摸操作，但需要用户先指向或聚焦到目标，然后再点击。鼠标、触控板、基于陀螺仪的空中鼠标、陀螺仪指针、操纵杆和多点触控板等多种输入设备都可以支持模拟触摸互动。Android 包含功能常量 android.hardware.faketouch，该常量对应于高保真非触控（即基于指针的）输入设备，例如可以充分模拟触控输入的鼠标或触控板（包括基本手势支持），并且该常量可指明设备支持所模拟的触摸屏功能子集。

如果设备实现不包含触摸屏，但包含另一种它们想要提供的指针输入系统，则：

  • 应声明支持 android.hardware.faketouch 功能标志。

如果设备实现声明支持 android.hardware.faketouch，则：

  • [C-1-1] 必须报告指针在屏幕中的绝对 X 和 Y 位置，并在屏幕中显示可见指针。
  • [C-1-2] 必须通过操作代码（指定在屏幕中按下或松开指针时发生的状态变化）报告触摸事件。
  • [C-1-3] 必须支持在屏幕中的对象上按下后再松开指针，以便用户模拟点按屏幕中的对象。
  • [C-1-4] 必须支持于时间阈值内在屏幕中对象上的同一位置按下、松开、按下后再松开指针，以便用户模拟点按两次屏幕中的对象。
  • [C-1-5] 必须支持在屏幕中的任意一点按下指针、将指针移至屏幕中的其他任意一点，然后再松开指针，以便用户模拟触摸拖动操作。
  • [C-1-6] 必须支持按下指针后允许用户快速将对象移至屏幕中的其他位置，然后在屏幕中松开指针，以便用户快速滑动屏幕中的对象。

如果设备实现声明支持 android.hardware.faketouch.multitouch.distinct，则：

  • [C-2-1] 必须声明支持 android.hardware.faketouch。
  • [C-2-2] 必须支持对两个或更多个独立的指针输入分别进行跟踪。

如果设备实现声明支持 android.hardware.faketouch.multitouch.jazzhand，则：

  • [C-3-1] 必须声明支持 android.hardware.faketouch。
  • [C-3-2] 必须支持完全独立地分别跟踪 5 个（对一只手上五根手指的操作进行跟踪）或更多个指针输入。

7.2.6. 游戏控制器支持

7.2.6.1. 按钮映射

设备实现：

  • [C-1-1] 必须能够将 HID 事件映射到下表中列出的对应 InputEvent 常量。上游 Android 实现满足此要求。

如果设备实现嵌入控制器，或在包装盒内随附单独的控制器，以便输入下表中列出的所有事件，则：

  • [C-2-1] 必须声明 android.hardware.gamepad 功能标志
按钮 HID 用法2 Android 按钮
A1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X1 0x09 0x0004 KEYCODE_BUTTON_X (99)
Y1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
向上方向键1
向下方向键1		 0x01 0x00393 AXIS_HAT_Y4
向左方向键1
向右方向键1		 0x01 0x00393 AXIS_HAT_X4
左肩按钮1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
右肩按钮1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
左摇杆点击1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
右摇杆点击1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
返回1 0x0c 0x0224 KEYCODE_BACK (4)

1 KeyEvent

2 上述 HID 用法必须在 Game Pad CA (0x01 0x0005) 中声明。

3 这种用法的最小逻辑值必须为 0，最大逻辑值必须为 7，最小物理值必须为 0，最大物理值必须为 315，单位必须为度，并且报告的尺寸值必须为 4。逻辑值指从纵轴顺时针旋转的角度；例如，逻辑值为 0 表示不旋转，并且按下了向上按钮，逻辑值为 1 则表示旋转 45 度，并且同时按下了向上和向左键。

4 MotionEvent

模拟控制1 HID 用法 Android 按钮
左触发 0x02 0x00C5 AXIS_LTRIGGER
右触发 0x02 0x00C4 AXIS_RTRIGGER
左摇杆 0x01 0x0030
0x01 0x0031		 AXIS_X
AXIS_Y
右摇杆 0x01 0x0032
0x01 0x0035		 AXIS_Z
AXIS_RZ

1 MotionEvent

7.2.7. 遥控器

请参阅第 2.3.1 节，了解设备专属要求。

7.3. 传感器

如果设备实现包含某种传感器，而这种传感器具有针对第三方开发者的对应 API，则设备实现必须实现该 API，如 Android SDK 文档和 Android 开放源代码文档中关于传感器的部分所述。

设备实现：

  • [C-0-1] 必须根据 android.content.pm.PackageManager 类准确报告是否存在传感器。
  • [C-0-2] 必须通过 SensorManager.getSensorList() 和类似方法返回准确的受支持传感器列表。
  • [C-0-3] 对于所有其他传感器 API，必须采取合理的行为（例如，在应用尝试注册监听器时视情况返回 true 或 false，在不存在对应的传感器时不调用传感器监听器，等等）。

如果设备实现包含某种传感器，而这种传感器具有针对第三方开发者的对应 API，则：

  • [C-1-1] 对于每种传感器（如 Android SDK 文档中所定义），都必须采用相关国际单位制（公制）报告所有传感器测量结果。
  • [C-1-2] 必须报告传感器数据，并且最大延迟为 100 毫秒 + 2 * sample_time（如果传感器进行流式传输），最大请求延迟为 0 毫秒（如果应用处理器处于活动状态）。此延迟不包含任何过滤延迟。
  • [C-1-3] 必须在启用传感器后的 400 毫秒 + 2 * sample_time 内报告第一个传感器样本。此样本的精度可以为 0。
  • [C-1-4] 对于 Android SDK 文档中指明为连续传感器的任何 API，设备实现都必须连续提供周期性数据样本，并且这些样本的抖动应低于 3%，抖动是指连续事件报告的时间戳值之差的标准偏差。
  • [C-1-5] 必须确保传感器事件流不得阻止设备 CPU 进入挂起状态或从挂起状态唤醒。
  • [C-1-6] 必须以纳秒为单位报告事件时间（具体定义请见 Android SDK 文档），该时间表示事件发生时的时间，与 SystemClock.elapsedRealtimeNano() 时钟同步。
  • [C-SR-1] 强烈建议将时间戳同步误差控制在 100 毫秒以内，并且时间戳同步误差应低于 1 毫秒。
  • 当多个传感器处于启用状态时，功耗不应超过各个传感器所报告的功耗的总和。

上述列表并不是详尽无遗的；请以 Android SDK 和 Android 开放源代码文档中关于传感器的部分所述的行为为准。

如果设备实现包含某种传感器，而这种传感器具有针对第三方开发者的对应 API，则：

  • [C-1-6] 必须为所有传感器设置非零分辨率，并通过 Sensor.getResolution() API 方法报告该值。

有些传感器为复合型，也就是说，它们可以从一个或多个其他传感器提供的数据推导出来。（例如方向传感器和线性加速度传感器。）

设备实现：

  • 应实现这些传感器类型，但前提是设备实现包含必要的实体传感器（如传感器类型中所述）。

如果设备实现包含复合传感器，则：

  • [C-2-1] 必须实现该传感器，如 Android 开放源代码文档中关于复合传感器的部分所述。

如果设备实现包含某种传感器，而这种传感器具有针对第三方开发者的对应 API，并且该传感器仅报告一个值，则设备实现：

  • [C-3-1] 必须将传感器的分辨率设置为 1，并通过 Sensor.getResolution() API 方法报告该值。

如果设备实现包含支持 SensorAdditionalInfo#TYPE_VEC3_CALIBRATION 的特定传感器类型，并且会向第三方开发者公开传感器，则：

  • [C-4-1] 不得在所提供的数据中包含任何固定的、工厂确定的校准参数。

如果设备实现包含 3 轴加速计、3 轴陀螺仪传感器或磁力计传感器的组合，则：

  • [C-SR-2] 强烈建议确保加速度计、陀螺仪和磁力计具有固定的相对位置，这样一来，如果设备可以转换（例如可折叠），传感器轴将在所有可能的设备转换状态中与传感器坐标系对齐并保持一致。

7.3.1. 加速度计

设备实现：

  • [C-SR-1] 强烈建议包含 3 轴加速计。

如果设备实现包含加速度计，则：

  • [C-1-1] 报告事件能够达到的最高频率必须至少为 50 Hz。
  • [C-1-3] 必须遵从 Android 传感器坐标系（Android API 中对此进行了详细说明）。
  • [C-1-4] 在任意轴上都必须能够测量从自由下落到高达四倍重力加速度 (4g) 的运动过程。
  • [C-1-5] 分辨率必须至少为 12 位。
  • [C-1-6] 标准偏差不得高于 0.05 m/s^，其中标准偏差应按每个轴进行计算，并且应使用以最大采样率在至少 3 秒内采集的样本进行计算。
  • 应以至少 200 Hz 的频率报告事件。
  • 分辨率应至少为 16 位。
  • 应在使用时进行校准（如果特性随生命周期发生变化）和补偿，并且在设备重新启动后直到再次重新启动之前应保留补偿参数。
  • 应进行温度补偿。

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

  • [C-2-1] 必须实现并报告 TYPE_ACCELEROMETER 传感器。
  • [C-SR-4] 强烈建议实现 TYPE_SIGNIFICANT_MOTION 复合传感器。
  • [C-SR-5] 强烈建议实现并报告 TYPE_ACCELEROMETER_UNCALIBRATED 传感器。强烈建议 Android 设备满足此要求，以便能够升级到未来的平台版本（在这些版本中，这可能会成为必需组件）。
  • 应实现 TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR、TYPE_STEP_COUNTER 复合传感器（如 Android SDK 文档中所述）。

如果设备实现包含轴数少于 3 的加速度计，则：

  • [C-3-1] 必须实现并报告 TYPE_ACCELEROMETER_LIMITED_AXES 传感器。
  • [C-SR-6] 强烈建议实现并报告 TYPE_ACCELEROMETER_LIMITED_AXES_UNCALIBRATED 传感器。

如果设备实现包含 3 轴加速计，并且实现了 TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR 和 TYPE_STEP_COUNTER 复合传感器中的任何一种，则：

  • [C-4-1] 其功耗总和必须始终低于 4 mW。
  • 每个传感器的功耗应在设备处于动态时低于 2 mW，在设备处于静态时低于 0.5 mW。

如果设备实现包含 3 轴加速计和 3 轴陀螺仪传感器，则：

  • [C-5-1] 必须实现 TYPE_GRAVITY 和 TYPE_LINEAR_ACCELERATION 复合传感器。
  • [C-SR-7] 强烈建议实现 TYPE_GAME_ROTATION_VECTOR 复合传感器。

如果设备实现包含 3 轴加速计、3 轴陀螺仪传感器和磁力计传感器，则：

  • [C-6-1] 必须实现 TYPE_ROTATION_VECTOR 复合传感器。

7.3.2. 磁力计

设备实现：

  • [C-SR-1] 强烈建议包含 3 轴磁力计（罗盘）。

如果设备实现包含 3 轴磁力计，则：

  • [C-1-1] 必须实现 TYPE_MAGNETIC_FIELD 传感器。
  • [C-1-2] 报告事件能够达到的最高频率必须至少为 10 Hz，并且报告事件应该达到的最高频率必须至少为 50 Hz。
  • [C-1-3] 必须遵从 Android 传感器坐标系（Android API 中对此进行了详细说明）。
  • [C-1-4] 饱和之前，在每个轴上的测量范围都必须能够达到 -900 µT 至 +900 µT。
  • [C-1-5] 必须通过以下方式使硬铁偏移值低于 700 µT，并且应低于 200 µT：将磁力计放在远离动态（电流感应）和静态（磁感应）磁场的位置。
  • [C-1-6] 分辨率必须等于或高于 0.6 µT。
  • [C-1-7] 必须支持在线校准和补偿硬铁偏差，并且在设备重新启动后直到再次重新启动之前保留补偿参数。
  • [C-1-8] 必须应用软铁补偿 - 可以在使用期间或设备生产期间进行校准。
  • [C-1-9] 标准偏差不得高于 1.5 µT，并且不应高于 0.5 µT，其中标准偏差是按每个轴进行计算，并且是使用以最大采样率在至少 3 秒内采集的样本进行计算。
  • [C-1-10] 必须实现 TYPE_MAGNETIC_FIELD_UNCALIBRATED 传感器。

如果设备实现包含 3 轴磁力计、加速度计传感器和 3 轴陀螺仪传感器，则：

  • [C-2-1] 必须实现 TYPE_ROTATION_VECTOR 复合传感器。

如果设备实现包含 3 轴磁力计和加速度计，则：

  • 可以实现 TYPE_GEOMAGNETIC_ROTATION_VECTOR 传感器。

如果设备实现包含 3 轴磁力计、加速度计和 TYPE_GEOMAGNETIC_ROTATION_VECTOR 传感器，则：

  • [C-3-1] 功耗必须低于 10 mW。
  • 如果传感器注册了 10 Hz 的批处理模式，功耗应低于 3 mW。

7.3.3. GPS

设备实现：

  • [C-SR-1] 强烈建议包含 GPS/GNSS 接收器。

如果设备实现包含 GPS/GNSS 接收器，并且通过 android.hardware.location.gps 功能标志向应用报告该功能，则：

  • [C-1-1] 当收到通过 LocationManager#requestLocationUpdate 提交的位置信息请求时，必须支持以至少 1 Hz 的频率输出位置信息。
  • [C-1-2] 当互联网连接的数据传输速度为 0.5 Mbps 或更快时，在露天条件（信号强，可忽略多路径，HDOP 小于 2）下必须能于 10 秒内确定位置（快速完成首次定位）。为了满足此要求，通常可以采用某种形式的辅助或预测 GPS/GNSS 技术来最大限度地缩短 GPS/GNSS 锁定时间（辅助数据包括参考时间、参考位置和卫星星历/时钟）。
    • [C-1-6] 完成此类位置计算后，如果设备在一个小时内再次收到位置信息请求，设备实现必须在露天条件下于 5 秒内确定其位置，即使后续请求是在无数据连接的情况下和/或设备重启之后发出的也是如此。

  • 确定位置之后，在露天条件下，当设备处于静止状态或以小于 1 m/s² 的加速度移动时：

    • [C-1-3] 必须至少在 95% 的时间内能够确定 20 米以内的位置以及 0.5 m/s 以内的速度。
    • [C-1-4] 必须通过 GnssStatus.Callback 同时跟踪和报告一个星群中的至少 8 颗卫星。
    • 应能够同时跟踪多个星群（例如 GPS 以及 Glonass、Beidou、Galileo 中的至少一个）中的至少 24 颗卫星。

  • [C-SR-2] 强烈建议在紧急通话期间继续通过 GNSS Location Provider API 提供正常的 GPS/GNSS 位置信息输出。

  • [C-SR-3] 强烈建议报告跟踪的所有星群的 GNSS 测量结果（在 GnssStatus 消息中报告），SBAS 除外。

  • [C-SR-4] 强烈建议报告 AGC 以及 GNSS 测量频率。

  • [C-SR-5] 强烈建议在每次报告 GPS/GNSS 位置时均报告所有估算的测量结果（包括方位、速度和高度）。

  • [C-SR-6] 强烈建议在发现 GNSS 测量结果后立即报告，即使尚未报告通过 GPS/GNSS 计算出的位置信息也是如此。

  • [C-SR-7] 强烈建议报告 GNSS 伪距和伪距率，以便在确定位置之后，在露天条件下，当设备处于静止状态或以小于 0.2 m/s² 的加速度移动时，至少在 95% 的情况下能够计算出 20 米以内的位置以及 0.2 m/s 以内的速度。

7.3.4. 陀螺仪

设备实现：

  • [C-SR-1] 强烈建议包含陀螺仪传感器。

如果设备实现包含陀螺仪，则：

  • [C-1-1] 报告事件能够达到的最高频率必须至少为 50 Hz。
  • [C-1-4] 分辨率必须为 12 位或更高。
  • [C-1-5] 必须进行温度补偿。
  • [C-1-6] 必须在使用时进行校准和补偿，并在设备重新启动后直到再次重新启动之前保留补偿参数。
  • [C-1-7] 每 Hz 方差不得超过 1e-7 rad^2/s^2（每 Hz 方差，或 rad^2/s）。方差可随采样率而变化，但不得超过此值。也就是说，如果以 1 Hz 的采样率测量陀螺仪的方差，则方差不应超过 1e-7 rad^2/s^2。
  • [C-SR-2] 强烈建议设备在室温下处于静止状态时的校准误差小于 0.01 rad/s。
  • [C-SR-3] 强烈建议分辨率为 16 位或更高。
  • 应以至少 200 Hz 的频率报告事件。

如果设备实现包含 3 轴陀螺仪，则：

如果设备实现包含轴数少于 3 的陀螺仪，则：

  • [C-3-1] 必须实现并报告 TYPE_GYROSCOPE_LIMITED_AXES 传感器。
  • [C-SR-5] 强烈建议实现并报告 TYPE_GYROSCOPE_LIMITED_AXES_UNCALIBRATED 传感器。

如果设备实现包含 3 轴陀螺仪、加速度计传感器和磁力计传感器，则：

  • [C-4-1] 必须实现 TYPE_ROTATION_VECTOR 复合传感器。

如果设备实现包含 3 轴加速计和 3 轴陀螺仪传感器，则：

  • [C-5-1] 必须实现 TYPE_GRAVITY 和 TYPE_LINEAR_ACCELERATION 复合传感器。
  • [C-SR-6] 强烈建议实现 TYPE_GAME_ROTATION_VECTOR 复合传感器。

7.3.5. 气压计

设备实现：

  • [C-SR-1] 强烈建议包含气压计（环境气压传感器）。

如果设备实现包含气压计，则：

  • [C-1-1] 必须实现并报告 TYPE_PRESSURE 传感器。
  • [C-1-2] 必须能够以至少 5 Hz 的频率报告事件。
  • [C-1-3] 必须进行温度补偿。
  • [C-SR-2] 强烈建议能够报告 300 hPa 到 1100 hPa 之间的压力测量结果。
  • 绝对精度应为 1 hPa。
  • 相对精度应为 20 hPa 范围内误差不超过 0.12 hPa（相当于在海平面上 200 m 左右的变化误差不超过 1 m 左右）。

7.3.6. 温度计

如果设备实现包含环境温度计（温度传感器），则：

  • [C-1-1] 必须定义环境温度传感器的 SENSOR_TYPE_AMBIENT_TEMPERATURE，并且传感器必须从用户与设备互动的位置（室内/车厢内）测量环境温度（以摄氏度为单位）。

如果设备实现包含温度计传感器，用于测量除环境温度以外的温度（如 CPU 温度），则：

如果设备实现包含用于监测体表温度的传感器，则：

7.3.7. 光度计

  • 设备实现可以包含光度计（环境光传感器）。

7.3.8. 近程传感器

  • 设备实现可以包含近程传感器。

如果设备实现包含近程传感器，并且仅报告二进制“近程”或“远程”读数，则：

  • [C-1-1] 必须沿与屏幕相同的方向测量物体的接近度。也就是说，近程传感器必须朝向适当方向，以便检测靠近屏幕的物体，因为此类传感器的主要用途是检测用户正在使用的手机。如果设备实现包含朝向任何其他方向的近程传感器，则不得通过此 API 访问此类传感器。
  • [C-1-2] 精度必须至少为 1 位。
  • [C-1-3] 必须将 0 厘米作为近程读数，并将 5 厘米作为远距离读数。
  • [C-1-4] 报告的最大范围和分辨率必须为 5。

7.3.9. 高保真传感器

如果设备实现包含一套质量更高的传感器（如本节中定义），并使其可供第三方应用使用，则：

  • [C-1-1] 必须通过 android.hardware.sensor.hifi_sensors 功能标志标识该功能。

如果设备实现声明 android.hardware.sensor.hifi_sensors，则：

  • [C-2-1] 必须具有符合以下要求的 TYPE_ACCELEROMETER 传感器：

    • 测量范围必须至少在 -8 g 到 +8 g 之间，强烈建议测量范围在 -16 g 到 +16 g 之间。
    • 测量分辨率必须至少为 2048 LSB/g。
    • 最小测量频率必须等于或低于 12.5 Hz。
    • 最大测量频率必须等于或高于 400 Hz，且应支持 SensorDirectChannel RATE_VERY_FAST。
    • 测量噪声不得高于 400 μg/√Hz。
    • 必须实现这种传感器的非唤醒形式，并且至少能够缓冲 3,000 个传感器事件。
    • 批处理功耗不得高于 3 mW。
    • [C-SR-1] 强烈建议采用 3 dB 的测量带宽以及至少 80% 的奈奎斯特频率，且此带宽中具有白噪声声谱。
    • 在室温下测试的加速度随机游走应小于 30 μg/√Hz。
    • 偏差随温度的变化应小于等于 +/- 1 mg/°C。
    • 最佳拟合线非线性度应小于等于 0.5%，并且灵敏度随温度的变化应小于等于 0.03%/C°。
    • 在设备工作温度范围内，交叉轴灵敏度应低于 2.5%，其变体应低于 0.2%。

  • [C-2-2] 必须具有 TYPE_ACCELEROMETER_UNCALIBRATED，并且其符合与 TYPE_ACCELEROMETER 相同的质量要求。

  • [C-2-3] 必须具有符合以下要求的 TYPE_GYROSCOPE 传感器：

    • 测量范围必须至少在 -1000 dps 到 +1000 dps 之间。
    • 测量分辨率必须至少为 16 LSB/dps。
    • 最小测量频率必须等于或低于 12.5 Hz。
    • 最大测量频率必须等于或高于 400 Hz，且应支持 SensorDirectChannel RATE_VERY_FAST。
    • 测量噪声不得高于 0.014 °/s/√Hz。
    • [C-SR-2] 强烈建议采用 3 dB 的测量带宽以及至少 80% 的奈奎斯特频率，且此带宽中具有白噪声声谱。
    • 在室温下测试的速率随机游走应小于 0.001 °/s √Hz。
    • 偏差随温度的变化应小于等于 +/- 0.05 °/s/°C。
    • 灵敏度随温度的变化应小于等于 0.02%/°C。
    • 最佳拟合线非线性度应小于等于 0.2%。
    • 噪声密度应小于等于 0.007 °/s/√Hz。
    • 当设备处于静态时，10-40 ℃ 温度范围内的校准误差应小于 0.002 rad/s。
    • G 灵敏度应低于 0.1°/s/g。
    • 在设备工作温度范围内，交叉轴灵敏度应低于 4.0%，其变体应低于 0.3%。

  • [C-2-4] 必须具有 TYPE_GYROSCOPE_UNCALIBRATED，并且其符合与 TYPE_GYROSCOPE 相同的质量要求。

  • [C-2-5] 必须具有符合以下要求的 TYPE_GEOMAGNETIC_FIELD 传感器：

    • 测量范围必须至少在 -900 µT 到 +900 µT 之间。
    • 测量分辨率必须至少为 5 LSB/uT。
    • 最小测量频率必须等于或低于 5 Hz。
    • 最大测量频率必须等于或高于 50 Hz。
    • 测量噪声不得高于 0.5 uT。

  • [C-2-6] 必须具有 TYPE_MAGNETIC_FIELD_UNCALIBRATED，并且其除了符合与 TYPE_GEOMAGNETIC_FIELD 相同的质量要求外，还要符合以下要求：

    • 必须实现这种传感器的非唤醒形式，并且至少能够缓冲 600 个传感器事件。
    • [C-SR-3] 如果报告的速率为 50 Hz 或更高，强烈建议白噪声谱在 1 Hz 到至少 10 Hz 之间。

  • [C-2-7] 必须具有符合以下要求的 TYPE_PRESSURE 传感器：

    • 测量范围必须至少在 300 hPa 到 1100 hPa 之间。
    • 测量分辨率必须至少为 80 LSB/hPa。
    • 最小测量频率必须等于或低于 1 Hz。
    • 最大测量频率必须等于或高于 10 Hz。
    • 测量噪声不得高于 2 Pa/√Hz。
    • 必须实现这种传感器的非唤醒形式，并且至少能够缓冲 300 个传感器事件。
    • 批处理功耗不得高于 2 mW。

  • [C-2-8] 必须具有 TYPE_GAME_ROTATION_VECTOR 传感器。

  • [C-2-9] 必须具有符合以下要求的 TYPE_SIGNIFICANT_MOTION 传感器：

    • 当设备处于静态时，功耗不得高于 0.5 mW；当设备处于动态时，功耗不得高于 1.5 mW。

  • [C-2-10] 必须具有符合以下要求的 TYPE_STEP_DETECTOR 传感器：

    • 必须实现这种传感器的非唤醒形式，并且至少能够缓冲 100 个传感器事件。
    • 当设备处于静态时，功耗不得高于 0.5 mW；当设备处于动态时，功耗不得高于 1.5 mW。
    • 批处理功耗不得高于 4 mW。

  • [C-2-11] 必须具有符合以下要求的 TYPE_STEP_COUNTER 传感器：

    • 当设备处于静态时，功耗不得高于 0.5 mW；当设备处于动态时，功耗不得高于 1.5 mW。

  • [C-2-12] 必须具有符合以下要求的 TILT_DETECTOR 传感器：

    • 当设备处于静态时，功耗不得高于 0.5 mW；当设备处于动态时，功耗不得高于 1.5 mW。

  • [C-2-13] 加速度计、陀螺仪和磁力计报告的同一物理事件的事件时间戳之差必须在 2.5 毫秒以内。加速度计和陀螺仪报告的同一物理事件的事件时间戳之差应在 0.25 毫秒以内。

  • [C-2-14] 陀螺仪传感器事件时间戳必须与摄像头子系统采用相同的时间基准，并且误差在 1 毫秒以内。

  • [C-2-15] 当上述任一物理传感器上的数据可供应用使用时，必须在 5 毫秒内将样本提供给应用。

  • [C-2-16] 如果启用了以下传感器的任意组合，当设备处于静态时，功耗不得高于 0.5 mW；当设备处于动态时，功耗不得高于 2.0 mW：

    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS

  • [C-2-17] 可以有 TYPE_PROXIMITY 传感器，但如果存在，则必须至少能够缓冲 100 个传感器事件。

请注意，本节中的所有功耗要求都不包括应用处理器的功耗。它包含的是整个传感器链（传感器、所有辅助电路、所有专用的传感器处理系统，等等）的功耗。

如果设备实现支持直接传感器，则：

  • [C-3-1] 必须通过 isDirectChannelTypeSupported 和 getHighestDirectReportRateLevel API 正确声明支持直接通道类型和直接报告速率级别。
  • [C-3-2] 对于声明支持传感器直接通道的所有传感器，都必须至少支持以下两种传感器直接通道类型之一。
  • 对于以下类型的主要传感器（非唤醒变体），应支持通过传感器直接通道报告事件：
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. 生物识别传感器

如需了解衡量生物识别解锁模式的安全性的其他背景，请参阅衡量生物识别的安全性文档。

如果设备实现包含安全锁定屏幕，则：

  • 应包含生物识别传感器

生物识别传感器可基于其欺骗和冒名攻击的接受率以及生物识别管道的安全分类为 3 类（之前的强）、2 类（之前的弱）或 1 类（之前的便利）。此分类确定生物识别传感器所具有的与平台和第三方应用接口的功能。若要将传感器归类为 1 类、2 类或 3 类，需要满足下面详述的额外要求。2 类和 3 类生物识别都可以获得下面详述的额外功能。

如果设备实现通过 android.hardware.biometrics.BiometricManager、android.hardware.biometrics.BiometricPrompt 和 android.provider.Settings.ACTION_BIOMETRIC_ENROLL 使生物识别传感器可用于第三方应用，则：

  • [C-4-1] 必须满足 3 类或 2 类生物识别的要求，如本文档中所定义。
  • [C-4-2] 必须识别并遵从 Authenticators 类中定义为常量的每个参数名称。反之，不得遵从或识别传递给 canAuthenticate(int) 和 setAllowedAuthenticators(int) 方法的整数常量，在 Authenticators 及其以及任何组合中载述为常量的整数常量除外。
  • [C-4-3] 必须在具有 3 类或 2 类生物识别功能的设备上实现 ACTION_BIOMETRIC_ENROLL 操作。此操作必须只为 3 类或 2 类生物识别提供注册入口点。

如果设备实现支持被动生物识别技术，则：

  • [C-5-1] 必须默认要求执行额外的确认步骤（例如按下按钮）。
  • [C-SR-1] 强烈建议提供一项设置，允许用户替换应用偏好设置，并且始终要求执行附带的确认步骤。
  • [C-SR-2] 强烈建议妥善保护确认操作，使操作系统或内核攻击无法欺骗确认操作。例如，这意味着基于物理按钮的确认操作会通过安全元件（无法由按物理按钮之外的任何其他方式触发）的仅限输入通用输入/输出 (GPIO) 引脚进行路由。
  • [C-5-2] 必须另外实现与 setConfirmationRequired(boolean) 相对应的隐式身份验证流（无需确认步骤）；应用可以设置它，以用于登录流程。

如果设备实现具有多个生物识别传感器，则：

新要求开始

  • [C-7-1] 如果生物识别功能因失败尝试次数过多而锁定（即生物识别功能处于停用状态，直到用户使用主要身份验证方法解锁）或限时锁定（即生物识别功能暂时处于停用状态，用户需要等待一段时间），必须也锁定更低生物识别类别的所有其他生物识别功能。在限时锁定的情况下，必须将生物识别验证的退避时间设置为限时锁定的所有生物识别功能的最长退避时间。

  • [C-SR-12] 如果生物识别功能因失败尝试次数过多而锁定（即生物识别功能处于停用状态，直到用户使用主要身份验证方法解锁）或限时锁定（即生物识别功能暂时处于停用状态，用户需要等待一段时间），强烈建议也锁定同一生物识别类别的所有其他生物识别功能。在限时锁定的情况下，强烈建议将生物识别验证的退避时间设置为限时锁定的所有生物识别功能的最长退避时间。

  • [C-7-2] 必须要求用户通过建议的主要身份验证方法（例如 PIN 码、图案、密码）验证身份，才能为已被锁定的生物识别功能重置锁定计数器。对于 3 类生物识别，可以允许为同一类别或更低类别的已锁定生物识别功能重置锁定计数器。对于 2 类或 1 类生物识别，不得允许为任何生物识别功能完成重置锁定操作。

新要求结束

  • [C-SR-3] 强烈建议每次身份验证仅要求确认一个生物识别特征（例如，如果设备上有指纹传感器和人脸传感器，应在其中任何一个特征被确认后发送 onAuthenticationSucceeded）。

如果设备实现要允许访问第三方应用的密钥库密钥，则：

  • [C-6-1] 必须满足 3 类生物识别的要求，如本节中所定义。
  • [C-6-2] 当身份验证要求执行 BIOMETRIC_STRONG 或者身份验证流程通过 CryptoObject 调用时，必须只提供 3 类身份验证。

如果设备实现希望将生物识别传感器视为 1 类（之前的便利），则：

  • [C-1-1] 错误接受率必须低于 0.002%。
  • [C-1-2] 必须披露此模式的安全性可能不及安全系数高的 PIN 码、图案或密码，并在欺骗和冒名攻击的接受率高于 7%（此值由 Android 生物识别测试协议衡量得出）时明确枚举启用此模式的风险。
  • [C-1-9] 尝试生物识别验证的失败次数不超过 20 次且退避时间不少于 90 秒后，必须对用户进行建议的主要身份验证（例如 PIN 码、图案、密码），验证失败是指采集的足够有效信息 (BIOMETRIC_ACQUIRED_GOOD) 与已注册的生物识别信息不匹配。
  • [C-SR-4] 强烈建议在欺骗和冒名攻击的接受率高于 7%（此值由 Android 生物识别测试协议衡量得出）时减少 [C-1-9] 中指定的生物识别验证的总失败次数。
  • [C-1-3] 必须限制生物识别验证的尝试次数，验证失败是指采集的足够有效信息 (BIOMETRIC_ACQUIRED_GOOD) 与已注册的生物识别信息不匹配。
  • [C-SR-5] 尝试生物识别验证的失败次数达到 5 次后，强烈建议根据 [C-1-9] 中规定的最大失败次数限制，在至少 30 秒内不能再进行生物识别验证，验证失败是指采集的足够有效信息 (BIOMETRIC_ACQUIRED_GOOD) 与已注册的生物识别信息不匹配。
  • [C-SR-6] 强烈建议在 TEE 中配置所有速率限制逻辑。

  • [C-1-10] 首次触发主要身份验证退避时间后，必须停用生物识别（如第 9.11 节的 [C-0-2] 中所述）。

  • [C-1-11] 欺骗和冒名攻击的接受率不得高于 30%；并且 (1) 针对 A 级演示攻击手段 (PAI) 类型的欺骗和冒名攻击的接受率不得高于 30%；(2) 针对 B 级 PAI 类型的欺骗和冒名攻击的接受率不得高于 40%（此值由 Android 生物识别测试协议衡量得出）。

  • [C-1-4] 必须通过以下方式防止在没有先建立信任链的情况下添加新的生物识别信息：让用户确认现有设备凭据（PIN 码/图案/密码，受 TEE 保护）或添加新设备凭据；Android 开源项目实现在框架中提供了实现这一点的机制。

  • [C-1-5] 必须在移除用户的账号（包括恢复出厂设置）时完全删除所有可识别的生物识别数据。

  • [C-1-6] 必须遵从相应生物识别的各个标志（即 DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT、DevicePolicymanager.KEYGUARD_DISABLE_FACE 或 DevicePolicymanager.KEYGUARD_DISABLE_IRIS）。

  • [C-1-7] 必须至少每隔 24 小时对用户进行一次建议的主要身份验证（例如 PIN 码、图案、密码）。注意：如果是发布时搭载 Android 9 或更低版本而后升级的设备，必须至少每隔 72 小时对用户进行一次建议的主要身份验证（例如 PIN 码、图案和密码）。

  • [C-1-8] 必须在执行以下操作之一后对用户进行建议的主要身份验证（例如 PIN 码、图案、密码）或第 3 类（强）生物识别：

    • 4 小时空闲超时期限，或
    • 尝试生物识别身份验证失败 3 次。
    • 空闲超时期限和失败的身份验证计数将在每次成功确认设备凭据后重置。注意：发布时搭载 Android 9 或更低版本而后升级的设备可以不遵守 C-1-8 要求。

  • [C-SR-7] 强烈建议使用 Android 开源项目提供的框架中的逻辑，为新设备强制执行 [C-1-7] 和 [C-1-8] 中规定的限制条件。

  • [C-SR-8] 强烈建议确保在设备上测得的错误拒绝率低于 10%。

  • [C-SR-9] 对于每个已注册的生物识别信息，强烈建议确保延迟（即从检测到生物识别信息到屏幕解锁的时间）低于 1 秒。

新要求开始

  • [C-1-12] 每种演示攻击手段 (PAI) 类型的欺骗和冒名攻击的接受率不得高于 40%（此值由 Android 生物识别测试协议衡量得出）。

  • [C-SR-13] 强烈建议每种演示攻击手段 (PAI) 类型的欺骗和冒名攻击接受率不高于 30%（此值由 Android 生物识别测试协议衡量得出）。

  • [C-SR-14] 强烈建议披露生物识别传感器的生物识别类别以及启用该传感器的相应风险。

  • [C-SR-17] 强烈建议实现新的 AIDL 接口（例如 IFace.aidl 和 IFingerprint.aidl）。

新要求结束

如果设备实现希望将生物识别传感器视为 2 类（之前的弱），则：

  • [C-2-1] 必须满足上述 1 类的所有要求。

  • [C-2-2] 欺骗和冒名攻击的接受率不得高于 20%；并且 (1) 针对 A 级演示攻击手段 (PAI) 类型的欺骗和冒名攻击的接受率不得高于 20%；(2) 针对 B 级 PAI 类型的欺骗和冒名攻击的接受率不得高于 30%（此值由 Android 生物识别测试协议衡量得出）。

新要求开始

  • [C-SR-15] 强烈建议每种演示攻击手段 (PAI) 类型的欺骗和冒名攻击接受率不高于 20%（此值由 Android 生物识别测试协议衡量得出）。

新要求结束

  • [C-2-3] 必须在 Android 用户或内核空间外部的隔离执行环境（如可信执行环境 [TEE]）中、或在具有通向隔离执行环境的安全信道的芯片上，或者在满足第 9.17 节中要求的受保护虚拟机上执行生物识别匹配。
  • [C-2-4] 必须对所有可识别的数据进行加密，并对其采用密码形式的身份验证机制，以确保在隔离执行环境、具有通向隔离执行环境的安全信道的芯片或者满足第 9.17 节中要求且由 Hypervisor 控制的受保护虚拟机之外无法获取、读取或更改这些数据（如 Android 开源项目网站上的实现准则中所述）。
  • [C-2-5] 对于基于摄像头的生物识别，进行基于生物识别的身份验证或注册时：
    • 必须在防止在隔离执行环境、具有通向隔离执行环境的安全信道的芯片或者满足第 9.17 节中要求且由 Hypervisor 控制的受保护虚拟机之外读取或更改摄像头帧的模式中操作摄像头。
    • 对于 RGB 单摄像头解决方案，可在隔离执行环境之外读取摄像头帧，以支持注册预览等操作，但仍不得更改。
  • [C-2-6] 不得允许第三方应用区分已注册的生物识别信息。
  • [C-2-7] 不得在 TEE 范围或者满足第 9.17 节中要求且由 Hypervisor 控制的受保护虚拟机之外允许应用处理器对可识别的生物识别数据及其衍生的任何数据（例如嵌入）进行未加密的访问。发布时搭载 Android 9 或更低版本而后升级的设备不可免于遵循 C-2-7 要求。

  • [C-2-8] 必须具有安全的处理流水线，使操作系统或内核攻击不能直接注入数据并将攻击者错误验证为用户。注意：如果设备实现已搭载 Android 9 或更低版本，且无法通过系统软件更新来满足 C-2-8 要求，可以不遵守该要求。

  • [C-SR-10] 强烈建议包含所有生物识别模式的活度检测和人脸生物识别的注意力检测。

  • [C-2-9] 必须使生物识别传感器可供第三方应用使用。

如果设备实现希望将生物识别传感器视为 3 类（之前的强），则：

  • [C-3-1] 必须满足上述 2 类的所有要求，[C-1-7] 和 [C-1-8] 除外。
  • [C-3-2] 必须具有硬件支持的密钥库实现。
  • [C-3-3] 欺骗和冒名攻击的接受率不得高于 7%；并且 (1) 针对 A 级演示攻击手段 (PAI) 类型的欺骗和冒名攻击的接受率不得高于 7%；(2) 针对 B 级 PAI 类型的欺骗和冒名攻击的接受率不得高于 20%（此值由 Android 生物识别测试协议衡量得出）。
  • [C-3-4] 必须至少每隔 72 小时对用户进行一次建议的主要身份验证（例如 PIN 码、图案、密码）。
  • [C-3-5] 必须为设备上支持的所有 3 类生物识别（如果已重新注册）重新生成身份验证器 ID。
  • [C-3-6] 必须启用第三方应用的支持生物识别的密钥库密钥。

新要求开始

  • [C-SR-16] 强烈建议每种演示攻击手段 (PAI) 类型的欺骗和冒名攻击接受率不高于 7%（此值由 Android 生物识别测试协议衡量得出）。

新要求结束

如果设备实现包含显示屏下方指纹传感器 (UDFPS)，则：

  • [C-SR-11] 强烈建议阻止 UDFPS 的可触摸区域干扰“三按钮”导航（某些用户可能需要以实现无障碍功能）。

7.3.11. 姿势传感器

设备实现：

  • 可以支持具有 6 个自由度的姿势传感器。

如果设备实现支持具有 6 个自由度的姿势传感器，则：

  • [C-1-1] 必须实现并报告 TYPE_POSE_6DOF 传感器。
  • [C-1-2] 必须比只使用旋转矢量更准确。

7.3.12. 合页角度传感器

如果设备实现支持合页角度传感器，则：

7.3.13. IEEE 802.1.15.4 (UWB)

如果设备实现支持 802.1.15.4，并将该功能提供给第三方应用使用，则：

新要求开始

  • [C-1-2] 必须报告硬件功能标志 android.hardware.uwb。
  • [C-1-3] 必须支持 AOSP 实现中定义的以下所有配置集（FIRA UCI 参数的预定义组合）。
    • CONFIG_ID_1：FiRa 定义的单播 STATIC STS DS-TWR 范围，延迟模式，测距间隔 240 毫秒。
    • CONFIG_ID_2：FiRa 定义的一对多 STATIC STS DS-TWR 范围，延迟模式，测距间隔 200 毫秒。典型用例：一部智能手机与多部智能设备交互。
    • CONFIG_ID_3：与 CONFIG_ID_1 相同，但系统不会报告到达角 (AoA) 数据。
    • CONFIG_ID_4：与 CONFIG_ID_1 相同，但已启用 P-STS 安全模式。
    • CONFIG_ID_5：与 CONFIG_ID_2 相同，但已启用 P-STS 安全模式。
    • CONFIG_ID_6：与 CONFIG_ID_3 相同，但已启用 P-STS 安全模式。
    • CONFIG_ID_7：与 CONFIG_ID_2 相同，但已启用 P-STS 单个控制者密钥模式。
  • [C-1-4] 必须提供一种用户功能，让用户能够切换 UWB 无线装置的开启/关闭状态。
  • [C-1-5] 必须强制要求使用 UWB 无线装置的应用拥有（NEARBY_DEVICES 权限组中的）UWB_RANGING 权限。

通过标准组织（包括 FIRA、CCC 和 CSA）定义的相关一致性和认证测试，有助于确保 802.1.15.4 正常运行。

新要求结束

7.4. 数据连接

7.4.1. telephony

在 Android API 和本文档中，“电话”专指与进行语音通话、发送短信或通过移动（例如 GSM、CDMA、LTE、NR）GSM 或 CDMA 网络建立移动数据相关的硬件。支持“电话”功能的设备可根据具体产品选择提供部分或全部通话、短信和数据服务。

通过 GSM 或 CDMA 网络。虽然这些语音通话可能采用也可能不采用分封交换技术，但都是为了使 Android 被视为独立于任何可通过同一网络实现的数据连接。也就是说，Android“电话”功能和 API 专指语音通话和短信。例如，如果设备实现无法打电话或收发短信，无论它们是否使用移动网络进行数据连接，都不会被视为电话设备。

  • Android 可以用在不包含电话硬件的设备上。也就是说，Android 可与非电话设备兼容。

如果设备实现包含 GSM 或 CDMA 电话，则：

  • [C-1-1] 必须根据该技术声明 android.hardware.telephony 功能标志和其他子功能标志。
  • [C-1-2] 必须完全支持针对该技术的 API。
  • 应允许在紧急呼叫期间调用所有可用的移动网络服务类型（2G、3G、4G、5G 等），而不考虑通过 SetAllowedNetworkTypeBitmap() 设置的网络类型。

如果设备实现不包含电话硬件，则：

  • [C-2-1] 必须将所有相关 API 实现为空操作。

如果设备实现支持 eUICC 或 eSIM 卡/嵌入式 SIM 卡并包含专有机制以使 eSIM 卡功能可供第三方开发者使用，则：

如果设备实现未将系统属性 ro.telephony.iwlan\_operation\_mode 设置为“legacy”，则：

如果设备实现支持为多媒体电话服务 (MMTEL) 和富通讯解决方案 (RCS) 功能进行单个 IP 多媒体子系统 (IMS) 注册，并预计符合关于对所有 IMS 信令流量使用单个 IMS 注册的移动网络运营商要求，则：

如果设备实现报告 android.hardware.telephony 功能，则：

如果设备实现报告 android.hardware.telephony 功能并提供系统状态栏，则：

  • [C-7-1] 必须为指定的群组 UUID 选择处于活动状态的代表性订阅，以在任何提供 SIM 卡状态信息的功能中向用户显示。此类功能的示例包括状态栏移动网络信号图标或快捷设置图块。
  • [C-SR-1] 强烈建议选择代表性订阅作为处于活动状态的数据订阅，除非设备正在进行语音通话；在进行语音通话期间，强烈建议将处于活动状态的语音订阅作为代表性订阅。

如果设备实现报告 android.hardware.telephony 功能，则：

  • [C-6-7] 必须能够按照 ETSI TS 102 221，针对每个 UICC 打开并同时使用最大数量的逻辑通道（共 20 个）。
  • [C-6-8] 不得自动或在用户未明确确认的情况下将以下任何行为应用于处于活动状态的运营商应用（如 TelephonyManager#getCarrierServicePackageName 所指定）：
    • 撤消或限制网络访问权限
    • 撤消权限
    • 除 AOSP 中包含的现有电源管理功能之外，限制其他后台或前台应用执行
    • 停用或卸载应用

如果设备实现报告 android.hardware.telephony 功能，共用同一群组 UUID 的所有处于活动状态的非机会性订阅均已停用，并且以物理方式从设备中移除或标记为机会性，则设备：

  • [C-8-1] 必须自动停用同一群组中所有剩余的处于活动状态的机会性订阅。

如果设备实现包含 GSM 电话，但不包含 CDMA 电话，则：

如果设备实现支持具有多个端口和配置文件的 eUICC，则：

7.4.1.1. 号码屏蔽兼容性

如果设备实现报告 android.hardware.telephony.calling 功能，则：

  • [C-1-1] 必须支持号码屏蔽
  • [C-1-2] 必须完整实现 BlockedNumberContract 和对应的 API（如 SDK 文档中所述）。

  • [C-1-3] 必须屏蔽从列入“BlockedNumberProvider”的电话号码打来的所有电话和发来的所有短信，而不与应用进行任何互动。唯一例外是当号码屏蔽被临时解除时，如 SDK 文档中所述。

  • [C-1-4] 必须将被屏蔽的呼叫写入平台通话记录提供程序，并且必须将具有 BLOCKED_TYPE 的呼叫从预安装的拨号器应用的默认通话记录视图中过滤出来。

  • [C-1-5] 不得将被屏蔽的短信写入电话提供程序。

  • [C-1-6] 必须实现被屏蔽号码管理界面，并且系统可因应 TelecomManager.createManageBlockedNumbersIntent() 方法返回的 intent 打开该界面。

  • [C-1-7] 不得允许次要用户查看或修改设备上被屏蔽的号码，因为 Android 平台会假设主要用户对设备上的电话服务（单个实例）拥有完全控制权。对于次要用户，必须隐藏所有与屏蔽相关的界面，并且仍必须遵从屏蔽列表。

  • 当设备更新到 Android 7.0 时，应将被屏蔽的号码迁移到提供程序。

  • 应提供一种用户功能，用于在预安装的拨号器应用中显示被屏蔽的呼叫。

7.4.1.2. Telecom API

如果设备实现报告 android.hardware.telephony.calling，则：

  • [C-1-1] 必须支持 ConnectionService API（如 SDK 中所述）。
  • [C-1-2] 必须显示新的来电，并且当用户在进行来自不支持呼叫保持功能（通过 CAPABILITY_SUPPORT_HOLD 指定）的第三方应用的通话时，能够接听或拒绝来电。
  • [C-1-3] 必须有实现 InCallService 的应用。

  • [C-SR-1] 强烈建议告知用户接听来电会导致正在进行的通话中断。

    AOSP 实现通过提醒式通知满足上述要求，此类通知可提示用户接听来电会导致其他通话中断。

  • [C-SR-2] 强烈建议预加载默认的拨号器应用，当第三方应用将其 PhoneAccount 上的 EXTRA_LOG_SELF_MANAGED_CALLS extra 键设置为 true 时，该拨号器应用会显示通话记录条目，并在通话记录中显示第三方应用的名称。

  • [C-SR-3] 强烈建议按如下所述为 android.telecom API 处理音频耳机的 KEYCODE_MEDIA_PLAY_PAUSE 和 KEYCODE_HEADSETHOOK 事件：

7.4.1.3. 移动网络 NAT-T keepalive 分流

设备实现：

  • 应支持移动网络 keepalive 分流。

如果设备实现支持移动网络 keepalive 分流，并使该功能可供第三方应用使用，则：

  • [C-1-1] 必须支持 SocketKeepAlive API。
  • [C-1-2] 必须支持至少一个移动网络上的并发 keepalive 槽。
  • [C-1-3] 所支持的并发移动网络 keepalive 槽的数量必须与移动网络无线装置 HAL 支持的数量相同。
  • [C-SR-1] 强烈建议每个无限装置实例至少支持三个移动网络 keepalive 槽。

如果设备实现不支持移动网络 keepalive 分流，则：

  • [C-2-1] 必须返回 ERROR_UNSUPPORTED。

7.4.2. IEEE 802.11 (Wi-Fi)

设备实现：

  • 应支持一种或多种形式的 802.11。

如果设备实现支持 802.11，并将该功能提供给第三方应用使用，则：

  • [C-1-1] 必须实现对应的 Android API。
  • [C-1-2] 必须报告硬件功能标志 android.hardware.wifi。
  • [C-1-3] 必须实现多播 API（如 SDK 文档中所述）。
  • [C-1-4] 必须支持多播 DNS (mDNS)，并且不得在操作过程中的任何时候滤除 mDNS 数据包（224.0.0.251 或 ff02::fb），包括在屏幕未处于活动状态时；除非丢弃或滤除这些数据包是为了保持在目标市场适用法规所要求的能耗范围内，必须如此。即使处于待机状态时（适用于 Android TV 设备实现）。
  • [C-1-5] 不得将 WifiManager.enableNetwork() API 方法调用视为充分的指示信号来切换当前处于活动状态的 Network（默认用于提供应用流量，由 getActiveNetwork 和 registerDefaultNetworkCallback 等 ConnectivityManager API 方法返回）。也就是说，只有成功确认 Wi-Fi 网络在提供互联网连接后，设备实现才能停用任何其他网络服务提供商（例如移动数据网络）提供的互联网连接。
  • [C-1-6] 强烈建议在调用 ConnectivityManager.reportNetworkConnectivity() API 方法后重新评估 Network 上的互联网连接，并在评估确定当前 Network 不再提供互联网连接后，切换至提供互联网连接的任何其他可用网络（例如移动数据网络）。
  • [C-1-7] 在 STA 断开连接时，必须在每次扫描开始时对探测请求帧的源 MAC 地址和序列号进行一次随机化处理。
  • [C-1-8] 必须使用一个一致的 MAC 地址（不应在扫描期间对 MAC 地址进行随机化处理）。
  • [C-1-9] 必须在扫描中包含的探测请求之间按正常方式（依序）迭代探测请求序列号。
  • [C-1-10] 必须在以下时间对探测请求序列号进行随机化处理：一次扫描包含的最后一个探测请求和下次扫描包含的第一个探测请求之间。
  • [C-SR-1] 强烈建议在与接入点 (AP) 建立关联以及保持关联期间，使用随机的源 MAC 地址与 AP 进行所有的 STA 通信。
    • 设备必须针对每个与其通信的 SSID（对于 Passpoint，为 FQDN）使用不同的随机分配的 MAC 地址。
    • 设备必须向用户提供针对每个 SSID（对于 Passpoint，为 FQDN）进行随机分配控制的选项（包括非随机分配和随机分配选项），还必须将新 Wi-Fi 配置的默认模式设置为随机分配。
  • [C-SR-2] 强烈建议为其创建的任何 AP 使用随机分配的 BSSID。
    • 对于 AP 使用的每个 SSID，MAC 地址必须进行随机化处理并予以保留。
    • 设备可以为用户提供停用此功能的选项。如果提供此类选项，必须默认启用随机分配。

如果设备实现支持 Wi-Fi 节能模式（如 IEEE 802.11 标准中所定义），则：

  • 每当应用通过 WifiManager.createWifiLock() 和 WifiManager.WifiLock.acquire() API 获取 WIFI_MODE_FULL_HIGH_PERF 锁定或 WIFI_MODE_FULL_LOW_LATENCY 锁定并且锁定处于活动状态时，都应关闭 Wi-Fi 节能模式。
  • [C-3-2] 当设备处于 Wi-Fi 低延迟锁定 (WIFI_MODE_FULL_LOW_LATENCY) 模式时，设备和接入点之间的平均往返延迟必须小于 Wi-Fi 高性能锁定 (WIFI_MODE_FULL_HIGH_PERF) 模式下的延迟。
  • [C-SR-3] 每当低延迟锁定 (WIFI_MODE_FULL_LOW_LATENCY) 已获取并生效时，都强烈建议将 Wi-Fi 往返延迟降至最低。

如果设备实现支持 Wi-Fi 并将 Wi-Fi 用于位置信息扫描，则：

7.4.2.1. Wi-Fi 直连

设备实现：

  • 应支持 Wi-Fi 直连（Wi-Fi 对等连接）。

如果设备实现支持 Wi-Fi 直连，则：

  • [C-1-1] 必须实现对应的 Android API（如 SDK 文档中所述）。
  • [C-1-2] 必须报告硬件功能 android.hardware.wifi.direct。
  • [C-1-3] 必须支持常规的 Wi-Fi 操作。
  • [C-1-4] 必须支持并发执行 Wi-Fi 和 Wi-Fi 直连操作。
  • [C-SR-1] 强烈建议使用随机的源 MAC 地址进行所有新建的 Wi-Fi 直连连接。

设备实现：

如果设备实现支持 TDLS，并且 TDLS 已由 WiFiManager API 启用，则：

  • [C-1-1] 必须通过 WifiManager.isTdlsSupported 声明支持 TDLS。
  • 只在能够使用且有好处时才应使用 TDLS。
  • 应进行一些试探，如果使用 TDLS 时的性能可能低于通过 Wi-Fi 接入点连接时的性能，不应使用 TDLS。
7.4.2.3. Wi-Fi 感知

设备实现：

如果设备实现支持 Wi-Fi 感知，并使该功能可供第三方应用使用，则：

  • [C-1-1] 必须实现 WifiAwareManager API（如 SDK 文档中所述）。
  • [C-1-2] 必须声明 android.hardware.wifi.aware 功能标志。
  • [C-1-3] 必须支持并发执行 Wi-Fi 和 Wi-Fi 感知操作。
  • [C-1-4] 除非 Wi-Fi 感知操作正在进行或感知数据路径可用，否则每当 Wi-Fi 感知处于启用状态时，都必须以不超过 30 分钟的间隔对 Wi-Fi 感知管理接口地址进行随机化处理（只要数据路径可用，就不需要进行随机化处理）。

如果设备实现支持 Wi-Fi 感知和 Wi-Fi 位置信息服务（如第 7.4.2.5 节中所述），并使这些功能可供第三方应用使用，则：

7.4.2.4. Wi-Fi Passpoint

如果设备实现支持 802.11 (Wi-Fi)，则：

  • [C-1-1] 必须支持 Wi-Fi Passpoint。
  • [C-1-2] 必须实现与 Passpoint 相关的 WifiManager API（如 SDK 文档中所述）。
  • [C-1-3] 必须支持 IEEE 802.11u 标准，特别是与网络发现和选择相关的标准，例如通用通告服务协议 (GAS) 和接入网络查询协议 (ANQP)。
  • [C-1-4] 必须声明 android.hardware.wifi.passpoint 功能标志。
  • [C-1-5] 必须遵从 AOSP 实现来发现、匹配 Passpoint 网络或与其相关联。
  • [C-1-6] 必须至少支持 Wi-Fi Alliance Passpoint R2 中定义的设备配置协议的以下子集：EAP-TTLS 身份验证和 SOAP-XML。
  • [C-1-7] 必须按照 Hotspot 2.0 R3 规范要求处理 AAA 服务器证书。
  • [C-1-8] 必须支持用户通过 Wi-Fi 选择器控制预配。
  • [C-1-9] 必须在重新启动后永久保留 Passpoint 配置。
  • [C-SR-1] 强烈建议支持条款及条件接受功能。
  • [C-SR-2] 强烈建议支持场地信息功能。

如果提供了全局 Passpoint 停用用户控制开关，那么实现：

  • [C-3-1] 必须默认启用 Passpoint。
7.4.2.5. Wi-Fi 位置信息（Wi-Fi 往返时间 - RTT）

设备实现：

如果设备实现支持 Wi-Fi 位置信息，并使该功能可供第三方应用使用，则：

  • [C-1-1] 必须实现 WifiRttManager API（如 SDK 文档中所述）。
  • [C-1-2] 必须声明 android.hardware.wifi.rtt 功能标志。
  • [C-1-3] 当执行 RTT 所在的 Wi-Fi 接口与接入点不相关时，必须为所执行的每个 RTT 高峰对源 MAC 地址进行随机化处理。
  • [C-1-4] 必须在 80 MHz 带宽的第 68 个百分位处精确到 2 米以内（使用累积分布函数计算得出）。
  • [C-SR-1] 强烈建议在 80 MHz 带宽的第 68 个百分位处将报告精确到 1.5 米以内（使用累积分布函数计算得出）。
7.4.2.6. Wi-Fi Keepalive 分流

设备实现：

  • 应支持 Wi-Fi keepalive 分流。

如果设备实现支持 Wi-Fi keepalive 分流，并使该功能可供第三方应用使用，则：

  • [C-1-1] 必须支持 SocketKeepAlive API。
  • [C-1-2] 必须支持至少三个 Wi-Fi 上的并发 keepalive 槽

如果设备实现不支持 Wi-Fi keepalive 分流，则：

7.4.2.7. Wi-Fi Easy Connect（设备配置协议）

设备实现：

如果设备实现支持 Wi-Fi Easy Connect，并使该功能可供第三方应用使用，则：

7.4.2.8. 企业 Wi-Fi 服务器证书验证

如果 Wi-Fi 服务器证书未通过验证或 Wi-Fi 服务器域名未设置，设备实现：

  • [C-SR-1] 强烈建议不要向用户提供在“设置”应用中手动添加企业 Wi-Fi 网络的选项。
7.4.2.9. 首次使用时信任 (TOFU)

如果设备实现支持首次使用时信任 (TOFU)，并允许用户定义 WPA-Enterprise/WPA2-Enterprise/WPA3-Enterprise 配置，则：

  • [C-4-1] 必须为用户提供使用 TOFU 的选项。

7.4.3. 蓝牙

如果设备实现支持蓝牙音频配置，则：

  • 应支持高级音频编解码器和蓝牙音频编解码器（例如 LDAC）

如果设备实现支持 HFP、A2DP 和 AVRCP，则：

  • 应至少共支持 5 个连接设备。

如果设备实现声明 android.hardware.vr.high_performance 功能，则：

  • [C-1-1] 必须支持蓝牙 4.2 和蓝牙 LE 数据长度扩展。

Android 支持蓝牙和蓝牙低功耗。

如果设备实现支持蓝牙和蓝牙低功耗，则：

  • [C-2-1] 必须声明相关平台功能（分别为 android.hardware.bluetooth 和 android.hardware.bluetooth_le ），并实现平台 API。
  • 应实现适合设备的相关蓝牙配置文件，例如 A2DP、AVRCP、OBEX 和 HFP 等。

如果设备实现支持蓝牙低功耗 (BLE)，则：

  • [C-3-1] 必须声明硬件功能 android.hardware.bluetooth_le。
  • [C-3-2] 必须启用基于 GATT（通用属性配置文件）的蓝牙 API（如 SDK 文档中所述）以及 android.bluetooth。
  • [C-3-3] 必须针对 BluetoothAdapter.isOffloadedFilteringSupported() 报告正确的值，以指明是否实现了针对 ScanFilter API 类的过滤逻辑。
  • [C-3-4] 必须针对 BluetoothAdapter.isMultipleAdvertisementSupported() 报告正确的值，以指明是否支持低功耗通告。

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

  • 应支持在实现 ScanFilter API 时将过滤逻辑分载到蓝牙芯片组。

  • 应支持将批量扫描分载到蓝牙芯片组。

  • 应支持至少为 4 个槽的多通告。

如果设备实现支持蓝牙 LE 并将蓝牙 LE 用于位置信息扫描，则：

  • [C-4-1] 必须提供一种方式，让用户能够启用/停用通过系统 API BluetoothAdapter.isBleScanAlwaysAvailable() 读取的值。

如果设备实现支持蓝牙 LE 和助听器配置文件（如使用蓝牙 LE 的助听器音频支持中所述），则：

如果设备实现支持蓝牙或蓝牙低功耗，则：

  • [C-6-1] 除非发出请求的应用成功通过 android.permission.ACCESS_FINE_LOCATION 权限检查（根据其当前前台/后台状态），否则必须限制对任何可用于推导设备位置信息的蓝牙元数据（例如扫描结果）的访问权限。

如果设备实现支持蓝牙或蓝牙低功耗，并且应用清单中未包含开发者声明其不会从蓝牙推导位置信息的声明，则：

如果设备实现针对 BluetoothAdapter.isLeAudioSupported() API 返回 true，则：

  • [C-7-1] 必须支持单播客户端。
  • [C-7-2] 必须支持 2M PHY。
  • [C-7-3] 必须支持 LE 扩展广播。
  • [C-7-4] 必须在 CIG 中支持至少 2 个 CIS 连接。
  • [C-7-5] 必须同时启用 BAP 单播客户端、CSIP 集协调器、MCP 服务器、VCP 控制器、CCP 服务器。
  • [C-SR-1] 强烈建议启用 HAP 单播客户端。

如果设备实现针对 BluetoothAdapter.isLeAudioBroadcastSourceSupported() API 返回 true，则：

  • [C-8-1] 必须在 BIG 中支持至少 2 个 BIS 链接。
  • [C-8-2] 必须同时启用 BAP 广播源和 BAP 广播助理程序。
  • [C-8-3] 必须支持 LE 定期通告。

如果设备实现针对 BluetoothAdapter.isLeAudioBroadcastAssistantSupported() API 返回 true，则：

  • [C-9-1] 必须支持 PAST（定期广播同步传输）。
  • [C-9-2] 必须支持 LE 定期通告。

如果设备实现声明 FEATURE_BLUETOOTH_LE，则：

  • [C-10-1] 对于在视线环境中与以 ADVERTISE_TX_POWER_HIGH 进行传输的参考设备相距 1 米时进行的测量，必须有 95% 的 RSSI 测量结果在 +/-9dB 的范围内。

  • [C-10-2] 必须包含 Rx/Tx 修正以减小每个通道的偏差，以便在各个天线（如果使用多个天线）上对这 3 个通道分别进行测量时，95% 的测量结果彼此之间的偏差都不超过 +/-3dB。

  • [C-SR-2] 强烈建议测量并补偿 Rx 偏移，以确保在与以 ADVERTISE_TX_POWER_HIGH 进行传输的参考设备相距 1 米时，BLE RSSI 中位数为 -60dBm +/-10 dB（要将设备置于正确方向，使各设备都位于“平行平面”上，且屏幕朝向相同的方向）。

  • [C-SR-3] 强烈建议测量并补偿 Tx 偏移，以确保从相距 1 米且以 ADVERTISE_TX_POWER_HIGH 进行传输的参考设备进行扫描时，BLE RSSI 中位数为 -60dBm +/-10 dB（要将设备置于正确方向，使各设备都位于“平行平面”上，且屏幕朝向相同的方向）。

    将要求 [C-10-3] 和 [C-10-4] 移到了 2.2.1. 硬件。

  • [C-10-3] 必须测量并补偿 Rx 偏移，以确保在与以 ADVERTISE_TX_POWER_HIGH 进行传输的参考设备相距 1 米时，BLE RSSI 中位数为 -55dBm +/-10 dB。
  • [C-10-4] 必须测量并补偿 Tx 偏移，以确保从相距 1 米且以 ADVERTISE_TX_POWER_HIGH 进行传输的参考设备进行扫描时，BLE RSSI 中位数为 -55dBm +/-10 dB。

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

如果设备实现支持蓝牙 5.0 版，则：

  • [C-SR-4] 强烈建议支持：
    • LE 2M PHY
    • LE 编解码器 PHY
    • LE 广播扩展项
    • 定期广播
    • 至少 10 个广播集
    • 至少 8 个 LE 并发连接。每个连接可以采用任一连接拓扑角色。
    • LE 链路层隐私保护
    • 至少包含 8 个条目的“解析列表”

7.4.4. 近距离无线通信

设备实现：

  • 应包含近距离无线通信 (NFC) 所需的收发器和相关硬件。
  • [C-0-1] 必须实现 android.nfc.NdefMessage 和 android.nfc.NdefRecord API，即使它们不支持 NFC 或未声明 android.hardware.nfc 功能也是如此，因为这些类表示独立于协议的数据表示格式。

如果设备实现包含 NFC 硬件，并计划使其可供第三方应用使用，则：

  • [C-1-1] 必须通过 android.content.pm.PackageManager.hasSystemFeature() 方法报告 android.hardware.nfc 功能。
  • 必须能够通过以下 NFC 标准读取和写入 NDEF 消息：
  • [C-1-2] 必须能够通过以下 NFC 标准充当 NFC Forum 读取器/写入器（如 NFC Forum 技术规范 NFCForum-TS-DigitalProtocol-1.0 中所定义）：
    • NfcA (ISO14443-3A)
    • NfcB (ISO14443-3B)
    • NfcF (JIS X 6319-4)
    • IsoDep (ISO 14443-4)
    • NFC Forum 标签类型 1、2、3、4、5（由 NFC Forum 定义）

  • [C-SR-1] 强烈建议能够通过以下 NFC 标准读取和写入 NDEF 消息以及原始数据。请注意，虽然此处说这些 NFC 标准是“强烈建议”遵循的标准，但我们计划在未来版本的兼容性定义文档中将其更改为“必须”遵循的标准。这些标准在此版本中是可选的，但在未来的版本中将是必须要遵循的。强烈建议运行此版 Android 的现有设备及新设备现在就满足这些要求，以便能够升级到未来的平台版本。

  • [C-1-13] 在 NFC 发现模式下，必须轮询所有支持的技术。

  • 当设备处于唤醒状态、屏幕处于活动状态，并且锁定屏幕未锁定时，应采用 NFC 发现模式。

  • 应能够读取 Thinfilm NFC Barcode 产品的条形码和网址（如果已编码）。

请注意，上面提到的 JIS、ISO 和 NFC Forum 规范没有公开提供的链接。

Android 支持 NFC 主机卡模拟 (HCE) 模式。

如果设备实现包含支持 HCE（适用于 NfcA 和/或 NfcB）的 NFC 控制器芯片组，并且支持应用 ID (AID) 路由，则：

  • [C-2-1] 必须报告 android.hardware.nfc.hce 功能常量。
  • [C-2-2] 必须支持 NFC HCE API（如 Android SDK 中定义）。

如果设备实现包含支持 HCE（适用于 NfcF）的 NFC 控制器芯片组，并且针对第三方应用实现了该功能，则：

  • [C-3-1] 必须报告 android.hardware.nfc.hcef 功能常量。
  • [C-3-2] 必须实现 NfcF 卡模拟 API（如 Android SDK 中所定义）。

如果设备实现支持常规 NFC（如本节中所述），并且支持读取器/写入器角色中的 MIFARE 技术（MIFARE Classic、MIFARE Ultralight、NDEF on MIFARE Classic），则：

  • [C-4-1] 必须实现对应的 Android API（如 Android SDK 中所述）。
  • [C-4-2] 必须通过 android.content.pm.PackageManager.hasSystemFeature() 方法报告 com.nxp.mifare 功能。请注意，这不是标准的 Android 功能，因此不会在 android.content.pm.PackageManager 类中显示为常量。

7.4.5. 网络协议和 API

7.4.5.1. 最低网络功能

设备实现：

  • [C-0-1] 必须支持一种或多种形式的数据网络。具体而言，设备实现必须支持至少一种能够达到 200 Kbit/sec 或更高的数据标准。满足此要求的技术包括 EDGE、HSPA、EV-DO、802.11g、以太网和蓝牙 PAN。
  • 当物理网络标准（例如以太网）是主要数据连接标准时，还应支持至少一种常用的无线数据连接标准，例如 802.11 (Wi-Fi)。
  • 可以实现多种形式的数据连接。
7.4.5.2. IPv6

设备实现：

  • [C-0-2] 必须包含 IPv6 网络堆栈，并支持使用受管理 API（例如 java.net.Socket 和 java.net.URLConnection）以及原生 API（例如 AF_INET6 套接字）进行 IPv6 通信。
  • [C-0-3] 必须默认启用 IPv6。
    • 必须确保 IPv6 通信和其他通信（例如 IPv4）一样可靠：
      • [C-0-4] 在低电耗模式下必须保持 IPv6 连接。
      • [C-0-5] 限制发送次数不得导致设备断开与任何符合 IPv6 标准的网络（使用的 RA 生命周期至少为 180 秒）的 IPv6 连接。
  • [C-0-6] 连接到 IPv6 网络时，必须为第三方应用提供与网络的直接 IPv6 连接，无需在设备本地进行任何形式的地址或端口转换。受管理 API（例如 Socket#getLocalAddress 或 Socket#getLocalPort）和 NDK API（例如 getsockname() 或 IPV6_PKTINFO）都必须返回实际上用于发送和接收网络上的数据包，并作为来源 IP 和互联网 (Web) 服务器端口显示的 IP 地址和端口。

所需的 IPv6 支持级别取决于网络类型，如以下要求中所示。

如果设备实现支持 Wi-Fi，则：

  • [C-1-1] 必须支持通过 Wi-Fi 执行双栈和 IPv6-only 操作。

如果设备实现支持以太网，则：

  • [C-2-1] 必须支持通过以太网执行双栈和 IPv6 单栈操作。

如果设备实现支持移动数据网络，则：

  • [C-3-1] 必须支持通过移动网络执行 IPv6 操作（IPv6 单栈操作，也可能是双栈操作）。

如果设备实现支持多种类型的网络（例如 Wi-Fi 和移动数据网络），则：

  • [C-4-1] 当设备同时连接到多种类型的网络时，必须同时满足上述针对连接到每种网络的要求。
7.4.5.3. 强制门户

强制门户是指需要登录才能访问互联网的网络。

如果设备实现提供 android.webkit.Webview API 的完整实现，则：

  • [C-1-1] 必须提供一个强制门户应用来处理 ACTION_CAPTIVE_PORTAL_SIGN_IN intent，并通过在调用系统 API ConnectivityManager#startCaptivePortalApp(Network, Bundle) 时发送该 intent 来显示强制门户登录页面。
  • [C-1-2] 当设备连接至任何类型的网络（包括移动网络、Wi-Fi、以太网或蓝牙）时，必须执行强制门户检测并支持通过强制门户应用登录。
  • [C-1-3] 当设备配置为使用专用 DNS 严格模式时，必须支持使用明文 DNS 登录强制门户。
  • [C-1-4] 必须按照 SDK 文档中关于 android.net.LinkProperties.getPrivateDnsServerName 和 android.net.LinkProperties.isPrivateDnsActive 的说明对所有未明确与强制门户通信的网络流量使用加密 DNS。
  • [C-1-5] 必须确保在用户登录强制门户时，应用所用的默认网络（由 ConnectivityManager.getActiveNetwork 和 ConnectivityManager.registerDefaultNetworkCallback 返回，并默认由 java.net.Socket 等 Java 网络 API 以及 connect() 等原生 API 使用）是任何其他可提供互联网连接的网络（如果有）。

7.4.6. 同步设置

设备实现：

7.4.7. 流量节省程序

如果设备实现包含按流量计费的网络连接，则：

  • [C-SR-1] 强烈建议提供流量节省程序模式。

如果设备实现提供流量节省程序模式，则：

  • [C-1-1] 必须支持 ConnectivityManager 类中的所有 API（如 SDK 文档中所述）

如果设备实现未提供流量节省程序模式，则：

7.4.8. 安全元件

如果设备实现支持 Open Mobile API 安全元件，并使其可供第三方应用使用，则：

7.4.9. UWB

如果设备实现支持 802.1.15.4，并将该功能提供给第三方应用使用，则：

  • [C-1-1] 必须在 android.uwb 中实现相应的 Android API。
  • [C-1-2] 必须报告硬件功能标志 android.hardware.uwb。
  • [C-1-3] 必须支持 Android 实现中定义的所有相关 UWB 配置文件。
  • [C-1-4] 必须提供一种用户功能，让用户能够切换 UWB 无线装置的开启/关闭状态。
  • [C-1-5] 必须强制要求使用 UWB 无线装置的应用拥有（NEARBY_DEVICES 权限组中的）UWB_RANGING 权限。
  • [C-SR-1] 强烈建议通过标准组织（包括 FIRA、CCC、CSA）定义的相关一致性和认证测试。
  • [C-1-6] 对于在非反射室中相距 1 米的视线环境中进行的测量，必须确保 95% 的测量结果符合以下条件：距离测量结果在 +/-15 厘米的范围内。
  • [C-1-7] 必须确保在与参考设备相距 1 米处进行测量时，测量结果的中位数在 [0.75 米，1.25 米] 以内（要测量被测设备顶部边缘与地面的真实距离，被测设备正面朝上且倾斜 45 度）。
  • [C-SR-2] 强烈建议遵循距离测量校准要求中指定的测量设置步骤。

7.5. 摄像头

如果设备实现包含至少一个摄像头，则：

  • [C-1-1] 必须声明 android.hardware.camera.any 功能标志。
  • [C-1-2] 当摄像头打开着以进行基本预览和静态拍摄时，必须确保应用可以同时分配 3 个 RGBA_8888 位图，并且其大小与设备上分辨率最高的摄像头传感器所生成的图片相同。
  • [C-1-3] 必须确保处理 MediaStore.ACTION_IMAGE_CAPTURE、MediaStore.ACTION_IMAGE_CAPTURE_SECURE 或 MediaStore.ACTION_VIDEO_CAPTURE intent 的预安装默认摄像头应用负责先移除图像元数据中的用户位置信息，再将其发送至接收应用（如果接收应用没有 ACCESS_FINE_LOCATION）。

如果设备实现支持 HDR 10 位输出功能，则：

  • [C-2-1] 所有支持 10 位输出的摄像头设备都必须至少支持 HLG HDR 配置。
  • [C-2-2] 主后置摄像头或主前置摄像头必须支持 10 位输出。
  • [C-SR-1] 强烈建议两个主摄像头均支持 10 位输出。
  • [C-2-3] 逻辑摄像头的所有支持 BACKWARD_COMPATIBLE 的物理子摄像头以及逻辑摄像头本身都必须支持相同的 HDR 配置文件。

对于支持 10 位 HDR 并实现 android.hardware.camera2.CaptureRequest#CONTROL_ZOOM_RATIO API 的逻辑摄像头设备，则：

  • [C-3-1] 必须支持通过逻辑摄像头上的 CONTROL_ZOOM_RATIO 控件在所有向后兼容的物理摄像头之间切换。

7.5.1. 后置摄像头

后置摄像头指位于设备上背向屏幕一侧的摄像头，也就是说，与传统摄像头一样，它拍摄的是背向设备屏幕一侧的景物。

新要求开始

后置摄像头是指朝向外面的摄像头，与传统摄像头一样，它拍摄的是背向设备一侧的景物；在手持设备上，这是指位于设备上背向显示屏一侧的摄像头。

新要求结束

设备实现：

  • 应包含后置摄像头。

如果设备实现包含至少一个后置摄像头，则：

  • [C-1-1] 必须报告功能标志 android.hardware.camera 和 android.hardware.camera.any。
  • [C-1-2] 分辨率必须至少为 200 万像素。
  • 应在摄像头驱动程序中实现硬件自动对焦或软件自动对焦（对应用软件透明）。
  • 可以具有固定焦距硬件或 EDOF（扩展景深）硬件。
  • 可以包含闪光灯。

如果摄像头包含闪光灯，则：

  • [C-2-1] 当已在摄像头预览 Surface 上注册 android.hardware.Camera.PreviewCallback 实例时，闪光灯不得亮起，除非应用已通过启用 Camera.Parameters 对象的 FLASH_MODE_AUTO 或 FLASH_MODE_ON 属性明确启用闪光灯。请注意，此项限制不适用于设备的内置系统摄像头应用，而仅适用于使用 Camera.PreviewCallback。

7.5.2. 前置摄像头

前置摄像头指与设备上的显示屏位于同一侧的摄像头，也就是通常用于拍摄用户自己的摄像头，例如用于视频会议及类似应用的摄像头。

新要求开始

前置摄像头是指朝向用户的摄像头，通常用于拍摄用户，例如用于视频会议或类似应用的摄像头；在手持设备上，这是指与设备上的显示屏位于同一侧的摄像头。

新要求结束

设备实现：

  • 可以包含前置摄像头。

如果设备实现包含至少一个前置摄像头，则：

  • [C-1-1] 必须报告功能标志 android.hardware.camera.any 和 android.hardware.camera.front。
  • [C-1-2] 分辨率必须至少为 VGA（640x480 像素）。
  • [C-1-3] 不得将前置摄像头用作 Camera API 的默认摄像头，并且不得将该 API 配置为将前置摄像头视为默认后置摄像头，即使它是设备上的唯一摄像头也是如此。
  • [C-1-4] 如果当前应用已通过调用 android.hardware.Camera.setDisplayOrientation() 方法明确请求旋转摄像头显示方向，则必须相对于应用指定的方向水平镜像摄像头预览。反之，如果当前应用未通过调用 android.hardware.Camera.setDisplayOrientation() 方法明确请求旋转摄像头显示方向，则必须沿着设备的默认水平轴镜像预览。
  • [C-1-5] 对于最终拍好后返回给应用回调或提交到媒体存储空间的静态图像或视频流，不得对其进行镜像。
  • [C-1-6] 必须按照镜像摄像头预览图像流时的方式镜像由 postview 显示的图像。
  • 可以包含可供后置摄像头（如第 7.5.1 节中所述）使用的功能，例如自动对焦、闪光灯等。

如果用户能够旋转设备实现（例如通过加速度计自动旋转或通过用户输入手动旋转），则：

  • [C-2-1] 必须相对于设备的当前方向水平镜像摄像头预览。

7.5.3. 外接摄像头

新要求开始

外接摄像头是指可以随时以物理方式与设备连接或分离，并可朝向任何方向的摄像头；例如 USB 摄像头。

新要求结束

设备实现：

  • 可以支持无需一直连接到设备的外接摄像头。

如果设备实现支持外接摄像头，则：

  • [C-1-1] 必须声明平台功能标志 android.hardware.camera.external 和 android.hardware camera.any。
  • [C-1-2] 如果通过 USB 主机端口连接外接摄像头，则必须支持 USB Video Class（UVC 1.0 或更高版本）。
  • [C-1-3] 必须在连接实体外接摄像头设备的情况下通过摄像头 CTS 测试。有关摄像头 CTS 测试的详细信息，请参阅 source.android.com。
  • 应支持 MJPEG 等视频压缩格式，以便传输高品质的未编码串流（即原始照片串流或独立压缩的照片串流）。
  • 可以支持多个摄像头。
  • 可以支持基于摄像头的视频编码。

如果支持基于摄像头的视频编码，则：

  • [C-2-1] 并发的未编码/MJPEG 流（QVGA 或更高分辨率）必须可供设备实现访问。

7.5.4. Camera API 行为

Android 包含两个用于访问摄像头的 API 包，较新的 android.hardware.camera2 API 使应用可以对摄像头进行较低级别的控制，包括高效的零复制连拍/视频串流，以及按帧对曝光、增益、白平衡增益、颜色转换、去噪、锐化等进行控制。

较旧的 API 软件包 android.hardware.Camera 在 Android 5.0 中被标为已废弃，但由于该软件包应仍可供应用使用，因此 Android 设备实现必须确保持续支持该 API（如本节和 Android SDK 中所述）。

已废弃的 android.hardware.Camera 类和较新的 android.hardware.camera2 软件包都具备的功能在这两种 API 中的性能和质量必须相当。例如，具有等效设置，自动对焦速度和精确度必须完全相同，且所拍图片的质量必须相同。依赖这两种 API 的不同语义的功能无需在速度和质量方面保持一致，但应尽可能保持一致。

设备实现必须为所有可用的摄像头实现摄像头相关 API 的以下行为。设备实现：

  • [C-0-1] 对于提供给应用回调的预览数据，必须使用 android.hardware.PixelFormat.YCbCr_420_SP（如果应用从未调用过 android.hardware.Camera.Parameters.setPreviewFormat(int)）。
  • [C-0-2] 如果应用注册了 android.hardware.Camera.PreviewCallback 实例，系统调用了 onPreviewFrame() 方法，并且预览格式为 YCbCr_420_SP，则传递到 onPreviewFrame() 中的 byte[] 格式的数据必须进一步采用 NV21 编码格式。也就是说，NV21 必须是默认设置。
  • [C-0-3] 对于 android.hardware.Camera，设备实现必须支持使用 YV12 格式（用 android.graphics.ImageFormat.YV12 常量表示）进行前置摄像头和后置摄像头的摄像头预览。（硬件视频编码器和摄像头可以使用任何原生像素格式，但设备实现必须支持转换为 YV12。）
  • [C-0-4] 对于在 android.request.availableCapabilities 中通告 REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE 功能的 android.hardware.camera2 设备，必须通过 android.media.ImageReader API 支持使用 android.hardware.ImageFormat.YUV_420_888 和 android.hardware.ImageFormat.JPEG 作为输出格式。
  • [C-0-5] 仍必须实现 Android SDK 文档中包含的完整 Camera API，无论设备是否包含硬件自动对焦或其他功能都是如此。例如，没有自动对焦功能的摄像头仍必须调用所有已注册的 android.hardware.Camera.AutoFocusCallback 实例（即使这与非自动对焦摄像头无关）。请注意，这适用于前置摄像头。例如，虽然大多数前置摄像头都不支持自动对焦，但仍必须如所述那样“伪造”API 回调。
  • [C-0-6] 必须识别并遵从 android.hardware.Camera.Parameters 类和 android.hardware.camera2.CaptureRequest 类中定义为常量的每个参数名称。反之，设备实现不得遵从或识别传递给 android.hardware.Camera.setParameters() 方法的字符串常量，在 android.hardware.Camera.Parameters 中载述为常量的字符串常量除外。也就是说，设备实现必须支持所有标准摄像头参数（如果硬件允许），不得支持自定义摄像头参数类型。例如，如果设备实现支持使用高动态范围 (HDR) 成像技术拍照，则必须支持摄像头参数 Camera.SCENE_MODE_HDR。
  • [C-0-7] 必须通过 android.info.supportedHardwareLevel 属性报告正确的支持级别（如 Android SDK 中所述），并报告相应的框架功能标志。
  • [C-0-8] 还必须通过 android.request.availableCapabilities 属性声明 android.hardware.camera2 的各项摄像头功能，并声明相应的功能标志；如果连接的任何摄像头设备支持某项功能，则必须定义相应的功能标志。
  • [C-0-9] 每当摄像头拍摄了新照片且相应的照片条目已添加到媒体存储区时，都必须广播 Camera.ACTION_NEW_PICTURE intent。
  • [C-0-10] 每当摄像头录制了新视频且相应的视频条目已添加到媒体存储区时，都必须广播 Camera.ACTION_NEW_VIDEO intent。
  • [C-0-11] 必须使所有摄像头都可通过已废弃的 android.hardware.Camera API 以及 android.hardware.camera2 API 访问。
  • [C-0-12] 对于任何 android.hardware.camera2 或 android.hardware.Camera API，必须确保不改变面部外观，包括但不限于改变面部几何形状、面部肤色或面部皮肤平滑化。
  • [C-SR-1] 对于多个 RGB 摄像头距离很近且朝向同一方向的设备，强烈建议支持列出 CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA 功能的逻辑摄像头设备，包含所有和物理子设备一样朝向该方向的 RGB 摄像头。

如果设备实现向第三方应用提供专有摄像头 API，则：

7.5.5. 摄像头方向

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

  • [C-1-1] 必须朝向正确方向，以便摄像头的长度方向与屏幕的长度方向对齐。也就是说，当设备处于横向时，摄像头必须横向拍摄。无论设备的自然方向为何，此规则都适用；也就是说，它适用于以横屏为主的设备以及以竖屏为主的设备。

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

  • 设备采用可变形屏幕，例如可折叠显示屏或合页式显示屏。
  • 当设备的折叠或合页状态发生变化时，设备会在以竖屏为主和以横屏为主的方向之间切换。

新要求开始

  • 用户无法旋转的设备实现，例如汽车设备。

新要求结束

7.6. 内存和存储空间

7.6.1. 最小内存和存储空间

设备实现：

  • [C-0-1] 必须包含可供应用下载数据文件的内容下载管理器，并且应用必须能够将不小于 100 MB 的各个文件下载到默认的“缓存”位置。

7.6.2. 应用共享的存储空间

设备实现：

  • [C-0-1] 必须提供可供应用共享的存储空间，该存储空间通常也称为“共享外部存储空间”或“应用共享的存储空间”，或者也可以通过该存储空间装载到的 Linux 路径“/sdcard”来指代它。
  • [C-0-2] 必须配有默认装载的（也就是说可以直接使用的）共享存储空间：可以在内部存储组件上或可移动存储媒介（例如安全数字卡插槽）上实现该存储空间。
  • [C-0-3] 必须直接在 Linux 路径 sdcard 中装载应用共享存储空间，或包含一个从 sdcard 指向实际装载点的 Linux 符号链接。
  • [C-0-4] 除以下情况外，必须对以 API 级别 29 或更高级别的所有应用默认启用分区存储：
    • 当应用在其清单中请求了 android:requestLegacyExternalStorage="true" 时。
  • [C-0-5] 必须遮盖通过 MediaStore 访问的媒体文件中存储的位置元数据（如 GPS Exif 标签），发出调用的应用具有 ACCESS_MEDIA_LOCATION 权限时除外。

设备实现可以使用以下两者之一来满足上述要求：

  • 可供用户使用的可移动存储设备，例如安全数字 (SD) 卡插槽。
  • Android 开源项目 (AOSP) 中实现的内部（不可移动）存储空间的一部分。

如果设备实现使用可移动存储设备来满足上述要求，则：

  • [C-1-1] 必须实现在插槽中未插入存储媒介时警告用户的消息框或弹出界面。
  • [C-1-2] 必须包含经过 FAT 格式化的存储媒介（例如 SD 卡），或者在包装箱上以及购买时随附的其他材料上注明需单独购买存储媒介。

如果设备实现使用不可移动存储空间的一部分来满足上述要求，则：

  • 应使用内部应用共享存储空间的 AOSP 实现。
  • 可以与应用专属数据共享存储空间。

如果设备实现具有支持 USB 外围设备模式的 USB 端口，则：

  • [C-3-1] 必须提供一种用于从主机访问应用共享存储空间内的数据的机制。
  • 应通过 Android 的媒体扫描程序服务和 android.provider.MediaStore 透明地公开上述两个存储空间路径中的内容。
  • 可以使用 USB 大容量存储设备，但应使用媒体传输协议来满足此要求。

如果设备实现具有支持 USB 外围设备模式的 USB 端口，并且支持媒体传输协议，则：

  • 应与 Android MTP 参考主机（Android 文件传输）兼容。
  • 应报告 USB 设备类 0x00。
  • 应报告 USB 接口名称“MTP”。

7.6.3. 可合并的存储设备

如果设备应具有移动性（不同于 TV），则对于设备实现：

  • [C-SR-1] 强烈建议在长期不变的固定位置实现可合并的存储设备，因为意外断开它们可能会导致数据丢失/损坏。

如果可移动存储设备端口位于长期不变的固定位置（例如电池盒或其他防护盖内），则对于设备实现：

7.7. USB

如果设备实现具有 USB 端口，则：

  • 应支持 USB 外围设备模式，并且应支持 USB 主机模式。
  • 应支持通过 USB 停用数据信号传输。

7.7.1. USB 外围设备模式

如果设备实现包含支持外围设备模式的 USB 端口，则：

  • [C-1-1] 该端口必须可连接到具有标准 A 型或 C 型 USB 端口的 USB 主机。
  • [C-1-2] 必须通过 android.os.Build.SERIAL 在 USB 标准设备描述符中为 iSerialNumber 报告正确的值。
  • [C-1-3] 如果它们支持 C 型 USB，必须根据 C 型电阻标准检测 1.5A 和 3.0A 充电器，并检测通告中的变化。
  • [C-SR-1] 该端口应使用 micro-B 型、micro-AB 型或 C 型 USB 外形规格。强烈建议现有和新推出的 Android 设备满足这些要求，以便能够升级到未来的平台版本。
  • [C-SR-2] 该端口应位于设备底部（根据自然方向），或为所有应用（包括主屏幕）启用软件屏幕旋转功能，以便设备在按照该端口位于底部的方位放置时，屏幕能够正确呈现内容。强烈建议现有和新推出的 Android 设备满足这些要求，以便能够升级到未来的平台版本。
  • [C-SR-3] 应支持在 HS 线性调频和流量传输期间采用 1.5 A 电流（如 USB 电池充电规范 - 修订版 1.2 中所规定）。强烈建议现有和新推出的 Android 设备满足这些要求，以便能够升级到未来的平台版本。
  • [C-SR-4] 强烈建议不要支持会修改高于默认电压的 Vbus 电压或更改接收端/源端角色的专有充电方法，因为这样可能会导致支持标准 USB Power Delivery 方法的充电器或设备出现互操作性问题。虽然此处说的是“强烈建议”，但在未来的 Android 版本中，我们可能会要求所有 C 型端口的设备支持与标准 C 型充电器进行完全互操作。
  • [C-SR-5] 如果它们支持 C 型 USB 和 USB 主机模式，则强烈建议支持 Power Delivery 以进行数据角色和电源角色交换。
  • 应支持 Power Delivery 以进行高压充电，并且应支持显示输出等替代模式。
  • 应实现 Android Open Accessory (AOA) API 和规范（如 Android SDK 文档中所述）。

如果设备实现包含 USB 端口，并且实现了 AOA 规范，则：

  • [C-2-1] 必须声明支持硬件功能 android.hardware.usb.accessory。
  • [C-2-2] USB 大容量存储设备类必须在 USB 大容量存储设备的接口描述 iInterface 字符串末尾添加字符串“android”
  • 不应实现 Android Open Accessory Protocol 2.0 文档中载述的 AOAv2 音频。从 Android 8.0（API 26 级）开始，AOAv2 音频便被废弃了。

7.7.2. USB 主机模式

如果设备实现包含支持主机模式的 USB 端口，则：

  • [C-1-1] 必须实现 Android USB 主机 API（如 Android SDK 中所述），并声明支持硬件功能 android.hardware.usb.host。
  • [C-1-2] 必须支持连接标准 USB 外围设备，也就是说，它们必须满足以下条件之一：
    • 具有设备自带的 C 型端口，或附带用于将设备自带的专有端口适配到标准 USB C 型端口（USB C 型设备）的数据线。
    • 具有设备自带的 A 型端口，或附带用于将设备自带的专有端口适配到标准 USB A 型端口的数据线。
    • 具有设备自带的 micro-AB 型端口，该端口应附带用于适配到标准 A 型端口的数据线。
  • [C-1-3] 不得附带将 USB A 型端口或 micro-AB 端口转接到 C 型端口（插口）的适配器。
  • [C-SR-1] 强烈建议实现 USB 音频类（如 Android SDK 文档中所述）。
  • 应支持在主机模式下为连接的 USB 外围设备充电；为 USB C 型连接器使用至少 1.5A 的源电流（如 USB C 型数据线和连接器规范 - 修订版 1.2 中的“端接参数”部分所规定），或为 Micro-AB 型连接器使用充电下行端口 (CDP) 输出电流范围（如 USB 电池充电规范 - 修订版 1.2 中所规定）。
  • 应实现并支持与 USB C 型相关的标准。

如果设备实现包含支持主机模式和 USB 音频类的 USB 端口，则：

  • [C-2-1] 必须支持 USB HID 类。
  • [C-2-2] 必须支持检测 USB HID 用法表和语音指令用法请求中指定的以下 HID 数据字段，并支持将其映射到 KeyEvent 常量，如下所示：
    • 用法页 (0xC) 用法 ID (0x0CD)：KEYCODE_MEDIA_PLAY_PAUSE
    • 用法页 (0xC) 用法 ID (0x0E9)：KEYCODE_VOLUME_UP
    • 用法页 (0xC) 用法 ID (0x0EA)：KEYCODE_VOLUME_DOWN
    • 用法页 (0xC) 用法 ID (0x0CF)：KEYCODE_VOICE_ASSIST

如果设备实现包含支持主机模式和存储访问框架 (SAF) 的 USB 端口，则：

  • [C-3-1] 必须识别任何远程连接的 MTP（媒体传输协议）设备并通过 ACTION_GET_CONTENT、ACTION_OPEN_DOCUMENT 和 ACTION_CREATE_DOCUMENT intent 使其内容可访问。。

如果设备实现包含支持主机模式和 USB C 型的 USB 端口，则：

  • [C-4-1] 必须实现双角色端口功能，如 USB C 型规范（第 4.5.1.3.3 节）所定义。对于双角色端口，在包含 3.5 毫米音频耳机插孔的设备上，USB 接收器检测（主机模式）可以默认处于关闭状态，但必须能让用户启用该检测。
  • [C-SR-2] 强烈建议支持 DisplayPort，应支持 USB SuperSpeed 数据传输速率，并且强烈建议支持 Power Delivery 以进行数据角色和电源角色交换。
  • [C-SR-3] 强烈建议不要支持耳机插孔转换器配件模式（如 USB C 型数据线和连接器规范 - 修订版 1.2 的附录 A 中所述）。
  • 应实现最适合设备外形规格的 Try.* 模型。例如，手持设备应实现 Try.SNK 模型。

7.8. 音频

7.8.1. 麦克风

如果设备实现包含麦克风，则：

  • [C-1-1] 必须报告 android.hardware.microphone 功能常量。
  • [C-1-2] 必须满足第 5.4 节中的录音要求。
  • [C-1-3] 必须满足第 5.6 节中的音频延迟要求。
  • [C-SR-1] 强烈建议支持近超声录音（如第 7.8.3 节中所述）。

如果设备实现省略了麦克风，则：

  • [C-2-1] 不得报告 android.hardware.microphone 功能常量。
  • [C-2-2] 必须至少按照第 7 节中的规定将录音 API 实现为空操作。

7.8.2. 音频输出

如果设备实现包含扬声器，或包含用于连接音频输出外围设备的音频/多媒体输出端口（例如 4 导体 3.5 毫米音频插孔或使用 USB 音频类的 USB 主机模式端口），则：

  • [C-1-1] 必须报告 android.hardware.audio.output 功能常量。
  • [C-1-2] 必须满足第 5.5 节中的音频播放要求。
  • [C-1-3] 必须满足第 5.6 节中的音频延迟要求。
  • [C-SR-1] 强烈建议支持近超声播放（如第 7.8.3 节中所述）。

如果设备实现不包含扬声器或音频输出端口，则：

  • [C-2-1] 不得报告 android.hardware.audio.output 功能。
  • [C-2-2] 必须至少将与音频输出机制相关的 API 实现为空操作。

在本节中，“输出端口”是指实体接口，例如 3.5 毫米音频插孔、HDMI 端口，或使用 USB 音频类的 USB 主机模式端口。支持通过无线协议（例如蓝牙、Wi-Fi 或移动网络）输出音频不算作包含“输出端口”。

7.8.2.1. 模拟音频端口

为了兼容 Android 生态系统中使用 3.5 毫米音频插头的耳机和其他音频配件，如果设备实现包含一个或多个模拟音频端口，则：

  • [C-SR-1] 强烈建议至少有一个音频端口为 4 导体 3.5 毫米音频插孔。

如果设备实现具有 4 导体 3.5 毫米音频耳机插孔，则：

  • [C-1-1] 必须支持将音频播放到带麦克风的立体声头戴式耳机和立体声耳机。
  • [C-1-2] 必须支持采用 CTIA 引脚顺序的 TRRS 音频插头。
  • [C-1-3] 必须支持检测音频插头上的麦克风导体和接地导体之间以下 3 个范围的等效阻抗，并支持将其映射到相应的键码：
    • 70 欧姆或更低：KEYCODE_HEADSETHOOK
    • 210-290 欧姆：KEYCODE_VOLUME_UP
    • 360-680 欧姆：KEYCODE_VOLUME_DOWN
  • [C-1-4] 必须在插入插头时触发 ACTION_HEADSET_PLUG，但只能在插头上的所有触点都已接触到耳机插孔上各自的相关部分后才能触发。
  • [C-1-5] 必须能够在 32 欧姆扬声器阻抗上驱动至少 150 mV ± 10% 的输出电压。
  • [C-1-6] 麦克风偏置电压必须介于 1.8 V 到 2.9 V 之间。
  • [C-1-7] 必须检测音频插头上的麦克风导体和接地导体之间以下范围的等效阻抗，并且必须将其映射到相应的键码：
    • 110-180 欧姆：KEYCODE_VOICE_ASSIST
  • [C-SR-2] 强烈建议支持具有 OMTP 引脚顺序的音频插头。
  • [C-SR-3] 强烈建议支持使用带麦克风的立体声耳机进行录音。

如果设备实现具有 4 导体 3.5 毫米音频插孔，支持麦克风，并且广播 android.intent.action.HEADSET_PLUG（其中包含一个设置为 1 的额外参数“microphone”），则：

  • [C-2-1] 必须支持检测插入的音频配件上是否有麦克风。
7.8.2.2. 数字音频端口

请参阅第 2.2.1 节，了解设备专属要求。

7.8.3. 近超声

近超声音频的频带为 18.5 kHz 到 20 kHz。

设备实现：

如果 PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND 为“true”，VOICE_RECOGNITION 和 UNPROCESSED 音频源必须满足以下要求：

  • [C-1-1] 麦克风在 18.5 kHz 到 20 kHz 频带之间的平均功率响应不得比 2 kHz 下的响应低 15 dB 以上。
  • [C-1-2] 对于 -26 dBFS 的 19 kHz 音调，麦克风在 18.5 kHz 到 20 kHz 频带内的不加权信噪比不得低于 50 dB。

如果 PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND 为“true”：

  • [C-2-1] 扬声器在 18.5 kHz 到 20 kHz 之间的平均响应与在 2 kHz 下的响应相比，不能低于后者 40 dB 以上。

7.8.4. 信号完整性

设备实现：

  • 应同时为手持设备上的输入和输出信息流提供无干扰音频信号路径，如进行每路径一分钟测试时测量的零干扰所定义。使用 OboeTester“自动干扰测试”进行测试。

测试需要直接用于 3.5 毫米耳机插孔和/或与 USB-C 至 3.5 毫米适配器配合使用的音频环回适配器。应测试所有音频输出端口。

OboeTester 目前支持 AAudio 路径，因此应使用 AAudio 测试以下组合是否有干扰：

性能模式 分享 输出采样率 输入通道 输出通道
LOW_LATENCY 独占 未指定 1 2
LOW_LATENCY 独占 未指定 2 1
LOW_LATENCY 已共享 未指定 1 2
LOW_LATENCY 已共享 未指定 2 1
无 已共享 48000 1 2
无 已共享 48000 2 1
无 已共享 44100 1 2
无 已共享 44100 2 1
无 已共享 16000 1 2
无 已共享 16000 2 1

可靠的信息流应符合 2,000 Hz 正弦的以下信噪比 (SNR) 和总谐波失真 (THD) 标准。

变频器 THD SNR
主要内置扬声器，使用外部参考麦克风测量 < 3.0% >= 50 dB
主要内置麦克风，使用外部参考扬声器测量 < 3.0% >= 50 dB
内置模拟 3.5 毫米耳机插孔，使用环回适配器测试 < 1% >= 60 dB
电话随附的 USB 适配器，使用环回适配器测试 < 1.0% >= 60 dB

7.9. 虚拟实境

Android 包含用于构建“虚拟实境”(VR) 应用（提供高品质的移动 VR 体验）的 API 和工具。设备实现必须正确实现本节中详细介绍的这些 API 和行为。

7.9.1. 虚拟现实 (VR) 模式

Android 支持 VR 模式，该模式用于处理通知的立体呈现，并会在 VR 应用获得用户聚焦时停用单目系统界面组件。

7.9.2. 虚拟实境模式 - 高性能

如果设备实现支持 VR 模式，则：

  • [C-1-1] 必须有至少 2 个实体核心。
  • [C-1-2] 必须声明 android.hardware.vr.high_performance 功能。
  • [C-1-3] 必须支持持续性能模式。
  • [C-1-4] 必须支持 OpenGL ES 3.2。
  • [C-1-5] 必须支持 android.hardware.vulkan.level 0。
  • 应支持 android.hardware.vulkan.level 1 或更高版本。
  • [C-1-6] 必须实现 EGL_KHR_mutable_render_buffer、EGL_ANDROID_front_buffer_auto_refresh、EGL_ANDROID_get_native_client_buffer、EGL_KHR_fence_sync、EGL_KHR_wait_sync、EGL_IMG_context_priority、EGL_EXT_protected_content 和 EGL_EXT_image_gl_colorspace，并在可用 EGL 扩展列表中公开这些扩展。
  • [C-1-8] 必须实现 GL_EXT_multisampled_render_to_texture2、GL_OVR_multiview、GL_OVR_multiview2 和 GL_EXT_protected_textures，并在可用 GL 扩展列表中公开这些扩展。
  • [C-SR-1] 强烈建议实现 GL_EXT_external_buffer、GL_EXT_EGL_image_array 和 GL_OVR_multiview_multisampled_render_to_texture，并在可用 GL 扩展列表中公开这些扩展。
  • [C-SR-2] 强烈建议支持 Vulkan 1.1。
  • [C-SR-3] 强烈建议实现 VK_ANDROID_external_memory_android_hardware_buffer、VK_GOOGLE_display_timing 和 VK_KHR_shared_presentable_image，并在可用 Vulkan 扩展列表中公开这些扩展。
  • [C-SR-4] 强烈建议公开至少一个 Vulkan 队列系列，其中 flags 包含 VK_QUEUE_GRAPHICS_BIT 和 VK_QUEUE_COMPUTE_BIT，且 queueCount 至少为 2。
  • [C-1-7] GPU 和显示屏必须能够同步访问共享的前端缓冲区，以便在两个呈现环境中以 60fps 的速率交替呈现 VR 内容时，没有可见的撕裂现象。
  • [C-1-9] 必须支持 AHardwareBuffer 标志 AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER、AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA 和 AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT（如 NDK 中所述）。
  • [C-1-10] 必须支持 AHardwareBuffer 和用法标志 AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT、AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE 及 AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT 至少以下列格式之一进行任意组合：AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM、AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM、AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM、AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT。
  • [C-SR-5] 强烈建议支持分配在 C-1-10 中指定的具有多个层的 AHardwareBuffer，以及各种标志和格式。
  • [C-1-11] 必须支持以至少 3840 x 2160 @ 30fps 的分辨率且压缩到平均 40 Mbps 的速度（相当于 4 个 1920 x 1080 @ 30 fps-10 Mbps 实例或 2 个 1920 x 1080 @ 60 fps-20 Mbps 实例）进行 H.264 解码。
  • [C-1-12] 必须支持 HEVC 和 VP9，必须能够以至少 1920 x 1080 @ 30 fps 的分辨率且压缩到平均 10 Mbps 的速度进行解码，并且应能够以 3840 x 2160 @ 30 fps-20 Mbps 的分辨率和速度进行解码（相当于 4 个 1920 x 1080 @ 30 fps-5 Mbps 实例）。
  • [C-1-13] 必须支持 HardwarePropertiesManager.getDeviceTemperatures API，并返回表层温度的准确值。
  • [C-1-14] 必须包含嵌入式屏幕，且其分辨率必须至少为 1920 x 1080。
  • [C-SR-6] 强烈建议屏幕分辨率至少为 2560 x 1440。
  • [C-1-15] 屏幕在 VR 模式下的更新率必须至少为 60 Hz。
  • [C-1-17] 屏幕必须支持低持久性模式（持久性小于等于 5 毫秒），持久性指像素发光的时长。
  • [C-1-18] 必须支持蓝牙 4.2 和蓝牙 LE 数据长度扩展（第 7.4.3 节）。
  • [C-1-19] 对于以下所有默认传感器类型，必须支持并正确报告直接通道类型：
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [C-SR-7] 对于上面列出的所有直接通道类型，强烈建议支持 TYPE_HARDWARE_BUFFER 直接通道类型。
  • [C-1-21] 对于 android.hardware.hifi_sensors，必须满足与陀螺仪、加速度计和磁力计相关的要求（如第 7.3.9 节中所规定）。
  • [C-SR-8] 强烈建议支持 android.hardware.sensor.hifi_sensors 功能。
  • [C-1-22] 从运动到成像的端到端延迟时间不得超过 28 毫秒。
  • [C-SR-9] 强烈建议从运动到成像的端到端延迟不超过 20 毫秒。
  • [C-1-23] 第一帧率（即第一帧上从黑过渡到白之后的像素亮度与白色像素处于稳定状态的亮度之间的比率）必须至少为 85%。
  • [C-SR-10] 强烈建议第一帧率至少为 90%。
  • 可以为前台应用提供专用核心，并且可以支持 Process.getExclusiveCores API，以便返回专供最靠前的前台应用使用的 CPU 核心数。

如果支持专属核心，则该核心：

  • [C-2-1] 不得允许任何其他用户空间进程（应用使用的设备驱动程序除外）在其上运行，但在必要时可以允许一些内核进程在其上运行。

7.10. 触感反馈

新要求开始

打算手持或穿戴的设备可以配备通用触感反馈致动器，可供应用用于多种用途，包括通过铃声、闹钟、通知和常规触摸反馈来吸引用户的注意力。

如果设备实现不包含此类通用触感反馈致动器，则：

  • [7.10/C] 必须针对 Vibrator.hasVibrator() 返回 false。

如果设备实现包含至少一个此类通用触感反馈致动器，则：

如果设备实现遵循触感反馈常量映射，则：

新要求结束

请参阅第 2.2.1 节，了解设备专属要求。

7.11. 媒体性能等级

可以从 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS API 获取设备实现的媒体性能等级。从 R（版本 30）开始，为每个 Android 版本定义了媒体性能等级的要求。特殊值 0 表示设备不必遵循媒体性能等级要求。

如果设备实现为 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 返回非零值，则：

  • [C-1-1] 必须至少返回 android.os.Build.VERSION_CODES.R 的一个值。

  • [C-1-2] 必须是手持设备实现。

  • [C-1-3] 必须满足第 2.2.7 节中所述的“媒体性能等级”的所有相关要求。

换句话说，Android T 中的媒体性能等级是仅为搭载版本 T、S 或 R 的手持设备所定义的。

请参阅第 2.2.7 节，了解设备专属要求。

8. 性能与功耗

有些最低性能和功耗标准对用户体验至关重要，并且会影响开发者在开发应用时所做的基准假设。

8.1. 用户体验一致性

如果有特定的最低要求来确保应用和游戏保持一致的帧速率和响应时间，则可以为最终用户提供流畅的界面。根据设备类型，设备实现可以有针对界面延迟和任务切换的可衡量要求（如第 2 节中所述）。

8.2. 文件 I/O 访问性能

通过提供在应用专属数据存储空间（/data 分区）上实现一致的文件访问性能所需的常用基准，应用开发者可以设定有助于进行软件设计的适当预期。根据设备类型，设备实现可以包含针对以下读取和写入操作的特定要求（如第 2 节中所述）：

  • 顺序写入性能：通过使用 10 MB 写入缓冲区写入一个 256 MB 的文件来衡量。
  • 随机写入性能：通过使用 4 KB 写入缓冲区写入一个 256 MB 的文件来衡量。
  • 顺序读取性能：通过使用 10 MB 写入缓冲区读取一个 256 MB 的文件来衡量。
  • 随机读取性能：通过使用 4 KB 写入缓冲区读取一个 256 MB 的文件来衡量。

8.3. 节能模式

如果设备实现包含可改进 AOSP 中的设备电源管理的功能（例如应用待机模式存储分区和低电耗模式），或者设备实现扩展了限制机制严格程度超过受限应用待机模式存储分区的功能，则：

  • [C-1-1] 节能模式（应用待机模式和低电耗模式）的触发、维护、唤醒算法以及对全局系统设置或 DeviceConfig 的使用都不得违背 AOSP 实现。
  • [C-1-2] 使用全局设置或 DeviceConfig 管理应用待机模式下每个存储分区中应用的作业、alarm 和网络节流都不得偏离 AOSP 实现。
  • [C-1-3] 应用待机模式所用应用待机模式存储分区的数量不得偏离 AOSP 实现。
  • [C-1-4] 必须实现应用待机模式存储分区和低电耗模式（如电源管理中所述）。
  • [C-1-5] 必须在设备处于节能模式时使 PowerManager.isPowerSaveMode() 返回 true。
  • [C-1-6] 必须提供一种方式，让用户能够查看免于进入应用待机模式和低电耗模式或任何电池优化的所有应用，并且必须实现 ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS intent 来请求用户允许应用忽略电池优化。
  • [C-SR-1] 强烈建议提供一种方式，让用户能够启用和停用省电模式。
  • [C-SR-2] 强烈建议提供一种方式，让用户能够查看免于进入应用待机模式和低电耗节能模式的所有应用。

如果设备实现扩展了 AOSP 中的电源管理功能，并且该扩展的限制机制比罕见应用待机模式存储分区更为严格，请参阅第 3.5.1 节。

除了节能模式之外，Android 设备实现还可以实现任意或全部 4 种休眠电源状态（如高级配置与电源接口 [ACPI] 中所定义）。

如果设备实现已实现 S4 电源状态（如 ACPI 中所定义），则：

  • [C-1-1] 必须仅在用户明确执行使设备处于不活动状态的操作（例如合上属于设备本身一部分的盖子或关闭车辆或电视）之后及用户重新激活设备（例如打开盖子或开启车辆或电视）之前进入此状态。

如果设备实现已实现 S3 电源状态（如 ACPI 中所定义），则：

  • [C-2-1] 必须满足上述 C-1-1 中的要求，或者必须仅在第三方应用不需要系统资源（例如，屏幕、CPU）时进入 S3 状态。

    相反，当第三方应用需要系统资源时，则必须退出 S3 状态，如本 SDK 中所述。

    例如，当第三方应用通过 FLAG_KEEP_SCREEN_ON 请求保持屏幕处于打开状态或通过 PARTIAL_WAKE_LOCK 请求 CPU 保持运行时，设备不得进入 S3 状态，除非用户明确执行使设备处于不活动状态的操作（如 C-1-1 中所述）。相反，当第三方应用通过 JobScheduler 实现的任务被触发或 Firebase Cloud Messaging 将其传递到第三方应用时，设备必须退出 S3 状态，除非用户使设备处于不活动状态。这些示例并不详尽，并且 AOSP 会实现大量可触发此状态唤醒的唤醒信号。

8.4. 功耗计算

更准确地计算和报告功耗有助于应用开发者找出能够优化应用功耗模式的措施和工具。

设备实现：

  • [C-SR-1] 强烈建议提供一个关于各组件功耗的配置文件，其中要定义每种硬件组件的耗电值，以及组件在一段时间内大概消耗的电量（如 Android 开源项目网站上所述）。
  • [C-SR-2] 强烈建议以毫安小时 (mAh) 为单位报告所有功耗值。
  • [C-SR-3] 强烈建议按每个进程的 UID 报告 CPU 功耗。Android 开源项目通过 uid_cputime 内核模块实现来满足此要求。
  • [C-SR-4] 强烈建议能让应用开发者通过 adb shell dumpsys batterystats shell 命令查看此功耗。
  • 如果无法将硬件组件的功耗归于某个应用，则应将其归于硬件组件本身。

8.5. 性能一致

高性能应用在长时间运行时，性能可能会因后台运行的其他应用或由于温度限制导致的 CPU 节流而出现大幅波动。Android 包含可编程接口，以便在设备胜任的情况下，最靠前的前台应用能够请求系统优化资源的分配，来应对这种波动。

设备实现：

如果设备实现报告支持持续性能模式，则：

  • [C-1-1] 必须能够让最靠前的前台应用至少在 30 分钟内保持稳定的性能水平（当该应用请求时）。
  • [C-1-2] 必须遵从 Window.setSustainedPerformanceMode() API 和其他相关 API。

如果设备实现包含两个或更多个 CPU 核心，则：

  • 应至少提供一个可预留给最靠前的前台应用使用的专用核心。

如果设备实现支持为最靠前的前台应用预留一个专用核心，则：

  • [C-2-1] 必须通过 Process.getExclusiveCores() API 方法报告可预留给最靠前的前台应用使用的专用核心的 ID 号。
  • [C-2-2] 不得允许任何用户空间进程（应用使用的设备驱动程序除外）在专用核心上运行，但在必要时可以允许一些内核进程在其上运行。

如果设备实现不支持专用核心，则：

9. 安全模型兼容性

设备实现：

  • [C-0-1] 必须实现与 Android 平台安全模型（如 Android 开发者文档 > API 指南 > 安全和权限参考文档中所定义）一致的安全模型。

  • [C-0-2] 必须支持安装自签名应用（无需从任何第三方/权威机构获得任何额外的权限/证书）。

如果设备实现声明 android.hardware.security.model.compatible 功能，则：

  • [C-1-1] 必须支持以下小节中列出的要求。

9.1. 权限

设备实现：

  • [C-0-1] 必须支持 Android 权限模型和 Android 角色模型（如 Android 开发者文档中所定义）。具体来说就是，必须强制执行定义的每个权限和角色（如 SDK 文档中所述）；不得省略、更改或忽略任何权限和角色。

  • 可以添加额外的权限，但前提是新权限的 ID 字符串不在 android.\* 命名空间内。

  • [C-0-2] protectionLevel 为 PROTECTION_FLAG_PRIVILEGED 的权限只能授予在系统映像（以及 APEX 文件）的特权路径中预安装的应用，并且此类权限只能位于明确为各个应用列入许可名单的权限的子集内。AOSP 实现通过以下方式来满足此要求：从 etc/permissions/ 路径下的文件中读取为各个应用列入许可名单的权限、遵从此类权限，并将 system/priv-app 路径用作特权路径。

保护级别为“危险”的权限属于运行时权限。targetSdkVersion 高于 22 的应用会在运行时请求这些权限。

设备实现：

  • [C-0-3] 必须显示一个专用界面，以便用户决定是否授予请求的运行时权限；此外还必须提供一个供用户管理运行时权限的界面。

  • [C-0-4] 对于这两个界面，必须有且只能有一个实现。

  • [C-0-5] 不得向应用授予任何运行时权限，除非：

    • 应用已在设备发货时安装；并且

    • 可以在应用使用相应权限之前获得用户同意。

      或者

    • 运行时权限是由默认权限授予政策授予，或用于充当某种平台角色。

  • [C-0-6] 必须仅将 android.permission.RECOVER_KEYSTORE 权限授予已注册采取适当安全措施的恢复代理的系统应用。采取适当安全措施的恢复代理是指符合以下条件的设备内置软件代理：可与设备外远程存储空间同步，且配有安全硬件，提供的保护功能相当于或优于 Google Cloud Key Vault Service 中所述的保护功能，可防止暴力破解攻击锁屏验证凭据。

设备实现：

  • [C-0-7] 当应用通过标准 Android API 或专有机制请求位置或身体活动数据时，必须遵循 Android 位置权限属性。此类数据包括但不限于：

    • 设备的位置信息（例如纬度和经度），如第 9.8.8 节中所述。
    • 可用于确定或估计设备位置的信息（例如 SSID、BSSID、小区 ID，或设备连接到的网络的位置）。
    • 用户的身体活动或身体活动的分类。

更具体地说，设备实现：

  • [C-0-8] 必须征得用户同意，应用才能访问位置信息或身体活动数据。
  • [C-0-9] 必须仅向具有足够权限（如 SDK 中所述）的应用授予运行时权限。例如，TelephonyManager#getServiceState 需要 android.permission.ACCESS_FINE_LOCATION。

上述 Android 位置信息权限属性的唯一例外情况是，应用不会访问位置信息来推导或标识用户位置信息；具体而言：

  • 在应用拥有 RADIO_SCAN_WITHOUT_LOCATION 权限时。
  • 在进行设备配置和设置时，系统应用拥有 NETWORK_SETTINGS 或 NETWORK_SETUP_WIZARD 权限。

权限可标记为限制更改其行为。

  • [C-0-10] 具有 hardRestricted 标志的权限不得被授予应用，除非：

    • 应用 APK 文件在系统分区中。
    • 用户将与 hardRestricted 权限关联的角色分配给应用。
    • 安装程序将 hardRestricted 授予应用。
    • 应用在早期 Android 版本中被授予 hardRestricted。

  • [C-0-11] 拥有 softRestricted 权限的应用只能获得有限访问权限，不得获取完全访问权限，除非如 SDK 中所述被列入许可名单，其中为每个 softRestricted 权限（例如 READ_EXTERNAL_STORAGE）定义了完全和有限访问权限。

  • [C-0-12] 不得提供任何自定义函数或 API 来绕过 setPermissionPolicy 和 setPermissiongrantState API 中定义的权限限制。

  • [C-0-13] 必须使用 AppOpsManager API 来记录和跟踪对受 Android 活动和服务提供的危险权限保护的数据的每次程序化访问。

  • [C-0-14] 只能将角色分配给功能符合角色要求的应用。

  • [C-0-15] 不得定义与平台定义的角色重复或为这些角色功能的超集的角色。

如果设备报告 android.software.managed_users，则：

  • [C-1-1] 不得由管理员以静默方式授予以下权限：
    • 位置信息（ACCESS_BACKGROUND_LOCATION、ACCESS_COARSE_LOCATION、ACCESS_FINE_LOCATION）。
    • 摄像头 (CAMERA)
    • 麦克风 (RECORD_AUDIO)
    • 身体传感器 (BODY_SENSORS)
    • 身体活动 (ACTIVITY_RECOGNITION)

如果设备实现提供了一种方式，让用户能够选择哪些应用可以借助处理 ACTION_MANAGE_OVERLAY_PERMISSION intent 的 activity 在其他应用的最上层显示内容，则：

  • [C-2-1] 必须确保针对 ACTION_MANAGE_OVERLAY_PERMISSION intent 具有 intent 过滤器的所有 activity 都具有相同的界面屏幕，无论启动应用或它提供的任何信息如何。

如果设备实现报告了 android.software.device_admin，则：

  • [C-3-1] 在全代管式设备设置（设备所有者设置）期间，必须显示免责声明，阐明 IT 管理员将能够允许应用控制手机上的设置（包括麦克风、摄像头和位置信息），并提供选项以便用户继续设置或退出设置；除非管理员已选择不控制设备上的权限。

如果设备实现预安装持有 System UI Intelligence、System Ambient Audio Intelligence、System Audio Intelligence、System Notification Intelligence、System Text Intelligence 或 System Visual Intelligence 角色的任何软件包，那么软件包：

  • [C-4-1] 必须满足“9.8.6 内容捕获”“9.8.6 操作系统级数据和环境数据”和“9.8.15 沙盒化 API 实现”小节中针对设备实现列出的所有要求。

  • [C-4-2] 不得拥有 android.permission.INTERNET 权限。这项要求的严格程度要比第 9.8.6 节中列出的“强烈建议”要求高。
  • [C-4-3] 不得绑定到其他应用，但以下系统应用除外：蓝牙、通讯录、媒体、电话、系统界面以及提供互联网 API 的组件。这项要求的严格程度要比第 9.8.6 节中列出的“强烈建议”要求高。

新要求开始

如果设备实现包含支持 VoiceInteractionService 的默认应用，则：

  • [C-5-1] 不得授予 ACCESS_FINE_LOCATION 作为该应用的默认权限。

新要求结束

9.2. UID 和进程隔离

设备实现：

  • [C-0-1] 必须支持 Android 应用沙盒模型。在该模型中，每个应用都是在单独的进程中作为独一无二的 Unixstyle UID 运行。
  • [C-0-2] 必须支持以同一 Linux 用户 ID 运行多个应用，但前提是这些应用已经过适当签名，并采用了适当的构建方式（如安全和权限参考文档中所定义）。

9.3. 文件系统权限

设备实现：

9.4. 替代执行环境

设备实现必须能够使 Android 安全性和权限模型保持一致性，即使它们包含存在以下情况的运行时环境也是如此：使用除了 Dalvik 可执行文件格式或原生代码以外的一些其他软件或技术来执行应用。也就是说：

  • [C-0-1] 替代运行时本身必须是 Android 应用，并且遵循标准的 Android 安全模型（如第 9 节中的其他部分所述）。

  • [C-0-2] 不得授权替代运行时访问受以下权限保护的资源：未在替代运行时的 AndroidManifest.xml 文件中通过 <uses-permission> 机制请求的权限。

  • [C-0-3] 替代运行时不得允许应用使用受仅限系统应用享有的 Android 权限保护的功能。

  • [C-0-4] 替代运行时必须遵循 Android 沙盒模型，并且使用替代运行时的安装式应用不得重复使用设备上已安装的任何其他应用的沙盒，除非通过共享用户 ID 和签名证书这两种标准 Android 机制。

  • [C-0-5] 不得使用对应于其他 Android 应用的沙盒启动替代运行时，不得向替代运行时授予对这些沙盒的访问权限，替代运行时也不得向其他应用授予此类访问权限。

  • [C-0-6] 不得使替代运行时在启动时获得超级用户 (root) 或任何其他用户 ID 的任何权限，不得向替代运行时授予任何此类权限，替代运行时也不得向其他应用授予任何此类权限。

  • [C-0-7] 当替代运行时的 .apk 文件包含在设备实现的系统映像中时，它必须已签名，且签名时所用的密钥必须不同于对设备实现随附的其他应用签名时使用的密钥。

  • [C-0-8] 在安装应用时，替代运行时必须就应用使用的 Android 权限获得用户同意。

  • [C-0-9] 如果某个应用需要使用具有相应 Android 权限的设备资源（例如摄像头和 GPS 等），则替代运行时必须通知用户，让他们知道该应用将能够访问相应资源。

  • [C-0-10] 如果运行时环境不会以这种方式记录应用功能，则在安装任何使用该运行时的应用时，运行时环境都必须列出运行时自身拥有的所有权限。

  • 替代运行时应通过 PackageManager 将应用安装到单独的 Android 沙盒（Linux 用户 ID 等）中。

  • 替代运行时可以提供一个供所有使用替代运行时的应用共享的 Android 沙盒。

9.5. 多用户支持

Android 支持多用户功能，并支持完全用户隔离，还支持采取部分隔离的克隆用户资料（即类型为 android.os.usertype.profile.CLONE 的单个附加用户资料）。

  • 如果设备实现使用可移动媒介作为主要的外部存储空间，则可以但不应启用多用户功能。

如果设备实现支持多用户，则：

  • [C-1-2] 必须为每位用户实现与 Android 平台安全模型（如 API 指南内的安全和权限参考文档中定义）一致的安全模型。
  • [C-1-3] 对于每个用户实例，都必须在共享应用存储空间（也称为 /sdcard）中有单独的隔离目录。
  • [C-1-4] 必须确保归指定用户所有且以其名义运行的应用无法列出、读取或写入到归任何其他用户所有的文件中，即使双方的数据都存储在相同的卷或文件系统中也是如此。
  • [C-1-5] 如果设备实现针对外部存储 API 使用可移动媒介，则必须使用仅存储在只有系统可访问的不可移动媒介上的密钥对 SD 卡中的内容加密（如果启用了多用户功能）。这样会使主机 PC 无法读取相应媒介，所以设备实现将需要切换到 MTP 或类似系统，才能为主机 PC 提供访问当前用户的数据的权限。

如果设备实现支持多用户，对于除专门为运行同一应用的双实例而创建的用户之外的所有用户，则：

  • [C-2-1] 对于每个用户实例，都必须在共享应用存储空间（也称为 /sdcard）中有单独的隔离目录。
  • [C-2-2] 必须确保归指定用户所有且以其名义运行的应用无法列出、读取或写入到归任何其他用户所有的文件中，即使双方的数据都存储在相同的卷或文件系统中也是如此。

设备实现可以针对主要用户（并且仅针对主要用户）创建类型为 android.os.usertype.profile.CLONE 的单个附加用户资料，以便运行同一应用的双实例。这些双实例会共用部分隔离的存储空间，同时在启动器中呈现给最终用户，并显示在同一“最近”视图中。例如，这可用于支持用户在双 SIM 卡设备上安装单个应用的两个单独实例。

如果设备实现创建上述附加用户配置文件，则：

  • [C-3-1] 必须仅提供对父级用户资料已可访问或直接归此附加用户资料所有的存储空间或数据的访问权限。
  • [C-3-2] 不得将其设为工作资料。
  • [C-3-3] 必须将专用应用数据目录与父用户账号隔离开来。
  • [C-3-4] 如果存在预配设备所有者（请参阅第 3.9.1 节），就不得允许创建附加用户个人资料，也不得允许在不移除其他用户个人资料的情况下预配设备所有者。

新要求开始

如果设备实现创建上述附加用户配置文件，则：

  • [C-4-5] 在向用户呈现图标时，必须在视觉上区分双实例应用图标。
  • [C-4-6] 必须提供一种用户功能，用于删除整个克隆资料数据。
  • [C-4-7] 当用户选择删除所有克隆资料数据时，必须卸载所有克隆应用、删除专用应用数据目录及其内容，并删除克隆资料数据。
  • 应在删除最后一个克隆应用时提示用户删除整个克隆资料数据。
  • [C-4-8] 必须通知用户卸载克隆应用时会删除应用数据，或为用户提供一个用于在从设备上卸载应用时保留应用数据的选项。
  • [C-4-9] 如果用户在卸载期间选择删除数据，必须删除专用应用数据目录及其内容。

  • [C-4-14] 必须对在此附加资料中运行的应用进行单独的权限和存储管理

  • [C-4-5] 对于其他资料中具有启动器 activity 的应用，必须仅允许它们访问已可供父级用户资料访问的联系人。

新要求结束

9.6. 付费短信警告

Android 支持针对任何外发付费短信向用户发出警告。付费短信是指向已在运营商处注册且可能需要用户付费的服务发送的短信。

如果设备实现声明支持 android.hardware.telephony，则：

  • [C-1-1] 在向通过设备的 /data/misc/sms/codes.xml 文件中定义的正则表达式识别出的号码发送短信之前，必须警告用户。上游 Android 开源项目提供了满足此要求的实现。

9.7. 安全功能

设备实现必须确保符合内核及平台中的安全功能要求（如下所述）。

Android 沙盒包含使用安全增强型 Linux (SELinux) 强制访问控制 (MAC) 系统、seccomp 沙盒功能以及 Linux 内核中其他安全功能的功能。设备实现：

  • [C-0-1] 必须与现有应用保持兼容，即使 SELinux 或任何其他安全功能是在 Android 框架以下实现的。
  • [C-0-2] 当在 Android 框架以下实现的安全功能检测到并成功阻止安全违规行为时，不得显示可见界面；但当发生未被阻止的安全违规行为且该行为导致漏洞被成功利用时，则可以显示可见界面。
  • [C-0-3] 必须确保用户或应用开发者无法对 SELinux 或任何其他在 Android 框架以下实现的安全功能进行配置。
  • [C-0-4] 不得允许可通过 API（例如 Device Administration API）影响其他应用的应用配置会破坏兼容性的政策。
  • [C-0-5] 必须将媒体框架拆分为多个进程，以便能够更精细地为每个进程授予访问权限（如 Android 开源项目网站上所述）。
  • [C-0-6] 必须实现一种允许使用多线程程序中的可配置政策对系统调用进行过滤的内核应用沙盒机制。上游 Android 开源项目通过启用采用 threadgroup 同步 (TSYNC) 的 seccomp-BPF（如 source.android.com 上的“内核配置”部分所述）来满足此要求。

内核完整性和自保护功能对于确保 Android 安全性至关重要。设备实现：

  • [C-0-7] 必须实现内核堆栈缓冲区溢出保护机制。例如 CC_STACKPROTECTOR_REGULAR 和 CONFIG_CC_STACKPROTECTOR_STRONG 都属于这种机制。
  • [C-0-8] 当可执行代码为只读、只读数据不可执行且不可写入，以及可写入数据不可执行时，必须实现严格的内核内存保护机制（例如 CONFIG_DEBUG_RODATA 或 CONFIG_STRICT_KERNEL_RWX）。
  • [C-0-9] 必须在最初搭载 API 级别 28 或更高级别的设备上对用户空间和内核空间之间的副本（例如 CONFIG_HARDENED_USERCOPY）实现静态和动态对象尺寸边界检查。
  • [C-0-10] 不得在最初搭载 API 级别 28 或更高级别的设备上执行在内核模式下运行的用户空间内存（例如硬件 PXN，或通过 CONFIG_CPU_SW_DOMAIN_PAN 或 CONFIG_ARM64_SW_TTBR0_PAN 模拟）。
  • [C-0-11] 不得在最初搭载 API 级别 28 或更高级别的设备上在正常用户副本访问 API 之外对内核中的用户空间内存执行读取或写入操作（例如硬件 PAN，或通过 CONFIG_CPU_SW_DOMAIN_PAN 或 CONFIG_ARM64_SW_TTBR0_PAN 模拟）。
  • [C-0-12] 如果硬件容易受到 CVE-2017-5754 的攻击，则必须在最初搭载 API 级别 28 或更高级别的所有设备上实现内核页表隔离（例如 CONFIG_PAGE_TABLE_ISOLATION 或 CONFIG_UNMAP_KERNEL_AT_EL0）。

  • [C-0-13] 如果硬件容易受到 CVE-2017-5715 的攻击，必须在最初搭载 API 级别 28 或更高级别的设备上实现分支预测安全强化（例如 CONFIG_HARDEN_BRANCH_PREDICTOR）。

  • [C-SR-1] 强烈建议在内核中启用堆栈初始化，防止使用未初始化的局部变量（CONFIG_INIT_STACK_ALL 或 CONFIG_INIT_STACK_ALL_ZERO）。此外，设备实现不应假定编译器用于初始化局部变量的值。

  • [C-SR-2] 强烈建议使仅在初始化期间会被写入的内核数据在初始化之后被标记为只读（例如 __ro_after_init）。

  • [C-SR-3] 强烈建议对内核代码和内存的布局进行随机化处理，并避免会影响此项随机化处理的曝光（例如通过 /chosen/kaslr-seed Device Tree node 或 EFI_RNG_PROTOCOL 并采用引导加载程序熵执行 CONFIG_RANDOMIZE_BASE）。

  • [C-SR-4] 强烈建议在内核中启用控制流完整性 (CFI)，以针对代码重用攻击提供额外保护（例如 CONFIG_CFI_CLANG 和 CONFIG_SHADOW_CALL_STACK）。

  • [C-SR-5] 强烈建议不要在已启用控制流完整性 (CFI)、阴影调用堆栈 (SCS) 或整数溢出排错功能 (IntSan) 的组件上停用这些功能。

  • [C-SR-6] 强烈建议为任何其他对安全性要求较高的用户空间组件同时启用 CFI、SCS 和 IntSan（如 CFI 和 IntSan 中所述）。

  • [C-SR-7] 强烈建议在内核中启用堆栈初始化，防止使用未初始化的局部变量（CONFIG_INIT_STACK_ALL 或 CONFIG_INIT_STACK_ALL_ZERO）。此外，设备实现不应假定编译器用于初始化局部变量的值。

  • [C-SR-8] 强烈建议在内核中启用堆初始化，防止使用未初始化的堆分配 (CONFIG_INIT_ON_ALLOC_DEFAULT_ON)。此外，设备实现不应假定内核用于初始化这些分配的值。

如果设备实现使用能够支持 SELinux 的 Linux 内核，则：

  • [C-1-1] 必须实现 SELinux。
  • [C-1-2] 必须将 SELinux 设置为全局强制模式。
  • [C-1-3] 必须将所有域配置为强制模式。不允许使用宽容模式域，包括特定于设备/供应商的域。
  • [C-1-4] 对于 AOSP SELinux 域以及特定于设备/供应商的域，不得修改、省略或替换上游 Android 开源项目 (AOSP) 中提供的 system/sepolicy 文件夹中存在的 neverallow 规则，并且政策必须在所有 neverallow 规则都存在的情况下编译。
  • [C-1-5] 必须在按应用划分的 SELinux 沙盒中运行以 API 级别 28 或更高级别为目标的第三方应用，并对每个应用的专属数据目录设定应用级 SELinux 限制。
  • 应保留上游 Android 开源项目的 system/sepolicy 文件夹中提供的默认 SELinux 政策，并且应仅针对自己的设备特定配置向此政策进一步添加内容。

如果设备实现使用 Linux 以外的内核，或者使用不含 SELinux 的 Linux，则：

  • [C-2-1] 必须使用与 SELinux 相当的强制访问控制系统。

如果设备实现使用支持 DMA 的 I/O 设备，则：

  • [C-SR-9] 强烈建议使用 IOMMU（例如 ARM SMMU）隔离每个支持 DMA 的 I/O 设备。

Android 包含多项对设备安全性至关重要的深度防御功能。此外，Android 着重减少了会影响质量和安全性的关键类别的常见 bug。

为了减少内存 bug，我们针对设备实现提出如下建议：

  • [C-SR-10] 强烈建议使用用户空间内存错误检测工具（例如适用于 ARMv9 设备的 MTE、适用于 ARMv8 及更高版本设备的 HWASan 或适用于其他设备类型的 ASan）对其进行测试。
  • [C-SR-11] 强烈建议使用 KASAN（CONFIG_KASAN、适用于 ARMv9 设备的 CONFIG_KASAN_HW_TAGS、适用于 ARMv8 设备的 CONFIG_KASAN_SW_TAGS 或适用于其他设备类型的 CONFIG_KASAN_GENERIC）等内核内存错误检测工具对其进行测试。
  • [C-SR-12] 强烈建议在生产环境中使用内存错误检测工具，例如 MTE、GWP-ASan 和 KFENCE。

如果设备实现使用基于 ARM TrustZone 的 TEE，则：

  • [C-SR-13] 强烈建议在 Android 和 TEE 之间使用标准内存共享协议，例如适用于 Armv8-A 的 ARM 固件框架 (FF-A)。
  • [C-SR-14] 强烈建议将可信应用限制为仅访问已通过上述协议与其显式共享的内存。如果设备支持 ARM S-EL2 异常级别，应由安全分区管理器强制执行此操作。否则，应由 TEE 操作系统强制执行此操作。

新要求开始

内存安全技术可在使用 android:memtagMode 清单选项的应用中至少减少以下类别的 bug（概率较高，超过 90%）：

  • 堆缓冲区溢出
  • 释放后再使用
  • 双重释放
  • 错误释放（释放非 malloc 指针）

设备实现：

  • [C-SR-15] 强烈建议设置 ro.arm64.memtag.bootctl_supported。

如果设备实现将系统属性 ro.arm64.memtag.bootctl_supported 设置为 true，则：

  • [C-3-1] 必须允许系统属性 arm64.memtag.bootctl 接受以下值的逗号分隔列表，并在下次重新启动时应用所需的效果：

    • memtag：上文定义的内存安全技术已启用
    • memtag-once：上文定义的内存安全技术已暂时启用，并会在下次重新启动时自动停用
    • memtag-off：上文定义的内存安全技术已停用

  • [C-3-2] 必须允许 shell 用户设置 arm64.memtag.bootctl。

  • [C-3-3] 必须允许任何进程读取 arm64.memtag.bootctl。

  • [C-3-4] 必须在启动时将 arm64.memtag.bootctl 设置为当前请求的状态；如果设备实现允许在不更改系统属性的情况下修改状态，还必须更新该属性。

  • [C-SR-16] 强烈建议显示用于设置 memtag-once 和重新启动设备的开发者设置。借助兼容的引导加载程序，Android 开源项目可通过 MTE 引导加载程序协议来满足上述要求。

  • [C-SR-17] 强烈建议在“安全设置”菜单中显示用于允许用户启用 memtag 的设置。

新要求结束

9.8. 隐私设置

9.8.1. 使用情况历史记录

Android 会存储用户所做选择的历史记录，并会通过 UsageStatsManager 管理此类记录。

设备实现：

  • [C-0-1] 必须保证此类用户历史记录具有合理的保留期限。
  • [C-SR-1] 强烈建议在 AOSP 实现中保留默认配置的 14 天保留期限。

Android 使用 StatsLog 标识符存储系统事件，并通过 StatsManager 和 IncidentManager 系统 API 管理此类历史记录。

设备实现：

  • [C-0-2] 必须只包含系统 API 类 IncidentManager 创建的突发事件报告中标有 DEST_AUTOMATIC 的字段。
  • [C-0-3] 不得使用系统事件标识符来记录 StatsLog SDK 文档中所述事件外的任何其他事件。如果记录了其他系统事件，就可以使用 100,000 到 200,000 之间的其他 Atom 标识符。

9.8.2. 录制

设备实现：

  • [C-0-1] 不得预安装或分发开箱即用的软件组件，以免这些组件未经用户的同意或未发出持续显示的明确通知，便从设备上发出用户的私密信息（例如按键操作、屏幕上显示的文本、bug 报告）。
  • [C-0-2] 每当每次通过 MediaProjection.createVirtualDisplay()、VirtualDeviceManager.createVirtualDisplay() 或专有 API 启用启动用于截取屏幕投屏或屏幕录制的会话时，都必须显示用户警告并获得用户的明确同意，允许捕捉其屏幕上显示的任何敏感信息包括与 AOSP 完全相同的信息。不得让用户能够禁用未来显示用户同意。
  • [C-0-3] 启用屏幕投射或屏幕录制时，必须持续向用户显示通知。AOSP 通过在状态栏中持续显示通知图标来满足此要求。

新要求开始

如果设备实现在系统中包含用于捕获屏幕上显示的内容和/或录制设备上播放的音频串流的功能，而不是通过系统 API ContentCaptureService 或第 9.8.6 节“操作系统级数据和环境数据”中所述的其他专有方式，则：

  • [C-1-1] 每当此功能处于启用状态并主动捕获内容/录音时，必须持续向用户显示通知。

如果设备实现包含一个能够录制环境音频和/或录制设备上播放的音频（以便推断关于用户所在环境的实用信息）且开箱即启用的组件，则：

  • [C-2-1] 除非用户明确同意，否则不得将录制的原始音频或以下任何格式的音频存储在设备上的永久性存储空间内，也不得将其发送到设备以外的位置：可以转换回原始音频或转换为与原始音频近似的副本的格式。

“麦克风指示标志”是指屏幕上的视图，对用户始终可见且无法遮挡，用户理解为麦克风正在使用中（通过唯一文本、颜色、图标或任何组合）。

“摄像头指示标志”是指屏幕上的视图，对用户始终可见且无法遮挡，用户理解为摄像头正在使用中（通过唯一文本、颜色、图标或任何组合）。

在首次显示 1 秒之后，指示标志可以直观地发生变化（例如变小），不一定要按照最初呈现和理解的方式显示。

麦克风指示标志可以与主动显示的摄像头指示标志合并，前提是文本、图标或颜色向用户指示麦克风已开始使用。

摄像头指示标志可以与主动显示的麦克风指示标志合并，前提是文本、图标或颜色向用户指示摄像头已开始使用。

如果设备实现声明 android.hardware.microphone，则：

  • [C-SR-1] 应用从麦克风访问音频数据时，强烈建议显示麦克风指示标志，但如果仅 HotwordDetectionService、SOURCE_HOTWORD 和 ContentCaptureService 或拥有“第 9.1 节 - 权限”中使用 CDD 标识符 [C-3-X] 所列角色的应用访问麦克风，则无需显示麦克风指示标志。
  • [C-SR-2] 强烈建议根据从 PermissionManager.getIndicatorAppOpUsageData() 返回的内容显示使用麦克风的“最近用过”和“使用中”应用列表，以及与此类应用相关联的所有归因消息。
  • [C-SR-3] 对于具有可见界面或直接用户互动的系统应用，强烈建议不要隐藏麦克风指示标志。

如果设备实现声明 android.hardware.camera.any，则：

  • [C-SR-4] 应用访问实时摄像头数据时，强烈建议显示摄像头指示标志，但如果仅拥有“第 9.1 节 - 权限”中使用 CDD 标识符 [C-3-X] 所列角色的应用访问摄像头，则无需显示摄像头指示标志。
  • [C-SR-5] 强烈建议根据从 PermissionManager.getIndicatorAppOpUsageData() 返回的内容显示使用摄像头的“最近用过”和“使用中”应用，以及与此类应用相关联的所有归因消息。
  • [C-SR-6] 对于具有可见界面或直接用户互动的系统应用，强烈建议不要隐藏摄像头指示标志。

9.8.3. 连接性

如果设备实现具有支持 USB 外围设备模式的 USB 端口，则：

  • [C-1-1] 在允许通过 USB 端口访问共享存储空间的内容之前，必须先显示一个征求用户同意的界面。

9.8.4. 网络流量

设备实现：

  • [C-0-1] 必须为系统信任的证书授权机构 (CA) 存储区预安装根证书（与上游 Android 开源项目中提供的根证书相同）。
  • [C-0-2] 必须搭载空的用户根 CA 存储区。
  • [C-0-3] 当添加了用户根 CA 时，必须向用户显示警告，以指明网络流量可能会受到监控。

如果设备流量通过 VPN 路由，设备实现：

  • [C-1-1] 必须向用户显示警告，以指明以下两者之一：
    • 该网络流量可能会受到监控。
    • 该网络流量通过提供 VPN 的特定 VPN 应用传输。

如果设备实现具有一种通过代理服务器或 VPN 网关路由网络数据流量且开箱即默认启用的机制（例如预加载已被授予 android.permission.CONTROL_VPN 权限的 VPN 服务），则：

  • [C-2-1] 必须在启用该机制之前征求用户同意，除非相应 VPN 由设备政策控制器通过 DevicePolicyManager.setAlwaysOnVpnPackage() 启用，在这种情况下，用户不需要单独表示同意，只需收到通知即可。

如果设备实现具有一种方式，可让用户开启第三方 VPN 应用的“始终开启的 VPN”功能，则：

  • [C-3-1] 对于不支持“始终开启的 VPN”服务（在 AndroidManifest.xml 文件中将 SERVICE_META_DATA_SUPPORTS_ALWAYS_ON 属性设置为 false）的应用，必须停用此方式。

9.8.5. 设备标识符

设备实现：

  • [C-0-1] 必须防止应用访问设备序列号以及 IMEI/MEID、SIM 卡序列号和国际移动用户识别码 (IMSI)（如果适用），除非满足以下要求之一：
    • 是通过设备制造商验证的签名运营商应用。
    • 已被授予 READ_PRIVILEGED_PHONE_STATE 权限。
    • 具有如 UICC Carrier Privileges 中定义的运营商权限。
    • 是已被授予 READ_PHONE_STATE 权限的设备所有者或资料所有者。
    • （仅适用于 SIM 卡序列号/ICCID）当地法规要求应用检测订阅者身份的变化。

9.8.6. 内容捕获与应用搜索操作系统级数据和环境数据

Android 通过系统 API ContentCaptureService、AugmentedAutofillService、AppSearchGlobalManager.query 或其他专有方式支持设备实现机制，以捕获应用和用户之间的以下应用数据互动以下敏感数据：

  • 屏幕上呈现的文字和图形，包括但不限于通过 AssistStructure API 的通知和辅助数据。
  • 媒体数据，如设备录制或播放的音频或视频。
  • 输入事件（例如键、鼠标、手势、语音、视频和无障碍功能）。

新要求开始

  • 通过 AugmentedAutofillService 发送到系统的任何界面或其他数据。
  • 可通过 Content Capture API 访问的任何界面或其他数据。
  • 可通过 FieldClassificationService API 访问的任何界面或其他数据
  • 通过 AppSearchManager API 传递给系统且可通过 AppSearchGlobalManager.query 访问的任何应用数据。

新要求结束

  • 应用通过 Content Capture API、AppSearchManager API 或具有类似功能的 Android 专有 API 提供给系统的任何其他事件。

  • 通过 TextClassifier API 发送到系统 TextClassifier（即系统服务）以理解文本的含义，以及根据文本生成预测的后续操作的任何文本或其他数据。
  • 由平台 AppSearch 实现编入索引数据，包括但不限于文本、图形、媒体数据或其他类似数据。

新要求开始

  • 因使用语音识别程序实现的 SpeechRecognizer#onDeviceSpeechRecognizer() 而获得的音频数据。
  • 通过 AudioRecord、SoundTrigger 或其他音频 API 在后台（连续）获取的音频数据（获取此类数据的行为不会导致显示用户可见的指示器）
  • 通过 CameraManager 或其他相机 API 在后台（连续）获取的相机数据（获取此类数据的行为不会导致显示用户可见的指示器）

新要求结束

如果设备实现捕获上述任何数据，则：

  • [C-1-1] 必须加密设备中存储的所有此类数据。可以使用基于 Android 文件的加密或列为 API 版本 26+（如加密 SDK 中所述）的任何加密执行这种加密。
  • [C-1-2] 不得使用 Android 备份方法或任何其他备份方法备份原始或加密数据。
  • [C-1-3] 对于所有此类数据和日志，如要将其发送到设备以外的地方，必须仅使用可保护隐私的机制来发送，但以下情况除外：每次共享数据时都征得用户的明确同意。隐私保护机制是指“仅允许汇总分析并防止将记录的事件或派生的结果与个别用户匹配的机制”，以防止任何用户级数据被内省（如使用 RAPPOR 等差分隐私技术实现）。
  • [C-1-4] 不得将此类数据与设备上的任何用户身份（如 Account）相关联，在每次关联数据时获得用户的明确同意除外。
  • [C-1-5] 不得与其他不符合当前章节（9.8.6 内容捕获操作系统级数据和环境数据）中概述的要求的操作系统组件共享此类数据，但每次共享数据时都征得用户明确同意的情况除外。除非此类功能是作为 Android SDK API（AmbientContext、HotwordDetectionService）构建的。
  • [C-1-6] 必须提供一种方式，让用户能够清除ContentCaptureService实现或专有方式收集的数据（如果 当数据以任何形式存储在设备上时）。如果用户选择清除数据，必须移除所有收集到的历史数据。
  • [C-1-7] 必须提供一种方式，让用户能够选择停止在 Android 平台（例如启动器）中显示通过 AppSearch 或专有方式收集的数据。
  • [C-SR-1] 强烈建议不要请求 INTERNET 权限。
  • [C-SR-2] 强烈建议只通过由公开可用的开放源代码实现支持的结构化 API 访问互联网。

新要求开始

  • [C-SR-4] 强烈建议使用 Android SDK API 或 OEM 拥有的类似开源代码库实现；并且/或者在沙盒化实现中执行（请参阅第 9.8.15 节“沙盒化 API 实现”）。

新要求结束

如果设备实现包含实现系统 API ContentCaptureService 的服务、AppSearchManager.index 或任何捕获上述数据的专有服务，则：

  • [C-2-1] 不得允许用户将该服务替换为用户可安装应用或服务，而只能允许预安装的服务捕获此类数据。
  • [C-2-2] 不得允许除预安装服务机制外的任何应用能够捕获此类数据。
  • [C-2-3] 必须提供一种方式，让用户能够停用该服务。
  • [C-2-4] 不得遗漏一种方式，让用户能够管理该服务保留的 Android 权限并遵循 Android 权限模型（如第 9.1 节 - “权限”中所述）。

  • [C-SR-3] 强烈建议确保该服务与其他系统组件保持独立（例如，不绑定该服务或共享进程 ID），但以下情况除外：

    • 电话、通讯录、系统界面和媒体

Android 通过 SpeechRecognizer#onDeviceSpeechRecognizer() 能够在设备上执行语音识别，而无需涉及网络。设备上 SpeechRecognizer 的任何实现必须遵循本节中概述的政策。

9.8.7. 剪贴板访问权限

设备实现：

  • [C-0-1] 不得返回剪贴板上剪辑的数据（例如通过 ClipboardManager API），除非第三方应用是默认 IME 或当前获得焦点的应用。

  • [C-0-2] 必须在上次将剪贴板数据放入剪贴板或从剪贴板读取相应数据后不超过 60 分钟内清除剪贴板数据。

9.8.8. 位置信息

位置信息包含 Android 位置信息类中的信息（如纬度、经度、海拔）以及可转换为位置信息的标识符。位置信息可精确到 DGPS（差分全球定位系统），也可粗略到国家/地区级别的位置信息（如国家/地区代码位置信息 - MCC - 移动设备国家/地区代码）。

下面列出了可以直接推导用户位置信息，也可以转换为用户位置信息的位置信息类型。此表未详尽列出所有信息类型，但应该用作示例，说明可直接或间接从中推导出哪些位置信息：

  • GPS/GNSS/DGPS/PPP
    • 全球定位解决方案、全球导航卫星系统或差分全球定位解决方案
    • 原始 GNSS 测量数据和 GNSS 状态也包含在内
      • 精确位置信息可以根据原始 GNSS 测量数据推导得出
  • 具有唯一标识符的无线技术，例如：
    • Wi-Fi 接入点（MAC、BSSID、名称或 SSID）
    • 蓝牙/BLE（MAC、BSSID、名称或 SSID）
    • UWB（MAC、BSSID、名称或 SSID）
    • 手机基站 ID（3G、4G、5G 等，包含具有唯一标识符的所有未来移动网络调制解调器技术）

主要参考是指需要 ACCESS_FINE_Location 或 ACCESS_COARSE_Location 权限的 Android API。

设备实现：

  • [C-0-1] 未经用户明确同意或用户发起，不得打开/关闭设备位置信息设置和 Wi-Fi/蓝牙扫描设置。
  • [C-0-2] 必须提供一种方式，让用户能够访问与位置有关的信息，包括用于确定位置的最近位置请求、应用级别权限和 Wi-Fi/蓝牙扫描用法。
  • [C-0-3] 必须确保使用 Emergency Location Bypass API [LocationRequest.setLocationSettingsIgnored()] 的应用是用户发起的紧急会话（例如拨打 911 或向 911 发短信）。不过，对于 Automotive，在检测到碰撞/事故的情况下，车辆可以在没有主动用户互动的情况下启动紧急会话（例如，为了满足 eCall 要求）。
  • [C-0-4] 必须保留 Emergency Location Bypass API 在不更改设置的情况下绕过设备位置设置的功能。
  • [C-0-5] 必须计划一则通知，在后台应用使用 [ACCESS_BACKGROUND_LOCATION] 权限访问其位置之后提醒用户。

9.8.9. 已安装的应用

默认情况下，以 API 级别 30 或更高级别为目标的 Android 应用无法查看其他安装式应用的详细信息（请参阅 Android SDK 文档中的软件包可见性）。

设备实现：

  • [C-0-1] 不得向任何以 API 级别 30 或更高级别为目标的应用公开有关任何其他安装式应用的详细信息，除非该应用能够通过受管理 API 查看有关其他安装式应用的详细信息。这包括但不限于由设备实现者添加的任何自定义 API 提供的详细信息，或者可通过文件系统访问的详细信息。
  • [C-0-2] 不得向任何应用授予外部存储空间中任何其他应用的专用于特定应用的目录中的文件的读写权限。只有下列情况除外：
    • 外部存储空间服务提供程序授权（例如 DocumentsUI 等应用）。
    • 使用“Downloads”提供程序授权将文件下载至应用存储空间的下载提供程序。
    • 由平台签名的媒体传输协议 (MTP) 应用使用特权权限 ACCESS_MTP 将文件传输到其他设备。
    • 安装其他应用并拥有 INSTALL_PACKAGES 权限的应用只能访问“OBB”目录以管理 APK 扩展文件。

9.8.10. 连接 bug 报告

如果设备实现声明 android.hardware.telephony 功能标志，则：

  • [C-1-1] 必须支持使用 BugreportManager 通过 BUGREPORT_MODE_TELEPHONY 生成连接 bug 报告。
  • [C-1-2] 每次使用 BUGREPORT_MODE_TELEPHONY 生成报告时，都必须征得用户的同意，并且不得提示用户同意该应用的所有未来请求。
  • [C-1-3] 未经用户明确同意，不得将生成的报告返回给发起请求的应用。
  • [C-1-4] 使用 BUGREPORT_MODE_TELEPHONY 生成的报告必须至少包含以下信息：
    • TelephonyDebugService 转储
    • TelephonyRegistry 转储
    • WifiService 转储
    • ConnectivityService 转储
    • 发出调用的软件包的 CarrierService 实例的转储（如果已绑定）
    • 无线装置日志缓冲区
    • SubscriptionManagerService 转储
  • [C-1-5] 不得在生成的报告中包含以下内容：
    • 与连接调试没有直接关系的任何类型的信息。
    • 任何一种用户安装的应用流量日志或用户安装的应用/软件包的详细配置文件（UID 可以，软件包名称不行）。
  • 可以包含不与任何用户身份关联的其他信息（例如供应商日志）。

如果设备实现的 bug 报告中包含其他信息（例如供应商日志），并且该信息对隐私权/安全性/电量/存储空间/内存有影响，则：

  • [C-SR-1] 强烈建议将某项开发者设置默认设置为停用。AOSP 参考实现通过在开发者设置中提供 Enable verbose vendor logging 选项来将其他设备专属供应商日志纳入 bug 报告，从而实现上述目的。

9.8.11. 数据 blob 共享

Android 通过 BlobStoreManager 允许应用向系统提供数据 blob，以便与选定的一组应用共享。

如果设备实现支持共享数据 blob（如 SDK 文档中所述），则：

9.8.12. 音乐识别

Android 通过系统 API MusicRecognitionManager 支持设备实现机制，该机制可以针对给定录音请求音乐识别，并将音乐识别委托给一款可实现 MusicRecognitionService API 的特权应用。

如果设备实现包含实现系统 API MusicRecognitionManager 的服务，或任何流式传输音频数据的专有服务，则：

  • [C-1-1] 必须强制使 MusicRecognitionManager 的调用方拥有 MANAGE_MUSIC_RECOGNITION 权限
  • [C-1-2] 必须强制使单个预安装的音乐识别应用实现 MusicRecognitionService。
  • [C-1-3] 不得允许用户将 MusicRecognitionManagerService 或 MusicRecognitionService 替换为用户可安装的应用或服务。
  • [C-1-4] 必须确保在 MusicRecognitionManagerService 访问音频录音并将其转发到实现 MusicRecognitionService 的应用时，系统会通过调用 AppOpsManager.noteOp / startOp 跟踪音频访问权限。

如果 MusicRecognitionManagerService 或 MusicRecognitionService 的设备实现存储捕获的任何音频数据，则：

  • [C-2-1] 不得在磁盘上或内存中存储任何原始音频或音频指纹超过 14 天。
  • [C-2-2] 不得共享除 MusicRecognitionService 之外的此类数据，每次共享时获得用户的明确同意除外。

9.8.13. 传感器隐私权管理器

如果设备实现提供一种软件方式，让用户能够关闭该设备实现的摄像头和/或麦克风输入，则：

  • [C-1-1] 必须针对相关 supportsSensorToggle() API 方法准确返回“true”。
  • [C-1-2] 当应用尝试访问已屏蔽麦克风或摄像头时，必须向用户显示不可关闭的用户可见内容，从而清楚地指示传感器已屏蔽并需要选择执行以下操作：根据符合此要求的 AOSP 实现继续屏蔽或取消屏蔽。
  • [C-1-3] 必须仅向应用传递空白（或虚构）摄像头和音频数据，且不应报告因用户未通过根据上述 [C-1-2] 呈现的用户可见内容而开启摄像头或麦克风的错误代码。

新要求开始

9.8.14. Credential Manager

已移除。

9.8.15. 沙盒化 API 实现

Android 通过一组委托 API 提供了一种处理安全的操作系统级数据和环境数据的机制。此类处理可以委托给具有特许权限和较少通信功能的预安装 APK，称为沙盒化 API 实现。

任何沙盒化 API 实现：

  • [C-0-1] 不得请求 INTERNET 权限。
  • [C-0-2] 必须仅通过以下方式访问互联网：使用由公开可用的开放源代码实现（采用可保护隐私的机制）支持的结构化 API，或通过 Android SDK API 间接访问。可保护隐私的机制是指“仅允许汇总分析并防止将记录的事件或派生的结果与个别用户匹配的机制”，以防止任何每用户数据被内省（如使用 RAPPOR 等差分隐私技术实现）。
  • [C-0-3] 必须确保该服务与其他系统组件保持独立（例如，不绑定该服务或共享进程 ID），但以下情况除外：
    • 电话、通讯录、系统界面和媒体
  • [C-0-4] 不得允许用户将该服务替换为用户可安装应用或服务
  • [C-0-5] 必须只允许预安装的服务捕获此类数据。 除非替换功能已内置到 AOSP 中（例如数字助理应用）。
  • [C-0-6] 不得允许除预安装服务机制外的任何应用能够捕获此类数据。除非此类捕获功能是通过 Android SDK API 实现的。
  • [C-0-7] 必须提供一种方式，让用户能够停用该服务。
  • [C-0-8] 不得遗漏一种方式，让用户能够管理该服务保留的 Android 权限并遵循 Android 权限模型（如第 9.1 节“权限”中所述）。

9.8.16. 连续的音频和相机数据

除了第 9.8.2 节“录制”、第 9.8.6 节“操作系统级数据和环境数据”以及第 9.8.15 节“沙盒化 API 实现”中列出的要求之外，如果实现会使用通过 AudioRecord、SoundTrigger 或其他音频 API 在后台（连续）获取的音频数据或者通过 CameraManager 或其他相机 API 在后台（连续）获取的相机数据，则：

  • [C-0-1] 必须强制执行相应的指示器（即相机和/或麦克风，如第 9.8.2 节“录制”所述），除非：
  • [C-SR-1] 强烈建议所有利用此类数据的功能均须征得用户同意，并且默认处于停用状态。
  • [C-SR-2] 强烈建议对来自远程穿戴式设备的相机数据采用相同的处理方式（即遵循第 9.8.2 节“录制”、第 9.8.6 节“操作系统级数据和环境数据”、第 9.8.15 节“沙盒化 API 实现”，以及第 9.8.16 节“连续音频和相机数据”）。

如果相机数据是由远程穿戴式设备提供的，并在脱离 Android 操作系统、沙盒化实现或由 WearableSensingManager 构建的沙盒化功能情况下，以非加密的形式处理，则：

  • [C-1-1] 必须指示远程穿戴式设备在相应位置显示额外的指示器。

如果设备可以在没有指定关键字的情况下与数字助理应用互动（处理一般用户查询，或通过相机分析用户活跃状态），则：

  • [C-2-1] 必须确保此类实现由具有 android.app.role.ASSISTANT 角色的软件包提供。
  • [C-2-2] 必须确保此类实现使用 HotwordDetectionService 和/或 VisualQueryDetectionService Android API。

9.8.17. 遥测

Android 使用 StatsLog API 存储系统和应用日志。这些日志通过可供特权系统应用使用的 StatsManager API 进行管理。

StatsManager 还提供了一种使用可保护隐私的机制从设备收集隐私敏感数据的方法。具体来说，StatsManager::query API 提供了查询 StatsLog 中定义的受限指标类别的功能。

如果实现会从 StatsManager 查询和收集受限指标，则一律：

  • [C-0-1] 必须是设备上的唯一应用/实现，并且具有 READ_RESTRICTED_STATS 权限。
  • [C-0-2] 只能使用可保护隐私的机制来发送设备的遥测数据和日志。可保护隐私的机制是指“仅允许汇总分析并防止将记录的事件或派生的结果与个别用户匹配的机制”，以防止任何每用户数据被内省（如使用 RAPPOR 等差分隐私技术实现）。
  • [C-0-3] 不得将此类数据与设备上的任何用户身份（如账号）相关联。
  • [C-0-4] 不得与其他不符合当前章节（第 9.8.17 节“可保护隐私的遥测技术”）中概述的要求的操作系统组件共享此类数据。
  • [C-0-5] 必须提供一种方式，让用户能够启用/停用以可保护隐私的方式收集、使用和共享遥测数据的功能。
  • [C-0-6] 必须提供一种方式，让用户能够清除该实现收集的此类数据（如果数据以任何形式存储在设备上）。如果用户选择清除数据，则必须移除设备上当前存储的所有数据。
  • [C-0-7] 必须在开源代码库中披露底层隐私保护协议实现。
  • [C-0-8 ] 必须强制执行本节中所述的数据出站流量政策，以限制 StatsLog 中定义的受限指标类别的数据收集。

新要求结束

9.9. 数据存储加密

所有设备都必须满足第 9.9.1 节的要求。 在早于本文档的 API 级别上启动的设备不受第 9.9.2 和 9.9.3 节的要求限制；而必须满足对应于设备所启动的 API 级别的“Android 兼容性定义”文档的第 9.9 节中的要求。

9.9.1. 直接启动

设备实现：

9.9.2. 加密要求

设备实现：

  • [C-0-1] 必须对应用专属数据（/data 分区）以及应用共享存储分区（/sdcard 分区，如果它是设备的永久不可移除部分）进行加密。
  • [C-0-2] 必须在用户完成开箱设置体验时默认启用数据存储加密。

  • [C-0-3] 必须通过实现以下两种加密方法之一来满足上述数据存储加密要求：

9.9.3. 加密方法

如果设备实现已加密，则：

  • [C-1-1] 启动时不得要求用户提供凭据，并且在广播 ACTION_LOCKED_BOOT_COMPLETED 消息后允许直接启动感知型应用访问设备加密 (DE) 存储空间。
  • [C-1-2] 只有在用户已通过提供凭据（例如密码、PIN 码、图案或指纹）解锁设备并且系统已广播 ACTION_USER_UNLOCKED 消息后，才能允许访问凭据加密 (CE) 存储空间。
  • [C-1-13] 如果用户未提供凭据、已注册的第三方托管密钥或符合第 9.9.4 节中要求的重新启动时恢复实现，则不得提供解锁受 CE 保护的存储空间的任何方法。
  • [C-1-4] 必须使用启动时验证功能。
9.9.3.1. 文件级加密和元数据加密

如果设备实现使用了文件级加密与元数据加密，则：

  • [C-1-5] 必须使用 AES-256-XTS 或 Adiantum 对文件和文件系统元数据进行加密。AES-256-XTS 是指具有 256 位加密密钥长度、在 XTS 模式下操作的高级加密标准；密钥的全长是 512 位。Adiantum 是指 Adiantum-XChaCha12-AES，如 https://github.com/google/adiantum 中指定。文件系统元数据是指文件大小、所有权、模式和扩展属性 (xattr) 等数据。
  • [C-1-6] 必须使用 AES-256-CBC-CTS、AES-256-HCTR2 或 Adiantum 对文件名进行加密。
  • [C-1-12] 如果设备具有高级加密标准 (AES) 指令（例如基于 ARM 的设备上的 ARMv8 加密扩展，或基于 x86 的设备上的 AES-NI），则必须使用上述基于 AES 的选项对文件名、文件内容和文件系统元数据进行加密，而不是 Adiantum。
  • [C-1-13] 必须使用强加密且不可逆的密钥派生函数（例如 HKDF-SHA512）从 CE 密钥和 DE 密钥中派生任何所需的子密钥（例如文件级密钥）。“强加密且不可逆”表示密钥派生函数的安全性至少为 256 位，并在其输入上表现为伪随机函数族。
  • [C-1-14] 不得将相同的文件级加密 (FBE) 密钥或子密钥用于不同的加密目的（例如都用于加密和密钥派生，或用于两种不同的加密算法）。
  • [C-1-15] 必须确保使用依赖于文件及其中偏移量的加密密钥和初始化矢量 (IV) 组合对永久性存储空间上所有未删除的加密文件内容进行加密。此外，除非使用仅支持 32 位 IV 长度的内嵌加密硬件完成加密，否则所有此类组合都不得重复。
  • [C-1-16] 必须确保使用加密密钥和初始化向量 (IV) 的不同组合对不同目录中永久性存储空间上所有未删除的加密文件名进行加密。

  • [C-1-17] 必须确保使用加密密钥和初始化向量 (IV) 的不同组合对永久性存储空间上的所有加密文件系统元数据块进行加密。

  • 用于保护 CE 和 DE 存储区域和文件系统元数据的密钥如下：

    • [C-1-7] 必须以加密形式绑定到由硬件支持的密钥库。此密钥库必须绑定到启动时验证功能和设备的硬件信任根。
    • [C-1-8] CE 密钥必须绑定到用户的锁定屏幕凭据。
    • [C-1-9] 如果用户未指定锁定屏幕凭据，CE 密钥必须绑定到默认密码。
    • [C-1-10] 必须是独一无二的，也就是说，任何用户的 CE 或 DE 密钥都不能与其他用户的 CE 或 DE 密钥一致。
    • [C-1-11] 必须使用强制支持的加密方式、密钥长度和模式。
    • [C-1-12] 在引导加载程序解锁和锁定期间，必须安全地清除数据，如此处所述。

  • 应将预安装的必要应用（例如闹钟、电话和 Messenger）设置为直接启动感知型应用。

上行 Android 开源项目提供了基于 Linux 内核“fscrypt”加密功能的文件级加密，以及基于 Linux 内核“dm-default-key”功能的元数据加密。

9.9.3.2. 按用户的块级加密

如果设备实现使用按用户的块级加密，则：

  • [C-1-1] 必须启用第 9.5 节中所述的多用户支持。
  • [C-1-2] 必须提供用户级分区（使用原始分区或逻辑卷）。
  • [C-1-3] 必须对每位用户使用唯一加密密钥来加密底层块存储设备。

  • [C-1-4] 必须使用 AES-256-XTS 对用户分区进行块级加密。

  • 用于保护按用户的块级加密设备的密钥如下：

    • [C-1-5] 必须以加密形式绑定到由硬件支持的密钥库。此密钥库必须绑定到启动时验证功能和设备的硬件信任根。
    • [C-1-6] 必须绑定到相应用户的锁定屏幕凭据。

可以针对用户级分区使用 Linux 内核“dm-crypt”功能实现按用户的块级加密。

9.9.4. 重新启动时恢复

重新启动时恢复功能支持在 OTA 发起的重新启动后解锁所有应用的 CE 存储空间，包括那些还不支持直接启动的应用。借助此功能，用户可以在重新启动后接收来自安装式应用的通知。

重新启动时恢复功能的实现必须一直确保当设备落入攻击者手中时，攻击者极难恢复用户的 CE 加密数据，即使设备已开机、CE 存储空间已解锁并且用户已在收到 OTA 后解锁设备。为了防止内部人员攻击，我们还假设攻击者获得了广播加密签名密钥的权限。

具体而言：

  • [C-0-1] 即便攻击者实际拥有设备、具备以下能力且存在相应限制，也不可读取 CE 存储空间：

    • 可以使用任何供应商或公司的签名密钥对任意邮件进行签名。
    • 可以使设备收到 OTA。
    • 可以修改任何硬件（AP 和闪光灯等，下文详述的除外）的操作，但此类修改至少会延迟一小时并造成破坏 RAM 内容的重启。
    • 无法修改防篡改硬件的操作（例如 Titan M）。
    • 无法读取当前设备的 RAM。
    • 无法获取用户的凭据（PIN 码、图案和密码），或以其他方式输入此类凭据。

举例来说，如果设备实现符合此处的所有说明，且符合所有规范，则符合 [C-0-1] 的要求。

9.10. 设备完整性

以下要求旨在确保设备完整性状态的透明性。设备实现：

  • [C-0-1] 必须通过系统 API 方法 PersistentDataBlockManager.getFlashLockState() 正确报告其引导加载程序所处的状态是否允许刷写系统映像。

  • [C-0-2] 必须支持启动时验证以确保设备完整性。

如果设备实现已在不支持启动时验证的情况下搭载早期 Android 版本，且无法通过系统软件更新来添加对此功能的支持，则可以不遵守该要求。

启动时验证是一项旨在保证设备软件完整性的功能。如果设备实现支持该功能，则：

  • [C-1-1] 必须声明平台功能标志 android.software.verified_boot。
  • [C-1-2] 必须对每个启动序列执行验证。
  • [C-1-3] 必须从作为信任根的不可变硬件密钥开始验证，一直验证到系统分区。
  • [C-1-4] 必须实现每个验证阶段，以便在执行下一阶段中的代码之前，先检查下一阶段中所有字节的完整性和真实性。
  • [C-1-5] 必须使用与 NIST 针对哈希算法 (SHA-256) 和公钥大小 (RSA-2048) 给出的最新建议一样强大的验证算法。
  • [C-1-6] 当系统验证失败时，不得允许完成启动，除非用户同意仍然尝试启动，在这种情况下，不得使用任何未经验证的存储块中的数据。
  • [C-1-7] 不得允许修改设备上经过验证的分区，除非用户已明确解锁引导加载程序。
  • [C-SR-1] 如果设备中有多个离散芯片（例如无线装置、专门的图像处理器），强烈建议其中每个芯片的启动进程在启动时验证每个阶段。
  • [C-1-8] 必须使用防篡改的存储空间：用于在引导加载程序处于解锁状态时存储。防篡改的存储空间意味着：如果存储空间在 Android 内被篡改，引导加载程序可以检测到。
  • [C-1-9] 必须在允许从引导加载程序锁定模式转换为引导加载程序解锁模式之前提示用户（如果他们在使用设备），并要求用户进行物理确认。
  • [C-1-10] 必须针对 Android 使用的分区（例如 boot 分区、system 分区）实现回滚保护，并使用防篡改存储空间存储用于确定允许使用的最低操作系统版本的元数据。
  • [C-1-11] 在引导加载程序解锁和锁定期间，必须安全地清除所有用户数据，如“第 9.12 节 - 数据删除”所述（包括用户数据分区和任何 NVRAM 空间）。
  • [C-SR-2] 强烈建议通过根目录在分区下的信任链（受启动时验证保护）验证所有特权应用 APK 文件。
  • [C-SR-3] 强烈建议先对特权应用从其 APK 文件之外加载的所有可执行软件工件（例如动态加载的代码或编译的代码）进行验证，然后再执行这些软件工件或根本不执行（强烈建议采取后一种做法）。
  • 应针对具有持久性固件（例如调制解调器、摄像头）的任何组件实现回滚保护，并且应使用防篡改存储空间存储用于确定允许使用的最低版本的元数据。

如果设备实现已在不支持 C-1-8 至 C-1-11 的情况下搭载早期 Android 版本，且无法通过系统软件更新满足上述要求，则可以不遵守这些要求。

上游 Android 开源项目在 external/avb/ 仓库中提供了此功能的首选实现，该实现可以集成到用于加载 Android 的引导加载程序中。

设备实现

如果设备实现能够基于每个页面验证文件内容，则：

  • [C-0-3C-2-1] 支持在不读取整个文件的情况下，对照可信密钥对文件内容进行加密验证。

  • [C-0-4C-2-2] 如果读取的内容未通过可信密钥的验证根据上面的 [C-2-1] 未通过验证，不得允许对受保护文件的读取请求成功执行。

新要求开始

  • [C-2-4] 必须针对已启用的文件返回 O(1) 中的文件校验和。

新要求结束

如果设备实现未搭载对照早期 Android 版本中的可信密钥验证文件内容的功能，并且无法通过系统软件更新来添加对此功能的支持，则可以不遵守该要求。上游 Android 开源项目基于 Linux 内核 fs-verity 功能提供了此功能的首选实现。

设备实现：

如果设备实现支持 Android Protected Confirmation API，则：

  • [C-3-1] 必须针对 ConfirmationPrompt.isSupported() API 报告 true。

  • [C-3-2] 必须确保 Android OS 中运行的代码（包括其内核和恶意内容等）在没有用户互动的情况下无法生成积极回应。

  • [C-3-3] 即使 Android OS（包括其内核）遭到入侵，也必须确保用户能够审核和批准提示消息。

9.11. 密钥和凭据

Android Keystore 系统允许应用开发者将加密密钥存储在容器中，并通过 KeyChain API 或 Keystore API 在加密操作中使用它们。设备实现：

  • [C-0-1] 必须至少允许导入或生成 8,192 个密钥。
  • [C-0-2] 锁定屏幕身份验证机制必须在失败的尝试之间设定时间间隔。如果失败的尝试次数为 n 次，则 9 < n < 30 秒时，时间间隔应至少为 30 秒。如果 n > 29，则时间间隔值必须至少为 30*2^floor((n-30)/10)) 秒或至少 24 小时，以较小者为准。
  • 不应限制可以生成的密钥数

新要求开始

  • [C-0-3] 必须限制主要身份验证方法尝试失败的次数。
  • [C-SR-2] 强烈建议将主要身份验证方法尝试失败的次数上限设置为 20 次；如果用户同意并选择启用该功能，则在超出主要身份验证方法尝试失败次数限制后执行“恢复出厂设置”。

如果设备实现会添加或修改用于解锁锁定的屏幕且基于已知密钥的身份验证方法，并将新的身份验证方法视为安全的屏幕锁定方式，则：

  • [C-SR-3] 强烈建议 PIN 码至少包含 6 位数或等效的 20 位熵。
  • [C-2-1] 不得允许在没有用户互动的情况下自动输入长度不足 6 位数的 PIN 码，以免泄露 PIN 码的长度。

新要求结束

如果设备实现支持安全锁定屏幕，则：

  • [C-1-1] 必须通过隔离的执行环境备份密钥库实现。
  • [C-1-2] 必须具有 RSA、AES、ECDSA、ECDH（如果支持 IKeyMintDevice）、3DES 和 HMAC 加密算法以及 MD5、SHA1 和 SHA-2 系列哈希函数的实现，以便在与内核上及更上面运行的代码安全隔离的区域中正确支持 Android Keystore 系统支持的算法。安全隔离必须能够阻止内核或用户空间代码可能会借以获取隔离环境内部状态的所有潜在机制，包括 DMA。上游 Android 开源项目 (AOSP) 通过使用 Trusty 实现来满足此要求，但也可以使用其他基于 ARM TrustZone 的解决方案，或使用经过第三方审核的基于 Hypervisor 的适当隔离方法的安全实现。
  • [C-1-3] 必须在隔离的执行环境中执行锁定屏幕身份验证，并且只有在成功通过验证后，才允许使用与身份验证绑定的密钥。锁定屏幕凭据的存储方式必须只允许隔离的执行环境执行锁屏身份验证。上游 Android 开源项目提供了可用于满足此要求的 Gatekeeper 硬件抽象层 (HAL) 和 Trusty。
  • [C-1-4] 如果认证签名密钥受安全硬件保护，并且签名是在安全硬件中进行，必须支持密钥认证。认证签名密钥必须在足够多的设备之间共享，以防止此类密钥被用作设备标识符。如需满足此要求，可以采用的一种方法是共享相同的认证密钥，除非生成了至少 10 万个单元的给定 SKU。如果生成了超过 10 万个单元的 SKU，可以针对每 10 万个单元使用一个不同的密钥。

请注意，如果设备实现已搭载较低 Android 版本，则此类设备无需满足具有由隔离的执行环境支持的密钥库并支持密钥认证这一要求，除非它声明了 android.hardware.fingerprint 功能（该功能需要受隔离的执行环境支持的密钥库）。

  • [C-1-5] 必须允许用户为从解锁状态到锁定状态的过渡时间选择休眠超时，允许的最短超时时间为 15 秒。Automotive 设备在每次关闭车机或切换用户时都会锁定屏幕，因此可以没有休眠超时配置。
  • [C-1-6] 必须支持 IKeymasterDevice 4.0、IKeymasterDevice 4.1、IKeyMintDevice 版本 1 或 IKeyMintDevice 版本 2。
  • [C-SR-1] 强烈建议支持 IKeyMintDevice 版本 1。

9.11.1. 安全锁定屏幕、身份验证和虚拟设备

AOSP 实现遵循分层的身份验证模式，其中基于知识的主要身份验证可由安全系数较高的辅助生物识别技术或安全系数较低的第三模态提供支持。

设备实现：

  • [C-SR-1] 强烈建议仅将以下身份验证方法之一设置为主要身份验证方法：

    • 数字 PIN 码
    • 字母数字密码

    • 3x3 点网格上的滑动图案

      请注意，上述身份验证方法在本文档中称为建议的主要身份验证方法。

新要求开始

  • [C-0-1] 必须限制主要身份验证方法尝试失败的次数。
  • [C-SR-5] 强烈建议将主要身份验证方法尝试失败的次数上限设置为 20 次；如果用户同意并选择启用该功能，则在超出主要身份验证方法尝试失败次数限制后执行“恢复出厂设置”。

如果设备实现将数字 PIN 码设置为建议的主要身份验证方法，则：

  • [C-SR-6] 强烈建议 PIN 码至少包含 6 位数或等效的 20 位熵。
  • [C-SR-7] 强烈建议不要允许在没有用户互动的情况下自动输入长度不足 6 位数的 PIN 码，以免泄露 PIN 码的长度。

新要求结束

如果设备实现会添加或修改建议的主要身份验证方法，并将新的身份验证方法用作安全的屏幕锁定方式，则新的身份验证方法：

如果设备实现会添加或修改用于解锁锁定屏幕且基于已知密钥的身份验证方法，并将新的身份验证方法视为安全的屏幕锁定方式，则：

  • [C-3-1] 允许的最短输入内容长度的熵必须大于 10 位。
  • [C-3-2] 所有可能的输入内容的最大熵必须大于 18 位。
  • [C-3-3] 新的身份验证方法不得替换 AOSP 中实现和提供的任何建议的主要身份验证方法（即 PIN 码、图案或密码）。
  • [C-3-4] 当设备政策控制器 (DPC) 应用已通过 DevicePolicyManager.setRequiredPasswordComplexity()（具有比 PASSWORD_COMPLEXITY_NONE 限制性更强的复杂性常量）或通过 DevicePolicyManager.setPasswordQuality()（具有比 PASSWORD_QUALITY_BIOMETRIC_WEAK 限制性更强的常量）设置密码要求政策时，新的身份验证方法必须处于停用状态。
  • [C-3-5] 新的身份验证方法至少每隔 72 小时不得回退到建议的主要身份验证方法（如 PIN 码、图案或密码）或明确地向用户披露：某些数据不会备份以便保留数据的隐私。

如果设备实现会添加或修改建议的主要身份验证方法以解锁锁定屏幕，并将基于生物识别的新身份验证方法视为安全的屏幕锁定方式，新的方法：

  • [C-4-1] 必须满足第 7.3.10 节 1 类（之前的便利）中所述的所有要求。
  • [C-4-2] 必须具有回退机制，以使用建议的主要身份验证方法之一（基于已知密钥）。
  • [C-4-3] 当设备政策控制器 (DPC) 应用已通过调用具有相关的任何生物识别标志（即 KEYGUARD_DISABLE_BIOMETRICS、KEYGUARD_DISABLE_FINGERPRINT、KEYGUARD_DISABLE_FACE 或 KEYGUARD_DISABLE_IRIS）的 DevicePolicyManager.setKeyguardDisabledFeatures() 方法设置键盘锁功能政策时，它们必须处于停用状态，并且仅允许使用建议的主要身份验证方法解锁屏幕。

如果生物识别身份验证方法不符合第 7.3.10 节中所述的 3 类（之前的强）的要求，则：

  • [C-5-1] 当设备政策控制器 (DPC) 应用已通过 DevicePolicyManager.setRequiredPasswordComplexity()（具有比 PASSWORD_COMPLEXITY_LOW 限制性更强的复杂性存储分区）或使用 DevicePolicyManager.setPasswordQuality() 方法（具有比 PASSWORD_QUALITY_BIOMETRIC_WEAK 限制性更强的质量常量）设置密码要求质量政策时，这些方法必须处于停用状态。
  • [C-5-2] 必须按第 7.3.10 节中的 [C-1-7] 和 [C-1-8] 所述，要求用户通过建议的主要身份验证方法（例如 PIN 码、图案、密码）验证身份。
  • [C-5-3] 这些方法不得被视为安全的锁屏方法，且必须满足本节下文中以 C-8 开头的要求。

如果设备实现会添加或修改用于解锁锁定屏幕的身份验证方法，且新的身份验证方法基于物理令牌或位置，则：

  • [C-6-1] 必须具有回退机制，以使用建议的主要身份验证方法之一（基于已知密钥，且满足被视为安全锁定屏幕的要求）。
  • [C-6-2] 当设备政策控制器 (DPC) 应用已通过以下方法设置政策时，新的身份验证方法必须处于停用状态，且仅允许使用建议的主要身份验证方法之一解锁屏幕：
  • [C-6-3] 必须至少每隔 4 小时要求用户通过建议的主要身份验证方法之一（例如 PIN 码、图案、密码）验证身份。如果物理令牌满足 C-X 中与 TrustAgent 实现相关的要求，改为应用 C-9-5 中定义的超时限制。
  • [C-6-4] 新的身份验证方法不得被视为安全的锁屏方法，且必须遵循下文 C-8 中所列的限制条件。

如果设备实现包含安全锁定屏幕，并且包含一个或多个实现 TrustAgentService 系统 API 的可信代理，则：

  • [C-7-1] 如果设备锁被推迟或可被可信代理解锁，则必须在“设置”菜单中和锁定屏幕上明确指明。例如，AOSP 通过以下方式满足此要求：在“设置”菜单中显示有关“自动锁定设置”和“电源按钮即时锁定”的文字说明，并在锁定屏幕上显示显眼的图标。
  • [C-7-2] 必须遵从并完整实现 DevicePolicyManager 类中的所有可信代理 API，例如 KEYGUARD_DISABLE_TRUST_AGENTS 常量。
  • [C-7-3] 不得在主要供个人使用的设备（例如手持设备）上完整实现 TrustAgentService.addEscrowToken() 功能，但可以在通常供多人共享的设备实现（例如 Android TV 或 Automotive 设备）上完整实现该功能。
  • [C-7-4] 必须对 TrustAgentService.addEscrowToken() 添加的所有存储令牌进行加密。
  • [C-7-5] 不得将加密密钥或第三方托管令牌存储在使用该密钥的设备上。例如，可以使用存储在手机上的密钥解锁 TV 上的用户账号。对于 Automotive 设备，不允许将第三方托管令牌存储在车辆的任何位置。
  • [C-7-6] 在启用第三方托管令牌以解密数据存储之前，必须先将会对安全性造成的影响通知用户。
  • [C-7-7] 必须具有回退机制，以使用建议的主要身份验证方法之一。
  • [C-7-8] 除非需要考虑用户安全（驾驶员分心），否则必须至少每隔 72 小时要求用户通过建议的主要身份验证方法之一（例如 PIN 码、图案、密码）验证身份。
  • [C-7-9] 除非需要考虑用户安全（驾驶员分心），否则必须按第 7.3.10 节中的 [C-1-7] 和 [C-1-8] 所述，要求用户通过建议的主要身份验证方法之一（例如 PIN 码、图案、密码）验证身份。
  • [C-7-10] 不得被视为安全的锁屏方法，且必须遵循下文 C-8 中所列的限制条件。
  • [C-7-11] 不得允许主要个人设备（如手持设备）上的 TrustAgents 解锁设备，而只能使用它们将已解锁的设备保持在已解锁状态最长达 4 小时。AOSP 中的 TrustManagerService 的默认实现满足此要求。
  • [C-7-12] 必须使用加密安全（如 UKEY2）信道将存储设备中的第三方托管令牌传递至目标设备。

如果设备实现会添加或修改用于解锁锁定屏幕（并非上述安全锁屏方式中的一种）的身份验证方法，并使用新的身份验证方法解锁键盘锁，则：

如果设备实现允许应用创建辅助虚拟屏幕并且不支持关联的输入事件（例如通过 VirtualDeviceManager），则：

  • [C-9-1] 当设备的默认屏幕处于锁定状态时，必须锁定这些辅助虚拟屏幕；当设备的默认屏幕处于解锁状态时，必须解锁这些辅助虚拟屏幕。

如果设备实现允许应用创建辅助虚拟屏幕，并且支持关联的输入事件（例如通过 VirtualDeviceManager），则：

  • [C-10-1] 必须支持每台虚拟设备都具有单独的锁定状态
  • [C-10-2] 空闲超时时，必须与所有虚拟设备断开连接
  • [C-10-3] 必须有空闲超时
  • [C-10-4] 当用户发起锁定时（包括通过手持设备所需的锁定用户功能），必须锁定所有屏幕（请参阅第 2.2.5[9.11/H-1-2] 节）
  • [C-10-5] 必须为每位用户设置单独的虚拟设备实例
  • [C-10-6] 当 DevicePolicyManager.setNearbyAppStreamingPolicy 指明时，必须禁止通过 VirtualDeviceManager 创建关联的输入事件
  • [C-10-7] 必须为每台虚拟设备专门使用单独的剪贴板（或为虚拟设备停用剪贴板）
  • [C-10-11] 必须停用虚拟设备上的身份验证界面，包括验证凭据输入和生物识别提示
  • [C-10-12] 必须限制从虚拟设备发起的 intent 仅在同一虚拟设备上显示
  • [C-10-13] 不得将虚拟设备锁定状态用作 Android Keystore 系统的用户身份验证授权。请参阅 KeyGenParameterSpec.Builder.setUserAuthentication*。

如果设备实现允许用户将主身份验证凭据从源设备传输到目标设备（例如，为了对目标设备进行初始设置而传输），则：

  • [C-11-1] 在将验证凭据从源设备传输到目标设备时，必须使用类似于 Google Cloud 密钥保险柜服务安全性白皮书中所述的保护技术来加密验证凭据，使其无法远程解密或用于远程解锁任何设备。
  • [C-11-2] 在将验证凭据传输到目标设备之前，必须在源设备上要求用户确认源设备的验证凭据。
  • [C-11-3] 在将验证凭据设为目标设备的主要身份验证凭据之前，以及提供从源设备传输的任何数据之前，必须在未设置任何主要身份验证凭据的目标设备上要求用户在目标设备上确认所传输的验证凭据。

如果设备实现包含安全锁定屏幕，并且包含一个或多个使用 FLAG_GRANT_TRUST_TEMPORARY_AND_RENEWABLE 标志调用 TrustAgentService.grantTrust() 系统 API 的可信代理，则：

  • [C-12-1] 必须仅在连接到具有自己的锁屏的邻近实体设备并且用户已针对该锁屏验证其身份时，才使用此标志调用 grantTrust()。邻近设备可以在一次性用户解锁后使用贴腕或贴身检测机制来满足用户身份验证要求。
  • [C-12-2] 如果屏幕已关闭（例如通过按下按钮或显示超时）且 TrustAgent 未撤消信任，必须将设备实现置于 TrustState.TRUSTABLE 状态。AOSP 满足此要求。
  • [C-12-3] 如果 TrustAgent 仍在根据 C-12-1 中的要求授予信任，只能将设备从 TrustState.TRUSTABLE 转换为 TrustState.TRUSTED 状态。
  • [C-12-4] 必须在自授予信任起最多 24 小时后、8 小时空闲期限过后或与邻近实体设备的底层连接丢失后调用 TrustManagerService.revokeTrust()。

如果设备实现允许应用创建辅助虚拟屏幕并支持关联的输入事件（例如通过 VirtualDeviceManager），且显示屏未标记 VIRTUAL_DISPLAY_FLAG_SECURE，则：

  • [C-13-8] 必须阻止具有属性 android:canDisplayOnRemoteDevices 或元数据 android.activity.can_display_on_remote_devices 设为 false 的 activity 在虚拟设备上启动。
  • [C-13-9] 必须阻止未明确启用流式传输并已指明会显示敏感内容（包括通过 SurfaceView#setSecure、FLAG_SECURE 或 SYSTEM_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS）的 activity 在虚拟设备上启动。
  • [C-13-10] 必须禁止从虚拟设备发起的应用安装。

如果设备实现通过 DeviceStateManager 支持单独的显示屏电源状态，并且通过 KeyguardDisplayManager 支持单独的屏幕锁定状态，则：

  • [C-SR-2] 强烈建议利用符合第 9.11.1 节中定义的要求的凭据或符合第 7.3.10 节中定义的至少 1 类规范的生物识别，以允许从默认设备屏幕独立解锁。
  • [C-SR-3] 强烈建议通过定义的屏幕超时限制单独的屏幕解锁。
  • [C-SR-4] 强烈建议允许用户从主要手持设备执行锁定来全局锁定所有屏幕。

9.11.2. StrongBox

Android Keystore 系统允许应用开发者将加密密钥存储在专用的安全处理器以及上述隔离的执行环境中。这种专用安全处理器称为“StrongBox”。下面的 C-1-3 至 C-1-11 要求规定了设备要符合 StrongBox 资格所必须满足的要求。

具有专用安全处理器的设备实现：

  • [C-SR-1] 强烈建议支持 StrongBox。StrongBox 在未来版本中很可能会成为一项要求。

如果设备实现支持 StrongBox，则：

  • [C-1-1] 必须声明 FEATURE_STRONGBOX_KEYSTORE。

  • [C-1-2] 必须提供专用的安全硬件，以支持密钥存储区和安全的用户身份验证。专用安全硬件也可用于其他目的。

  • [C-1-3] 必须具有不与应用处理器 (AP) 共享任何缓存、DRAM、协处理器或其他核心资源的独立 CPU。

  • [C-1-4] 必须确保与 AP 共享的任何外围设备都不得以任何方式改变 StrongBox 处理或从 StrongBox 中获取任何信息。AP 可以停用或屏蔽对 StrongBox 的访问。

  • [C-1-5] 必须具有准确度在合理范围 (+-10%) 内的内置时钟，且该时钟不受 AP 操纵。

  • [C-1-6] 必须具有真正的随机号码生成器，该生成器会生成均匀分布且不可预测的输出。

  • [C-1-7] 必须具有防篡改功能，包括防物理渗透和干扰。

  • [C-1-8] 必须能够抗边信道攻击，包括防止通过电源、定时器、电磁辐射和热辐射边信道泄露信息。

  • [C-1-9] 必须具有安全存储空间，以确保内容的机密性、完整性、真实性、一致性和新鲜度。除非经过 StrongBox API 允许，否则不得读取或更改存储内容。

  • 如需验证对 [C-1-3] 到 [C-1-9] 的遵从性，设备实现：

    • [C-1-10] 包含的硬件必须经过 Secure IC Protection Profile BSI-CC-PP-0084-2014 认证或通过国家认可的测试实验室的评估，以及根据 Common Criteria Application of Attack Potential to Smartcards 进行的高攻击性潜在漏洞评估。
    • [C-1-11] 包含的固件必须通过国家认可的测试实验室的评估，以及根据 Common Criteria Application of Attack Potential to Smartcards 进行的高攻击性潜在漏洞评估。
    • [C-SR-2] 强烈建议使包含的硬件通过安全目标、安全评估等级 (EAL) 5（由 AVA_VAN.5 增强）的评估。EAL 5 认证在未来版本中很可能会成为一项要求。
    • [C-SR-3] 强烈建议提供防内部人员攻击 (IAR) 功能，这意味着有权访问固件签名密钥的内部人员无法生成导致 StrongBox 泄露密钥的固件，因此无法绕过功能安全要求或以其他方式访问敏感的用户数据。IAR 的建议实现方法是仅在通过 IAuthSecret HAL 提供主要用户密码时才允许固件更新。

9.11.3. 身份凭据

身份凭据系统是通过实现 android.security.identity.* 软件包中的所有 API 来定义和实现的。这些 API 允许应用开发者存储和检索身份证明文档。设备实现：

  • [C-SR-1] 强烈建议实现身份凭据系统。

如果设备实现已实现身份凭据系统，则：

  • [C-1-1] 必须针对 IdentityCredentialStore#getInstance() 方法返回非 null 值。

  • [C-1-2] 必须在与内核上及更上面运行的代码安全隔离的区域中通过与可信应用通信的代码实现身份凭据系统（如 android.security.identity.* API）。安全隔离必须能够阻止内核或用户空间代码可能会借以获取隔离环境内部状态的所有潜在机制，包括 DMA。

  • [C-1-3] 实现身份凭据系统（例如 android.security.identity.* API）所需的加密操作必须完全在可信应用中执行，并且私钥材料绝不能离开这个隔离的执行环境，除非较高级别的 API（例如 createEphemeralKeyPair() 方法）明确要求。

  • [C-1-4] 可信应用必须以这样的方式来实现：即使 Android 行为异常或遭到破解，它的安全属性也不会受到影响（例如，除非满足访问权限控制条件，否则无法发布凭据数据，无法为任意数据生成 MAC 地址）。

上游 Android 开源项目提供了可用于实现身份凭据系统的可信应用 (libeic) 的参考实现。

9.12. 数据删除

所有设备实现：

  • [C-0-1] 必须为用户提供一种用于执行“恢复出厂设置”的机制。
  • [C-0-2] 执行“恢复出厂设置”时，必须删除用户数据文件系统上的所有数据。
  • [C-0-3] 执行“恢复出厂设置”时，必须采用符合相关行业标准（例如 NIST SP800-88\）的方式删除数据。
  • [C-0-4] 当主要用户的设备政策控制器应用调用 DevicePolicyManager.wipeData() API 时，必须触发上述“恢复出厂设置”流程。
  • 可以提供仅会执行逻辑数据清空操作的快速数据擦除功能。

9.13. 安全启动模式

Android 提供了安全启动模式，可让用户启动到仅允许运行预安装的系统应用而停用所有第三方应用的模式。这种模式称为“安全启动模式”，它可以让用户卸载可能有害的第三方应用。

设备实现：

  • [C-SR-1] 强烈建议实现安全启动模式。

如果设备实现已实现安全启动模式，则：

  • [C-1-1] 必须为用户提供一个进入安全启动模式的选项，并确保在进入该模式时不会被设备上安装的第三方应用中断，除非第三方应用是设备政策控制器，并且已将 UserManager.DISALLOW_SAFE_BOOT 标志设置为 true。

  • [C-1-2] 必须让用户能够在安全模式下卸载任何第三方应用。

  • 应为用户提供一个用于从启动菜单进入安全启动模式的选项（采用的工作流程不同于正常启动时的工作流程）。

9.14. Automotive 车载系统隔离

Android Automotive 设备应使用车载 HAL 与关键车载子系统交换数据，以便通过车载网络（如 CAN 总线）收发消息。

可以通过以下方式保护数据交换的安全性：在 Android 框架层以下实现安全功能，以防止与这些子系统进行恶意互动或意外互动。

9.15. 订阅方案

“订阅方案”是指移动运营商通过 SubscriptionManager.setSubscriptionPlans() 提供的结算关系方案详情。

所有设备实现：

  • [C-0-1] 必须仅将订阅套餐返回给最初提供它们的移动运营商应用。
  • [C-0-2] 不得远程备份或上传订阅方案。
  • [C-0-3] 必须只允许当前提供有效订阅方案的移动运营商应用进行替换，例如 SubscriptionManager.setSubscriptionOverrideCongested()。

9.16. 应用数据迁移

如果设备实现包含将数据从一部设备迁移到其他设备的功能，并且不将复制的应用数据限制在应用开发者通过 android:fullBackupContent 属性在清单中配置的范围内，则：

  • [C-1-1] 不得从用户尚未设置主要身份验证方法（如 9.11.1 安全锁定屏幕和身份验证中所述）的设备启动应用数据转移。
  • [C-1-2] 必须以安全方式确认源设备上的主要身份验证方法，并在转移任何数据之前向用户确认他们是否想要复制源设备上的数据。
  • [C-1-3] 必须使用安全密钥认证，以确保设备间迁移中的源设备和目标设备都是合法的 Android 设备，并且具有锁定的引导加载程序。
  • [C-1-4] 只能将应用数据迁移到目标设备上的同一应用中，并使用相同的软件包名称和签名证书。
  • [C-1-5] 必须在设置菜单中显示指示元素，表明源设备已通过设备间数据迁移进行数据迁移。用户应该无法移除此指示元素。

9.17. Android 虚拟化框架

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

  • [C-1-1] 必须支持 android.system.virtualmachine 软件包定义的所有 API。
  • [C-1-2] 不得修改 Android SELinux 和用于管理受保护的虚拟机 (pVM) 的权限模型。

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

  • [C-1-4] 必须只允许由平台签名的代码和特权应用不得允许不受信任的代码（例如第三方应用）创建和运行受保护的虚拟机 pVM。 注意：此要求在未来的 Android 版本中可能会发生变化。

  • [C-1-5] 不得允许受保护的虚拟机 pVM 执行出厂映像或其更新中未包含的代码。Android 启动时验证未涵盖的任何内容（例如从互联网下载的文件或旁加载的文件）都不得在受保护的虚拟机中运行。

新要求开始

  • [C-1-5] 必须只允许不可调试的 pVM 执行出厂映像或其平台更新中的代码，其中也包括特权应用的任何更新。

新要求结束

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

  • [C-2-1] 必须能够在受保护的虚拟机 pVM 中运行虚拟化 APEX 中提供的所有操作系统。
  • [C-2-2] 不得允许受保护的虚拟机 pVM 运行未由设备实现人员或操作系统供应商签名的操作系统。
  • [C-2-3] 不得允许受保护的虚拟机 pVM 将数据作为代码执行（例如 SELinux neverallow execmem）。

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

  • [C-2-5] 必须实现受保护的虚拟机 pVM 深度防护机制（例如用于 pVM 的 SELinux），即使对于非 Microdroid 操作系统也是如此。
  • [C-2-6] 必须确保在无法验证初始映像无法验证虚拟机将运行的映像时，pVM 无法固件拒绝启动。验证必须在虚拟机内完成。
  • [C-2-7] 必须确保在 instance.img 完整性受到破坏时，pVM 无法固件拒绝启动。

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

  • [C-3-1] 必须确保虚拟机（pVM 或主机虚拟机）专有的内存页面只能由虚拟机本身或 Hypervisor 访问，而不能由其他受保护或不受保护的虚拟机访问。不得允许任何 pVM 访问属于其他实体（即其他 pVM 或 Hypervisor）的网页，除非网页所有者明确共享该网页。其中包括主机虚拟机。此要求适用于对 CPU 和 DMA 的访问。
  • [C-3-2] 如果 pVM 使用了某个网页，在其返回主机（例如 pVM 被销毁）之前，必须擦除该网页。
  • [C-3-3SR-1] 强烈建议确保必须确保先加载和执行 pVM 固件，然后才能在 pVM 中加载和执行任何代码。
  • [C-3-4] 必须确保每个虚拟机都会为每个虚拟机派生 Secret提供给 pVM 实例的启动证书链 (BCC) 和复合设备标识符 (CDI)，这个 Secret 只能由该特定虚拟机实例派生，并在恢复出厂设置和 OTA 后更改。

如果设备实现支持 Android 虚拟化框架 API，则在所有区域中：

  • [C-4-1] 不得为 pVM 提供允许绕过 Android 安全模型的功能。

如果设备实现支持 Android 虚拟化框架 API，则：

  • [C-5-1] 必须能够支持隔离编译，但可能会在设备发货时停用隔离编译功能ART 运行时更新。

如果设备实现支持 Android 虚拟化框架 API，则在密钥管理方面：

  • [C-6-1] 必须在用户无法修改的点为 DICE 链启用 root 权限，即使在未锁定的设备上也是如此（目的是确保其不会遭到仿冒）。

  • [C-SR-26-2] 强烈建议使用 DICE 作为每个虚拟机的 Secret 派生机制。 必须正确执行 DICE，即提供正确的值。

10. 软件兼容性测试

设备实现必须通过本节中所述的所有测试。 不过请注意，任何软件测试包都不是详尽无遗的。 因此，强烈建议设备实现者尽可能避免对可从 Android 开源项目获得的 Android 参考实现和首选实现进行更改。这样有助于最大限度地降低引入 bug 的风险，从而避免由此造成需要进行返工和潜在设备更新的不兼容问题。

10.1. 兼容性测试套件

设备实现：

  • [C-0-1] 必须通过 Android 开源项目提供的 Android 兼容性测试套件 (CTS) 的测试（使用设备上最终交付的软件）。

  • [C-0-2] 对于 CTS 中不明确的情况，以及参考源代码中部分内容的任何重新实现，都必须确保兼容性。

CTS 能够在实际设备上运行。与所有软件一样，CTS 自身也可能包含 bug。CTS 的版本发布独立于本兼容性定义，我们可能会针对 Android 14 发布多个 CTS 修订版本。

设备实现：

  • [C-0-3] 必须通过设备软件发布时可用的最新 CTS 版本的测试。

  • 应尽可能多地使用 Android 开源树中的参考实现。

10.2. CTS 验证程序

CTS 验证程序包含在兼容性测试套件中，以便人工操作员运行该验证程序来测试无法由自动化系统测试的功能（例如，测试摄像头和传感器能否正常工作）。

设备实现：

  • [C-0-1] 必须正确执行 CTS 验证程序中的所有适用用例。

CTS 验证程序中包含针对多种硬件（其中包括一些选配硬件）的测试。

设备实现：

  • [C-0-2] 必须通过针对其具备的硬件的所有测试；例如，如果某台设备具备加速度计，就必须正确执行 CTS 验证程序中的加速度计测试用例。

对于本兼容性定义文档中注明为选配的功能，可跳过或省略相应的测试用例。

  • [C-0-2] 如上所述，每种设备和每个 build 都必须正确运行 CTS 验证程序。不过，由于很多 build 非常相似，因此设备实现者可能不会对只有细微差别的 build 明确运行 CTS 验证程序。具体来说，如果设备实现与已通过 CTS 验证程序测试的某个实现只是在所包含语言区域、品牌信息等方面存在差别，则设备实现可以省略 CTS 验证程序测试。

11. 可更新软件

  • [C-0-1] 设备实现必须包含可用于替换整个系统软件的机制。该机制不需要执行“实时”升级 - 也就是说，可能需要重新启动设备。可以使用任何方法，但前提是该方法可以替换设备上预安装的整个软件。例如，以下任何方法都可以满足此要求：

    • “无线 (OTA)”下载（通过重新启动进行离线更新）。
    • 从主机 PC 上通过 USB 进行“网络共享”更新。
    • 通过重新启动进行“离线”更新，以及通过可移动存储设备中的文件进行更新。

  • [C-0-2] 使用的更新机制必须支持在不擦除用户数据的情况下进行更新。也就是说，更新机制必须保留应用专属数据和应用共享数据。请注意，上游 Android 软件包含满足此要求的更新机制。

  • [C-0-3] 必须对整个更新进行签名，并且设备上更新机制必须根据设备上存储的公钥验证更新和签名。

  • [C-SR-1] 强烈建议签名机制使用 SHA-256 对更新进行哈希处理，并使用 ECDSA NIST P-256 根据公钥验证哈希。

如果设备实现支持 802.11 或蓝牙 PAN（个人局域网）配置等不按流量计费的数据网络连接，则：

  • [C-1-1] 必须支持 (OTA) 下载（通过重新启动进行离线更新）。

设备实现应在 OTA 之后验证系统映像是否为与预期结果完全相同的二进制文件。上游 Android 开源项目中基于块的 OTA 实现（从 Android 5.1 开始添加了此实现）可满足此要求。

此外，设备实现还应支持 A/B 系统更新。AOSP 使用启动控件 HAL 实现了此功能。

在设备实现发布后，如果在其合理的产品生命周期内发现其中存在错误，并且经与 Android 兼容性团队磋商后确定该错误会影响第三方应用的兼容性，则：

  • [C-2-1] 设备实现者必须通过可按上述机制应用的可用软件更新来更正该错误。

Android 包含一些可让设备所有者应用（如果存在）控制系统更新安装的功能。如果设备的系统更新子系统报告 android.software.device_admin，则：

12. 文档更新日志

有关对此版本中的兼容性定义所做变更的摘要，请参阅：

13. 与我们联系

您可以加入 android-compatibility 论坛，发帖咨询或提出您认为本文档未涵盖的任何问题。