Android 15 兼容性定义

使用集合保持井井有条 根据您的偏好保存内容并对其进行分类。

1. 简介

本文档列举了设备与 Android 15 兼容必须满足的要求。

“必须 (MUST)”、“不得 (MUST NOT)”、“必需 (REQUIRED)”、“应 (SHALL)”、“不应 (SHALL NOT)”、“应该 (SHOULD)”、“不应该 (SHOULD NOT)”、“建议 (RECOMMENDED)”、“可以 (MAY)”和“可选 (OPTIONAL)”的使用符合 RFC2119 中定义的 IETF 标准。

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

要被视为与 Android 15 兼容，设备实现必须满足本兼容性定义中提出的要求，包括通过引用并入的任何文档。

如果本定义或第 10 节中描述的软件测试中存在未提及、含义模糊或不完整之处，则设备实现方有责任确保与现有实现的兼容性。

因此，Android 开源项目既是 Android 的参考实现，也是首选实现。强烈建议设备实现方尽可能以 Android 开源项目提供的“上游”源代码为基础进行实现。虽然某些组件在理论上可以替换为其他实现，但强烈建议不要采用这种做法，因为通过软件测试将变得更加困难。实现方有责任确保与标准 Android 实现的完全行为兼容性，包括且不限于兼容性测试套件。最后请注意，本文档明确禁止某些组件替换和修改。

本文档中链接的许多资源直接或间接来源于 Android SDK，并且在功能上与该 SDK 文档中的信息相同。如果本兼容性定义或兼容性测试套件与 SDK 文档存在分歧，则以 SDK 文档为准。本文档通篇链接的资源中提供的任何技术细节均被视为本兼容性定义的一部分。

1.1 文档结构

1.1.1. 按设备类型划分的要求

第 2 节包含适用于特定设备类型的所有要求。第 2 节的每个小节都专门针对一种特定的设备类型。

普遍适用于任何 Android 设备实现的所有其他要求都列在第 2 节之后的章节中。在本文档中，这些要求被称为“核心要求”。

1.1.2. 要求 ID

要求 ID 针对 MUST 要求分配。

• ID 仅针对 MUST 要求分配。
• STRONGLY RECOMMENDED 要求标记为 [SR]，但不分配 ID。
• ID 由以下部分组成：设备类型 ID - 条件 ID - 要求 ID（例如 C-0-1）。

每个 ID 的定义如下：

• 设备类型 ID（详情请参阅2. 设备类型）
  • C：核心（适用于所有 Android 设备实现的要求）
  • H：Android 手持设备
  • T：Android 电视设备
  • A：Android 车载系统实现
  • W：Android 手表实现
  • Tab：Android 平板电脑实现
• 条件 ID
  • 当要求是无条件的，此 ID 设置为 0。
  • 当要求是有条件的，对于同一章节和同一设备类型中的第一个条件，分配 1，编号依次递增。
• 要求 ID
  • 此 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 英寸到 8 英寸之间。
• 具有触摸屏输入界面。

本节其余部分中的附加要求特定于 Android 手持设备实现。

2.2.1. 硬件

手持设备实现

• [7.1.1.1/H-0-1] 必须至少有一个 Android 兼容显示屏，其短边至少为 2.2 英寸，长边至少为 3.4 英寸。

• [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% 或更高。

如果手持设备实现包含对 Vulkan 的支持，则它们

• [7.1.4.2/H-1-1] 必须满足Android Baseline 2021 配置文件中指定的各项要求。

如果手持设备实现通过 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.4.6/H-1-1] 必须以 protobuf 轨迹的形式报告输出，该轨迹需符合 Perfetto 文档中定义的 GPU 计数器和 GPU 渲染阶段的架构。
• [7.1.4.6/H-1-2] 必须根据 gpu 计数器轨迹数据包 proto，报告设备 GPU 计数器的符合性值。
• [7.1.4.6/H-1-3] 必须根据 渲染阶段轨迹数据包 proto，报告设备 GPU 渲染阶段的符合性值。
• [7.1.4.6/H-1-4] 必须报告 GPU 频率轨迹点，其格式由 power/gpu_frequency 指定。

手持设备实现

• [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] 强烈建议在长按 KEYCODE_MEDIA_PLAY_PAUSE 或 KEYCODE_HEADSETHOOK 时启动用户选择的辅助应用，换句话说，即实现 VoiceInteractionService 的应用，或处理 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 米/秒平方的加速度移动时，这些值应足以在至少 95% 的时间内将位置计算精度控制在 20 米以内，速度计算精度控制在 0.2 米/秒以内。

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

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

可以进行语音通话并在 getPhoneType 中指示 PHONE_TYPE_NONE 以外的任何值的手持设备实现

• [7.3.8/H] 应该配备接近传感器。

手持设备实现

• [7.3.11/H-SR-1] 强烈建议支持 6 自由度姿势传感器。

Android 15 的新增要求开始

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

• [7.4.2.5/H-1-1] 必须准确报告 160 MHz 带宽下 68% 百分位数（使用累积分布函数计算）的 +/-1 米范围、80 MHz 带宽下 68% 百分位数的 +/-2 米范围、40 MHz 带宽下 68% 百分位数的 +/-4 米范围，以及 20 MHz 带宽下 68% 百分位数的 +/-8 米范围（距离为 10 厘米、1 米、3 米和 5 米），如通过 WifiRttManager#startRanging Android API 观察到的那样。

• [7.4.2.5/H-SR-1] 强烈建议准确报告 160 MHz 带宽下 90% 百分位数（使用累积分布函数计算）的 +/-1 米范围、80 MHz 带宽下 90% 百分位数的 +/-2 米范围、40 MHz 带宽下 90% 百分位数的 +/-4 米范围，以及 20 MHz 带宽下 90% 百分位数的 +/-8 米范围（距离为 10 厘米），如通过 WifiRttManager#startRanging Android API 观察到的那样。

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

如果手持设备实现声明 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。

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

• [7.5.4/H-1-1] 默认情况下必须具有正常视场 (FOV)，且必须在 50 度到 60 度之间。

手持设备实现

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

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

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

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

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

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

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

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

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

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

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

请注意，上述“内核和用户空间可用的内存”是指除设备实现上已专用于无线装置、视频等硬件组件（不受内核控制）的任何内存之外提供的内存空间。

如果手持设备实现内核和用户空间可用的内存小于或等于 1GB，则它们

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

如果手持设备实现内核和用户空间可用的内存大于 1GB，则它们

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

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

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

如果手持设备实现内核和用户空间可用的内存小于 2GB，则它们

• [7.6.1/H-1-1] 必须仅支持单个 ABI（仅 64 位或仅 32 位）。

手持设备实现

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

Android 15 的新增要求开始

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

• [7.7.2/H-1-1] 必须实现 Android SDK 文档中记载的 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-C 端口并实现（USB 音频类），除了第 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，并将“microphone”extra 设置为 0。

当检测到 USB 音频终端类型 0x0402 时，它们

• [7.8.2.2/H-3-1] 必须广播 Intent ACTION_HEADSET_PLUG，并将“microphone”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 音频外围设备时，在 1000 毫秒内执行 USB 描述符的枚举、识别终端类型并广播 Intent ACTION_HEADSET_PLUG。

Android 15 的新增要求开始

线性谐振致动器 (LRA) 是一种单质量弹簧系统，它具有一个主导谐振频率，在该频率下，质量在所需运动方向上平移。

如果手持设备实现包括至少一个通用 7.10 线性谐振致动器，则它们

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

• [7.10/H] 应该在设备自然方向的 X 轴（左右）上移动触觉致动器。

如果手持设备实现具有通用触觉致动器，该致动器是 X 轴线性谐振致动器 (LRA)，则它们

• [7.10/H] 应该使 X 轴 LRA 的谐振频率低于 200 Hz。

如果手持设备实现遵循触觉常量映射，则它们

• [7.10/H]* 应该通过运行 android.os.Vibrator.areAllEffectsSupported() 和 android.os.Vibrator.arePrimitivesSupported() API 来验证实现状态。

• [7.10/H]* 应该对触觉常量执行 质量评估。

