Android 10 兼容性定义

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

1. 简介

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

“必须 (MUST)”、“不得 (MUST NOT)”、“必需 (REQUIRED)”、“应 (SHALL)”、“不应 (SHALL NOT)”、“应该 (SHOULD)”、“不应该 (SHOULD NOT)”、“推荐 (RECOMMENDED)”、“可以 (MAY)”和“可选 (OPTIONAL)”等术语的用法均符合 RFC2119 中定义的 IETF 标准。

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

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

如果本定义或第 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，并且在同一章节和同一设备类型中，数字递增 1。
• 要求 ID
  • 此 ID 从 1 开始，并在同一章节和同一条件下递增 1。

1.1.3. 第 2 节中的要求 ID

第 2 节中的要求 ID 以相应的章节 ID 开头，后跟上述要求 ID。

• 第 2 节中的 ID 的组成部分为：章节 ID / 设备类型 ID - 条件 ID - 要求 ID（例如 7.4.3/A-0-1）。

2. 设备类型

虽然 Android 开源项目提供了可用于各种设备类型和外形规格的软件堆栈，但仍有少数几种设备类型拥有相对完善的应用分发生态系统。

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

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

2.1 设备配置

如需了解按设备类型划分的硬件配置的主要差异，请参阅本节后面的设备专用要求。

2.2. 手持设备要求

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

如果 Android 设备实现满足以下所有条件，则归类为手持设备

• 具有提供移动性的电源，例如电池。
• 物理对角线屏幕尺寸在 2.5 到 8 英寸范围内。

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

2.2.1. 硬件

手持设备实现

• [7.1.1.1/H-0-1] 必须至少有一个物理对角线尺寸至少为 2.5 英寸的 Android 兼容显示屏，并且每个 Android 兼容显示屏都必须满足本文档中描述的所有要求。
• [7.1.1.3/H-SR] 强烈建议为用户提供更改显示尺寸（屏幕密度）的功能。

如果手持设备实现通过 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.5/H-0-1] 必须支持上游 Android 开源代码实现的旧版应用兼容模式。也就是说，设备实现绝不能更改激活兼容模式的触发器或阈值，并且绝不能更改兼容模式本身的行为。
• [7.2.1/H-0-1] 必须支持第三方输入法编辑器 (IME) 应用。
• [7.2.3/H-0-3] 必须在提供主屏幕的所有 Android 兼容显示屏上提供“主屏幕”功能。
• [7.2.3/H-0-4] 必须在所有 Android 兼容显示屏上提供“返回”功能，并且必须在至少一个 Android 兼容显示屏上提供“最近使用”功能。
• [7.2.3/H-0-2] 必须将“返回”功能（KEYCODE_BACK）的正常和长按事件都发送到前台应用。这些事件绝不能被系统占用，并且可以通过 Android 设备外部触发（例如，连接到 Android 设备的外部硬件键盘）。
• [7.2.4/H-0-1] 必须支持触摸屏输入。
• [7.2.4/H-SR] 强烈建议在长按 KEYCODE_MEDIA_PLAY_PAUSE 或 KEYCODE_HEADSETHOOK 时启动用户选择的辅助应用，换句话说，即实现 VoiceInteractionService 的应用或处理 ACTION_ASSIST 的 Activity，前提是前台 Activity 不处理这些长按事件。
• [7.3.1/H-SR] 强烈建议包含 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] 建议支持具有 6 个自由度的姿势传感器。
• [7.4.3/H] 应该包含对蓝牙和低功耗蓝牙 (Bluetooth LE) 的支持。

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

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

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

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

手持设备实现

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

手持设备实现

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

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

• [7.7.1/H-1-1] 必须实现 Android 开放配件 (AOA) API。

如果手持设备实现包含支持主机模式的 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 代码的软件映射

• [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] 强烈建议在连接 USB-C 音频外围设备后，在 1000 毫秒内执行 USB 描述符枚举、识别终端类型并广播 Intent ACTION_HEADSET_PLUG。

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.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

2.2.3. 软件

手持设备实现

• [3.2.3.1/H-0-1] 必须有一个应用程序来处理 SDK 文档中描述的 ACTION_GET_CONTENT、ACTION_OPEN_DOCUMENT、ACTION_OPEN_DOCUMENT_TREE 和 ACTION_CREATE_DOCUMENT intent，并提供用户便利通过使用 DocumentsProvider API 访问文档提供程序数据。
• [3.4.1/H-0-1] 必须提供 android.webkit.Webview API 的完整实现。
• [3.4.2/H-0-1] 必须包含一个独立的浏览器应用程序，供普通用户进行网页浏览。
• [3.8.1/H-SR] 强烈建议实施一个默认启动器，该启动器支持应用内固定快捷方式、小部件和 widgetFeatures。
• [3.8.1/H-SR] 强烈建议实施一个默认启动器，该启动器通过 ShortcutManager API 提供对第三方应用程序提供的其他快捷方式的快速访问。
• [3.8.1/H-SR] 强烈建议包含一个默认启动器应用程序，该应用程序显示应用程序图标的标记。
• [3.8.2/H-SR] 强烈建议支持第三方应用程序小部件。
• [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] 强烈建议在通知栏中显示通过 RemoteInput.Builder setChoices() 提供的第一个选项，而无需额外的用户交互。
• [3.8.3/H-SR] 强烈建议当用户在通知栏中展开所有通知时，在通知栏中显示通过 RemoteInput.Builder setChoices() 提供的所有选项。
• [3.8.3.1/H-SR] 强烈建议将 Notification.Action.Builder.setContextual 设置为 true 的操作与 Notification.Remoteinput.Builder.setChoices 显示的回复内联显示。
• [3.8.4/H-SR] 强烈建议在设备上实施一个助手来处理 Assist action。

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

• [3.8.4/H-SR] 强烈建议使用长按 HOME 键作为启动助手应用程序的指定交互，如 7.2.3 节中所述。 必须启动用户选择的助手应用程序，换句话说，即实施 VoiceInteractionService 或处理 ACTION_ASSIST intent 的 activity 的应用程序。

如果 Android 手持设备实施支持锁屏，则它们

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

如果手持设备实施支持安全锁屏，则它们

• [3.9/H-1-1] 必须实施 Android SDK 文档中定义的全部 设备管理 策略。
• [3.9/H-1-2] 必须声明通过 android.software.managed_users 功能标志支持托管配置文件，除非设备配置为 报告 自身为低 RAM 设备，或者配置为将内部（不可移动）存储分配为共享存储。

手持设备实现

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

2.2.4. 性能和功耗

• [8.1/H-0-1] 一致的帧延迟。不一致的帧延迟或帧渲染延迟每秒不得超过 5 帧发生，且应低于每秒 1 帧。
• [8.1/H-0-2] 用户界面延迟。设备实施必须通过在 36 秒内滚动 Android 兼容性测试套件 (CTS) 定义的 1 万个列表条目的列表来确保低延迟用户体验。
• [8.1/H-0-3] 任务切换。当启动了多个应用程序后，重新启动已启动的应用程序必须在 1 秒内完成。

手持设备实现

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

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

• [8.3/H-1-1] 必须提供用户便利来启用和禁用省电功能。
• [8.3/H-1-2] 必须提供用户便利来显示所有从应用待机和省电模式中豁免的应用程序。

手持设备实现

• [8.4/H-0-1] 必须提供每个组件的功耗配置文件，该文件定义每个硬件组件的 当前功耗值 以及组件随时间推移造成的大致电池损耗，如 Android 开源项目站点中所述。
• [8.4/H-0-2] 必须以毫安时 (mAh) 为单位报告所有功耗值。
• [8.4/H-0-3] 必须报告每个进程的 UID 的 CPU 功耗。Android 开源项目通过 uid_cputime 内核模块实施满足此要求。
• [8.4/H-0-4] 必须通过 adb shell dumpsys batterystats shell 命令向应用程序开发者提供此功耗使用情况。
• [8.4/H] 如果无法将硬件组件功耗归因于应用程序，则应归因于硬件组件本身。

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

• [8.4/H-1-1] 必须遵守 android.intent.action.POWER_USAGE_SUMMARY intent 并显示一个设置菜单，其中显示此功耗使用情况。

2.2.5. 安全模型

手持设备实现

• [9.1/H-0-1] 必须允许第三方应用程序通过 android.permission.PACKAGE_USAGE_STATS 权限访问使用情况统计信息，并提供用户可访问的机制来响应 android.settings.ACTION_USAGE_ACCESS_SETTINGS intent 来授予或撤销对此类应用程序的访问权限。

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

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

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

当手持设备实施支持安全锁屏时，它们

• [9.11/H-1-1] 必须允许用户选择最短的睡眠超时时间，即从解锁状态到锁定状态的过渡时间，为 15 秒或更短。
• [9.11/H-1-2] 必须提供用户便利来隐藏通知并禁用除 9.11.1 安全锁屏中描述的主要身份验证之外的所有形式的身份验证。AOSP 将其作为锁定模式来满足要求。

如果手持设备实施包含多个用户且未声明 android.hardware.telephony 功能标志，则它们

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

如果手持设备实施包含多个用户并声明 android.hardware.telephony 功能标志，则它们

• [9.5/H-3-1] 不得支持受限配置文件，但必须与 AOSP 对控件的实施保持一致，以启用/禁用其他用户访问语音通话和 SMS。

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

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

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

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

• Perfetto
  • [6.1/H-0-2]* 必须向 shell 用户公开一个 /system/bin/perfetto 二进制文件，其 cmdline 符合 perfetto 文档。
  • [6.1/H-0-3]* perfetto 二进制文件必须接受符合 perfetto 文档中定义的架构的 protobuf 配置作为输入。
  • [6.1/H-0-4]* perfetto 二进制文件必须将符合 perfetto 文档中定义的架构的 protobuf 跟踪写入为输出。
  • [6.1/H-0-5]* 必须通过 perfetto 二进制文件至少提供 perfetto 文档中描述的数据源。

2.3. 电视要求

Android 电视设备是指一种 Android 设备实施，它是一种娱乐界面，供用户在大约十英尺远的地方坐着（“后仰”或“10 英尺用户界面”）消费数字媒体、电影、游戏、应用程序和/或直播电视。

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

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

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

2.3.1. 硬件

电视设备实施

• [7.2.2/T-0-1] 必须支持 D-pad。
• [7.2.3/T-0-1] 必须提供 Home 和 Back 功能。
• [7.2.3/T-0-2] 必须将 Back 功能的正常和长按事件 (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] 必须支持蓝牙和蓝牙 LE。
• [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.2/T-SR] 强烈建议支持以每秒 30 帧的速度对 720p 和 1080p 分辨率的视频进行 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

电视设备实施必须支持 MPEG-2 解码，如 5.3.1 节详述，在标准视频帧速率和分辨率下，最高可达并包括

• [5.3.1/T-1-1] 高清 1080p，每秒 29.97 帧，主配置文件高级别。
• [5.3.1/T-1-2] 高清 1080i，每秒 59.94 帧，主配置文件高级别。它们必须对隔行 MPEG-2 视频进行去隔行处理，并使其可供第三方应用程序使用。

电视设备实施必须支持 H.264 解码，如 5.3.4 节详述，在标准视频帧速率和分辨率下，最高可达并包括

• [5.3.4/T-1-1] 高清 1080p，每秒 60 帧，基线配置文件
• [5.3.4/T-1-2] 高清 1080p，每秒 60 帧，主配置文件
• [5.3.4/T-1-3] 高清 1080p，每秒 60 帧，高级配置文件级别 4.2

具有 H.265 硬件解码器的电视设备实施必须支持 H.265 解码，如 5.3.5 节详述，在标准视频帧速率和分辨率下，最高可达并包括

• [5.3.5/T-1-1] 高清 1080p，每秒 60 帧，主配置文件级别 4.1

如果具有 H.265 硬件解码器的电视设备实施支持 H.265 解码和 UHD 解码配置文件，则它们

• [5.3.5/T-2-1] 必须支持 UHD 解码配置文件，每秒 60 帧，Main10 级别 5 主层配置文件。

电视设备实施必须支持 VP8 解码，如 5.3.6 节详述，在标准视频帧速率和分辨率下，最高可达并包括

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

具有 VP9 硬件解码器的电视设备实施必须支持 VP9 解码，如 5.3.7 节详述，在标准视频帧速率和分辨率下，最高可达并包括

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

如果具有 VP9 硬件解码器的电视设备实施支持 VP9 解码和 UHD 解码配置文件，则它们

• [5.3.7/T-2-1] 必须支持 UHD 解码配置文件，每秒 60 帧，配置文件 0（8 位颜色深度）。
• [5.3.7/T-2-1] 强烈建议支持 UHD 解码配置文件，每秒 60 帧，配置文件 2（10 位颜色深度）。

电视设备实施

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

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

• [5.8/T-0-1] 必须设置 HDMI 输出模式以选择可以使用 50Hz 或 60Hz 刷新率支持的最大分辨率。
• [5.8/T-SR] 强烈建议提供用户可配置的 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.4.1/T-0-1] 必须提供 android.webkit.Webview API 的完整实现。

如果 Android 电视设备实施支持锁屏，则它们

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

电视设备实施

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

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

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

电视设备实施

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

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] 必须提供用户便利来显示所有从应用待机和省电模式中豁免的应用程序。

电视设备实施

• [8.4/T-0-1] 必须提供每个组件的功耗配置文件，该文件定义每个硬件组件的 当前功耗值 以及组件随时间推移造成的大致电池损耗，如 Android 开源项目站点中所述。
• [8.4/T-0-2] 必须以毫安时 (mAh) 为单位报告所有功耗值。
• [8.4/T-0-3] 必须报告每个进程的 UID 的 CPU 功耗。Android 开源项目通过 uid_cputime 内核模块实施满足此要求。
• [8.4/T] 如果无法将硬件组件功耗归因于应用程序，则应归因于硬件组件本身。
• [8.4/T-0-4] 必须通过 adb shell dumpsys batterystats shell 命令向应用程序开发者提供此功耗使用情况。

2.3.5. 安全模型

电视设备实施

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

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

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

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

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

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

如果电视设备实施包含多个用户并声明 android.hardware.telephony 功能标志，则它们

• [9.5/T-3-1] 不得支持受限配置文件，但必须与 AOSP 对控件的实施保持一致，以启用/禁用其他用户访问语音通话和 SMS。

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

电视设备实施

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

2.4. 手表要求

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] 强烈建议包含 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 米每二次方秒的加速度移动时，这些数据应足以在至少 95% 的时间内将位置计算在 20 米以内，速度计算在 0.2 米每秒以内。

如果手表设备实现包含 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.8.4/W-SR] 强烈建议在设备上实现助手，以处理 Assist 操作。

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

• [3.10/W-1-1] 必须支持第三方辅助功能服务。

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

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

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

2.4.4. 性能和功耗

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

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

手表设备实施

• [8.4/W-0-1] 必须提供每个组件的功耗配置文件，其中定义了每个硬件组件的 电流消耗值 以及组件随时间推移造成的大致电池损耗，如 Android 开源项目站点中所述。
• [8.4/W-0-2] 必须以毫安时 (mAh) 为单位报告所有功耗值。
• [8.4/W-0-3] 必须报告每个进程 UID 的 CPU 功耗。Android 开源项目通过 uid_cputime 内核模块实现来满足此要求。
• [8.4/W-0-4] 必须通过 adb shell dumpsys batterystats shell 命令向应用开发者提供此功耗使用情况。
• [8.4/W] 如果无法将硬件组件功耗归因于某个应用，则*应*将其归因于硬件组件本身。

2.4.5. 安全模型

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

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

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

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

2.5. 汽车要求

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

如果 Android 设备实现声明了功能 android.hardware.type.automotive 或满足以下所有条件，则将其归类为汽车。

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

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

2.5.1. 硬件

汽车设备实现

• [7.1.1.1/A-0-1] 必须配备物理对角线尺寸至少为 6 英寸的屏幕。

• [7.1.1.1/A-0-2] 必须具有至少 750 dp x 480 dp 的屏幕尺寸布局。

• [7.2.3/A-0-1] 必须提供主屏幕功能，并且*可以*提供返回和最近使用的应用功能。

• [7.2.3/A-0-2] 必须将返回功能的正常和长按事件 (KEYCODE_BACK) 发送到前台应用。
• [7.3/A-0-1] 必须实现并报告 GEAR_SELECTION、NIGHT_MODE、PERF_VEHICLE_SPEED 和 PARKING_BRAKE_ON。
• [7.3/A-0-2] NIGHT_MODE 标志的值必须与仪表板白天/夜晚模式一致，并且*应*基于环境光传感器输入。底层环境光传感器*可以*与 光度计 相同。
• [7.3/A-0-3] 必须为提供的每个传感器提供传感器附加信息字段 TYPE_SENSOR_PLACEMENT，作为 SensorAdditionalInfo 的一部分。
• [7.3/A-0-1] *可以*通过将 GPS/GNSS 与其他传感器融合来航位推算 Location。如果 Location 是航位推算的，则强烈建议实现并报告使用的相应 Sensor 类型和/或 Vehicle Property IDs。
• [7.3/A-0-2] 通过 LocationManager#requestLocationUpdates() 请求的 Location *不得*进行地图匹配。

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

• [7.3.1/A-1-1] 必须能够报告频率至少为 100 Hz 的事件。
• [7.3.1/A-1-2] 必须符合 Android 汽车传感器坐标系。

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

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

汽车设备实现

• [7.4.3/A-0-1] 必须支持蓝牙，并且*应*支持蓝牙 LE。

• [7.4.3/A-0-2] Android Automotive 实现必须支持以下蓝牙配置文件

  • 通过免提配置文件 (HFP) 进行电话呼叫。
  • 通过音频分发配置文件 (A2DP) 进行媒体播放。
  • 通过远程控制配置文件 (AVRCP) 进行媒体播放控制。
  • 使用电话簿访问配置文件 (PBAP) 进行联系人共享。

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

• [7.4.5/A] *应*包括对基于蜂窝网络的网络数据连接的支持。

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

外部视图摄像头是指对设备实现外部场景进行成像的摄像头，如行车记录仪。

汽车设备实现

• *应*包括一个或多个外部视图摄像头。

如果汽车设备实现包含外部视图摄像头，则对于此类摄像头，它们

• [7.5/A-1-1] *不得*通过 Android Camera API 访问外部视图摄像头，除非它们符合摄像头 核心要求。
• [7.5/A-SR] 强烈建议不要旋转或水平镜像摄像头预览。
• [7.5.5/A-SR] 强烈建议将其方向设置为使摄像头的长边与地平线对齐。
• [7.5/A-SR] 强烈建议分辨率至少为 130 万像素。
• *应*具有定焦或 EDOF（扩展景深）硬件。
• *可以*在摄像头驱动程序中实现硬件自动对焦或软件自动对焦。

汽车设备实现

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

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

如果汽车设备实现通过内部不可移动存储的一部分提供共享外部存储，则它们

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

如果汽车设备实现是 32 位

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

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

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

  • 小型/普通屏幕上 xhdpi 或更高
  • 大型屏幕上 hdpi 或更高
  • 超大屏幕上 mdpi 或更高

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

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

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

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

如果汽车设备实现是 64 位

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

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

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

  • 小型/普通屏幕上 xhdpi 或更高
  • 大型屏幕上 hdpi 或更高
  • 超大屏幕上 mdpi 或更高

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

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

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

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

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

汽车设备实现

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

汽车设备实现

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

汽车设备实现

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

2.5.2. 多媒体

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

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

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

• [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] H.265 HEVC

2.5.3. 软件

汽车设备实现

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

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

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

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

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

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

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

如果汽车设备实现包含一键通按钮，则它们

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

汽车设备实现

• [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] *应*限制使用丰富的管理任务，例如每个通知渠道的控件。*可以*使用每个应用的 UI 界面来减少控件。

汽车设备实现

• [3.14/A-0-1] 必须包含 UI 框架，以支持第三方应用使用 3.14 节中描述的媒体 API。
• [3.14/A-0-2] 必须允许用户在驾驶时安全地与媒体应用交互。
• [3.14/A-0-3] 必须支持带有 CAR_EXTRA_MEDIA_PACKAGE 额外信息的 CAR_INTENT_ACTION_MEDIA_TEMPLATE 隐式 Intent 操作。
• [3.14/A-0-4] 必须提供一个界面来导航到媒体应用的 偏好设置 Activity，但*必须*仅在汽车 UX 限制未生效时启用它。
• [3.14/A-0-5] 必须显示媒体应用设置的 错误消息，并且必须支持可选的额外信息 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 打开它们。

汽车设备实现

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

2.5.4. 性能和功耗

汽车设备实现

• [8.2/A-0-1] 必须报告每个进程 UID 读取和写入非易失性存储的字节数，以便开发者可以通过 System API android.car.storagemonitoring.CarStorageMonitoringManager 获取统计信息。Android 开源项目通过 uid_sys_stats 内核模块来满足此要求。
• [8.3/A-1-3] 必须在汽车断电前至少进入一次 车库模式。
• [8.3/A-1-4] 必须处于 车库模式 至少 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] 即使设备上的用户数已达到最大值，也必须支持创建 访客用户 的功能。

汽车设备实现

• [9.11/A-0-1] 必须使用隔离的执行环境来备份密钥库实现。
• [9.11/A-0-2] 必须具有 RSA、AES、ECDSA 和 HMAC 加密算法以及 MD5、SHA1 和 SHA-2 系列哈希函数的实现，以在安全隔离于内核及以上运行代码的区域中正确支持 Android Keystore 系统支持的算法。安全隔离必须阻止内核或用户空间代码可能访问隔离环境内部状态的所有潜在机制，包括 DMA。上游 Android 开源项目 (AOSP) 通过使用 Trusty 实现来满足此要求，但另一个基于 ARM TrustZone 的解决方案或第三方审查的基于适当虚拟机监控程序的隔离的安全实现是备选方案。
• [9.11/A-0-3] 必须在隔离的执行环境中执行锁屏身份验证，并且仅在成功时才允许使用身份验证绑定的密钥。锁屏凭据的存储方式必须仅允许隔离的执行环境执行锁屏身份验证。上游 Android 开源项目提供了 Gatekeeper 硬件抽象层 (HAL) 和 Trusty，它们可用于满足此要求。
• [9.11/A-0-4] 必须支持密钥证明，其中证明签名密钥受安全硬件保护，签名在安全硬件中执行。证明签名密钥必须在足够多的设备之间共享，以防止密钥被用作设备标识符。满足此要求的一种方法是共享相同的证明密钥，除非生产了给定 SKU 的至少 100,000 个单元。如果生产了超过 100,000 个 SKU 单元，则对于每 100,000 个单元，*可以*使用不同的密钥。

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

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

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

汽车设备实现

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

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

汽车设备实现

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

2.6. 平板电脑要求

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

• 通常用双手握持使用。
• 不具有翻盖或可转换配置。
• 与设备一起使用的任何物理键盘实现都必须通过标准连接方式连接。
• 具有提供移动性的电源，例如电池。
• 物理对角线屏幕尺寸在 7 到 18 英寸之间。

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

2.6.1. 硬件

屏幕尺寸

• [7.1.1.1/Tab-0-1] 必须配备 7 到 18 英寸范围内的屏幕。

陀螺仪

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

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

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

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

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

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

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

虚拟现实模式（第 7.9.1 节）

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

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

2.6.2. 安全模型

密钥和凭据（第 9.11 节）

请参阅第 [9.11] 节。

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

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

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

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

3. 软件

3.1. 托管 API 兼容性

托管 Dalvik 字节码执行环境是 Android 应用的主要载体。Android 应用程序编程接口 (API) 是向在托管运行时环境中运行的应用公开的 Android 平台接口集。

设备实现

• [C-0-1] 必须提供 Android SDK 或上游 Android 源代码中用“@SystemApi”标记装饰的任何 API 公开的任何已记录 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] 必须随附每个 API 级别分支在 AOSP 的 prebuilts/runtime/appcompat/hiddenapi-flags.csv 路径中通过临时列表和拒绝列表标志提供的每个非 SDK 接口上的相同受限列表一起发布。

  但是它们

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

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

3.1.1. Android 扩展

Android 包括扩展托管 API 的支持，同时保持相同的 API 级别版本。

• [C-0-1] Android 设备实现*必须*预加载共享库 ExtShared 和服务 ExtServices 的 AOSP 实现，其版本必须高于或等于每个 API 级别允许的最低版本。例如，运行 API 级别 24 的 Android 7.0 设备实现*必须*至少包含版本 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] 设备实现者*必须*支持并强制执行 Permission 参考页面记录的所有权限常量。请注意，第 9 节列出了与 Android 安全模型相关的其他要求。

3.2.2. 构建参数

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

• [C-0-1] 为了在设备实现之间提供一致、有意义的值，下表包括对设备实现*必须*符合的这些值的格式的附加限制。

必须（是或返回）硬件序列号，该序列号必须可用，并且在具有相同型号和制造商的设备之间是唯一的。此字段的值必须编码为 7 位 ASCII 码，并符合正则表达式“^[a-zA-Z0-9._-,]+$”。

3.2.3. Intent 兼容性

3.2.3.1. 核心应用程序 Intent

• Android Intent 允许应用程序组件从其他 Android 组件请求功能。Android 上游项目包含一个被认为是核心 Android 应用程序的应用程序列表，这些应用程序实现了多个 Intent 模式以执行常见操作。

  • [C-0-1] 设备实现必须为 AOSP 中以下核心 Android 应用程序定义的所有公共 Intent 过滤器模式预加载一个或多个带有 Intent 处理程序的应用程序或服务组件
  • 桌面时钟
  • 浏览器
  • 日历
  • 联系人
  • 图库
  • 全局搜索
  • 启动器
  • 设置

音乐

• 3.2.3.2. Intent 解析

• [C-0-1] 由于 Android 是一个可扩展的平台，设备实现必须允许第三方应用程序覆盖 第 3.2.3.1 节中引用的每个 Intent 模式，但 Settings 除外。上游 Android 开源实现默认允许这样做。

• [C-0-2] 设备实现者不得将特殊特权附加到系统应用程序对这些 Intent 模式的使用，或阻止第三方应用程序绑定和控制这些模式。此项禁止特别包括但不限于禁用“选择器”用户界面，该界面允许用户在所有处理相同 Intent 模式的多个应用程序之间进行选择。

• [C-0-3] 设备实现必须为用户提供一个用户界面，以修改 Intent 的默认活动。

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

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

[C-0-8] 如果设备实现允许某些候选 URI Intent 过滤器成功验证，而另一些则可能失败，则设备实现必须为用户提供查看和覆盖特定候选 URI Intent 过滤器的能力。

• 3.2.3.3. Intent 命名空间
• [C-0-1] 设备实现不得包含任何使用 android. 或 com.android. 命名空间中的 ACTION、CATEGORY 或其他键字符串来响应任何新 Intent 或广播 Intent 模式的 Android 组件。
• [C-0-2] 设备实现者不得包含任何使用属于其他组织的包空间中的 ACTION、CATEGORY 或其他键字符串来响应任何新 Intent 或广播 Intent 模式的 Android 组件。
• [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 文档中也描述了对后台应用程序的限制。

3.2.3.5. 默认应用设置

Android 包括一些设置，为用户提供了一种简单的方式来选择他们的默认应用程序，例如用于主屏幕或短信。

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

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

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

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

• [C-2-1] 必须提供一个设置菜单，该菜单将使用 RoleManager.ROLE_SMS 调用 RoleManager.createRequestRoleIntent(String) 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.app.role.CALL_REDIRECTION 角色的应用程序使用 android.telecom.CallRedirectionService。

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

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

[C-3-1] 必须响应 android.settings.NFC_PAYMENT_SETTINGS Intent 以显示“点击支付”的默认应用设置菜单。

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

[C-4-1] 必须响应 android.settings.ACTION_VOICE_INPUT_SETTINGS Intent 以显示语音输入和辅助功能的默认应用设置菜单。

3.2.4. 二级/多显示器上的活动

• 如果设备实现允许在多个显示器上启动正常的 Android 活动，则它们
• [C-1-1] 必须设置 android.software.activities_on_secondary_displays 功能标志。
• [C-1-2] 必须保证类似于在主显示器上运行的活动的 API 兼容性。
• [C-1-3] 当启动新活动时未通过 ActivityOptions.setLaunchDisplayId() API 指定目标显示器时，必须将新活动放置在与启动它的活动相同的显示器上。
• [C-1-4] 当具有 Display.FLAG_PRIVATE 标志的显示器被移除时，必须销毁所有活动。
• [C-1-5] 当设备使用安全锁屏锁定时，必须安全地隐藏所有屏幕上的内容，除非应用程序选择使用 Activity#setShowWhenLocked() API 在锁屏之上显示。

如果活动在二级显示器上启动，为了能够正确显示、正常运行并保持兼容性，应该具有与该显示器对应的 android.content.res.Configuration。

• 如果设备实现允许在二级显示器上启动正常的 Android 活动，并且二级显示器具有 android.view.Display.FLAG_PRIVATE 标志

[C-3-1] 只有该显示器的所有者、系统以及已在该显示器上的活动才能在该显示器上启动。每个人都可以在具有 android.view.Display.FLAG_PUBLIC 标志的显示器上启动。

3.3. 本机 API 兼容性

• 本机代码兼容性具有挑战性。因此，强烈建议设备实现者

[SR] 强烈建议使用来自上游 Android 开源项目的以下库的实现。

3.3.1. 应用程序二进制接口

设备实现

• 托管的 Dalvik 字节码可以调用应用程序 .apk 文件中提供的本机代码，该本机代码是为适当的设备硬件架构编译的 ELF .so 文件。由于本机代码高度依赖于底层处理器技术，因此 Android 在 Android NDK 中定义了多个应用程序二进制接口 (ABI)。
• [C-0-1] 必须与一个或多个已定义的 ABI 兼容，并实现与 Android NDK 的兼容性。
• [C-0-2] 必须包含对在托管环境中运行的代码调用本机代码的支持，使用标准的 Java 本机接口 (JNI) 语义。
• [C-0-3] 必须与下面列表中的每个必需库在源代码级别（即头文件兼容）和二进制级别（对于 ABI）上兼容。

• [C-0-5] 必须通过 android.os.Build.SUPPORTED_ABIS、android.os.Build.SUPPORTED_32_BIT_ABIS 和 android.os.Build.SUPPORTED_64_BIT_ABIS 参数准确报告设备支持的本机应用程序二进制接口 (ABI)，每个参数都是以逗号分隔的 ABI 列表，从最优先到最不优先排序。

  • [C-0-6] 必须通过上述参数报告以下 ABI 列表的子集，并且不得报告列表中未包含的任何 ABI。
  • armeabi
  • armeabi-v7a
  • arm64-v8a
  • x86

  • x86-64

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

  • libaaudio.so (AAudio 本机音频支持)
  • libamidi.so (本机 MIDI 支持，如果声明了第 5.9 节中描述的 android.software.midi 功能)
  • libandroid.so (本机 Android 活动支持)
  • 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 库导出 NDK 中定义的所有 OpenGL ES 3.1 和 Android 扩展包 函数符号。请注意，虽然必须存在所有符号，但第 7.1.4.1 节更详细地描述了何时需要每个相应函数的完整实现的要求。
• [C-0-12] 必须通过 libvulkan.so 库导出核心 Vulkan 1.0 函数符号以及 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 指令。
  • SETEND 指令。

• 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 10 分支上的上游 Android 开源项目的 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 访问最低要求的系统服务。WebView 的 AOSP 实现满足此要求。

请注意，如果设备实现是 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-7] 如果应用以 API 级别 25 或更高级别为目标，则它们**必须**停止应用的后台服务，就像应用调用服务的 stopSelf() 方法一样，除非该应用被临时添加到允许列表以处理用户可见的任务。
  • [C-0-8] 如果应用以 API 级别 25 或更高级别为目标，则它们**必须**释放应用持有的唤醒锁。
• [C-0-9] 设备**必须**返回以下安全提供程序，作为来自 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. 后台限制

如果设备实现包含在 AOSP 中的应用限制或扩展了应用限制，则它们

• [C-1-1] **必须**提供用户界面，用户可以在其中看到受限应用的列表。
• [C-1-2] **必须**提供用户界面，以打开/关闭每个应用的限制。
• [C-1-3] **不得**在没有系统运行状况不良行为证据的情况下自动应用限制，但**可以**在检测到系统运行状况不良行为（如卡住的唤醒锁、长时间运行的服务和其他标准）时对应用应用限制。标准**可以**由设备实施者确定，但**必须**与应用对系统运行状况的影响相关。其他与系统运行状况纯粹无关的标准，例如应用在市场上的受欢迎程度不足，**不得**用作标准。
• [C-1-4] 当用户手动关闭应用限制时，**不得**自动对应用应用应用限制，并且**可以**建议用户应用应用限制。
• [C-1-5] 如果应用限制自动应用于应用，**必须**通知用户。
• [C-1-6] 当受限应用调用此 API 时，**必须**为 ActivityManager.isBackgroundRestricted() 返回 true。
• [C-1-7] **不得**限制用户显式使用的顶部前台应用。
• [C-1-8] 当用户显式开始使用曾经受限的应用时，**必须**暂停对变为顶部前台应用的限制。

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 增加的内存使用量的影响。

如果设备实施者建议改进上述包命名空间之一（例如，通过向现有 API 添加有用的新功能，或添加新的 API），则实施者**应**访问 source.android.com 并根据该站点上的信息开始贡献更改和代码的过程。

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

3.7. 运行时兼容性

设备实现

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

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

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

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

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

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。

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] **强烈建议**在用户多次关闭某个第三方应用的通知后，自动显示用户界面，以阻止每个渠道和应用包级别的该第三方应用的通知。
• **应**支持富媒体通知。
• **应**将一些更高优先级的通知呈现为浮动通知。
• **应**具有用户界面来推迟通知。
• **可以**仅管理第三方应用程序通知用户值得注意的事件的可见性和时间，以减轻安全问题，例如驾驶员分心。

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

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

如果设备实现支持浮动通知：则它们

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

3.8.3.2. 通知侦听器服务

Android 包括 NotificationListenerService API，这些 API 允许应用（一旦用户明确启用）在发布或更新时接收所有通知的副本。

如果设备实现报告功能标志 android.hardware.ram.normal，则它们

• [C-1-1] **必须**正确且及时地将其全部通知更新到所有此类已安装且用户启用的侦听器服务，包括附加到 Notification 对象的任何和所有元数据。
• [C-1-2] **必须**遵守 snoozeNotification() API 调用，并在 API 调用中设置的推迟持续时间后关闭通知并进行回调。

如果设备实现具有用户界面来推迟通知，则它们

• [C-2-1] **必须**通过标准 API（例如 NotificationListenerService.getSnoozedNotifications()）正确反映推迟的通知状态。
• [C-2-2] **必须**使此用户界面可用于推迟来自每个已安装的第三方应用的通知，除非它们来自持久性/前台服务。

3.8.3.3. 请勿打扰 (DND)

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

• [C-1-1] **必须**实现一个 Activity，该 Activity 将响应 intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS，对于具有 UI_MODE_TYPE_NORMAL 的实现，它**必须**是一个用户可以在其中授予或拒绝应用访问 DND 策略配置的 Activity。
• [C-1-2] 对于设备实现已提供用户授予或拒绝第三方应用访问 DND 策略配置的方式的情况，**必须**显示应用程序创建的 自动 DND 规则 以及用户创建和预定义的规则。
• [C-1-3] **必须**遵守沿 NotificationManager.Policy 传递的 suppressedVisualEffects 值，并且如果应用已设置任何 SUPPRESSED_EFFECT_SCREEN_OFF 或 SUPPRESSED_EFFECT_SCREEN_ON 标志，则它**应**向用户指示视觉效果在 DND 设置菜单中被抑制。

3.8.4. 搜索

Android 包括允许开发者将搜索整合到其应用程序中，并将其应用程序的数据公开到全局系统搜索的 API。一般来说，此功能包括一个单一的、系统范围的用户界面，允许用户输入查询、在用户键入时显示建议以及显示结果。Android API 允许开发者重用此界面以在其自己的应用程序中提供搜索，并允许开发者向公共全局搜索用户界面提供结果。

• Android 设备实现**应**包括全局搜索，一个能够实时响应用户输入的建议的单一、共享、系统范围的搜索用户界面。

如果设备实现实现了全局搜索界面，则它们

• [C-1-1] **必须**实现允许第三方应用程序在全局搜索模式下运行时向搜索框添加建议的 API。

如果没有安装任何利用全局搜索的第三方应用程序

• 默认行为**应**是显示 Web 搜索引擎结果和建议。

Android 还包括 Assist API，允许应用程序选择与设备上的助手共享当前上下文的信息量。

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

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

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 主题属性 或其资产。

Android 还包括“Device Default”主题系列，作为一组定义的样式，供应用程序开发者使用，如果他们想要匹配设备实施者定义的设备主题的外观和感觉。

• 设备实现**可以**修改暴露给应用程序的 Device Default 主题属性。

Android 支持带有半透明系统栏的变体主题，这允许应用程序开发者用其应用程序内容填充状态栏和导航栏后面的区域。为了在这种配置中实现一致的开发者体验，重要的是跨不同的设备实现保持状态栏图标样式。

如果设备实现包括系统状态栏，则它们

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

3.8.7. 动态壁纸

Android 定义了一个组件类型和相应的 API 和生命周期，允许应用程序向最终用户公开一个或多个 “动态壁纸”。动态壁纸是动画、图案或类似的图像，具有有限的输入功能，作为壁纸显示在其他应用程序后面。

如果硬件能够以合理的帧速率运行所有动态壁纸，且对其他应用程序没有不利影响，则该硬件被认为能够可靠地运行动态壁纸，且功能不受限制。如果硬件的限制导致壁纸和/或应用程序崩溃、故障、消耗过多的 CPU 或电池电量或以不可接受的低帧速率运行，则该硬件被认为无法运行动态壁纸。例如，某些动态壁纸可能使用 OpenGL 2.0 或 3.x 上下文来渲染其内容。动态壁纸在不支持多个 OpenGL 上下文的硬件上无法可靠运行，因为动态壁纸对 OpenGL 上下文的使用可能与也使用 OpenGL 上下文的其他应用程序冲突。

• 能够如上所述可靠运行动态壁纸的设备实现**应**实现动态壁纸。

如果设备实现实现了动态壁纸，则它们

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

3.8.8. Activity 切换

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

包括概览功能导航键的设备实现（如 第 7.2.3 节 中所述）**可以**更改界面。

如果包括概览功能导航键的设备实现（如 第 7.2.3 节 中所述）更改了界面，则它们

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

3.8.9. 输入管理

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

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

• [C-1-1] **必须**声明平台功能 android.software.input_methods 并支持 Android SDK 文档中定义的 IME API。
• [C-1-2] **必须**提供用户可访问的机制，以响应 android.settings.INPUT_METHOD_SETTINGS intent 添加和配置第三方输入法。

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

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

3.8.10. 锁屏媒体控制

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

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

Android 包括对 交互式屏幕保护程序 的支持，以前称为 Dreams。屏幕保护程序允许用户在连接到电源的设备处于空闲状态或停靠在桌面底座中时与应用程序交互。Android Watch 设备**可以**实现屏幕保护程序，但其他类型的设备实现**应**包括对屏幕保护程序的支持，并提供一个设置选项，供用户响应 android.settings.DREAM_SETTINGS intent 配置屏幕保护程序。

3.8.12. 位置

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

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

3.8.13. Unicode 和字体

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

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

• [C-1-1] **必须**能够以彩色字形渲染这些表情符号字符。
• [C-1-2] **必须**包括对以下内容的支持
  • 具有不同粗细的 Roboto 2 字体—sans-serif-thin、sans-serif-light、sans-serif-medium、sans-serif-black、sans-serif-condensed、sans-serif-condensed-light，适用于设备上可用的语言。
  • 拉丁语、希腊语和西里尔语的完整 Unicode 7.0 覆盖范围，包括拉丁语扩展 A、B、C 和 D 范围，以及 Unicode 7.0 货币符号块中的所有字形。
• **应**支持 Unicode 技术报告 #51 中指定的肤色和多元家庭表情符号。

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

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

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

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

* [C-2-1] MUST render text with Unicode compliant font as default;
  non-Unicode compliant font MUST NOT be set as default font unless the user
  chooses it in the language picker.
* [C-2-2] MUST support a Unicode font and a non-Unicode compliant font if a
  non-Unicode compliant font is supported on the device.  Non-Unicode
  compliant font MUST NOT remove or overwrite the Unicode font.
* [C-2-3] MUST render text with non-Unicode compliant font ONLY IF a
  language code with [script code Qaag](
  http://unicode.org/reports/tr35/#unicode_script_subtag_validity) is
  specified (e.g. my-Qaag). No other ISO language or region codes (whether
  assigned, unassigned, or reserved) can be used to refer to non-Unicode
  compliant font for Myanmar. App developers and web page authors can
  specify my-Qaag as the designated language code as they would for any
  other language.

3.8.14. 多窗口

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

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

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

• [C-2-1] **必须**预加载 可调整大小的 启动器作为默认启动器。
• [C-2-2] 必须裁剪分屏多窗口停靠的 Activity，但如果启动器应用是焦点窗口，应该显示其部分内容。
• [C-2-3] 必须遵守第三方启动器应用声明的 AndroidManifestLayout_minWidth 和 AndroidManifestLayout_minHeight 值，并且在显示停靠 Activity 的部分内容时，不得覆盖这些值。

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

• [C-3-1] 当应用符合以下条件时，必须在画中画多窗口模式下启动 Activity：* 目标 API 级别为 26 或更高，并声明了 android:supportsPictureInPicture * 目标 API 级别为 25 或更低，并同时声明了 android:resizeableActivity 和 android:supportsPictureInPicture。
• [C-3-2] 必须通过 setActions() API，在 SystemUI 中公开当前 PIP Activity 指定的操作。
• [C-3-3] 必须支持大于或等于 1:2.39 且小于或等于 2.39:1 的宽高比，这是由 PIP Activity 通过 setAspectRatio() API 指定的。
• [C-3-4] 必须使用 KeyEvent.KEYCODE_WINDOW 来控制 PIP 窗口；如果未实现 PIP 模式，则该键必须可用于前台 Activity。
• [C-3-5] 必须提供用户界面，以阻止应用在 PIP 模式下显示；AOSP 实现通过在通知栏中设置控件来满足此要求。
• [C-3-6] 当 Configuration.uiMode 配置为 UI_MODE_TYPE_TELEVISION 时，PIP 窗口必须分配最小宽度和高度为 108 dp，以及最小宽度为 240 dp 和高度为 135 dp。

3.8.15. 显示屏缺口

Android 支持 SDK 文档中描述的显示屏缺口。DisplayCutout API 定义了显示屏边缘上不用于显示内容的区域。

如果设备实现包含显示屏缺口，则它们

• [C-1-1] 必须仅在设备的短边上具有缺口。相反，如果设备的宽高比为 1.0(1:1)，则不得有缺口。
• [C-1-2] 不得在每条边上具有多个缺口。
• [C-1-3] 必须遵守应用通过 WindowManager.LayoutParams API 设置的显示屏缺口标志，如 SDK 中所述。
• [C-1-4] 必须报告 DisplayCutout API 中定义的所有缺口指标的正确值。

3.9. 设备管理

Android 包含一些功能，允许具有安全意识的应用在系统级别执行设备管理功能，例如强制执行密码政策或执行远程擦除，这通过 Android 设备管理 API 实现。

如果设备实现实现了 Android SDK 文档中定义的全部 设备管理 政策，则它们

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

3.9.1 设备配置

3.9.1.1 设备所有者配置

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

• [C-1-1] 必须支持将设备政策客户端 (DPC) 注册为 设备所有者应用，如下所述
  • 当设备实现尚未配置用户数据时，它
    • [C-1-3] 必须为 DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) 报告 true。
    • [C-1-4] 必须响应 intent 操作 android.app.action.PROVISION_MANAGED_DEVICE，将 DPC 应用注册为设备所有者应用。
    • [C-1-5] 如果设备通过功能标志 android.hardware.nfc 声明支持近场通信 (NFC)，并且收到包含 MIME 类型为 MIME_TYPE_PROVISIONING_NFC 的记录的 NFC 消息，则必须将 DPC 应用注册为设备所有者应用。
  • 当设备实现具有用户数据时，它
    • [C-1-6] 必须为 DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) 报告 false。
    • [C-1-7] 不得再将任何 DPC 应用注册为设备所有者应用。
• [C-1-2] 在配置过程中，必须要求采取某些肯定性操作来同意将应用设置为设备所有者。同意可以通过用户操作或配置期间的某些编程方式获得，但不得硬编码或阻止使用其他设备所有者应用。

如果设备实现声明了 android.software.device_admin，但也包含专有的设备所有者管理解决方案，并提供一种机制来将解决方案中配置的应用提升为“设备所有者等效项”，使其成为标准 Android DevicePolicyManager API 识别的标准“设备所有者”，则它们

• [C-2-1] 必须有一个流程来验证要提升的特定应用是否属于合法的企业设备管理解决方案，并且该应用已在其专有解决方案中配置为具有与“设备所有者”同等的权限。
• [C-2-2] 在将 DPC 应用注册为“设备所有者”之前，必须显示与 android.app.action.PROVISION_MANAGED_DEVICE 发起的流程相同的 AOSP 设备所有者同意披露信息。
• 可以在设备上拥有用户数据，然后再将 DPC 应用注册为“设备所有者”。

3.9.1.2 托管配置文件配置

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

• [C-1-1] 必须实现 API，允许设备政策控制器 (DPC) 应用成为新的托管配置文件的所有者。

• [C-1-2] 托管配置文件配置过程（由 android.app.action.PROVISION_MANAGED_PROFILE 发起的流程）用户体验必须与 AOSP 实现保持一致。

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

  • 一致的图标或其他用户界面（例如上游 AOSP 信息图标），用于表示特定设置何时受到设备管理员的限制。
  • 简短的解释消息，由设备管理员通过 setShortSupportMessage 提供。
  • DPC 应用的图标。

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] 如果存在托管配置文件，则必须在意图“选择器”中显示可视化界面，以允许用户在托管配置文件和主用户之间转发意图（如果设备政策控制器启用此功能）。
• [C-1-7] 如果存在托管配置文件，则必须为主要用户和托管配置文件公开以下用户界面
  • 主要用户和托管配置文件的电池、位置信息、移动数据和存储使用情况的单独核算。
  • 主要用户或托管配置文件中安装的 VPN 应用的独立管理。
  • 主要用户或托管配置文件中安装的应用的独立管理。
  • 主要用户或托管配置文件中的帐户的独立管理。