• [7.10/H]* 应该根据常量的 实施指南 验证和更新对不受支持的原语的回退配置（如果需要）。

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] 必须包含一个独立的浏览器应用程序，用于一般的用户 Web 浏览。
• [3.8.1/H-SR-1] 强烈建议实现一个默认启动器，该启动器支持应用内固定快捷方式、小部件和 widgetFeatures。
• [3.8.1/H-SR-2] 强烈建议实现一个默认启动器，该启动器通过 ShortcutManager API 提供对第三方应用程序提供的其他快捷方式的快速访问。
• [3.8.1/H-SR-3] 强烈建议包含一个默认启动器应用程序，该应用程序显示应用程序图标的徽章。
• [3.8.2/H-SR-1] 强烈建议支持第三方应用程序小部件。
• [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.Action.Builder.setContextual 设置为 true 的操作与 Notification.Remoteinput.Builder.setChoices 显示的回复内联显示。
• [3.8.4/H-SR-1] 强烈建议在设备上实现一个助手来处理 Assist action。

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

• [3.8.3.1/H-SR-2] 强烈建议从系统 UI 提供一个用户操作界面（例如，输出切换器），允许用户在适当的可用媒体路由（例如，蓝牙设备和提供给 MediaRouter2Manager 的路由）之间切换，当应用程序发布带有 MediaSession token 的 MediaStyle 通知时。

如果设备实现（包括 7.2.3 节中详述的最近使用的应用功能导航键）更改了界面，则它们

• [3.8.3/H-1-1] 必须实现屏幕固定行为，并为用户提供一个设置菜单来切换该功能。

如果手持设备实现支持 Assist action，则它们

• [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 和 Control API 的支持，并允许第三方应用程序发布 设备控件，那么它们

• [3.8.16/H-1-1] 必须声明功能标志 android.software.controls 并将其设置为 true。
• [3.8.16/H-1-2] 必须提供用户操作界面，以便从第三方应用程序通过 ControlsProviderService 和 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 和 Control Control.isAuthRequired API 注册的控件中选择退出应用程序指定的无需身份验证的设备控件。

• [3.8.16/H-1-6] 设备实现必须按如下方式准确呈现用户操作界面

  • 如果设备已设置 config_supportsMultiWindow=true 并且应用程序在 ControlsProviderService 声明中声明了元数据 META_DATA_PANEL_ACTIVITY，包括有效 Activity 的 ComponentName（由 API 定义），则应用程序必须将所述 Activity 嵌入到此用户操作界面中。
  • 如果应用程序未声明元数据 META_DATA_PANEL_ACTIVITY，则必须呈现 ControlsProviderService API 提供的指定字段以及 Control API 提供的任何指定字段。

• [3.8.16/H-1-7] 如果应用程序声明了元数据 META_DATA_PANEL_ACTIVITY，则必须在使用 EXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS 启动嵌入式 Activity 时传递 [3.8.16/H-1-5] 中定义的设置值。

相反，如果手持设备实现未实现此类控件，则它们

• [3.8.16/H-2-1] 必须为 ControlsProviderService 和 Control API 报告 null。
• [3.8.16/H-2-2] 必须声明功能标志 android.software.controls 并将其设置为 false。

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

• [3.8.17/H-1-1] 必须向用户显示已将数据复制到剪贴板的确认信息（例如，缩略图或“内容已复制”的提示）。此外，此处还应包含剪贴板数据是否将在设备之间同步的指示。

手持设备实现

• [3.10/H-0-1] 必须支持第三方辅助功能服务。
• [3.10/H-SR-1] 强烈建议在设备上预加载辅助功能服务，其功能应与 talkback 开源项目 中提供的 Switch Access 和 TalkBack（对于预安装的文本到语音引擎支持的语言）辅助功能服务相当或超出。
• [3.11/H-0-1] 必须支持安装第三方 TTS 引擎。
• [3.11/H-SR-1] 强烈建议包含一个支持设备上可用语言的 TTS 引擎。
• [3.13/H-SR-1] 强烈建议包含快速设置 UI 组件。

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

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

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

• [7.2.3/H] Home 功能的手势识别区域的高度不应高于屏幕底部 32 dp。

如果手持设备实现从屏幕左边缘和右边缘的任何位置提供导航功能作为手势

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

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

• [3.9/H-1-2] 必须声明通过 android.software.managed_users 功能标志对托管配置文件的支持。

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

• [7.5.4/H-1-1] 必须遵守 android.media.action.STILL_IMAGE_CAMERA 和 android.media.action.STILL_IMAGE_CAMERA_SECURE intent，并按照 SDK 中的描述在静止图像模式下启动摄像头。
• [7.5.4/H-1-2] 必须遵守 android.media.action.VIDEO_CAMERA intent，以按照 SDK 中的描述在视频模式下启动摄像头。

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

• [3.2.3.1/ H-1-1] 当拆分功能开启时，必须具有一个 Activity 来处理 Settings#ACTION_SETTINGS_EMBED_DEEP_LINK_ACTIVITY intent。该 Activity 必须受到 android.permission.LAUNCH_MULTI_PANE_SETTINGS_DEEP_LINK 的保护，并且必须启动从 Settings#EXTRA_SETTINGS_EMBEDDED_DEEP_LINK_INTENT_URI 解析的 Intent 的 Activity。

如果设备实现允许用户进行任何类型的呼叫，则它们

• [7.4.1.2/H-0-1] 必须声明功能标志 android.software.telecom。
• [7.4.1.2/H-0-2] 必须实现 telecom framework。

2.2.4. 性能和功耗

• [8.1/H-0-1] 一致的帧延迟。不一致的帧延迟或渲染帧的延迟发生频率不得超过每秒 5 帧，并且应该低于每秒 1 帧。
• [8.1/H-0-2] 用户界面延迟。设备实现必须通过在 36 秒内滚动 Android 兼容性测试套件 (CTS) 定义的 10K 列表条目列表来确保低延迟用户体验。
• [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] 必须提供用户操作界面以显示所有免于应用待机和 Doze 省电模式的应用程序。

手持设备实现

• [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.4/H-1-1] 必须遵守 android.intent.action.POWER_USAGE_SUMMARY intent，并显示一个设置菜单，其中显示此功耗信息。

手持设备实现

• [8.5/H-0-1] 必须提供用户操作界面，以查看所有具有活动前台服务或用户启动的作业的应用程序，包括自启动以来每个服务的持续时间，如 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 15 的新增要求开始

如果设备实现声明支持 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、SHA-1 和 SHA-2 系列哈希函数的实现，以便在与内核及更高版本上运行的代码安全隔离的区域中正确支持 Android Keystore 系统支持的算法。安全隔离必须阻止内核或用户空间代码可能访问隔离环境内部状态的所有潜在机制，包括 DMA。上游 Android 开源项目 (AOSP) 通过使用 Trusty 实现来满足此要求，但另一个基于 ARM TrustZone 的解决方案或第三方审查的基于适当虚拟机监控程序隔离的安全实现也是替代方案。
• [9.11/H-0-4] 必须在隔离的执行环境中执行锁屏身份验证，并且仅在成功时才允许使用绑定身份验证的密钥。锁屏凭据的存储方式必须仅允许隔离的执行环境执行锁屏身份验证。上游 Android 开源项目提供了 Gatekeeper 硬件抽象层 (HAL) 和 Trusty，可用于满足此要求。

Android 15 的新增要求开始

请注意，如果设备实现已在早期 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 对启用/禁用其他用户访问语音呼叫和 SMS 的控件的实现保持一致。

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

• [9.5/H-4-1] 不得包含对 eUICC 或具有呼叫功能的 eSIM 的支持。
• [9.5/H-4-2] 不得声明对 android.hardware.telephony 的支持。

Android 通过 System API VoiceInteractionService 支持一种用于安全常时热词检测的机制，无需麦克风访问指示，以及常时查询检测，无需麦克风或摄像头访问指示。

Android 15 的新增要求开始

如果手持设备实现支持 System API HotwordDetectionService 或其他用于热词检测且不指示麦克风访问权限的机制，则这些实现

• [9.8/H-1-1] 必须确保热词检测服务只能将数据传输到系统、ContentCaptureService 或由 SpeechRecognizer#createOnDeviceSpeechRecognizer() 创建的设备端语音识别服务。
• [9.8/H-1-2] 必须确保热词检测服务只能通过 HotwordDetectionService API 将麦克风音频数据或从中派生的数据传输到系统服务器，或者通过 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 字节的数据（不包括音频流）。
• [9.8/H-1-7] 对于每次负面热词结果，不允许从热词检测服务传输超过 5 位的数据。
• [9.8/H-1-8] 仅允许在来自系统服务器的热词验证请求时，才能从热词检测服务传输数据。
• [9.8/H-1-9] 不得允许用户可安装的应用提供热词检测服务。
• [9.8/H-1-10] 不得在 UI 中显示有关热词检测服务麦克风使用情况的定量数据。
• [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 次硬件触发事件（以先到者为准）重启托管热词检测服务的进程一次。

如果设备实现包含使用 System API HotwordDetectionService 或类似机制进行热词检测且不指示麦克风使用情况的应用，则该应用

• [9.8/H-2-1] 必须为支持的每个热词短语提供明确通知给用户。
• [9.8/H-2-2] 不得通过热词检测服务保留原始音频数据或从中派生的数据。
• [9.8/H-2-3] 不得从热词检测服务传输音频数据、可用于（全部或部分）重建音频的数据或与热词本身无关的音频内容，除非传输到 ContentCaptureService 或设备端语音识别服务。

如果手持设备实现支持 System API VisualQueryDetectionService 或其他用于查询检测且不指示麦克风和/或摄像头访问权限的机制，则这些实现

• [9.8/H-3-1] 必须确保查询检测服务只能将数据传输到系统、ContentCaptureService 或设备端语音识别服务（由 SpeechRecognizer#createOnDeviceSpeechRecognizer() 创建）。
• [9.8/H-3-2] 不允许从 VisualQueryDetectionService 传输任何音频或视频信息，除非传输到 ContentCaptureService 或设备端语音识别服务。
• [9.8/H-3-3] 当设备检测到用户打算与数字助理应用互动时（例如，通过摄像头检测用户存在），必须在系统 UI 中显示用户通知。
• [9.8/H-3-4] 必须在检测到用户查询后立即显示麦克风指示器，并在 UI 中显示检测到的用户查询。
• [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() 的最近和活跃麦克风使用应用列表，以及与它们关联的任何归因消息。
• [9.8.2/H-4-3] 不得为具有可见用户界面或直接用户交互的系统应用隐藏麦克风指示器。
• [9.8.2/H-4-4] 必须显示来自 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() 的最近和活跃摄像头使用应用列表，以及与它们关联的任何归因消息。
• [9.8.2/H-5-3] 不得为具有可见用户界面或直接用户交互的系统应用隐藏摄像头指示器。

Android 15 的新增要求开始

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

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

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

Android 15 的新增要求开始

2.2.7. 手持媒体性能等级

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

2.2.7.1. 媒体

如果手持设备实现为 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 返回 android.os.Build.VERSION_CODES.U，则这些实现

• 必须满足 Android 14 CDD 第 2.2.7.1 节中列出的媒体要求。

Android 15 的新增要求开始

• [5.1/H-1-1] 必须通过 CodecCapabilities.getMaxSupportedInstances() 和 VideoCapabilities.getSupportedPerformancePoints() 方法，通告可以在任何编解码器组合中并发运行的最大硬件视频解码器会话数。

Android 15 的新增要求开始

• [5.1/H-1-3] 必须通过 CodecCapabilities.getMaxSupportedInstances() 和 VideoCapabilities.getSupportedPerformancePoints() 方法，通告可以在任何编解码器组合中并发运行的最大硬件视频编码器会话数。

Android 15 的新增要求开始

• [5.1/H-1-5] 必须通过 CodecCapabilities.getMaxSupportedInstances() 和 VideoCapabilities.getSupportedPerformancePoints() 方法，通告可以在任何编解码器组合中并发运行的最大硬件视频编码器和解码器会话数。

Android 15 的新增要求开始

Android 15 的新增要求开始

• [5.1/H-1-7] 对于所有硬件视频编码器，在负载下，1080p 或更小视频编码会话的编解码器初始化延迟必须为 40 毫秒或更短。此处的负载定义为使用硬件视频编解码器并发进行 1080p 到 720p 纯视频转码会话，以及 1080p 音视频录制初始化。对于杜比视界编解码器，编解码器初始化延迟必须为 50 毫秒或更短。
• [5.1/H-1-8] 对于所有音频编码器，在负载下，128 kbps 或更低比特率音频编码会话的编解码器初始化延迟必须为 30 毫秒或更短。此处的负载定义为使用硬件视频编解码器并发进行 1080p 到 720p 纯视频转码会话，以及 1080p 音视频录制初始化。

Android 15 的新增要求开始

Android 15 的新增要求开始

• [5.1/H-1-11] 必须为设备上的每个硬件 AVC、HEVC、VP9 或 AV1 解码器支持安全解码器。
• [5.1/H-1-12] 对于所有硬件视频解码器，在负载下，1080p 或更小视频解码会话的编解码器初始化延迟必须为 40 毫秒或更短。此处的负载定义为使用硬件视频编解码器并发进行 1080p 到 720p 纯视频转码会话，以及 1080p 音视频播放初始化。对于杜比视界编解码器，编解码器初始化延迟必须为 50 毫秒或更短。
• [5.1/H-1-13] 对于所有音频解码器，在负载下，128 kbps 或更低比特率音频解码会话的编解码器初始化延迟必须为 30 毫秒或更短。此处的负载定义为使用硬件视频编解码器并发进行 1080p 到 720p 纯视频转码会话，以及 1080p 音视频播放初始化。

Android 15 的新增要求开始

• [5.1/H-1-15] 必须至少有 1 个支持 4K60 的硬件视频解码器。
• [5.1/H-1-16] 必须至少有 1 个支持 4K60 的硬件视频编码器。

Android 15 的新增要求开始

Android 15 的新增要求开始

• [5.3/H-1-1] 对于 4K 60 fps 视频会话，在负载下，每 10 秒不得丢帧超过 1 帧（即，丢帧率低于 0.167%）。
• [5.3/H-1-2] 对于 4K 会话，在 60 fps 视频会话中进行视频分辨率更改期间，每 10 秒不得丢帧超过 1 帧。
• [5.6/H-1-1] 使用 CTS Verifier tap-to-tone 测试时，tap-to-tone 延迟必须为 80 毫秒或更短。
• [5.6/H-1-2] 至少在一个支持的数据路径上，往返音频延迟必须为 80 毫秒或更短。
• [5.6/H-1-3] 如果存在 3.5 毫米音频插孔，并且如果通过整个数据路径（用于低延迟和流式传输配置）支持 USB 音频，则必须为立体声输出支持 >= 24 位音频。对于低延迟配置，应用程序应在低延迟回调模式下使用 AAudio。对于流式传输配置，应用程序应使用 Java AudioTrack。在低延迟和流式传输配置中，HAL 输出接收器应接受 AUDIO_FORMAT_PCM_24_BIT、AUDIO_FORMAT_PCM_24_BIT_PACKED、AUDIO_FORMAT_PCM_32_BIT 或 AUDIO_FORMAT_PCM_FLOAT 作为其目标输出格式。

Android 15 的新增要求开始

• [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 Baseline Profile 的硬件图像解码器。
• [5.1/H-1-18] 必须支持 AV1 编码器，该编码器可以编码高达 480p 分辨率（30fps 和 1Mbps）。

Android 15 的新增要求开始

• [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) 中至少有 6 个硬件叠加层，其中至少 2 个能够显示 10 位视频内容。

Android 15 的新增要求开始

• [5.2/H-2-1] 必须满足硬件 AVC 和 HEVC 编解码器的视频编码器速率失真曲线定义的最低质量目标，如 运行性能等级 14 (PC14) - 视频编码质量 (VEQ) 测试 中所定义。

2.2.7.2. 摄像头

如果手持设备实现为 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 返回 android.os.Build.VERSION_CODES.U，则这些实现

• 必须满足 Android 14 CDD 第 2.2.7.2 节中列出的媒体要求。

Android 15 的新增要求开始

Android 15 的新增要求开始

• [7.5/H-1-2] 必须具有分辨率至少为 6 兆像素的主前置摄像头，并支持 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] 对于两个主摄像头，在 ITS 照明条件 (3000K) 下，CTS 摄像头 PerformanceTest 测量的 1080p 分辨率的 camera2 JPEG 拍摄延迟必须 < 1000 毫秒。
• [7.5/H-1-6] 对于两个主摄像头，在 ITS 照明条件 (3000K) 下，CTS 摄像头 PerformanceTest 测量的 camera2 启动延迟（打开摄像头到第一帧预览帧）必须 < 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)。

Android 15 的新增要求开始

2.2.7.3. 硬件

如果手持设备实现为 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 返回 android.os.Build.VERSION_CODES.U，则这些实现

• 必须满足 Android 14 CDD 第 2.2.7.3 节中列出的媒体要求。

Android 15 的新增要求开始

• [7.1.1.1/H-2-1] 屏幕分辨率必须至少为 1080p。

Android 15 的新增要求开始

• [7.1.1.3/H-3-1] 必须具有支持至少 1000 尼特平均亮度的 HDR 显示屏。

Android 15 的新增要求开始

2.2.7.4. 性能

如果手持设备实现为 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 返回 android.os.Build.VERSION_CODES.U，则这些实现

• 必须满足 Android 14 CDD 第 2.2.7.4 节中列出的性能要求。

Android 15 的新增要求开始

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

Android 15 的新增要求开始

2.2.7.5. 图形

2.3. 电视要求

Android 电视设备是指 Android 设备实现，它是一种娱乐界面，供用户在约 10 英尺远的位置（“后仰式”或“10 英尺用户界面”）消费数字媒体、电影、游戏、应用和/或直播电视。

如果 Android 设备实现满足以下所有条件，则将其归类为电视

• 已提供一种机制来远程控制显示屏上呈现的用户界面，该显示屏可能位于距用户 10 英尺远的位置。
• 具有对角线长度大于 24 英寸的嵌入式屏幕显示屏，或者包括视频输出端口，例如 VGA、HDMI、DisplayPort 或用于显示的无线端口。

本节其余部分中的附加要求特定于 Android 电视设备实现。

2.3.1. 硬件

电视设备实现

• [7.2.2/T-0-1] 必须支持 D-pad。
• [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] 应该提供遥控器，用户可以通过该遥控器访问 非触摸导航 和 核心导航键 输入。

如果电视设备实现包含 3 轴陀螺仪，则这些实现

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

电视设备实现

• [7.4.3/T-0-1] 必须支持蓝牙和低功耗蓝牙。
• [7.6.1/T-0-1] 必须具有至少 4 GB 的非易失性存储空间，可用于应用程序私有数据（又名“/data”分区）。

如果电视设备实现包括支持主机模式的 USB 端口，则这些实现

• [7.5.3/T-1-1] 必须包含对通过此 USB 端口连接的外部摄像头的支持，但不一定始终连接。

如果电视设备实现是 32 位

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

  • 小型/普通屏幕上的 400dpi 或更高
  • 大型屏幕上的 xhdpi 或更高
  • 超大屏幕上的 tvdpi 或更高

如果电视设备实现是 64 位

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

  • 小型/普通屏幕上的 400dpi 或更高
  • 大型屏幕上的 xhdpi 或更高
  • 超大屏幕上的 tvdpi 或更高

请注意，上述“内核和用户空间可用的内存”是指除设备实现上已专用于无线装置、视频等硬件组件（不受内核控制）的任何内存之外提供的内存空间。

电视设备实现

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

2.3.2. 多媒体

电视设备实现必须支持以下音频编码和解码格式，并使它们可供第三方应用程序使用

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

电视设备实现**必须**支持以下视频编码格式，并向第三方应用程序开放这些格式

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

电视设备实现

• [5.2.2/T-SR-1] **强烈建议**支持 720p 和 1080p 分辨率视频在每秒 30 帧的 H.264 编码。

电视设备实现**必须**支持以下视频解码格式，并向第三方应用程序开放这些格式

• [5.3.3/T-0-1] MPEG-4 SP
• [5.3.4/T-0-2] H.264 AVC
• [5.3.5/T-0-3] H.265 HEVC
• [5.3.6/T-0-4] VP8
• [5.3.7/T-0-5] VP9
• [5.3.1/T-0-6] MPEG-2
• [5.3.2/T-0-7] AV1

电视设备实现**必须**支持 MPEG-2 解码，具体细节请参考 5.3.1 节，在标准视频帧率和分辨率下，最高可达

• [5.3.1/T-1-1] 高清 1080p，29.97 帧/秒，主Profile 高级别。
• [5.3.1/T-1-2] 高清 1080i，59.94 帧/秒，主Profile 高级别。它们**必须**对隔行扫描 MPEG-2 视频进行去隔行处理，并向第三方应用程序开放。

电视设备实现**必须**支持 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 硬件解码器的电视设备实现**必须**支持 H.265 解码，具体细节请参考 5.3.5 节，在标准视频帧率和分辨率下，最高可达

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

如果配备 H.265 硬件解码器的电视设备实现支持 H.265 解码和 UHD 解码 Profile，则它们

• [5.3.5/T-2-1] **必须**支持 UHD 解码 Profile，60 帧/秒，Main10 Level 5 Main Tier profile

电视设备实现**必须**支持 VP8 解码，具体细节请参考 5.3.6 节，在标准视频帧率和分辨率下，最高可达

• [5.3.6/T-1-1] 高清 1080p，60 帧/秒解码 Profile

配备 VP9 硬件解码器的电视设备实现**必须**支持 VP9 解码，具体细节请参考 5.3.7 节，在标准视频帧率和分辨率下，最高可达

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

如果配备 VP9 硬件解码器的电视设备实现支持 VP9 解码和 UHD 解码 Profile，则它们

• [5.3.7/T-2-1] **必须**支持 UHD 解码 Profile，60 帧/秒，profile 0（8 位颜色深度）。
• [5.3.7/T-SR1] **强烈建议**支持 UHD 解码 Profile，60 帧/秒，profile 2（10 位颜色深度）。

电视设备实现

• [5.5/T-0-1] **必须**包含对系统主音量和数字音频输出音量衰减的支持，在支持的输出上，压缩音频直通输出（设备上未进行音频解码）除外。

如果电视设备实现没有内置显示屏，而是支持通过 HDMI 连接的外部显示屏，则它们

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

如果电视设备实现没有内置显示屏，而是支持通过 HDMI 连接的外部显示屏，则它们

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

如果电视设备实现不支持 UHD 解码，而是支持通过 HDMI 连接的外部显示屏，则它们

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

2.3.3. 软件

电视设备实现

• [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 电视设备实现支持锁屏，则它们

• [3.8.10/T-1-1] **必须**显示锁屏通知，包括媒体通知模板。

电视设备实现

• [3.8.14/T-SR-1] **强烈建议**支持画中画 (PIP) 模式多窗口。
• [3.10/T-0-1] **必须**支持第三方辅助功能服务。
• [3.10/T-SR-1] **强烈建议**在设备上预加载辅助功能服务，其功能应与 Switch Access 和 TalkBack（对于预装的文本转语音引擎支持的语言）辅助功能服务相当或超过它们的功能，如 talkback 开源项目 中提供的服务。

如果电视设备实现报告了功能 android.hardware.audio.output，则它们

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

Android 15 的新增要求开始

Android 15 的新增要求开始

2.3.4. 性能和功耗

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

如果电视设备实现包含 AOSP 中包含的或扩展 AOSP 中包含的功能以改进设备电源管理的功能，则它们

• [8.3/T-1-1] **必须**提供用户界面来启用和停用省电功能。

如果电视设备实现没有电池，则它们

• [8.3/T-1-2] **必须**按照 支持无电池设备 中的描述，将设备注册为无电池设备。

如果电视设备实现有电池，则它们

• [8.3/T-1-3] **必须**提供用户界面来显示所有免于应用待机和 Doze 省电模式的应用。

电视设备实现

• [8.4/T-0-1] **必须**提供每个组件的功耗 Profile，其中定义了每个硬件组件的 电流消耗值 以及组件随时间推移造成的大致电池电量消耗，如 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. 安全模型

电视设备实现

• [9/T-0-1] **必须**声明 android.hardware.security.model.compatible 功能。
• [9.11/T-0-1] **必须**使用隔离的执行环境来支持密钥库实现。
• [9.11/T-0-2] **必须**具有 RSA、AES、ECDSA 和 HMAC 加密算法以及 MD5、SHA-1 和 SHA-2 系列哈希函数的实现，以便在安全隔离于内核及以上代码运行区域的区域中正确支持 Android Keystore 系统支持的算法。安全隔离**必须**阻止内核或用户空间代码可能访问隔离环境内部状态的所有潜在机制，包括 DMA。上游 Android 开源项目 (AOSP) 通过使用 Trusty 实现来满足此要求，但另一个基于 ARM TrustZone 的解决方案或第三方审核的适当基于虚拟机监控程序的隔离的安全实现也是备选方案。
• [9.11/T-0-3] **必须**在隔离的执行环境中执行锁屏身份验证，并且仅在身份验证成功时，才允许使用与身份验证绑定的密钥。锁屏凭据**必须**以仅允许隔离的执行环境执行锁屏身份验证的方式存储。上游 Android 开源项目提供了 Gatekeeper 硬件抽象层 (HAL) 和 Trusty，可用于满足此要求。

Android 15 的新增要求开始

请注意，如果设备实现已在早期 Android 版本上启动，则此类设备免于密钥库由隔离的执行环境支持并支持密钥证明的要求，除非它声明 android.hardware.fingerprint 功能，该功能需要由隔离的执行环境支持的密钥库。

如果电视设备实现支持安全锁屏，则它们

• [9.11/T-1-1] **必须**允许用户选择从解锁状态转换到锁定状态的睡眠超时时间，最小允许超时时间最多为 15 秒或更短。

如果电视设备实现包含多用户，并且未声明 android.hardware.telephony 功能标记，则它们

• [9.5/T-2-1] **必须**支持受限 Profile，此功能允许设备所有者管理设备上的其他用户及其功能。借助受限 Profile，设备所有者可以快速为其他用户设置独立的环境以供工作，并能够更精细地管理这些环境中可用的应用。

如果电视设备实现包含多用户，并且声明了 android.hardware.telephony 功能标记，则它们

• [9.5/T-3-1] **不得**支持受限 Profile，但**必须**与 AOSP 的控件实现保持一致，以启用/停用其他用户访问语音通话和短信。

如果电视设备实现声明了 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] 对于具有可见用户界面或直接用户交互的系统应用，**不得**隐藏麦克风指示器。

如果电视设备实现声明了 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. 开发者工具和选项兼容性

Android 15 的新增要求开始

2.4. 手表要求

**Android 手表设备**是指旨在佩戴在身体上（可能是在手腕上）的 Android 设备实现。

如果 Android 设备实现满足以下所有标准，则归类为手表

• 屏幕的物理对角线长度在 1.1 到 2.5 英寸范围内。
• 提供佩戴在身体上的机制。

本节其余部分中的附加要求特定于 Android 手表设备实现。

2.4.1. 硬件

手表设备实现

• [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 轴加速度计。

如果手表设备实现包含 GPS/GNSS 接收器，并通过 android.hardware.location.gps 功能标记向应用程序报告此功能，则它们

• [7.3.3/W-1-1] **必须**报告 GNSS 测量值，即使尚未报告从 GPS/GNSS 计算的位置，也应尽快报告。
• [7.3.3/W-1-2] **必须**报告 GNSS 伪距和伪距率，在开阔天空条件下，确定位置后，当静止或以小于 0.2 米/秒平方的加速度移动时，这些值应足以在 20 米内计算位置，并在 0.2 米/秒内计算速度，至少 95% 的时间。

如果手表设备实现包含 3 轴陀螺仪，则它们

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

手表设备实现

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

手表设备实现

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

手表设备实现

• [3.8.4/W-SR-1] **强烈建议**在设备上实现助手以处理 Assist 操作。

声明了 android.hardware.audio.output 功能标记的手表设备实现

• [3.10/W-1-1] **必须**支持第三方辅助功能服务。
• [3.10/W-SR-1] **强烈建议**在设备上预加载辅助功能服务，其功能应与 Switch Access 和 TalkBack（对于预装的文本转语音引擎支持的语言）辅助功能服务相当或超过它们的功能，如 talkback 开源项目 中提供的服务。

如果手表设备实现报告了功能 android.hardware.audio.output，则它们

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

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

2.4.4. 性能和功耗

如果手表设备实现包含 AOSP 中包含的或扩展 AOSP 中包含的功能以改进设备电源管理的功能，则它们

• [8.3/W-SR-1] **强烈建议**提供用户界面来显示所有免于应用待机和 Doze 省电模式的应用。
• [8.3/W-SR-2] **强烈建议**提供用户界面来启用和停用省电功能。

手表设备实现

• [8.4/W-0-1] **必须**提供每个组件的功耗 Profile，其中定义了每个硬件组件的 电流消耗值 以及组件随时间推移造成的大致电池电量消耗，如 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. 安全模型

手表设备实现

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

如果手表设备实现包含多用户，并且未声明 android.hardware.telephony 功能标记，则它们

• [9.5/W-1-1] **必须**支持受限 Profile，此功能允许设备所有者管理设备上的其他用户及其功能。借助受限 Profile，设备所有者可以快速为其他用户设置独立的环境以供工作，并能够更精细地管理这些环境中可用的应用。

如果手表设备实现包含多用户，并且声明了 android.hardware.telephony 功能标记，则它们

• [9.5/W-2-1] **不得**支持受限 Profile，但**必须**与 AOSP 的控件实现保持一致，以启用/停用其他用户访问语音通话和短信。

如果设备实现具有安全锁屏并包含一个或多个信任代理（实现 TrustAgentService 系统 API），则它们

• [9.11.1/W-1-1] **必须**比每 72 小时一次更频繁地要求用户提供推荐的主要身份验证方法之一（例如：PIN 码、图案、密码）。

2.5. 汽车要求

**Android Automotive 实现**是指运行 Android 作为系统一部分或全部系统和/或信息娱乐功能的车载主机。

如果 Android 设备实现声明了功能 android.hardware.type.automotive 或满足以下所有标准，则归类为 Automotive。

• 嵌入为汽车车辆的一部分或可插入汽车车辆。
• 在驾驶员座椅排中使用屏幕作为主显示屏。

本节其余部分中的附加要求特定于 Android Automotive 设备实现。

2.5.1. 硬件

Automotive 设备实现

• [7.1.1.1/A-0-1] **必须**具有物理对角线尺寸至少为 6 英寸的屏幕。
• [7.1.1.1/A-0-2] **必须**具有至少 750 dp x 480 dp 的屏幕尺寸布局。

Android 15 的新增要求开始

如果 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 设备实现

Android 15 的新增要求开始

• [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 传感器。

Android 15 的新增要求开始

如果 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] **强烈建议**将陀螺仪的测量范围配置为 +/-250dps，以便最大限度地提高可能的分辨率。

如果 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 中描述的首次定位时间标准。在没有基于蜂窝网络的数据连接的车辆中，通常通过使用接收器上计算的 GNSS 轨道预测，或使用上次已知的车辆位置以及至少 60 秒的航位推算能力（位置精度满足 7.3.3/C-1-3），或两者结合来满足要求 7.3.3/C-1-2。

如果 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 实现**必须**支持以下蓝牙 Profile
  • 通过免提 Profile (HFP) 进行电话呼叫。
  • 通过音频分发 Profile (A2DP) 进行媒体播放。
  • 通过远程控制 Profile (AVRCP) 进行媒体播放控制。
  • 使用电话簿访问 Profile (PBAP) 进行联系人共享。

Android 15 的新增要求开始

Android 15 的新增要求开始

Automotive 设备实现

• [7.4.5/A] **应该**包含对基于蜂窝网络的数据连接的支持。
• [7.4.5/A] **可以**将系统 API NetworkCapabilities#NET_CAPABILITY_OEM_PAID 常量用于应供系统应用使用的网络。

如果设备实现包含对 AM/FM 广播无线电的支持，并将功能公开给任何应用程序，则它们

• [7.4/A-1-1] **必须**声明对 FEATURE_BROADCAST_RADIO 的支持。

后置摄像头是指朝向世界的摄像头，它可以位于车辆上的任何位置，并且朝向车辆座舱外部；也就是说，它可以拍摄车辆车身远侧的场景，例如后视摄像头。

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

Automotive 设备实现

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

如果汽车设备实现方案包含至少一个朝向世界的摄像头，那么对于此类摄像头，它们

• [7.5/A-1-1] 必须 定向，使其长边与 Android 汽车传感器轴的 X-Y 平面对齐。
• [7.5/A-SR-3] 强烈建议 具有固定焦距或 EDOF（扩展景深）硬件。
• [7.5/A-1-2] 必须 将主朝向世界的摄像头作为摄像头 ID 最小的朝向世界的摄像头。

如果汽车设备实现方案包含至少一个朝向用户的摄像头，那么对于此类摄像头

• [7.5/A-2-1] 主朝向用户的摄像头 必须 是摄像头 ID 最小的朝向用户的摄像头。
• 可以 定向，使其长边与 Android 汽车传感器轴的 X-Y 平面对齐。

如果汽车设备实现方案包含可通过 android.hardware.Camera 或 android.hardware.camera2 API 访问的摄像头，那么它们

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

如果汽车设备实现方案包含不可通过 android.hardware.Camera 或 android.hardware.camera2 API 访问的摄像头，那么它们

• [7.5/A-4-1] 必须 可通过扩展视图系统服务访问。

如果汽车设备实现方案包含一个或多个可通过扩展视图系统服务访问的摄像头，那么对于此类摄像头，它们

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

如果汽车设备实现方案包含一个或多个可通过扩展视图系统服务和 android.hardware.Camera 或 android.hardware.Camera2 API 访问的摄像头，那么对于此类摄像头，它们

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

如果汽车设备实现方案提供专有的摄像头 API，那么它们

• [7.5/A-7-1] 必须 使用 android.hardware.camera2 API 或扩展视图系统 API 来实现此类摄像头 API。

Automotive 设备实现

• [7.6.1/A-0-1] 必须 具有至少 4 GB 的非易失性存储空间，用于存储应用专用数据（/data 分区）。

• [7.6.1/A] 应该 格式化数据分区，以便在闪存存储器上提供更高的性能和更长的使用寿命（例如，使用 f2fs 文件系统）。

如果汽车设备实现方案通过内部不可移动存储器的一部分提供共享外部存储空间，那么它们

• [7.6.1/A-SR-1] 强烈建议 减少在外部存储器上执行操作时的 I/O 开销，例如使用 SDCardFS。

Android 15 的新增要求开始

如果汽车设备实现方案是 64 位

Android 15 的新增要求开始

Automotive 设备实现

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

Automotive 设备实现

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

Automotive 设备实现

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

Android 15 的新增要求开始

2.5.2. 多媒体

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

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

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

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

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

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

强烈建议 汽车设备实现方案支持以下视频解码

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

Android 15 的新增要求开始

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。

如果汽车设备实现方案使用 android.car.CarPropertyManager 和 android.car.VehiclePropertyIds 提供专有 API，那么它们

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

Automotive 设备实现

• [3.2.1/A-0-1] 必须 支持并强制执行 汽车权限参考页中记录的所有权限常量。

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

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

Android 15 的新增要求开始

Automotive 设备实现

• [3.8.3/A-0-1] 必须 在第三方应用请求时，显示使用 Notification.CarExtender API 的通知。

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

如果汽车设备实现方案包含一键通按钮，那么它们

• [3.8.4/A-1-1] 必须 使用短按一键通按钮作为指定互动操作，以启动用户选择的助理应用，换句话说，即实现 VoiceInteractionService 的应用。

Automotive 设备实现

• [3.8.3.1/A-0-1] 必须 正确呈现 Notifications on Automotive OS SDK 文档中所述的资源。
• [3.8.3.1/A-0-2] 必须 显示通知操作的“播放”和“静音”，以取代通过 Notification.Builder.addAction() 提供的操作。
• [3.8.3.1/A] 应该 限制使用丰富的管理任务，例如按通知渠道控件。可以 对每个应用使用界面辅助功能来减少控件。

如果汽车设备实现方案支持用户 HAL 属性，那么它们

• [3.9.3/A-1-1] 必须 实现所有 用户生命周期属性
  • INITIAL_USER_INFO、SWITCH_USER、CREATE_USER、REMOVE_USER。

Automotive 设备实现

• [3.14/A-0-1] 必须 包含一个 UI 框架，以支持第三方应用使用第 3.14 节中所述的媒体 API。
• [3.14/A-0-2] 必须 允许用户在驾驶时安全地与媒体应用互动。
• [3.14/A-0-3] 必须 支持 CAR_INTENT_ACTION_MEDIA_TEMPLATE 隐式 Intent 操作以及 CAR_EXTRA_MEDIA_PACKAGE extra。
• [3.14/A-0-4] 必须 提供一种辅助功能，以导航到媒体应用的 偏好设置 Activity，但 必须 仅在汽车用户体验限制未生效时启用它。
• [3.14/A-0-5] 必须 显示媒体应用设置的 错误消息，并且 必须 支持可选的 extra ERROR_RESOLUTION_ACTION_LABEL 和 ERROR_RESOLUTION_ACTION_INTENT。
• [3.14/A-0-6] 必须 为支持搜索的应用支持应用内搜索辅助功能。
• [3.14/A-0-7] 在显示 MediaBrowser 层次结构时，必须 遵守 CONTENT_STYLE_BROWSABLE_HINT 和 CONTENT_STYLE_PLAYABLE_HINT 定义。

如果汽车设备实现方案包含默认启动器应用，那么它们

• [3.14/A-1-1] 必须 包含媒体服务，并使用 CAR_INTENT_ACTION_MEDIA_TEMPLATE intent 打开它们。

Automotive 设备实现

• [3.8/A] 可以 限制应用进入全屏模式的请求，如 沉浸式文档中所述。
• [3.8/A] 可以 始终保持状态栏和导航栏可见。
• [3.8/A] 可以 限制应用更改系统 UI 元素后面的颜色的请求，以确保这些元素始终清晰可见。

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. 安全模型

如果汽车设备实现方案支持多用户，那么它们

• [9.5/A-1-1] 必须 不允许用户与 无头系统用户 互动或切换到该用户，设备配置 除外。
• [9.5/A-1-2] 必须 在 BOOT_COMPLETED 之前切换到 辅助用户。
• [9.5/A-1-3] 必须 支持创建 访客用户 的功能，即使设备上的用户数已达到上限也是如此。

如果汽车设备实现方案声明 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] 必须 提供一个用户辅助功能，用于在“设置”应用中切换麦克风。

如果汽车设备实现方案声明 android.hardware.camera.any，那么它们

• [9.8.2/A-2-1] 必须 在应用正在访问实时摄像头数据时显示摄像头指示器，但在摄像头仅由在 第 9.1 节权限中 CDD 标识符为 [C-4-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、SHA-1 和 SHA-2 系列哈希函数的实现方案，以便在安全隔离于内核及更高层级运行的代码的区域中正确支持 Android 密钥库系统支持的算法。安全隔离 必须 阻止内核或用户空间代码可能访问隔离环境内部状态的所有潜在机制，包括 DMA。上游 Android 开源项目 (AOSP) 通过使用 Trusty 实现方案来满足此要求，但基于 ARM TrustZone 的其他解决方案或经过第三方审核的基于适当虚拟机监控程序的隔离的安全实现方案也是替代选项。
• [9.11/A-0-3] 必须 在隔离的执行环境中执行锁屏身份验证，并且仅在验证成功后，才允许使用身份验证绑定的密钥。锁屏凭据 必须 以仅允许隔离的执行环境执行锁屏身份验证的方式存储。上游 Android 开源项目提供了 Gatekeeper 硬件抽象层 (HAL) 和 Trusty，可用于满足此要求。

Android 15 的新增要求开始

请注意，如果设备实现已在早期 Android 版本上启动，则此类设备免于密钥库由隔离的执行环境支持并支持密钥证明的要求，除非它声明 android.hardware.fingerprint 功能，该功能需要由隔离的执行环境支持的密钥库。

Automotive 设备实现

• [9.14/A-0-1] 必须 对来自 Android 框架车辆子系统的消息进行门控控制，例如，允许列出允许的消息类型和消息来源。
• [9.14/A-0-2] 必须 防范来自 Android 框架或第三方应用的拒绝服务攻击。这可以防止恶意软件用流量淹没车辆网络，这可能会导致车辆子系统发生故障。

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

Android 15 的新增要求开始

2.6. 平板电脑要求

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

• 用双手握持使用。
• 没有翻盖式或可转换配置。
• 与设备一起使用的物理键盘实现方案通过标准连接方式（例如 USB、蓝牙）连接。

• 具有提供移动性的电源，例如电池。

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

平板电脑设备实现方案与手持设备实现方案具有类似的要求。例外情况在该部分中以 * 指示，并在本节中注明以供参考。

2.6.1. 硬件

陀螺仪

如果平板电脑设备实现方案包含 3 轴陀螺仪，那么它们

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

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

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

Android 15 的新增要求开始

虚拟现实模式（第 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] 必须 提供 Android SDK 公开的任何文档化 API 或上游 Android 源代码中任何使用“@SystemApi”标记修饰的 API 的完整实现方案，包括所有文档化行为。

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

• [C-0-3] 必须 不得省略任何受管理 API，不得更改 API 接口或签名，不得偏离文档化行为，也不得包含空操作，除非本兼容性定义明确允许。

• [C-0-4] 即使省略了 Android 包含 API 的某些硬件功能，也 必须 仍然保持 API 存在并以合理的方式运行。有关此场景的具体要求，请参阅第 7 节。

• [C-0-5] 必须 不允许第三方应用使用非 SDK 接口，这些接口定义为 AOSP 中启动类路径下的 Java 语言包中的方法和字段，并且不构成公共 SDK 的一部分。这包括使用 @hide 注解但未使用 @SystemAPI 修饰的 API，如 SDK 文档和私有及包私有类成员中所述。

• [C-0-6] 必须 随附每个非 SDK 接口，这些接口与 AOSP 中相应 API 级别分支的 prebuilts/runtime/appcompat/hiddenapi-flags.csv 路径中通过 provisional 和 denylist 标记提供的受限列表位于相同的受限列表中。

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

  但是，它们

  • 可以 在设备实现方案中缺少隐藏 API 或以不同方式实现时，将隐藏 API 移至 denylist，或从所有受限列表中省略它。
  • 可以 如果隐藏 API 在 AOSP 中尚不存在，则将隐藏 API 添加到任何受限列表。

Android 15 的新增要求开始

3.1.1. Android 扩展程序

Android 支持通过更新特定 API 级别的扩展程序版本来扩展该 API 级别的受管理 API 表面。android.os.ext.SdkExtensions.getExtensionVersion(int apiLevel) API 会返回所提供 apiLevel 的扩展程序版本（如果该 API 级别有扩展程序）。

Android 设备实现方案

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

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

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

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，其形式为 intent、权限以及 Android 应用的类似方面，这些方面无法在应用编译时强制执行。

3.2.1. 权限

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

3.2.2. 构建参数

Android API 在 android.os.Build 类中包含许多常量，旨在描述当前设备。

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

参数	详情
VERSION.RELEASE	当前正在执行的 Android 系统的版本，采用人类可读的格式。此字段必须具有 Android 15 的允许版本字符串中定义的字符串值之一。
VERSION.SDK	当前正在执行的 Android 系统的版本，采用第三方应用程序代码可访问的格式。 对于 Android 15，此字段必须具有整数值 15_INT。
VERSION.SDK_INT	当前正在执行的 Android 系统的版本，采用第三方应用程序代码可访问的格式。 对于 Android 15，此字段必须具有整数值 15_INT。
VERSION.INCREMENTAL	设备实现者选择的值，用于指定当前正在执行的 Android 系统的特定版本，采用人类可读的格式。 此值不得重复用于提供给最终用户的不同版本。 此字段的典型用途是指示用于生成版本的构建号或源代码控制更改标识符。 此字段的值必须编码为可打印的 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	唯一标识此版本的字符串。 它应该是相当人类可读的。 它必须遵循此模板 $(BRAND)/$(PRODUCT)/     $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) 例如 acme/myproduct/     mydevice:15/LMYXX/3359:userdebug/test-keys 指纹不得包含空格字符。 此字段的值必须编码为 7 位 ASCII 字符。
HARDWARE	硬件的名称（来自内核命令行或 /proc）。 它应该是相当人类可读的。 此字段的值必须编码为 7 位 ASCII 字符，并与正则表达式 ^[a-zA-Z0-9_-]+$ 匹配。
HOST	唯一标识构建所在的主机的字符串，采用人类可读的格式。 对此字段的特定格式没有要求，但它不得为 null 或空字符串 ("")。
ID	设备实现者选择的标识符，用于指代特定版本，采用人类可读的格式。 此字段可以与 android.os.Build.VERSION.INCREMENTAL 相同，但应是一个对最终用户而言足够有意义的值，以区分软件版本。 此字段的值必须编码为 7 位 ASCII 字符，并与正则表达式 ^[a-zA-Z0-9._-]+$ 匹配。
MANUFACTURER	产品的原始设备制造商 (OEM) 的商品名称。 对此字段的特定格式没有要求，但它不得为 null 或空字符串 ("")。 此字段在产品生命周期内不得更改。
SOC_MANUFACTURER	产品中使用的主要片上系统 (SOC) 的制造商的商品名称。 具有相同 SOC 制造商的设备应使用相同的常量值。 请向 SOC 制造商询问要使用的正确常量。 此字段的值必须编码为 7 位 ASCII 字符，必须与正则表达式 ^([0-9A-Za-z ]+) 匹配，不得以空格开头或结尾，且不得等于 “unknown”。 此字段在产品生命周期内不得更改。
SOC_MODEL	产品中使用的主要片上系统 (SOC) 的型号名称。 具有相同 SOC 型号的设备应使用相同的常量值。 请向 SOC 制造商询问要使用的正确常量。 此字段的值必须编码为 7 位 ASCII 字符，并与正则表达式 ^([0-9A-Za-z ._/+-]+)$ 匹配，不得以空格开头或结尾，且不得等于 “unknown”。 此字段在产品生命周期内不得更改。
MODEL	设备实现者选择的值，包含最终用户所知的设备名称。 这应该是设备销售给最终用户时使用的名称。 对此字段的特定格式没有要求，但它不得为 null 或空字符串 ("")。 此字段在产品生命周期内不得更改。
PRODUCT	设备实现者选择的值，包含特定产品 (SKU) 的开发名称或代码名称，该名称在同一品牌内必须是唯一的。 必须是人类可读的，但不一定旨在供最终用户查看。 此字段的值必须编码为 7 位 ASCII 字符，并与正则表达式 ^[a-zA-Z0-9_-]+$ 匹配。 此产品名称在产品生命周期内不得更改。
ODM_SKU	设备实现者选择的可选值，其中包含用于跟踪设备特定配置的 SKU（库存单位），例如，销售时设备随附的任何外围设备。 此字段的值必须编码为 7 位 ASCII 字符，并与正则表达式 ^([0-9A-Za-z.,_-]+)$ 匹配。
SERIAL	必须返回 “UNKNOWN”。
TAGS	设备实现者选择的以逗号分隔的标记列表，用于进一步区分版本。 这些标记必须编码为 7 位 ASCII 字符，并与正则表达式 ^[a-zA-Z0-9._-]+ 匹配，并且必须具有与三个典型的 Android 平台签名配置之一对应的值：release-keys、dev-keys 和 test-keys。
TIME	表示构建发生时间的时间戳的值。
TYPE	设备实现者选择的值，用于指定构建的运行时配置。 此字段必须具有与三个典型的 Android 运行时配置之一对应的值：user、userdebug 或 eng。
USER	生成构建的用户（或自动化用户）的名称或用户 ID。 对此字段的特定格式没有要求，但它不得为 null 或空字符串 ("")。
SECURITY_PATCH	指示构建的安全补丁级别的数值。 它必须表示构建在任何方面都不容易受到指定的 Android 公共安全公告中描述的任何问题的影响。 它必须采用 [YYYY-MM-DD] 格式，与 Android 公共安全公告或 Android 安全公告中记录的已定义字符串匹配，例如 “2015-11-01”。
BASE_OS	表示 FINGERPRINT 参数的值，该构建与其他方面与此构建相同，但 Android 公共安全公告中提供的补丁除外。 它必须报告正确的值，如果不存在此类构建，则报告空字符串 ("")。
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 过滤器模式，并提供满足，即满足 SDK 中描述的这些常用应用程序 Intent 的开发者期望。

有关每种设备类型的强制性应用程序 Intent，请参阅第 2 节。

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。 例如，指定数据 URI “http://www.android.com” 的 Intent 过滤器模式比浏览器用于 “http://” 的核心 Intent 模式更具体。

Android 还包括一种机制，供第三方应用程序为某些类型的 Web URI Intent 声明权威默认 应用链接行为。 当此类权威声明在应用程序的 Intent 过滤器模式中定义时，设备实现

• [C-0-4] 必须尝试通过执行上游 Android 开源项目中的软件包管理器实现的 数字资产链接规范中定义的验证步骤来验证任何 Intent 过滤器。
• [C-0-5] 必须在安装应用程序期间尝试验证 Intent 过滤器，并将所有成功验证的 URI Intent 过滤器设置为其 URI 的默认应用程序处理程序。
• 如果特定的 URI 过滤器已成功验证，但其他候选 URI 过滤器验证失败，则可以设置特定的 URI Intent 过滤器作为其 URI 的默认应用程序处理程序。 如果设备实现执行此操作，则必须在设置菜单中为用户提供适当的按 URI 模式覆盖。
• 必须在设置中为用户提供每个应用程序的应用链接控件，如下所示
  • [C-0-6] 用户必须能够整体覆盖应用程序的默认应用链接行为，使其为：始终打开、始终询问或永不打开，这必须同等地应用于所有候选 URI Intent 过滤器。
  • [C-0-7] 用户必须能够查看候选 URI Intent 过滤器的列表。
  • 设备实现可以为用户提供按 Intent 过滤器覆盖特定成功验证的候选 URI Intent 过滤器的能力。
  • [C-0-8] 如果设备实现允许某些候选 URI Intent 过滤器成功验证，而其他一些候选 URI Intent 过滤器可能验证失败，则设备实现必须为用户提供查看和覆盖特定候选 URI Intent 过滤器的能力。

3.2.3.3. Intent 命名空间

• [C-0-1] 设备实现不得包含任何 Android 组件，该组件使用 android.* 或 com.android.* 命名空间中的 ACTION、CATEGORY 或其他键字符串来处理任何新的 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] 必须根据 SDK 文档中的描述，在响应适当的系统事件时，广播此处列出的公共广播 Intent。 请注意，此要求与第 3.5 节不冲突，因为 SDK 文档中也描述了后台应用程序的限制。 此外，某些广播 Intent 取决于硬件支持，如果设备支持必要的硬件，它们必须广播 Intent 并提供与 SDK 文档一致的行为。

3.2.3.5. 条件应用程序 Intent

Android 包含一些设置，这些设置使用户可以轻松选择其默认应用程序，例如用于主屏幕或短信的应用程序。

在有意义的情况下，设备实现必须提供类似的设置菜单，并且与 SDK 文档中描述的 Intent 过滤器模式和 API 方法兼容，如下所示。

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

• [C-1-1] 必须遵循 android.settings.HOME_SETTINGS Intent，以显示主屏幕的默认应用程序设置菜单。

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

• [C-2-1] 必须提供一个设置菜单，该菜单将调用 android.provider.Telephony.ACTION_CHANGE_DEFAULT Intent，以显示一个对话框来更改默认短信应用程序。

• [C-2-2] 必须遵循 android.telecom.action.CHANGE_DEFAULT_DIALER Intent，以显示一个对话框，允许用户更改默认电话应用程序。

  • 必须对来电和去电使用用户选择的默认电话应用程序的 UI，但紧急呼叫除外，紧急呼叫将使用预装的电话应用程序。

• [C-2-3] 必须遵循 android.telecom.action.CHANGE_PHONE_ACCOUNTS Intent，以提供用户操作来配置与 PhoneAccounts 关联的 ConnectionServices，以及电信服务提供商将用于拨打外拨电话的默认 PhoneAccount。 AOSP 实现通过在 “通话” 设置菜单中包含 “通话帐户选项” 菜单来满足此要求。

• [C-2-4] 必须允许应用程序使用 android.telecom.CallRedirectionService，该应用程序持有 android.app.role.CALL_REDIRECTION 角色。

• [C-2-5] 必须为用户提供操作来选择一个持有 android.app.role.CALL_REDIRECTION 角色的应用程序。

• [C-2-6] 必须遵循 android.intent.action.SENDTO 和 android.intent.action.VIEW Intent，并提供一个 Activity 来发送/显示短信消息。

• [C-SR-1] 强烈建议使用预加载的拨号器应用程序来遵循 android.intent.action.ANSWER、android.intent.action.CALL、android.intent.action.CALL_BUTTON、android.intent.action.VIEW 和 android.intent.action.DIAL Intent，该应用程序可以处理这些 Intent 并提供 SDK 中描述的满足。

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

• [C-3-1] 必须遵循 android.settings.NFC_PAYMENT_SETTINGS Intent，以显示非接触式支付的默认应用程序设置菜单。
• [C-3-2] 必须遵循 android.nfc.cardemulation.action.ACTION_CHANGE_DEFAULT Intent，以显示一个 Activity，该 Activity 打开一个对话框，要求用户更改 SDK 中描述的特定类别的默认卡模拟服务。

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

• [C-4-1] 必须遵循这些 Intent：android.nfc.action.NDEF_DISCOVERED、android.nfc.action.TAG_DISCOVERED 和 android.nfc.action.TECH_DISCOVERED，以显示一个 Activity，该 Activity 满足开发者对 SDK 中描述的这些 Intent 的期望。

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

• [C-5-1] 必须遵循 'android.bluetooth.adapter.action.REQUEST_ENABLE' Intent，并显示一个系统 Activity，以允许用户打开蓝牙。
• [C-5-2] 必须遵循 'android.bluetooth.adapter.action.REQUEST_DISCOVERABLE' Intent，并显示一个请求可发现模式的系统 Activity。

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

• [C-6-1] 必须实现一个 Activity，该 Activity 将响应 Intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS，对于具有 UI_MODE_TYPE_NORMAL 的实现，它必须是一个用户可以在其中授予或拒绝应用程序访问 DND 策略配置的 Activity。

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

• [C-7-1] 必须提供用户可访问的机制，以响应 android.settings.INPUT_METHOD_SETTINGS Intent，添加和配置第三方输入法。

如果设备实现支持第三方辅助功能服务，则它们

• [C-8-1] 必须遵循 android.settings.ACCESSIBILITY_SETTINGS Intent，以提供用户可访问的机制，以便在预加载的辅助功能服务旁边启用和禁用第三方辅助功能服务。

如果设备实现包含对 Wi-Fi Easy Connect 的支持并将功能公开给第三方应用程序，则它们

• [C-9-1] 必须实现 SDK 文档中描述的 Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI Intent API。

如果设备实现提供数据保护程序模式，则它们

• [C-10-1] 必须在设置中提供一个用户界面，该用户界面处理 Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS Intent，允许用户将应用程序添加到允许列表或从允许列表中删除应用程序。

如果设备实现不提供数据保护程序模式，则它们

• [C-11-1] 必须有一个 Activity 来处理 Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS Intent，但可以将其实现为无操作。

如果设备实现通过 android.hardware.camera.any 报告对相机的支持，则它们

• [C-12-3] 必须处理并且必须仅允许预装的 Android 应用程序处理以下 Intent：MediaStore.ACTION_IMAGE_CAPTURE、MediaStore.ACTION_IMAGE_CAPTURE_SECURE 和 MediaStore.ACTION_VIDEO_CAPTURE，如 SDK 文档中所述。

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

• [C-13-1] 必须遵循 Intent android.app.action.ADD_DEVICE_ADMIN，以调用 UI 来引导用户将设备管理员添加到系统（或允许他们拒绝）。

• [C-13-2] 必须遵循 Intent android.app.action.PROVISION_MANAGED_PROFILE、android.app.action.SET_NEW_PARENT_PROFILE_PASSWORD、android.app.action.SET_NEW_PASSWORD 和 android.app.action.START_ENCRYPTION，并具有一个 Activity 来为 此处 SDK 中描述的这些 Intent 提供满足。

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

• [C-14-1] 必须完全实现 AutofillService 和 AutofillManager API，并遵循 android.settings.REQUEST_SET_AUTOFILL_SERVICE Intent，以显示一个默认应用程序设置菜单，用于启用和禁用自动填充，并更改用户的默认自动填充服务。

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

• [C-SR-2] 强烈建议提供用户可访问的机制，以响应 android.settings.ACTION_USAGE_ACCESS_SETTINGS Intent，为声明 android.permission.PACKAGE_USAGE_STATS 权限的应用程序授予或撤销对使用情况统计信息的访问权限。

如果设备实现打算禁止任何应用程序（包括预装的应用程序）访问使用情况统计信息，则它们

• [C-15-1] 必须仍然有一个 Activity 来处理 android.settings.ACTION_USAGE_ACCESS_SETTINGS Intent 模式，但必须将其实现为无操作，即具有与用户拒绝访问时相同的行为。

如果设备实现在设置中显示 AutofillService_passwordsActivity 指定的 Activity 的链接，或者通过类似机制显示用户密码的链接，则它们

• [C-16-1] 必须为所有已安装的自动填充服务显示此类链接。

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

• [C-18-1] 必须遵循 android.settings.ACTION_VOICE_INPUT_SETTINGS Intent，以显示语音输入和辅助功能的默认应用程序设置菜单。

如果设备实现报告功能 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 来为 此处 SDK 中描述的这些 Intent 提供满足。

Android 包括对交互式屏幕保护程序（以前称为 Dreams）的支持。 当连接到电源的设备处于空闲状态或停靠在桌面扩展坞中时，屏幕保护程序允许用户与应用程序交互。 设备实现

• 应包括对屏幕保护程序的支持，并提供一个设置选项，供用户响应 android.settings.DREAM_SETTINGS Intent 来配置屏幕保护程序。

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

• [C-19-1] 必须实现 NfcAdapter.ACTION_TRANSACTION_DETECTED Intent API（如 GSM 协会技术规范 TS.26 - NFC 手机要求定义的 “EVT_TRANSACTION”）。

3.2.4. 二级/多显示器上的 Activity

如果设备实现允许在多个显示器上启动正常的 Android Activity，则它们

• [C-1-1] 必须设置 android.software.activities_on_secondary_displays 功能标志。
• [C-1-2] 必须保证 API 兼容性，类似于在主显示器上运行的 Activity。
• [C-1-3] 当启动新 Activity 时未通过 ActivityOptions.setLaunchDisplayId() API 指定目标显示器时，必须将新 Activity 放置在与启动它的 Activity 相同的显示器上。
• [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 才能启动到该显示器。 每个人都可以启动到具有 android.view.Display.FLAG_PUBLIC 标志的显示器。

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 列表，从最优先到最不优先排序。

Android 15 的新增要求开始

• [C-0-7] 必须使所有以下库（提供本机 API）可供包含本机代码的应用程序使用

  • libaaudio.so (AAudio 本机音频支持)
  • libamidi.so (本机 MIDI 支持，如果声明了 android.software.midi 功能，如第 5.9 节中所述)
  • libandroid.so (本机 Android Activity 支持)
  • libc (C 库)
  • libcamera2ndk.so
  • libdl (动态链接器)
  • libEGL.so (本机 OpenGL 表面管理)
  • 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 (神经网络 API)
  • libOpenMAXAL.so (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] 不得向以 API 级别 24 或更高版本为目标的第三方应用程序公开任何其他本机库（在 AOSP 中实现并作为系统库提供），因为它们是保留的。

• [C-0-11] 必须通过 libGLESv3.so 库导出所有 OpenGL ES 3.1 和 Android 扩展包函数符号，如 NDK 中定义的那样。 请注意，虽然所有符号都必须存在，但第 7.1.4.1 节更详细地描述了何时需要每个相应函数的完整实现的要求。

• [C-0-12] 必须通过 libvulkan.so 库导出核心 Vulkan 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 开源项目的 Android 15 分支的 Chromium 项目构建，以实现 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 的应用程序不同的进程中渲染提供的内容或远程 URL 内容。具体而言，单独的渲染器进程必须持有较低的特权，以单独的用户 ID 运行，无权访问应用程序的数据目录，没有直接网络访问权限，并且只能通过 Binder 访问最低限度所需的系统服务。 AOSP 的 WebView 实现满足此要求。

请注意，如果设备实现是 32 位或声明了功能标志 android.hardware.ram.low，则它们可以免除 C-1-3 的要求。

3.4.2. 浏览器兼容性

如果设备实现包含用于通用 Web 浏览的独立浏览器应用程序，则它们

• [C-1-1] 必须支持与 HTML5 关联的以下每个 API
  • 应用程序缓存/离线操作
  • <video> 标签
  • 地理位置
• [C-1-2] 必须支持 HTML5/W3C webstorage API，并且应支持 HTML5/W3C IndexedDB API。请注意，由于 Web 开发标准机构正在过渡到偏向 IndexedDB 而不是 webstorage，因此 IndexedDB 预计将在未来版本的 Android 中成为必需的组件。
• 可以在独立浏览器应用程序中附带自定义用户代理字符串。
• 应在独立浏览器应用程序上尽可能多地实现对 HTML5 的支持（无论是基于上游 WebKit 浏览器应用程序还是第三方替代品）。

但是，如果设备实现不包含独立的浏览器应用程序，则它们

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

3.5. API 行为兼容性

设备实现

• [C-0-9] 必须确保 API 行为兼容性应用于所有已安装的应用程序，除非它们受到 第 3.5.1 节中所述的限制。
• [C-0-10] 不得实施仅为设备实现者选择的应用程序确保 API 行为兼容性的允许列表方法。

每种 API 类型（托管、软、原生和 Web）的行为都必须与上游 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] 设备必须返回以下安全提供程序，作为来自 Security.getProviders() 方法的前七个数组值，按照给定的顺序和给定的名称（由 Provider.getName() 返回）和类，除非应用程序已通过 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 的显式用户交互或任何可能导致应用程序离开强制停止状态的操作定义，包括服务绑定、内容提供程序绑定、显式广播等，这些操作将通过新的 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。“公开的元素”是指任何未使用上游 Android 源代码中使用的“@hide”标记修饰的构造。

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

• [C-0-3] 不得影响任何公开 API 的声明行为和 Java 语言签名。
• [C-0-4] 不得向开发者宣传或以其他方式公开。

但是，设备实现者可以在标准 Android 命名空间之外添加自定义 API，但自定义 API

• [C-0-5] 不得位于其他组织拥有或引用的命名空间中。例如，设备实现者不得将 API 添加到 com.google.* 或类似的命名空间：只有 Google 可以这样做。同样，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 Executable (DEX) 格式和 Dalvik 字节码规范和语义。

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

• 应使用 Android RunTime (ART)，即 Dalvik Executable Format 的参考上游实现，以及参考实现的包管理系统。

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

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

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

3.8. 用户界面兼容性

3.8.1. 启动器（主屏幕）

Android 包括一个启动器应用程序（主屏幕），并支持第三方应用程序替换设备启动器（主屏幕）。

如果设备实现允许第三方应用程序替换设备主屏幕，则它们

• [C-1-1] 必须声明平台功能 android.software.home_screen。
• [C-1-2] 当第三方应用程序使用 <adaptive-icon> 标签提供其图标，并且调用 PackageManager 方法检索图标时，必须返回 AdaptiveIconDrawable 对象。

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

• [C-2-1] 对于 ShortcutManager.isRequestPinShortcutSupported()，必须报告 true。
• [C-2-2] 在通过 ShortcutManager.requestPinShortcut() API 方法添加应用程序请求的快捷方式之前，必须具有用户界面询问用户。
• [C-2-3] 必须支持固定快捷方式以及动态和静态快捷方式，如 应用快捷方式页面中所述。

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

• [C-3-1] 对于 ShortcutManager.isRequestPinShortcutSupported()，必须报告 false。

如果设备实现实现了默认启动器，该启动器通过 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. 小部件

Android 通过定义组件类型以及相应的 API 和生命周期来支持第三方应用程序小部件，这允许应用程序向最终用户公开 “AppWidget”。

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

• [C-1-1] 必须声明对平台功能 android.software.app_widgets 的支持。
• [C-1-2] 必须包含对 AppWidget 的内置支持，并公开用户界面功能以添加、配置、查看和删除 AppWidget
• [C-1-3] 必须能够渲染标准网格尺寸中为 4 x 4 的小部件。有关详细信息，请参阅 Android SDK 文档中的 App Widget 设计指南。
• 可以支持锁定屏幕上的应用程序小部件。

如果设备实现支持第三方应用程序小部件和应用内固定快捷方式，则它们

• [C-2-1] 对于 AppWidgetManager.html.isRequestPinAppWidgetSupported()，必须报告 true。
• [C-2-2] 在通过 AppWidgetManager.requestPinAppWidget() API 方法添加应用程序请求的快捷方式之前，必须具有用户界面询问用户。

3.8.3. 通知

Android 包含 Notification 和 NotificationManager API，这些 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 以及通知文本提供的所有资源（图像、贴纸、图标等），而无需额外的用户交互。例如，必须显示通过 android.app.Person 在通过 setGroupConversation 设置的群组对话中提供的所有资源，包括图标。

• [C-SR-1] 强烈建议为用户提供一种功能，以控制暴露给已被授予通知侦听器权限的应用程序的通知。粒度必须达到用户可以为每个此类通知侦听器控制桥接到此侦听器的通知类型。类型必须包括“对话”、“警报”、“静默”和“重要进行中”通知。

• [C-SR-2] 强烈建议为用户提供一种功能，以指定要从通知任何特定通知侦听器中排除的应用程序。

• [C-SR-3] 强烈建议在用户多次关闭某个第三方应用程序的通知后，自动显示用户界面，以阻止该应用程序的每个渠道和应用程序包级别的通知。

• 应支持富通知。

• 应将一些更高优先级的通知呈现为浮动通知。

• 应具有用户界面来暂停通知。

• 可以仅管理第三方应用程序何时可以通知用户值得注意的事件的可见性和时间，以减轻驾驶员分心等安全问题。

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

设备实现

• [C-SR-4] 强烈建议将 对话通知 分组并显示在非对话通知之前，但正在进行的前台服务通知和 importance:high 通知除外。

如果设备实现支持 对话通知，并且应用程序为 气泡 提供了所需的数据，则它们

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

如果设备实现支持富通知，则它们

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

浮动通知是指在用户进入时独立于用户所在表面呈现给用户的通知。如果设备实现支持浮动通知，则它们

• [C-3-1] 呈现Heads-up通知时，必须按照 Notification.Builder API 类中的描述使用Heads-up通知视图和资源。
• [C-3-2] 必须将通过 Notification.Builder.addAction() 提供的操作与通知内容一同显示，无需额外的用户交互，如 SDK 中所述。

3.8.3.2. 通知侦听器服务

Android 包含 NotificationListenerService API，允许应用（在用户明确启用后）接收所有已发布或更新的通知副本。

设备实现

• [C-0-1] 必须正确且及时地将通知完整地更新到所有此类已安装且用户已启用的侦听器服务，包括附加到Notification对象的所有元数据。
• [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 设置菜单中视觉效果已受到抑制。

Android 15 的新增要求开始

3.8.3.4. 敏感通知保护

3.8.4. 辅助 API

Android 包含辅助 API，允许应用程序选择与设备上的助手共享当前上下文的多少信息。

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

• [C-2-1] 必须通过以下任一方式，清楚地向最终用户指示何时共享上下文：
  • 每次辅助应用访问上下文时，屏幕边缘周围都会显示白光，其持续时间和亮度达到或超过 Android 开源项目实现的水平。
  • 对于预安装的辅助应用，提供一个用户功能，该功能距离默认语音输入和助手应用设置菜单不到两次导航，并且仅在用户通过热词或辅助导航键输入显式调用辅助应用时才共享上下文。
• [C-2-2] 如第 7.2.3 节中所述，用于启动辅助应用的指定交互必须启动用户选择的辅助应用，换句话说，即实现 VoiceInteractionService 的应用，或处理 ACTION_ASSIST intent 的活动。

3.8.5. 提醒和Toast

应用程序可以使用 Toast API 向最终用户显示短暂的非模态字符串，这些字符串会在短暂的时间后消失；并使用 TYPE_APPLICATION_OVERLAY 窗口类型 API 将警报窗口显示为覆盖在其他应用之上。

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

• [C-1-1] 必须提供用户功能，以阻止应用显示使用 TYPE_APPLICATION_OVERLAY 的警报窗口。AOSP 实现通过在通知栏中设置控件来满足此要求。

• [C-1-2] 必须遵守 Toast API，并以某种高度可见的方式向最终用户显示来自应用程序的 Toast。

3.8.6. 主题

Android 提供“主题”作为一种机制，供应用程序在整个Activity或应用程序中应用样式。

Android 包括“Holo”和“Material”主题系列，作为一组定义的样式，供应用程序开发人员在想要匹配由 Android SDK 定义的 Holo 主题外观和风格时使用。

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

• [C-1-1] 不得更改向应用程序公开的任何 Holo 主题属性。
• [C-1-2] 必须支持“Material”主题系列，并且不得更改向应用程序公开的任何 Material 主题属性或其资源。

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

• [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] 必须具有 5 或更大的 CAM16 色度值。

  • 应该通过 com.android.systemui.monet.ColorScheme#getSeedColors 从壁纸派生，这提供了多个有效的源颜色可供选择。

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

Android 还包括“设备默认”主题系列，作为一组定义的样式，供应用程序开发人员在想要匹配设备实现者定义的设备主题外观和风格时使用。

• 设备实现可以修改向应用程序公开的 设备默认主题属性。

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. 活动切换

上游 Android 源代码包含概览屏幕，这是一个系统级别的用户界面，用于任务切换，并使用应用程序上次离开应用程序时图形状态的缩略图图像显示最近访问的活动和任务。

包括第 7.2.3 节中详细描述的“最近使用”功能导航键的设备实现可以更改界面。

如果包括第 7.2.3 节中详细描述的“最近使用”功能导航键的设备实现更改了界面，则它们

• [C-1-1] 必须支持至少显示 7 个活动。
• 应该至少一次显示 4 个活动的标题。
• 应该在“最近使用”中显示高亮颜色、图标、屏幕标题。
• 应该显示关闭功能按钮（“x”），但可以延迟到用户与屏幕交互时才显示。
• 应该实现一个快捷方式，以便轻松切换到上一个活动。
• 当双击“最近使用”功能键时，应该触发最近使用的两个应用之间的快速切换操作。
• 如果支持分屏多窗口模式，则当长按“最近使用”功能键时，应该触发分屏多窗口模式。
• 可以将关联的“最近使用”显示为一起移动的组。
• [C-SR-1] 强烈建议对概览屏幕使用上游 Android 用户界面（或类似的基于缩略图的界面）。

3.8.9. 输入管理

Android 包括对输入管理的支持，并支持第三方输入法编辑器。

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

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

3.8.10. 锁屏媒体控件

Remote Control Client API 已从 Android 5.0 中弃用，取而代之的是媒体通知模板，该模板允许媒体应用程序与锁屏上显示的播放控件集成。

3.8.11. 屏幕保护程序（以前称为Dreams）

有关配置屏幕保护程序的设置 intent，请参阅第 3.2.3.5 节。

3.8.12. 位置信息

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

• [C-1-2] 必须在“设置”中的“位置信息”菜单中显示位置信息的当前状态。
• [C-1-3] 不得在“设置”中的“位置信息”菜单中显示位置信息模式。

3.8.13. Unicode 和字体

Android 包括对 Unicode 10.0 中定义的 emoji 表情符号字符的支持。

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

• [C-1-1] 必须能够以彩色字形渲染这些 emoji 表情符号字符。
• [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。（可以添加新的 emoji 字体来覆盖 NotoColorEmoji.tff 中的 emoji）
• 应该支持 Unicode 技术报告 #51 中指定的肤色和多元家庭 emoji 表情符号。

如果设备实现包含 IME，则它们

• 应该为用户提供输入这些 emoji 表情符号字符的输入法。

Android 包括对渲染缅甸语字体的支持。缅甸语有几种不符合 Unicode 标准的字体，俗称“Zawgyi”，用于渲染缅甸语。

如果设备实现包括对缅甸语的支持，则它们

• [C-2-1] 必须默认使用符合 Unicode 标准的字体渲染文本；除非用户在语言选择器中选择，否则不得将不符合 Unicode 标准的字体设置为默认字体。
• [C-2-2] 如果设备支持不符合 Unicode 标准的字体，则必须支持 Unicode 字体和不符合 Unicode 标准的字体。不符合 Unicode 标准的字体不得删除或覆盖 Unicode 字体。
• [C-2-3] 必须仅在指定了带有 script 代码 Qaag 的语言代码（例如 my-Qaag）时，才使用不符合 Unicode 标准的字体渲染文本。不得使用任何其他 ISO 语言或地区代码（无论是已分配、未分配还是保留）来指代缅甸语的不符合 Unicode 标准的字体。应用开发人员和网页作者可以像指定任何其他语言一样指定 my-Qaag 作为指定的语言代码。

3.8.14. 多窗口

如果设备实现具有同时显示多个活动的功能，则它们

• [C-1-1] 必须根据 Android SDK 多窗口模式支持文档中描述的应用程序行为和 API 来实现此类多窗口模式，并满足以下要求：
• [C-1-2] 必须遵守应用在 AndroidManifest.xml 文件中设置的 android:resizeableActivity，如此 SDK 中所述。
• [C-1-3] 如果屏幕高度小于 440 dp 且屏幕宽度小于 440 dp，则不得提供分屏或自由窗口模式。
• [C-1-4] 在图片画中画huà zhōng huà以外的多窗口模式下，活动不得调整大小至小于 220dp 的尺寸。
• 屏幕尺寸为 xlarge 的设备实现应该支持自由窗口模式。

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

• [C-2-2] 如果启动器应用是焦点窗口，则必须裁剪分屏多窗口的停靠活动，但应该显示其部分内容。
• [C-2-3] 必须遵守第三方启动器应用程序声明的 AndroidManifestLayout_minWidth 和 AndroidManifestLayout_minHeight 值，并且在显示停靠活动的部分内容的过程中，不得覆盖这些值。

如果设备实现支持多窗口模式和图片画中画huà zhōng huà多窗口模式，则它们

• [C-3-1] 当应用属于以下情况时，必须在图片画中画huà zhōng huà多窗口模式下启动活动：* 目标 API 级别为 26 或更高版本，并声明 android:supportsPictureInPicture * 目标 API 级别为 25 或更低版本，并同时声明 android:resizeableActivity 和 android:supportsPictureInPicture。
• [C-3-2] 必须通过 setActions() API 公开其 SystemUI 中的操作，这些操作由当前 PIP 活动指定。
• [C-3-3] 必须支持纵横比大于或等于 1:2.39 且小于或等于 2.39:1 的纵横比，如 PIP 活动通过 setAspectRatio() API 指定的那样。
• [C-3-4] 必须使用 KeyEvent.KEYCODE_WINDOW 来控制 PIP 窗口；如果未实现 PIP 模式，则该键必须可用于前台活动。
• [C-3-5] 必须提供用户功能，以阻止应用在 PIP 模式下显示；AOSP 实现通过在通知栏中设置控件来满足此要求。

• [C-3-6] 当应用程序未声明任何 AndroidManifestLayout_minWidth 和 AndroidManifestLayout_minHeight 值时，必须为 PIP 窗口分配以下最小宽度和高度：

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

Android 15 的新增要求开始

3.8.15. 显示屏开孔kāikǒng

Android 支持 SDK 文档中描述的显示屏开孔kāikǒng。DisplayCutout API 定义了显示屏边缘上的一个区域，由于显示屏开孔kāikǒng或边缘上的曲面显示屏，该区域可能无法用于应用程序。

如果设备实现包含显示屏开孔kāikǒng，则它们

• [C-1-5] 如果设备的纵横比为 1.0(1:1)，则不得有开孔kāikǒng。
• [C-1-2] 每个边缘不得有多个开孔kāikǒng。
• [C-1-3] 必须遵守应用通过 WindowManager.LayoutParams API 设置的显示屏开孔kāikǒng标志，如 SDK 中所述。
• [C-1-4] 必须报告 DisplayCutout API 中定义的所有开孔kāikǒng指标的正确值。

3.8.16. 设备控件

Android 包括 ControlsProviderService 和 Control API，允许第三方应用程序发布设备控件，以便用户快速查看状态和执行操作。

有关设备特定的要求，请参阅第 2_2_3 节。

3.8.17. 剪贴板

设备实现

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

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

• [C-1-1] 必须编辑用户可见的预览

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

3.9. 设备管理

Android 15 的新增要求开始

3.9.1. 设备配置

3.9.1.1. 设备所有者配置

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

• [C-1-1] 必须支持将设备策略控制器 (DPC) 注册为设备所有者应用，如下所述：
  • 当设备实现既没有用户也没有配置用户数据时，它
    • [C-1-5] 如果设备通过功能标志 android.hardware.nfc 声明支持近场通信 (NFC) 并收到包含 MIME 类型为 MIME_TYPE_PROVISIONING_NFC 的记录的 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 应用程序注册为设备所有者应用。

Android 15 的新增要求开始

3.9.1.2. 受管理个人资料配置

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

• [C-1-1] 必须实现 API，允许设备策略控制器 (DPC) 应用程序成为新的受管理个人资料的所有者。

Android 15 的新增要求开始

• [C-1-3] 必须在“设置”中提供以下用户功能，以向用户指示设备策略控制器 (DPC) 何时禁用了特定的系统功能：

  • 一致的图标或其他用户功能（例如，上游 AOSP 信息图标），以表示特定设置何时受到设备管理员的限制。
  • 一条简短的说明消息，由设备管理员通过 setShortSupportMessage 提供。
  • DPC 应用程序的图标。

• [C-1-4] 如果在由 android.app.action.PROVISION_MANAGED_PROFILE intent 启动配置且 DPC 已实现处理程序时，建立了个人资料所有者，则必须在工作个人资料中启动 ACTION_PROVISIONING_SUCCESSFUL intent 的处理程序。

• [C-1-5] 当配置由 android.app.action.PROVISION_MANAGED_PROFILE intent 启动时，必须向工作个人资料 DPC 发送 ACTION_PROFILE_PROVISIONING_COMPLETE 广播。

• [C-1-6] 必须在触发个人资料所有者配置后发送 ACTION_GET_PROVISIONING_MODE intent，以便 DPC 应用可以选择是成为设备所有者还是个人资料所有者，除非配置是由 android.app.action.PROVISION_MANAGED_PROFILE intent 触发的。

• [C-1-7] 如果在配置期间建立了个人资料所有者，无论使用哪种配置方法，都必须向工作个人资料发送 ACTION_ADMIN_POLICY_COMPLIANCE intent，除非配置是由 android.app.action.PROVISION_MANAGED_PROFILE intent 触发的。在个人资料所有者应用完成之前，用户不得在设置向导中继续操作。

• [C-1-8] 无论使用哪种配置方法，当建立个人资料所有者时，都必须向个人个人资料 DPC 发送 ACTION_MANAGED_PROFILE_PROVISIONED 广播。

3.9.2. 受管理个人资料支持

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

• [C-1-1] 必须通过 android.app.admin.DevicePolicyManager API 支持受管理个人资料。
• [C-1-2] 必须允许创建且仅允许创建一个受管理个人资料。
• [C-1-3] 必须使用图标标记（类似于上游 AOSP 工作标记）来表示受管理的应用程序和小部件以及其他带有标记的 UI 元素，如“最近使用”和“通知”。
• [C-1-4] 必须显示通知图标（类似于上游 AOSP 工作标记），以指示用户何时在受管理个人资料应用程序中。
• [C-1-5] 如果设备唤醒 (ACTION_USER_PRESENT) 且前台应用程序在受管理个人资料中，则必须显示 toast，指示用户在受管理个人资料中。
• [C-1-6] 如果存在受管理个人资料，则必须在 Intent“选择器”中显示可视功能，以允许用户在设备策略控制器启用时，将 intent 从受管理个人资料转发到主用户，或反之亦然。
• [C-1-7] 如果存在受管理个人资料，则必须为主用户和受管理个人资料公开以下用户功能：
  • 分别核算主用户和受管理个人资料的电池、位置信息、移动数据和存储空间使用情况。
  • 独立管理主用户或受管理个人资料中安装的 VPN 应用程序。
  • 独立管理主用户或受管理个人资料中安装的应用程序。
  • 独立管理主用户或受管理个人资料中的帐户。
• [C-1-8] 必须确保预装的拨号器、联系人和消息应用程序可以从受管理的用户资料（如果存在）以及主要用户资料中搜索和查找来电者信息，如果设备策略控制器允许这样做。
• [C-1-9] 必须确保其满足针对启用多用户的设备的所有安全要求（参见第 9.5 节），即使受管理的用户资料不被视为主要用户之外的另一个用户。
• [C-1-10] 必须确保当使用具有topActivity窗口（该窗口具有焦点，即用户在所有活动中最后与之交互的窗口）且属于工作用户资料应用的窗口捕获屏幕截图时，屏幕截图数据保存在工作用户资料存储空间中。
• [C-1-11] *当将屏幕截图保存到工作用户资料时*，除工作用户资料应用程序的窗口外，不得捕获任何其他屏幕内容（系统栏、通知或任何个人用户资料内容）（以确保个人用户资料数据不会保存在工作用户资料中）。

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

• [C-2-1] 必须支持指定一个单独的锁屏，以满足以下要求，从而仅授予对在受管理的用户资料中运行的应用的访问权限。
  • 设备实现必须遵守 DevicePolicyManager.ACTION_SET_NEW_PASSWORD intent，并显示一个界面来为受管理的用户资料配置单独的锁屏凭据。
  • 受管理的用户资料的锁屏凭据必须使用与父用户资料相同的凭据存储和管理机制，如 Android 开源项目网站 上所述。
  • DPC 密码政策 必须仅适用于受管理的用户资料的锁屏凭据，除非在 DevicePolicyManager 实例上调用 getParentProfileInstance 返回的实例。
• 当预装的通话记录、通话中 UI、正在进行和未接来电通知、联系人和消息应用中显示来自受管理的用户资料的联系人时，它们应使用与指示受管理的用户资料应用程序相同的徽章进行标记。

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] 该应用程序必须实现一个 intent 过滤器，该过滤器解析 android.app.action.UPDATE_DEVICE_POLICY_MANAGEMENT_ROLE_HOLDER。

3.9.5. 设备策略解析框架

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

• [C-1-1] 必须按照设备策略解析框架中的文档解析设备策略冲突。

3.10. 无障碍功能

Android 提供了一个无障碍功能层，帮助残疾用户更轻松地导航他们的设备。此外，Android 还提供平台 API，使无障碍功能服务实现能够接收用户和系统事件的回调，并生成替代反馈机制，例如文本转语音、触觉反馈和轨迹球/D-pad 导航。

如果设备实现支持第三方辅助功能服务，则它们

• [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 包括 API，允许应用程序使用文本转语音 (TTS) 服务，并允许服务提供商提供 TTS 服务的实现。

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

• [C-1-1] 必须支持 Android TTS 框架 API。

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

• [C-2-1] 必须提供用户操作界面，允许用户选择一个 TTS 引擎以在系统级别使用。

Android 15 的新增要求开始

3.12. TV 输入框架

3.13. 快速设置

Android 提供了一个快速设置 UI 组件，允许快速访问常用或紧急需要的操作。

如果设备实现包含快速设置 UI 组件并支持第三方快速设置，则它们

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

3.14. 媒体 UI

如果设备实现包括非语音激活的应用程序（应用），这些应用程序通过 MediaBrowser 或 MediaSession 与第三方应用程序交互，则这些应用

• [C-1-2] 必须清晰地显示通过 getIconBitmap() 或 getIconUri() 获取的图标以及通过 MediaDescription 中描述的 getTitle() 获取的标题。*可以*缩短标题以符合安全法规（例如，驾驶员分心）。

• [C-1-3] 只要显示由此第三方应用程序提供的内容，就必须显示第三方应用程序图标。

• [C-1-4] 必须允许用户与整个 MediaBrowser 层次结构交互。*可以*限制对层次结构一部分的访问以符合安全法规（例如，驾驶员分心），但*不得*根据内容或内容提供商给予优惠待遇。

• [C-1-5] 必须将双击 KEYCODE_HEADSETHOOK 或 KEYCODE_MEDIA_PLAY_PAUSE 视为 KEYCODE_MEDIA_NEXT，用于 MediaSession.Callback#onMediaButtonEvent。

3.15. Instant Apps

如果设备实现支持 Instant Apps，则它们必须满足以下要求

• [C-1-1] Instant Apps 必须仅被授予 android:protectionLevel 设置为 "instant" 的权限。
• [C-1-2] Instant Apps 不得通过 隐式 intent 与已安装的应用交互，除非以下情况之一为真
  • 组件的 intent 模式过滤器已公开并具有 CATEGORY_BROWSABLE
  • 操作是 ACTION_SEND、ACTION_SENDTO、ACTION_SEND_MULTIPLE 之一
  • 目标通过 android:visibleToInstantApps 显式公开
• [C-1-3] Instant Apps 不得与已安装的应用显式交互，除非组件通过 android:visibleToInstantApps 公开。
• [C-1-4] 已安装的应用不得查看设备上有关 Instant Apps 的详细信息，除非 Instant App 显式连接到已安装的应用程序。

• 设备实现必须提供以下用户操作界面，用于与 Instant Apps 交互。AOSP 通过默认系统 UI、设置和启动器满足这些要求。设备实现

  • [C-1-5] 必须提供用户操作界面，以查看和删除为每个单独的应用软件包本地缓存的 Instant Apps。
  • [C-1-6] 必须提供一个持久性用户通知，该通知可以在 Instant App 在前台运行时折叠。此用户通知必须包括 Instant Apps 不需要安装，并提供一个用户操作界面，将用户定向到设置中的应用程序信息屏幕。对于通过 Web intent 启动的 Instant Apps，如通过使用操作设置为 Intent.ACTION_VIEW 且方案为“http”或“https”的 intent 定义的那样，如果设备上有浏览器可用，则额外的用户操作界面*应*允许用户不启动 Instant App，而是使用配置的 Web 浏览器启动关联的链接。
  • [C-1-7] 如果设备上提供了“最近使用”功能，则必须允许从“最近使用”功能访问正在运行的 Instant Apps。

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

3.16. 伴侣设备配对

Android 包括对伴侣设备配对的支持，以更有效地管理与伴侣设备的关联，并提供 CompanionDeviceManager API 供应用访问此功能。

如果设备实现支持伴侣设备配对功能，则它们

• [C-1-1] 必须声明功能标志 FEATURE_COMPANION_DEVICE_SETUP 。
• [C-1-2] 必须确保 android.companion 包中的 API 已完全实现。

Android 15 的新增要求开始

3.17. 重量级应用

如果设备实现声明了功能 FEATURE_CANT_SAVE_STATE，则它们

• [C-1-1] 必须一次只运行一个已安装的应用，该应用指定了 cantSaveState。如果用户在未显式退出的情况下离开此类应用（例如，在离开系统中的活动活动时按 Home 键，而不是在系统中没有剩余活动活动的情况下按 Back 键），则设备实现必须像对待其他预期保持运行的事物（例如前台服务）一样，优先处理 RAM 中的该应用。当此类应用在后台运行时，系统仍然可以对其应用电源管理功能，例如限制 CPU 和网络访问。
• [C-1-2] 一旦用户启动第二个声明了 cantSaveState 属性的应用，必须提供 UI 操作界面来选择不参与正常状态保存/恢复机制的应用。
• [C-1-3] *不得*对指定了 cantSaveState 的应用应用其他策略更改，例如更改 CPU 性能或更改调度优先级。

如果设备实现未声明功能 FEATURE_CANT_SAVE_STATE，则它们

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

3.18. 联系人

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

RawContacts 在 ACCOUNT_NAME 和 ACCOUNT_TYPE 列的原始联系人与帐户的相应 Account.name 和 Account.type 字段匹配时，“与”帐户“关联”或“存储在”帐户中。

默认本地帐户：原始联系人的帐户，这些原始联系人仅存储在设备上，并且未与 AccountManager 中的帐户关联，这些帐户是使用 ACCOUNT_NAME 和 ACCOUNT_TYPE 列的 *null* 值创建的。

自定义本地帐户：原始联系人的帐户，这些原始联系人仅存储在设备上，并且未与 AccountManager 中的帐户关联，这些帐户是使用 ACCOUNT_NAME 和 ACCOUNT_TYPE 列的 *至少一个非 null 值* 创建的。

设备实现

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

如果设备实现使用自定义本地帐户

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

Android 15 的新增要求开始

3.19. 语言设置

4. 应用程序打包兼容性

设备实现

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

  • 由于上述要求可能具有挑战性，因此*建议*设备实现使用 AOSP 参考实现的软件包管理系统。

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

• [C-0-3] *不得*以阻止这些文件在其他兼容设备上正确安装和运行的方式扩展 .apk、Android 清单、Dalvik 字节码或 RenderScript 字节码格式。

• [C-0-4] *不得*允许包的当前“记录安装程序”以外的应用在没有任何用户确认的情况下静默卸载该应用，如 SDK 中关于 DELETE_PACKAGE 权限的文档中所述。唯一的例外是处理 PACKAGE_NEEDS_VERIFICATION intent 的系统软件包验证程序应用和处理 ACTION_MANAGE_STORAGE intent 的存储管理器应用。

• [C-0-5] 必须具有一个 Activity 来处理 android.settings.MANAGE_UNKNOWN_APP_SOURCES intent。

• [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 Signature Scheme v4 和 APK Signature Scheme v4.1 验证 .apk 文件。

5. 多媒体兼容性

设备实现

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

设备实现

• *应*以最小编解码器延迟为目标，换句话说，它们
  • *应*在处理完输入缓冲区后才使用并存储输入缓冲区并返回输入缓冲区。
  • *应*保持解码缓冲区的时间不超过标准 (例如 SPS) 规定的时间。
  • *应*保持编码缓冲区的时间不超过 GOP 结构所需的时间。

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

请注意，Google 和开放手机联盟均未声明这些编解码器不受第三方专利的限制。建议那些打算在硬件或软件产品中使用此源代码的人员，此代码的实现（包括在开源软件或共享软件中）可能需要获得相关专利持有人的专利许可。

5.1. 媒体编解码器

5.1.1. 音频编码

有关更多详细信息，请参见 5.1.3. 音频编解码器详细信息。

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

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

所有音频编码器*必须*支持

• [C-3-1] 通过 android.media.MediaCodec API 的 PCM 16 位本机字节顺序音频帧。

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 (enhanced AAC+)
• [C-1-4] AAC ELD (enhanced low delay 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 中的“Dynamic Range Control (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] 响度和 DRC 元数据必须根据 MPEG-D DRC Dynamic Range Control Profile Level 1 进行解释和应用。
• [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 元数据*应*优先。

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

• [C-6-1] 通过 android.media.MediaCodec API 的 PCM 16 位本机字节顺序音频帧。

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

• [C-7-1] *必须*能够由应用程序使用密钥 KEY_MAX_OUTPUT_CHANNEL_COUNT 进行配置解码，以控制内容是下混为立体声（当使用值 2 时）还是使用本机声道数输出（当使用等于或大于该声道数的值时）。例如，值 6 或更大将配置解码器在馈送 5.1 内容时输出 6 个声道。
• [C-7-2] 解码时，解码器*必须*使用 KEY_CHANNEL_MASK 密钥在输出格式上播发正在使用的声道掩码，使用 android.media.AudioFormat 常量（示例：CHANNEL_OUT_5POINT1）。

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

• [C-SR-2] *强烈建议* 解码器能够由应用程序使用密钥 KEY_MAX_OUTPUT_CHANNEL_COUNT 进行配置解码，以控制内容是下混为立体声（当使用值 2 时）还是使用本机声道数输出（当使用等于或大于该声道数的值时）。例如，值 6 或更大将配置解码器在馈送 5.1 内容时输出 6 个声道。
• [C-SR-3] 解码时，**强烈建议**解码器使用 KEY_CHANNEL_MASK 键在输出格式上声明正在使用的声道掩码，并使用 android.media.AudioFormat 常量（例如：CHANNEL_OUT_5POINT1）。

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

格式/编解码器	详情	要支持的文件类型/容器格式
MPEG-4 AAC 配置文件 （AAC LC）	支持单声道/立体声/5.0/5.1 内容，标准采样率从 8 kHz 到 48 kHz。	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS 原始 AAC (.aac，不支持 ADIF) MPEG-TS (.ts，不可搜索，仅解码) Matroska (.mkv，仅解码)
MPEG-4 HE AAC 配置文件 (AAC+)	支持单声道/立体声/5.0/5.1 内容，标准采样率从 16 kHz 到 48 kHz。	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
MPEG-4 HE AACv2 配置文件（增强型 AAC+）	支持单声道/立体声/5.0/5.1 内容，标准采样率从 16 kHz 到 48 kHz。	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
AAC ELD（增强型低延迟 AAC）	支持单声道/立体声内容，标准采样率从 16 kHz 到 48 kHz。	3GPP (.3gp) MPEG-4 (.mp4, .m4a)
USAC	支持单声道/立体声内容，标准采样率从 7.35 kHz 到 48 kHz。	MPEG-4 (.mp4, .m4a)
AMR-NB	4.75 至 12.2 kbps，采样率 @ 8 kHz	3GPP (.3gp)
AMR-WB	9 种速率，从 6.60 kbit/s 到 23.85 kbit/s，采样率 @ 16 kHz，如 AMR-WB, Adaptive Multi-Rate - Wideband Speech Codec 中定义	3GPP (.3gp)
FLAC	对于编码器和解码器：必须至少支持单声道和立体声模式。必须支持高达 192 kHz 的采样率；必须支持 16 位和 24 位分辨率。FLAC 24 位音频数据处理必须可用于浮点音频配置。	FLAC (.flac) MPEG-4 (.mp4, .m4a, 仅解码) Matroska (.mkv，仅解码)
MP3	单声道/立体声 8-320Kbps 常量 (CBR) 或可变比特率 (VBR)	MP3 (.mp3) MPEG-4 (.mp4, .m4a, 仅解码) Matroska (.mkv，仅解码)
MIDI	MIDI Type 0 和 1。DLS Version 1 和 2。XMF 和 Mobile XMF。支持铃声格式 RTTTL/RTX、OTA 和 iMelody	Type 0 和 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) iMelody (.imy)
Vorbis	解码：支持单声道、立体声、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)
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 和 Baseline Profile。

如果设备实现通过 android.media.MediaCodec 支持媒体类型 MIMETYPE_IMAGE_ANDROID_HEIC 的 HEIC 编码，则它们

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

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（Baseline Profile）

如果设备实现支持 HEVC 视频解码，则它们

• [C-1-1] **必须**支持 HEIF (HEIC) 图像解码。

支持高位深度格式（每个通道 9 位以上）的图像解码器

• [C-2-1] **必须**在应用程序请求时支持输出 8 位等效格式，例如，通过 ARGB_8888 android.graphics.Bitmap 配置。

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（Baseline Profile）	图像、图像集合、图像序列 Baseline Profile	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. 视频编解码器

• 为了获得可接受的 Web 视频流和视频会议服务质量，设备实现**应该**使用符合 要求的硬件 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 位等效格式。这**必须**通过经由 android.media.MediaCodecInfo 支持 YUV420 8:8:8 颜色格式来体现。

如果设备实现通过 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] 如果配置为不使用 Surface 输出，**必须**默认为针对 CPU 读取优化的 YUV420 8:8:8 颜色格式。

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	WebM (.webm) Matroska (.mkv)
VP9	有关详细信息，请参阅 第 5.3 节	WebM (.webm) Matroska (.mkv)
AV1	有关详细信息，请参阅 第 5.2 节和 第 5.3 节	MPEG-4 (.mp4) Matroska (.mkv，仅解码)

5.1.9. 媒体编解码器安全性

设备实现**必须**确保符合下述媒体编解码器安全功能。

Android 包括对跨平台多媒体加速 API OMX 以及低开销多媒体加速 API Codec 2.0 的支持。

如果设备实现支持多媒体，则它们

• [C-1-1] **必须**通过 OMX 或 Codec 2.0 API（或两者）提供对媒体编解码器的支持，如 Android 开源项目中所述，并且不得禁用或规避安全保护。这并非特指每个编解码器**必须**使用 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] 所有视频编解码器**必须**发布以下尺寸的可实现帧率数据（如果编解码器支持）：

	SD（低质量）	SD（高质量）	HD 720p	HD 1080p	UHD
视频分辨率	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. 视频编码

如果设备实现支持任何视频编码器并将其提供给第三方应用，并且将
MediaFormat.KEY_BITRATE_MODE 设置为 BITRATE_MODE_VBR，以便编码器在可变比特率模式下运行，那么，只要它不影响 最低质量下限，编码比特率

• **应该**在帧内帧（I 帧）间隔之间的一个滑动窗口内，不超过比特率的 15%。
• **应该**在一个 1 秒的滑动窗口内，不超过比特率的 100%。

如果设备实现支持任何视频编码器并将其提供给第三方应用，并且将 MediaFormat.KEY_BITRATE_MODE 设置为 BITRATE_MODE_CBR，以便编码器在恒定比特率模式下运行，则编码比特率

• [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（任意切片顺序）、FMO（灵活宏块顺序）和 RS（冗余切片）的支持是可选的。此外，为了保持与其他 Android 设备的兼容性，**建议**编码器不要将 ASO、FMO 和 RS 用于 Baseline Profile。
• [C-1-2] **必须**支持下表中的 SD（标准清晰度）视频编码配置文件。
• **应该**支持 Main Profile Level 4。
• **应该**支持下表中指示的 HD（高清）视频编码配置文件。

如果设备实现通过媒体 API 报告支持 720p 或 1080p 分辨率视频的 H.264 编码，则它们

• [C-2-1] **必须**支持下表中的编码配置文件。

	SD（低质量）	SD（高质量）	HD 720p	HD 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] **必须**支持 SD 视频编码配置文件。
• **应该**支持以下 HD（高清）视频编码配置文件。
• [C-1-2] **必须**写入 Matroska WebM 文件。
• **应该**提供符合 WebM 项目 RTC 硬件编码要求的硬件 VP8 编解码器，以确保 Web 视频流和视频会议服务的可接受质量。

如果设备实现通过媒体 API 报告支持 720p 或 1080p 分辨率视频的 VP8 编码，则它们

• [C-2-1] **必须**支持下表中的编码配置文件。

	SD（低质量）	SD（高质量）	HD 720p	HD 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 数据。
• **应该**支持下表中指示的 HD 解码配置文件。
• [C-SR-1] 如果有硬件编码器，**强烈建议**支持下表中指示的 HD 解码配置文件。

	SD	HD 720p	HD 1080p	UHD
视频分辨率	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

如果设备实现声明通过 Media 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 SD 配置文件和下表中指示的 HD 编码配置文件。

	SD	HD 720p	HD 1080p	UHD
视频分辨率	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 的编码配置文件

	SD	HD 720p	HD 1080p	UHD
视频分辨率	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 编解码器的动态视频分辨率和帧率切换，并且达到设备上每个编解码器支持的最大分辨率。

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（任意切片顺序）、FMO（灵活宏块顺序）和 RS（冗余切片）的支持是可选的。
• [C-1-2] **必须**能够解码下表中列出的 SD（标准清晰度）配置文件，并使用 Baseline Profile 和 Main Profile Level 3.1（包括 720p30）进行编码的视频。
• **应该**能够解码下表中指示的 HD（高清）配置文件视频。

如果 Display.getSupportedModes() 方法报告的高度等于或大于视频分辨率，则设备实现

• [C-2-1] **必须**支持下表中的 HD 720p 视频解码配置文件。
• [C-2-2] **必须**支持下表中的 HD 1080p 视频解码配置文件。

	SD（低质量）	SD（高质量）	HD 720p	HD 1080p
视频分辨率	320 x 240 像素	720 x 480 像素	1280 x 720 像素	1920 x 1080 像素
视频帧率	30 fps	30 fps	60 fps	30 fps (60 fps电视)
视频比特率	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 和下表中指示的 SD 视频解码配置文件。
• **应该**支持下表中指示的 HD 解码配置文件。
• [C-1-2] 如果有硬件解码器，**必须**支持下表中指示的 HD 解码配置文件。

如果 Display.getSupportedModes() 方法报告的高度等于或大于视频分辨率，则

• [C-2-1] 设备实现**必须**支持 720、1080 和 UHD 配置文件的 H.265 或 VP9 解码中的至少一个。

	SD（低质量）	SD（高质量）	HD 720p	HD 1080p	UHD
视频分辨率	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 硬件解码的电视)	60 fps
视频比特率	600 Kbps	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

如果设备实现声明通过 Media API 支持 HDR Profile

• [C-3-1] 设备实现**必须**接受来自应用程序的所需 HDR 元数据，以及支持从码流和/或容器中提取和输出所需的 HDR 元数据。
• [C-3-2] 设备实现**必须**在设备屏幕上或标准视频输出端口（例如，HDMI）上正确显示 HDR 内容。

5.3.6. VP8

如果设备实现支持 VP8 编解码器，则它们

• [C-1-1] **必须**支持下表中的 SD 解码配置文件。
• **应该**使用符合 要求的硬件 VP8 编解码器。
• **应该**支持下表中的 HD 解码配置文件。

如果 Display.getSupportedModes() 方法报告的高度等于或大于视频分辨率，则

• [C-2-1] 设备实现**必须**支持下表中的 720p 配置文件。
• [C-2-2] 设备实现**必须**支持下表中的 1080p 配置文件。

	SD（低质量）	SD（高质量）	HD 720p	HD 1080p
视频分辨率	320 x 180 像素	640 x 360 像素	1280 x 720 像素	1920 x 1080 像素
视频帧率	30 fps	30 fps	30 fps (60 fps电视)	30 (60 fps电视)
视频比特率	800 Kbps	2 Mbps	8 Mbps	20 Mbps

5.3.7. VP9

如果设备实现支持 VP9 编解码器，则它们

• [C-1-1] **必须**支持下表中指示的 SD 视频解码配置文件。
• **应该**支持下表中指示的 HD 解码配置文件。

如果设备实现支持 VP9 编解码器和硬件解码器

• [C-2-1] **必须**支持下表中指示的 HD 解码配置文件。

如果 Display.getSupportedModes() 方法报告的高度等于或大于视频分辨率，则

• [C-3-1] 设备实现**必须**支持 720、1080 和 UHD 配置文件的 VP9 或 H.265 解码中的至少一个。

	SD（低质量）	SD（高质量）	HD 720p	HD 1080p	UHD
视频分辨率	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 硬件解码的电视)	60 fps
视频比特率	600 Kbps	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