• [C-1-8] 必须确保预装的拨号器、联系人和消息应用可以从托管配置文件（如果存在）以及主要配置文件中搜索和查找来电者信息（如果设备政策控制器允许）。
• [C-1-9] 必须确保它满足启用多用户的设备的所有适用安全要求（请参阅第 9.5 节），即使托管配置文件不计为除主要用户之外的另一个用户。
• [C-1-10] 必须支持指定单独的锁屏，以满足以下要求，从而授予对在托管配置文件中运行的应用的访问权限。
  • 设备实现必须遵守 DevicePolicyManager.ACTION_SET_NEW_PASSWORD intent，并显示界面以配置托管配置文件的单独锁屏凭据。
  • 托管配置文件的锁屏凭据必须使用与父配置文件相同的凭据存储和管理机制，如 Android 开源项目站点中所述。
  • DPC 密码政策 必须仅适用于托管配置文件的锁屏凭据，除非在 getParentProfileInstance 返回的 DevicePolicyManager 实例上调用。
• 当托管配置文件中的联系人显示在预装的通话记录、通话中 UI、正在进行和未接来电通知、联系人和消息应用中时，它们应该使用与指示托管配置文件应用相同的徽章进行标记。

3.9.3 托管用户支持

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

• [C-1-1] 当 isLogoutEnabled 返回 true 时，必须提供用户界面，以便从当前用户注销并切换回多用户会话中的主要用户。用户界面必须可从锁屏界面访问，而无需解锁设备。

3.10. 无障碍功能

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

如果设备实现支持第三方无障碍功能服务，则它们

• [C-1-1] 必须按照 无障碍功能 API SDK 文档中的描述，提供 Android 无障碍功能框架的实现。
• [C-1-2] 必须生成无障碍功能事件，并将相应的 AccessibilityEvent 传递给所有已注册的 AccessibilityService 实现，如 SDK 文档中所述。
• [C-1-3] 必须遵守 android.settings.ACCESSIBILITY_SETTINGS intent，以提供用户可访问的机制来启用和停用第三方无障碍功能服务以及预装的无障碍功能服务。
• [C-1-4] 当启用的无障碍功能服务声明了 AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON 时，必须在系统的导航栏中添加一个按钮，允许用户控制无障碍功能服务。请注意，对于没有系统导航栏的设备实现，此要求不适用，但设备实现应该提供用户界面来控制这些无障碍功能服务。

如果设备实现包含预装的无障碍功能服务，则它们

• [C-2-1] 当数据存储使用基于文件的加密 (FBE) 进行加密时，必须将这些预装的无障碍功能服务实现为 Direct Boot Aware 应用。
• 应该在开箱即用设置流程中提供一种机制，供用户启用相关的无障碍功能服务，以及调整字体大小、显示大小和放大手势的选项。

3.11. 文本转语音

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

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

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

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

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

3.12. TV 输入框架

Android 电视输入框架 (TIF) 简化了向 Android 电视设备交付直播内容的过程。TIF 提供了一个标准 API，用于创建控制 Android 电视设备的输入模块。

如果设备实现支持 TIF，则它们

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

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() 获取的图标，以及通过 getTitle() 获取的标题，如 MediaDescription 中所述。可以缩短标题以符合安全法规（例如，驾驶员分心）。

• [C-1-3] 必须在显示此第三方应用提供的内容时始终显示第三方应用图标。

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

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

3.15. 即时应用

设备实现必须满足以下要求

• [C-0-1] 即时应用必须仅被授予 android:protectionLevel 设置为 "instant" 的权限。
• [C-0-2] 即时应用不得通过 隐式 Intent 与已安装的应用进行交互，除非满足以下条件之一
  • 组件的 Intent 模式过滤器已公开，并且具有 CATEGORY_BROWSABLE
  • 操作是 ACTION_SEND、ACTION_SENDTO、ACTION_SEND_MULTIPLE 之一
  • 目标通过 android:visibleToInstantApps 显式公开
• [C-0-3] 除非组件通过 android:visibleToInstantApps 公开，否则即时应用不得与已安装的应用显式交互。
• [C-0-4] 已安装的应用不得查看设备上即时应用的详细信息，除非即时应用显式连接到已安装的应用。
• 设备实现必须提供以下用户界面，以便与即时应用进行交互。AOSP 通过默认的 System UI、“设置”和启动器满足这些要求。设备实现
  • [C-0-5] 必须提供用户界面，以查看和删除本地缓存的每个单独应用包的即时应用。
  • [C-0-6] 在即时应用在前台运行时，必须提供可以折叠的持久性用户通知。此用户通知必须包括即时应用不需要安装，并提供用户界面，将用户定向到“设置”中的应用信息屏幕。对于通过 Web Intent 启动的即时应用，如通过将操作设置为 Intent.ACTION_VIEW 且方案为“http”或“https”的 Intent 定义的，如果设备上有浏览器可用，则额外的用户界面应该允许用户不启动即时应用，而是使用配置的 Web 浏览器启动关联的链接。
  • [C-0-7] 如果设备上提供了“最近使用”功能，则必须允许从“最近使用”功能访问正在运行的即时应用。

3.16. 伴侣设备配对

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

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

• [C-1-1] 必须声明功能标志 FEATURE_COMPANION_DEVICE_SETUP 。
• [C-1-2] 必须确保完全实现 android.companion 包中的 API。
• [C-1-3] 必须提供用户界面，供用户选择/确认伴侣设备存在且可操作。

3.17. 重量级应用

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

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

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

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

4. 应用封装兼容性

设备实现

• [C-0-1] 必须能够安装和运行由 官方 Android SDK 中包含的“aapt”工具生成的 Android“.apk”文件。
• 由于上述要求可能具有挑战性，建议设备实现使用 AOSP 参考实现的软件包管理系统。

设备实现

• [C-0-2] 必须支持使用 APK 签名方案 v3、APK 签名方案 v2 和 JAR 签名验证“.apk”文件。
• [C-0-3] 不得以阻止这些文件在其他兼容设备上正确安装和运行的方式扩展 .apk、Android 清单、Dalvik 字节码 或 RenderScript 字节码格式。

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

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

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

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

• 应该提供用户界面，以授予/撤销每个应用从未知来源安装应用的权限，但可以选择将其实现为无操作，并为 startActivityForResult() 返回 RESULT_CANCELED，如果设备实现不想允许用户拥有此选择权。但是，即使在这种情况下，它们应该向用户指示为什么没有提供此类选择。

• [C-0-7] 在启动已通过相同的系统 API PackageManager.setHarmfulAppWarning 标记为可能有害的应用中的 Activity 之前，必须向用户显示带有警告字符串的警告对话框，该警告字符串通过系统 API PackageManager.setHarmfulAppWarning 提供。

• 应该在警告对话框上提供用户界面，以选择卸载或启动应用。

5. 多媒体兼容性

设备实现

• [C-0-1] 必须支持 第 5.1 节 中定义的每种和所有由 MediaCodecList 声明的编解码器的媒体格式、编码器、解码器、文件类型和容器格式。
• [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 中“动态范围控制 (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。
• [SR] 强烈建议所有 AAC 音频解码器都满足上述 C-2-1 和 C-2-2 要求。

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

• [C-3-1] 响度和 DRC 元数据必须按照 MPEG-D DRC 动态范围控制配置文件级别 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 动态范围控制配置文件的响度和动态范围控制。

如果支持 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 位本机字节序音频帧。

5.1.3. 音频编解码器详情

5.1.4. 图像编码

有关更多详细信息，请参见 5.1.6. 图像编解码器详情。

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

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

如果设备实现通过 android.media.MediaCodec 支持 HEIC 编码，媒体类型为 MIMETYPE_IMAGE_ANDROID_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] HEIF (HEIC)

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

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

5.1.6. 图像编解码器详情

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

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

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

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

5.1.7. 视频编解码器

• 为了获得可接受的网络视频流和视频会议服务质量，设备实现应使用满足 要求 的硬件 VP8 编解码器。

如果设备实现包含视频解码器或编码器

• [C-1-1] 视频编解码器必须支持输出和输入字节缓冲区大小，这些大小应能容纳标准和配置所要求的最大可行压缩和未压缩帧，但也不应过度分配。

• [C-1-2] 视频编码器和解码器必须通过 CodecCapabilities 支持 YUV420 8:8:8 灵活颜色格式 (COLOR_FormatYUV420Flexible)。

• [C-1-3] 视频编码器和解码器必须支持至少一种平面或半平面 YUV420 8:8:8 颜色格式：COLOR_FormatYUV420PackedPlanar（等效于 COLOR_FormatYUV420Planar）或 COLOR_FormatYUV420PackedSemiPlanar（等效于 COLOR_FormatYUV420SemiPlanar）。强烈建议同时支持两者。

• [SR] 强烈建议视频编码器和解码器支持至少一种硬件优化的平面或半平面 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. 视频编解码器列表

5.1.9. 媒体编解码器安全性

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

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

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

• [C-1-1] 必须按照 Android 开源项目中的方式，通过 OMX 或 Codec 2.0 API（或两者）提供对媒体编解码器的支持，并且不得禁用或规避安全保护。这并非特别意味着每个编解码器都必须使用 OMX 或 Codec 2.0 API，而仅意味着必须提供对至少一个 API 的支持，并且对可用 API 的支持必须包括存在的安全保护。
• [C-SR] 强烈建议包括对 Codec 2.0 API 的支持。

如果设备实现不支持 Codec 2.0 API，则它们

• [C-2-1] 必须为设备支持的每种媒体格式和类型（编码器或解码器）包含来自 Android 开源项目的相应 OMX 软件编解码器（如果可用）。
• [C-2-2] 名称以 "OMX.google." 开头的编解码器必须基于其 Android 开源项目源代码。
• [C-SR] 强烈建议 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] 编解码器名称不得具有误导性。例如，名为 "decoders" 的编解码器必须支持解码，而名为 "encoders" 的编解码器必须支持编码。名称包含媒体格式的编解码器必须支持这些格式。

如果设备实现支持视频编解码器

• [C-2-1] 所有视频编解码器都必须发布以下尺寸的可实现帧率数据（如果编解码器支持这些尺寸）

• [C-2-2] 被描述为硬件加速的视频编解码器必须发布性能点信息。除非另一个受支持的标准性能点涵盖，否则它们必须各自列出所有受支持的标准性能点（在 PerformancePoint API 中列出）。
• 此外，如果它们支持除列出的标准性能点以外的可持续视频性能，则应发布扩展性能点。

5.2. 视频编码

如果设备实现支持任何视频编码器并将其提供给第三方应用，则它们

• 在两个滑动窗口中，不应超过帧内帧 (I 帧) 间隔之间比特率的 15% 以上。
• 在 1 秒的滑动窗口中，不应超过比特率的 100% 以上。

如果设备实现包括对角线长度至少为 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] 所有硬件加速的视频和图像编码器都必须支持从硬件摄像头编码帧。
• 应支持通过所有视频或图像编码器从硬件摄像头编码帧。

5.2.1. H.263

如果设备实现支持 H.263 编码器并将其提供给第三方应用，则它们

• [C-1-1] 必须支持 Baseline Profile Level 45。
• 应支持受支持编码器的动态可配置比特率。

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] 必须支持下表中的编码配置文件。

5.2.3. VP8

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

• [C-1-1] 必须支持 SD 视频编码配置文件。
• 应支持以下 HD（高清）视频编码配置文件。
• [C-1-2] 必须支持写入 Matroska WebM 文件。
• 应提供满足 WebM 项目 RTC 硬件编码要求 的硬件 VP8 编解码器，以确保网络视频流和视频会议服务具有可接受的质量。

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

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

5.2.4. VP9

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

• [C-1-2] 必须支持 Profile 0 Level 3。
• [C-1-1] 必须支持写入 Matroska WebM 文件。
• [C-1-3] 必须生成 CodecPrivate 数据。
• 应支持下表中指示的 HD 解码配置文件。
• [SR] 如果有硬件编码器，则强烈建议支持下表中指示的 HD 解码配置文件。

如果设备实现声明通过 Media API 支持 Profile 2 或 Profile 3

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

5.2.5. H.265

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

• [C-1-1] 必须支持 Main Profile Level 3。
• 应支持下表中指示的 HD 编码配置文件。
• [SR] 如果有硬件编码器，则强烈建议支持下表中指示的 HD 编码配置文件。

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 和 Level 45。

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 视频解码配置文件。

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 解码中的至少一种。

如果设备实现声明通过 Media API 支持 HDR 配置文件（HEVCProfileMain10HDR10、HEVCProfileMain10HDR10Plus）

• [C-3-1] 设备实现必须接受来自应用程序的所需 HDR 元数据（所有 HDR 配置文件的 MediaFormat#KEY_HDR_STATIC_INFO），使用 MediaCodec API，并支持从比特流和/或容器中提取所需的 HDR 元数据（所有 HDR 配置文件的 MediaFormat#KEY_HDR_STATIC_INFO，以及 HDR10Plus 配置文件的 MediaFormat#KEY_HDR10_PLUS_INFO），如相关规范所定义。它们还必须支持从比特流和/或容器中输出所需的 HDR 元数据（所有 HDR 配置文件的 MediaFormat#KEY_HDR_STATIC_INFO），如相关规范所定义。

• [C-SR] 强烈建议设备实现通过 MediaCodec#getOutputFormat(int). 输出 HDR10Plus 配置文件的元数据 MediaFormat#KEY_HDR10_PLUS_INFO。

• [C-3-2] 设备实现必须在设备屏幕或标准视频输出端口（例如，HDMI）上正确显示 HEVCProfileMain10HDR10 配置文件的 HDR 内容。

• [C-SR] 强烈建议设备实现在设备屏幕或标准视频输出端口（例如，HDMI）上正确显示 HEVCProfileMain10HDR10Plus 配置文件的 HDR 内容。

5.3.6. VP8

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

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

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

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

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 解码中的至少一种。

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

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

如果设备实现声明通过媒体 API 支持 HDR 配置文件（VP9Profile2HDR、VP9Profile2HDR10Plus、VP9Profile3HDR、VP9Profile3HDR10Plus）

• [C-4-1] 设备实现必须接受来自应用程序的所需 HDR 元数据（所有 HDR 配置文件的 MediaFormat#KEY_HDR_STATIC_INFO，以及 HDR10Plus 配置文件的参数 MediaCodec#PARAMETER_KEY_HDR10_PLUS_INFO），使用 MediaCodec API，并支持从比特流和/或容器中提取所需的 HDR 元数据（所有 HDR 配置文件的 MediaFormat#KEY_HDR_STATIC_INFO，以及 HDR10Plus 配置文件的 MediaFormat#KEY_HDR10_PLUS_INFO），如相关规范所定义。它们还必须支持从比特流和/或容器中输出所需的 HDR 元数据（所有 HDR 配置文件的 MediaFormat#KEY_HDR_STATIC_INFO），如相关规范所定义。

• [C-4-2] 设备实现必须在设备屏幕或标准视频输出端口（例如，HDMI）上正确显示 VP9Profile2HDR 和 VP9Profile3HDR 配置文件的 HDR 内容。

• [C-SR] 强烈建议设备实现通过 MediaCodec#getOutputFormat(int) 输出 HDR10Plus 配置文件的元数据 MediaFormat#KEY_HDR10_PLUS_INFO。

• [C-SR] 强烈建议设备实现在设备屏幕或标准视频输出端口（例如，HDMI）上正确显示 VP9Profile2HDR10Plus 和 VP9Profile3HDR10Plus 配置文件的 HDR 内容。

5.3.8. Dolby Vision

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

• [C-1-1] 必须提供支持 Dolby Vision 的提取器。
• [C-1-2] 必须在设备屏幕或标准视频输出端口（例如，HDMI）上正确显示 Dolby Vision 内容。
• [C-1-3] 必须将向后兼容的基层（如果存在）的轨道索引设置为与组合的 Dolby Vision 层的轨道索引相同。

5.3.9. AV1

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

• [C-1-1] 必须支持 Profile 0，包括 10 位内容。

5.4. 音频录制

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

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

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

• [C-1-1] 必须允许捕获具有以下特征的原始音频内容

  • 格式：线性 PCM，16 位
  • 采样率：8000、11025、16000、44100、48000 Hz
  • 声道：单声道

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

  • 格式：线性 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 访问的可用麦克风的信息，以及当前活动的麦克风，这些麦克风可供第三方应用程序通过 AudioRecord.getActiveMicrophones() 和 MediaRecorder.getActiveMicrophones() API 访问。如果设备实现允许 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 为 ±3 dB。
• 应设置语音识别音频流的输入灵敏度，使得在 1000 Hz 处 90 dB 声功率级 (SPL) 源产生 16 位样本的 RMS 为 2500。
• 应录制语音识别音频流，以便 PCM 幅度级别在线性跟踪输入 SPL 变化，范围至少为 30 dB，从麦克风处 90 dB SPL 的 -18 dB 到 +12 dB re。
• 应录制语音识别音频流，使得在麦克风处 1 kHz、90 dB SPL 输入电平下的总谐波失真 (THD) 小于 1%。

如果设备实现声明 android.hardware.microphone 和针对语音识别调整的噪声抑制（降低）技术，则它们

• [C-2-1] 必须允许使用 android.media.audiofx.NoiseSuppressor API 控制此音频效果。
• [C-2-2] 必须通过 AudioEffect.Descriptor.uuid 字段唯一标识每种噪声抑制技术实现。

5.4.3. 用于回放重路由的捕获

android.media.MediaRecorder.AudioSource 类包含 REMOTE_SUBMIX 音频源。

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

• [C-1-1] 必须正确实现 REMOTE_SUBMIX 音频源，以便当应用使用 android.media.AudioRecord API 从此音频源录制时，它会捕获除以下各项之外的所有音频流的混合音频：

  • AudioManager.STREAM_RING
  • AudioManager.STREAM_ALARM
  • AudioManager.STREAM_NOTIFICATION

5.4.4. 声学回声消除器

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

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

如果设备实现在选择 AudioSource.VOICE_COMMUNICATION 时，在捕获音频路径中插入了声学回声消除器，则它们

• [C-SR] 强烈建议通过 AcousticEchoCanceler API 方法 AcousticEchoCanceler.isAvailable() 声明此功能
• [C-SR] 强烈建议允许使用 AcousticEchoCanceler API 控制此音频效果。
• [C-SR] 强烈建议通过 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.4.6. 麦克风增益级别

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

• 应该在中频范围内表现出近似平坦的幅度-频率特性：具体而言，对于用于录制语音识别音频源的每个麦克风，在 100 Hz 到 4000 Hz 范围内为 ±3dB。
• 应该设置音频输入灵敏度，以便在 90 dB 声压级 (SPL) 下播放的 1000 Hz 正弦波音源对于 16 位采样 (或浮点/双精度采样的 -22.35 dB 满量程) 产生 RMS 为 2500 的响应，这适用于用于录制语音识别音频源的每个麦克风。
• [C-SR] 强烈建议在低频范围内表现出幅度级别：具体而言，对于用于录制语音识别音频源的每个麦克风，在 5 Hz 到 100 Hz 范围内，与中频范围相比为 ±20 dB。
• [C-SR] 强烈建议在高频范围内表现出幅度级别：具体而言，对于用于录制语音识别音频源的每个麦克风，在 4000 Hz 到 22 KHz 范围内，与中频范围相比为 ±30 dB。

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、32000、44100、48000
    • 单声道和立体声下的 96000

• 应该允许播放具有以下特征的原始音频内容：

  • 采样率: 24000

5.5.2. 音频效果

Android 为设备实现提供用于音频效果的 API。

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

• [C-1-1] 必须支持通过 AudioEffect 子类 Equalizer 和 LoudnessEnhancer 控制的 EFFECT_TYPE_EQUALIZER 和 EFFECT_TYPE_LOUDNESS_ENHANCER 实现。
• [C-1-2] 必须支持可视化工具 API 实现，可通过 Visualizer 类进行控制。
• [C-1-3] 必须支持通过 AudioEffect 子类 DynamicsProcessing 控制的 EFFECT_TYPE_DYNAMICS_PROCESSING 实现。
• 应该支持通过 AudioEffect 子类 BassBoost、EnvironmentalReverb、PresetReverb 和 Virtualizer 控制的 EFFECT_TYPE_BASS_BOOST、EFFECT_TYPE_ENV_REVERB、EFFECT_TYPE_PRESET_REVERB 和 EFFECT_TYPE_VIRTUALIZER 实现。
• [C-SR] 强烈建议在浮点和多声道中支持效果。

5.5.3. 音频输出音量

汽车设备实现

• 应该允许使用 AudioAttributes 中定义的内容类型或用法以及 android.car.CarAudioManager 中公开定义的车载音频用法，分别调整每个音频流的音频音量。

5.6. 音频延迟

音频延迟是指音频信号通过系统时的时间延迟。许多应用类别都依赖于短延迟来实现实时音效。

在本节中，使用以下定义：

• 输出延迟。指应用写入 PCM 编码数据帧的时间与在设备上传感器上向环境呈现相应的声音或信号通过端口离开设备并可在外部观察到的时间之间的时间间隔。
• 冷启动输出延迟。指第一个帧的输出延迟，此时音频输出系统在请求之前一直处于空闲和断电状态。
• 持续输出延迟。指设备正在播放音频后，后续帧的输出延迟。
• 输入延迟。指环境在设备上传感器上向设备呈现声音或信号通过端口进入设备的时间与应用读取相应的 PCM 编码数据帧的时间之间的时间间隔。
• 丢失输入。指输入信号的初始部分，该部分不可用或无法使用。
• 冷启动输入延迟。指丢失输入时间和第一个帧的输入延迟之和，此时音频输入系统在请求之前一直处于空闲和断电状态。
• 持续输入延迟。指设备正在捕获音频时，后续帧的输入延迟。
• 冷启动输出抖动。指冷启动输出延迟值的不同测量值之间的变异性。
• 冷启动输入抖动。指冷启动输入延迟值的不同测量值之间的变异性。
• 持续往返延迟。指持续输入延迟、持续输出延迟和一个缓冲区周期的总和。缓冲区周期允许应用处理信号的时间，以及应用缓解输入和输出流之间相位差的时间。
• OpenSL ES PCM 缓冲区队列 API。指 OpenSL ES API 在 Android NDK 中的与 PCM 相关的 API 集。
• AAudio 原生音频 API。指 AAudio API 在 Android NDK 中的 API 集。
• 时间戳。指由流中的相对帧位置以及估计的帧进入或离开关联端点上的音频处理管道的时间组成的对。另请参阅 AudioTimestamp。
• 故障。指音频信号中的临时中断或不正确的采样值，通常是由输出的 缓冲区欠载、输入的缓冲区溢出或任何其他数字或模拟噪声源引起的。

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

• [C-1-1] 由 AudioTrack.getTimestamp 和 AAudioStream_getTimestamp 返回的输出时间戳的准确度在 +/- 2 毫秒以内。
• [C-1-2] 冷启动输出延迟为 500 毫秒或更短。

如果设备实现声明了 android.hardware.audio.output，则强烈建议它们满足或超过以下要求：

• [C-SR] 冷启动输出延迟为 100 毫秒或更短。强烈建议现在运行此 Android 版本的现有设备和新设备满足这些要求。在 2021 年的未来平台版本中，我们将要求冷启动输出延迟必须为 200 毫秒或更短。
• [C-SR] 持续输出延迟为 45 毫秒或更短。
• [C-SR] 尽量减小冷启动输出抖动。
• [C-SR] 由 AudioTrack.getTimestamp 和 AAudioStream_getTimestamp 返回的输出时间戳的准确度在 +/- 1 毫秒以内。

如果设备实现在任何初始校准之后，在使用 OpenSL ES PCM 缓冲区队列和 AAudio 原生音频 API 时，在至少一个受支持的音频输出设备上满足上述关于持续输出延迟和冷启动输出延迟的要求，则它们

• [C-SR] 强烈建议通过声明 android.hardware.audio.low_latency 功能标志来报告低延迟音频。
• [C-SR] 强烈建议通过 AAudio API 满足低延迟音频的要求。
• [C-SR] 强烈建议确保对于从 AAudioStream_getPerformanceMode() 返回 AAUDIO_PERFORMANCE_MODE_LOW_LATENCY 的流，由 AAudioStream_getFramesPerBurst() 返回的值小于或等于由 android.media.AudioManager.getProperty(String) 为属性键 AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER 返回的值。

如果设备实现未通过 OpenSL ES PCM 缓冲区队列和 AAudio 原生音频 API 满足低延迟音频的要求，则它们

• [C-2-1] 不得报告支持低延迟音频。

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

• [C-3-1] 将输入时间戳（由 AudioRecord.getTimestamp 或 AAudioStream_getTimestamp 返回）的误差限制在 +/- 2 毫秒以内。“误差”在此处是指与正确值的偏差。
• [C-3-2] 冷启动输入延迟为 500 毫秒或更短。

如果设备实现包含 android.hardware.microphone，则强烈建议它们满足以下输入音频要求：

• [C-SR] 冷启动输入延迟为 100 毫秒或更短。强烈建议现在运行此 Android 版本的现有设备和新设备满足这些要求。在 2021 年的未来平台版本中，我们将要求冷启动输入延迟必须为 200 毫秒或更短。
• [C-SR] 持续输入延迟为 30 毫秒或更短。
• [C-SR] 持续往返延迟为 50 毫秒或更短。
• [C-SR] 尽量减小冷启动输入抖动。
• [C-SR] 将输入时间戳（由 AudioRecord.getTimestamp 或 AAudioStream_getTimestamp 返回）的误差限制在 +/- 1 毫秒以内。

5.7. 网络协议

设备实现必须支持 Android SDK 文档中指定的用于音频和视频播放的媒体网络协议。

如果设备实现包含音频或视频解码器，则它们

• [C-1-1] 必须支持 第 5.1 节中通过 HTTP(S) 传输的所有必需编解码器和容器格式。

• [C-1-2] 必须支持下表“媒体分段格式”中显示的通过 HTTP Live Streaming 草案协议版本 7 传输的媒体分段格式。

• [C-1-3] 必须支持下表“RTSP”中显示的以下 RTP 音频视频配置文件和相关编解码器。有关例外情况，请参阅 第 5.1 节中的表格脚注。

媒体分段格式

RTSP (RTP, SDP)

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 节
  • USB 外围设备模式，第 7.7 节
  • 以中央角色运行的低功耗蓝牙 MIDI，第 7.4.3 节

• [C-1-2] 必须支持应用间 MIDI 软件传输（虚拟 MIDI 设备）

• [C-1-3] 必须包含 libamidi.so（原生 MIDI 支持）

5.10. 专业音频

如果设备实现通过 android.content.pm.PackageManager 类报告支持 android.hardware.audio.pro 功能，则它们

• [C-1-1] 必须报告支持 android.hardware.audio.low_latency 功能。
• [C-1-2] 必须具有持续往返音频延迟，如第 5.6 节 音频延迟中所定义，在至少一个受支持的路径上为 20 毫秒或更短，并且应该为 10 毫秒或更短。
• [C-1-3] 必须包含支持 USB 主机模式和 USB 外围设备模式的 USB 端口。
• [C-1-4] 必须报告支持 android.software.midi 功能。
• [C-1-5] 必须使用 OpenSL ES PCM 缓冲区队列 API 和 AAudio 原生音频 API 的至少一个路径来满足延迟和 USB 音频要求。
• [SR] 强烈建议使用 AAudio 原生音频 API 通过 MMAP 路径来满足延迟和 USB 音频要求。
• [C-1-6] 必须具有 200 毫秒或更短的冷启动输出延迟。
• [C-1-7] 必须具有 200 毫秒或更短的冷启动输入延迟。
• [SR] 强烈建议在音频处于活动状态且 CPU 负载变化时提供一致的 CPU 性能。应该使用 Android 应用版本的 SynthMark 提交 ID 09b13c6f49ea089f8c31e5d035f912cc405b7ab8 来测试此性能。SynthMark 使用在模拟音频框架上运行的软件合成器来测量系统性能。SynthMark 应用需要使用“Automated Test”选项运行，并达到以下结果：
  • voicemark.90 >= 32 个声音
  • latencymark.fixed.little <= 15 毫秒
  • latencymark.dynamic.little <= 50 毫秒

有关基准测试的说明，请参阅 SynthMark 文档。

• 应该尽量减小音频时钟相对于标准时间的不准确性和漂移。
• 当音频时钟和 CPU CLOCK_MONOTONIC 都处于活动状态时，应该尽量减小音频时钟相对于 CPU CLOCK_MONOTONIC 的漂移。
• 应该尽量减小设备上传感器上的音频延迟。
• 应该尽量减小 USB 数字音频上的音频延迟。
• 应该记录所有路径上的音频延迟测量值。
• 应该尽量减小音频缓冲区完成回调进入时间的抖动，因为这会影响回调可用的完整 CPU 带宽的百分比。
• 应该在正常使用报告的延迟下提供零音频故障。
• 应该提供零声道间延迟差异。
• 应该尽量减小所有传输上的 MIDI 平均延迟。
• 应该尽量减小所有传输上的负载（抖动）下的 MIDI 延迟变化。
• 应该在所有传输上提供准确的 MIDI 时间戳。
• 应该尽量减小设备上传感器上的音频信号噪声，包括冷启动后立即的时间段。
• 当音频时钟和对应的端点的输入侧和输出侧都处于活动状态时，应该在它们之间提供零音频时钟差异。对应端点的示例包括设备上的麦克风和扬声器，或音频插孔输入和输出。
• 当输入侧和输出侧都处于活动状态时，应该在同一线程上处理对应端点的输入侧和输出侧的音频缓冲区完成回调，并在从输入回调返回后立即进入输出回调。或者，如果无法在同一线程上处理回调，则应在进入输入回调后不久进入输出回调，以允许应用具有输入侧和输出侧的一致时序。
• 应该尽量减小对应端点的输入侧和输出侧的 HAL 音频缓冲之间的相位差。
• 应该尽量减小触摸延迟。
• 应该尽量减小负载（抖动）下的触摸延迟变化。
• 应该具有从触摸输入到音频输出的小于或等于 40 毫秒的延迟。

如果设备实现满足上述所有要求，则它们

• [SR] 强烈建议通过 android.content.pm.PackageManager 类报告支持 android.hardware.audio.pro 功能。

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

• [C-2-1] 必须使音频插孔路径上的持续往返音频延迟为 20 毫秒或更短。
• [SR] 强烈建议遵守有线音频耳机规范 (v1.1)的移动设备（插孔）规范部分。
• 音频插孔路径上的持续往返音频延迟应该为 10 毫秒或更短。

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

• [C-3-1] 必须实现 USB 音频类。
• [C-3-2] 必须使使用 USB 音频类的 USB 主机模式端口上的持续往返音频延迟为 20 毫秒或更短。
• 使用 USB 音频类的 USB 主机模式端口上的持续往返音频延迟应该为 10 毫秒或更短。
• [C-SR] 强烈建议在使用也支持这些要求的 USB 音频外围设备时，支持高达每个方向 8 个声道、96 kHz 采样率和 24 位或 32 位深度的同步 I/O。

如果设备实现包含 HDMI 端口，则它们

• 应该在至少一种配置中支持以立体声和八声道输出，且位深为 20 位或 24 位，频率为 192 kHz，且不损失位深或重采样。

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 范围内为 ±10dB。

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

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

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

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

• [C-1-7] 必须使在 90 dB SPL 输入电平下、在用于录制未处理音频源的每个麦克风上，1 kHZ 的总谐波失真 (THD) 小于 1%。

• 路径中不得有任何其他信号处理（例如，自动增益控制、高通滤波器或回声消除），除了将电平提升到所需范围的电平乘法器。换句话说：

• [C-1-8] 如果架构中出于任何原因存在任何信号处理，则必须禁用它，并有效地为信号路径引入零延迟或额外延迟。
• [C-1-9] 允许路径上存在电平乘法器，但不得为信号路径引入延迟或时延。

所有 SPL 测量均在紧邻被测麦克风的位置进行。对于多麦克风配置，这些要求适用于每个麦克风。

如果设备实现声明了 android.hardware.microphone 但不支持未处理的音频源，则它们

• [C-2-1] 必须为 AudioManager.getProperty(PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED) API 方法返回 null，以正确指示缺少支持。
• [SR] 仍然强烈建议满足尽可能多的未处理录音源信号路径要求。

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

6.1. 开发者工具

设备实现

• [C-0-1] 必须支持 Android SDK 中提供的 Android 开发者工具。

• Android 调试桥 (adb)

  • [C-0-2] 必须支持 Android SDK 中记录的 adb 和 AOSP 中提供的 shell 命令，应用开发者可以使用这些命令，包括 dumpsys cmd stats
  • [C-SR] 强烈建议支持 shell 命令 cmd testharness。
  • [C-0-3] 不得更改通过 dumpsys 命令记录的设备系统事件（batterystats、diskstats、指纹、graphicsstats、netstats、通知、procstats）的格式或内容。
  • [C-0-10] 必须完整记录以下事件，并使其可供 cmd stats shell 命令和 StatsManager 系统 API 类访问和使用。
    • ActivityForegroundStateChanged
    • AnomalyDetected
    • AppBreadcrumbReported
    • AppCrashOccurred
    • AppStartOccurred
    • BatteryLevelChanged
    • BatterySaverModeStateChanged
    • BleScanResultReceived
    • BleScanStateChanged
    • ChargingStateChanged
    • DeviceIdleModeStateChanged
    • ForegroundServiceStateChanged
    • GpsScanStateChanged
    • JobStateChanged
    • PluggedStateChanged
    • ScheduledJobStateChanged
    • ScreenStateChanged
    • SyncStateChanged
    • SystemElapsedRealtime
    • UidProcessStateChanged
    • WakelockStateChanged
    • WakeupAlarmOccurred
    • WifiLockStateChanged
    • WifiMulticastLockStateChanged
    • WifiScanStateChanged
  • [C-0-4] 必须使设备端 adb 守护程序在默认情况下处于非活动状态，并且必须存在用户可访问的机制来打开 Android 调试桥。
  • [C-0-5] 必须支持安全 adb。Android 包括对安全 adb 的支持。安全 adb 允许在已知的经过身份验证的主机上使用 adb。

  • [C-0-6] 必须提供一种机制，允许从主机连接 adb。例如：

    • 不带支持外围设备模式的 USB 端口的设备实现必须通过局域网（如以太网或 Wi-Fi）来实现 adb。
    • 必须为 Windows 7、9 和 10 提供驱动程序，允许开发人员使用 adb 协议连接到设备。

• Dalvik 调试监视器服务 (ddms)

  • [C-0-7] 必须支持 Android SDK 中记录的所有 ddms 功能。由于 ddms 使用 adb，因此默认情况下 ddms 支持应处于非活动状态，但只要用户已激活上述 Android 调试桥，就必须支持 ddms。
• Monkey
  • [C-0-8] 必须包含 Monkey 框架，并使其可供应用程序使用。
• SysTrace
  • [C-0-9] 必须支持 Android SDK 中记录的 systrace 工具。Systrace 必须默认处于非活动状态，并且必须有用户可访问的机制来启用 Systrace。

• Perfetto

  • [C-SR] 强烈建议向 shell 用户公开 /system/bin/perfetto 二进制文件，该二进制文件的 cmdline 符合perfetto 文档。
  • [C-SR] 强烈建议 perfetto 二进制文件接受符合perfetto 文档中定义的架构的 protobuf 配置作为输入。
  • [C-SR] 强烈建议 perfetto 二进制文件将符合perfetto 文档中定义的架构的 protobuf 跟踪记录作为输出写入。
  • [C-SR] 强烈建议通过 perfetto 二进制文件至少提供perfetto 文档中描述的数据源。

• 测试工具模式

  如果设备实现支持 shell 命令 cmd testharness 并运行 cmd testharness enable，则它们

  • [C-2-1] 对于 ActivityManager.isRunningInUserTestHarness() 必须返回 true
  • [C-2-2] 必须按照测试工具模式文档中的描述实现测试工具模式。

如果设备实现通过 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] 在 SDK 文档允许的情况下，API 方法必须返回 null 值。
• [C-0-5] 在 SDK 文档不允许使用 null 值的情况下，API 方法必须返回类的空操作实现。
• [C-0-6] API 方法不得抛出 SDK 文档中未记录的异常。
• [C-0-7] 对于相同的构建指纹，设备实现必须通过 android.content.pm.PackageManager 类上的 getSystemAvailableFeatures() 和 hasSystemFeature(String) 方法一致地报告准确的硬件配置信息。

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

7.1. 显示和图形

Android 包含一些功能，可以根据设备自动调整应用程序资源和 UI 布局，以确保第三方应用程序在各种硬件配置上良好运行。在所有第三方 Android 兼容应用程序都可以运行的 Android 兼容显示屏上，设备实现必须正确实现这些 API 和行为，本节将详细介绍。

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

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

7.1.1. 屏幕配置

7.1.1.1. 屏幕尺寸和形状

Android UI 框架支持各种不同的逻辑屏幕布局尺寸，并允许应用程序通过带有 SCREENLAYOUT_SIZE_MASK 和 Configuration.smallestScreenWidthDp 的 Configuration.screenLayout 查询当前配置的屏幕布局尺寸。

设备实现

• [C-0-1] 必须报告 Android SDK 文档中定义的 Configuration.screenLayout 的正确布局尺寸。具体而言，设备实现必须报告正确的逻辑密度无关像素 (dp) 屏幕尺寸，如下所示

  • 将 Configuration.uiMode 设置为 UI_MODE_TYPE_WATCH 以外的任何值，并报告 Configuration.screenLayout 为 small 尺寸的设备，必须至少具有 426 dp x 320 dp。
  • 报告 Configuration.screenLayout 为 normal 尺寸的设备，必须至少具有 480 dp x 320 dp。
  • 报告 Configuration.screenLayout 为 large 尺寸的设备，必须至少具有 640 dp x 480 dp。
  • 报告 Configuration.screenLayout 为 xlarge 尺寸的设备，必须至少具有 960 dp x 720 dp。

• [C-0-2] 必须正确遵循应用程序通过 AndroidManifest.xml 中的 <supports-screens> 属性声明的对屏幕尺寸的支持，如 Android SDK 文档中所述。

• 可以具有带圆角的 Android 兼容显示屏。

如果设备实现支持 UI_MODE_TYPE_NORMAL 并包含带圆角的 Android 兼容显示屏，则它们

• [C-1-1] 必须确保圆角的半径小于或等于 38 dp。
• 应包含用户功能以切换到带直角的显示模式。

7.1.1.2. 屏幕宽高比

虽然 Android 兼容显示屏的物理显示屏的宽高比没有限制，但呈现第三方应用的逻辑显示屏的宽高比（可以从通过 view.Display API 和 Configuration API 报告的高度和宽度值中得出）必须满足以下要求

• [C-0-1] 将 Configuration.uiMode 设置为 UI_MODE_TYPE_NORMAL 的设备实现必须具有小于或等于 1.86（约 16:9）的宽高比值，除非应用满足以下条件之一

  • 应用已通过 android.max_aspect 元数据值声明它支持更大的屏幕宽高比。
  • 应用通过 android:resizeableActivity 属性声明它是可调整大小的。
  • 应用的目标 API 级别为 24 或更高，并且未声明会限制允许的宽高比的 android:maxAspectRatio。

• [C-0-2] 将 Configuration.uiMode 设置为 UI_MODE_TYPE_NORMAL 的设备实现必须具有等于或大于 1.3333 (4:3) 的宽高比值，除非应用可以通过满足以下条件之一来拉伸得更宽

  • 应用通过 android:resizeableActivity 属性声明它是可调整大小的。
  • 应用声明了会限制允许的宽高比的 android:minAspectRatio。

• [C-0-3] 将 Configuration.uiMode 设置为 UI_MODE_TYPE_WATCH 的设备实现必须将宽高比值设置为 1.0 (1:1)。

7.1.1.3. 屏幕密度

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

• [C-0-1] 默认情况下，设备实现必须仅通过 DENSITY_DEVICE_STABLE API 报告 DisplayMetrics 上列出的 Android 框架密度之一，并且此值在任何时候都不得更改；但是，设备可以根据用户在初始启动后设置的显示配置更改（例如，显示尺寸）报告不同的任意密度。

• 设备实现应定义在数值上最接近屏幕物理密度的标准 Android 框架密度，除非该逻辑密度将报告的屏幕尺寸推至低于支持的最小值。如果数值上最接近物理密度的标准 Android 框架密度导致屏幕尺寸小于最小支持的兼容屏幕尺寸（320 dp 宽度），则设备实现应报告下一个最低的标准 Android 框架密度。

如果可以更改设备的显示尺寸

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

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

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

• [C-1-1] 必须支持 OpenGL ES 1.1 和 2.0，如 Android SDK 文档中所体现和详述的那样。
• [C-SR] 强烈建议支持 OpenGL ES 3.1。
• 应支持 OpenGL ES 3.2。

如果设备实现支持任何 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-SR] 强烈建议支持 EGL_KHR_partial_update 和 OES_EGL_image_external 扩展。
• 应通过 getString() 方法准确报告它们支持的任何纹理压缩格式，这些格式通常是特定于供应商的。

如果设备实现声明支持 OpenGL ES 3.0、3.1 或 3.2，则它们

• [C-3-1] 除了 libGLESv2.so 库中的 OpenGL ES 2.0 函数符号外，还必须导出这些版本的相应函数符号。
• [SR] 强烈建议支持 OES_EGL_image_external_essl3 扩展。

如果设备实现支持 OpenGL ES 3.2，则它们

• [C-4-1] 必须完全支持 OpenGL ES Android 扩展包。

如果设备实现完全支持 OpenGL ES Android 扩展包，则它们

• [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，则它们

• [SR] 强烈建议包含对 Vulkan 1.1 的支持。

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

• 应包含对 Vulkan 1.1 的支持。

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

• [C-1-1] 必须使用 android.hardware.vulkan.level 和 android.hardware.vulkan.version 功能标记报告正确的整数值。
• [C-1-2] 必须为 Vulkan 原生 API vkEnumeratePhysicalDevices() 枚举至少一个 VkPhysicalDevice。
• [C-1-3] 必须为每个枚举的 VkPhysicalDevice 完全实现 Vulkan 1.0 API。
• [C-1-4] 必须通过 Vulkan 原生 API vkEnumerateInstanceLayerProperties() 和 vkEnumerateDeviceLayerProperties() 枚举应用程序包的原生库目录中名为 libVkLayer*.so 的原生库中包含的层。
• [C-1-5] 除非应用程序将 android:debuggable 属性设置为 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-SR] 强烈建议支持 VK_KHR_driver_properties 和 VK_GOOGLE_display_timing 扩展。

如果设备实现不包含对 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 扩展。

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] 强烈建议支持 GL_EXT_sRGB。

相反，如果设备实现不支持广色域显示屏，则它们

• [C-2-1] 应在 CIE 1931 xyY 空间中覆盖 100% 或更多的 sRGB，尽管屏幕色域未定义。

7.1.5. 传统应用程序兼容模式

Android 指定了一种“兼容模式”，其中框架在“正常”屏幕尺寸等效模式（320dp 宽度）下运行，以使未针对屏幕尺寸独立性之前的旧版本 Android 开发的传统应用程序受益。

7.1.6. 屏幕技术

Android 平台包含一些 API，这些 API 允许应用程序将丰富的图形渲染到 Android 兼容显示屏。除非本文档中另有明确允许，否则设备必须支持 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] 必须完全实现 输入管理框架
• [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] 必须为用户提供启动已安装应用程序的功能，这些应用程序的 Activity 具有设置为 ACTION=MAIN 和 CATEGORY=LAUNCHER 的 <intent-filter>，或者电视设备实现的 CATEGORY=LEANBACK_LAUNCHER。主页功能应该是此用户功能的机制。
• 应为“最近任务”和“返回”功能提供按钮。

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

• [C-1-1] 当其中任何一个功能可访问时，必须可通过单个操作（例如，点击、双击或手势）访问。
• [C-1-2] 必须清楚地指示哪个单一操作会触发每个功能。在按钮上印上可见图标、在屏幕导航栏部分显示软件图标，或在开箱即用设置体验期间引导用户完成分步演示流程都是此类指示的示例。

设备实现

• [SR] 强烈建议不要为 菜单功能 提供输入机制，因为它自 Android 4.0 起已被弃用，转而支持操作栏。

如果设备实现提供“菜单”功能，则它们

• [C-2-1] 只要操作溢出菜单弹出窗口不为空且操作栏可见，就必须显示操作溢出按钮。
• [C-2-2] 不得修改通过在操作栏中选择溢出按钮显示的操作溢出弹出窗口的位置，但在通过选择“菜单”功能显示操作溢出弹出窗口时，可以以修改后的位置在屏幕上呈现操作溢出弹出窗口。

如果设备实现不提供“菜单”功能，为了向后兼容，它们：* [C-SR] 强烈建议在 targetSdkVersion 小于 10 时，通过物理按钮、软件键或手势使应用程序可以使用“菜单”功能。除非与其他导航功能一起隐藏，“菜单”功能应可访问。

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

• [C-4-1] 当其他导航键可访问时，必须使“Assist”功能可通过单个操作（例如，点击、双击或手势）访问。
• [SR] 强烈建议使用长按“主页”功能作为此指定交互。

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

• [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 标志时，从边缘滑动必须表现得像 AOSP 中实现的那样，这在 SDK 中有文档记录。
• [C-7-4] 当前台应用程序设置了 View.SYSTEM_UI_FLAG_IMMERSIVE 或 View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY 标志时，自定义可滑动系统面板必须保持隐藏状态，直到用户调出系统栏（也称为导航栏和状态栏），如 AOSP 中实现的那样。

7.2.4. 触摸屏输入

Android 包含对各种指针输入系统（如触摸屏、触摸板和虚假触摸输入设备）的支持。基于触摸屏的设备实现与显示屏相关联，使用户感觉可以直接操作屏幕上的项目。由于用户直接触摸屏幕，因此系统不需要任何额外的功能来指示正在操作的对象。

设备实现

• 应具有某种类型的指针输入系统（鼠标式或触摸式）。
• 应支持完全独立跟踪的指针。

如果设备实现包括触摸屏（单点触摸或更好），则它们

• [C-1-1] 对于 Configuration.touchscreen API 字段，必须报告 TOUCHSCREEN_FINGER。
• [C-1-2] 必须报告 android.hardware.touchscreen 和 android.hardware.faketouch 功能标记。

如果设备实现包括可以跟踪多个触摸点的触摸屏，则它们

• [C-2-1] 必须报告与设备上特定触摸屏类型对应的适当功能标记 android.hardware.touchscreen.multitouch、android.hardware.touchscreen.multitouch.distinct、android.hardware.touchscreen.multitouch.jazzhand。

如果设备实现不包含触摸屏（仅依赖指针设备），并且满足7.2.5 节中的伪触摸要求，则它们

• [C-3-1] 绝不能报告任何以 android.hardware.touchscreen 开头的功能标志，并且必须仅报告 android.hardware.faketouch。

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] 必须支持指针按下，然后允许用户快速将对象移动到屏幕上的不同位置，然后在屏幕上指针抬起，这允许用户在屏幕上快速滑动对象。
• [C-1-7] 必须为 Configuration.touchscreen API 字段报告 TOUCHSCREEN_NOTOUCH。