如果设备实现声明通过 'CodecProfileLevel' 媒体 API 支持 VP9Profile2 或 VP9Profile3

• 对 12 位格式的支持是可选的。

如果设备实现声明通过媒体 API 支持 HDR Profile (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. Dolby Vision

如果设备实现通过 HDR_TYPE_DOLBY_VISION 声明支持 Dolby Vision 解码器，则它们

• [C-1-1] **必须**提供支持 Dolby Vision 的提取器。

Android 15 的新增要求开始

• [C-1-3] **必须**将向后兼容的基础层（如果存在）的 track ID 设置为与组合 Dolby Vision 层的 track ID 相同。

5.3.9. AV1

如果设备实现支持 AV1 编解码器并使其可供第三方应用程序使用，则它们

• [C-1-1] **必须**支持 Main Profile，包括 8 位和 10 位内容。

如果设备实现提供对具有硬件加速解码器的 AV1 编解码器的支持，那么它们

• [C-2-1] 当 Display.getSupportedModes() 方法报告的高度等于或大于 720p 时，**必须**能够解码下表中的至少 HD 720p 视频解码配置文件。
• [C-2-2] 当 Display.getSupportedModes() 方法报告的高度等于或大于 1080p 时，**必须**能够解码下表中的至少 HD 1080p 视频解码配置文件。

	SD	HD 720p	HD 1080p	UHD
视频分辨率	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

如果设备实现通过 Media API 支持 HDR Profile，那么它们

• [C-3-1] **必须**支持从码流和/或容器中提取和输出 HDR 元数据。
• [C-3-2] **必须**在设备屏幕上或标准视频输出端口（例如，HDMI）上正确显示 HDR 内容。

5.4. 音频录制

虽然本节中概述的某些要求自 Android 4.3 以来被列为 SHOULD，但未来版本的兼容性定义计划将这些要求更改为 MUST。**强烈建议**现有和新的 Android 设备满足这些被列为 SHOULD 的要求，否则当升级到未来版本时，它们将无法获得 Android 兼容性。

5.4.1. 原始音频捕获和麦克风信息

如果设备实现声明 android.hardware.microphone，则它们

• [C-1-1] **必须**允许捕获任何成功打开的 AudioRecord 或 AAudio INPUT 流的原始音频内容。至少，**必须**支持以下特性

  • **格式：**线性 PCM，16 位
  • **采样率：**8000、11025、16000、44100、48000 Hz
  • **声道：**单声道
  • **音频源：**DEFAULT、MIC、CAMCORDER、VOICE_RECOGNITION、VOICE_COMMUNICATION、UNPROCESSED 或 VOICE_PERFORMANCE。这也适用于 AAudio 中的等效输入预设，例如，AAUDIO_INPUT_PRESET_CAMCORDER。

• **应该**允许捕获具有以下特性的原始音频内容

  • **格式**：线性 PCM，16 位和 24 位
  • **采样率**：8000、11025、16000、22050、24000、32000、44100、48000 Hz
  • **声道**：与设备上的麦克风数量一样多的声道

• [C-1-2] **必须**以高于上述采样率进行捕获，而无需升采样。

• [C-1-3] 当使用降采样捕获上述采样率时，**必须**包含适当的抗锯齿滤波器。

• **应该**允许 AM 无线电和 DVD 质量的原始音频内容捕获，这意味着以下特性

  • **格式**：线性 PCM，16 位
  • **采样率**：22050、48000 Hz
  • **声道**：立体声

• [C-1-4] **必须**遵循 MicrophoneInfo API，并正确填写设备上可供第三方应用程序通过 AudioManager.getMicrophones() API 访问的可用麦克风的信息，用于使用 MediaRecorder.AudioSources DEFAULT、MIC、CAMCORDER、VOICE_RECOGNITION、VOICE_COMMUNICATION、UNPROCESSED 或 VOICE_PERFORMANCE 的活动 AudioRecord。如果设备实现允许 AM 无线电和 DVD 质量的原始音频内容捕获，则它们

• [C-2-1] **必须**在任何高于 16000:22050 或 44100:48000 的比率下进行捕获，而无需升采样。

• [C-2-2] **必须**为任何升采样或降采样包含适当的抗锯齿滤波器。

5.4.2. 语音识别捕获

如果设备实现声明 android.hardware.microphone，则它们

• [C-1-1] **必须**以 44100 和 48000 采样率之一捕获 android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION 音频源。
• [C-1-2] 在从 AudioSource.VOICE_RECOGNITION 音频源录制音频流时，**必须**默认禁用任何降噪音频处理。

• [C-1-3] 在从 AudioSource.VOICE_RECOGNITION 音频源录制音频流时，**必须**默认禁用任何自动增益控制。

• **应该**在频率中频范围内表现出大致平坦的幅度与频率特性：具体而言，对于用于录制语音识别音频源的每个麦克风，在 100 Hz 至 4000 Hz 范围内为 ±3dB。

• [C-SR-1] **强烈建议**在低频范围内表现出幅度水平：具体而言，对于用于录制语音识别音频源的每个麦克风，在 30 Hz 至 100 Hz 范围内与中频范围相比为 ±20 dB。

• [C-SR-2] 强烈建议 用于录制语音识别音频源的每个麦克风，在高频范围内表现出振幅水平：具体而言，与中频范围相比，在 4000 Hz 至 22 KHz 范围内为 ±30 dB。

• 应该 设置音频输入灵敏度，使得以 90 分贝声压级 (SPL) (在麦克风旁边测量) 播放的 1000 Hz 正弦波音调源，对于 16 位采样，产生 RMS 2500 的理想响应，范围在 1770 到 3530 之间（或者对于浮点/双精度采样，为 -22.35 db ±3dB 满量程），用于录制语音识别音频源的每个麦克风。

• 应该 录制语音识别音频流，以便 PCM 振幅水平在线性跟踪输入 SPL 变化，范围至少为 30 dB，从 -18 dB 到 +12 dB re 90 dB SPL 在麦克风处。

• 应该 录制语音识别音频流，在麦克风处 90 dB SPL 输入电平时，1 kHz 的总谐波失真 (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，则它们

• 应该 实现一个 声学回声消除器 (AEC) 技术，该技术针对语音通信进行调优，并在使用 AudioSource.VOICE_COMMUNICATION 捕获时应用于捕获路径。

如果设备实现提供了一个声学回声消除器，当选择 AudioSource.VOICE_COMMUNICATION 时，该消除器被插入到捕获音频路径中，则它们

• [C-SR-1] 强烈建议 通过 AcousticEchoCanceler API 方法 AcousticEchoCanceler.isAvailable() 声明此功能
• [C-SR-2] 强烈建议 允许使用 AcousticEchoCanceler API 控制此音频效果。
• [C-SR-3] 强烈建议 通过 AudioEffect.Descriptor.uuid 字段唯一标识每种 AEC 技术实现。

5.4.5. 并发捕获

如果设备实现声明了 android.hardware.microphone，则它们必须按照 此文档 中所述实现并发捕获。具体而言

• [C-1-1] 必须 允许使用 AudioSource.VOICE_RECOGNITION 捕获的可访问性服务和至少一个使用任何 AudioSource 捕获的应用程序并发访问麦克风。
• [C-1-2] 必须 允许持有 Assistant 角色的预装应用程序和至少一个使用任何 AudioSource 捕获的应用程序并发访问麦克风，但 AudioSource.VOICE_COMMUNICATION 或 AudioSource.CAMCORDER 除外。
• [C-1-3] 必须 在应用程序使用 AudioSource.VOICE_COMMUNICATION 或 AudioSource.CAMCORDER 捕获时，静音任何其他应用程序（可访问性服务除外）的音频捕获。但是，当应用程序通过 AudioSource.VOICE_COMMUNICATION 捕获时，如果另一个应用程序是具有 CAPTURE_AUDIO_OUTPUT 权限的特权（预装）应用程序，则它可以捕获语音通话。
• [C-1-4] 如果两个或多个应用程序同时捕获，并且没有应用程序在最上层有 UI，则最近开始捕获的应用程序接收音频。

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 控制。

Android 15 的新增要求开始

Android 15 的新增要求开始

• 应该 支持 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。 OpenSL ES API 在 Android NDK 中的 PCM 相关集合。
• AAudio 原生音频 API。 AAudio API 在 Android NDK 中的集合。
• 时间戳。 由流中的相对帧位置和估计的帧进入或离开关联端点上的音频处理管道的时间组成的一对。 另请参见 AudioTimestamp。
• 故障。 音频信号中的临时中断或不正确的采样值，通常由输出的 缓冲区欠载、输入的缓冲区溢出或任何其他数字或模拟噪声源引起。
• 平均绝对偏差 (MAD)。 一组值的偏差绝对值与平均值的平均值。

Android 15 的新增要求开始

如果设备实现声明了 android.hardware.audio.output，则它们必须满足或超过以下要求

Android 15 的新增要求开始

• [C-1-2] 冷启动输出延迟为 500 毫秒或更短。

• [C-1-3] 使用 AAudioStreamBuilder_openStream() 打开输出流必须花费少于 1000 毫秒。

Android 15 的新增要求开始

Android 15 的新增要求开始

Android 15 的新增要求开始

Android 15 的新增要求开始

如果设备实现包含 android.hardware.microphone，则它们必须满足这些输入音频要求

Android 15 的新增要求开始

• [C-3-2] 冷启动输入延迟为 500 毫秒或更短。
• [C-3-3] 使用 AAudioStreamBuilder_openStream() 打开输入流必须花费少于 1000 毫秒。

Android 15 的新增要求开始

Android 15 的新增要求开始

Android 15 的新增要求开始

Android 15 的新增要求开始

Android 15 的新增要求开始

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 有关 H264 AVC、MPEG2-4 SP 和 MPEG-2 的详细信息，请参阅 5.1.8 节。 音频编解码器 AAC 有关 AAC 及其变体的详细信息，请参阅 5.1.3 节。
具有 ADTS 帧和 ID3 标签的 AAC	ISO 13818-7	有关 AAC 及其变体的详细信息，请参阅 5.1.1 节
WebVTT	WebVTT

RTSP (RTP, SDP)

配置文件名称	参考	必需的编解码器支持
H264 AVC	RFC 6184	有关 H264 AVC 的详细信息，请参阅 5.1.8 节
MP4A-LATM	RFC 6416	有关 AAC 及其变体的详细信息，请参阅 5.1.3 节
H263-1998	RFC 3551 RFC 4629 RFC 2190	有关 H263 的详细信息，请参阅 5.1.8 节
H263-2000	RFC 4629	有关 H263 的详细信息，请参阅 5.1.8 节
AMR	RFC 4867	有关 AMR-NB 的详细信息，请参阅 5.1.3 节
AMR-WB	RFC 4867	有关 AMR-WB 的详细信息，请参阅 5.1.3 节
MP4V-ES	RFC 6416	有关 MPEG-4 SP 的详细信息，请参阅 5.1.8 节
mpeg4-generic	RFC 3640	有关 AAC 及其变体的详细信息，请参阅 5.1.3 节
MP2T	RFC 2250	有关详细信息，请参阅 HTTP Live Streaming 下方的 MPEG-2 传输流

5.8. 安全媒体

如果设备实现支持安全视频输出并能够支持安全表面，则它们

• [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 over 所有 MIDI 功能硬件传输，对于这些硬件传输，它们提供通用非 MIDI 连接，其中此类传输包括

  • USB 主机模式，7.7 节
  • 在中央角色中充当的低功耗蓝牙 MIDI，7.4.3 节

• [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 功能。

Android 15 的新增要求开始

• [C-1-3] 必须 包含支持 USB 主机模式和 USB 外围设备模式的 USB 端口。
• [C-1-4] 必须 报告支持 android.software.midi 功能。

Android 15 的新增要求开始

• [C-1-6] 必须 具有 200 毫秒或更短的冷启动输出延迟。
• [C-1-7] 必须 具有 200 毫秒或更短的冷启动输入延迟。

Android 15 的新增要求开始

Android 15 的新增要求开始

如果设备实现包含 4 导体 3.5 毫米音频插孔，则它们

Android 15 的新增要求开始

Android 15 的新增要求开始

如果设备实现省略了 4 导体 3.5 毫米音频插孔，并包含支持 USB 主机模式的 USB 端口，则它们

• [C-3-1] 必须 实现 USB 音频类。

Android 15 的新增要求开始

Android 15 的新增要求开始

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] 必须 在中频范围内表现出近似平坦的幅度与频率特性：具体而言，对于用于录制未处理音频源的每个麦克风，在 100 Hz 至 7000 Hz 范围内为 ±10 dB。

• [C-1-3] 必须 在低频范围内表现出振幅水平：具体而言，对于用于录制未处理音频源的每个麦克风，与中频范围相比，在 5 Hz 至 100 Hz 范围内为 ±20 dB。

• [C-1-4] 必须 在高频范围内表现出振幅水平：具体而言，对于用于录制未处理音频源的每个麦克风，与中频范围相比，在 7000 Hz 至 22 KHz 范围内为 ±30 dB。

• [C-1-5] 必须 设置音频输入灵敏度，使得以 94 分贝声压级 (SPL) 播放的 1000 Hz 正弦波音调源对于 16 位采样产生 RMS 为 520 的响应（或者对于浮点/双精度采样，为 -36 dB 满量程），用于录制未处理音频源的每个麦克风。

• [C-1-6] 必须 对于用于录制未处理音频源的每个麦克风，具有 60 dB 或更高的信噪比 (SNR)。（而 SNR 测量为 94 dB SPL 与自噪声的等效 SPL 之间的差异，A 计权）。

• [C-1-7] 必须 对于用于录制未处理音频源的每个麦克风，在 90 dB SPL 输入电平下 1 kHz 的总谐波失真 (THD) 小于 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 读取（ImageReader、MediaImage、ByteBuffer）的 P010 格式。在 Android 13 中，P010 已放宽限制，允许 Y 和 UV 平面具有任意步幅。

• [C-1-2] P010 输出缓冲区必须能够被 GPU 采样（当使用 GPU_SAMPLING 用法分配时）。这支持通过应用进行 GPU 合成和自定义色调映射。

如果视频解码器声明支持 COLOR_Format32bitABGR2101010，则

• [C-2-1] 必须支持用于输出表面和 CPU 可读（ByteBuffer 输出）的 RGBA_1010102 格式。

如果视频编码器声明支持 COLOR_FormatYUVP010，则

• [C-3-1] 必须支持用于输入表面和 CPU 可写（ImageWriter、MediaImage、ByteBuffer）输入的 P010 格式。

如果视频编码器声明支持 COLOR_Format32bitABGR2101010，则

• [C-4-1] 必须支持用于输入表面和 CPU 可写（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 元数据不存在时，应使用最小延迟生成 HDR 元数据，并且应优雅地处理某些帧存在元数据而其他帧不存在元数据的情况。此元数据应是精确的（例如，表示帧的实际峰值亮度和直方图）。

如果设备实现包括支持 FEATURE_HdrEditing 的编解码器，则这些编解码器

• [C-7-1] 必须支持至少一个 HDR 配置文件。

• [C-7-2] 必须为该编解码器声明的所有 HDR 配置文件支持 FEATURE_HdrEditing。换句话说，它们必须支持为使用 HDR 元数据的所有受支持 HDR 配置文件在元数据不存在时生成 HDR 元数据。

• [C-7-3] 必须支持以下完全保留 HDR 解码信号的视频编码器输入格式

  • RGBA_1010102（已在目标传输曲线中），用于输入表面和 ByteBuffer，并且必须声明支持 COLOR_Format32bitABGR2101010。

如果设备实现包括支持 FEATURE_HdrEditing 的编解码器，则该设备

• [C-7-4] 必须声明支持 EXT_YUV_target OpenGL 扩展。

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

6.1. 开发者工具

设备实现

• [C-0-1] 必须支持 Android SDK 中提供的 Android 开发者工具。
• Android 调试桥 (adb)

• 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 二进制文件，该文件命令行符合 perfetto 文档。
  • [C-SR-2] 强烈建议 perfetto 二进制文件接受符合 perfetto 文档中定义的架构的 protobuf 配置作为输入。
  • [C-SR-3] 强烈建议 perfetto 二进制文件将符合 perfetto 文档中定义的架构的 protobuf 跟踪记录为输出。
  • [C-SR-4] 强烈建议通过 perfetto 二进制文件至少提供 perfetto 文档中描述的数据源。

• 内存不足终止程序

  • [C-0-12] 当应用被 内存不足终止程序终止时，必须将 LMK_KILL_OCCURRED_FIELD_NUMBER Atom 写入 statsd 日志。

• 测试工具模式 如果设备实现支持 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 实现默认情况下会隐藏“开发者选项”菜单，并允许用户在连续点击七 (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] API 方法必须在 SDK 文档允许的情况下返回空值。
• [C-0-5] API 方法必须在 SDK 文档不允许空值的情况下返回类的无操作实现。
• [C-0-6] API 方法绝不能抛出 SDK 文档中未记录的异常。
• [C-0-7] 设备实现必须通过 getSystemAvailableFeatures() 和 hasSystemFeature(String) 方法在 android.content.pm.PackageManager 类上一致地报告同一构建指纹的准确硬件配置信息。

这些要求适用的典型场景示例是电话 API：即使在非电话设备上，这些 API 也必须实现为合理的无操作。

7.1. 显示屏和图形

Android 包括自动调整应用资源和 UI 布局以适应设备的工具，以确保第三方应用在各种硬件显示屏和配置上都能良好运行。Android 兼容显示屏是指实现 Android 开发者 - 屏幕兼容性概览、本节 (7.1) 及其子节中描述的所有行为和 API 以及 第 2 节的 CDD 中记录的任何其他设备类型特定行为的显示屏。

设备实现

• [C-0-1] 必须默认仅将第三方应用渲染到 Android 兼容显示屏上。

本节中要求的单位定义如下

• 物理对角线尺寸。显示屏发光部分两个相对角之间的英寸距离。
• 密度。1 英寸线性水平或垂直跨度所包含的像素数，以每英寸像素数 (ppi 或 dpi) 表示。如果列出了 ppi 和 dpi 值，则水平和垂直 dpi 都必须在列出的范围内。
• 宽高比。屏幕较长尺寸的像素与较短尺寸的像素之比。例如，480x854 像素的显示屏的宽高比为 854/480 = 1.779，或大约为“16:9”。
• 与密度无关的像素 (dp)。归一化为 160 屏幕密度的虚拟像素单位。对于某些密度 d 和像素数 p，与密度无关的像素 dp 数计算公式为：dp = (160 / d) * p。

7.1.1. 屏幕配置

7.1.1.1. 屏幕尺寸和形状

Android UI 框架支持各种不同的逻辑屏幕布局尺寸，并允许应用通过 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 尺寸配置的屏幕，并使用带有圆角的物理显示屏来渲染这些屏幕，则它们

• [C-1-1] 必须确保每个此类显示屏至少满足以下要求之一

  • 圆角的半径小于或等于 38 dp。
  • 当 18 dp x 18 dp 的框锚定在逻辑显示屏的每个角时，每个框的至少一个像素在屏幕上可见。

• 应包括用户途径来切换到具有直角边角的显示模式。

如果设备实现仅支持 NO_KEYS 键盘配置，并且打算报告支持 UI_MODE_TYPE_NORMAL UI 模式配置，则它们

• [C-4-1] 必须具有至少 596 dp x 384 dp 或更大的布局尺寸（不包括任何显示屏切口）。

有关正确实现侧屏或扩展 API 的详细信息，请参阅 WindowManager Jetpack 的公共文档。

Android 15 的新增要求开始

7.1.1.2. 屏幕宽高比

本节已在 Android 14 中删除。

7.1.1.3. 屏幕密度

Android UI 框架定义了一组标准逻辑密度，以帮助应用开发者定位应用资源。

设备实现

• [C-0-1] 必须通过 DENSITY_DEVICE_STABLE API 报告 DisplayMetrics 上列出的 Android 框架密度之一，并且此值对于每个物理显示屏都必须是静态值。但是，设备可能会根据用户在初始启动后设置的显示屏配置更改（例如，显示屏尺寸）报告不同的 DisplayMetrics.density。

• 应定义在数值上最接近屏幕物理密度的标准 Android 框架密度，或映射到手持设备相同等效视角测量值的值。

如果设备实现提供更改设备显示屏尺寸的途径，则它们

• [C-1-1] 显示屏缩放比例绝不能大于 DENSITY_DEVICE_STABLE 的 1.5 倍，或者产生的有效最小屏幕尺寸小于 320dp（相当于资源限定符 sw320dp），以先到者为准。
• [C-1-2] 显示屏缩放比例绝不能小于 DENSITY_DEVICE_STABLE 的 0.85 倍。
• 为了确保良好的可用性和一致的字体大小，建议提供以下本机显示屏选项的缩放比例（同时遵守上述限制）
  • 小：0.85 倍
  • 默认：1 倍（本机显示屏比例）
  • 大：1.15 倍
  • 更大：1.3 倍
  • 最大：1.45 倍

7.1.2. 显示屏指标

如果设备实现包括 Android 兼容显示屏或到 Android 兼容显示屏的视频输出，则它们

• [C-1-1] 必须报告 android.util.DisplayMetrics API 中定义的所有 Android 兼容显示屏指标的正确值。

如果设备实现不包括嵌入式屏幕或视频输出，则它们

• [C-2-1] 必须报告 android.util.DisplayMetrics API 中定义的模拟默认 view.Display 的 Android 兼容显示屏的正确值。

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 的支持。

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

Android 15 的新增要求开始

Android 15 的新增要求开始

• 应支持 OpenGL ES 3.2。

OpenGL ES dEQP 测试分为多个测试列表，每个列表都有一个关联的日期/版本号。这些列表位于 Android 源代码树中的 external/deqp/android/cts/main/glesXX-master-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] 必须至少支持版本 132383489（自 2020 年 3 月 1 日起），如 android.software.opengles.deqp.level 功能标志中所报告。
• [C-2-5] 必须通过版本 132383489 和 android.software.opengles.deqp.level 功能标志中指定的版本之间的测试列表中的所有 OpenGL ES dEQP 测试（对于每个受支持的 OpenGL ES 版本）。
• [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-master-YYYY-MM-DD.txt 中。支持自报告级别的 Vulkan 的设备表明，它可以通过此级别及更早级别的所有测试列表中的 dEQP 测试。

如果设备实现包括对 Vulkan 的支持，则它们

• [C-1-1] 必须使用 android.hardware.vulkan.level 和 android.hardware.vulkan.version 功能标志报告正确的整数值。
• [C-1-2] 必须为 Vulkan 原生 API vkEnumeratePhysicalDevices() 枚举至少一个 VkPhysicalDevice。
• [C-1-3] 必须为每个枚举的 VkPhysicalDevice 完全实现 Vulkan 1.1 API。
• [C-1-4] 必须通过 Vulkan 原生 API vkEnumerateInstanceLayerProperties() 和 vkEnumerateDeviceLayerProperties() 枚举应用软件包原生库目录中名为 libVkLayer*.so 的原生库中包含的图层。
• [C-1-5] 除非应用将 android:debuggable 属性设置为 true 或将元数据 com.android.graphics.injectLayers.enable 设置为 true，否则绝不能枚举应用软件包外部的库提供的图层，或提供其他方法来跟踪或拦截 Vulkan API。
• [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] 必须至少支持版本 132317953（自 2019 年 3 月 1 日起），如 android.software.vulkan.deqp.level 功能标志中所报告。
• [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 扩展。
• [C-1-12] 绝不能枚举对 VK_KHR_performance_query 扩展的支持。
• [C-SR-4] 强烈建议满足 Android Baseline 2022 配置文件中指定的要求。
• [C-SR-5] 强烈建议支持 VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory 和 VK_EXT_global_priority。
• [C-SR-6] 强烈建议将 SkiaVk 与 HWUI 结合使用。

Android 15 的新增要求开始

如果设备实现不包括对 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 扩展可供第三方应用使用，并使应用能够将 fence 有效负载导出到 POSIX 文件描述符并从中导入 fence 有效负载，如 此处所述。

7.1.4.3. RenderScript

设备实现

• [C-0-1] 必须支持 Android RenderScript，如 Android SDK 文档中所详述。

7.1.4.4. 2D 图形加速

Android 包括一种机制，应用可以通过使用清单标记 android:hardwareAccelerated 或直接 API 调用声明它们想要为应用、Activity、窗口或 View 级别启用 2D 图形硬件加速。

设备实现

• [C-0-1] 必须默认启用硬件加速，如果开发者通过设置 android:hardwareAccelerated="false" 或直接通过 Android View API 禁用硬件加速来请求禁用硬件加速，则必须禁用硬件加速。
• [C-0-2] 必须表现出与 硬件加速相关的 Android SDK 文档一致的行为。

Android 包括一个 TextureView 对象，该对象允许开发者将硬件加速的 OpenGL ES 纹理直接集成为 UI 层次结构中的渲染目标。

设备实现

• [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 空间中面积至少为 DCI-P3 的 90% 的显示屏。
• [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 开发的旧版应用受益。

7.1.6. 屏幕技术

Android 平台包含允许应用程序向 Android 兼容显示屏渲染丰富图形的 API。除非本文档明确允许，否则设备

必须

支持 Android SDK 定义的所有这些 API。

所有设备实现的 Android 兼容显示屏

• [C-0-1]

  必须

  能够渲染 16 位彩色图形。

• 应该

  支持能够渲染 24 位彩色图形的显示屏。
• [C-0-2]

  必须

  能够渲染动画。
• [C-0-3]

  必须

  具有介于 0.9 和 1.15 之间的像素纵横比 (PAR)。也就是说，像素纵横比

  必须

  接近正方形 (1.0)，容差为 10 ~ 15%。

7.1.7. 副显示屏

Android 包含对辅助 Android 兼容显示屏的支持，以实现媒体共享功能和用于访问外部显示屏的开发者 API。

如果设备实现支持外部显示屏（通过有线、无线或嵌入式附加显示屏连接），则它们

• [C-1-1]

  必须

  实现 Android SDK 文档中描述的 DisplayManager 系统服务和 API。

7.2. 输入设备

设备实现

• [C-0-1]

  必须

  包含输入机制，例如 触摸屏 或 非触摸导航，以在 UI 元素之间导航。

7.2.1. 键盘

如果设备实现包含对第三方输入法编辑器 (IME) 应用程序的支持，则它们

• [C-1-1]

  必须

  声明 android.software.input_methods 功能标志。
• [C-1-2]

  必须

  完整实现 Input Management Framework
• [C-1-3]

  必须

  预装软件键盘。

设备实现

• [C-0-1]

  不得

  包含与 android.content.res.Configuration.keyboard（QWERTY 或 12 键）中指定的格式之一不匹配的硬件键盘。

• 应该

  包含额外的软键盘实现。

• 可以

  包含硬件键盘。

7.2.2. 非触摸导航

Android 包含对 D-pad、轨迹球和滚轮作为非触摸导航机制的支持。

设备实现

• [C-0-1]

  必须

  报告 android.content.res.Configuration.navigation 的正确值。

如果设备实现缺少非触摸导航，则它们

• [C-1-1]

  必须

  为文本的选择和编辑提供合理的替代用户界面机制，该机制与输入管理引擎兼容。上游 Android 开源实现包含一种选择机制，适用于缺乏非触摸导航输入的设备。

7.2.3. 导航键

主页、最近任务 和 返回 功能通常通过与专用物理按钮或触摸屏的不同部分交互来提供，这对于 Android 导航范例至关重要，因此，设备实现

• [C-0-1]

  必须

  提供用户可操作性以启动已安装的应用程序，这些应用程序具有使用 <intent-filter> 设置为 ACTION=MAIN 和 CATEGORY=LAUNCHER 或 CATEGORY=LEANBACK_LAUNCHER（对于电视设备实现）的 activity。主页功能

  应该

  是此用户可操作性的机制。

• 应该

  为“最近任务”和“返回”功能提供按钮。

如果提供了“主页”、“最近任务”或“返回”功能，则它们

• [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 时，通过物理按钮、软件键或手势使应用程序可以使用“菜单”功能。除非与其他导航功能一起隐藏，“菜单”功能

  应该

  是可访问的。

如果设备实现提供 Assist 功能，则它们

• [C-4-1]

  必须

  在其他导航键可访问时，都可通过单击操作（例如，点击、双击或手势）访问“Assist 功能”。
• [C-SR-3]

  强烈建议

  使用长按“主页”功能作为此指定交互。

如果设备实现使用屏幕的不同部分来显示导航键，则它们

• [C-5-1] 导航键

  必须

  使用屏幕的不同部分，应用程序无法使用，并且

  不得

  遮挡或以其他方式干扰应用程序可使用的屏幕部分。
• [C-5-2]

  必须

  向应用程序提供满足 7.1.1 节中定义的显示屏部分要求。
• [C-5-3]

  必须

  遵守应用程序通过 View.setSystemUiVisibility() API 方法设置的标志，以便屏幕的这一不同部分（也称为导航栏）按照 SDK 中的文档正确隐藏。

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

• [C-6-1] WindowInsets#getMandatorySystemGestureInsets()

  必须

  仅用于报告“主页”手势识别区域。
• [C-6-2] 在前台应用程序通过 View#setSystemGestureExclusionRects() 提供的排除矩形内开始，但在 WindowInsets#getMandatorySystemGestureInsets() 之外的手势，只要排除矩形在 View#setSystemGestureExclusionRects() 的文档中指定的最大排除限制内，

  不得

  被导航功能拦截。
• [C-6-3] 如果前台应用程序先前已发送 MotionEvent.ACTION_DOWN 事件，则一旦触摸开始被系统手势拦截，

  必须

  向前台应用程序发送 MotionEvent.ACTION_CANCEL 事件。
• [C-6-4]

  必须

  提供用户可操作性以切换到基于屏幕按钮的导航（例如，在“设置”中）。

• 应该

  提供“主页”功能，作为从屏幕当前方向的底部边缘向上滑动的手势。

• 应该

  提供“最近任务”功能，作为从与“主页”手势相同的区域向上滑动并按住不放的手势。
• 在 WindowInsets#getMandatorySystemGestureInsets() 内开始的手势

  应该

  不受前台应用程序通过 View#setSystemGestureExclusionRects() 提供的排除矩形的影响。

如果从屏幕当前方向的左边缘和右边缘的任何位置提供导航功能

• [C-7-1] 导航功能

  必须

  是“返回”，并且作为从屏幕当前方向的左边缘和右边缘滑动的手势提供。
• [C-7-2] 如果在左边缘或右边缘提供了自定义可滑动系统面板，则它们

  必须

  放置在屏幕顶部 1/3 区域内，并具有清晰、持久的视觉指示，表明拖动将调用上述面板，而不是“返回”。系统面板

  可以

  由用户配置为位于屏幕边缘顶部 1/3 区域以下，但系统面板

  不得

  使用超过边缘 1/3 的区域。
• [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)
D-pad 上1 D-pad 下1	0x01 0x00393	AXIS_HAT_Y4
D-pad 左1 D-pad 右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)

¹ KeyEvent

² 上述 HID 用途

必须

在游戏手柄 CA (0x01 0x0005) 中声明。

³ 此用途

必须

具有逻辑最小值 0、逻辑最大值 7、物理最小值 0、物理最大值 315、单位为度，以及报告大小为 4。逻辑值定义为偏离垂直轴的顺时针旋转；例如，逻辑值 0 表示没有旋转且按下了向上按钮，而逻辑值 1 表示旋转了 45 度且同时按下了向上和向左键。

⁴ 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

¹ MotionEvent

7.2.7. 遥控器

有关设备特定要求，请参阅 2.3.1 节。

7.3. 传感器

如果设备实现包含特定传感器类型，并且该类型具有第三方开发人员对应的 API，则设备实现

必须

按照 Android SDK 文档和 Android 开源文档中关于 传感器 的描述来实现该 API。

设备实现

• [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] 当应用程序处理器处于活动状态时，对于最大请求延迟为 0 毫秒的传感器流，

  必须

  以最大延迟 100 毫秒 + 2 * sample_time 报告传感器数据。此延迟不包括任何滤波延迟。
• [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 API 中详述的 Android 传感器坐标系。
• [C-1-4]

  必须

  能够测量从自由落体到任何轴上重力 (4g) 的四倍或更多。
• [C-1-5]

  必须

  具有至少 12 位的分辨率。
• [C-1-6]

  必须

  具有不大于 0.05 m/s^2 的标准偏差，其中标准偏差应根据在最快采样率下至少 3 秒内收集的样本按轴计算。

• 应该

  以至少 200 Hz 的频率报告事件。

• 应该

  具有至少 16 位的分辨率。

• 应该

  在使用时进行校准（如果特性在生命周期内发生变化）并进行补偿，并在设备重启之间保留补偿参数。

• 应该

  进行温度补偿。

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

• [C-2-1]

  必须

  实现和报告 TYPE_ACCELEROMETER 传感器。
• [C-SR-4]

  强烈建议

  实现 TYPE_SIGNIFICANT_MOTION 复合传感器。
• [C-SR-5]

  强烈建议

  实现和报告 TYPE_ACCELEROMETER_UNCALIBRATED 传感器。强烈建议 Android 设备满足此要求，以便它们能够升级到未来的平台版本，其中这可能成为

  必需

  的。

• 应该

  实现 Android SDK 文档中描述的 TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR、TYPE_STEP_COUNTER 复合传感器。

如果设备实现包含轴数少于 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 API 中详述的 Android 传感器坐标系。
• [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]

  必须

  具有标准偏差（在最快采样率下至少 3 秒内收集的样本上按轴计算）不大于 1.5 µT；

  应该

  具有不大于 0.5 µT 的标准偏差。
• [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 米的加速度移动时

  • [C-1-3]

    必须

    能够至少在 95% 的时间内将位置确定在 20 米以内，速度确定在每秒 0.5 米以内。
  • [C-1-4]

    必须

    通过 GnssStatus.Callback 同时跟踪和报告来自一个星座的至少 8 颗卫星。

  • 应该

    能够同时跟踪来自多个星座（例如 GPS + 至少 Glonass、北斗、Galileo 之一）的至少 24 颗卫星。

• [C-SR-2]

  强烈建议

  在紧急电话呼叫期间，继续通过 GNSS 位置提供程序 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 米/秒平方的加速度移动时，应足以在至少 95% 的时间内计算出 20 米内的位置和 0.2 米/秒内的速度。

7.3.4. 陀螺仪

设备实现

• [C-SR-1] 强烈建议包含陀螺仪传感器。

如果设备实现包含陀螺仪，则它们

• [C-1-1]

  必须

  能够以至少 50 Hz 的频率报告事件。
• [C-1-4] 必须具有 12 位或更高的分辨率。
• [C-1-5] 必须进行温度补偿。
• [C-1-6] 必须在使用时进行校准和补偿，并在设备重启之间保留补偿参数。
• [C-1-7] 必须具有不大于 1e-7 rad^2 / s^2 每 Hz 的方差（每 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 轴陀螺仪，则它们

• [C-2-1] 必须实现 TYPE_GYROSCOPE 传感器。
• [C-SR-4] 强烈建议实现 TYPE_GYROSCOPE_UNCALIBRATED 传感器。

如果设备实现包含少于 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] 强烈建议能够报告 300hPa 至 1100hPa 范围内的压力测量值。
• 应该具有 1hPa 的绝对精度。
• 应该在 20hPa 范围内具有 0.12hPa 的相对精度（相当于海平面上约 200m 变化时约 1m 的精度）。

7.3.6. 温度计

如果设备实现包含环境温度计（温度传感器），则它们

• [C-1-1] 必须为环境温度传感器定义 SENSOR_TYPE_AMBIENT_TEMPERATURE，并且该传感器必须测量用户与设备交互位置的环境（房间/车厢）温度，单位为摄氏度。

如果设备实现包含测量非环境温度（例如 CPU 温度）的温度传感器，则它们

• [C-2-1] 不得为该温度传感器定义 SENSOR_TYPE_AMBIENT_TEMPERATURE。

如果设备实现包含用于监测皮肤温度的传感器，则它们

• [C-SR-1] 强烈建议支持 PowerManager.getThermalHeadroom API。

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 传感器，该传感器

  • 必须具有至少 -8g 和 +8g 之间的测量范围，强烈建议具有至少 -16g 和 +16g 之间的测量范围。
  • 必须具有至少 2048 LSB/g 的测量分辨率。
  • 必须具有 12.5 Hz 或更低的最小测量频率。
  • 必须具有 400 Hz 或更高的最大测量频率；应该支持 SensorDirectChannel RATE_VERY_FAST。
  • 必须具有不高于 400 μg/√Hz 的测量噪声。
  • 必须实现此传感器的非唤醒形式，且缓冲能力至少为 3000 个传感器事件。
  • 必须具有不差于 3 mW 的批量处理功耗。
  • [C-SR-1] 强烈建议具有至少为奈奎斯特频率 80% 的 3dB 测量带宽，以及此带宽内的白噪声频谱。
  • 应该具有在室温下测试的小于 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 和 +1000 dps 之间的测量范围。
  • 必须具有至少 16 LSB/dps 的测量分辨率。
  • 必须具有 12.5 Hz 或更低的最小测量频率。
  • 必须具有 400 Hz 或更高的最大测量频率；应该支持 SensorDirectChannel RATE_VERY_FAST。
  • 必须具有不高于 0.014°/s/√Hz 的测量噪声。
  • [C-SR-2] 强烈建议具有至少为奈奎斯特频率 80% 的 3dB 测量带宽，以及此带宽内的白噪声频谱。
  • 应该具有在室温下测试的小于 0.001 °/s √Hz 的速率随机游走。
  • 应该具有 ≤ +/- 0.05 °/ s / °C 的偏置随温度变化。
  • 应该具有 ≤ 0.02% / °C 的灵敏度随温度变化。
  • 应该具有 ≤ 0.2% 的最佳拟合线非线性。
  • 应该具有 ≤ 0.007 °/s/√Hz 的噪声密度。
  • 应该在设备静止时，在 10 ~ 40 ℃ 温度范围内具有小于 0.002 rad/s 的校准误差。
  • 应该具有小于 0.1°/s/g 的 g 灵敏度。
  • 应该具有 < 4.0 % 的轴间灵敏度，以及在设备工作温度范围内 < 0.3% 的轴间灵敏度变化。

• [C-2-4] 必须具有 TYPE_GYROSCOPE_UNCALIBRATED，其质量要求与 TYPE_GYROSCOPE 相同。

• [C-2-5] 必须具有 TYPE_GEOMAGNETIC_FIELD 传感器，该传感器

  • 必须具有至少 -900 和 +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 和 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_HARDWARE_BUFFER
  • TYPE_MEMORY_FILE
• 应该支持通过传感器直接通道报告以下类型的主传感器（非唤醒变体）的事件
  • TYPE_ACCELEROMETER
  • TYPE_ACCELEROMETER_UNCALIBRATED
  • TYPE_GYROSCOPE
  • TYPE_GYROSCOPE_UNCALIBRATED
  • TYPE_MAGNETIC_FIELD
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. 生物识别传感器

有关测量生物识别解锁安全性的更多背景信息，请参阅 测量生物识别安全性文档。

如果设备实现包含安全锁屏，则它们

• 应该包含生物识别传感器

生物识别传感器可根据其欺骗和冒名顶替接受率以及生物识别管道的安全性分为Class 3（以前的Strong）、Class 2（以前的Weak）或Class 1（以前的Convenience）。此分类决定了生物识别传感器与平台和第三方应用程序接口的能力。如果传感器希望被归类为 Class 1、Class 2 或 Class 3，则需要满足以下详述的其他要求。Class 2 和 Class 3 生物识别技术都将获得以下详述的附加功能。

如果设备实现通过 android.hardware.biometrics.BiometricManager、android.hardware.biometrics.BiometricPrompt 和 android.provider.Settings.ACTION_BIOMETRIC_ENROLL 向第三方应用程序提供生物识别传感器，则它们

• [C-4-1] 必须满足本文档中定义的 Class 3 或 Class 2 生物识别技术的要求。
• [C-4-2] 必须识别并遵守在 Authenticators 类中定义为常量的每个参数名称及其任何组合。相反，除了在 Authenticators 中记录为公共常量的那些及其任何组合之外，不得遵守或识别传递给 canAuthenticate(int) 和 setAllowedAuthenticators(int) 方法的整数常量。
• [C-4-3] 必须在具有 Class 3 或 Class 2 生物识别技术的设备上实现 ACTION_BIOMETRIC_ENROLL 操作。此操作必须仅显示 Class 3 或 Class 2 生物识别技术的注册入口点。

Android 15 的新增要求开始

如果设备实现支持被动生物识别技术，则它们

• [C-5-1] 默认情况下必须要求额外的确认步骤（例如，按下按钮）。
• [C-SR-1] 强烈建议具有一个设置，允许用户覆盖应用程序首选项并始终要求随附的确认步骤。
• [C-SR-2] 强烈建议确认操作是安全的，以防止操作系统或内核遭到破坏时被欺骗。例如，这意味着基于物理按钮的确认操作通过安全元件 (SE) 的仅输入通用输入/输出 (GPIO) 引脚路由，该引脚不能通过物理按钮按下以外的任何其他方式驱动。
• [C-5-2] 必须另外实现与 setConfirmationRequired(boolean) 对应的隐式身份验证流程（没有确认步骤），应用程序可以将其设置为用于登录流程。

如果设备实现具有多个生物识别传感器，则它们

• [C-7-1] 必须在生物识别被锁定（即，生物识别功能被禁用，直到用户使用主身份验证解锁）或限时锁定（即，生物识别功能暂时禁用，直到用户等待一段时间间隔）时，由于失败尝试次数过多，也锁定所有其他较低生物识别类别的生物识别技术。在限时锁定的情况下，生物识别验证的退避时间必须是所有限时锁定中生物识别技术的最长退避时间。

• [C-SR-12] 强烈建议当生物识别被锁定（即，生物识别功能被禁用，直到用户使用主身份验证解锁）或限时锁定（即，生物识别功能暂时禁用，直到用户等待一段时间间隔）时，由于失败尝试次数过多，也锁定所有其他相同生物识别类别的生物识别技术。在限时锁定的情况下，强烈建议生物识别验证的退避时间是所有限时锁定中生物识别技术的最长退避时间。

• [C-7-2] 必须质询用户以获得推荐的主身份验证（例如：PIN 码、图案、密码），以重置被锁定的生物识别技术的锁定计数器。Class 3 生物识别技术可以被允许重置相同或较低类别的锁定生物识别技术的锁定计数器。Class 2 或 Class 1 生物识别技术不得被允许完成任何生物识别技术的重置锁定操作。

• [C-SR-3] 强烈建议每次身份验证仅要求确认一个生物识别技术（例如，如果设备上同时提供指纹和面部传感器，则在确认其中任何一个后，应发送 onAuthenticationSucceeded）。

为了使设备实现允许第三方应用程序访问密钥库密钥，它们

• [C-6-1] 必须满足下文定义的 Class 3 的要求。
• [C-6-2] 当身份验证需要 BIOMETRIC_STRONG，或者身份验证是通过 CryptoObject 调用的时，必须仅显示 Class 3 生物识别技术。

如果设备实现希望将生物识别传感器视为 Class 1（以前的 Convenience），则它们

• [C-1-1] 必须具有小于 0.002% 的错误接受率。
• [C-1-2] 如果通过 Android 生物识别测试协议 测量的欺骗和冒名顶替接受率高于 7%，则必须披露此模式可能不如强 PIN 码、图案或密码安全，并清楚地列举启用它的风险。
• [C-1-9] 在不超过 20 次错误尝试之后，以及生物识别验证不少于 90 秒的退避时间之后，必须质询用户以获得推荐的主身份验证（例如，PIN 码、图案、密码） - 其中错误尝试是指具有足够的捕获质量 (BIOMETRIC_ACQUIRED_GOOD) 但与已注册生物识别不匹配的尝试。
• [C-SR-4] 如果通过 Android 生物识别测试协议测量的欺骗和冒名顶替接受率高于 7%，则强烈建议降低 [C-1-9] 中指定的生物识别验证的总错误尝试次数。
• [C-1-3] 必须限制生物识别验证的尝试次数 - 其中错误尝试是指具有足够的捕获质量 (BIOMETRIC_ACQUIRED_GOOD) 但与已注册生物识别不匹配的尝试。
• [C-SR-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 码/图案/密码），建立信任链，然后才能添加新的生物识别技术；Android 开源项目实现提供了框架中的机制来执行此操作。

Android 15 的新增要求开始

• [C-1-6] 必须遵守该生物识别技术的单个标志（即 DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT、DevicePolicymanager.KEYGUARD_DISABLE_FACE 或 DevicePolicymanager.KEYGUARD_DISABLE_IRIS）。

Android 15 的新增要求开始

Android 15 的新增要求开始

• [C-SR-7] 强烈建议使用 Android 开源项目提供的框架中的逻辑来强制执行 [C-1-7] 和 [C-1-8] 中为新设备指定的约束。
• [C-SR-8] 强烈建议具有小于 10% 的错误拒绝率，在设备上测量。
• [C-SR-9] 强烈建议对于每个注册的生物识别技术，从检测到生物识别技术到屏幕解锁的延迟低于 1 秒。
• [C-1-12] 必须具有不高于 40% 每演示攻击工具 (PAI) 物种的欺骗和冒名顶替接受率，如 Android 生物识别测试协议 所测量。
• [C-SR-13] 强烈建议具有不高于 30% 每演示攻击工具 (PAI) 物种的欺骗和冒名顶替接受率，如 Android 生物识别测试协议 所测量。
• [C-SR-8] 强烈建议具有小于 10% 的错误拒绝率，在设备上测量。

Android 15 的新增要求开始

• [C-SR-14] 强烈建议披露生物识别传感器的生物识别类别以及启用它的相应风险。

• [C-SR-17] 强烈建议实现新的 AIDL 接口（例如，IFace.aidl 和 IFingerprint.aidl）。

如果设备实现希望将生物识别传感器视为 Class 2（以前的 Weak），则它们

• [C-2-1] 必须满足上述 Class 1 的所有要求。
• [C-2-2] 必须具有不高于 20% 的欺骗和冒名顶替接受率，其中 (1) A 级演示攻击工具 (PAI) 物种的欺骗和冒名顶替接受率不高于 20%，以及 (2) B 级 PAI 物种的欺骗和冒名顶替接受率不高于 30%，如 Android 生物识别测试协议 所测量。
• [C-SR-15] 强烈建议具有不高于 20% 每演示攻击工具 (PAI) 物种的欺骗和冒名顶替接受率，如 Android 生物识别测试协议 所测量。
• [C-2-3] 必须在 Android 用户或内核空间之外的隔离执行环境中执行生物识别匹配，例如可信执行环境 (TEE)，在具有与隔离执行环境的安全通道的芯片上，或在满足第 9.17 节要求的受保护虚拟机上。
• [C-2-4] 必须对所有可识别数据进行加密和密码学身份验证，以便它们无法在隔离执行环境之外或具有与隔离执行环境的安全通道的芯片之外获取、读取或更改，如 Android 开源项目站点上的 实施指南 或满足第 9.17 节要求的虚拟机中所述。
• [C-2-5] 对于基于摄像头的生物识别技术，在发生基于生物识别的身份验证或注册时
  • 必须在一种模式下操作摄像头，以防止摄像头帧在隔离执行环境之外或具有与隔离执行环境的安全通道的芯片之外或满足第 9.17 节要求的受保护虚拟机之外被读取或更改。
  • 对于 RGB 单摄像头解决方案，摄像头帧可以在隔离执行环境外部读取，以支持注册预览等操作，但仍然必须不可更改。
• [C-2-6] 不得允许第三方应用程序区分单个生物识别注册。
• [C-2-7] 不得允许在 TEE 或满足第 9.17 节要求的虚拟机上下文之外，在应用程序处理器上对可识别生物识别数据或从中派生的任何数据（例如嵌入）进行未加密访问。在 Android 版本 9 或更早版本上启动的升级设备不免除 C-2-7。

• [C-2-8] 必须具有安全的处理管道，以便操作系统或内核遭到破坏时无法直接注入数据以错误地验证为用户。注意：如果设备实现已在 Android 版本 9 或更早版本上启动，并且无法通过系统软件更新满足 C-2-8 要求，则它们可以免除此要求。

• [C-SR-10] 强烈建议为所有生物识别方式包含活体检测，并为面部生物识别包含注意力检测。

• [C-2-9] 必须使生物识别传感器可供第三方应用程序使用。

如果设备实现希望将生物识别传感器视为 Class 3（以前的 Strong），则它们

• [C-3-1] 必须满足上述 Class 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] 如果重新注册任何 Class 3 生物识别技术，则必须为设备上支持的所有 Class 3 生物识别技术重新生成 Authenticator ID。
• [C-3-6] 必须允许第三方应用程序使用生物识别支持的密钥库密钥。

• [C-SR-16] 强烈建议具有不高于 7% 每演示攻击工具 (PAI) 物种的欺骗和冒名顶替接受率，如 Android 生物识别测试协议 所测量。

如果设备实现包含屏下指纹传感器 (UDFPS)，则它们

• [C-SR-11] 强烈建议防止 UDFPS 的可触摸区域干扰 3 按钮导航（某些用户可能出于辅助功能目的而需要）。

7.3.11. 姿势传感器

设备实现

• 可以支持具有 6 自由度的姿势传感器。

如果设备实现支持具有 6 自由度的姿势传感器，则它们

• [C-1-1] 必须实现并报告 TYPE_POSE_6DOF 传感器。
• [C-1-2] 必须比单独的旋转矢量更准确。

7.3.12. 铰链角度传感器

如果设备实现支持铰链角度传感器，则它们

• [C-1-1] 必须实现并报告 TYPE_HINGLE_ANGLE。
• [C-1-2] 必须支持 0 到 360 度（包括 0 和 360 度）之间的至少两个读数。
• [C-1-3] 必须为 getDefaultSensor(SENSOR_TYPE_HINGE_ANGLE) 返回一个 wakeup 传感器。

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 无线电的应用程序持有 UWB_RANGING 权限（在 NEARBY_DEVICES 权限组下）。

通过标准组织（包括 FIRA、CCC 和 CSA）定义的相关一致性和认证测试，有助于确保 802.1.15.4 功能正常运行。

7.4. 数据连接

7.4.1. 电话

Android API 和本文档中使用的“电话”特指与拨打语音电话和发送 SMS 消息，或通过移动（例如 GSM、CDMA、LTE、NR）GSM 或 CDMA 网络建立移动数据相关的硬件。支持“电话”的设备可以选择提供部分或全部通话、消息和数据服务，以适应产品。

• 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 功能，则它们

• [C-3-1] 必须声明 android.hardware.telephony.euicc 功能标志。

如果设备实现未将系统属性 ro.telephony.iwlan\_operation\_mode 设置为“legacy”，则它们

• [C-4-1] 禁止通过 NetworkRegistrationInfo#getAccessNetworkTechnology() 报告 'NETWORK_TYPE_IWLAN'，当 NetworkRegistrationInfo#getTransportType() 对于同一个 NetworkRegistrationInfo 实例报告为 'TRANSPORT_TYPE_WWAN' 时。

如果设备实现支持多媒体电话服务 (MMTEL) 和富通信服务 (RCS) 功能的单个 IP 多媒体子系统 (IMS) 注册，并且期望符合蜂窝运营商关于对所有 IMS 信令流量使用单个 IMS 注册的要求，则它们

• [C-5-1] 必须声明 android.hardware.telephony.ims 功能标志，并为 MMTEL 和 RCS 用户能力交换 API 提供完整的 ImsService API 实现。
• [C-5-2] 必须声明 android.hardware.telephony.ims.singlereg 功能标志，并提供 SipTransport API、GbaService API、使用 IRadio 1.6 HAL 的专用承载指示以及通过自动配置服务器 (ACS) 或其他专有配置机制使用 IMS 配置 API 的完整实现。

如果设备实现报告了 android.hardware.telephony 功能，则

• [C-6-1] SmsManager#sendTextMessage 和 SmsManager#sendMultipartTextMessage 必须导致对 CarrierMessagingService 的相应调用，以提供短信功能。SmsManager#sendMultimediaMessage 和 SmsManager#downloadMultimediaMessage 必须导致对 CarrierMessagingService 的相应调用，以提供多媒体消息功能。
• [C-6-2] 由 android.provider.Telephony.Sms#getDefaultSmsPackage 指定的应用程序在发送和接收 SMS 和 MMS 消息时必须使用 SmsManager API。packages/apps/Messaging 中的 AOSP 参考实现满足此要求。
• [C-6-3] 响应 Intent#ACTION_DIAL 的应用程序必须支持输入格式为 *#*#CODE#*#* 的任意拨号器代码，并触发相应的 TelephonyManager#ACTION_SECRET_CODE 广播。
• [C-6-4] 响应 Intent#ACTION_DIAL 的应用程序如果支持可视语音邮件转录，必须使用 VoicemailContract.Voicemails#TRANSCRIPTION 向用户显示可视语音邮件转录。
• [C-6-5] 必须将所有具有等效 group UUID 的 SubscriptionInfo 表示为所有用户可见的配置（用于显示和控制 SIM 卡信息）中的单个订阅。此类配置的示例包括与 Settings#ACTION_MANAGE_ALL_SIM_PROFILES_SETTINGS 或 EuiccManager#ACTION_MANAGE_EMBEDDED_SUBSCRIPTIONS 匹配的设置界面。
• [C-6-6] 禁止在任何允许配置或控制 SIM 卡设置的用户可见的配置中显示或允许控制具有非空 group UUID 和 opportunistic bit 的任何 SubscriptionInfo。

如果设备实现报告了 android.hardware.telephony 功能并提供系统状态栏，则

• [C-7-1] 必须为给定的 group 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 功能，并且共享 group UUID 的所有活动的非机会主义订阅 被禁用、从设备物理移除或标记为机会主义，则设备

• [C-8-1] 必须自动禁用同一组中的所有剩余活动机会主义订阅。

如果设备实现包括 GSM 电话，但不包括 CDMA 电话，则它们

• [C-9-1] 禁止声明 PackageManager#FEATURE_TELEPHONY_CDMA。
• [C-9-2] 在尝试在首选或允许的网络类型位掩码中设置任何 3GPP2 网络类型时，必须抛出 IllegalArgumentException。
• [C-9-3] 必须从 TelephonyManager#getMeid 返回空字符串。

如果设备实现支持具有多个端口和配置文件的 eUICC，则它们

• [C-10-1] 必须声明 android.hardware.telephony.euicc.mep 功能标志。

7.4.1.1. 号码阻止兼容性

如果设备实现报告了 android.hardware.telephony.calling 功能，则它们

• [C-1-1] 必须包含号码阻止支持
• [C-1-2] 必须完全实现 BlockedNumberContract 和 SDK 文档中描述的相应 API。

• [C-1-3] 必须阻止来自 'BlockedNumberProvider' 中电话号码的所有呼叫和消息，而无需与应用进行任何交互。唯一的例外是当号码阻止被临时解除时，如 SDK 文档中所述。

• [C-1-4] 必须为被阻止的呼叫写入 平台呼叫日志提供程序，并且必须在预安装的拨号器应用中的默认呼叫日志视图中过滤掉具有 BLOCKED_TYPE 的呼叫。

• [C-1-5] 禁止为被阻止的消息写入 Telephony provider。

• [C-1-6] 必须实现一个被阻止号码管理 UI，该 UI 通过 TelecomManager.createManageBlockedNumbersIntent() 方法返回的 intent 打开。

• [C-1-7] 禁止允许辅助用户查看或编辑设备上的被阻止号码，因为 Android 平台假定主要用户对设备上的电话服务（单个实例）具有完全控制权。所有与阻止相关的 UI 必须对辅助用户隐藏，并且仍必须遵守阻止列表。

• 应该在设备更新到 Android 7.0 时将阻止的号码迁移到提供程序中。

• 应该提供用户配置，以在预安装的拨号器应用中显示被阻止的呼叫。

7.4.1.2. 电信 API

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

• [C-1-1] 必须支持 SDK 中描述的 ConnectionService API。
• [C-1-2] 当用户正在进行由不支持通过 CAPABILITY_SUPPORT_HOLD 指定的保持功能的第三方应用发起的正在进行的呼叫时，必须显示新的来电并提供用户配置来接受或拒绝来电。
• [C-1-3] 必须有一个实现 InCallService 的应用程序。

• [C-SR-1] 强烈建议通知用户，接听来电将断开正在进行的呼叫。

  AOSP 实现通过抬头通知满足这些要求，该通知向用户指示接听来电将导致另一个呼叫被断开。

• [C-SR-2] 强烈建议预加载默认拨号器应用，当第三方应用在其 PhoneAccount 上将 EXTRA_LOG_SELF_MANAGED_CALLS 额外键设置为 true 时，该应用会在其呼叫日志中显示呼叫日志条目和第三方应用的名称。

• [C-SR-3] 强烈建议处理音频耳机的 KEYCODE_MEDIA_PLAY_PAUSE 和 KEYCODE_HEADSETHOOK 事件，用于 android.telecom API，如下所示

  • 在正在进行的呼叫期间检测到按键事件的短按时，调用 Connection.onDisconnect()。
  • 在来电期间检测到按键事件的短按时，调用 Connection.onAnswer()。
  • 在来电期间检测到按键事件的长按时，调用 Connection.onReject()。
  • 切换 CallAudioState 的静音状态。

7.4.1.3. 蜂窝 NAT-T Keepalive 卸载

设备实现

• 应该包含对蜂窝 keepalive 卸载的支持。

如果设备实现包括对蜂窝 keepalive 卸载的支持并将该功能公开给第三方应用，则它们

• [C-1-1] 必须支持 SocketKeepAlive API。
• [C-1-2] 必须支持蜂窝上至少一个并发 keepalive 插槽。
• [C-1-3] 必须支持与蜂窝无线 HAL 支持的并发蜂窝 keepalive 插槽数量一样多的插槽。
• [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] 必须实现 multicast API，如 SDK 文档中所述。

• [C-1-4] 必须支持 mDNS，并且在任何操作时间（包括屏幕未处于活动状态时）都禁止过滤 mDNS 数据包（224.0.0.251 或 ff02::fb），除非未持有多播锁定并且数据包被 APF 过滤。不要求数据包满足当前应用程序通过 NsdManager API 请求的任何 mDNS 操作。但是，如果过滤 mDNS 数据包对于保持在目标市场适用的法规要求所需的功耗范围内是必要的，则设备可以过滤 mDNS 数据包。

• [C-1-5] 禁止将 WifiManager.enableNetwork() API 方法调用视为足以切换当前活动的 Network，该 Network 默认用于应用程序流量，并由 ConnectivityManager API 方法（如 getActiveNetwork 和 registerDefaultNetworkCallback）返回。换句话说，它们可以仅在成功验证 Wi-Fi 网络提供互联网访问后，才禁用任何其他网络提供商（例如移动数据）提供的互联网访问。

• [C-1-6] 强烈建议在调用 ConnectivityManager.reportNetworkConnectivity() API 方法时，重新评估 Network 上的互联网访问，并且一旦评估确定当前 Network 不再提供互联网访问，则切换到任何其他可用的网络（例如移动数据），以提供互联网访问。

• [C-1-7] 必须在每次扫描开始时随机化探测请求帧的源 MAC 地址和序列号，当 STA 断开连接时。

• [C-1-8] 必须使用一个一致的 MAC 地址（不应在扫描中途随机化 MAC 地址）。

• [C-1-9] 必须在扫描中的探测请求之间正常（顺序地）迭代探测请求序列号。

• [C-1-10] 必须在扫描的最后一个探测请求和下一次扫描的第一个探测请求之间随机化探测请求序列号。

• [C-SR-1] 强烈建议在关联和关联期间，随机化用于所有 STA 通信到接入点 (AP) 的源 MAC 地址。

  • 设备必须为与其通信的每个 SSID（Passpoint 的 FQDN）使用不同的随机 MAC 地址。
  • 设备必须为用户提供一个选项来控制每个 SSID（Passpoint 的 FQDN）的随机化，选项包括非随机和随机，并且必须将新 Wi-Fi 配置的默认模式设置为随机。

• [C-SR-2] 强烈建议为他们创建的任何 AP 使用随机 BSSID。

  • MAC 地址必须被随机化，并持久化到 AP 使用的每个 SSID。
  • 设备可以为用户提供禁用此功能的选项。如果提供此类选项，则必须默认启用随机化。

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

• 应该在应用通过 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 进行位置扫描，则它们

• [C-2-1] 必须提供用户配置，以启用/禁用通过 WifiManager.isScanAlwaysAvailable API 方法读取的值。

7.4.2.1. Wi-Fi Direct

设备实现

• 应该包含对 Wi-Fi Direct（Wi-Fi 对等网络）的支持。

如果设备实现包括对 Wi-Fi Direct 的支持，则它们

• [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 Direct 操作。
• [C-SR-1] 强烈建议为所有新形成的 Wi-Fi Direct 连接随机化源 MAC 地址。

7.4.2.2. Wi-Fi 隧道直接链路设置

设备实现

• 应该包含对 Wi-Fi 隧道直接链路设置 (TDLS) 的支持，如 Android SDK 文档中所述。

如果设备实现包括对 TDLS 的支持并且通过 WiFiManager API 启用了 TDLS，则它们

• [C-1-1] 必须通过 WifiManager.isTdlsSupported 声明对 TDLS 的支持。
• 应该仅在可能且有利时使用 TDLS。
• 应该有一些启发式方法，并且当 TDLS 的性能可能比通过 Wi-Fi 接入点更差时，不应使用 TDLS。

7.4.2.3. Wi-Fi Aware

设备实现

• 应该包含对 Wi-Fi Aware 的支持。

如果设备实现包括对 Wi-Fi Aware 的支持并将该功能公开给第三方应用，则它们

• [C-1-1] 必须实现 WifiAwareManager API，如 SDK 文档中所述。
• [C-1-2] 必须声明 android.hardware.wifi.aware 功能标志。
• [C-1-3] 必须同时支持 Wi-Fi 和 Wi-Fi Aware 操作。
• [C-1-4] 必须在不超过 30 分钟的间隔内以及每次启用 Wi-Fi Aware 时随机化 Wi-Fi Aware 管理接口地址，除非正在进行 Aware 测距操作或 Aware 数据路径处于活动状态（只要数据路径处于活动状态，就不需要随机化）。

如果设备实现包括对 Wi-Fi Aware 和 第 7.4.2.5 节中描述的 Wi-Fi 位置的支持，并将这些功能公开给第三方应用，则它们

• [C-2-1] 必须实现位置感知发现 API：setRangingEnabled、setMinDistanceMm、setMaxDistanceMm 和 onServiceDiscoveredWithinRange。

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 位置的支持。

如果设备实现包括对 Wi-Fi 位置的支持并将该功能公开给第三方应用，则它们

• [C-1-1] 必须实现 WifiRttManager API，如 SDK 文档中所述。
• [C-1-2] 必须声明 android.hardware.wifi.rtt 功能标志。
• [C-1-3] 必须为每个 RTT 突发随机化源 MAC 地址，该突发在执行 RTT 的 Wi-Fi 接口未关联到接入点时执行。
• [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 卸载的支持，则它们

• [C-2-1] 必须返回 ERROR_UNSUPPORTED。

7.4.2.7. Wi-Fi Easy Connect（设备配置协议）

设备实现

• 应该包含对 Wi-Fi Easy Connect (DPP) 的支持。

如果设备实现包含对 Wi-Fi Easy Connect 的支持并将功能公开给第三方应用程序，则它们

• [C-1-1] 必须使 WifiManager#isEasyConnectSupported() 方法返回 true。

7.4.2.8. 企业 Wi-Fi 服务器证书验证

如果未验证 Wi-Fi 服务器证书或未设置 Wi-Fi 服务器域名，则设备实现

• [C-SR-1] 强烈建议不为用户提供在“设置”应用中手动添加 企业 Wi-Fi 网络 的选项。

7.4.2.9. 首次使用信任 (TOFU)

如果设备实现支持首次使用信任 (TOFU) 并允许用户定义 WPA/WPA2/WPA3-企业配置，则它们

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

• 应该在实现 ScanFilter API 时，支持将过滤逻辑卸载到蓝牙芯片组。

• 应该支持将批量扫描卸载到蓝牙芯片组。

• 应该支持至少 4 个插槽的多重广播。

如果设备实现支持低功耗蓝牙 LE 并使用低功耗蓝牙 LE 进行位置扫描，则它们

• [C-4-1] 必须提供用户配置，以启用/禁用通过系统 API BluetoothAdapter.isBleScanAlwaysAvailable() 读取的值。

如果设备实现包括对低功耗蓝牙 LE 和助听器配置文件的支持，如 使用低功耗蓝牙的助听器音频支持 中所述，则它们

• [C-5-1] 对于 BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID)，必须返回 true。

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

• [C-6-1] 禁止限制访问任何蓝牙元数据（例如扫描结果），这些元数据可能用于推断设备的位置，除非请求的应用根据其当前前台/后台状态成功通过了 android.permission.ACCESS_FINE_LOCATION 权限检查。

如果设备实现包括对蓝牙或低功耗蓝牙的支持，并且应用清单不包含来自开发者的声明，声明他们没有从蓝牙中推断位置，那么，它们

• [C-6-2] 必须使用 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] 必须确保 RSSI 测量值在视距环境中，在距参考设备 1 米距离且以 ADVERTISE_TX_POWER_HIGH 发射功率发射时，95% 的测量值在 +/-9dB 范围内。
• [C-10-2] 必须包含 Rx/Tx 校正，以减少每通道偏差，从而使每个天线（如果使用多个天线）上 3 个通道中的每一个通道的测量值在 95% 的测量值中彼此相差 +/-3dB。
• [C-SR-2] 强烈建议测量并补偿 Rx 偏移，以确保在距参考设备 1 米距离且以 ADVERTISE_TX_POWER_HIGH 发射功率发射时，中值 BLE RSSI 为 -60dBm +/-10 dB，其中设备的朝向应使其位于“平行平面”上，屏幕朝向同一方向。
• [C-SR-3] 强烈建议测量并补偿 Tx 偏移，以确保当从位于 1 米距离且以 ADVERTISE_TX_POWER_HIGH 发射功率发射的参考设备进行扫描时，中值 BLE RSSI 为 -60dBm +/-10 dB，其中设备的朝向应使其位于“平行平面”上，屏幕朝向同一方向。

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

7.4.4. 近场通信

设备实现

• 应该包括用于近场通信 (NFC) 的收发器和相关硬件。
• [C-0-1] 即使设备不包含对 NFC 的支持或未声明 android.hardware.nfc 功能，也必须实现 android.nfc.NdefMessage 和 android.nfc.NdefRecord API，因为这些类代表与协议无关的数据表示格式。

如果设备实现包括 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 条形码产品的条形码和 URL（如果已编码）。

请注意，上面引用的 JIS、ISO 和 NFC Forum 规范的公开链接不可用。

Android 包括对 NFC 主机卡模拟 (HCE) 模式的支持。

如果设备实现包括能够进行 HCE（用于 NfcA 和/或 NfcB）并支持应用 ID (AID) 路由的 NFC 控制器芯片组，则它们

• [C-2-1] 必须报告 android.hardware.nfc.hce 功能常量。
• [C-2-2] 必须支持 Android SDK 中定义的 NFC HCE API。

如果设备实现包括能够进行 NfcF 的 HCE 的 NFC 控制器芯片组，并为第三方应用程序实现该功能，则它们

• [C-3-1] 必须报告 android.hardware.nfc.hcef 功能常量。
• [C-3-2] 必须实现 Android SDK 中定义的 NfcF 卡模拟 API。

如果设备实现在本节中描述的包括通用 NFC 支持，并在读取器/写入器角色中支持 MIFARE 技术（MIFARE Classic、MIFARE Ultralight、NDEF on MIFARE Classic），则它们

• [C-4-1] 必须实现 Android SDK 记录的相应 Android API。
• [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/秒或更高速度的数据标准的支持。满足此要求的技术示例包括 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] 必须在 Doze 模式下保持 IPv6 连接。
    • [C-0-5] 速率限制不得导致设备在任何使用至少 180 秒 RA 生存期的兼容 IPv6 网络上丢失 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 操作。

如果设备实现支持以太网，则它们

• [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] 必须提供一个强制门户应用程序来处理 intent ACTION_CAPTIVE_PORTAL_SIGN_IN，并通过在调用 System 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 网络 API（如 java.net.Socket）和本机 API（如 connect()）默认使用）是任何其他可用的提供互联网访问的网络（如果可用）。

7.4.6. 同步设置

设备实现

• [C-0-1] 必须默认启用主自动同步设置，以便方法 getMasterSyncAutomatically() 返回 "true"。

7.4.7. 流量节省程序

如果设备实现包括按流量计费的连接，则它们

• [C-SR-1] 强烈建议提供流量节省程序模式。

如果设备实现提供数据保护程序模式，则它们

• [C-1-1] 必须支持 ConnectivityManager 类中的所有 API，如 SDK 文档中所述

如果设备实现不提供数据保护程序模式，则它们

• [C-2-1] 必须为 ConnectivityManager.getRestrictBackgroundStatus() 返回值 RESTRICT_BACKGROUND_STATUS_DISABLED
• [C-2-2] 不得广播 ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED。

7.4.8. 安全元件

如果设备实现支持 Open Mobile API 兼容的安全元件并向第三方应用开放，则它们

• [C-1-1] 必须通过 android.se.omapi.SEService.getReaders() API 枚举可用的安全元件读取器。

• [C-1-2] 必须通过 android.hardware.se.omapi.uicc 为具有基于 UICC 的安全元件的设备、android.hardware.se.omapi.ese 为具有基于 eSE 的安全元件的设备以及 android.hardware.se.omapi.sd 为具有基于 SD 的安全元件的设备声明正确的功能标志。

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 无线电的应用程序持有 UWB_RANGING 权限（在 NEARBY_DEVICES 权限组下）。
• [C-SR-1] 强烈建议通过标准组织（包括 FIRA、CCC 和 CSA）定义的相关一致性和认证测试。
• [C-1-6] 必须确保在非反射室中，在 1 米距离的视距环境下，95% 的距离测量值在 +/-15 厘米范围内。
• [C-1-7] 必须确保距参考设备 1 米距离的距离测量值的中值在 [0.75 米，1.25 米] 范围内，其中实际距离是从 DUT 的顶边测量的。
• [C-SR-2] 强烈建议遵循存在校准要求中指定的测量设置步骤。

7.5. 相机

如果设备实现包括至少一个相机，则它们

• [C-1-1] 必须声明 android.hardware.camera.any 功能标志。
• [C-1-2] 必须允许应用程序在相机打开以进行基本预览和静止图像捕获时，同时分配 3 个 RGBA_8888 位图，其大小等于设备上最大分辨率相机传感器生成的图像大小。
• [C-1-3] 必须确保预安装的默认相机应用程序在处理 intent MediaStore.ACTION_IMAGE_CAPTURE、MediaStore.ACTION_IMAGE_CAPTURE_SECURE 或 MediaStore.ACTION_VIDEO_CAPTURE 时，在将用户位置信息发送到接收应用程序之前，删除图像元数据中的用户位置信息，当接收应用程序没有 ACCESS_FINE_LOCATION 权限时。

如果设备实现支持 HDR 10 位输出能力，则它们

• [C-2-1] 对于每个支持 10 位输出的相机设备，必须至少支持 HLG HDR 配置文件。
• [C-2-2] 必须为主要后置摄像头或主要前置摄像头支持 10 位输出。
• [C-SR-1] 强烈建议为主要前后摄像头都支持 10 位输出。
• [C-2-3] 必须为逻辑相机的向后兼容物理子相机和逻辑相机本身支持相同的 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] 当在相机预览表面上注册了 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] 必须以与相机预览图像流相同的方式镜像后视图显示的图像。
• 可以包括 第 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 视频类 (UVC 1.0 或更高版本)。
• [C-1-3] 必须在连接物理外部相机设备的情况下通过相机 CTS 测试。相机 CTS 测试的详细信息可在 source.android.com 上找到。
• 应该支持视频压缩，例如 MJPEG，以实现高质量未编码流（即原始或独立压缩的图片流）的传输。
• 可以支持多个相机。
• 可以支持基于相机的视频编码。

如果支持基于相机的视频编码

• [C-2-1] 设备实现必须可访问同步的未编码/MJPEG 流（QVGA 或更高分辨率）。

7.5.4. 相机 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.Camera.Parameters.setPreviewFormat(int) 时，必须使用 android.hardware.PixelFormat.YCbCr_420_SP 作为提供给应用程序回调的预览数据。
• [C-0-2] 当应用程序注册 android.hardware.Camera.PreviewCallback 实例并且系统调用 onPreviewFrame() 方法且预览格式为 YCbCr_420_SP 时，在传递到 onPreviewFrame() 的 byte[] 中的数据必须进一步采用 NV21 编码格式。也就是说，NV21 必须是默认格式。
• [C-0-3] 必须支持 YV12 格式（由 android.graphics.ImageFormat.YV12 常量表示）用于 android.hardware.Camera 的前置和后置相机的相机预览。（硬件视频编码器和相机可以使用任何本机像素格式，但设备实现必须支持转换为 YV12。）
• [C-0-4] 对于广告 REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE 功能（在 android.request.availableCapabilities 中）的 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 SDK 中描述的 android.info.supportedHardwareLevel 属性报告正确的支持级别，并报告相应的 框架功能标志。
• [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，则它们

• [C-1-1] 必须使用 android.hardware.camera2 API 实现此类相机 API。
• 可以为 android.hardware.camera2 API 提供供应商标签和/或扩展。

7.5.5. 相机方向

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

• [C-1-1] 必须定向，使相机的长尺寸与屏幕的长尺寸对齐。也就是说，当设备以横向方向握持时，相机必须以横向方向捕获图像。这适用于设备的自然方向，即适用于横向主设备以及纵向主设备。

满足以下所有标准的设备可免除上述要求

• 设备实现可变几何形状屏幕，例如可折叠或铰链式显示屏。
• 当设备的折叠或铰链状态更改时，设备会在纵向主方向和横向主方向（或反之亦然）方向之间切换。
• 无法由用户旋转的设备实现，例如汽车设备。

7.6. 内存和存储

7.6.1. 最低内存和存储

设备实现

• [C-0-1] 必须包括 下载管理器，应用程序可以使用它来下载数据文件，并且它们必须能够下载至少 100MB 大小的单个文件到默认的“缓存”位置。

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] 当插槽中未插入存储介质时，必须实现 toast 或弹出式用户界面警告用户。
• [C-1-2] 必须包括 FAT 格式的存储介质（例如 SD 卡），或在包装盒和购买时可用的其他材料上显示存储介质必须单独购买。

如果设备实现使用不可移动存储的一部分来满足上述要求，则它们

• 应该使用内部应用程序共享存储的 AOSP 实现。
• 可以与应用程序私有数据共享存储空间。

如果设备实现具有支持 USB 外围设备模式的 USB 端口，则它们

• [C-3-1] 必须提供一种机制，以便从主机计算机访问应用程序共享存储上的数据。
• 应该通过 Android 的媒体扫描器服务和 android.provider.MediaStore 透明地公开来自两个存储路径的内容。
• 可以使用 USB 大容量存储，但应该使用媒体传输协议来满足此要求。

如果设备实现具有支持 USB 外围设备模式和媒体传输协议的 USB 端口，则它们

• 应该与参考 Android MTP 主机 Android File Transfer 兼容。
• SHOULD 报告 USB 设备类别为 0x00。
• SHOULD 报告 USB 接口名称为 “MTP”。

7.6.3. 可采纳的存储设备

如果设备预计本质上是移动设备，而非电视等设备，则设备实现应

• [C-SR-1] 强烈建议在长期稳定的位置实现可采纳的存储设备，因为意外断开连接可能会导致数据丢失/损坏。

如果可移动存储设备端口位于长期稳定的位置，例如在电池仓或其他保护盖内，则设备实现应

• [C-SR-2] 强烈建议实现可采纳的存储设备。

7.7. USB

如果设备实现具有 USB 端口，则它们应

• SHOULD 支持 USB 外围设备模式，并且 SHOULD 支持 USB 主机模式。
• SHOULD 支持禁用通过 USB 的数据信号传输。

7.7.1. USB 外围设备模式

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

• [C-1-1] 该端口 MUST 可连接到具有标准 Type-A 或 Type-C USB 端口的 USB 主机。
• [C-1-2] MUST 通过 android.os.Build.SERIAL 在 USB 标准设备描述符中报告正确的 iSerialNumber 值。
• [C-1-3] 如果设备实现支持 Type-C USB，则 MUST 按照 Type-C 电阻标准检测 1.5A 和 3.0A 充电器，并且 MUST 检测广告中的更改。
• [C-SR-1] 该端口 SHOULD 使用 micro-B、micro-AB 或 Type-C USB 外形尺寸。强烈建议现有和新的 Android 设备满足这些要求，以便它们能够升级到未来的平台版本。
• [C-SR-2] 该端口 SHOULD 位于设备底部（根据自然方向）或为所有应用（包括主屏幕）启用软件屏幕旋转，以便在设备方向为端口位于底部时，显示器能够正确绘制。强烈建议现有和新的 Android 设备满足这些要求，以便它们能够升级到未来的平台版本。
• [C-SR-3] SHOULD 实现支持在 HS 啁啾和流量期间汲取 1.5 A 电流，如 USB 电池充电规范，修订版 1.2 中所规定。强烈建议现有和新的 Android 设备满足这些要求，以便它们能够升级到未来的平台版本。
• [C-SR-4] 强烈建议不要支持超出默认级别的 Vbus 电压或更改接收器/源角色的专有充电方法，因为这可能会导致与支持标准 USB Power Delivery 方法的充电器或设备出现互操作性问题。虽然这被称为“强烈建议”，但在未来的 Android 版本中，我们可能会要求所有 Type-C 设备完全支持与标准 Type-C 充电器的互操作性。
• [C-SR-5] 强烈建议在支持 Type-C USB 和 USB 主机模式时，支持 Power Delivery 以进行数据和电源角色交换。
• SHOULD 支持 Power Delivery 以进行高压充电，并支持显示输出等备用模式。
• SHOULD 实现 Android Open Accessory (AOA) API 和规范，如 Android SDK 文档中所述。

如果设备实现包含 USB 端口并实现 AOA 规范，则它们

• [C-2-1] MUST 声明支持硬件功能 android.hardware.usb.accessory。
• [C-2-2] USB 大容量存储类 MUST 在 USB 大容量存储的接口描述 iInterface 字符串的末尾包含字符串 “android”。

7.7.2. USB 主机模式

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

• [C-1-1] MUST 实现 Android USB 主机 API，如 Android SDK 中所述，并且 MUST 声明支持硬件功能 android.hardware.usb.host。
• [C-1-2] MUST 实现支持连接标准 USB 外围设备，换句话说，它们 MUST 满足以下任一条件：
  • 具有设备上的 Type-C 端口，或随附将设备上的专有端口适配到标准 USB Type-C 端口的线缆（USB Type-C 设备）。
  • 具有设备上的 Type-A 端口，或随附将设备上的专有端口适配到标准 USB Type-A 端口的线缆。
  • 具有设备上的 micro-AB 端口，该端口 SHOULD 随附将端口适配到标准 Type-A 端口的线缆。
• [C-1-3] MUST NOT 随附将 USB Type-A 或 micro-AB 端口转换为 Type-C 端口（插座）的适配器。
• [C-SR-1] 强烈建议实现 USB 音频类，如 Android SDK 文档中所述。
• SHOULD 支持在主机模式下为连接的 USB 外围设备充电；对于 USB Type-C 连接器，应宣传至少 1.5A 的源电流，如 USB Type-C 线缆和连接器规范修订版 1.2 的“终端参数”部分中所述，或对于 Micro-AB 连接器，应使用 USB 电池充电规范，修订版 1.2 中规定的充电下游端口 (CDP) 输出电流范围。
• SHOULD 实现并支持 USB Type-C 标准。

如果设备实现包含支持主机模式和 USB 音频类的 USB 端口，则它们

• [C-2-1] MUST 支持 USB HID 类。
• [C-2-2] MUST 支持检测和映射 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] MUST 识别任何远程连接的 MTP（媒体传输协议）设备，并通过 ACTION_GET_CONTENT、ACTION_OPEN_DOCUMENT 和 ACTION_CREATE_DOCUMENT intent 使其内容可访问。

如果设备实现包含支持主机模式和 USB Type-C 的 USB 端口，则它们

• [C-4-1] MUST 实现 USB Type-C 规范（第 4.5.1.3.3 节）定义的双重角色端口功能。对于双重角色端口，在包含 3.5 毫米音频插孔的设备上，USB 接收器检测（主机模式）MAY 默认关闭，但用户必须能够启用它。
• [C-SR-2] 强烈建议支持 DisplayPort，SHOULD 支持 USB SuperSpeed 数据速率，并且强烈建议支持 Power Delivery 以进行数据和电源角色交换。
• [C-SR-3] 强烈建议不要支持 USB Type-C 线缆和连接器规范修订版 1.2 附录 A 中描述的音频适配器配件模式。
• SHOULD 实现最适合设备外形尺寸的 Try.* 模型。例如，手持设备 SHOULD 实现 Try.SNK 模型。

7.8. 音频

7.8.1. 麦克风

如果设备实现包含麦克风，则它们

• [C-1-1] MUST 报告 android.hardware.microphone 功能常量。
• [C-1-2] MUST 满足第 5.4 节中的音频录制要求。
• [C-1-3] MUST 满足第 5.6 节中的音频延迟要求。
• [C-SR-1] 强烈建议支持近超声录音，如第 7.8.3 节中所述。

如果设备实现省略了麦克风，则它们

• [C-2-1] MUST NOT 报告 android.hardware.microphone 功能常量。
• [C-2-2] MUST 至少将音频录制 API 实现为无操作，根据第 7 节。

7.8.2. 音频输出

如果设备实现包含扬声器或用于音频输出外围设备的音频/多媒体输出端口，例如 4 芯 3.5 毫米音频插孔或使用 USB 音频类 的 USB 主机模式端口，则它们

• [C-1-1] MUST 报告 android.hardware.audio.output 功能常量。
• [C-1-2] MUST 满足第 5.5 节中的音频播放要求。
• [C-1-3] MUST 满足第 5.6 节中的音频延迟要求。
• [C-SR-1] 强烈建议支持近超声播放，如第 7.8.3 节中所述。

如果设备实现不包含扬声器或音频输出端口，则它们

• [C-2-1] MUST NOT 报告 android.hardware.audio.output 功能。
• [C-2-2] MUST 至少将音频输出相关 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] MUST 支持音频播放到立体声耳机和带有麦克风的立体声耳机。
• [C-1-2] MUST 支持具有 CTIA 引脚排列顺序的 TRRS 音频插头。
• [C-1-3] MUST 支持检测和映射到以下 3 个阻抗范围的键码，这些阻抗范围是音频插头上麦克风和接地导体之间的等效阻抗：
  • 70 欧姆或更小：KEYCODE_HEADSETHOOK
  • 210-290 欧姆：KEYCODE_VOLUME_UP
  • 360-680 欧姆：KEYCODE_VOLUME_DOWN
• [C-1-4] MUST 在插入插头时触发 ACTION_HEADSET_PLUG，但仅在插头上的所有触点都接触到插孔上的相关段后。
• [C-1-5] MUST 能够驱动 32 欧姆扬声器阻抗上至少 150mV ± 10% 的输出电压。
• [C-1-6] MUST 具有介于 1.8V ~ 2.9V 之间的麦克风偏置电压。
• [C-1-7] MUST 检测并映射到以下阻抗范围的键码，该阻抗范围是音频插头上麦克风和接地导体之间的等效阻抗：
  • 110-180 欧姆： KEYCODE_VOICE_ASSIST
• [C-SR-2] 强烈建议支持具有 OMTP 引脚排列顺序的音频插头。
• [C-SR-3] 强烈建议支持从带有麦克风的立体声耳机进行音频录制。

如果设备实现具有 4 芯 3.5 毫米音频插孔并支持麦克风，并且广播带有额外值 microphone 设置为 1 的 android.intent.action.HEADSET_PLUG，则它们

• [C-2-1] MUST 支持检测插入的音频配件上的麦克风。

7.8.2.2. 数字音频端口

有关设备特定要求，请参阅第 2.2.1 节。

7.8.3. 近超声

近超声音频是指 18.5 kHz 至 20 kHz 频段。

设备实现

• MUST 通过 AudioManager.getProperty API 正确报告对近超声音频功能的支持，如下所示：

如果 PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND 为 “true”，则 VOICE_RECOGNITION 和 UNPROCESSED 音频源 MUST 满足以下要求：

• [C-1-1] 麦克风在 18.5 kHz 至 20 kHz 频段的平均功率响应 MUST 不超过 2 kHz 响应以下 15 dB。
• [C-1-2] 对于 -26 dBFS 下的 19 kHz 音调，麦克风在 18.5 kHz 至 20 kHz 上的未加权信噪比 MUST 不低于 50 dB。

如果 PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND 为 “true”

• [C-2-1] 扬声器在 18.5 kHz - 20 kHz 频段的平均响应 MUST 不低于 2 kHz 响应以下 40 dB。

7.8.4. 信号完整性

设备实现

• SHOULD 为手持设备上的输入和输出流提供无毛刺的音频信号路径，定义为每个路径一分钟的测试期间测得的零毛刺。使用 OboeTester “Automated Glitch Test” 进行测试。

测试需要一个 音频环回适配器，直接在 3.5 毫米插孔中使用，和/或与 USB-C 转 3.5 毫米适配器结合使用。所有音频输出端口 SHOULD 都应进行测试。

OboeTester 当前支持 AAudio 路径，因此 SHOULD 应使用 AAudio 测试以下组合的毛刺：

Perf Mode	共享	输出采样率	输入通道	输出通道
LOW_LATENCY	EXCLUSIVE	UNSPECIFIED	1	2
LOW_LATENCY	EXCLUSIVE	UNSPECIFIED	2	1
LOW_LATENCY	SHARED	UNSPECIFIED	1	2
LOW_LATENCY	SHARED	UNSPECIFIED	2	1
NONE	SHARED	48000	1	2
NONE	SHARED	48000	2	1
NONE	SHARED	44100	1	2
NONE	SHARED	44100	2	1
NONE	SHARED	16000	1	2
NONE	SHARED	16000	2	1

可靠的流 SHOULD 满足以下 2000 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 和工具。设备实现 MUST 正确实现这些 API 和行为，如本节详述。

7.9.1. 虚拟现实模式

Android 包含对 VR 模式的支持，该功能处理通知的立体渲染，并在 VR 应用程序具有用户焦点时禁用单眼系统 UI 组件。

7.9.2. 虚拟现实模式 - 高性能

如果设备实现支持 VR 模式，则它们

• [C-1-1] MUST 至少具有 2 个物理核心。
• [C-1-2] MUST 声明 android.hardware.vr.high_performance 功能。
• [C-1-3] MUST 支持持续性能模式。
• [C-1-4] MUST 支持 OpenGL ES 3.2。
• [C-1-5] MUST 支持 android.hardware.vulkan.level 0。
• SHOULD 支持 android.hardware.vulkan.level 1 或更高版本。
• [C-1-6] MUST 实现 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] MUST 实现 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 和显示器 MUST 能够同步对共享前缓冲区的访问，以便在两个渲染上下文中以 60fps 速率交替渲染 VR 内容时，显示内容不会出现可见的撕裂伪影。
• [C-1-9] MUST 实现对 AHardwareBuffer 标志 AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER、AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA 和 AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT 的支持，如 NDK 中所述。
• [C-1-10] MUST 实现对 AHardwareBuffer 的支持，这些 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] MUST 支持 H.264 解码，至少 3840 x 2160 @ 30fps，压缩到平均 40Mbps（相当于 4 个 1920 x1080 @ 30 fps-10 Mbps 或 2 个 1920 x 1080 @ 60 fps-20 Mbps 的实例）。
• [C-1-12] MUST 支持 HEVC 和 VP9，MUST 能够解码至少 1920 x 1080 @ 30 fps，压缩到平均 10 Mbps，并且 SHOULD 能够解码 3840 x 2160 @ 30 fps-20 Mbps（相当于 4 个 1920 x 1080 @ 30 fps-5 Mbps 的实例）。
• [C-1-13] MUST 支持 HardwarePropertiesManager.getDeviceTemperatures API，并返回皮肤温度的准确值。
• [C-1-14] MUST 具有嵌入式屏幕，并且其分辨率 MUST 至少为 1920 x 1080。
• [C-SR-6] 强烈建议显示分辨率至少为 2560 x 1440。
• [C-1-15] 显示器在 VR 模式下 MUST 以至少 60 Hz 的频率刷新。
• [C-1-17] 显示器 MUST 支持低余晖模式，余晖 ≤ 5 毫秒，余晖定义为像素发光的时间量。
• [C-1-18] MUST 支持蓝牙 4.2 和蓝牙 LE 数据长度扩展第 7.4.3 节。
• [C-1-19] MUST 支持并正确报告以下所有默认传感器类型的 直接通道类型：
  • 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] MUST 满足第 7.3.9 节中规定的 android.hardware.hifi_sensors 的陀螺仪、加速度计和磁力计相关要求。
• [C-SR-8] 强烈建议支持 android.hardware.sensor.hifi_sensors 功能。
• [C-1-22] MUST 具有不高于 28 毫秒的端到端运动到光子延迟。
• [C-SR-9] 强烈建议具有不高于 20 毫秒的端到端运动到光子延迟。
• [C-1-23] MUST 具有第一帧比率，即从黑到白过渡后的第一帧上像素的亮度与稳态下白色像素的亮度之比，至少为 85%。
• [C-SR-10] 强烈建议第一帧比率至少为 90%。
• MAY 为前台应用程序提供独占核心，并且 MAY 支持 Process.getExclusiveCores API 以返回专用于顶部前台应用程序的 CPU 核心编号。

如果支持独占核心，则该核心

• [C-2-1] MUST 不允许任何其他用户空间进程在其上运行（应用程序使用的设备驱动程序除外），但 MAY 允许运行一些必要的内核进程。

7.10. 触感反馈

旨在手持或佩戴的设备可以包括通用触感反馈致动器，应用程序可以使用它来实现各种目的，包括通过铃声、闹钟、通知以及通用触摸反馈来引起注意。

如果设备实现不包含此类通用触感反馈致动器，则它们

• [7.10/C] 对于 Vibrator.hasVibrator()，MUST 返回 false。