如果设备实现声明支持 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. 按钮映射

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

• [C-1-1] 必须嵌入控制器或在包装盒中附带单独的控制器，这将提供输入下表中列出的所有事件的方式。
• [C-1-2] 必须能够将 HID 事件映射到其关联的 Android view.InputEvent 常量，如下表所示。上游 Android 实现包括满足此要求的游戏控制器的实现。

¹ KeyEvent

² 上述 HID 用法必须在游戏手柄 CA (0x01 0x0005) 中声明。

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

⁴ MotionEvent

¹ 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 是可以接受的。

• [SR] 强烈建议按照 Android SDK 文档中的定义，以纳秒为单位报告事件时间，表示事件发生的时间并与 SystemClock.elapsedRealtimeNano() 时钟同步。强烈建议现有和新的 Android 设备满足这些要求，以便它们能够升级到未来平台版本，其中这可能成为必需的组件。同步误差应低于 100 毫秒。

• [C-1-4] 对于 Android SDK 文档指示为连续传感器的任何 API，设备实现必须持续提供周期性数据样本，这些样本的抖动应低于 3%，其中抖动定义为连续事件之间报告的时间戳值差异的标准偏差。

• [C-1-5] 必须确保传感器事件流不得阻止设备 CPU 进入挂起状态或从挂起状态唤醒。

• 当激活多个传感器时，功耗不应超过各个传感器报告的功耗之和。

上面的列表并非详尽无遗；Android SDK 和 Android 开源文档中关于传感器的文档化行为应被视为权威。

某些传感器类型是复合的，这意味着它们可以从一个或多个其他传感器提供的数据中派生出来。（示例包括方向传感器和线性加速度传感器。）

设备实现

• 当它们包含传感器类型中描述的先决条件物理传感器时，应实现这些传感器类型。

如果设备实现包含复合传感器，则它们

• [C-2-1] 必须按照 Android 开源文档中关于复合传感器的描述来实现传感器。

7.3.1. 加速度计

设备实现

• [C-SR] 强烈建议包含 3 轴加速度计。

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

• [C-1-1] 必须能够报告高达至少 50 Hz 频率的事件。
• [C-1-2] 必须实现并报告 TYPE_ACCELEROMETER 传感器。
• [C-1-3] 必须符合 Android API 中详述的Android 传感器坐标系。
• [C-1-4] 必须能够在任何轴上测量从自由落体到重力四倍 (4g) 或更大的范围。
• [C-1-5] 必须具有至少 12 位的分辨率。
• [C-1-6] 必须具有不大于 0.05 m/s^2 的标准偏差，其中标准偏差应基于以最快采样率在至少 3 秒的时间段内收集的样本，在每个轴的基础上计算。
• [SR] 强烈建议实现 TYPE_SIGNIFICANT_MOTION 复合传感器。
• [SR] 强烈建议实现并报告 TYPE_ACCELEROMETER_UNCALIBRATED 传感器。强烈建议 Android 设备满足此要求，以便它们能够升级到未来平台版本，其中这可能成为必需的要求。
• 应实现 Android SDK 文档中描述的 TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR、TYPE_STEP_COUNTER 复合传感器。
• 应报告高达至少 200 Hz 的事件。
• 应具有至少 16 位的分辨率。
• 如果在使用过程中特性发生变化，应在使用时进行校准和补偿，并在设备重启之间保留补偿参数。
• 应进行温度补偿。

如果设备实现包含 3 轴加速度计，并且实现了 TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR、TYPE_STEP_COUNTER 复合传感器中的任何一个

• [C-2-1] 它们的功耗总和必须始终小于 4 mW。
• 在动态或静态条件下，每个传感器的功耗应低于 2 mW 和 0.5 mW。

如果设备实现包含 3 轴加速度计和 3 轴陀螺仪传感器，则它们

• [C-3-1] 必须实现 TYPE_GRAVITY 和 TYPE_LINEAR_ACCELERATION 复合传感器。
• [C-SR] 强烈建议实现 TYPE_GAME_ROTATION_VECTOR 复合传感器。

如果设备实现包含 3 轴加速度计、3 轴陀螺仪传感器和磁力计传感器，则它们

• [C-4-1] 必须实现 TYPE_ROTATION_VECTOR 复合传感器。

7.3.2. 磁力计

设备实现

• [C-SR] 强烈建议包含 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 的标准偏差。
• 应实现 TYPE_MAGNETIC_FIELD_UNCALIBRATED 传感器。
• [SR] 强烈建议现有和新的 Android 设备实现 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] 强烈建议包含 GPS/GNSS 接收器。

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

• [C-1-1] 通过 LocationManager#requestLocationUpdate 请求时，必须支持至少 1 Hz 速率的位置输出。
• [C-1-2] 当连接到 0.5 Mbps 或更快的互联网数据速度连接时，必须能够在 10 秒内（快速首次定位时间）在开阔天空条件下（强信号、可忽略的多径、HDOP < 2）确定位置。此要求通常通过使用某种形式的辅助或预测 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] 强烈建议在紧急电话呼叫期间继续通过 GNSS 位置提供程序 API 传递正常的 GPS/GNSS 位置输出。
  • [C-SR] 强烈建议报告来自所有跟踪的星座（在 GnssStatus 消息中报告）的 GNSS 测量值，SBAS 除外。
  • [C-SR] 强烈建议报告 GNSS 测量的 AGC 和频率。
  • [C-SR] 强烈建议将所有精度估计值（包括方位角、速度和垂直精度）作为每个 GPS/GNSS 位置的一部分报告。
  • [C-SR] 强烈建议尽快报告 GNSS 测量值，即使尚未报告从 GPS/GNSS 计算的位置。
  • [C-SR] 强烈建议报告 GNSS 伪距和伪距率，在开阔天空条件下，在确定位置后，当静止或以小于 0.2 米/秒平方的加速度移动时，这些伪距和伪距率足以至少 95% 的时间在 20 米内计算位置，并在 0.2 米/秒内计算速度。

7.3.4. 陀螺仪

设备实现

• [C-SR] 强烈建议包含陀螺仪传感器，除非还包含 3 轴加速度计。

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

• [C-1-1] 必须能够报告高达至少 50 Hz 频率的事件。
• [C-1-2] 必须实现 TYPE_GYROSCOPE 传感器，并且强烈建议也实现 TYPE_GYROSCOPE_UNCALIBRATED 传感器。
• [C-1-4] 必须具有 12 位或更高的分辨率，并且应具有 16 位或更高的分辨率。
• [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。
• [SR] 强烈建议当设备在室温下静止时，校准误差小于 0.01 rad/s。
• 应报告高达至少 200 Hz 的事件。

如果设备实现包含 3 轴陀螺仪、加速度计传感器和磁力计传感器，则它们

• [C-2-1] 必须实现 TYPE_ROTATION_VECTOR 复合传感器。

如果设备实现包含 3 轴加速度计和 3 轴陀螺仪传感器，则它们

• [C-3-1] 必须实现 TYPE_GRAVITY 和 TYPE_LINEAR_ACCELERATION 复合传感器。
• [C-SR] 强烈建议实现 TYPE_GAME_ROTATION_VECTOR 复合传感器。

7.3.5. 气压计

设备实现

• [C-SR] 强烈建议包含气压计（环境气压传感器）。

如果设备实现包含气压计，则它们

• [C-1-1] 必须实现并报告 TYPE_PRESSURE 传感器。
• [C-1-2] 必须能够以 5 Hz 或更高的频率传递事件。
• [C-1-3] 必须进行温度补偿。
• [SR] 强烈建议能够报告 300hPa 至 1100hPa 范围内的压力测量值。
• 应具有 1hPa 的绝对精度。
• 应在 20hPa 范围内具有 0.12hPa 的相对精度（相当于海平面上 ~200m 变化时 ~1m 的精度）。

7.3.6. 温度计

设备实现

• 可以包含环境温度计（温度传感器）。
• 可以但不应包含 CPU 温度传感器。

如果设备实现包含环境温度计（温度传感器），则它们

• [C-1-1] 必须定义为 SENSOR_TYPE_AMBIENT_TEMPERATURE，并且必须测量用户与设备交互的环境（房间/车辆座舱）温度，单位为摄氏度。
• [C-1-2] 必须定义为 SENSOR_TYPE_TEMPERATURE。
• [C-1-3] 必须测量设备 CPU 的温度。
• [C-1-4] 绝不能测量任何其他温度。

请注意，SENSOR_TYPE_TEMPERATURE 传感器类型在 Android 4.0 中已弃用。

7.3.7. 光度计

• 设备实现可以包含光度计（环境光传感器）。

7.3.8. 接近传感器

• 设备实现可以包含接近传感器。

如果设备实现包含接近传感器，则它们

• [C-1-1] 必须测量与屏幕方向相同的物体的接近程度。也就是说，接近传感器必须定向为检测靠近屏幕的物体，因为此传感器类型的主要目的是检测用户正在使用的手机。如果设备实现包含任何其他方向的接近传感器，则不得通过此 API 访问它。
• [C-1-2] 必须具有 1 位或更高的精度。

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] 强烈建议具有至少为奈奎斯特频率 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] 强烈建议具有至少为奈奎斯特频率 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。
  • g 灵敏度应小于 0.1°/s/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] 强烈建议当报告速率为 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 毫瓦，设备移动时功耗不得高于 2.0 毫瓦
  • 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. 生物识别传感器

有关衡量生物识别解锁安全性的更多背景信息，请参阅衡量生物识别安全性的文档。

如果设备实现包括安全锁屏，则

• 应包含生物识别传感器

生物识别传感器可根据其欺骗和冒名顶替接受率以及生物识别管道的安全性分为强、弱或便捷级别。 此分类决定了生物识别传感器与平台和第三方应用程序交互的能力。 传感器默认分类为便捷级别，如果希望分类为弱或强级别，则需要满足以下详述的附加要求。 弱和强生物识别都将获得以下详述的附加功能。

为了使生物识别传感器可供第三方应用程序使用，设备实现

• [C-0-1] 必须满足本文档中定义的强或弱生物识别的要求。

为了允许第三方应用程序访问密钥库密钥，设备实现

• [C-0-2] 必须满足本文档中定义的强生物识别的要求。

此外

• [C-0-3] 如果强生物识别是被动的（例如，面部或虹膜识别，其中不存在用户的明确意图信号），则必须与显式确认操作（例如，按钮按下）配对。
  • [C-SR] 强烈建议被动生物识别的确认操作应受到保护，以防止操作系统或内核受到攻击而进行欺骗。 例如，这意味着基于物理按钮的确认操作通过安全元件 (SE) 的仅输入通用输入/输出 (GPIO) 引脚进行路由，该引脚不能通过物理按钮按下以外的任何其他方式驱动。

如果设备实现希望将生物识别传感器视为便捷级别，则

• [C-1-1] 必须具有低于 0.002% 的错误接受率。
• [C-1-2] 如果欺骗和冒名顶替接受率高于 7%，则必须披露此模式可能不如强 PIN 码、图案或密码安全，并明确列举启用它的风险。
• [C-1-3] 对于生物识别验证，在五次错误尝试后，必须将尝试次数限制在至少 30 秒内 - 其中错误尝试是指具有足够捕获质量 (BIOMETRIC_ACQUIRED_GOOD) 但与已注册的生物识别不匹配的尝试。
• [C-1-4] 必须先通过让用户确认现有设备凭据或添加新的设备凭据（PIN 码/图案/密码），建立信任链，才能添加新的生物识别，该凭据由 TEE 保护； Android 开源项目实现提供了框架中执行此操作的机制。
• [C-1-5] 当用户帐户被删除时（包括通过恢复出厂设置），必须完全删除用户的所有可识别生物识别数据。
• [C-1-6] 必须遵守该生物识别的单独标志（即 DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT、DevicePolicymanager.KEYGUARD_DISABLE_FACE 或 DevicePolicymanager.KEYGUARD_DISABLE_IRIS）。
• [C-1-7] 对于使用 Android 版本 10 启动的新设备，必须每 24 小时或更短时间内，对于从早期 Android 版本升级的设备，必须每 72 小时或更短时间内，挑战用户进行建议的主要身份验证（例如，PIN 码、图案、密码）。

• [C-1-8] 在发生以下情况之一后，必须挑战用户进行建议的主要身份验证（例如：PIN 码、图案、密码）

  • 4 小时的空闲超时期限，或
  • 3 次生物识别身份验证失败尝试。
  • 在成功确认设备凭据后，空闲超时期限和失败身份验证计数将重置。

  从早期 Android 版本升级的设备可以免除 C-1-8 的要求。

• [C-SR] 强烈建议错误拒绝率低于 10%（在设备上测量）。

• [C-SR] 强烈建议对于每个注册的生物识别，从检测到生物识别到屏幕解锁的延迟低于 1 秒。

如果设备实现希望将生物识别传感器视为弱级别，则

• [C-2-1] 必须满足上述便捷级别的所有要求，但 [C-1-2] 除外。
• [C-2-2] 必须具有不高于 20% 的欺骗和冒名顶替接受率。
• [C-2-3] 必须具有硬件支持的密钥库实现，并在 Android 用户或内核空间之外的隔离执行环境（例如可信执行环境 (TEE)）或具有与隔离执行环境的安全通道的芯片上执行生物识别匹配。
• [C-2-4] 必须对所有可识别数据进行加密和加密身份验证，以确保无法在隔离执行环境之外或具有与 Android 开源项目站点上的实施指南中记录的隔离执行环境的安全通道的芯片上获取、读取或更改这些数据。
• [C-2-5] 对于基于摄像头的生物识别，当正在进行基于生物识别的身份验证或注册时
  • 必须在一种模式下操作摄像头，以防止在隔离执行环境之外或具有与隔离执行环境的安全通道的芯片上读取或更改摄像头帧。
  • 对于 RGB 单摄像头解决方案，摄像头帧可以在隔离执行环境之外读取，以支持注册预览等操作，但仍然必须不可更改。
• [C-2-6] 不得允许第三方应用程序区分各个生物识别注册。
• [C-2-7] 不得允许在 TEE 上下文之外，在应用程序处理器上以未加密的方式访问可识别的生物识别数据或从中派生的任何数据（例如嵌入）。

• [C-2-8] 必须具有安全的处理管道，以防止操作系统或内核受到攻击而允许直接注入数据以虚假地验证为用户。

  如果设备实现已在早期 Android 版本上启动，并且无法通过系统软件更新满足 C-2-8 要求，则可以免除此要求。

如果设备实现希望将生物识别传感器视为强级别，则

• [C-3-1] 必须满足上述弱级别的所有要求。 从早期 Android 版本升级的设备不能免除 C-2-7 的要求。
• [C-3-2] 必须具有不高于 7% 的欺骗和冒名顶替接受率。
• [C-3-3] 必须每 72 小时或更短时间内，挑战用户进行建议的主要身份验证（例如，PIN 码、图案、密码）。

7.3.12. 姿势传感器

设备实现

• 可以支持具有 6 个自由度的姿势传感器。

如果设备实现支持具有 6 个自由度的姿势传感器，则

• [C-1-1] 必须实现并报告 TYPE_POSE_6DOF 传感器。
• [C-1-2] 必须比仅旋转矢量更准确。

7.4. 数据连接

7.4.1. 电话

Android API 和本文档中使用的“电话”特指与通过 GSM 或 CDMA 网络拨打语音电话和发送 SMS 消息相关的硬件。 虽然这些语音电话可能是也可能不是分组交换的，但为了 Android 的目的，它们被认为独立于可能使用同一网络实现的任何数据连接。 换句话说，Android “电话”功能和 API 专门指语音电话和 SMS。 例如，无论设备是否使用蜂窝网络进行数据连接，无法拨打电话或发送/接收 SMS 消息的设备都不被视为电话设备。

• Android 可以用于不包括电话硬件的设备。 也就是说，Android 与非电话设备兼容。

如果设备实现包括 GSM 或 CDMA 电话，则

• [C-1-1] 必须根据技术声明 android.hardware.telephony 功能标志和其他子功能标志。
• [C-1-2] 必须完全实现该技术的 API 支持。

如果设备实现不包括电话硬件，则

• [C-2-1] 必须将完整的 API 实现为无操作。

如果设备实现支持 eUICC 或 eSIM/嵌入式 SIM 卡，并且包含专有机制以使第三方开发人员可以使用 eSIM 功能，则

• [C-3-1] 必须提供 EuiccManager API 的完整实现。

7.4.1.1. 号码阻止兼容性

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

• [C-1-1] 必须包括号码阻止支持
• [C-1-2] 必须完全实现 BlockedNumberContract 和 SDK 文档中描述的相应 API。
• [C-1-3] 必须阻止来自 'BlockedNumberProvider' 中电话号码的所有呼叫和消息，而无需与应用程序进行任何交互。 唯一的例外是 SDK 文档中描述的临时解除号码阻止的情况。
• [C-1-4] 不得为被阻止的呼叫写入 平台呼叫日志提供程序。
• [C-1-5] 不得为被阻止的消息写入 Telephony 提供程序。
• [C-1-6] 必须实现阻止号码管理 UI，该 UI 通过 TelecomManager.createManageBlockedNumbersIntent() 方法返回的 intent 打开。
• [C-1-7] 不得允许辅助用户查看或编辑设备上的阻止号码，因为 Android 平台假定主用户对设备上的电话服务（单个实例）具有完全控制权。 所有阻止相关的 UI 必须对辅助用户隐藏，并且阻止列表必须仍然受到尊重。
• 当设备更新到 Android 7.0 时，应将阻止的号码迁移到提供程序中。

7.4.1.2. 电信 API

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

• [C-1-1] 必须支持 SDK 中描述的 ConnectionService API。
• [C-1-2] 当用户正在进行由不支持通过 CAPABILITY_SUPPORT_HOLD 指定的保持功能的第三方应用程序进行的通话时，必须显示新的来电并提供用户可接受或拒绝来电的功能。
• [C-1-3] 必须有一个应用程序实现 InCallService。

• [C-SR] 强烈建议通知用户，接听来电将断开正在进行的通话。

  AOSP 实现通过一个抬头通知来满足这些要求，该通知向用户指示接听来电将导致另一个通话被断开。

• [C-SR] 强烈建议预加载默认拨号器应用程序，当第三方应用程序在其 PhoneAccount 上将 EXTRA_LOG_SELF_MANAGED_CALLS 额外键设置为 true 时，该应用程序会在其通话记录中显示通话记录条目和第三方应用程序的名称。

• [C-SR] 强烈建议按如下方式处理音频耳机的 KEYCODE_MEDIA_PLAY_PAUSE 和 KEYCODE_HEADSETHOOK 事件，用于 android.telecom API
  • 当在正在进行的通话期间检测到按键事件的短按时，调用 Connection.onDisconnect()。
  • 当在来电期间检测到按键事件的短按时，调用 Connection.onAnswer()。
  • 当在来电期间检测到按键事件的长按时，调用 Connection.onReject()。
  • 切换 CallAudioState 的静音状态。

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] 必须实现 SDK 文档中描述的 multicast API。
• [C-1-4] 必须支持组播 DNS (mDNS)，并且在任何操作时间（包括以下情况）都不得过滤 mDNS 数据包 (224.0.0.251)
  • 即使屏幕未处于活动状态。
  • 对于 Android 电视设备实现，即使在待机功耗状态下。
• [C-1-5] 不得将 WifiManager.enableNetwork() API 方法调用视为足以切换当前活动的 Network 的指示，该 Network 默认用于应用程序流量，并且由 ConnectivityManager API 方法（例如 getActiveNetwork 和 registerDefaultNetworkCallback）返回。 换句话说，只有在成功验证 Wi-Fi 网络提供互联网访问的情况下，它们才可以禁用任何其他网络提供商（例如移动数据）提供的互联网访问。
• [C-1-6] 强烈建议在调用 ConnectivityManager.reportNetworkConnectivity() API 方法时，重新评估 Network 上的互联网访问，并且一旦评估确定当前 Network 不再提供互联网访问，则切换到任何其他可用的网络（例如移动数据），以提供互联网访问。
• [C-SR] 强烈建议在 STA 断开连接时，在每次扫描开始时随机化探测请求帧的源 MAC 地址和序列号。
  • 包含一次扫描的每组探测请求帧应使用一个一致的 MAC 地址（不应在扫描过程中随机化 MAC 地址）。
  • 探测请求序列号应在扫描中的探测请求之间正常迭代（顺序）。
  • 探测请求序列号应在扫描的最后一个探测请求和下一次扫描的第一个探测请求之间随机化。
• [C-SR] 强烈建议在 STA 断开连接时，仅允许探测请求帧中存在以下元素
  • SSID 参数集 (0)
  • DS 参数集 (3)

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

• [C-3-1] 每当应用程序通过 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] 强烈建议在获取并生效低延迟锁 (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] 必须实现 SDK 文档中描述的 相应的 Android API。
• [C-1-2] 必须报告硬件功能 android.hardware.wifi.direct。
• [C-1-3] 必须支持常规 Wi-Fi 操作。
• [C-1-4] 必须同时支持 Wi-Fi 和 Wi-Fi Direct 操作。

7.4.2.2. Wi-Fi 隧道式直接链路设置

设备实现

• 应包括对 Android SDK 文档中描述的 Wi-Fi 隧道式直接链路设置 (TDLS) 的支持。

如果设备实现包括对 TDLS 的支持，并且通过 WiFiManager API 启用了 TDLS，则

• [C-1-1] 必须通过 WifiManager.isTdlsSupported 声明对 TDLS 的支持。
• 仅当 TDLS 可行且有益时，才应使用 TDLS。
• 应具有一些启发式方法，并且当 TDLS 的性能可能比通过 Wi-Fi 接入点更差时，不应使用 TDLS。

7.4.2.3. Wi-Fi Aware

设备实现

• 应包括对 Wi-Fi Aware 的支持。

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