如果设备实现确实包含至少一个此类通用触感反馈致动器，则它们

• [C-1-1] 对于 Vibrator.hasVibrator()，MUST 返回 true。
• SHOULD NOT 使用偏心旋转质量 (ERM) 触感反馈致动器（振动器）。
• SHOULD 实现 清晰触感反馈在 android.view.HapticFeedbackConstants 中的所有公共常量，即 (CLOCK_TICK、CONTEXT_CLICK、KEYBOARD_PRESS、KEYBOARD_RELEASE、KEYBOARD_TAP、LONG_PRESS、TEXT_HANDLE_MOVE、VIRTUAL_KEY、VIRTUAL_KEY_RELEASE、CONFIRM、REJECT、GESTURE_START 和 GESTURE_END)。
• SHOULD 实现 清晰触感反馈在 android.os.VibrationEffect 中的所有公共常量，即 (EFFECT_TICK、EFFECT_CLICK、EFFECT_HEAVY_CLICK 和 EFFECT_DOUBLE_CLICK) 以及 丰富触感反馈在 android.os.VibrationEffect.Composition 中的所有可行的公共 PRIMITIVE_* 常量，即 (CLICK、TICK、LOW_TICK、QUICK_FALL、QUICK_RISE、SLOW_RISE、SPIN、THUD)。某些基元，例如 LOW_TICK 和 SPIN，可能仅在振动器可以支持相对较低的频率时才可行。
• SHOULD 遵循 映射公共常量的指南，将 android.view.HapticFeedbackConstants 中的公共常量映射到推荐的 android.os.VibrationEffect 常量，并具有相应的幅度关系。
• SHOULD 使用这些链接的触感反馈常量映射。
• SHOULD 遵循 createOneShot() 和 createWaveform() API 的质量评估。
• SHOULD 验证公共 android.os.Vibrator.hasAmplitudeControl() API 的结果是否正确反映了其振动器的功能。
• SHOULD 通过运行 android.os.Vibrator.hasAmplitudeControl() 来验证幅度可扩展性的功能。

如果设备实现遵循触感反馈常量映射，则它们

• SHOULD 通过运行 android.os.Vibrator.areAllEffectsSupported() 和 android.os.Vibrator.arePrimitivesSupported() API 来验证实现状态。
• SHOULD 对触感反馈常量执行质量评估。
• SHOULD 根据需要验证和更新对不支持的基元的后备配置，如常量的实现指南中所述。
• SHOULD 提供后备支持，以减轻此处描述的故障风险。

7.11. 媒体性能等级

设备实现的媒体性能等级可以从 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS API 获取。媒体性能等级的要求针对每个 Android 版本定义，从 R（版本 30）开始。特殊值 0 表示设备不属于媒体性能等级。

如果设备实现为 android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS 返回非零值，则它们

• [C-1-1] MUST 返回至少 android.os.Build.VERSION_CODES.R 的值。

• [C-1-2] MUST 是手持设备实现。

• [C-1-3] MUST 满足 第 2.2.7 节中描述的“媒体性能等级”的所有要求。

换句话说，Android T 中的媒体性能等级仅针对版本 T、S 或 R 的手持设备定义。

有关设备特定要求，请参阅第 2.2.7 节。

8. 性能和功耗

一些最低性能和功耗标准对于用户体验至关重要，并且会影响开发人员在开发应用程序时的基准假设。