• [C-1-1] 必须实现 SDK 文档中描述的 WifiAwareManager API。
• [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 管理接口地址。

如果设备实现包括对 Wi-Fi Aware 和 第 7.4.2.5 节 Wi-Fi 位置中描述的 Wi-Fi 位置的支持，并将这些功能公开给第三方应用程序，则它们

• [C-2-1] 必须实现位置感知发现 API：setRangingEnabled、setMinDistanceMm、setMaxDistanceMm 和 onServiceDiscoveredWithinRange。

7.4.2.4. Wi-Fi Passpoint

设备实现

• 应包括对 Wi-Fi Passpoint 的支持。

如果设备实现包括对 Wi-Fi Passpoint 的支持，则

• [C-1-1] 必须实现 SDK 文档中描述的 Passpoint 相关 WifiManager API。
• [C-1-2] 必须支持 IEEE 802.11u 标准，特别是与网络发现和选择相关的标准，例如通用广告服务 (GAS) 和接入网络查询协议 (ANQP)。

相反，如果设备实现不包括对 Wi-Fi Passpoint 的支持

• [C-2-1] Passpoint 相关 WifiManager API 的实现必须抛出 UnsupportedOperationException。

7.4.2.5. Wi-Fi 位置（Wi-Fi 往返时间 - RTT）

设备实现

• 应包括对 Wi-Fi 位置 的支持。

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

• [C-1-1] 必须实现 SDK 文档中描述的 WifiRttManager API。
• [C-1-2] 必须声明 android.hardware.wifi.rtt 功能标志。
• [C-1-3] 必须为在执行 RTT 的 Wi-Fi 接口未与接入点关联时执行的每个 RTT 突发随机化源 MAC 地址。

7.4.2.6. Wi-Fi Keepalive Offload（Wi-Fi 保持活动卸载）

设备实现

• 应包括对 Wi-Fi 保持活动卸载的支持。

如果设备实现包括对 Wi-Fi 保持活动卸载的支持并将功能公开给第三方应用程序，则它们

• [C-1-1] 必须支持 SocketKeepAlive API。

• [C-1-2] 必须支持至少三个并发的 Wi-Fi 保持活动槽和至少一个蜂窝保持活动槽。

如果设备实现不包括对 Wi-Fi 保持活动卸载的支持，则它们

• [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] 必须实现 SDK 文档中描述的 Settings#ACTION_PROCESS_WIFI_EASY_CONNECT_URI Intent API。
• [C-1-2] 必须使 WifiManager#isEasyConnectSupported() 方法返回 true。

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 等。

如果设备实现包括对蓝牙低功耗的支持，则

• [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() 的正确值，以指示是否支持低功耗广播。
• 在实现 ScanFilter API 时，应支持将过滤逻辑卸载到蓝牙芯片组。
• 应支持将批量扫描卸载到蓝牙芯片组。

• 应支持至少 4 个槽的多重广播。

• [SR] 强烈建议实施不超过 15 分钟的可解析私有地址 (RPA) 超时，并在超时时轮换地址以保护用户隐私。

如果设备实现支持蓝牙 LE 并使用蓝牙 LE 进行位置扫描，则

• [C-4-1] 必须提供用户功能，以启用/禁用通过系统 API BluetoothAdapter.isBleScanAlwaysAvailable() 读取的值。

如果设备实现包括对蓝牙 LE 和助听器配置文件的支持，如 使用蓝牙 LE 的助听器音频支持中所述，则

• [C-5-1] 对于 BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID)，必须返回 true。

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 论坛技术规范 NFCForum-TS-DigitalProtocol-1.0 定义），通过以下 NFC 标准
  • NfcA (ISO14443-3A)
  • NfcB (ISO14443-3B)
  • NfcF (JIS X 6319-4)
  • IsoDep (ISO 14443-4)
  • NFC Forum Tag Types 1、2、3、4、5（由 NFC 论坛定义）

• [SR] 强烈建议能够通过以下 NFC 标准读取和写入 NDEF 消息以及原始数据。 请注意，虽然 NFC 标准被声明为强烈建议，但未来版本的兼容性定义计划将这些标准更改为必须。 这些标准在此版本中是可选的，但在未来版本中将是必需的。 强烈鼓励运行此 Android 版本的现有设备和新设备现在就满足这些要求，以便它们能够升级到未来的平台版本。

• [C-1-13] 必须在 NFC 发现模式下轮询所有受支持的技术。

• 当设备唤醒且屏幕处于活动状态且锁屏已解锁时，应处于 NFC 发现模式。
• 应能够读取 Thinfilm NFC 条形码产品的条形码和 URL（如果已编码）。

请注意，上述 JIS、ISO 和 NFC 论坛规范没有公开可用的链接。

Android 包括对 NFC 主机卡模拟 (HCE) 模式的支持。

如果设备实现包括能够进行 HCE（用于 NfcA 和/或 NfcB）的 NFC 控制器芯片组并支持应用程序 ID (AID) 路由，则

• [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. 最低网络能力

设备实现

• [C-0-1] 必须包含对一种或多种形式的数据网络的支持。具体而言，设备实现必须包含对至少一种数据标准的支持，该标准能够达到 200 Kbit/秒或更高的速度。满足此要求的技术示例包括 EDGE、HSPA、EV-DO、802.11g、以太网和蓝牙 PAN。
• 当物理网络标准（如以太网）是主要数据连接时，应该也包含对至少一种常见的无线数据标准的支持，例如 802.11 (Wi-Fi)。
• 可以实现多种形式的数据连接。
• [C-0-2] 必须包含 IPv6 网络堆栈，并支持使用托管 API（如 java.net.Socket 和 java.net.URLConnection）以及原生 API（如 AF_INET6 套接字）进行 IPv6 通信。
• [C-0-3] 必须默认启用 IPv6。
• 必须确保 IPv6 通信与 IPv4 一样可靠，例如
  • [C-0-4] 必须在打盹模式下保持 IPv6 连接。
  • [C-0-5] 速率限制不得导致设备在任何使用至少 180 秒 RA 生存期的 IPv6 兼容网络上丢失 IPv6 连接。
• [C-0-6] 当连接到 IPv6 网络时，必须为第三方应用程序提供直接的 IPv6 网络连接，设备本地不得进行任何形式的地址或端口转换。托管 API（如 Socket#getLocalAddress 或 Socket#getLocalPort) 和 NDK API（如 getsockname() 或 IPV6_PKTINFO）都必须返回实际用于在网络上发送和接收数据包的 IP 地址和端口。

所需的 IPv6 支持级别取决于网络类型，如下列要求所示。

如果设备实现支持 Wi-Fi，则它们

• [C-1-1] 必须支持 Wi-Fi 上的双栈和仅 IPv6 操作。

如果设备实现支持以太网，则它们

• [C-2-1] 必须支持以太网上的双栈操作。

如果设备实现支持蜂窝数据，则它们

• 应该支持蜂窝网络上的 IPv6 操作（仅 IPv6 和可能的双栈）。

如果设备实现支持多种网络类型（例如，Wi-Fi 和蜂窝数据），则它们

• [C-3-1] 当设备同时连接到多种网络类型时，必须同时满足上述每种网络的要求。

7.4.6. 同步设置

设备实现

• [C-0-1] 必须默认启用主自动同步设置，以便方法 getMasterSyncAutomatically() 返回 “true”。

7.4.7. 流量节省程序

如果设备实现包含按流量计费的连接，则它们

• [SR] 强烈建议提供流量节省程序模式。

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

• [C-1-1] 必须支持 ConnectivityManager 类中的所有 API，如 SDK 文档中所述
• [C-1-2] 必须在设置中提供用户界面，以处理 Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS intent，允许用户将应用程序添加到允许列表或从允许列表中删除应用程序。

如果设备实现不提供流量节省程序模式，则它们

• [C-2-1] 必须为 ConnectivityManager.getRestrictBackgroundStatus() 返回值 RESTRICT_BACKGROUND_STATUS_DISABLED
• [C-2-2] 不得广播 ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED。
• [C-2-3] 必须具有一个处理 Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS intent 的 activity，但可以将其实现为无操作。

7.4.8. 安全元件

如果设备实现支持支持 Open Mobile API 的安全元件并将其提供给第三方应用，则它们

• [C-1-1] 当调用 android.se.omapi.SEService.getReaders() 方法时，必须枚举可用的安全元件读取器。

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 时。

7.5.1. 后置摄像头

后置摄像头是位于设备显示屏相对一侧的摄像头；也就是说，它像传统相机一样对准设备远侧的场景成像。

设备实现

• 应该包含后置摄像头。

如果设备实现包含至少一个后置摄像头，则它们

• [C-1-1] 必须报告功能标志 android.hardware.camera 和 android.hardware.camera.any。
• [C-1-2] 必须具有至少 200 万像素的分辨率。
• 应该在相机驱动程序中实现硬件自动对焦或软件自动对焦（对应用程序软件透明）。
• 可以具有固定焦点或 EDOF（扩展景深）硬件。
• 可以包含闪光灯。

如果相机包含闪光灯

• [C-2-1] 除非应用程序通过启用 Camera.Parameters 对象的 FLASH_MODE_AUTO 或 FLASH_MODE_ON 属性显式启用了闪光灯，否则当 android.hardware.Camera.PreviewCallback 实例已在相机预览表面上注册时，闪光灯灯泡不得点亮。请注意，此约束不适用于设备的内置系统相机应用程序，而仅适用于使用 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. 外部相机

设备实现

• 可以包含对外部相机的支持，该相机不一定始终连接。

如果设备实现包含对外部相机的支持，则它们

• [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 设备实现必须确保按照本节和 Android SDK 中的描述继续支持该 API。

在已弃用的 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] 必须支持 android.hardware.ImageFormat.YUV_420_888 和 android.hardware.ImageFormat.JPEG 格式作为通过 android.media.ImageReader API 为在 REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE 功能在 android.request.availableCapabilities 中声明的 android.hardware.camera2 设备提供的输出。
• [C-0-5] 必须仍然实现 Android SDK 文档中包含的完整 Camera API，无论设备是否包含硬件自动对焦或其他功能。例如，缺少自动对焦功能的相机仍必须调用任何已注册的 android.hardware.Camera.AutoFocusCallback 实例（即使这与非自动对焦相机无关）。请注意，这确实适用于前置摄像头；例如，即使大多数前置摄像头不支持自动对焦，API 回调仍必须按照描述进行“伪造”。
• [C-0-6] 必须识别并遵守在 android.hardware.Camera.Parameters 类和 android.hardware.camera2.CaptureRequest 类中定义为常量的每个参数名称。相反，设备实现不得遵守或识别传递给 android.hardware.Camera.setParameters() 方法的字符串常量，除非这些常量在 android.hardware.Camera.Parameters 上记录为常量。也就是说，如果硬件允许，设备实现必须支持所有标准相机参数，并且不得支持自定义相机参数类型。例如，使用高动态范围 (HDR) 成像技术支持图像捕获的设备实现必须支持相机参数 Camera.SCENE_MODE_HDR。
• [C-0-7] 必须使用 android.info.supportedHardwareLevel 属性报告适当的支持级别，如 Android SDK 中所述，并报告相应的 框架功能标志。
• [C-0-8] 还必须通过 android.request.availableCapabilities 属性声明其 android.hardware.camera2 的各个相机功能，并声明相应的 功能标志；如果其任何连接的相机设备支持该功能，则必须定义该功能标志。
• [C-0-9] 每当相机拍摄新照片并将照片条目添加到媒体存储时，必须广播 Camera.ACTION_NEW_PICTURE intent。
• [C-0-10] 每当相机录制新视频并将照片条目添加到媒体存储时，必须广播 Camera.ACTION_NEW_VIDEO intent。
• [C-0-11] 必须通过已弃用的 android.hardware.Camera API 访问的所有相机也必须可以通过 android.hardware.camera2 API 访问。
• [C-SR] 对于具有多个朝向相同方向的 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] 必须在此共享存储上强制执行 android.permission.WRITE_EXTERNAL_STORAGE 权限，如 SDK 中所述。
• [C-0-5] 必须为所有以 API 级别 29 或更高版本为目标的应用程序默认启用 分区存储，除非在以下情况下
  • 当应用程序在设备升级到 API 级别 29 之前安装时，无论应用程序的目标 API 是什么。
  • 当应用程序在其清单中请求 android:requestLegacyExternalStorage="true" 时。
  • 当应用程序被授予 android.permission.WRITE_MEDIA_STORAGE 权限时。
• [C-0-6] 必须强制执行启用分区存储的应用程序无法直接文件系统访问其应用程序特定目录之外的文件，这些目录由 Context API 方法返回，例如 Context.getExternalFilesDirs()、Context.getExternalCacheDirs()、Context.getExternalMediaDirs() 和 Context.getObbDirs() 方法。
• [C-0-7] 当通过 MediaStore 访问媒体文件时，必须编辑存储在媒体文件中的位置元数据（例如 GPS Exif 标签），除非调用应用程序持有 ACCESS_MEDIA_LOCATION 权限。

设备实现可以使用以下任一方法满足上述要求

• 用户可访问的可移动存储，例如安全数字 (SD) 卡插槽。
• 内部（不可移动）存储的一部分，如 Android 开源项目 (AOSP) 中实现的那样。

如果设备实现使用可移动存储来满足上述要求，则它们

• [C-1-1] 当插槽中未插入存储介质时，必须实现 toast 或弹出式用户界面警告用户。
• [C-1-2] 必须包含 FAT 格式的存储介质（例如 SD 卡），或在包装盒和购买时可用的其他材料上显示存储介质必须单独购买。

如果设备实现使用不可移动存储的一部分来满足上述要求，则它们

• 应该使用内部应用程序共享存储的 AOSP 实现。
• 可以与应用程序私有数据共享存储空间。

如果设备实现包含多个共享存储路径（例如 SD 卡插槽和共享内部存储），则它们

• [C-2-1] 除了写入其特定于软件包的目录或 ACTION_OPEN_DOCUMENT_TREE intent 返回的 URI 内之外，必须仅允许具有 WRITE_MEDIA_STORAGE 权限的预安装和特权 Android 应用程序写入辅助外部存储。
• [C-2-2] 必须要求仅当也授予 android.permission.WRITE_EXTERNAL_STORAGE 权限时，才将与 android.permission.WRITE_MEDIA_STORAGE 权限关联的直接访问权限授予用户可见的应用。
• [SR] 强烈建议预安装和特权 Android 应用程序使用公共 API（如 MediaStore）与存储设备交互，而不是依赖于 android.permission.WRITE_MEDIA_STORAGE 授予的直接访问权限。

如果设备实现具有带 USB 外围设备模式支持的 USB 端口，则它们

• [C-3-1] 必须提供一种机制，用于从主机计算机访问应用程序共享存储上的数据。
• 应该通过 Android 的媒体扫描器服务和 android.provider.MediaStore 透明地公开来自两个存储路径的内容。
• 可以使用 USB 大容量存储，但应该使用媒体传输协议来满足此要求。

如果设备实现具有带 USB 外围设备模式的 USB 端口并支持媒体传输协议，则它们

• 应该与参考 Android MTP 主机 Android File Transfer 兼容。
• 应该报告 USB 设备类 0x00。
• 应该报告 USB 接口名称为 “MTP”。

7.6.3. 可采纳存储

如果设备预计本质上是移动的，而不是电视，则设备实现

• [SR] 强烈建议在长期稳定的位置实现可采纳存储，因为意外断开连接可能会导致数据丢失/损坏。

如果可移动存储设备端口位于长期稳定的位置，例如在电池仓或其他保护盖内，则设备实现

• [SR] 强烈建议实现 可采纳存储。

7.7. USB

如果设备实现具有 USB 端口，则它们

• 应该支持 USB 外围设备模式，并且应该支持 USB 主机模式。

7.7.1. USB 外围设备模式

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

• [C-1-1] 该端口必须可连接到具有标准 A 型或 C 型 USB 端口的 USB 主机。
• [C-1-2] 必须通过 android.os.Build.SERIAL 报告 USB 标准设备描述符中 iSerialNumber 的正确值。
• [C-1-3] 必须按照 C 型电阻标准检测 1.5A 和 3.0A 充电器，并且如果它们支持 C 型 USB，则必须检测广告中的更改。
• [SR] 该端口应该使用 micro-B、micro-AB 或 C 型 USB 外形尺寸。强烈建议现有和新的 Android 设备满足这些要求，以便它们能够升级到未来的平台版本。
• [SR] 该端口应该位于设备底部（根据自然方向）或为所有应用程序（包括主屏幕）启用软件屏幕旋转，以便当设备以端口位于底部的方向定向时，显示器能够正确绘制。强烈建议现有和新的 Android 设备满足这些要求，以便它们能够升级到未来的平台版本。
• [SR] 应该实现支持在 HS 啁啾和流量期间汲取 1.5 A 电流，如 USB 电池充电规范修订版 1.2 中所指定。强烈建议现有和新的 Android 设备满足这些要求，以便它们能够升级到未来的平台版本。
• [SR] 强烈建议不要支持超出默认级别的修改 Vbus 电压或更改接收器/源角色的专有充电方法，因为这可能会导致与支持标准 USB Power Delivery 方法的充电器或设备出现互操作性问题。虽然这被称为“强烈建议”，但在未来的 Android 版本中，我们可能会要求所有 C 型设备支持与标准 C 型充电器的完全互操作性。
• [SR] 强烈建议在支持 C 型 USB 和 USB 主机模式时支持 Power Delivery 以进行数据和电源角色交换。
• 应该支持 Power Delivery 以进行高压充电并支持备用模式（如显示输出）。
• 应该实现 Android 开放附件 (AOA) API 和规范，如 Android SDK 文档中所述。

如果设备实现包含 USB 端口并实现 AOA 规范，则它们

• [C-2-1] 必须声明对硬件功能 android.hardware.usb.accessory 的支持。
• [C-2-2] USB 大容量存储类必须在 USB 大容量存储的接口描述 iInterface 字符串末尾包含字符串 “android”

7.7.2. USB 主机模式

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

• [C-1-1] 必须实现 Android USB 主机 API，如 Android SDK 中所述，并且必须声明对硬件功能 android.hardware.usb.host 的支持。
• [C-1-2] 必须实现支持连接标准 USB 外围设备，换句话说，它们必须
  • 具有设备上的 C 型端口或随附将设备上的专有端口适配为标准 C 型 USB 端口的线缆（C 型 USB 设备）。
  • 具有设备上的 A 型端口或随附将设备上的专有端口适配为标准 A 型 USB 端口的线缆。
  • 具有设备上的 micro-AB 端口，应该随附将端口适配为标准 A 型端口的线缆。
• [C-1-3] 不得随附将 A 型或 micro-AB 端口转换为 C 型端口（插座）的适配器。
• [C-SR] 强烈建议实现 USB 音频类，如 Android SDK 文档中所述。
• 应该支持在主机模式下为连接的 USB 外围设备充电；对于 USB C 型连接器，宣传至少 1.5A 的源电流，如 USB C 型线缆和连接器规范修订版 1.2 的终止参数部分中所指定，或对于 Micro-AB 连接器，使用 USB 电池充电规范修订版 1.2 中指定的充电下游端口 (CDP) 输出电流范围。
• 应该实现并支持 USB C 型标准。

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

• [C-2-1] 必须支持 USB HID 类。
• [C-2-2] 必须支持检测和映射 USB HID 用法表 和 语音命令用法请求 中指定的以下 HID 数据字段到如下 KeyEvent 常量
  • 用法页 (0xC) 用法 ID (0x0CD): KEYCODE_MEDIA_PLAY_PAUSE
  • 用法页 (0xC) 用法 ID (0x0E9): KEYCODE_VOLUME_UP
  • 用法页 (0xC) 用法 ID (0x0EA): KEYCODE_VOLUME_DOWN
  • 用法页 (0xC) 用法 ID (0x0CF): KEYCODE_VOICE_ASSIST

如果设备实现包含支持主机模式和存储访问框架 (SAF) 的 USB 端口，则它们

• [C-3-1] 必须识别任何远程连接的 MTP（媒体传输协议）设备，并使其内容可通过 ACTION_GET_CONTENT、ACTION_OPEN_DOCUMENT 和 ACTION_CREATE_DOCUMENT intent 访问。

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

• [C-4-1] 必须实现 USB C 型规范（第 4.5.1.3.3 节）定义的双重角色端口功能。
• [SR] 强烈建议支持 DisplayPort，应该支持 USB 超速数据速率，并且强烈建议支持 Power Delivery 以进行数据和电源角色交换。
• [SR] 强烈建议不要支持 USB C 型线缆和连接器规范修订版 1.2 的附录 A 中描述的音频适配器附件模式。
• 应该实现最适合设备外形尺寸的 Try.* 模型。例如，手持设备应该实现 Try.SNK 模型。

7.8. 音频

7.8.1. 麦克风

如果设备实现包含麦克风，则它们

• [C-1-1] 必须报告 android.hardware.microphone 功能常量。
• [C-1-2] 必须满足 第 5.4 节中的音频录制要求。
• [C-1-3] 必须满足 第 5.6 节中的音频延迟要求。
• [SR] 强烈建议支持近超声录制，如 第 7.8.3 节中所述。

如果设备实现省略麦克风，则它们

• [C-2-1] 不得报告 android.hardware.microphone 功能常量。
• [C-2-2] 必须至少将音频录制 API 实现为无操作，根据 第 7 节。

7.8.2. 音频输出

如果设备实现包括扬声器或音频/多媒体输出端口（用于音频输出外围设备，例如 4 芯 3.5 毫米音频插孔或使用 USB 音频类的 USB 主机模式端口），则

• [C-1-1] 必须报告 android.hardware.audio.output 功能常量。
• [C-1-2] 必须满足 5.5 节中的音频播放要求。
• [C-1-3] 必须满足 第 5.6 节中的音频延迟要求。
• [SR] 强烈建议支持 7.8.3 节中描述的近超声播放。

如果设备实现不包括扬声器或音频输出端口，则

• [C-2-1] 不得报告 android.hardware.audio.output 功能。
• [C-2-2] 必须至少将音频输出相关 API 实现为 no-op。

在本节中，“输出端口”是指物理接口，例如 3.5 毫米音频插孔、HDMI 或具有 USB 音频类的 USB 主机模式端口。通过基于无线电的协议（例如蓝牙、WiFi 或蜂窝网络）进行音频输出的支持不符合包含“输出端口”的条件。

7.8.2.1. 模拟音频端口

为了与整个 Android 生态系统中使用 3.5 毫米音频插头的耳机和其他音频配件兼容，如果设备实现包括一个或多个模拟音频端口，则

• [C-SR] 强烈建议至少包括一个 4 芯 3.5 毫米音频插孔作为音频端口之一。

如果设备实现具有 4 芯 3.5 毫米音频插孔，则

• [C-1-1] 必须支持音频播放到立体声耳机和带有麦克风的立体声耳机。
• [C-1-2] 必须支持采用 CTIA 引脚排列顺序的 TRRS 音频插头。
• [C-1-3] 必须支持检测和映射到以下 3 个阻抗范围的键码，这些阻抗范围等效于音频插头上麦克风和接地导体之间的阻抗
  • 70 欧姆或更小：KEYCODE_HEADSETHOOK
  • 210-290 欧姆：KEYCODE_VOLUME_UP
  • 360-680 欧姆：KEYCODE_VOLUME_DOWN
• [C-1-4] 必须在插入插头时触发 ACTION_HEADSET_PLUG，但仅在插头上的所有触点都接触到插孔上的相关部分之后。
• [C-1-5] 必须能够在 32 欧姆扬声器阻抗上驱动至少 150mV ± 10% 的输出电压。
• [C-1-6] 必须具有 1.8V ~ 2.9V 之间的麦克风偏置电压。
• [C-1-7] 必须检测和映射到以下阻抗范围的键码，这些阻抗范围等效于音频插头上麦克风和接地导体之间的阻抗
  • 110-180 欧姆： KEYCODE_VOICE_ASSIST
• [C-SR] 强烈建议支持采用 OMTP 引脚排列顺序的音频插头。
• [C-SR] 强烈建议支持从带有麦克风的立体声耳机进行音频录制。

如果设备实现具有 4 芯 3.5 毫米音频插孔并支持麦克风，并且广播 android.intent.action.HEADSET_PLUG，且额外值麦克风设置为 1，则

• [C-2-1] 必须支持检测插入的音频配件上的麦克风。

7.8.2.2. 数字音频端口

为了与使用 USB-C 连接器并在整个 Android 生态系统中实现（USB 音频类）的耳机和其他音频配件兼容，如 Android USB 耳机规范中所定义。

有关设备特定要求，请参见2.2.1 节。

7.8.3. 近超声

近超声音频频段为 18.5 kHz 至 20 kHz。

设备实现

• 必须通过 AudioManager.getProperty API 正确报告对近超声音频功能的支持，如下所示

如果 PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND 为“true”，则 VOICE_RECOGNITION 和 UNPROCESSED 音频源必须满足以下要求

• [C-1-1] 麦克风在 18.5 kHz 至 20 kHz 频段的平均功率响应必须不低于 2 kHz 响应 15 dB 以上。
• [C-1-2] 对于 -26 dBFS 下的 19 kHz 音调，麦克风在 18.5 kHz 至 20 kHz 范围内的非加权信噪比必须不低于 50 dB。

如果 PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND 为“true”

• [C-2-1] 扬声器在 18.5 kHz - 20 kHz 范围内的平均响应必须不低于 2 kHz 响应 40 dB 以上。

7.8.4. 信号完整性

设备实现

• 对于手持设备上的输入和输出流，应提供无毛刺的音频信号路径，定义为每个路径一分钟测试期间测得的零毛刺。使用 [OboeTester] (https://github.com/google/oboe/tree/master/apps/OboeTester) “Automated Glitch Test” 进行测试。

测试需要一个音频环回适配器，直接用于 3.5 毫米插孔，和/或与 USB-C 转 3.5 毫米适配器结合使用。应测试所有音频输出端口。

OboeTester 目前支持 AAudio 路径，因此应使用 AAudio 测试以下组合是否存在毛刺

可靠的流应满足以下 2000 Hz 正弦波的信噪比 (SNR) 和总谐波失真 (THD) 标准。

7.9. 虚拟现实

Android 包含用于构建“虚拟现实”(VR) 应用程序的 API 和工具，包括高质量的移动 VR 体验。设备实现必须正确实现这些 API 和行为，如本节详细介绍。

7.9.1. 虚拟现实模式

Android 包括对 VR 模式的支持，此功能在 VR 应用程序获得用户焦点时处理通知的立体渲染并禁用单眼系统 UI 组件。

7.9.2. 虚拟现实模式 - 高性能

如果设备实现支持 VR 模式，则

• [C-1-1] 必须至少有 2 个物理核心。
• [C-1-2] 必须声明 android.hardware.vr.high_performance 功能。
• [C-1-3] 必须支持持续性能模式。
• [C-1-4] 必须支持 OpenGL ES 3.2。
• [C-1-5] 必须支持 android.hardware.vulkan.level 0。
• 应支持 android.hardware.vulkan.level 1 或更高版本。
• [C-1-6] 必须实现 EGL_KHR_mutable_render_buffer、EGL_ANDROID_front_buffer_auto_refresh、EGL_ANDROID_get_native_client_buffer、EGL_KHR_fence_sync、EGL_KHR_wait_sync、EGL_IMG_context_priority、EGL_EXT_protected_content、EGL_EXT_image_gl_colorspace，并在可用 EGL 扩展列表中公开这些扩展。
• [C-1-8] 必须实现 GL_EXT_multisampled_render_to_texture2、GL_OVR_multiview、GL_OVR_multiview2、GL_OVR_multiview_multisampled_render_to_texture、GL_EXT_protected_textures，并在可用 GL 扩展列表中公开这些扩展。
• [C-SR] 强烈建议实现 GL_EXT_external_buffer、GL_EXT_EGL_image_array，并在可用 GL 扩展列表中公开这些扩展。
• [C-SR] 强烈建议支持 Vulkan 1.1。
• [C-SR] 强烈建议实现 VK_ANDROID_external_memory_android_hardware_buffer、VK_GOOGLE_display_timing、VK_KHR_shared_presentable_image，并在可用 Vulkan 扩展列表中公开它。
• [C-SR] 强烈建议公开至少一个 Vulkan 队列族，其中 flags 包含 VK_QUEUE_GRAPHICS_BIT 和 VK_QUEUE_COMPUTE_BIT，并且 queueCount 至少为 2。
• [C-1-7] GPU 和显示器必须能够同步对共享前缓冲区的访问，以便在 60fps 下使用两个渲染上下文交替眼睛渲染 VR 内容时，不会出现可见的撕裂伪影。
• [C-1-9] 必须实现对 AHardwareBuffer 标志 AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER、AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA 和 AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT 的支持，如 NDK 中所述。
• [C-1-10] 必须实现对 AHardwareBuffer 的支持，其使用标志 AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT、AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE、AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT 的任意组合，至少对于以下格式：AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM、AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM、AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM、AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT。
• [C-SR] 强烈建议支持分配具有多个图层以及 C-1-10 中指定的标志和格式的 AHardwareBuffer。
• [C-1-11] 必须支持 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] 必须支持 HEVC 和 VP9，必须能够解码至少 1920 x 1080（30 fps），压缩到平均 10 Mbps，并且应能够解码 3840 x 2160（30 fps-20 Mbps）（相当于 4 个 1920 x 1080（30 fps-5 Mbps）实例）。
• [C-1-13] 必须支持 HardwarePropertiesManager.getDeviceTemperatures API，并返回皮肤温度的准确值。
• [C-1-14] 必须具有嵌入式屏幕，并且其分辨率必须至少为 1920 x 1080。
• [C-SR] 强烈建议显示分辨率至少为 2560 x 1440。
• [C-1-15] 显示器在 VR 模式下必须至少以 60 Hz 的频率更新。
• [C-1-17] 显示器必须支持低余晖模式，余晖 ≤ 5 毫秒，余晖定义为像素发光的时间量。
• [C-1-18] 必须支持蓝牙 4.2 和蓝牙 LE 数据长度扩展 7.4.3 节。
• [C-1-19] 必须支持并正确报告所有以下默认传感器类型的直接通道类型
  • TYPE_ACCELEROMETER（加速度计）
  • TYPE_ACCELEROMETER_UNCALIBRATED（未校准的加速度计）
  • TYPE_GYROSCOPE（陀螺仪）
  • TYPE_GYROSCOPE_UNCALIBRATED（未校准的陀螺仪）
  • TYPE_MAGNETIC_FIELD（磁场传感器）
  • TYPE_MAGNETIC_FIELD_UNCALIBRATED（未校准的磁场传感器）
• [C-SR] 强烈建议为上面列出的所有直接通道类型支持 TYPE_HARDWARE_BUFFER 直接通道类型。
• [C-1-21] 必须满足 7.3.9 节中指定的 android.hardware.hifi_sensors 的陀螺仪、加速度计和磁力计相关要求。
• [C-SR] 强烈建议支持 android.hardware.sensor.hifi_sensors 功能。
• [C-1-22] 端到端运动到光子延迟时间必须不高于 28 毫秒。
• [C-SR] 强烈建议端到端运动到光子延迟时间不高于 20 毫秒。
• [C-1-23] 首帧比率必须至少为 85%，首帧比率是黑色到白色过渡后的第一帧像素亮度与稳态白色像素亮度之间的比率。
• [C-SR] 强烈建议首帧比率至少为 90%。
• 可以为前台应用程序提供独占核心，并且可以支持 Process.getExclusiveCores API 以返回专用于顶部前台应用程序的 CPU 核心编号。

如果支持独占核心，则该核心

• [C-2-1] 必须不允许任何其他用户空间进程在其上运行（应用程序使用的设备驱动程序除外），但可以允许某些内核进程根据需要运行。

8. 性能和功耗

一些最低性能和功耗标准对于用户体验至关重要，并影响开发者在开发应用程序时的基线假设。

8.1. 用户体验一致性

如果存在某些最低要求以确保应用程序和游戏的一致帧率和响应时间，则可以为最终用户提供流畅的用户界面。设备实现可以根据设备类型，对 第 2 节中描述的用户界面延迟和任务切换具有可衡量的要求。

8.2. 文件 I/O 访问性能

为应用程序私有数据存储 (/data 分区) 提供一致文件访问性能的通用基线，使应用程序开发者可以设置适当的期望，这将有助于他们的软件设计。设备实现可以根据设备类型，对 第 2 节中描述的以下读取和写入操作具有某些要求

• 顺序写入性能。使用 10MB 写入缓冲区写入 256MB 文件进行测量。
• 随机写入性能。使用 4KB 写入缓冲区写入 256MB 文件进行测量。
• 顺序读取性能。使用 10MB 写入缓冲区读取 256MB 文件进行测量。
• 随机读取性能。使用 4KB 写入缓冲区读取 256MB 文件进行测量。

8.3. 省电模式

如果设备实现包括旨在改进设备电源管理的功能（这些功能包含在 AOSP 中或扩展了 AOSP 中包含的功能），则

• [C-1-1] 对于应用程序待机和 Doze 省电模式的触发、维护、唤醒算法以及全局系统设置的使用，不得偏离 AOSP 实现。
• [C-1-2] 对于使用全局设置来管理应用程序待机中每个存储分区的应用程序的作业、警报和网络限制，不得偏离 AOSP 实现。
• [C-1-3] 对于用于应用程序待机的应用程序待机存储分区的数量，不得偏离 AOSP 实现。
• [C-1-4] 必须实现 应用程序待机存储分区和 Doze，如电源管理中所述。
• [C-1-5] 当设备处于省电模式时，必须为 PowerManager.isPowerSaveMode() 返回 true。
• [C-SR] 强烈建议提供用户界面来启用和禁用省电功能。
• [C-SR] 强烈建议提供用户界面来显示所有从应用程序待机和 Doze 省电模式中豁免的应用程序。

除了省电模式外，Android 设备实现还可以实现高级配置和电源接口 (ACPI) 定义的 4 种睡眠电源状态的任何一种或全部。

如果设备实现实现了 ACPI 定义的 S4 电源状态，则

• [C-1-1] 只有在用户采取明确操作将设备置于非活动状态（例如，通过关闭物理上是设备一部分的盖子或关闭车辆或电视）之后，以及在用户重新激活设备之前（例如，通过打开盖子或重新打开车辆或电视）才能进入此状态。

如果设备实现实现了 ACPI 定义的 S3 电源状态，则

• [C-2-1] 必须满足上述 C-1-1，或者，只有在第三方应用程序不需要系统资源（例如屏幕、CPU）时才能进入 S3 状态。

  相反，当第三方应用程序需要系统资源（如本 SDK 中所述）时，必须退出 S3 状态。

  例如，当第三方应用程序请求通过 FLAG_KEEP_SCREEN_ON 保持屏幕开启或通过 PARTIAL_WAKE_LOCK 保持 CPU 运行时，除非如 C-1-1 中所述用户已采取明确操作将设备置于非活动状态，否则设备不得进入 S3 状态。相反，当通过 JobScheduler 实现的第三方应用程序的任务被触发或 Firebase Cloud Messaging 传递给第三方应用程序时，除非用户已将设备置于非活动状态，否则设备必须退出 S3 状态。这些不是全面的示例，AOSP 实现了广泛的唤醒信号，这些信号会触发从此状态唤醒。

8.4. 功耗核算

更准确的功耗核算和报告为应用程序开发者提供了优化应用程序功耗模式的激励和工具。

设备实现

• [SR] 强烈建议提供每个组件的功率配置文件，该文件定义每个硬件组件的电流消耗值以及 Android 开源项目站点中记录的组件随时间推移引起的大致电池耗尽。
• [SR] 强烈建议以毫安时 (mAh) 为单位报告所有功耗值。
• [SR] 强烈建议报告每个进程 UID 的 CPU 功耗。Android 开源项目通过 uid_cputime 内核模块实现满足此要求。
• [SR] 强烈建议通过 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 开发者文档中 安全和权限参考文档 中所定义。

• [C-0-2] 必须支持安装自签名应用程序，而无需任何第三方/机构的任何其他权限/证书。具体而言，兼容设备必须支持以下小节中描述的安全机制。

9.1. 权限

设备实现

• [C-0-1] 必须支持 Android 开发者文档中定义的 Android 权限模型。具体而言，它们必须强制执行 SDK 文档中描述的每个权限；不得省略、更改或忽略任何权限。

• 可以添加其他权限，前提是新的权限 ID 字符串不在 android.\* 命名空间中。

• [C-0-2] PROTECTION_FLAG_PRIVILEGED 的 protectionLevel 权限只能授予预安装在系统映像的特权路径中且在每个应用程序的显式允许列表权限子集中的应用程序。AOSP 实现通过从 etc/permissions/ 路径中的文件中读取和遵循每个应用程序的允许列表权限，并将 system/priv-app 路径用作特权路径来满足此要求。

保护级别为 dangerous 的权限是运行时权限。 targetSdkVersion > 22 的应用程序在运行时请求它们。

设备实现

• [C-0-3] 必须显示专用界面供用户决定是否授予请求的运行时权限，并提供一个界面供用户管理运行时权限。
• [C-0-4] 必须具有用户界面的唯一实现。
• [C-0-5] 除非满足以下条件，否则不得向预安装的应用程序授予任何运行时权限
  • 可以在应用程序使用该权限之前获得用户的同意。
  • 运行时权限与意图模式关联，预安装的应用程序被设置为该意图模式的默认处理程序。
• [C-0-6] 必须仅向注册了正确安全恢复代理的系统应用程序授予 android.permission.RECOVER_KEYSTORE 权限。正确安全恢复代理定义为与设备外远程存储同步的设备上软件代理，该代理配备了安全硬件，其保护级别等同于或强于 Google Cloud Key Vault Service 中描述的保护级别，以防止对锁屏知识因素进行暴力攻击。

设备实现

• [C-0-7] 当应用程序通过标准 Android API 或专有机制请求位置或物理活动数据时，必须遵守 Android 位置权限属性。此类数据包括但不限于

  • 设备的位置（例如，纬度和经度）。
  • 可用于确定或估计设备位置的信息（例如，SSID、BSSID、小区 ID、蓝牙扫描或设备连接到的网络的位置）。
  • 用户的身体活动或身体活动的分类。

更具体地说，设备实现

• [C-0-8] 必须获得用户同意才能允许应用程序访问位置或物理活动数据。
• [C-0-9] 必须仅向持有 SDK 上描述的足够权限的应用程序授予运行时权限。例如，TelephonyManager#getServiceState 需要 android.permission.ACCESS_FINE_LOCATION）。

权限可以标记为受限，从而改变其行为。

• [C-0-10] 除非满足以下条件，否则不得向应用程序授予标记有标志 hardRestricted 的权限

  • 应用程序 APK 文件位于系统分区中。
  • 用户将与 hardRestricted 权限关联的角色分配给应用程序。
  • 安装程序将 hardRestricted 授予应用程序。
  • 应用程序在早期 Android 版本上被授予 hardRestricted。

• [C-0-11] 持有 softRestricted 权限的应用程序必须仅获得有限访问权限，并且在添加到 SDK 中描述的允许列表之前，不得获得完全访问权限，其中为每个 softRestricted 权限定义了完全访问权限和有限访问权限（例如，WRITE_EXTERNAL_STORAGE 和 READ_EXTERNAL_STORAGE）。

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

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

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

• [C-1-1] 仍然必须具有一个活动来处理 android.settings.ACTION_USAGE_ACCESS_SETTINGS 意图模式，但必须将其实现为 no-op，即具有与用户拒绝访问时相同的行为。

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 应用程序，并遵守 第 9 节中其他位置描述的标准 Android 安全模型。

• [C-0-2] 不得授予备用运行时访问权限，以访问受运行时 AndroidManifest.xml 文件中未通过 <uses-permission> 机制请求的权限保护的资源。

• [C-0-3] 备用运行时不得允许应用程序使用受限于系统应用程序的 Android 权限保护的功能。

• [C-0-4] 备用运行时必须遵守 Android 沙箱模型，并且使用备用运行时安装的应用程序不得重用设备上安装的任何其他应用程序的沙箱，除非通过共享用户 ID 和签名证书的标准 Android 机制。

• [C-0-5] 备用运行时不得启动、授予或被授予对与其他 Android 应用程序对应的沙箱的访问权限。

• [C-0-6] 备用运行时不得以超级用户 (root) 或任何其他用户 ID 的任何权限启动、被授予或授予给其他应用程序。

• [C-0-7] 当备用运行时的 .apk 文件包含在设备实现的系统映像中时，它必须使用与用于对设备实现中包含的其他应用程序进行签名的密钥不同的密钥进行签名。

• [C-0-8] 安装应用程序时，备用运行时必须获得用户对应用程序使用的 Android 权限的同意。

• [C-0-9] 当应用程序需要使用设备资源（存在相应的 Android 权限，例如摄像头、GPS 等）时，备用运行时必须告知用户该应用程序将能够访问该资源。

• [C-0-10] 当运行时环境未以这种方式记录应用程序功能时，运行时环境在安装使用该运行时的任何应用程序时，必须列出运行时本身持有的所有权限。

• 备用运行时应通过 PackageManager 将应用程序安装到单独的 Android 沙箱（Linux 用户 ID 等）中。

• 备用运行时可以提供由使用备用运行时的所有应用程序共享的单个 Android 沙箱。

9.5. 多用户支持

Android 包括对多用户的支持，并提供对完全用户隔离的支持。

• 如果设备实现使用可移动媒体作为主外部存储，则可以但不应启用多用户。

如果设备实现包括多用户，则

• [C-1-1] 必须满足与多用户支持相关的以下要求。
• [C-1-2] 对于每个用户，必须实现与 Android 平台安全模型一致的安全模型，如 API 中的安全和权限参考文档中所定义。
• [C-1-3] 必须为每个用户实例设置单独且隔离的共享应用程序存储（又名 /sdcard）目录。
• [C-1-4] 必须确保给定用户拥有和代表该用户运行的应用程序无法列出、读取或写入任何其他用户拥有的文件，即使两个用户的数据都存储在同一卷或文件系统上。
• [C-1-5] 如果设备实现使用可移动媒体进行外部存储 API，则当启用多用户时，必须使用仅存储在仅系统可访问的不可移动媒体上的密钥来加密 SD 卡的内容。由于这将使主机 PC 无法读取媒体，因此设备实现将需要切换到 MTP 或类似的系统，以便为主机 PC 提供对当前用户数据的访问权限。

9.6. 高级短信警告

Android 包括对用户发出任何外发高级短信消息警告的支持。高级短信消息是发送到在运营商处注册的服务的文本消息，可能会向用户收取费用。

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

• [C-1-1] 在向设备中 /data/misc/sms/codes.xml 文件中定义的正则表达式标识的号码发送 SMS 消息之前，必须警告用户。上游 Android 开源项目提供了满足此要求的实现。

9.7. 安全功能

设备实现必须确保符合内核和平台中的安全功能，如下所述。

Android 沙箱包括使用安全增强型 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] 在内核模式下执行时，不得执行用户空间内存（例如硬件 PXN，或通过 CONFIG_CPU_SW_DOMAIN_PAN 或 CONFIG_ARM64_SW_TTBR0_PAN 模拟），在最初随 API 级别 28 或更高版本出厂的设备上。
• [C-0-11] 在内核中，不得在正常 usercopy 访问 API 之外读取或写入用户空间内存（例如硬件 PAN，或通过 CONFIG_CPU_SW_DOMAIN_PAN 或 CONFIG_ARM64_SW_TTBR0_PAN 模拟），在最初随 API 级别 28 或更高版本出厂的设备上。
• [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）。
• [SR] 强烈建议将仅在初始化期间写入的内核数据在初始化后标记为只读（例如 __ro_after_init）。

• [C-SR] 强烈建议随机化内核代码和内存的布局，并避免会危及随机化的暴露（例如 CONFIG_RANDOMIZE_BASE，通过 /chosen/kaslr-seed Device Tree 节点 或 EFI_RNG_PROTOCOL 使用引导加载程序熵）。

• [C-SR] 强烈建议在内核中启用控制流完整性 (CFI)，以提供针对代码重用攻击的额外保护（例如 CONFIG_CFI_CLANG 和 CONFIG_SHADOW_CALL_STACK）。

• [C-SR] 强烈建议不要在已启用控制流完整性 (CFI)、Shadow Call Stack (SCS) 或整数溢出清理 (IntSan) 的组件上禁用它们。
• [C-SR] 强烈建议为任何其他对安全敏感的用户空间组件启用 CFI、SCS 和 IntSan，如 CFI 和 IntSan 中所述。

如果设备实现使用 Linux 内核，则它们

• [C-1-1] 必须实现 SELinux。
• [C-1-2] 必须将 SELinux 设置为全局强制模式。
• [C-1-3] 必须在强制模式下配置所有域。不允许任何宽容模式域，包括特定于设备/供应商的域。
• [C-1-4] 不得修改、省略或替换上游 Android 开源项目 (AOSP) 中 system/sepolicy 文件夹中提供的 neverallow 规则，并且策略必须在所有 neverallow 规则存在的情况下进行编译，包括 AOSP SELinux 域以及设备/供应商特定的域。
• [C-1-5] 必须在每个应用程序的 SELinux 沙盒中运行以 API 级别 28 或更高版本为目标的第三方应用程序，并在每个应用程序的私有数据目录上施加每个应用程序的 SELinux 限制。
• 应保留上游 Android 开源项目的 system/sepolicy 文件夹中提供的默认 SELinux 策略，并且仅为此策略添加其自身的设备特定配置。

如果设备实现已在较早的 Android 版本上启动，并且无法通过系统软件更新满足 [C-1-1] 和 [C-1-5] 的要求，则可以免除这些要求。

如果设备实现使用 Linux 以外的内核，则它们

• [C-2-1] 必须使用等效于 SELinux 的强制访问控制系统。

Android 包含多重深度防御功能，这些功能是设备安全性的组成部分。

9.8. 隐私

9.8.1. 使用历史记录

Android 存储用户选择的历史记录，并通过 UsageStatsManager 管理此类历史记录。

设备实现

• [C-0-1] 必须保持此类用户历史记录的合理保留期限。
• [SR] 强烈建议保持 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 或专有 API 启用屏幕投射或屏幕录制时，必须显示并获得明确的用户同意，其中包含与 AOSP 基本相同的消息。不得为用户提供禁用未来显示用户同意的便利。

• [C-0-3] 必须在启用屏幕投射或屏幕录制时向用户显示持续通知。AOSP 通过在状态栏中显示持续通知图标来满足此要求。

如果设备实现包括系统中通过系统 API ContentCaptureService 或 第 9.8.6 节内容捕获中描述的其他专有方式捕获屏幕上显示的内容和/或录制设备上播放的音频流的功能，则它们

• [C-1-1] 每当启用此功能并主动捕获/录制时，都必须向用户显示持续通知。

如果设备实现包括开箱即用启用的组件，该组件能够录制环境音频和/或录制设备上播放的音频以推断有关用户上下文的有用信息，则它们

• [C-2-1] 除非获得用户的明确同意，否则不得将录制的原始音频或任何可以转换回原始音频或近似副本的格式持久存储在设备上或传输到设备外部。

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 文件中始终开启 VPN 服务的应用程序，必须禁用此用户便利功能，方法是将 SERVICE_META_DATA_SUPPORTS_ALWAYS_ON 属性设置为 false。

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 ContentCaptureService 或其他专有方式，支持设备实现捕获应用程序与用户之间以下交互的机制。

• 屏幕上呈现的文本和图形，包括但不限于通知和辅助数据（通过 AssistStructure API）。
• 媒体数据，例如设备录制或播放的音频或视频。
• 输入事件（例如，按键、鼠标、手势、语音、视频和辅助功能）。
• 应用程序通过 内容捕获 API 或类似功能的专有 API 提供给系统的任何其他事件。

如果设备实现捕获上述数据，则它们

• [C-1-1] 必须在设备中存储所有此类数据时对其进行加密。此加密可以使用 Android 基于文件的加密或 Cipher SDK 中描述的 API 版本 26+ 中列出的任何密码进行。
• [C-1-2] 不得使用 Android 备份方法或任何其他备份方法备份原始数据或加密数据。
• [C-1-3] 必须仅使用隐私保护机制发送所有此类数据和设备日志。隐私保护机制定义为“仅允许聚合分析并防止将记录的事件或派生的结果与单个用户匹配的机制”，以防止任何按用户的数据可被内省（例如，使用差分隐私技术（如 RAPPOR）实现）。
• [C-1-4] 不得将此类数据与设备上的任何用户身份（例如 Account）关联，除非每次关联数据时都获得用户的明确同意。
• [C-1-5] 不得与其他应用程序共享此类数据，除非每次共享时都获得用户的明确同意。
• [C-1-6] 如果 ContentCaptureService 或专有方式收集的数据以任何形式存储在设备上，则必须提供用户便利功能来擦除此类数据。

如果设备实现包括实现系统 API ContentCaptureService 的服务，或任何专有服务，用于捕获上述描述的数据，则它们

• [C-2-1] 不得允许用户使用用户可安装的应用程序或服务替换内容捕获服务，并且必须仅允许预安装的服务捕获此类数据。
• [C-2-2] 不得允许除预安装的内容捕获服务机制之外的任何应用程序能够捕获此类数据。
• [C-2-3] 必须提供用户便利功能来禁用内容捕获服务。
• [C-2-4] 不得省略用户便利功能来管理内容捕获服务持有的 Android 权限，并遵循 第 9.1 节权限中描述的 Android 权限模型。

• [C-SR] 强烈建议保持内容捕获服务组件的独立性，例如，不绑定服务或与其他系统组件共享进程 ID，以下组件除外

  • 电话、联系人、系统 UI 和媒体

9.8.7. 剪贴板访问

设备实现

• [C-0-1] 不得返回剪贴板上的剪切数据（例如，通过 ClipboardManager API），除非应用程序是默认 IME 或当前具有焦点的应用程序。

9.8.8. 位置信息

设备实现

• [C-0-1] 未经用户明确同意或用户启动，不得打开/关闭设备位置设置和 Wi-Fi/蓝牙扫描设置。
• [C-0-2] 必须向用户提供便利功能以访问与位置相关的信息，包括最近的位置请求、应用程序级别权限以及使用 Wi-Fi/蓝牙扫描来确定位置。
• [C-0-3] 必须确保使用紧急位置绕过 API [LocationRequest.setLocationSettingsIgnored()] 的应用程序是由用户启动的紧急会话（例如，拨打 911 或发送短信至 911）。
• [C-0-4] 必须保留紧急位置绕过 API 的能力，以绕过设备位置设置而不更改设置。
• [C-0-5] 必须在后台应用程序使用 [ACCESS_BACKGROUND_LOCATION] 权限访问其位置后，安排通知提醒用户。

9.9. 数据存储加密

所有设备必须满足 9.9.1 节的要求。在早于本文档 API 级别的 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. 基于文件的加密

加密设备

• [C-1-1] 必须在不提示用户输入凭据的情况下启动，并允许直接启动感知应用程序在 ACTION_LOCKED_BOOT_COMPLETED 消息广播后访问设备加密 (DE) 存储。
• [C-1-2] 只有在用户通过提供其凭据（例如，密码、PIN 码、图案或指纹）解锁设备并且 ACTION_USER_UNLOCKED 消息广播后，才允许访问凭据加密 (CE) 存储。
• [C-1-3] 不得提供任何在没有用户提供的凭据或已注册的托管密钥的情况下解锁 CE 保护存储的方法。
• [C-1-4] 必须使用已验证启动，并确保 DE 密钥以加密方式绑定到设备的硬件信任根。
• [C-1-5] 必须使用 AES-256-XTS 或 Adiantum 加密文件内容。AES-256-XTS 是指具有 256 位密码密钥长度的高级加密标准，在 XTS 模式下运行；密钥的完整长度为 512 位。Adiantum 是指 Adiantum-XChaCha12-AES，如 https://github.com/google/adiantum 中指定。
• [C-1-6] 必须使用 AES-256-CBC-CTS 或 Adiantum 加密文件名。

• [C-1-12] 如果设备具有高级加密标准 (AES) 指令，则必须使用 AES-256-XTS 加密文件内容，并使用 AES-256-CBC-CTS 加密文件名（而不是 Adiantum）。AES 指令是基于 ARM 的设备上的 ARMv8 加密扩展，或基于 x86 的设备上的 AES-NI。如果设备没有 AES 指令，则设备可以使用 Adiantum。

• 保护 CE 和 DE 存储区域的密钥

• [C-1-7] 必须以加密方式绑定到硬件支持的密钥库。

• [C-1-8] CE 密钥必须绑定到用户的锁屏凭据。
• [C-1-9] 当用户未指定锁屏凭据时，CE 密钥必须绑定到默认密码。
• [C-1-10] 必须是唯一且不同的，换句话说，没有用户的 CE 或 DE 密钥与任何其他用户的 CE 或 DE 密钥匹配。
• [C-1-11] 必须使用强制支持的密码、密钥长度和模式。

• [C-SR] 强烈建议使用以加密方式绑定到设备硬件信任根的密钥来加密文件系统元数据，例如文件大小、所有权、模式和扩展属性 (xattrs)。

• 应使预安装的基本应用程序（例如，闹钟、电话、消息程序）能够感知直接启动。

上游 Android 开源项目基于 Linux 内核“fscrypt”加密功能提供了此功能的首选实现。

9.10. 设备完整性

以下要求确保设备完整性状态的透明度。设备实现

• [C-0-1] 必须通过系统 API 方法 PersistentDataBlockManager.getFlashLockState() 正确报告其引导加载程序状态是否允许刷写系统映像。FLASH_LOCK_UNKNOWN 状态保留供从早期版本的 Android 升级的设备实现使用，在早期版本的 Android 中，此新的系统 API 方法不存在。

• [C-0-2] 必须支持已验证启动以确保设备完整性。

如果设备实现已在较早版本的 Android 上启动而未支持已验证启动，并且无法通过系统软件更新添加对此功能的支持，则可以免除此要求。

已验证启动是一项保证设备软件完整性的功能。如果设备实现支持此功能，则它们

• [C-1-1] 必须声明平台功能标志 android.software.verified_boot。
• [C-1-2] 必须在每个启动序列上执行验证。
• [C-1-3] 必须从作为信任根的不可变硬件密钥开始验证，并一直向上验证到系统分区。
• [C-1-4] 必须实现验证的每个阶段，以在执行下一阶段的代码之前检查下一阶段中所有字节的完整性和真实性。
• [C-1-5] 必须使用与 NIST 当前关于哈希算法 (SHA-256) 和公钥大小 (RSA-2048) 的建议一样强大的验证算法。
• [C-1-6] 当系统验证失败时，不得允许启动完成，除非用户同意尝试仍然启动，在这种情况下，不得使用来自任何未验证存储块的数据。
• [C-1-7] 除非用户已显式解锁引导加载程序，否则不得允许修改设备上已验证的分区。
• [C-SR] 如果设备中有多个离散芯片（例如，无线电、专用图像处理器），则强烈建议每个芯片的启动过程在启动时验证每个阶段。
• [C-1-8] 必须使用防篡改存储：用于存储引导加载程序是否已解锁。防篡改存储意味着引导加载程序可以检测到存储是否已从 Android 内部被篡改。
• [C-1-9] 在使用设备时，必须提示用户，并且在允许从引导加载程序锁定模式转换为引导加载程序解锁模式之前，需要物理确认。
• [C-1-10] 必须为 Android 使用的分区（例如，启动分区、系统分区）实施回滚保护，并使用防篡改存储来存储用于确定允许的最低操作系统版本的元数据。
• [C-SR] 强烈建议使用根植于已验证启动保护的分区的信任链来验证所有特权应用程序 APK 文件。
• [C-SR] 强烈建议在执行特权应用程序从其 APK 文件外部加载的任何可执行工件（例如，动态加载的代码或编译的代码）之前对其进行验证，或者强烈建议完全不要执行它们。
• 应为具有持久固件的任何组件（例如，调制解调器、摄像头）实施回滚保护，并且应使用防篡改存储来存储用于确定允许的最低版本的元数据。

如果设备实现已在较早版本的 Android 上启动而未支持 C-1-8 到 C-1-10，并且无法通过系统软件更新添加对这些要求的支持，则可以免除这些要求。

上游 Android 开源项目在 external/avb/ 存储库中提供了此功能的首选实现，该实现可以集成到用于加载 Android 的引导加载程序中。

设备实现

• [C-R] 建议支持 Android 受保护确认 API。

如果设备实现支持 Android 受保护确认 API，则它们

• [C-3-1] 必须为 ConfirmationPrompt.isSupported() API 报告 true。

• [C-3-2] 必须确保在 Android OS 中运行的代码（包括其内核，无论是恶意的还是其他的）都无法在没有用户交互的情况下生成肯定响应。

• [C-3-3] 必须确保即使在 Android OS（包括其内核）受到破坏的情况下，用户也能够查看和批准提示的消息。

9.11. 密钥和凭据

Android 密钥库系统允许应用程序开发者在容器中存储加密密钥，并通过 KeyChain API 或 Keystore API 在加密操作中使用它们。设备实现

• [C-0-1] 必须允许导入或生成至少 8,192 个密钥。
• [C-0-2] 锁屏身份验证必须限制尝试次数，并且必须具有指数退避算法。超过 150 次失败尝试后，每次尝试的延迟必须至少为 24 小时。
• 不应限制可以生成的密钥数量

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

• [C-1-1] 必须使用隔离的执行环境备份密钥库实现。
• [C-1-2] 必须具有 RSA、AES、ECDSA 和 HMAC 加密算法以及 MD5、SHA1 和 SHA-2 系列哈希函数的实现，以便在安全隔离于内核和之上运行的代码的区域中正确支持 Android 密钥库系统支持的算法。安全隔离必须阻止内核或用户空间代码可能访问隔离环境内部状态的所有潜在机制，包括 DMA。上游 Android 开源项目 (AOSP) 通过使用 Trusty 实现来满足此要求，但另一个基于 ARM TrustZone 的解决方案或第三方审查的基于适当虚拟机监控程序隔离的安全实现是替代选项。
• [C-1-3] 必须在隔离的执行环境中执行锁屏身份验证，并且仅在成功时，才允许使用绑定到身份验证的密钥。锁屏凭据的存储方式必须仅允许隔离的执行环境执行锁屏身份验证。上游 Android 开源项目提供了 Gatekeeper 硬件抽象层 (HAL) 和 Trusty，可用于满足此要求。
• [C-1-4] 必须支持密钥证明，其中证明签名密钥受安全硬件保护，并且签名在安全硬件中执行。证明签名密钥必须在足够多的设备之间共享，以防止密钥被用作设备标识符。满足此要求的一种方法是共享相同的证明密钥，除非生产了至少 100,000 个给定 SKU 的单元。如果生产了超过 100,000 个 SKU 的单元，则每个 100,000 个单元可以使用不同的密钥。

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

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

9.11.1. 安全锁屏和身份验证

AOSP 实现遵循分层身份验证模型，其中基于知识工厂的主要身份验证可以由辅助强生物识别或较弱的三级模式支持。

设备实现

• [C-SR] 强烈建议仅将以下方法之一设置为主要身份验证方法
  • 数字 PIN 码
  • 字母数字密码
  • 在正好 3x3 个点的网格上的滑动图案

请注意，以上身份验证方法在本文档中称为推荐的主要身份验证方法。

如果设备实现添加或修改了推荐的主要身份验证方法，并使用新的身份验证方法作为锁定屏幕的安全方式，则新的身份验证方法

• [C-2-1] 必须是 需要用户身份验证才能使用密钥中描述的用户身份验证方法。
• [C-2-2] 当用户解锁安全锁屏时，必须解锁第三方开发者应用程序使用的所有密钥。例如，所有密钥必须通过相关 API（例如 createConfirmDeviceCredentialIntent 和 setUserAuthenticationRequired）可供第三方开发者应用程序使用。

如果设备实现添加或修改了基于已知秘密解锁锁屏的身份验证方法，并使用新的身份验证方法被视为锁定屏幕的安全方式

• [C-3-1] 最短允许输入长度的熵必须大于 10 位。
• [C-3-2] 所有可能输入的最大熵必须大于 18 位。
• [C-3-3] 新的身份验证方法不得替换 AOSP 中实现和提供的任何推荐的主要身份验证方法（即 PIN 码、图案、密码）。
• [C-3-4] 当设备策略控制器 (DPC) 应用程序通过 DevicePolicyManager.setPasswordQuality() 方法设置密码质量策略时，新的身份验证方法必须禁用，且质量常量比 PASSWORD_QUALITY_SOMETHING 更严格。
• [C-3-5] 新的身份验证方法必须每 72 小时或更短的时间内回退到推荐的主要身份验证方法（即 PIN 码、图案、密码），或者清楚地向用户披露，为了保护其数据的隐私，某些数据将不会被备份。

如果设备实现添加或修改了推荐的主要身份验证方法以解锁锁屏，并使用基于生物识别的新身份验证方法被视为锁定屏幕的安全方式，则新方法

• [C-4-1] 必须满足 第 7.3.10 节中针对便捷描述的所有要求。
• [C-4-2] 必须具有回退机制以使用基于已知秘密的推荐的主要身份验证方法之一。
• [C-4-3] 当设备策略控制器 (DPC) 应用程序通过调用方法 DevicePolicyManager.setKeyguardDisabledFeatures() 设置了锁屏功能策略时，必须禁用该方法，并且仅允许推荐的主要身份验证解锁屏幕，其中包含任何关联的生物识别标志（即 KEYGUARD_DISABLE_BIOMETRICS、KEYGUARD_DISABLE_FINGERPRINT、KEYGUARD_DISABLE_FACE 或 KEYGUARD_DISABLE_IRIS）。

如果生物识别身份验证方法不满足 第 7.3.10 节中描述的强要求

• [C-5-1] 如果设备策略控制器 (DPC) 应用程序通过 DevicePolicyManager.setPasswordQuality() 方法设置密码质量策略，且质量常量比 PASSWORD_QUALITY_BIOMETRIC_WEAK 更严格，则必须禁用这些方法。
• [C-5-2] 在任何 4 小时空闲超时期限后，必须要求用户进行推荐的主要身份验证（例如：PIN 码、图案、密码）。在成功确认设备凭据后，空闲超时期限将重置。
• [C-5-3] 这些方法不得被视为安全锁屏，并且必须满足本节下面以 C-8 开头的要求。

如果设备实现添加或修改了身份验证方法以解锁锁屏，并且新的身份验证方法基于物理令牌或位置

• [C-6-1] 它们必须具有回退机制以使用基于已知秘密的推荐的主要身份验证方法之一，并满足被视为安全锁屏的要求。
• [C-6-2] 当设备策略控制器 (DPC) 应用程序通过 DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) 方法或 DevicePolicyManager.setPasswordQuality() 方法设置策略时，新的方法必须禁用，并且仅允许推荐的主要身份验证方法之一解锁屏幕，且质量常量比 PASSWORD_QUALITY_UNSPECIFIED 更严格。
• [C-6-3] 必须至少每 4 小时或更短的时间内要求用户进行推荐的主要身份验证方法之一（例如，PIN 码、图案、密码）。
• [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-8] 除非用户的安全（例如，驾驶员分心）受到关注，否则用户必须至少每 72 小时或更短时间内接受一次推荐的主要身份验证（例如：PIN 码、图案、密码）方法的质询。
• [C-7-9] 除非用户的安全（例如，驾驶员分心）受到关注，否则在任何 4 小时空闲超时 period 之后，用户必须接受一次推荐的主要身份验证（例如：PIN 码、图案、密码）方法的质询。在成功确认设备凭据后，空闲超时 period 将重置。
• [C-7-10] 不得被视为安全锁屏，并且必须遵循下面 C-8 中列出的约束。
• [C-7-11] 不得允许主要个人设备（例如：手持设备）上的信任代理解锁设备，并且只能使用它们将已解锁的设备保持解锁状态，最长不超过 4 小时。AOSP 中 TrustManagerService 的默认实现满足此要求。
• [C-7-12] 必须使用加密安全（例如 UKEY2）的通信通道将托管令牌从存储设备传递到目标设备。

如果设备实现添加或修改了用于解锁锁屏的身份验证方法，而该锁屏不是上述安全锁屏，并使用新的身份验证方法来解锁 Keyguard

• [C-8-1] 当设备策略控制器 (DPC) 应用程序通过 DevicePolicyManager.setPasswordQuality() 方法设置了比 PASSWORD_QUALITY_UNSPECIFIED 更严格的质量常量的密码质量策略时，必须禁用新方法。
• [C-8-2] 它们不得重置由 DevicePolicyManager.setPasswordExpirationTimeout() 设置的密码过期计时器。
• [C-8-3] 它们不得公开 API 以供第三方应用程序更改锁定状态。

9.11.2. StrongBox

Android Keystore 系统 允许应用程序开发人员将加密密钥存储在专用安全处理器以及上述隔离的执行环境中。这种专用安全处理器称为“StrongBox”。以下要求 C-1-3 到 C-1-11 定义了设备必须满足才能获得 StrongBox 资格的要求。

具有专用安全处理器的设备实现

• [C-SR] 强烈建议支持 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-10] 必须包含已根据安全 IC 保护配置文件 BSI-CC-PP-0084-2014 认证的硬件，或由国家认可的测试实验室根据 通用准则对智能卡应用攻击潜力 评估的高攻击潜力漏洞评估进行评估。
  • [C-1-11] 必须包含已由国家认可的测试实验室根据 通用准则对智能卡应用攻击潜力 评估的高攻击潜力漏洞评估进行评估的固件。
  • [C-SR] 强烈建议包含使用安全目标、评估保证级别 (EAL) 5 并由 AVA_VAN.5 增强的硬件进行评估。EAL 5 认证很可能在未来的版本中成为一项要求。