8.1. 用户体验一致性

如果存在某些最低要求以确保应用程序和游戏具有一致的帧速率和响应时间，则可以为最终用户提供流畅的用户界面。设备实现可以根据设备类型，对用户界面延迟和任务切换具有可衡量的要求，如第 2 节中所述。

8.2. 文件 I/O 访问性能

为应用程序私有数据存储 (/data 分区) 提供一致文件访问性能的通用基准，使应用程序开发人员能够设定适当的期望，这将有助于他们的软件设计。设备实现可以根据设备类型，对以下读取和写入操作具有第 2 节中描述的某些要求：

• 顺序写入性能。通过使用 10MB 写入缓冲区写入 256MB 文件来衡量。
• 随机写入性能。通过使用 4KB 写入缓冲区写入 256MB 文件来衡量。
• 顺序读取性能。通过使用 10MB 写入缓冲区读取 256MB 文件进行测量。
• 随机读取性能。通过使用 4KB 写入缓冲区读取 256MB 文件进行测量。

8.3. 省电模式

如果设备实现包括 AOSP 中包含的（例如，应用待机分 buckets、Doze 模式）用于改进设备电源管理的功能，或者扩展这些功能以应用比 RESTRICTED 应用待机分 buckets 更严格的限制，则它们

• [C-1-1] 对于应用待机和 Doze 省电模式的触发、维护、唤醒算法以及全局系统设置或 DeviceConfig 的使用，不得偏离 AOSP 实现。
• [C-1-2] 对于使用全局设置或 DeviceConfig 来管理应用待机模式下每个分 buckets 中应用的作业、闹钟和网络限流，不得偏离 AOSP 实现。
• [C-1-3] 对于应用待机模式使用的 应用待机分 buckets 的数量，不得偏离 AOSP 实现。
• [C-1-4] 必须按照 电源管理 中的描述实现 应用待机分 buckets 和 Doze 模式。
• [C-1-5] 当设备处于省电模式时，必须为 PowerManager.isPowerSaveMode() 返回 true。
• [C-1-6] 必须提供用户界面以显示所有被排除在应用待机和 Doze 省电模式或任何电池优化之外的应用，并且必须实现 ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS intent，以请求用户允许应用忽略电池优化。
• [C-SR-1] 强烈建议提供用户界面以启用和停用省电功能。
• [C-SR-2] 强烈建议提供用户界面以显示所有被排除在应用待机和 Doze 省电模式之外的应用。

如果设备实现扩展了 AOSP 中包含的电源管理功能，并且该扩展应用了比 Rare 应用待机分 buckets 更严格的限制，请参阅 第 3.5.1 节。

除了省电模式外，Android 设备实现可以实现高级配置和电源接口 (ACPI) 定义的 4 种休眠电源状态中的任何一种或全部。

如果设备实现实现了 ACPI 定义的 S4 电源状态，则它们

• [C-1-1] 仅当用户采取显式操作将设备置于非活动状态（例如，关闭设备物理部件的盖子或关闭车辆或电视）之后，以及在用户重新激活设备（例如，打开盖子或重新打开车辆或电视）之前，才能进入此状态。

如果设备实现实现了 ACPI 定义的 S3 电源状态，则它们

• [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-0-1] 必须通过 PowerManager.isSustainedPerformanceModeSupported() API 方法准确报告对持续性能模式的支持。

• 应支持持续性能模式。

如果设备实现报告支持持续性能模式，则它们

• [C-1-1] 当顶层前台应用请求时，必须为其提供至少 30 分钟的持续性能水平。
• [C-1-2] 必须遵守 Window.setSustainedPerformanceMode() API 和其他相关 API。

如果设备实现包含两个或多个 CPU 核心，则它们

• 应提供至少一个可供顶层前台应用保留的独占核心。

如果设备实现支持为顶层前台应用保留一个独占核心，则它们

• [C-2-1] 必须通过 Process.getExclusiveCores() API 方法报告可供顶层前台应用保留的独占核心的 ID 编号。
• [C-2-2] 除应用使用的设备驱动程序外，不得允许任何用户空间进程在独占核心上运行，但可以根据需要允许某些内核进程运行。

如果设备实现不支持独占核心，则它们

• [C-3-1] 必须通过 Process.getExclusiveCores() API 方法返回空列表。

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 路径作为特权路径来满足此要求。

Android 15 的新增要求开始

protection level 为 dangerous 的权限是运行时权限。 targetSdkVersion > 22 的应用在运行时请求它们。

设备实现

• [C-0-3] 必须显示一个专用界面，供用户决定是否授予请求的运行时权限，并提供一个界面供用户管理运行时权限。

• [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、Cell 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 权限时。

权限可以标记为 restricted，以改变其行为。

• [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 都具有相同的 UI 屏幕，无论启动的应用或其提供的任何信息如何。

如果设备实现报告 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.15 沙盒 API 实现”章节中为设备实现概述的所有要求。

如果设备实现包含支持 VoiceInteractionService 的默认应用，则它们

• [C-5-1] 不得将 ACCESS_FINE_LOCATION 作为该应用的默认权限授予。

9.2. UID 和进程隔离

设备实现

• [C-0-1] 必须支持 Android 应用沙盒模型，其中每个应用都以唯一的 Unix 风格 UID 并在单独的进程中运行。
• [C-0-2] 必须支持以相同的 Linux 用户 ID 运行多个应用，前提是这些应用已正确签名和构建，如 安全性和权限参考 中所定义。

9.3. 文件系统权限

设备实现

• [C-0-1] 必须支持 Android 文件访问权限模型，如 安全性和权限参考 中所定义。

9.4. 备选执行环境

即使设备实现包括使用 Dalvik 可执行格式或本机代码以外的其他软件或技术来执行应用的运行时环境，也必须保持 Android 安全和权限模型的一致性。换句话说

• [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] 当应用需要使用设备资源（例如相机、GPS 等）时，如果存在相应的 Android 权限，则备选运行时必须告知用户应用将能够访问该资源。

• [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-1] 必须允许来自附加配置文件的以下 intent 由设备上主用户的应用处理

  • Intent.ACTION_VIEW
  • Intent.ACTION_SENDTO
  • Intent.ACTION_SEND
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT
  • Intent.ACTION_INSERT_OR_EDIT
  • Intent.ACTION_SEND_MULTIPLE
  • Intent.ACTION_PICK
  • Intent.ACTION_GET_CONTENT
  • MediaStore.ACTION_IMAGE_CAPTURE
  • MediaStore.ACTION_VIDEO_CAPTURE

• [C-4-2] 必须将应用于设备主用户的此附加用户配置文件的所有设备策略用户限制和选定的非用户 restrictions(list below) 继承到此附加用户配置文件。

  • setScreenCaptureDisabled
  • setAccountManagementDisabled
  • setCameraDisabled
  • setPermittedInputMethods
  • setApplicationHidden
  • setPersonalAppsSuspended

• [C-4-3] 必须仅允许通过以下 intent 从此附加配置文件写入联系人

  • ContactsContract.Intents.Insert.ACTION
  • Intent.ACTION_PICK
  • Intent.ACTION_EDIT
  • Intent.ACTION_INSERT_OR_EDIT

• [C-4-4] 不得为在此附加用户配置文件中运行的应用运行联系人同步。

• [C-4-5] 必须仅允许附加配置文件中具有启动器 Activity 的应用访问父用户配置文件已可访问的联系人。

9.6. 高级短信警告

Android 包括对警告用户任何发出的 高级短信 的支持。高级短信是发送到在运营商处注册的服务的短信，可能会向用户收取费用。

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

• [C-1-1] 在向设备中 /data/misc/sms/codes.xml 文件中定义的正则表达式标识的号码发送短信之前，必须警告用户。上游 Android 开源项目提供了满足此要求的实现。

9.7. 安全功能

设备实现必须确保符合内核和平台中的安全功能，如下所述。

Android 沙箱包括使用 Security-Enhanced Linux (SELinux) 强制访问控制 (MAC) 系统、seccomp 沙箱和 Linux 内核中的其他安全功能的功能。设备实现

• [C-0-1] 即使在 Android 框架下实现了 SELinux 或任何其他安全功能，也必须保持与现有应用的兼容性。
• [C-0-2] 当安全功能检测到并成功阻止了安全违规时，不得具有可见的用户界面，但当发生未阻止的安全违规并导致成功利用时，可以具有可见的用户界面，安全功能是在 Android 框架下实现的。
• [C-0-3] 不得使 SELinux 或在 Android 框架下实现的任何其他安全功能可供用户或应用开发者配置。
• [C-0-4] 不得允许可以通过 API（例如设备管理 API）影响另一个应用的应用配置破坏兼容性的策略。
• [C-0-5] 必须将媒体框架拆分为多个进程，以便可以更精细地为每个进程授予访问权限，如 Android 开源项目站点中 所述。
• [C-0-6] 必须实现内核应用沙箱机制，该机制允许从多线程程序中使用可配置策略过滤系统调用。上游 Android 开源项目通过启用带有线程组同步 (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 或更高的设备上，不得在内核中读取或写入正常 usercopy 访问 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] 强烈建议在初始化后将仅在初始化期间写入的内核数据标记为只读（例如，__ro_after_init）。

• [C-SR-2] 强烈建议随机化内核代码和内存的布局，并避免会损害随机化的暴露（例如，通过 /chosen/kaslr-seed Device Tree node 或 EFI_RNG_PROTOCOL 使用引导加载程序熵的 CONFIG_RANDOMIZE_BASE）。

• [C-SR-3] 强烈建议在内核中启用控制流完整性 (CFI)，以提供针对代码重用攻击的额外保护（例如，CONFIG_CFI_CLANG 和 CONFIG_SHADOW_CALL_STACK）。

• [C-SR-4] 强烈建议不要在已启用控制流完整性 (CFI)、影子调用堆栈 (SCS) 或整数溢出清理 (IntSan) 的组件上禁用它们。

• [C-SR-5] 强烈建议为任何其他安全敏感的用户空间组件启用 CFI、SCS 和 IntSan，如 CFI 和 IntSan 中所述。

• [C-SR-6] 强烈建议在内核中启用堆栈初始化，以防止使用未初始化的局部变量（CONFIG_INIT_STACK_ALL 或 CONFIG_INIT_STACK_ALL_ZERO）。此外，设备实现不应假定编译器用于初始化局部变量的值。

• [C-SR-7] 强烈建议在内核中启用堆初始化，以防止使用未初始化的堆分配（CONFIG_INIT_ON_ALLOC_DEFAULT_ON），并且设备实现不应假定内核用于初始化这些分配的值。

如果设备实现使用能够支持 SELinux 的 Linux 内核，则它们

• [C-1-1] 必须实现 SELinux。
• [C-1-2] 必须将 SELinux 设置为全局强制模式。
• [C-1-3] 必须在强制模式下配置所有域。不允许任何 permissive 模式域，包括特定于设备/供应商的域。
• [C-1-4] 不得修改、省略或替换上游 Android 开源项目 (AOSP) 中提供的 system/sepolicy 文件夹中存在的 neverallow 规则，并且对于 AOSP SELinux 域以及设备/供应商特定的域，策略必须使用所有 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 还专注于减少导致质量和安全性下降的关键常见错误类别。

为了减少内存错误，设备实现

• [C-SR-10] 强烈建议使用用户空间内存错误检测工具进行测试，例如 ARMv9 设备的 MTE、ARMv8+ 设备的 HWASan 或其他设备类型的 ASan。
• [C-SR-11] 强烈建议使用内核内存错误检测工具进行测试，例如 KASAN（ARMv9 设备的 CONFIG_KASAN、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 清单选项的情况下，缓解概率很高（> 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 引导加载程序协议满足上述要求。

Android 15 的新增要求开始

9.8. 隐私权

9.8.1. 使用历史记录

Android 存储用户选择的历史记录，并通过 UsageStatsManager 管理此类历史记录。

设备实现

• [C-0-1] 必须保持此类用户历史记录的合理保留期限。
• [C-SR-1] 强烈建议保持 14 天的保留期限，如 AOSP 实现中的默认配置。

Android 使用 StatsLog 标识符存储系统事件，并通过 StatsManager 和 IncidentManager 系统 API 管理此类历史记录。

设备实现

• [C-0-2] 必须仅在系统 API 类 IncidentManager 创建的事件报告中包含标记为 DEST_AUTOMATIC 的字段。
• [C-0-3] 不得使用系统事件标识符记录 StatsLog SDK 文档中描述的事件以外的任何其他事件。 如果记录了其他系统事件，它们可以使用 100,000 到 200,000 范围内的不同原子标识符。

9.8.2. 录制

设备实现

• [C-0-1] 不得预加载或开箱即用地分发软件组件，这些组件会在未经用户同意或没有清晰的持续通知的情况下，将用户的私人信息（例如，击键、屏幕上显示的文本、错误报告）发送到设备外。

• [C-0-2] 每次通过 MediaProjection.createVirtualDisplay()、 VirtualDeviceManager.createVirtualDisplay() 或专有 API 启动屏幕捕获会话时，必须显示用户警告并获得明确的用户同意，允许捕获用户屏幕上显示的任何敏感信息。

• [C-0-3] 屏幕投射或屏幕录制启用时，必须向用户显示持续通知。 AOSP 通过在状态栏中显示持续通知图标来满足此要求。

• [C-SR-1] 强烈建议显示与 AOSP 中实现的完全相同的用户警告消息，但可以更改，只要该消息清楚地警告用户，用户屏幕上的任何敏感信息都将被捕获。

• [C-0-4] 不得为用户提供禁用未来屏幕捕获用户同意提示的功能，除非会话是由用户已允许通过 associate() 与 android.app.role.COMPANION_DEVICE_APP_STREAMING 或 android.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING 设备配置文件关联的系统应用启动的。

Android 15 的新增要求开始

如果设备实现在系统中包含通过系统 API ContentCaptureService 或 第 9.8.6 节操作系统级别和环境数据 中描述的其他专有方式捕获屏幕上显示的内容和/或录制设备上播放的音频流的功能，则它们

• [C-1-1] 每当启用此功能并主动捕获/录制时，必须向用户显示持续通知。

如果设备实现包含开箱即用启用的组件，该组件能够录制环境音频和/或录制设备上播放的音频以推断有关用户上下文的有用信息，则它们

• [C-2-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] 必须预安装与上游 Android 开源项目中 提供的系统信任证书颁发机构 (CA) 存储相同的根证书。
• [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] 必须为在 AndroidManifest.xml 文件中通过将 SERVICE_META_DATA_SUPPORTS_ALWAYS_ON 属性设置为 false 来表明不支持始终开启 VPN 服务的应用禁用此用户界面。

9.8.5. 设备标识符

设备实现

• [C-0-1] 必须阻止应用访问设备序列号，以及在适用的情况下，IMEI/MEID、SIM 卡序列号和国际移动用户识别码 (IMSI)，除非该应用满足以下要求之一
  • 是由设备制造商验证的已签名运营商应用。
  • 已被授予 READ_PRIVILEGED_PHONE_STATE 权限。
  • 具有 UICC 运营商特权 中定义的运营商特权。
  • 是已被授予 READ_PHONE_STATE 权限的设备所有者或个人资料所有者。
  • （仅适用于 SIM 卡序列号/ICCID）具有应用检测订户身份变更的当地法规要求。

9.8.6. 操作系统级别和环境数据

Android 通过系统 API 支持设备实现捕获以下敏感数据的机制

• 屏幕上呈现的文本和图形，包括但不限于，通知和辅助数据，通过 AssistStructure API。
• 媒体数据，例如设备录制或播放的音频或视频。

• 输入事件（例如，按键、鼠标、手势、语音、视频和辅助功能）。

• 通过 AugmentedAutofillService 发送到系统的任何屏幕或其他数据。

• 通过 Content Capture API 访问的任何屏幕或其他数据。

• 通过 AppSearchManager API 传递到系统并通过 AppSearchGlobalManager.query 访问的任何应用程序数据。

• 通过 TextClassifier API 发送到系统 TextClassifier 的任何文本或其他数据，即发送到系统服务以理解文本的含义，以及根据文本生成预测的后续操作。

• 平台 AppSearch 实现索引的数据，包括但不限于文本、图形、媒体数据或其他类似数据。

• 通过语音识别器实现使用 SpeechRecognizer#onDeviceSpeechRecognizer() 获取的音频数据。

• 在后台（持续）通过 AudioRecord、 SoundTrigger 或其他音频 API 获取，并且未产生用户可见指示器的音频数据

• 在后台（持续）通过 CameraManager 或其他摄像头 API 获取，并且未产生用户可见指示器的摄像头数据

如果设备实现捕获上述任何数据，则它们

• [C-1-1] 必须在设备中存储所有此类数据时对其进行加密。 此加密可以使用 Android 基于文件的加密或 Cipher SDK 中描述的 API 版本 26+ 中列出的任何密码。
• [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] 必须提供用户界面来擦除实现或专有方式在设备上以任何形式存储的数据。 如果用户选择擦除数据，则必须删除所有收集的历史数据。

• [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 权限，并遵循 第 9.1 节。权限 中描述的 Android 权限模型。

• [C-SR-3] 强烈建议将这些服务与其他系统组件分开（例如，不绑定服务或共享进程 ID），但以下项除外

  • 电话、联系人、系统 UI 和媒体

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] 必须确保使用紧急位置绕过 API [LocationRequest.setLocationSettingsIgnored()] 的应用程序是由用户发起的紧急会话（例如，拨打 911 或短信发送到 911）。 但是，对于汽车，如果检测到碰撞/事故（例如，为了满足 eCall 要求），车辆可以在没有主动用户交互的情况下发起紧急会话。
• [C-0-4] 必须保留紧急位置绕过 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. 连接性错误报告

如果设备实现声明 android.hardware.telephony 功能标志，则它们

• [C-1-1] 必须支持通过带有 BugreportManager 的 BUGREPORT_MODE_TELEPHONY 生成连接性错误报告。
• [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 可以，软件包名称不行）。
• 可以包含与任何用户身份无关的其他信息。 （例如，供应商日志）。

如果设备实现在错误报告中包含其他信息（例如，供应商日志），并且该信息具有隐私/安全/电池/存储/内存影响，则它们

• [C-SR-1] 强烈建议具有默认情况下禁用的开发者设置。 AOSP 参考实现通过在开发者设置中提供 启用详细供应商日志记录 选项来满足此要求，以便在错误报告中包含其他特定于设备的供应商日志。

9.8.11. 数据 Blob 共享

Android 通过 BlobStoreManager 允许应用向系统贡献数据 Blob，以便与选定的一组应用共享。

如果设备实现支持 SDK 文档 中描述的共享数据 Blob，则它们

• [C-1-1] 不得共享超出应用打算允许范围的应用的数据 Blob（即，默认访问范围和可以使用 BlobStoreManager.session#allowPackageAccess()、 BlobStoreManager.session#allowSameSignatureAccess() 或 BlobStoreManager.session#allowPublicAccess() 指定的其他访问模式不得修改）。 AOSP 参考实现满足这些要求。
• [C-1-2] 不得将数据 Blob 的安全哈希（用于控制访问）发送到设备外或与其他应用共享。

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. SensorPrivacyManager

如果设备实现为用户提供软件界面以关闭设备实现的摄像头和/或麦克风输入，则它们

• [C-1-1] 对于相关的 supportsSensorToggle() API 方法，必须准确返回“true”。
• [C-1-2] 当应用尝试访问被阻止的麦克风或摄像头时，必须向用户呈现一个不可关闭的用户界面，该界面清楚地指示传感器已被阻止，并且需要选择继续阻止或取消阻止，如满足此要求的 AOSP 实现所示。
• [C-1-3] 必须仅将空白（或伪造）摄像头和音频数据传递给应用，并且不会由于用户未通过上述 [C-1-2] 中的用户界面打开摄像头或麦克风而报告错误代码。

9.8.14. 不适用

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），但以下项除外
  • 电话、联系人、系统 UI 和媒体
• [C-0-4] 不得允许用户用用户可安装的应用程序或服务替换这些服务
• [C-0-5] 必须仅允许预安装的服务捕获此类数据。 除非替换功能内置于 AOSP 中（例如，对于数字助理应用）。
• [C-0-6] 不得允许预安装的服务机制以外的任何应用能够捕获此类数据。 除非此类捕获功能是通过 Android SDK API 实现的。
• [C-0-7] 必须提供用户界面来禁用这些服务。
• [C-0-8] 不得省略用户界面来管理服务持有的 Android 权限，并遵循 第 9.1 节。权限 中描述的 Android 权限模型。

9.8.16. 连续音频和摄像头数据

Android 15 的新增要求开始

• [C-0-1] 必须强制执行相应的指示器（摄像头和/或麦克风，按照 9.8.2 节录音的规定），除非
  • 此访问是在沙盒实现（参见 9.8.15 沙盒 API 实现）中执行的，通过持有以下一个或多个角色的软件包：系统界面智能、系统环境音频智能、系统音频智能、系统通知智能、系统文本智能或 系统视觉智能。
  • 访问是通过沙盒执行的，沙盒通过 AOSP 中的机制（HotwordDetectionService、WearableSensingService、VisualQueryDetector）实现和强制执行。
  • 音频访问是由数字助理应用出于辅助目的执行的，提供 SOURCE_HOTWORD 作为音频源。
  • 访问由系统执行，并使用开源代码实现。
• [C-SR-1] 强烈建议要求用户为利用此类数据的每个功能征得用户同意，并默认禁用。
• [C-SR-2] 强烈建议对来自远程可穿戴设备的摄像头数据应用相同的处理方式（即，遵循 9.8.2 录音、9.8.6 操作系统级和环境数据、9.8.15 沙盒 API 实现和 9.8.16 连续音频和摄像头数据中概述的限制）。

Android 15 的新增要求开始

• [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 管理，特权系统应用程序可以使用这些 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. 直接启动

设备实现

• [C-0-1] 即使设备不支持存储加密，也必须实现 直接启动模式 API。

• [C-0-2] ACTION_LOCKED_BOOT_COMPLETED 和 ACTION_USER_UNLOCKED Intent 仍然必须广播，以向直接启动感知应用程序发出信号，表明设备加密 (DE) 和凭据加密 (CE) 存储位置可供用户使用。

9.9.2. 加密要求

设备实现

• [C-0-1] 必须加密应用程序私有数据（/data 分区），以及应用程序共享存储分区（/sdcard 分区）（如果它是设备的永久性、不可移除的部分）。
• [C-0-2] 必须在用户完成开箱即用设置体验时默认启用数据存储加密。

• [C-0-3] 必须通过实施以下两种加密方法之一来满足上述数据存储加密要求

  • 基于文件的加密 (FBE) 和 元数据加密，如 9.9.3.1 节中所述。
  • 如 9.9.3.2 节中所述的按用户块级加密。

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 中指定的那样。文件系统元数据是诸如文件大小、所有权、模式和扩展属性 (xattrs) 之类的数据。
• [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] 必须在引导加载程序解锁和锁定时安全擦除，如 此处 所述。

• 应该使预装的基本应用程序（例如，闹钟、电话、消息程序）具有直接启动感知能力。

上游 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 存储已解锁，并且用户在接收 OTA 后已解锁设备，攻击者也极难恢复用户的 CE 加密数据。对于内部人员攻击抵抗，我们还假设攻击者获得了广播加密签名密钥的访问权限。

具体而言

• [C-0-1] 即使对于物理上拥有设备且具有以下能力和限制的攻击者，CE 存储也必须不可读

  • 可以使用任何供应商或公司的签名密钥来签署任意消息。
  • 可以导致设备接收 OTA。
  • 可以修改任何硬件（AP、闪存等）的运行，但如下所述除外，但此类修改涉及至少一小时的延迟和破坏 RAM 内容的电源循环。
  • 无法修改防篡改硬件（例如 Titan M）的运行。
  • 无法读取实时设备的 RAM。
  • 无法获取用户的凭据（PIN 码、图案、密码）或以其他方式导致其输入。

例如，符合 此处 找到的所有描述的设备实现将符合 [C-0-1]。

9.10. 设备完整性

以下要求确保设备完整性状态的透明度。设备实现

• [C-0-1] 必须通过 System 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-1-8] 必须使用防篡改存储：用于存储引导加载程序是否已解锁。防篡改存储意味着引导加载程序可以检测到存储是否已从 Android 内部被篡改。
• [C-1-9] 必须在使用设备时提示用户，并在允许从引导加载程序锁定模式转换为引导加载程序解锁模式之前需要物理确认。
• [C-1-10] 必须为 Android 使用的分区（例如，启动、系统分区）实施回滚保护，并使用防篡改存储来存储用于确定允许的最低操作系统版本的元数据。
• [C-1-11] 必须按照“9.12. 数据删除”的规定（包括 userdata 分区和任何 NVRAM 空间）在引导加载程序解锁和锁定时安全擦除所有用户数据。

Android 15 的新增要求开始

• [C-SR-2] 强烈建议使用植根于已验证启动保护的分区的信任链来验证所有特权应用 APK 文件。
• [C-SR-3] 强烈建议在执行特权应用从其 APK 文件外部加载的任何可执行工件（例如，动态加载的代码或编译的代码）之前对其进行验证，或者强烈建议根本不执行它们。
• 应该为任何具有持久性固件的组件（例如，调制解调器、摄像头）实施回滚保护，并且应该使用防篡改存储来存储用于确定允许的最低版本的元数据。

Android 15 的新增要求开始

上游 Android 开源项目在 external/avb/ 存储库中提供了此功能的首选实现，可以将其集成到用于加载 Android 的引导加载程序中。

如果设备实现具有按页验证文件内容的能力，那么它们

• [C-2-1] 支持无需读取整个文件即可加密验证文件内容。

• [C-2-2] 当读取的内容未按照上面的 [C-2-1] 进行验证时，不得允许对受保护文件的读取请求成功。

• [C-2-4] 必须以 O(1) 的复杂度返回已启用文件的文件校验和。

如果设备实现在早期版本的 Android 上发布时没有根据受信任的密钥验证文件内容的能力，并且无法通过系统软件更新添加对此功能的支持，则可以免除此要求。上游 Android 开源项目提供了基于 Linux 内核 fs-verity 功能的此功能的首选实现。

Android 15 的新增要求开始

9.11. 密钥和凭据

Android 密钥库系统 允许应用开发者将加密密钥存储在容器中，并通过 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-1-1] 必须使用隔离执行环境备份密钥库实现。
• [C-1-2] 必须具有 RSA、AES、ECDSA、ECDH（如果支持 IKeyMintDevice）、3DES 和 HMAC 加密算法以及 MD5、SHA-1 和 SHA-2 系列哈希函数的实现，以便在安全地与内核及以上代码隔离的区域中正确支持 Android 密钥库系统支持的算法。安全隔离必须阻止内核或用户空间代码可能访问隔离环境内部状态的所有潜在机制，包括 DMA。上游 Android 开源项目 (AOSP) 通过使用 Trusty 实现来满足此要求，但另一种基于 ARM TrustZone 的解决方案或第三方审查的基于适当虚拟机监控程序的隔离的安全实现是替代选项。
• [C-1-3] 必须在隔离的执行环境中执行锁屏身份验证，并且仅在成功时才允许使用绑定身份验证的密钥。锁屏凭据的存储方式必须仅允许隔离的执行环境执行锁屏身份验证。上游 Android 开源项目提供了 Gatekeeper 硬件抽象层 (HAL) 和 Trusty，可用于满足此要求。

Android 15 的新增要求开始

请注意，如果设备实现已在早期 Android 版本上启动，则此类设备免于密钥库由隔离的执行环境支持并支持密钥证明的要求，除非它声明 android.hardware.fingerprint 功能，该功能需要由隔离的执行环境支持的密钥库。

• [C-1-5] 必须允许用户选择从解锁状态转换到锁定状态的睡眠超时时间，最小允许超时时间可达 15 秒。当主机单元关闭或用户切换时锁定屏幕的汽车设备，可能没有睡眠超时配置。
• [C-1-6] 必须支持以下之一
  • IKeymasterDevice 3.0，
  • 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-2-1] 必须是 要求用户身份验证才能使用密钥 中描述的用户身份验证方法。

如果设备实现添加或修改了基于已知秘密解锁锁屏的身份验证方法，并使用新的身份验证方法作为锁定屏幕的安全方式

• [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) 应用程序通过调用方法 DevicePolicyManager.setKeyguardDisabledFeatures() 设置了任何关联的生物识别标志（即 KEYGUARD_DISABLE_BIOMETRICS、KEYGUARD_DISABLE_FINGERPRINT、KEYGUARD_DISABLE_FACE 或 KEYGUARD_DISABLE_IRIS）的键盘锁功能策略时，必须禁用新的身份验证方法，并且仅允许推荐的主要身份验证来解锁屏幕。

如果生物识别身份验证方法不满足 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) 应用程序通过以下方式设置策略时，必须禁用新方法，并且仅允许推荐的主要身份验证方法之一来解锁屏幕
  • DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) 方法
  • DevicePolicyManager.setPasswordQuality() 方法，其质量常量比 PASSWORD_QUALITY_NONE 更严格。
  • DevicePolicyManager.setRequiredPasswordComplexity() 方法，其复杂性桶比 PASSWORD_COMPLEXITY_NONE 更严格。
• [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 电视或汽车设备）上完全实现该函数。
• [C-7-4] 必须加密 TrustAgentService.addEscrowToken() 添加的所有存储令牌。
• [C-7-5] 不得将加密密钥或托管令牌存储在使用该密钥的同一设备上。例如，允许存储在手机上的密钥解锁电视上的用户帐户。对于汽车设备，不允许将托管令牌存储在车辆的任何部分。
• [C-7-6] 在启用托管令牌以解密数据存储之前，必须告知用户有关安全影响的信息。
• [C-7-7] 必须具有回退机制，以使用推荐的主要身份验证方法之一。
• [C-7-9] 必须按照 7.3.10 节中的 [C-1-7] 和 [C-1-8] 的描述，对用户进行推荐的主要身份验证（例如：PIN 码、图案、密码）方法的质询，除非用户的安全（例如，驾驶员分心）受到关注。
• [C-7-10] 不得被视为安全锁屏，并且必须遵循下面 C-8 中列出的约束。
• [C-7-11] 禁止在主要个人设备（例如：手持设备）上允许 TrustAgent 解锁设备，并且只能使用 TrustAgent 将已解锁的设备保持解锁状态，最长不超过 4 小时。AOSP 中 TrustManagerService 的默认实现满足此要求。
• [C-7-12] 必须使用密码学安全的通信通道（例如 UKEY2）将托管令牌从存储设备传递到目标设备。

如果设备实现添加或修改了用于解锁锁定屏幕的身份验证方法，而该方法不是上述安全锁定屏幕，并使用新的身份验证方法来解锁密钥保护

• [C-8-1] 当设备策略控制器 (DPC) 应用通过 DevicePolicyManager.setPasswordQuality() 方法设置的密码质量策略比 PASSWORD_QUALITY_NONE 更严格，或者通过 DevicePolicyManager.setRequiredPasswordComplexity() 方法设置的复杂性常量比 'PASSWORD_COMPLEXITY_NONE' 更严格时，必须禁用新方法。
• [C-8-2] 不得重置由 DevicePolicyManager.setPasswordExpirationTimeout() 设置的密码过期计时器。
• [C-8-3] 不得公开 API 供第三方应用更改锁定状态。

如果设备实现允许应用创建辅助 虚拟显示屏，并且不支持关联的输入事件，例如通过 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] 必须为每个用户提供单独的虚拟设备实例

Android 15 的新增要求开始

Android 15 的新增要求开始

• [C-10-11] 必须禁用虚拟设备上的身份验证 UI，包括知识因素输入和生物识别提示

Android 15 的新增要求开始

• [C-10-13] 不得使用虚拟设备锁定状态作为 Android Keystore 系统的用户身份验证授权。请参阅 KeyGenParameterSpec.Builder.setUserAuthentication*。

Android 15 的新增要求开始

当设备实现允许用户将主要身份验证知识因素从源设备传输到目标设备时（例如，用于目标设备的初始设置），设备

• [C-11-1] 在将知识因素从源设备传输到目标设备时，必须使用与 Google Cloud Key Vault Service 安全白皮书中描述的保护保证类似的保护保证来加密知识因素，以便无法远程解密知识因素或将其用于远程解锁任何设备。
• [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] 必须调用 TrustManagerService.revokeTrust()
  • 在授予信任后最多 24 小时，或者
  • 在 8 小时的空闲窗口后，或者
  • 如果实现未使用 [C-12-5] 中定义的密码学安全和准确的测距，则当与邻近物理设备的底层连接丢失时。
• [C-12-5] 依赖于安全和准确测距来满足 [C-12-4] 要求的实现必须使用以下解决方案之一
  • 使用 UWB 的实现
    • 必须满足 7.4.9 中描述的 UWB 的一致性、认证、准确性和 校准要求。
    • 必须使用 7.4.9 中列出的 P-STS 安全模式之一。
  • 使用 Wi-Fi 邻居感知网络 (NAN) 的实现
    • 必须满足 2.2.1 [7.4.2.5/H-SR-1] 中的准确性要求，使用 160 MHz 带宽（或更高），并遵循 Presence Calibration 中指定的测量设置步骤。
    • 必须使用 IEEE 802.11az 中定义的 Secure LTF。

如果设备实现允许应用创建辅助 虚拟显示屏，并支持关联的输入事件，例如通过 VirtualDeviceManager，并且显示屏未标记为 VIRTUAL_DISPLAY_FLAG_SECURE，则设备

• [C-13-8] 必须阻止具有属性 android:canDisplayOnRemoteDevices 或元数据 android.activity.can_display_on_remote_devices 设置为 false 的 activity 在虚拟设备上启动。

Android 15 的新增要求开始

如果设备实现通过 DeviceStateManager 支持单独的显示屏电源状态，并且通过 KeyguardDisplayManager 支持单独的显示屏锁定状态，则设备

• [C-SR-2] 强烈建议使用满足第 9.11.1 节中定义的凭据要求或满足第 7.3.10 节中定义的至少 Class 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] 必须具有独立的 CPU，该 CPU 与应用处理器 (AP) 不共享缓存、DRAM、协处理器或其他核心资源。

• [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-11] 必须包含由国家认可的测试实验室根据 通用准则智能卡攻击潜力应用指南 进行评估的固件，其中包含高攻击潜力漏洞评估。
• [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] 受信任的应用的实现方式必须使其安全属性不受影响（例如，除非满足访问控制条件，否则不会发布凭据数据，否则无法为任意数据生成 MAC），即使 Android 行为不当或受到威胁也是如此。

上游 Android 开源项目提供了一个受信任应用的参考实现 (libeic)，可用于实现身份凭据系统。

9.12. 数据删除

所有设备实现

• [C-0-1] 必须为用户提供执行“恢复出厂设置”的机制。
• [C-0-2] 执行“恢复出厂设置”时，必须删除 userdata 文件系统上的所有数据。
• [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. 汽车车辆系统隔离

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 15 的新增要求开始

10. 软件兼容性测试

设备实现必须通过本节中描述的所有测试。但是，请注意，没有软件测试包是完全全面的。因此，**强烈建议** 设备实现者尽可能少地更改 Android 开源项目中提供的 Android 参考和首选实现。这将最大限度地降低引入错误的风险，这些错误会造成不兼容性，需要返工和潜在的设备更新。

10.1. 兼容性测试套件

设备实现

• [C-0-1] 必须通过 Android 开源项目提供的 Android 兼容性测试套件 (CTS)，使用设备上的最终发布软件。

• [C-0-2] 必须确保 CTS 中存在歧义以及对参考源代码的任何重新实现情况下的兼容性。

CTS 旨在在实际设备上运行。与任何软件一样，CTS 本身可能包含错误。CTS 的版本将独立于此兼容性定义进行版本控制，并且可能会为 Android 15 发布多个 CTS 修订版。

设备实现

• [C-0-3] 必须通过设备软件完成时可用的最新 CTS 版本。

• 应该尽可能多地使用 Android 开源树中的参考实现。

10.2. CTS 验证程序

CTS 验证程序包含在兼容性测试套件中，旨在由人工操作员运行，以测试自动化系统无法测试的功能，例如相机和传感器的正确功能。

设备实现

• [C-0-1] 必须正确执行 CTS 验证程序中的所有适用用例。

CTS 验证程序具有许多类型的硬件测试，包括一些可选硬件。

设备实现

• [C-0-2] 必须通过他们拥有的硬件的所有测试；例如，如果设备拥有加速度计，则必须正确执行 CTS 验证程序中的加速度计测试用例。

对于本兼容性定义文档中注明为可选的功能的测试用例，可以跳过或省略。

• [C-0-2] 如上所述，每个设备和每个版本都必须正确运行 CTS 验证程序。但是，由于许多版本非常相似，因此不希望设备实现者在仅在细微方面不同的版本上显式运行 CTS 验证程序。具体而言，与已通过 CTS 验证程序的实现仅在包含的语言区域设置、品牌等集合方面不同的设备实现，可以省略 CTS 验证程序测试。

11. 可更新软件

• [C-0-1] 设备实现必须包含替换整个系统软件的机制。该机制不需要执行“实时”升级，也就是说，可能需要重启设备。可以使用任何方法，前提是它可以替换设备上预安装的整个软件。例如，以下任何方法都将满足此要求

  • 通过重启进行离线更新的“无线下载 (OTA)”。
  • 通过 USB 从主机 PC 进行“有线连接”更新。
  • 通过重启和从可移动存储设备上的文件进行更新的“离线”更新。

• [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 5.1 以来添加的上游 Android 开源项目中的基于块的 OTA 实现满足此要求。

此外，设备实现应支持 A/B 系统更新。AOSP 使用启动控制 HAL 实现此功能。

如果在设备实现发布后但在其合理的产品寿命内发现错误，并且经与 Android 兼容性团队协商后确定该错误会影响第三方应用的兼容性，则

• [C-2-1] 设备实现者必须通过软件更新来纠正错误，该软件更新可通过刚刚描述的机制应用。

Android 包含允许设备所有者应用（如果存在）控制系统更新安装的功能。如果设备的系统更新子系统报告 android.software.device_admin，则设备

• [C-3-1] 必须实现 SystemUpdatePolicy 类中描述的行为。

12. 文档变更日志

有关此版本中兼容性定义的更改摘要

• 文档变更日志

13. 联系我们

您可以加入 android-compatibility 论坛 并请求澄清或提出您认为文档未涵盖的任何问题。