• [C-SR] 强烈建议提供内部人员攻击抵抗 (IAR)，这意味着有权访问固件签名密钥的内部人员无法生成导致 StrongBox 泄露机密、绕过功能安全要求或以其他方式访问敏感用户数据的固件。实现 IAR 的推荐方法是仅当通过 IAuthSecret HAL 提供主要用户密码时才允许固件更新。

9.12. 数据删除

所有设备实现

• [C-0-1] 必须为用户提供执行“恢复出厂设置”的机制。
• [C-0-2] 必须删除 userdata 文件系统上的所有数据。
• [C-0-3] 必须以满足相关行业标准（例如 NIST SP800-88）的方式删除数据。
• [C-0-4] 当主用户的设备策略控制器应用程序调用 DevicePolicyManager.wipeData() API 时，必须触发上述“恢复出厂设置”过程。
• 可以提供快速数据擦除选项，该选项仅执行逻辑数据擦除。

9.13. 安全启动模式

Android 提供安全启动模式，该模式允许用户启动到仅允许运行预安装的系统应用程序且禁用所有第三方应用程序的模式。此模式（称为“安全启动模式”）为用户提供了卸载潜在有害的第三方应用程序的功能。

设备实现是

• [SR] 强烈建议实现安全启动模式。

如果设备实现实现了安全启动模式，则它们

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

10. 软件兼容性测试

设备实现必须通过本节中描述的所有测试。但是，请注意，没有哪个软件包是完全全面的。因此，强烈建议设备实现者尽可能少地更改 Android 开放源代码项目中提供的 Android 参考和首选实现。这将最大限度地降低引入错误的风险，这些错误会产生不兼容性，需要返工和潜在的设备更新。

10.1. 兼容性测试套件

设备实现

• [C-0-1] 必须使用设备上的最终交付软件通过 Android 开放源代码项目中提供的 Android 兼容性测试套件 (CTS)。

• [C-0-2] 必须确保在 CTS 中存在歧义以及对参考源代码的任何重新实现的情况下保持兼容性。

CTS 旨在在实际设备上运行。与任何软件一样，CTS 本身可能包含错误。CTS 的版本将独立于此兼容性定义进行版本控制，并且可能会为 Android 10 发布 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)”下载。
  • 通过主机 PC 通过 USB 进行“ tethered” 更新。
  • 通过重新启动和从可移动存储上的文件进行更新的“离线”更新。

• [C-0-2] 使用的更新机制必须支持在不擦除用户数据的情况下进行更新。也就是说，更新机制必须保留应用程序私有数据和应用程序共享数据。请注意，上游 Android 软件包括满足此要求的更新机制。

• [C-0-3] 整个更新必须签名，并且设备上的更新机制必须根据设备上存储的公钥验证更新和签名。

• [C-SR] 强烈建议签名机制使用 SHA-256 对更新进行哈希处理，并使用 ECDSA NIST P-256 根据公钥验证哈希值。

如果设备实现包括对非计量数据连接（例如 802.11 或蓝牙 PAN（个人区域网络）配置文件）的支持，则它们

• [C-1-1] 必须支持通过重新启动进行离线更新的 OTA 下载。

对于使用 Android 6.0 及更高版本启动的设备实现，更新机制应支持验证系统映像在 OTA 后是否与预期结果完全相同。自 Android 5.1 以来添加的上游 Android 开放源代码项目中的基于块的 OTA 实现满足此要求。

此外，设备实现应支持 A/B 系统更新。AOSP 使用启动控制 HAL 实现此功能。

如果在设备发布后但在其合理的产品寿命期内发现设备实现中存在影响第三方应用程序兼容性的错误（这需要在与 Android 兼容性团队协商后确定），则

• [C-2-1] 设备实现者必须通过可根据刚刚描述的机制应用的软件更新来纠正错误。

Android 包括允许设备所有者应用程序（如果存在）控制系统更新安装的功能。如果设备的系统更新子系统报告 android.software.device_admin，则它们

• [C-3-1] 必须实现 SystemUpdatePolicy 类中描述的行为。

12. 文档变更日志

有关此版本中兼容性定义的更改摘要

• 文档变更日志

有关各个部分更改的摘要

1. 简介
2. 设备类型
3. 软件
4. 应用程序打包
5. 多媒体
6. 开发者工具和选项
7. 硬件兼容性
8. 性能和功耗
9. 安全模型
10. 软件兼容性测试
11. 可更新的软件
12. 文档变更日志
13. 联系我们

12.1. 变更日志查看提示

更改标记如下

• CDD
  对兼容性要求的实质性更改。

• 文档
  外观或构建相关的更改。

为了获得最佳观看效果，请将 pretty=full 和 no-merges URL 参数附加到您的变更日志 URL。

13. 联系我们

您可以加入 android-compatibility 论坛，并请求澄清或提出您认为文档未涵盖的任何问题。