Android 12 兼容性定义

1. 简介

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

“必须 (MUST)”、“禁止 (MUST NOT)”、 “必需 (REQUIRED)”、“应 (SHALL)”、“不应 (SHALL NOT)”、“应该 (SHOULD)”、“不应该 (SHOULD NOT)”、“建议 (RECOMMENDED)”、“可以 (MAY)”和“可选 (OPTIONAL)”等词语的用法符合 IETF RFC2119 标准（请参阅 RFC2119）中的定义。

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

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

如果本定义或第 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。
    • 当要求为有条件时，第一个条件的 ID 分配为 1，并且在同一章节和同一设备类型中，编号递增 1。
  • 要求 ID
    • 此 ID 从 1 开始，并在同一章节和同一条件下递增 1。

1.1.3. 第 2 节中的要求 ID

第 2 节中的要求 ID 由两部分组成。第一部分对应于如上所述的章节 ID。第二部分标识外形规格和特定于外形规格的要求。

章节 ID 后跟上述要求 ID。

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

2. 设备类型

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

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

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

2.1 设备配置

有关按设备类型划分的硬件配置的主要差异，请参阅本节后面的设备特定要求。

2.2. 手持设备要求

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

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

  • 具有提供移动性的电源，例如电池。
  • 物理对角线屏幕尺寸在 3.3 英寸（或对于在 API 级别 29 或更早版本上发布的设备实现为 2.5 英寸）到 8 英寸之间。

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

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

2.2.1. 硬件

手持设备实现

  • [7.1.1.1/H-0-1] **必须**至少有一个符合 Android 兼容性要求的显示屏，且该显示屏必须满足本文档中描述的所有要求。

  • [7.1.1.3/H-SR-1] **强烈建议**提供用户更改显示尺寸（屏幕密度）的方式。

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

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

  • [7.1.1.1/H-1-1]* **必须**使提供给第三方应用的逻辑屏幕在短边上至少为 2 英寸，在长边上至少为 2.7 英寸。在 Android API 级别 29 或更早版本上发布的设备可以**豁免**此要求。

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

  • [7.1.1.1/H-2-1]* **必须**使提供给第三方应用的逻辑屏幕在短边上至少为 2.7 英寸。在 Android API 级别 29 或更早版本上发布的设备可以**豁免**此要求。

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

  • [7.1.4.5/H-1-1] **必须**声明支持 EGL_EXT_gl_colorspace_bt2020_pq、EGL_EXT_surface_SMPTE2086_metadata、EGL_EXT_surface_CTA861_3_metadata、VK_EXT_swapchain_colorspace 和 VK_EXT_hdr_metadata 扩展程序。

手持设备实现

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

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

手持设备实现

  • [7.1.5/H-0-1] **必须**支持上游 Android 开放源代码实现的旧版应用兼容模式。即，设备实现**不得**更改激活兼容模式的触发器或阈值，并且**不得**更改兼容模式本身的行为。
  • [7.2.1/H-0-1] **必须**支持第三方输入法编辑器 (IME) 应用。
  • [7.2.3/H-0-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-1] **强烈建议**在长按 KEYCODE_MEDIA_PLAY_PAUSE 或 KEYCODE_HEADSETHOOK 时启动用户选择的辅助应用，即实现 VoiceInteractionService 的应用，或处理 ACTION_ASSIST 的 Activity（如果前台 Activity 不处理这些长按事件）。
  • [7.3.1/H-SR-1] **强烈建议**包含 3 轴加速度计。

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

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

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

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

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

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

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

  • [7.3.8/H] **应该**包含接近传感器。

手持设备实现

  • [7.3.11/H-SR-1] **建议**支持具有 6 个自由度的姿势传感器。
  • [7.4.3/H] **应该**包含对蓝牙和低功耗蓝牙 (Bluetooth LE) 的支持。

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

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

手持设备实现

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

手持设备实现

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

如果手持设备实现包含支持外围设备模式的 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 代码的软件映射：
功能 映射 上下文 行为
A HID 用法页：0x0C
HID 用法：0x0CD
内核键：KEY_PLAYPAUSE
Android 键：KEYCODE_MEDIA_PLAY_PAUSE		 媒体播放 输入：短按
输出：播放或暂停
输入：长按
输出：启动语音命令
发送：如果设备已锁定或屏幕已关闭，则发送 android.speech.action.VOICE_SEARCH_HANDS_FREE。否则，发送 android.speech.RecognizerIntent.ACTION_WEB_SEARCH
来电 输入：短按
输出：接听电话
输入：长按
输出：拒接电话
通话中 输入：短按
输出：结束通话
输入：长按
输出：麦克风静音或取消静音
B HID 用法页：0x0C
HID 用法：0x0E9
内核键：KEY_VOLUMEUP
Android 键：VOLUME_UP		 媒体播放、通话中 输入：短按或长按
输出：增大系统或耳机音量
C HID 用法页：0x0C
HID 用法：0x0EA
内核键：KEY_VOLUMEDOWN
Android 键：VOLUME_DOWN		 媒体播放、通话中 输入：短按或长按
输出：减小系统或耳机音量
D HID 用法页：0x0C
HID 用法：0x0CF
内核键：KEY_VOICECOMMAND
Android 键：KEYCODE_VOICE_ASSIST		 全部。可在任何实例中触发。 输入：短按或长按
输出：启动语音命令
  • [7.8.2.2/H-1-2] **必须**在插入插头时触发 ACTION_HEADSET_PLUG，但前提是必须在正确枚举 USB 音频接口和端点之后，以便识别所连接的终端类型。

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

  • [7.8.2.2/H-2-1] **必须**广播 Intent ACTION_HEADSET_PLUG，并将“microphone”extra 设置为 0。

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

  • [7.8.2.2/H-3-1] **必须**广播 Intent ACTION_HEADSET_PLUG，并将“microphone”extra 设置为 1。

当在连接 USB 外围设备时调用 API AudioManager.getDevices() 时，它们

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

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

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

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

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

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

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

  • [7.8.2.2/H-SR-1] **强烈建议**在连接 USB-C 音频外围设备后，在不到 1000 毫秒的时间内执行 USB 描述符的枚举、识别终端类型并广播 Intent ACTION_HEADSET_PLUG。

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

  • [5.6(#56_audio-latency)/H-1-1] **必须**在至少一个受支持的路径上，经过 5 次测量，平均连续往返延迟时间为 800 毫秒或更短，平均绝对偏差小于 100 毫秒。

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

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

如果手持设备实现方案包含至少一个线性谐振致动器，则

  • [7.10/H]* 应在纵向模式的 X 轴上移动触感致动器。

如果手持设备实现方案具有 X 轴线性谐振致动器 (LRA) 触感致动器，则

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

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

2.2.2. 多媒体

手持设备实现方案必须支持以下音频编码和解码格式，并向第三方应用提供这些格式

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

手持设备实现方案必须支持以下视频编码格式，并向第三方应用提供这些格式

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

手持设备实现方案必须支持以下视频解码格式，并向第三方应用提供这些格式

  • [5.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] 必须具有一个应用来处理 ACTION_GET_CONTENT、ACTION_OPEN_DOCUMENT、ACTION_OPEN_DOCUMENT_TREE 和 ACTION_CREATE_DOCUMENT Intent（如 SDK 文档中所述），并提供用户操作界面，以便通过使用 DocumentsProvider API 访问文档提供程序数据。
  • [3.2.3.1/H-0-2]* 必须预加载一个或多个应用或服务组件，其中包含 intent 处理程序，用于处理此处 here 列出的所有公共 intent 过滤器模式。
  • [3.2.3.1/H-SR-1] 强烈建议预加载一个电子邮件应用，该应用可以处理 ACTION_SENDTO 或 ACTION_SEND 或 ACTION_SEND_MULTIPLE Intent 以发送电子邮件。
  • [3.4.1/H-0-1] 必须提供 android.webkit.Webview API 的完整实现。
  • [3.4.2/H-0-1] 必须包含一个独立的浏览器应用，用于常规用户网页浏览。
  • [3.8.1/H-SR-1] 强烈建议实现一个默认启动器，该启动器支持应用内固定快捷方式、微件和 widgetFeatures。
  • [3.8.1/H-SR-2] 强烈建议实现一个默认启动器，该启动器可以通过 ShortcutManager API 快速访问第三方应用提供的其他快捷方式。
  • [3.8.1/H-SR-3] 强烈建议包含一个默认启动器应用，该应用显示应用图标的徽章。
  • [3.8.2/H-SR-1] 强烈建议支持第三方应用微件。
  • [3.8.3/H-0-1] 必须允许第三方应用通过 Notification 和 NotificationManager API 类来通知用户值得注意的事件。
  • [3.8.3/H-0-2] 必须支持富通知。
  • [3.8.3/H-0-3] 必须支持浮动通知。
  • [3.8.3/H-0-4] 必须包含通知阴影，以便用户能够直接控制（例如，回复、稍后提醒、关闭、阻止）通知，方法是通过用户操作界面（例如，操作按钮或 AOSP 中实现的控制面板）。
  • [3.8.3/H-0-5] 必须在通知阴影中显示通过 RemoteInput.Builder setChoices() 提供的选项。
  • [3.8.3/H-SR-1] 强烈建议在通知阴影中显示通过 RemoteInput.Builder setChoices() 提供的第一个选项，而无需额外的用户互动。
  • [3.8.3/H-SR-2] 强烈建议当用户展开通知阴影中的所有通知时，在通知阴影中显示通过 RemoteInput.Builder setChoices() 提供的所有选项。
  • [3.8.3.1/H-SR-1] 强烈建议以内嵌方式显示 Notification.Action.Builder.setContextual 设置为 true 的操作，与 Notification.Remoteinput.Builder.setChoices 显示的回复对齐。
  • [3.8.4/H-SR-1] 强烈建议在设备上实现一个助理来处理 Assist 操作。

如果手持设备实现方案支持 Assist 操作，则

  • [3.8.4/H-SR-2] 强烈建议使用长按 HOME 键作为启动助理应用的指定互动方式，如 7.2.3 节中所述。必须启动用户选择的助理应用，换句话说，即实现 VoiceInteractionService 的应用，或者处理 ACTION_ASSIST Intent 的 Activity。

如果手持设备实现方案支持对话通知，并将对话通知与提醒通知和静默非对话通知分组到不同的版块，则

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

如果 Android 手持设备实现方案支持锁屏，则

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

如果手持设备实现方案支持安全锁屏，则

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

如果手持设备实现方案包含对 ControlsProviderService 和 Control API 的支持，并允许第三方应用发布设备控件，那么它们

  • [3.8.16/H-1-1] 必须声明功能标记 android.software.controls 并将其设置为 true。
  • [3.8.16/H-1-2] 必须提供用户操作界面，使用户能够从第三方应用通过 ControlsProviderService 和 Control API 注册的控件中添加、编辑、选择和操作用户收藏的设备控件。
  • [3.8.16/H-1-3] 必须在默认启动器的三次互动内提供对此用户操作界面的访问权限。
  • [3.8.16/H-1-4] 必须在此用户操作界面中准确呈现每个通过 ControlsProviderService API 提供控件的第三方应用的名称和图标，以及 Control API 提供的任何指定字段。

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

手持设备实现

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

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

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

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

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

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

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

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

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

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

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/秒的顺序写入性能。
  • [8.2/H-0-2] 必须确保至少 0.5 MB/秒的随机写入性能。
  • [8.2/H-0-3] 必须确保至少 15 MB/秒的顺序读取性能。
  • [8.2/H-0-4] 必须确保至少 3.5 MB/秒的随机读取性能。

如果手持设备实现方案包含用于改进设备功耗管理的功能（这些功能包含在 AOSP 中或扩展了 AOSP 中包含的功能），则

  • [8.3/H-1-1] 必须提供用户操作界面来启用和停用省电模式功能。
  • [8.3/H-1-2] 必须提供用户操作界面来显示所有免于应用待机和 Doze 省电模式的应用。

手持设备实现

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

如果手持设备实现方案包含屏幕或视频输出，则

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 Keystore 系统支持的算法。安全隔离必须阻止内核或用户空间代码可能访问隔离环境内部状态的所有潜在机制，包括 DMA。上游 Android 开源项目 (AOSP) 通过使用 Trusty 实现方案来满足此要求，但另一个基于 ARM TrustZone 的解决方案或经过第三方审核的基于适当虚拟机监控程序的隔离的安全实现方案也是替代方案。
  • [9.11/H-0-4] 必须在隔离的执行环境中执行锁屏身份验证，并且仅在成功时，才允许使用身份验证绑定的密钥。锁屏凭据的存储方式必须仅允许隔离的执行环境执行锁屏身份验证。上游 Android 开源项目提供了 Gatekeeper 硬件抽象层 (HAL) 和 Trusty，可用于满足此要求。
  • [9.11/H-0-5] 必须支持密钥证明，其中证明签名密钥受安全硬件保护，并且签名在安全硬件中执行。证明签名密钥必须在足够多数量的设备之间共享，以防止这些密钥被用作设备标识符。满足此要求的一种方法是共享相同的证明密钥，除非生产了给定 SKU 的至少 100,000 个单元。如果生产了 SKU 的 100,000 个以上单元，则可以为每 100,000 个单元使用不同的密钥。
  • [9/H-0-1] 必须声明“android.hardware.security.model.compatible”功能。

请注意，如果设备实现方案已在较早的 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 对启用/停用其他用户访问语音通话和短信的控件的实现方案保持一致。

Android 通过 System API VoiceInteractionService 支持一种安全且始终开启的热词检测机制，无需麦克风访问指示

如果手持设备实现方案支持 System API HotwordDetectionService 或另一种无需麦克风访问指示的热词检测机制，则

  • [9.8/H-1-1] 必须确保热词检测服务只能将数据传输到 System 或 ContentCaptureService
  • [9.8/H-1-2] 必须确保热词检测服务只能通过 HotwordDetectionService API 将麦克风音频数据或从中派生的数据传输到系统服务器，或通过 ContentCaptureManager API 传输到 ContentCaptureService。
  • [9.8/H-1-3] 对于硬件触发的单个热词检测服务请求，不得提供超过 30 秒的麦克风音频。
  • [9.8/H-1-4] 对于发送给热词检测服务的单个请求，不得提供早于 8 秒的缓冲麦克风音频。
  • [9.8/H-1-5] 不得向语音互动服务或类似实体提供早于 30 秒的缓冲麦克风音频。
  • [9.8/H-1-6] 对于每个成功的热词结果，不允许从热词检测服务传输超过 100 字节的数据。
  • [9.8/H-1-7] 对于每个否定热词结果，不允许从热词检测服务传输超过 5 位的数据。
  • [9.8/H-1-8] 仅允许在来自系统服务器的热词验证请求中，才允许从热词检测服务传输数据。
  • [9.8/H-1-9] 不得允许用户可安装的应用提供热词检测服务。
  • [9.8/H-1-10] 不得在 UI 中显示有关热词检测服务使用麦克风的定量数据。
  • [9.8/H-1-11] 必须记录每次从热词检测服务传输的数据的字节数，以便安全研究人员进行检查。
  • [9.8/H-1-12] 必须支持调试模式，该模式记录每次从热词检测服务传输的原始内容，以便安全研究人员进行检查。
  • [9.8/H-1-13] 必须至少每小时或每 30 次硬件触发事件（以先到者为准）重启托管热词检测服务的进程一次。
  • [9.8/H-1-14] 当成功的热词结果传输到语音互动服务或类似实体时，必须显示麦克风指示器，如 9.8.2 节中所述。
  • [9.8/H-SR-1] 强烈建议在将应用设置为热词检测服务提供程序之前通知用户。
  • [9.8/H-SR-2] 强烈建议不允许从热词检测服务传输非结构化数据。

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

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

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

  • [9.8.2/H-4-1] 当应用正在访问来自麦克风的音频数据时，必须显示麦克风指示器，但仅当 HotwordDetectionService、SOURCE_HOTWORD、ContentCaptureService 或在 CDD 标识符为 [C-4-X] 的 9.1 节中调用的角色中持有应用访问麦克风时除外。
  • [9.8.2/H-4-2] 必须显示从 PermissionManager.getIndicatorAppOpUsageData() 返回的最近和活动应用列表（这些应用正在使用麦克风），以及与它们关联的任何归因消息。
  • [9.8.2/H-4-3] 不得为具有可见用户界面或直接用户互动的系统应用隐藏麦克风指示器。
  • [9.8.2/H-4-4] 必须显示从 PermissionManager.getIndicatorAppOpUsageData() 返回的最近和活动应用列表（这些应用正在使用麦克风），以及与它们关联的任何归因消息。

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

  • [9.8.2/H-5-1] 当应用正在访问实时摄像头数据时，必须显示摄像头指示器，但仅当在 CDD 标识符为 [C-4-X] 的 9.1 节中调用的角色中持有应用访问摄像头时除外。
  • [9.8.2/H-5-2] 必须显示从 PermissionManager.getIndicatorAppOpUsageData() 返回的最近和活动应用列表（这些应用正在使用摄像头），以及与它们关联的任何归因消息。
  • [9.8.2/H-5-3] 不得为具有可见用户界面或直接用户互动的系统应用隐藏摄像头指示器。

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 二进制文件必须接受 protobuf 配置作为输入，该配置符合 perfetto 文档中定义的架构。
    • [6.1/H-0-4]* perfetto 二进制文件必须将 protobuf 跟踪作为输出写入，该跟踪符合 perfetto 文档中定义的架构。
    • [6.1/H-0-5]* 必须通过 perfetto 二进制文件提供至少 perfetto 文档中描述的数据源。
    • [6.1/H-0-6]* perfetto 跟踪守护程序必须默认启用（系统属性 persist.traced.enable）。

2.2.7. 手持媒体性能等级

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

2.2.7.1. 媒体

如果手持设备实现方案为 android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS 返回 android.os.Build.VERSION_CODES.R，则它们

  • 必须满足 android 11 CDD 2.2.7.1 节中列出的媒体要求

如果手持设备实现方案为 android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS 返回 android.os.Build.VERSION_CODES.S，则它们

  • [5.1/H-1-1] 必须通过 CodecCapabilities.getMaxSupportedInstances() 和 VideoCapabilities.getSupportedPerformancePoints() 方法，通告可在任何编解码器组合中并发运行的最大硬件视频解码器会话数。
  • [5.1/H-1-2] 必须支持 6 个硬件视频解码器会话实例（AVC、HEVC、VP9* 或更高版本），以便在 720p 分辨率@30 fps 下并发运行任何编解码器组合。*如果存在 VP9 编解码器，则仅需 2 个实例。
  • [5.1/H-1-3] 必须通过 CodecCapabilities.getMaxSupportedInstances() 和 VideoCapabilities.getSupportedPerformancePoints() 方法，通告可在任何编解码器组合中并发运行的最大硬件视频编码器会话数。
  • [5.1/H-1-4] 必须支持 6 个硬件视频编码器会话实例（AVC、HEVC、VP9* 或更高版本），以便在 720p 分辨率@30fps 下并发运行任何编解码器组合。*如果存在 VP9 编解码器，则仅需 2 个实例。
  • [5.1/H-1-5] 必须通过 CodecCapabilities.getMaxSupportedInstances() 和 VideoCapabilities.getSupportedPerformancePoints() 方法，通告可在任何编解码器组合中并发运行的最大硬件视频编码器和解码器会话数。
  • [5.1/H-1-6] 必须支持 6 个硬件视频解码器和硬件视频编码器会话实例（AVC、HEVC、VP9* 或更高版本），以便在 720p@30fps 分辨率下并发运行任何编解码器组合。*如果存在 VP9 编解码器，则仅需 2 个实例。
  • [5.1/H-1-7] 对于所有硬件视频编码器（杜比视界编解码器除外），在负载下，1080p 或更小视频编码会话的编解码器初始化延迟必须为 50 毫秒或更短。此处的负载定义为使用硬件视频编解码器的并发 1080p 到 720p 纯视频转码会话，以及 1080p 音视频录制初始化。
  • [5.1/H-1-8] 对于所有音频编码器，在负载下，128 kbps 或更低比特率音频编码会话的编解码器初始化延迟必须为 40 毫秒或更短。此处的负载定义为使用硬件视频编解码器的并发 1080p 到 720p 纯视频转码会话，以及 1080p 音视频录制初始化。
  • [5.3/H-1-1] 对于 1080p 60 fps 视频会话，在负载下，不得丢帧超过 10 秒内 2 帧（即丢帧率低于 0.333%）。负载定义为使用硬件视频编解码器的并发 1080p 到 720p 纯视频转码会话，以及 128 kbps AAC 音频播放。
  • [5.3/H-1-2] 在负载下，60 fps 视频会话中视频分辨率更改期间，不得丢帧超过 10 秒内 2 帧。负载定义为使用硬件视频编解码器的并发 1080p 到 720p 纯视频转码会话，以及 128 kbps AAC 音频播放。
  • [5.6/H-1-1] 使用 OboeTester 点击到音调测试或 CTS Verifier 点击到音调测试时，点击到音调的延迟必须小于 100 毫秒。

2.2.7.2. 摄像头

如果手持设备实现方案为 android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS 返回 android.os.Build.VERSION_CODES.R，则它们

  • 必须满足 android 11 CDD 2.2.7.2 节中列出的摄像头要求

如果手持设备实现方案为 android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS 返回 android.os.Build.VERSION_CODES.S，则它们

  • [7.5/H-1-1] 必须具有一个主后置摄像头，分辨率至少为 1200 万像素，支持以 4k@30fps 拍摄视频。主后置摄像头是摄像头 ID 最低的后置摄像头。
  • [7.5/H-1-2] 必须具有一个主前置摄像头，分辨率至少为 500 万像素，并支持以 1080p@30fps 拍摄视频。主前置摄像头是摄像头 ID 最低的前置摄像头。
  • [7.5/H-1-3] 对于后置主摄像头，必须支持 android.info.supportedHardwareLevel 属性为 FULL 或更高，对于前置主摄像头，则为 LIMITED 或更高。
  • [7.5/H-1-4] 对于前后主摄像头，必须支持 CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME。
  • [7.5/H-1-5] 主摄像头必须在 ITS 照明条件 (3000K) 下，通过 CTS 摄像头 PerformanceTest 测得，针对 1080p 分辨率，相机 2 JPEG 拍摄延迟 < 1000 毫秒。
  • [7.5/H-1-6] 主摄像头必须在 ITS 照明条件 (3000K) 下，通过 CTS 摄像头 PerformanceTest 测得，相机 2 启动延迟（打开相机到第一帧预览帧）< 600 毫秒。
  • [7.5/H-1-8] 主后置摄像头必须支持 CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW 和 android.graphics.ImageFormat.RAW_SENSOR。

2.2.7.3. 硬件

如果手持设备实现方案为 android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS 返回 android.os.Build.VERSION_CODES.R，则它们

如果手持设备实现方案为 android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS 返回 android.os.Build.VERSION_CODES.S，则它们

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

2.2.7.4. 性能

如果手持设备实现方案为 android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS 返回 android.os.Build.VERSION_CODES.R，则它们

如果手持设备实现方案为 android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS 返回 android.os.Build.VERSION_CODES.S，则它们

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

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] 必须提供主屏幕和返回功能。
  • [7.2.3/T-0-2] 必须将返回功能的正常和长按事件 (KEYCODE_BACK) 发送到前台应用。
  • [7.2.6.1/T-0-1] 必须包括对游戏控制器的支持，并声明 android.hardware.gamepad 功能标记。
  • [7.2.7/T] 应该提供一个遥控器，用户可以通过该遥控器访问 非触摸导航 和 核心导航键 输入。

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

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

电视设备实现

  • [7.4.3/T-0-1] 必须支持蓝牙和低功耗蓝牙 (Bluetooth 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-1] 强烈建议支持以每秒 30 帧的速度对 720p 和 1080p 分辨率视频进行 H.264 编码。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

电视设备实现

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

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

  • [5.8/T-0-1] 必须设置 HDMI 输出模式，以选择可以支持的最大分辨率，刷新率为 50Hz 或 60Hz。
  • [5.8/T-SR-1] 强烈建议提供用户可配置的 HDMI 刷新率选择器。
  • [5.8] 应该根据设备销售区域的视频刷新率，将 HDMI 输出模式刷新率设置为 50Hz 或 60Hz。

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

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

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

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

2.3.3. 软件

电视设备实现

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

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

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

电视设备实现

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

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

  • [3.11/T-SR-1] 强烈建议包括支持设备上可用语言的 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-3] 必须提供用户界面来显示所有免于应用待机和 Doze 省电模式的应用。

电视设备实现

  • [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 Keystore 系统支持的算法。安全隔离必须阻止内核或用户空间代码可能访问隔离环境内部状态的所有潜在机制，包括 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 个单元可以使用不同的密钥。
  • [9/T-0-1] 必须声明 “android.hardware.security.model.compatible” 功能。

请注意，如果设备实现方案已在较早的 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 实现的控件保持一致，以启用/停用其他用户访问语音通话和短信。

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

  • [9.8.2/T-4-1] 当应用正在访问麦克风中的音频数据时，必须显示麦克风指示器，但 HotwordDetectionService、SOURCE_HOTWORD、ContentCaptureService 或在第 9.1 节“权限”中带有 CDD 标识符 C-3-X] 中提及的角色的应用仅访问麦克风时除外。
  • [9.8.2/T-4-2] 对于具有可见用户界面或直接用户交互的系统应用，不得隐藏麦克风指示器。

如果电视设备实现声明 android.hardware.camera.any，则它们

  • [9.8.2/T-5-1] 当应用正在访问实时摄像头数据时，必须显示摄像头指示器，但持有第 9.1 节“权限”中带有 CDD 标识符 [C-3-X] 的角色应用仅访问摄像头时除外。
  • [9.8.2/T-5-2] 对于具有可见用户界面或直接用户交互的系统应用，不得隐藏摄像头指示器。

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

电视设备实现

  • 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-1] 强烈建议包括 3 轴加速度计。

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

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

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

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

手表设备实现

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

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

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

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

  • [7.8.2/W] 可以具有音频输出。

2.4.2. 多媒体

无其他要求。

2.4.3. 软件

手表设备实现

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

手表设备实现

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

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

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

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

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

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

2.4.4. 性能和功耗

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

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

手表设备实现

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

2.4.5. 安全模型

手表设备实现

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

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

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

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

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

2.5. 汽车要求

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

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

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

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

2.5.1. 硬件

汽车设备实现

如果汽车设备实现支持 OpenGL ES 3.1，则它们

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

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

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

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

如果 Automotive 设备实现包含 GPS/GNSS 接收器，但不包含基于蜂窝网络的数据连接，则它们

  • [7.3.3/A-3-1] 必须在首次开启 GPS/GNSS 接收器时或在 4 天以上后 60 秒内确定位置。
  • [7.3.3/A-3-2] 必须满足 7.3.3/C-1-2 和 7.3.3/C-1-6 中描述的首次定位时间标准，适用于所有其他位置请求（即非首次或 4 天以上后的请求）。在不具备基于蜂窝网络的数据连接的车辆中，通常通过以下方式满足 7.3.3/C-1-2 的要求：使用接收器上计算的 GNSS 轨道预测，或使用上次已知的车辆位置以及至少 60 秒的航位推算能力，且位置精度满足 7.3.3/C-1-3，或两者结合使用。

汽车设备实现

  • [7.4.3/A-0-1] 必须支持 Bluetooth，并且应该支持 Bluetooth LE。
  • [7.4.3/A-0-2] Android Automotive 实现必须支持以下 Bluetooth 配置文件
    • 通过 Hands-Free Profile (HFP) 进行电话呼叫。
    • 通过 Audio Distribution Profile (A2DP) 进行媒体播放。
    • 通过 Remote Control Profile (AVRCP) 进行媒体播放控制。
    • 使用 Phone Book Access Profile (PBAP) 进行联系人共享。

  • [7.4.3/A-SR-1] 强烈建议支持 Message Access Profile (MAP)。

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

  • [7.4.5/A] 可以使用 System API NetworkCapabilities#NET_CAPABILITY_OEM_PAID 常量来表示应向系统应用提供的网络。

外部视图摄像头是一种拍摄设备实现外部场景的摄像头，例如行车记录仪。

汽车设备实现

  • 应该包含一个或多个外部视图摄像头。

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

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

汽车设备实现

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

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

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

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

如果 Automotive 设备实现是 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 或更高

如果 Automotive 设备实现是 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. 多媒体

Automotive 设备实现必须支持以下音频编码和解码格式，并向第三方应用程序提供这些格式

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

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

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

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

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

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

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

2.5.3. 软件

汽车设备实现

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

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

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

如果 Automotive 设备实现使用 android.car.CarPropertyManager 和 android.car.VehiclePropertyIds 提供专有 API，则它们

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

汽车设备实现

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

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

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

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

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

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

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

汽车设备实现

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

汽车设备实现

如果 Automotive 设备实现包含默认启动器应用程序，则它们

汽车设备实现

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

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] 除非发生以下情况，否则每次驾驶后应该处于车库模式至少 15 分钟
    • 电池耗尽。
    • 未安排空闲作业。
    • 驾驶员退出车库模式。
  • [8.4/A-0-1] 必须提供每个组件的功耗配置文件，该文件定义了每个硬件组件的 电流消耗值 以及 Android 开源项目站点中记录的组件随时间推移引起的大致电池消耗。
  • [8.4/A-0-2] 必须以毫安时 (mAh) 为单位报告所有功耗值。
  • [8.4/A-0-3] 必须报告每个进程 UID 的 CPU 功耗。Android 开源项目通过 uid_cputime 内核模块实现满足此要求。
  • [8.4/A] 如果无法将硬件组件功耗归因于应用程序，则应该将其归因于硬件组件本身。
  • [8.4/A-0-4] 必须通过 adb shell dumpsys batterystats shell 命令向应用程序开发者提供此功耗信息。

2.5.5. 安全模型

如果 Automotive 设备实现支持多用户，则它们

汽车设备实现

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

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

汽车设备实现

  • [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 二进制文件必须接受符合 perfetto 文档中定义的 schema 的 protobuf 配置作为输入。
    • [6.1/A-0-3] perfetto 二进制文件必须输出符合 perfetto 文档中定义的 schema 的 protobuf 跟踪。
    • [6.1/A-0-4] 必须通过 perfetto 二进制文件提供至少 perfetto 文档中描述的数据源。

2.6. 平板电脑要求

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

  • 用双手握持使用。
  • 不具有翻盖或可转换配置。
  • 与设备一起使用的物理键盘实现通过标准连接（例如 USB、Bluetooth）连接。
  • 具有提供移动性的电源，例如电池。
  • 屏幕显示尺寸大于 7 英寸且小于 18 英寸，对角线测量。

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

2.6.1. 硬件

陀螺仪

如果平板电脑设备实现包含 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 控制实现保持一致，以启用/禁用其他用户访问语音通话和短信。

2.6.2. 软件

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

3. 软件

3.1. 托管 API 兼容性

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

设备实现

  • [C-0-1] 必须提供 Android SDK 或上游 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] 必须随附每个非 SDK 接口，这些接口与 AOSP 中相应 API 级别分支的 prebuilts/runtime/appcompat/hiddenapi-flags.csv 路径中通过 provisional 和 denylist 标志提供的受限列表位于相同的受限列表上。

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

    但是它们

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

3.1.1. Android 扩展

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

Android 设备实现

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

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

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

3.1.2. Android 库

由于 Apache HTTP 客户端弃用，设备实现

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

AOSP 实现满足这些要求。

3.2. 软 API 兼容性

除了 第 3.1 节中的托管 API 之外，Android 还包括重要的运行时“软”API，其形式为 intent、权限以及 Android 应用程序的类似方面，这些方面无法在应用程序编译时强制执行。

3.2.1. 权限

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

3.2.2. 构建参数

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

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

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

例如

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

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

3.2.3. Intent 兼容性

3.2.3.1. 常用应用程序 Intent

Android Intent 允许应用程序组件从其他 Android 组件请求功能。Android 上游项目包含一个应用程序列表，这些应用程序实现了几种 Intent 模式来执行常用操作。

设备实现

  • [C-SR-1] 强烈建议 (STRONGLY RECOMMENDED) 预加载一个或多个具有 Intent 处理程序的应用程序或服务组件，用于此处 here 列出的所有公共 Intent 过滤器模式，并提供 SDK 中描述的这些常用应用程序 Intent 的实现，即满足开发人员的期望。

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

3.2.3.2. Intent 解析

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

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

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

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

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

  • [C-0-4] MUST 尝试通过执行上游 Android 开源项目中软件包管理器实现的 数字资产链接规范 中定义的验证步骤来验证任何 Intent 过滤器。
  • [C-0-5] MUST 尝试在安装应用程序期间验证 Intent 过滤器，并将所有成功验证的 URI Intent 过滤器设置为其 URI 的默认应用程序处理程序。
  • MAY 可以将特定的 URI Intent 过滤器设置为其 URI 的默认应用程序处理程序，如果它们已成功验证，但其他候选 URI 过滤器验证失败。如果设备实现执行此操作，则 MUST 在设置菜单中为用户提供适当的按 URI 模式覆盖。
  • MUST 在“设置”中为用户提供每个应用程序的应用链接控件，如下所示
    • [C-0-6] 用户 MUST 能够全面覆盖应用程序的默认应用链接行为，使其为：始终打开、始终询问或从不打开，这必须平等地应用于所有候选 URI Intent 过滤器。
    • [C-0-7] 用户 MUST 能够看到候选 URI Intent 过滤器的列表。
    • 设备实现 MAY 可以为用户提供在每个 Intent 过滤器的基础上覆盖已成功验证的特定候选 URI Intent 过滤器的能力。
    • [C-0-8] 如果设备实现允许某些候选 URI Intent 过滤器验证成功，而其他候选 URI Intent 过滤器验证失败，则设备实现 MUST 为用户提供查看和覆盖特定候选 URI Intent 过滤器的能力。
3.2.3.3. Intent 命名空间
  • [C-0-1] 设备实现 MUST 不得包含任何 Android 组件，该组件使用 android.* 或 com.android.* 命名空间中的 ACTION、CATEGORY 或其他键字符串来处理任何新的 Intent 或广播 Intent 模式。
  • [C-0-2] 设备实现者 MUST 不得包含任何 Android 组件，该组件使用属于另一个组织的包空间中的 ACTION、CATEGORY 或其他键字符串来处理任何新的 Intent 或广播 Intent 模式。
  • [C-0-3] 设备实现者 MUST 不得更改或扩展 第 3.2.3.1 节 中列出的任何 Intent 模式。
  • 设备实现 MAY 可以包含使用与其自身组织明确且明显关联的命名空间的 Intent 模式。此禁令类似于 第 3.6 节 中为 Java 语言类指定的禁令。
3.2.3.4. 广播 Intent

第三方应用程序依赖于平台广播某些 Intent 以通知它们硬件或软件环境的变化。

设备实现

  • [C-0-1] MUST 广播此处 here 列出的公共广播 Intent，以响应 SDK 文档中描述的适当系统事件。请注意，此要求与第 3.5 节不冲突，因为 SDK 文档中也描述了后台应用程序的限制。此外，某些广播 Intent 取决于硬件支持，如果设备支持必要的硬件，则它们 MUST 广播 Intent 并提供与 SDK 文档一致的行为。
3.2.3.5. 条件应用程序 Intent

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

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

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

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

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

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

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

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

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

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

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

  • [C-8-1] MUST 处理 android.settings.ACCESSIBILITY_SETTINGS Intent，以提供一种用户可访问的机制，以启用和禁用第三方辅助功能服务以及预加载的辅助功能服务。

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

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

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

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

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

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

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

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

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

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

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

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

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

  • [C-SR-3] 强烈建议 (STRONGLY RECOMMENDED) 处理 android.intent.action.TTS_SERVICE、android.speech.tts.engine.INSTALL_TTS_DATA 和 android.speech.tts.engine.GET_SAMPLE_TEXT Intent，并具有一个活动来为 SDK 此处描述的这些 Intent 提供实现。

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

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

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

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

  • [C-1-1] MUST 设置 android.software.activities_on_secondary_displays 功能标志。
  • [C-1-2] MUST 保证与在主显示器上运行的活动类似的 API 兼容性。
  • [C-1-3] MUST 在未通过 ActivityOptions.setLaunchDisplayId() API 指定目标显示器的情况下启动新活动时，将新活动放置在与启动它的活动相同的显示器上。
  • [C-1-4] MUST 在删除具有 Display.FLAG_PRIVATE 标志的显示器时，销毁所有活动。
  • [C-1-5] MUST 在设备使用安全锁屏锁定时，安全地隐藏所有屏幕上的内容，除非应用程序选择使用 Activity#setShowWhenLocked() API 在锁屏顶部显示。
  • SHOULD 应具有 android.content.res.Configuration，该配置与该显示器相对应，以便在二级显示器上启动活动时，能够正确显示、正常运行并保持兼容性。

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

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

3.3. Native API 兼容性

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

  • [C-SR-1] 强烈建议 (STRONGLY RECOMMENDED) 使用来自上游 Android 开源项目的以下库的实现。

3.3.1. 应用程序二进制接口

托管的 Dalvik 字节码可以调用应用程序 .apk 文件中提供的本机代码，作为为适当的设备硬件架构编译的 ELF .so 文件。由于本机代码高度依赖于底层处理器技术，因此 Android 在 Android NDK 中定义了许多应用程序二进制接口 (ABI)。

设备实现

  • [C-0-1] MUST 与一个或多个定义的 Android NDK ABI 兼容。
  • [C-0-2] MUST 包括对在托管环境中运行的代码的支持，以使用标准 Java 本机接口 (JNI) 语义调用本机代码。
  • [C-0-3] 对于下面列表中的每个必需库，MUST 在源兼容性（即标头兼容性）和二进制兼容性（对于 ABI）方面保持兼容。
  • [C-0-5] MUST 通过 android.os.Build.SUPPORTED_ABIS、android.os.Build.SUPPORTED_32_BIT_ABIS 和 android.os.Build.SUPPORTED_64_BIT_ABIS 参数准确报告设备支持的本机应用程序二进制接口 (ABI)，每个参数都是以逗号分隔的 ABI 列表，从最优先到最不优先排序。

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

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

    • libaaudio.so（AAudio 本机音频支持）
    • libamidi.so（本机 MIDI 支持，如果声明了功能 android.software.midi，如第 5.9 节所述）
    • 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] MUST 不得添加或删除上述本机库的公共函数。

  • [C-0-9] MUST 在 /vendor/etc/public.libraries.txt 中列出直接向第三方应用程序公开的其他非 AOSP 库。

  • [C-0-10] MUST 不得向以 API 级别 24 或更高版本为目标的第三方应用程序公开 AOSP 中实现和提供的任何其他本机库，因为它们是保留的。

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

  • [C-0-12] MUST 通过 libvulkan.so 库导出核心 Vulkan 1.0 函数符号，以及 VK_KHR_surface、VK_KHR_android_surface、VK_KHR_swapchain、VK_KHR_maintenance1 和 VK_KHR_get_physical_device_properties2 扩展。请注意，虽然所有符号 MUST 都必须存在，但第 7.1.4.2 节更详细地描述了何时期望每个相应函数的完整实现的要求。

  • SHOULD 应使用上游 Android 开源项目中提供的源代码和头文件构建

请注意，未来版本的 Android 可能会引入对其他 ABI 的支持。

3.3.2. 32 位 ARM 本机代码兼容性

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

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

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

  • [C-2-1] MUST 在 /proc/cpuinfo 中包含以下行，并且即使它们被其他 ABI 读取，SHOULD 也不应更改同一设备上的值。

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

  • [C-2-2] MUST 始终保持以下操作可用，即使在 ARMv8 架构上实现 ABI 的情况下，也要通过本机 CPU 支持或通过软件模拟来实现

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

  • [C-2-3] MUST 包括对 高级 SIMD（又名 NEON）扩展的支持。

3.4. Web 兼容性

3.4.1. WebView 兼容性

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

  • [C-1-1] MUST 报告 android.software.webview。
  • [C-1-2] MUST 使用来自 Android 12 分支上上游 Android 开源项目的 Chromium 项目构建，以实现 android.webkit.WebView API。

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

    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

    • The value of the $(VERSION) string MUST be the same as the value for android.os.Build.VERSION.RELEASE。
    • The $(MODEL) string MAY be empty, but if it is not empty it MUST have the same value as android.os.Build.MODEL。
    • "Build/$(BUILD)" MAY be omitted, but if it is present the $(BUILD) string MUST be the same as the value for android.os.Build.ID。
    • The value of the $(CHROMIUM_VER) string MUST be the version of Chromium in the upstream Android Open Source Project。
    • Device implementations MAY omit Mobile in the user agent string。

  • The WebView component SHOULD include support for as many HTML5 features as possible and if it supports the feature SHOULD conform to the HTML5 specification。

  • [C-1-4] MUST render the provided content or remote URL content in a process that is distinct from the application that instantiates the WebView. Specifically the separate renderer process MUST hold lower privilege, run as a separate user ID, have no access to the app's data directory, have no direct network access, and only have access to the minimum-required system services over Binder. The AOSP implementation of WebView meets this requirement。

Note that if device implementations are 32-bit or declare the feature flag android.hardware.ram.low, they are exempted from C-1-3。

3.4.2. Browser Compatibility

If device implementations include a standalone Browser application for general web browsing, they

  • [C-1-1] MUST support each of these APIs associated with HTML5
  • [C-1-2] MUST support the HTML5/W3C webstorage API and SHOULD support the HTML5/W3C IndexedDB API. Note that as the web development standards bodies are transitioning to favor IndexedDB over webstorage, IndexedDB is expected to become a required component in a future version of Android。
  • MAY ship a custom user agent string in the standalone Browser application。
  • SHOULD implement support for as much of HTML5 as possible on the standalone Browser application (whether based on the upstream WebKit Browser application or a third-party replacement)。

However, If device implementations do not include a standalone Browser application, they

  • [C-2-1] MUST still support the public intent patterns as described in section 3.2.3.1。

3.5. API Behavioral Compatibility

设备实现

  • [C-0-9] MUST ensure that API behavioral compatibility is applied for all installed apps unless they are restricted as described in Section 3.5.1。
  • [C-0-10] MUST NOT implement the allowlisting approach that ensures API behavioral compatibility only for apps that are selected by device implementers。

The behaviors of each of the API types (managed, soft, native, and web) must be consistent with the preferred implementation of the upstream Android Open Source Project. Some specific areas of compatibility are

  • [C-0-1] Devices MUST NOT change the behavior or semantics of a standard intent。
  • [C-0-2] Devices MUST NOT alter the lifecycle or lifecycle semantics of a particular type of system component (such as Service, Activity, ContentProvider, etc.)。
  • [C-0-3] Devices MUST NOT change the semantics of a standard permission。
  • Devices MUST NOT alter the limitations enforced on background applications. More specifically, for background apps
    • [C-0-4] they MUST stop executing callbacks that are registered by the app to receive outputs from the GnssMeasurement and GnssNavigationMessage。
    • [C-0-5] they MUST rate-limit the frequency of updates that are provided to the app through the LocationManager API class or the WifiManager.startScan() method。
    • [C-0-6] if the app is targeting API level 25 or higher, they MUST NOT allow to register broadcast receivers for the implicit broadcasts of standard Android intents in the app's manifest, unless the broadcast intent requires a "signature" or "signatureOrSystem" protectionLevel permission or are on the exemption list。
    • [C-0-7] if the app is targeting API level 25 or higher, they MUST stop the app's background services, just as if the app had called the services'stopSelf() method, unless the app is placed on a temporary allowlist to handle a task that's visible to the user。
    • [C-0-8] if the app is targeting API level 25 or higher, they MUST release the wakelocks the app holds。
  • [C-0-11] Devices MUST return the following security providers as the first seven array values from the Security.getProviders() method, in the given order and with the given names (as returned by Provider.getName()) and classes, unless the app has modified the list via insertProviderAt() or removeProvider(). Devices MAY return additional providers after the specified list of providers below。
    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

The above list is not comprehensive. The Compatibility Test Suite (CTS) tests significant portions of the platform for behavioral compatibility, but not all. It is the responsibility of the implementer to ensure behavioral compatibility with the Android Open Source Project. For this reason, device implementers SHOULD use the source code available via the Android Open Source Project where possible, rather than re-implement significant parts of the system。

3.5.1. Application Restriction

If device implementations implement a proprietary mechanism to restrict apps and that mechanism is more restrictive than the Restricted App Standby Bucket, they

  • [C-1-1] MUST provide user affordance where the user can see the list of restricted apps。
  • [C-1-2] MUST provide user affordance to turn on / off the restrictions on each app。
  • [C-1-3] MUST not automatically apply restrictions without evidence of poor system health behavior, but MAY apply the restrictions on apps upon detection of poor system health behavior like stuck wakelocks, long running services, and other criteria. The criteria MAY be determined by device implementers but MUST be related to the app’s impact on the system health. Other criteria that are not purely related to the system health, such as the app’s lack of popularity in the market, MUST NOT be used as criteria。
  • [C-1-4] MUST not automatically apply app restrictions for apps when a user has turned off app restrictions manually, and MAY suggest the user to apply app restrictions。
  • [C-1-5] MUST inform users if app restrictions are applied to an app automatically. Such information MUST be provided within 24 hours of when the restrictions are applied。
  • [C-1-6] MUST return true for ActivityManager.isBackgroundRestricted() when the restricted app calls this API。
  • [C-1-7] MUST NOT restrict the top foreground app that is explicitly used by the user。
  • [C-1-8] MUST suspend restrictions on an app that becomes the top foreground application when the user explicitly starts to use the app that used to be restricted。
  • [C-1-10] MUST NOT allow an app to be automatically placed in the RESTRICTED bucket within 2 hours of the most recent usage by a user。

If device implementations extend the app restrictions that are implemented in AOSP, they

  • [C-2-1] MUST follow the implementation described in this document。

3.5.2. Application Hibernation

If device implementations include App Hibernation that is included in AOSP or extends the feature that is included in AOSP, then they

  • [C-1-1] MUST meet all the requirements in section 3.5.1 except for [C-1-6] and [C-1-3]。
  • [C-1-2] MUST only apply the restriction on the app for a user when there is evidence that the user has not used the app for some period of time. This duration is STRONGLY RECOMMENDED to be one month or longer. Usage MUST be defined by either explicit user interaction via the UsageStats#getLastTimeVisible() API or anything that would cause an app to leave the force-stopped state, including service bindings, content provider bindings, explicit broadcasts, etc., which will be tracked by a new API UsageStats#getLastTimeAnyComponentUsed()。
  • [C-1-3] MUST only apply restrictions affecting all device users when there is evidence that the package has not been used by ANY user for some period of time. This duration is STRONGLY RECOMMENDED to be one month or longer。
  • [C-1-4] MUST NOT render the app unable to respond to activity intents, service bindings, content provider requests, or explicit broadcasts。

App Hibernation in AOSP meets the above requirements。

3.6. API Namespaces

Android follows the package and class namespace conventions defined by the Java programming language. To ensure compatibility with third-party applications, device implementers MUST NOT make any prohibited modifications (see below) to these package namespaces

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

That is, they

  • [C-0-1] MUST NOT modify the publicly exposed APIs on the Android platform by changing any method or class signatures, or by removing classes or class fields。
  • [C-0-2] MUST NOT add any publicly exposed elements (such as classes or interfaces, or fields or methods to existing classes or interfaces) or Test or System APIs to the APIs in the above namespaces. A "publicly exposed element" is any construct that is not decorated with the "@hide" marker as used in the upstream Android source code。

Device implementers MAY modify the underlying implementation of the APIs, but such modifications

  • [C-0-3] MUST NOT impact the stated behavior and Java-language signature of any publicly exposed APIs。
  • [C-0-4] MUST NOT be advertised or otherwise exposed to developers。

However, device implementers MAY add custom APIs outside the standard Android namespace, but the custom APIs

  • [C-0-5] MUST NOT be in a namespace owned by or referring to another organization. For instance, device implementers MUST NOT add APIs to the com.google.* or similar namespace: only Google may do so. Similarly, Google MUST NOT add APIs to other companies' namespaces。
  • [C-0-6] MUST be packaged in an Android shared library so that only apps that explicitly use them (via the <uses-library> mechanism) are affected by the increased memory usage of such APIs。

Device implementers MAY add custom APIs in native languages, outside of the NDK APIs, but the custom APIs

  • [C-1-1] MUST NOT be in a NDK library or a library owned by another organization as described here。

If a device implementer proposes to improve one of the package namespaces above (such as by adding useful new functionality to an existing API, or adding a new API), the implementer SHOULD visit source.android.com and begin the process for contributing changes and code, according to the information on that site。

Note that the restrictions above correspond to standard conventions for naming APIs in the Java programming language; this section simply aims to reinforce those conventions and make them binding through inclusion in this Compatibility Definition。

3.7. Runtime Compatibility

设备实现

  • [C-0-1] MUST support the full Dalvik Executable (DEX) format and Dalvik bytecode specification and semantics。

  • [C-0-2] MUST configure Dalvik runtimes to allocate memory in accordance with the upstream Android platform, and as specified by the following table. (See section 7.1.1 for screen size and screen density definitions.)

  • SHOULD use Android RunTime (ART), the reference upstream implementation of the Dalvik Executable Format, and the reference implementation's package management system。

  • SHOULD run fuzz tests under various modes of execution and target architectures to assure the stability of the runtime. Refer to JFuzz and DexFuzz in the Android Open Source Project website。

Note that memory values specified below are considered minimum values and device implementations MAY allocate more memory per application。

Screen Layout Screen Density Minimum Application Memory
Android Watch 120 dpi (ldpi) 32MB
140 dpi (140dpi)
160 dpi (mdpi)
180 dpi (180dpi)
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi) 36MB
240 dpi (hdpi)
280 dpi (280dpi)
320 dpi (xhdpi) 48MB
360 dpi (360dpi)
400 dpi (400dpi) 56MB
420 dpi (420dpi) 64MB
480 dpi (xxhdpi) 88MB
560 dpi (560dpi) 112MB
640 dpi (xxxhdpi) 154MB
small/normal 120 dpi (ldpi) 32MB
140 dpi (140dpi)
160 dpi (mdpi)
180 dpi (180dpi) 48MB
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi)
240 dpi (hdpi)
280 dpi (280dpi)
320 dpi (xhdpi) 80MB
360 dpi (360dpi)
400 dpi (400dpi) 96MB
420 dpi (420dpi) 112MB
480 dpi (xxhdpi) 128MB
560 dpi (560dpi) 192MB
640 dpi (xxxhdpi) 256MB
large 120 dpi (ldpi) 32MB
140 dpi (140dpi) 48MB
160 dpi (mdpi)
180 dpi (180dpi) 80MB
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi)
240 dpi (hdpi)
280 dpi (280dpi) 96MB
320 dpi (xhdpi) 128MB
360 dpi (360dpi) 160MB
400 dpi (400dpi) 192MB
420 dpi (420dpi) 228MB
480 dpi (xxhdpi) 256MB
560 dpi (560dpi) 384MB
640 dpi (xxxhdpi) 512MB
xlarge 120 dpi (ldpi) 48MB
140 dpi (140dpi) 80MB
160 dpi (mdpi)
180 dpi (180dpi) 96MB
200 dpi (200dpi)
213 dpi (tvdpi)
220 dpi (220dpi)
240 dpi (hdpi)
280 dpi (280dpi) 144MB
320 dpi (xhdpi) 192MB
360 dpi (360dpi) 240MB
400 dpi (400dpi) 288MB
420 dpi (420dpi) 336MB
480 dpi (xxhdpi) 384MB
560 dpi (560dpi) 576MB
640 dpi (xxxhdpi) 768MB

3.8. User Interface Compatibility

3.8.1. Launcher (Home Screen)

Android includes a launcher application (home screen) and support for third-party applications to replace the device launcher (home screen)。

If device implementations allow third-party applications to replace the device home screen, they

  • [C-1-1] MUST declare the platform feature android.software.home_screen。
  • [C-1-2] MUST return the AdaptiveIconDrawable object when the third-party application use <adaptive-icon> tag to provide their icon, and the PackageManager methods to retrieve icons are called。

If device implementations include a default launcher that supports in-app pinning of shortcuts, they

Conversely, if device implementations do not support in-app pinning of shortcuts, they

If device implementations implement a default launcher that provides quick access to the additional shortcuts provided by third-party apps through the ShortcutManager API, they

  • [C-4-1] MUST support all documented shortcut features (e.g. static and dynamic shortcuts, pinning shortcuts) and fully implement the APIs of the ShortcutManager API class。

If device implementations include a default launcher app that shows badges for the app icons, they

  • [C-5-1] MUST respect the NotificationChannel.setShowBadge() API method. In other words, show a visual affordance associated with the app icon if the value is set as true, and do not show any app icon badging scheme when all of the app's notification channels have set the value as false。
  • MAY override the app icon badges with their proprietary badging scheme when third-party applications indicate support of the proprietary badging scheme through the use of proprietary APIs, but SHOULD use the resources and values provided through the notification badges APIs described in the SDK, such as the Notification.Builder.setNumber() and the Notification.Builder.setBadgeIconType() API。

3.8.2. Widgets

Android supports third-party app widgets by defining a component type and corresponding API and lifecycle that allows applications to expose an “AppWidget” to the end user。

If device implementations support third-party app widgets, they

  • [C-1-1] MUST declare support for platform feature android.software.app_widgets。
  • [C-1-2] MUST include built-in support for AppWidgets and expose user interface affordances to add, configure, view, and remove AppWidgets directly within the Launcher。
  • [C-1-3] MUST be capable of rendering widgets that are 4 x 4 in the standard grid size. See the App Widget DesignGuidelines in the Android SDK documentation for details。
  • MAY support application widgets on the lock screen。

If device implementations support third-party app widgets and in-app pinning of shortcuts, they

3.8.3. Notifications

Android includes Notification and NotificationManager APIs that allow third-party app developers to notify users of notable events and attract users' attention using the hardware components (e.g. sound, vibration and light) and software features (e.g. notification shade, system bar) of the device。

3.8.3.1. Presentation of Notifications

If device implementations allow third-party apps to notify users of notable events, they

  • [C-1-1] MUST support notifications that use hardware features, as described in the SDK documentation, and to the extent possible with the device implementation hardware. For instance, if a device implementation includes a vibrator, it MUST correctly implement the vibration APIs. If a device implementation lacks hardware, the corresponding APIs MUST be implemented as no-ops. This behavior is further detailed in section 7。
  • [C-1-2] MUST correctly render all resources (icons, animation files, etc.) provided for in the APIs, or in the Status/System Bar icon style guide, although they MAY provide an alternative user experience for notifications than that provided by the reference Android Open Source implementation。
  • [C-1-3] MUST honor and implement properly the behaviors described for the APIs to update, remove and group notifications。
  • [C-1-4] MUST provide the full behavior of the NotificationChannel API documented in the SDK。
  • [C-1-5] MUST provide a user affordance to block and modify a certain third-party app's notification per each channel and app package level。
  • [C-1-6] MUST also provide a user affordance to display deleted notification channels。
  • [C-1-7] MUST correctly render all resources (images, stickers, icons, etc.) provided through Notification.MessagingStyle alongside the notification text without additional user interaction. For example, MUST show all resources including icons provided through android.app.Person in a group conversation that is set through setGroupConversation。
  • [C-SR-1] Are STRONGLY RECOMMENDED to automatically surface a user affordance to block a certain third-party app's notification per each channel and app package level after the user dismisses that notification multiple times。
  • [C-SR-2] are STRONGLY RECOMMENDED to provide an affordance for the user to control the notifications that are exposed to apps that have been granted the Notification Listener permission. The granularity MUST be such that the user can control for each such notification listener what notification types are bridged to this listener. The types MUST include "conversations", "alerting", "silent", and "important ongoing" notifications。
  • [C-SR-3] are STRONGLY RECOMMENDED to provide an affordance for users to specify apps to exclude from notifying any specific notification listener。
  • SHOULD support rich notifications。
  • SHOULD present some higher priority notifications as heads-up notifications。
  • SHOULD have a user affordance to snooze notifications。
  • MAY only manage the visibility and timing of when third-party apps can notify users of notable events to mitigate safety issues such as driver distraction。

Android 11 introduces support for conversation notifications, which are notifications that use MessagingStyle and provides a published People Shortcut ID。

设备实现

  • [C-SR-4] Are STRONGLY RECOMMENDED to group and display conversation notifications ahead of non conversation notifications with the exception of ongoing foreground service notifications and importance:high notifications。

If device implementations support conversation notifications and the app provides the required data for bubbles, they

  • [C-SR-5] Are STRONGLY RECOMMENDED to display this conversation as a bubble. The AOSP implementation meets these requirements with the default System UI, Settings, and Launcher。

If device implementations support rich notifications, they

  • [C-2-1] MUST use the exact resources as provided through the Notification.Style API class and its subclasses for the presented resource elements。
  • SHOULD present each and every resource element (e.g. icon, title and summary text) defined in the Notification.Style API class and its subclasses。

If device implementations support heads-up notifications: they

  • [C-3-1] MUST use the heads-up notification view and resources as described in the Notification.Builder API class when heads-up notifications are presented。
  • [C-3-2] MUST display the actions provided through Notification.Builder.addAction() together with the notification content without additional user interaction as described in the SDK。
3.8.3.2. Notification Listener Service

Android includes the NotificationListenerService APIs that allow apps (once explicitly enabled by the user) to receive a copy of all notifications as they are posted or updated。

设备实现

  • [C-0-1] MUST correctly and promptly update notifications in their entirety to all such installed and user-enabled listener services, including any and all metadata attached to the Notification object。
  • [C-0-2] MUST respect the snoozeNotification() API call, and dismiss the notification and make a callback after the snooze duration that is set in the API call。

If device implementations have a user affordance to snooze notifications, they

  • [C-1-1] MUST reflect the snoozed notification status properly through the standard APIs such as NotificationListenerService.getSnoozedNotifications()。
  • [C-1-2] MUST make this user affordance available to snooze notifications from each installed third-party app's, unless they are from persistent/foreground services。
3.8.3.3. DND (Do not Disturb)

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

  • [C-1-1] MUST, for when the device implementation has provided a means for the user to grant or deny third-party apps to access the DND policy configuration, display Automatic DND rules created by applications alongside the user-created and pre-defined rules。
  • [C-1-3] MUST honor the suppressedVisualEffects values passed along the NotificationManager.Policy and if an app has set any of the SUPPRESSED_EFFECT_SCREEN_OFF or SUPPRESSED_EFFECT_SCREEN_ON flags, it SHOULD indicate to the user that the visual effects are suppressed in the DND settings menu。

3.8.4. Assist API's

Android includes the Assist APIs to allow applications to elect how much information of the current context is shared with the assistant on the device。

If device implementations support the Assist action, they

  • [C-2-1] MUST indicate clearly to the end user when the context is shared, by either
    • Each time the assist app accesses the context, displaying a white light around the edges of the screen that meet or exceed the duration and brightness of the Android Open Source Project implementation。
    • For the preinstalled assist app, providing a user affordance less than two navigations away from the default voice input and assistant app settings menu, and only sharing the context when the assist app is explicitly invoked by the user through a hotword or assist navigation key input。
  • [C-2-2] The designated interaction to launch the assist app as described in section 7.2.3 MUST launch the user-selected assist app, in other words the app that implements VoiceInteractionService, or an activity handling the ACTION_ASSIST intent。

3.8.5. Alerts and Toasts

Applications can use the Toast API to display short non-modal strings to the end user that disappear after a brief period of time, and use the TYPE_APPLICATION_OVERLAY window type API to display alert windows as an overlay over other apps。

If device implementations include a screen or video output, they

  • [C-1-1] MUST provide a user affordance to block an app from displaying alert windows that use the TYPE_APPLICATION_OVERLAY . The AOSP implementation meets this requirement by having controls in the notification shade。

  • [C-1-2] MUST honor the Toast API and display Toasts from applications to end users in some highly visible manner。

3.8.6. Themes

Android provides “themes” as a mechanism for applications to apply styles across an entire Activity or application。

Android includes a “Holo” and "Material" theme family as a set of defined styles for application developers to use if they want to match the Holo theme look and feel as defined by the Android SDK。

If device implementations include a screen or video output, they

  • [C-1-1] MUST NOT alter any of the Holo theme attributes exposed to applications。
  • [C-1-2] MUST support the “Material” theme family and MUST NOT alter any of the Material theme attributes or their assets exposed to applications。
  • [C-1-3] MUST either set the "sans-serif" font family to Roboto version 2.x for the languages that Roboto supports, or provide a user affordance to change the font used for the "sans-serif" font family to Roboto version 2.x for the languages that Roboto supports。

Android also includes a “Device Default” theme family as a set of defined styles for application developers to use if they want to match the look and feel of the device theme as defined by the device implementer。

Android supports a variant theme with translucent system bars, which allows application developers to fill the area behind the status and navigation bar with their app content. To enable a consistent developer experience in this configuration, it is important the status bar icon style is maintained across different device implementations。

If device implementations include a system status bar, they

  • [C-2-1] MUST use white for system status icons (such as signal strength and battery level) and notifications issued by the system, unless the icon is indicating a problematic status or an app requests a light status bar using the WindowInsetsController#APPEARANCE_LIGHT_STATUS_BARS flag。
  • [C-2-2] Android device implementations MUST change the color of the system status icons to black (for details, refer to R.style) when an app requests a light status bar。

3.8.7. Live Wallpapers

Android defines a component type and corresponding API and lifecycle that allows applications to expose one or more “Live Wallpapers” to the end user. Live wallpapers are animations, patterns, or similar images with limited input capabilities that display as a wallpaper, behind other applications。

Hardware is considered capable of reliably running live wallpapers if it can run all live wallpapers, with no limitations on functionality, at a reasonable frame rate with no adverse effects on other applications. If limitations in the hardware cause wallpapers and/or applications to crash, malfunction, consume excessive CPU or battery power, or run at unacceptably low frame rates, the hardware is considered incapable of running live wallpaper. As an example, some live wallpapers may use an OpenGL 2.0 or 3.x context to render their content. Live wallpaper will not run reliably on hardware that does not support multiple OpenGL contexts because the live wallpaper use of an OpenGL context may conflict with other applications that also use an OpenGL context。

  • Device implementations capable of running live wallpapers reliably as described above SHOULD implement live wallpapers。

If device implementations implement live wallpapers, they

  • [C-1-1] MUST report the platform feature flag android.software.live_wallpaper。

3.8.8. Activity Switching

The upstream Android source code includes the overview screen, a system-level user interface for task switching and displaying recently accessed activities and tasks using a thumbnail image of the application’s graphical state at the moment the user last left the application。

Device implementations including the recents function navigation key as detailed in section 7.2.3 MAY alter the interface。

If device implementations including the recents function navigation key as detailed in section 7.2.3 alter the interface, they

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

3.8.9. 输入管理

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

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

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

3.8.10. 锁屏媒体控制

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

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

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

3.8.12. 位置信息

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

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

3.8.13. Unicode 和字体

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

If device implementations include a screen or video output, they

  • [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 中的拉丁文、希腊文和西里尔文，包括 Latin Extended A、B、C 和 D 范围，以及 Unicode 7.0 货币符号块中的所有字形。
  • [C-1-3] 不得删除或修改系统映像中的 NotoColorEmoji.tff。（可以添加新的表情符号字体以覆盖 NotoColorEmoji.tff 中的表情符号）
  • 应支持 Unicode 技术报告 #51 中指定的肤色和多元化家庭表情符号。

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

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

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

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

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

3.8.14. 多窗口

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

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

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

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

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

  • [C-3-1] 当应用符合以下条件时，必须在画中画多窗口模式下启动活动：

  • [C-3-2] 必须通过 setActions() API，在其 SystemUI 中公开当前 PIP 活动指定的操作。

  • [C-3-3] 必须支持大于或等于 1:2.39 且小于或等于 2.39:1 的宽高比，由 PIP 活动通过 setAspectRatio() API 指定。

  • [C-3-4] 必须使用 KeyEvent.KEYCODE_WINDOW 来控制 PIP 窗口；如果未实现 PIP 模式，则该键必须可供前台活动使用。

  • [C-3-5] 必须提供用户提示，以阻止应用在 PIP 模式下显示；AOSP 实现通过在通知栏中设置控件来满足此要求。

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

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

3.8.15. 显示屏缺口

Android 支持 SDK 文档中描述的显示屏缺口。DisplayCutout API 定义了显示屏边缘上的一个区域，由于显示屏缺口或边缘的曲面显示，该区域可能无法供应用程序使用。

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

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

3.8.16. 设备控件

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

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

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-5] 如果设备通过功能标志 android.hardware.nfc 声明支持近场通信 (NFC)，并且收到包含 MIME 类型为 MIME_TYPE_PROVISIONING_NFC 的记录的 NFC 消息，则必须将 DPC 应用程序注册为设备所有者应用。
      • [C-1-8] 必须在设备所有者配置触发后发送 ACTION_GET_PROVISIONING_MODE Intent，以便 DPC 应用可以选择成为设备所有者还是个人资料所有者，除非可以从上下文中确定只有一个有效的选项（例如，对于不支持个人资料所有者配置的基于 NFC 的配置）。
      • [C-1-9] 无论使用何种配置方法，如果在配置期间建立了设备所有者，则必须向设备所有者应用发送 ACTION_ADMIN_POLICY_COMPLIANCE Intent。在设备所有者应用完成之前，用户不得在设置向导中继续操作。
    • 当设备实现具有用户数据时，它
      • [C-1-7] 不得再将任何 DPC 应用程序注册为设备所有者应用。
  • [C-1-2] 在配置过程之前或期间，必须要求采取某些肯定性操作，以同意将该应用设置为设备所有者。同意可以通过用户操作或某些编程方式获得，但在启动设备所有者配置之前，必须显示适当的披露通知（如 AOSP 中引用的）。此外，企业用于设备所有者配置的编程设备所有者同意机制不得干扰非企业用途的开箱即用体验。
  • [C-1-3] 不得硬编码同意，也不得阻止使用其他设备所有者应用。

如果设备实现声明了 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，则它们

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-6] 在受管理个人资料存在的情况下，必须在 Intent“选择器”中显示视觉提示，以允许用户在设备策略控制器启用时，将 Intent 从受管理个人资料转发到主用户，反之亦然。
  • [C-1-7] 在受管理个人资料存在的情况下，必须为主要用户和受管理个人资料都公开以下用户提示：
    • 主要用户和受管理个人资料的电池、位置信息、移动数据和存储使用量的单独核算。
    • 主要用户或受管理个人资料中安装的 VPN 应用程序的独立管理。
    • 主要用户或受管理个人资料中安装的应用程序的独立管理。
    • 主要用户或受管理个人资料中的帐户的独立管理。
  • [C-1-8] 如果设备策略控制器允许，则必须确保预装的拨号器、联系人和消息应用程序可以搜索和查找来自受管理个人资料（如果存在）以及来自主要个人资料的来电者信息。
  • [C-1-9] 必须确保它满足适用于启用多用户的设备的所有安全要求（请参阅第 9.5 节），即使受管理个人资料不计为主要用户之外的另一个用户。

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

  • [C-2-1] 必须支持指定单独的锁屏的功能，该锁屏满足以下要求，仅授予对在受管理个人资料中运行的应用的访问权限。
  • 当来自受管理个人资料的联系人显示在预装的通话记录、通话中 UI、进行中和未接来电通知、联系人和消息应用中时，它们应带有与指示受管理个人资料应用程序相同的徽章。

3.9.3 受管理用户支持

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

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

如果设备实现声明了 android.software.device_admin 并提供设备上的用户提示以添加其他辅助用户，则它们

  • [C-SR-1] 强烈建议在允许在新辅助用户中添加帐户之前，显示与 android.app.action.PROVISION_MANAGED_DEVICE 发起的流程中显示的相同的 AOSP 设备所有者同意披露内容，以便用户了解设备是受管理的。

3.10. 无障碍功能

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

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

  • [C-1-1] 必须提供 Android 无障碍功能框架的实现，如 无障碍功能 API SDK 文档中所述。
  • [C-1-2] 必须生成无障碍功能事件，并将适当的 AccessibilityEvent 传递给所有已注册的 AccessibilityService 实现，如 SDK 文档中所述。
  • [C-1-4] 必须提供用户提示来控制声明了 AccessibilityServiceInfo.FLAG_REQUEST_ACCESSIBILITY_BUTTON 的无障碍功能服务。请注意，对于带有系统导航栏的设备实现，它们应允许用户选择在系统的导航栏中设置一个按钮来控制这些服务。

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

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

3.11. 文本转语音

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

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

如果设备实现支持安装第三方 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-1-1] 即时应用只能被授予 android:protectionLevel 设置为 "instant" 的权限。
  • [C-1-2] 即时应用不得通过 隐式 Intent 与已安装的应用交互，除非满足以下条件之一：
    • 组件的 Intent 模式过滤器已公开，并且具有 CATEGORY_BROWSABLE
    • 操作是 ACTION_SEND、ACTION_SENDTO、ACTION_SEND_MULTIPLE 之一
    • 目标通过 android:visibleToInstantApps 显式公开
  • [C-1-3] 除非组件通过 android:visibleToInstantApps 公开，否则即时应用不得与已安装的应用显式交互。
  • [C-1-4] 已安装的应用不得查看设备上有关即时应用的详细信息，除非即时应用显式连接到已安装的应用程序。

  • 设备实现必须提供以下用户提示，用于与即时应用交互。AOSP 通过默认系统 UI、“设置”和启动器满足了这些要求。设备实现

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

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

3.16. 伴侣设备配对

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

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

3.17. 重量级应用

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

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

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

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

3.18. 联系人

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

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

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

自定义本地帐户：一种用于原始联系人的帐户，这些联系人仅存储在设备上，并且不与 AccountManager 中的帐户关联，这些帐户在 ACCOUNT_NAME 和 ACCOUNT_TYPE 列中至少具有一个非空值的情况下创建。

设备实现

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

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

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

4. 应用程序打包兼容性

设备实现

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

设备实现

  • [C-0-2] 必须支持使用 APK 签名方案 v3、APK 签名方案 v2 和 JAR 签名验证 “.apk” 文件。
  • [C-0-3] 不得以阻止这些文件在其他兼容设备上正确安装和运行的方式，扩展 .apk、Android Manifest、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 提供。

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

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

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

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

所有音频编码器必须支持

5.1.2. 音频解码

更多详情请参见 5.1.3. 音频编解码器详情。

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

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

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

  • [C-2-1] 解码必须在不进行下混的情况下执行（例如，5.0 AAC 流必须解码为五个声道的 PCM，5.1 AAC 流必须解码为六个声道的 PCM）。
  • [C-2-2] 动态范围元数据必须按照 ISO/IEC 14496-3 中的“动态范围控制 (DRC)”定义，并且 android.media.MediaFormat DRC 键用于配置音频解码器的动态范围相关行为。AAC DRC 键在 API 21 中引入，包括：KEY_AAC_DRC_ATTENUATION_FACTOR、KEY_AAC_DRC_BOOST_FACTOR、KEY_AAC_DRC_HEAVY_COMPRESSION、KEY_AAC_DRC_TARGET_REFERENCE_LEVEL 和 KEY_AAC_ENCODED_TARGET_LEVEL。
  • [SR-1] 强烈建议所有 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 元数据应优先。

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

5.1.3. 音频编解码器详情

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

5.1.4. 图像编码

更多详情请参见 5.1.6. 图像编解码器详情。

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

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

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

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

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

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

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

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

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

5.1.6. 图像编解码器详情

格式/编解码器 详情 支持的文件类型/容器格式
JPEG Base+渐进式 JPEG (.jpg)
GIF GIF (.gif)
PNG PNG (.png)
BMP BMP (.bmp)
WebP WebP (.webp)
Raw ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)
HEIF 图像、图像集合、图像序列 HEIF (.heif), HEIC (.heic)

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

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

  • [SR-1] 强烈建议支持 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-1] 强烈建议视频编码器和解码器支持至少一种硬件优化的平面或半平面 YUV420 8:8:8 颜色格式（YV12、NV12、NV21 或等效的供应商优化格式）。

  • [C-1-5] 支持高位深格式（每个通道 9 位以上）的视频解码器必须支持在应用程序请求时输出 8 位等效格式。这必须通过 android.media.MediaCodecInfo 支持 YUV420 8:8:8 颜色格式来体现。

如果设备实现通过 Display.HdrCapabilities 声明 HDR 配置文件支持，则它们

  • [C-2-1] 必须支持 HDR 静态元数据解析和处理。

如果设备实现通过 MediaCodecInfo.CodecCapabilities 类中的 FEATURE_IntraRefresh 声明帧内刷新支持，则它们

  • [C-3-1] 必须支持 10 - 60 帧范围内的刷新周期，并在配置的刷新周期的 20% 范围内准确运行。

除非应用程序使用 KEY_COLOR_FORMAT 格式键另行指定，否则视频解码器实现

  • [C-4-1] 如果使用 Surface 输出进行配置，则必须默认使用针对硬件显示优化的颜色格式。
  • [C-4-2] 如果配置为不使用 Surface 输出，则必须默认使用针对 CPU 读取优化的 YUV420 8:8:8 颜色格式。

5.1.8. 视频编解码器列表

格式/编解码器 详情 要支持的文件类型/容器格式
H.263
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • Matroska (.mkv, 仅解码)
H.264 AVC 详情请参见 第 5.2 节和 5.3
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • MPEG-2 TS (.ts, 不可搜索)
  • Matroska (.mkv, 仅解码)
H.265 HEVC 详情请参见 第 5.3 节
  • MPEG-4 (.mp4)
  • Matroska (.mkv, 仅解码)
MPEG-2 Main Profile
  • MPEG2-TS (.ts, 不可搜索)
  • MPEG-4 (.mp4, 仅解码)
  • Matroska (.mkv, 仅解码)
MPEG-4 SP
  • 3GPP (.3gp)
  • MPEG-4 (.mp4)
  • Matroska (.mkv, 仅解码)
VP8 详情请参见 第 5.2 节和 5.3
VP9 详情请参见 第 5.3 节

5.1.9. 媒体编解码器安全性

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

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

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

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

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

  • [C-2-1] 必须包含来自 Android 开源项目的相应 OMX 软件编解码器（如果可用），用于设备支持的每种媒体格式和类型（编码器或解码器）。
  • [C-2-2] 名称以 “OMX.google.” 开头的编解码器必须基于其 Android 开源项目源代码。
  • [C-SR-2] 强烈建议 OMX 软件编解码器在无法访问内存映射器以外的硬件驱动程序的编解码器进程中运行。

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

  • [C-3-1] 必须包含来自 Android 开源项目的相应 Codec 2.0 软件编解码器（如果可用），用于设备支持的每种媒体格式和类型（编码器或解码器）。
  • [C-3-2] 必须将 Codec 2.0 软件编解码器放在 Android 开源项目中提供的软件编解码器进程中，以便更严格地授予对软件编解码器的访问权限。
  • [C-3-3] 名称以 “c2.android.” 开头的编解码器必须基于其 Android 开源项目源代码。

5.1.10. 媒体编解码器特性描述

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

  • [C-1-1] 必须通过 MediaCodecInfo API 返回媒体编解码器特性的正确值。

特别是

  • [C-1-2] 名称以 “OMX.” 开头的编解码器必须使用 OMX API，并且名称符合 OMX IL 命名指南。
  • [C-1-3] 名称以 “c2.” 开头的编解码器必须使用 Codec 2.0 API，并且名称符合 Android 的 Codec 2.0 命名指南。
  • [C-1-4] 名称以 “OMX.google.” 或 “c2.android.” 开头的编解码器不得被描述为供应商或硬件加速。
  • [C-1-5] 在可以访问内存分配器和映射器以外的硬件驱动程序的编解码器进程（供应商或系统）中运行的编解码器不得被描述为仅软件。
  • [C-1-6] Android 开源项目中不存在或不基于该项目中的源代码的编解码器必须被描述为供应商。
  • [C-1-7] 利用硬件加速的编解码器必须被描述为硬件加速。
  • [C-1-8] 编解码器名称不得具有误导性。例如，名为 “decoders” 的编解码器必须支持解码，而名为 “encoders” 的编解码器必须支持编码。名称中包含媒体格式的编解码器必须支持这些格式。

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

  • [C-2-1] 如果编解码器支持以下大小，则所有视频编解码器必须发布可实现的帧率数据
SD (低质量) SD (高质量) HD 720p HD 1080p UHD
视频分辨率
  • 176 x 144 px (H263, MPEG2, MPEG4)
  • 352 x 288 px (MPEG4 编码器, H263, MPEG2)
  • 320 x 180 px (VP8, VP8)
  • 320 x 240 px (其他)
  • 704 x 576 px (H263)
  • 640 x 360 px (VP8, VP9)
  • 640 x 480 px (MPEG4 编码器)
  • 720 x 480 px (其他)
  • 1408 x 1152 px (H263)
  • 1280 x 720 px (其他)
 1920 x 1080 px (MPEG4 以外) 3840 x 2160 px (HEVC, VP9)
  • [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] 所有硬件加速的视频和图像编码器必须支持从硬件摄像头编码帧。
  • 应该支持通过所有视频或图像编码器从硬件摄像头编码帧。

如果设备实现提供 HDR 编码，则它们

  • [C-SR-1] 强烈建议为无缝转码 API 提供插件，以将 HDR 格式转换为 SDR 格式。

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 设备的兼容性，建议编码器不要对 Baseline Profile 使用 ASO、FMO 和 RS。
  • [C-1-2] 必须支持下表中的 SD（标准清晰度）视频编码配置文件。
  • 应该支持 Main Profile Level 4。
  • 应该支持下表中指示的 HD（高清）视频编码配置文件。

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

  • [C-2-1] 必须支持下表中的编码配置文件。
SD (低质量) SD (高质量) HD 720p HD 1080p
视频分辨率 320 x 240 px 720 x 480 px 1280 x 720 px 1920 x 1080 px
视频帧率 20 fps 30 fps 30 fps 30 fps
视频比特率 384 Kbps 2 Mbps 4 Mbps 10 Mbps

5.2.3. VP8

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

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

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

  • [C-2-1] 必须支持下表中的编码配置文件。
SD (低质量) SD (高质量) HD 720p HD 1080p
视频分辨率 320 x 180 px 640 x 360 px 1280 x 720 px 1920 x 1080 px
视频帧率 30 fps 30 fps 30 fps 30 fps
视频比特率 800 Kbps 2 Mbps 4 Mbps 10 Mbps

5.2.4. VP9

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

  • [C-1-2] 必须支持 Profile 0 Level 3。
  • [C-1-1] 必须支持写入 Matroska WebM 文件。
  • [C-1-3] 必须生成 CodecPrivate 数据。
  • 应该支持下表中指示的 HD 解码配置文件。
  • [C-SR-1] 如果有硬件编码器，强烈建议支持下表中指示的 HD 解码配置文件。
SD HD 720p HD 1080p UHD
视频分辨率 720 x 480 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 px
视频帧率 30 fps 30 fps 30 fps 30 fps
视频比特率 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

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

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

5.2.5. H.265

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

  • [C-1-1] 必须支持 Main Profile Level 3。
  • 应该支持下表所示的 HD 编码配置文件。
  • [C-SR-1] 强烈建议支持下表所示的 HD 编码配置文件（如果存在硬件编码器）。
SD HD 720p HD 1080p UHD
视频分辨率 720 x 480 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 px
视频帧率 30 fps 30 fps 30 fps 30 fps
视频比特率 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

5.3. 视频解码

如果设备实现支持 VP8、VP9、H.264 或 H.265 编解码器，则它们

  • [C-1-1] 必须通过标准 Android API 在同一码流内实时支持 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 视频解码配置文件。
SD (低质量) SD (高质量) HD 720p HD 1080p
视频分辨率 320 x 240 px 720 x 480 px 1280 x 720 px 1920 x 1080 px
视频帧率 30 fps 30 fps 60 fps 30 fps (60 fpsTelevision)
视频比特率 800 Kbps 2 Mbps 8 Mbps 20 Mbps

5.3.5. H.265 (HEVC)

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

  • [C-1-1] 必须支持 Main Profile Level 3 Main tier 和下表所示的 SD 视频解码配置文件。
  • 应该支持下表中指示的 HD 解码配置文件。
  • [C-1-2] 必须支持下表所示的 HD 解码配置文件（如果存在硬件解码器）。

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

  • [C-2-1] 设备实现必须支持 H.265 或 VP9 对 720、1080 和 UHD 配置文件的解码（至少支持其中一种）。
SD (低质量) SD (高质量) HD 720p HD 1080p UHD
视频分辨率 352 x 288 px 720 x 480 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 px
视频帧率 30 fps 30 fps 30 fps 30/60 fps (60 fpsTelevision with H.265 hardware decoding) 60 fps
视频比特率 600 Kbps 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

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

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

5.3.6. VP8

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

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

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

  • [C-2-1] 设备实现必须支持下表中的 720p 配置文件。
  • [C-2-2] 设备实现必须支持下表中的 1080p 配置文件。
SD (低质量) SD (高质量) HD 720p HD 1080p
视频分辨率 320 x 180 px 640 x 360 px 1280 x 720 px 1920 x 1080 px
视频帧率 30 fps 30 fps 30 fps (60 fpsTelevision) 30 (60 fpsTelevision)
视频比特率 800 Kbps 2 Mbps 8 Mbps 20 Mbps

5.3.7. VP9

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

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

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

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

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

  • [C-3-1] 设备实现必须支持 VP9 或 H.265 对 720、1080 和 UHD 配置文件的解码（至少支持其中一种）。
SD (低质量) SD (高质量) HD 720p HD 1080p UHD
视频分辨率 320 x 180 px 640 x 360 px 1280 x 720 px 1920 x 1080 px 3840 x 2160 px
视频帧率 30 fps 30 fps 30 fps 30 fps (60 fpsTelevision with VP9 hardware decoding) 60 fps
视频比特率 600 Kbps 1.6 Mbps 4 Mbps 5 Mbps 20 Mbps

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

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

如果设备实现声明通过媒体 API 支持 HDR Profile (VP9Profile2HDR, VP9Profile2HDR10Plus, VP9Profile3HDR, VP9Profile3HDR10Plus)

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

5.3.8. Dolby Vision

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

  • [C-1-1] 必须提供支持 Dolby Vision 的提取器。
  • [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 位样本产生 2500 的 RMS。
  • 应该记录语音识别音频流，以便 PCM 幅度级别在线性跟踪输入 SPL 变化，范围至少为 30 dB，从 -18 dB 到 +12 dB re 90 dB SPL 在麦克风处。
  • 应该记录语音识别音频流，总谐波失真 (THD) 在麦克风处 90 dB SPL 输入电平下 1 kHz 时小于 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 时提供插入到捕获音频路径中的声学回声消除器，则它们

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 位样本的 RMS 为 2500（或浮点/双精度样本的 -22.35 dB Full Scale）的响应。
  • [C-SR-1] 强烈建议在低频范围内表现出幅度级别：具体而言，对于用于记录语音识别音频源的每个麦克风，与中间频率范围相比，从 5 Hz 到 100 Hz 为 ±20 dB。
  • [C-SR-2] 强烈建议在高频范围内表现出幅度级别：具体而言，对于用于记录语音识别音频源的每个麦克风，与中间频率范围相比，从 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、24000、32000、44100、48000（在上面列出的声道配置中）
      • 96000（在单声道和立体声中）

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-1] 强烈建议支持浮点和多声道效果。

5.5.3. 音频输出音量

汽车设备实现

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

5.5.4. 音频卸载

如果设备实现支持 音频卸载播放，则它们

  • [C-SR-1] 强烈建议在 AudioTrack 无缝 API 和 MediaPlayer 的媒体容器指定时，修剪播放的无缝音频内容。

5.6. 音频延迟

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

就本节而言，使用以下定义

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

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

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

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

  • [C-SR-1] 通过扬声器数据路径的冷启动输出延迟为 100 毫秒或更短。强烈建议运行此 Android 版本的现有和新设备现在满足这些要求。在未来的平台版本中，我们将要求冷启动输出延迟为 200 毫秒或更短（必须满足）。
  • [C-SR-2] 点击到声音的延迟为 80 毫秒或更短。
  • [C-SR-3] 尽量减少冷启动输出抖动。
  • [C-SR-4] AudioTrack.getTimestamp 和 AAudioStream_getTimestamp 返回的输出时间戳的精度在 +/- 1 毫秒以内。

如果设备实现在任何初始校准之后，当使用 AAudio 本机音频 API 时，对于至少一个受支持的音频输出设备上的连续输出延迟和冷启动输出延迟满足上述要求，则它们

如果设备实现不满足通过 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-8] 通过麦克风数据路径的冷启动输入延迟为 100 毫秒或更短。强烈建议运行此 Android 版本的现有和新设备现在满足这些要求。在未来的平台版本中，我们将要求冷启动输入延迟为 200 毫秒或更短（必须满足）。
  • [C-SR-9] 连续输入延迟为 30 毫秒或更短。
  • [C-SR-10] 尽量减少冷启动输入抖动。
  • [C-SR-11] 将 AudioRecord.getTimestamp 或 AAudioStream_getTimestamp 返回的输入时间戳的误差限制在 +/- 1 毫秒以内。

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

  • [C-SR-12] 强烈建议在至少一个受支持的路径上，5 次测量的平均连续往返延迟为 50 毫秒或更短，平均绝对偏差小于 10 毫秒。

5.7. 网络协议

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

对于设备实现需要支持的每种编解码器和容器格式，设备实现

  • [C-1-1] 必须支持通过 HTTP 和 HTTPS 的该编解码器或容器。

  • [C-1-2] 必须支持下方的媒体分段格式表所示的对应媒体分段格式，通过 HTTP Live Streaming draft protocol, Version 7。

  • [C-1-3] 必须支持 RTSP 表中所示的对应 RTSP 有效负载格式。有关例外情况，请参见 第 5.1 节 中的表脚注。

媒体分段格式

分段格式 参考 必需的编解码器支持
MPEG-2 传输流 ISO 13818 视频编解码器
  • H264 AVC
  • MPEG-4 SP
  • MPEG-2
有关 H264 AVC、MPEG2-4 SP 和
MPEG-2 的详细信息，请参见 第 5.1.8 节。

音频编解码器

  • AAC
有关 AAC 及其变体的详细信息，请参见 第 5.1.3 节。
带有 ADTS 帧和 ID3 标签的 AAC ISO 13818-7 有关 AAC 及其变体的详细信息，请参见 第 5.1.1 节
WebVTT WebVTT

RTSP (RTP, SDP)

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

5.8. 安全媒体

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

  • [C-1-1] 必须声明支持 Display.FLAG_SECURE。

如果设备实现声明支持 Display.FLAG_SECURE 并支持无线显示协议，则它们

  • [C-2-1] 必须使用密码学强度高的机制（例如 HDCP 2.x 或更高版本）来保护通过无线协议（例如 Miracast）连接的显示器的链路。

如果设备实现声明支持 Display.FLAG_SECURE 并支持有线外部显示器，则它们

  • [C-3-1] 必须支持 HDCP 1.2 或更高版本，用于通过用户可访问的有线端口连接的所有外部显示器。

5.9. 乐器数字接口 (MIDI)

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

  • [C-1-1] 必须支持通过所有支持 MIDI 的硬件传输方式传输 MIDI，对于这些传输方式，它们提供通用的非 MIDI 连接，其中这些传输方式包括：

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

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

  • 应该支持通过 USB 外围设备模式传输 MIDI，第 7.7 节

5.10. 专业音频

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

  • [C-1-1] 必须报告支持 android.hardware.audio.low_latency 功能。
  • [C-1-2] 必须具有连续往返音频延迟，如 5.6 音频延迟 节中所定义，必须为 20 毫秒或更短，并且应该在至少一条支持的路径上为 10 毫秒或更短。
  • [C-1-3] 必须包含支持 USB 主机模式和 USB 外围设备模式的 USB 端口。
  • [C-1-4] 必须报告支持 android.software.midi 功能。
  • [C-1-5] 必须使用 AAudio 原生音频 API 满足延迟和 USB 音频要求。
  • [C-1-6] 必须具有 200 毫秒或更短的冷输出延迟。
  • [C-1-7] 必须具有 200 毫秒或更短的冷输入延迟。
  • [C-SR-1] 强烈建议在扬声器到麦克风路径上的 5 次测量中，满足 5.6 音频延迟 节中定义的延迟，即 20 毫秒或更短，平均绝对偏差小于 5 毫秒。
  • [C-SR-2] 强烈建议在使用 AAudio 原生音频 API over MMAP 路径时，满足专业音频对连续往返音频延迟、冷输入延迟、冷输出延迟和 USB 音频的要求。
  • [C-SR-3] 强烈建议在音频活动且 CPU 负载变化时，提供一致的 CPU 性能水平。这应该使用 Android 应用 SynthMark 进行测试。SynthMark 使用在模拟音频框架上运行的软件合成器来测量系统性能。SynthMark 应用需要使用“Automated Test”（自动测试）选项运行，并达到以下结果：
    • voicemark.90 >= 32 个声音
    • latencymark.fixed.little <= 15 毫秒
    • latencymark.dynamic.little <= 50 毫秒

请参阅 SynthMark 文档，了解基准测试的说明。

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

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

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

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

  • [C-3-1] 必须实现 USB 音频类。
  • [C-3-2] 必须具有 25 毫秒或更短的连续往返音频平均延迟（在 5 次测量中，平均绝对偏差小于 5 毫秒），使用 USB 音频类通过 USB 主机模式端口进行测量。（可以使用 USB-3.5 毫米适配器和音频环回 Dongle，或使用 USB 音频接口，用跳线将输入连接到输出进行测量）。
  • [C-SR-6] 强烈建议在使用也支持这些要求的 USB 音频外围设备时，支持高达 8 个通道的同步 I/O（每个方向）、96 kHz 采样率和 24 位或 32 位深度。
  • [C-SR-7] 强烈建议使用 AAudio 原生音频 API over MMAP 路径满足这组要求。

如果设备实现包含 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 范围内为 ±10 dB。

  • [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 位采样的 RMS 响应为 520（或对于浮点/双精度采样为 -36 dB 满量程），对于用于记录未处理音频源的每个麦克风。

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

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

  • [C-1-8] 必须在路径中没有任何其他信号处理（例如，自动增益控制、高通滤波器或回声消除），除了将电平调整到所需范围的电平乘法器。换句话说

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

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

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

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

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

6.1. 开发者工具

设备实现

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

  • Android 调试桥 (adb)

    • [C-0-2] 必须支持 Android SDK 和 AOSP 中提供的 shell 命令中记录的 adb，应用开发者可以使用这些命令，包括 dumpsys cmd stats
    • [C-0-11] 必须支持 shell 命令 cmd testharness。从没有持久数据块的早期 Android 版本升级的设备实现可以豁免 C-0-11。
    • [C-0-3] 必须不更改通过 dumpsys 命令记录的设备系统事件（batterystats、diskstats、fingerprint、graphicsstats、netstats、notification、procstats）的格式或内容。
    • [C-0-10] 必须无遗漏地记录以下事件，并使其可供 cmd stats shell 命令和 StatsManager 系统 API 类访问和使用。
      • ActivityForegroundStateChanged
      • AnomalyDetected
      • AppBreadcrumbReported
      • AppCrashOccurred
      • AppStartOccurred
      • BatteryLevelChanged
      • BatterySaverModeStateChanged
      • BleScanResultReceived
      • BleScanStateChanged
      • ChargingStateChanged
      • DeviceIdleModeStateChanged
      • ForegroundServiceStateChanged
      • GpsScanStateChanged
      • JobStateChanged
      • PluggedStateChanged
      • ScheduledJobStateChanged
      • ScreenStateChanged
      • SyncStateChanged
      • SystemElapsedRealtime
      • UidProcessStateChanged
      • WakelockStateChanged
      • WakeupAlarmOccurred
      • WifiLockStateChanged
      • WifiMulticastLockStateChanged
      • WifiScanStateChanged
    • [C-0-4] 必须默认情况下禁用设备端 adb 守护程序，并且必须提供用户可访问的机制来启用 Android 调试桥。
    • [C-0-5] 必须支持安全 adb。Android 包含对安全 adb 的支持。安全 adb 在已知的已验证主机上启用 adb。
    • [C-0-6] 必须提供一种机制，允许从主机连接 adb。具体而言：

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

    • [C-3-1] 必须通过局域网（例如以太网或 Wi-Fi）实现 adb。
    • [C-3-2] 必须提供适用于 Windows 7、8 和 10 的驱动程序，允许开发者使用 adb 协议连接到设备。

    如果设备实现支持通过 Wi-Fi 连接 adb 到主机，则它们

    • [C-4-1] 必须使 AdbManager#isAdbWifiSupported() 方法返回 true。

    如果设备实现支持通过 Wi-Fi 连接 adb 到主机，并且包含至少一个摄像头，则它们

    • [C-5-1] 必须使 AdbManager#isAdbWifiQrSupported() 方法返回 true。

  • Dalvik 调试监视服务 (ddms)

    • [C-0-7] 必须支持 Android SDK 中记录的所有 ddms 功能。由于 ddms 使用 adb，因此默认情况下应该禁用对 ddms 的支持，但只要用户已激活 Android 调试桥（如上所述），必须支持 ddms。

  • Monkey

    • [C-0-8] 必须包含 Monkey 框架，并使其可供应用程序使用。

  • SysTrace

    • [C-0-9] 必须支持 Android SDK 中记录的 systrace 工具。Systrace 必须默认处于禁用状态，并且必须提供用户可访问的机制来启用 Systrace。

  • Perfetto

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

  • 低内存 Killer

    • [C-0-10] 当应用被 低内存 Killer 终止时，必须将 LMK_KILL_OCCURRED_FIELD_NUMBER Atom 写入 statsd 日志。

  • 测试工具模式 如果设备实现支持 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] API 方法必须在 SDK 文档允许的情况下返回 null 值。
  • [C-0-5] API 方法必须在 SDK 文档不允许使用 null 值的情况下返回类的无操作实现。
  • [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 屏幕的虚拟像素单位，计算公式为：像素 = dps * (密度/160)。

7.1.1. 屏幕配置

7.1.1.1. 屏幕尺寸和形状

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

设备实现

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

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

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

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

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

  • [C-1-1] 必须确保满足以下至少一项要求：

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

  • 应该包含用户切换到带有矩形角的显示模式的功能。

如果设备实现包含可折叠的 Android 兼容显示屏，或者包含多个显示面板之间的折叠铰链，并将此类显示屏提供给第三方应用渲染，则它们

如果设备实现包含可折叠的 Android 兼容显示屏，或者包含多个显示面板之间的折叠铰链，并且铰链或折叠穿过全屏应用程序窗口，则它们

  • [C-3-1] 必须通过 extensions 或 sidecar API 向应用程序报告铰链或折叠的位置、边界和状态。

有关正确实现 sidecar 或 extension API 的详细信息，请参阅 Window Manager Jetpack 的公共文档。

7.1.1.2. 屏幕纵横比

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

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

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

7.1.1.3. 屏幕密度

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

  • [C-0-1] 默认情况下，设备实现必须仅通过 DisplayMetrics 上列出的 DENSITY_DEVICE_STABLE API 报告 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-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 的支持。

If device implementations include a screen or video output, they

  • [C-1-1] 必须支持 OpenGL ES 1.1 和 2.0，具体体现和详细说明请参见 Android SDK 文档。
  • [C-SR-1] 强烈建议支持 OpenGL ES 3.1。
  • 应该支持 OpenGL ES 3.2。

OpenGL ES dEQP 测试被划分为多个测试列表，每个列表都有一个关联的日期/版本号。这些列表位于 Android 源代码树中的 external/deqp/android/cts/main/glesXX-master-YYYY-MM-DD.txt。如果设备支持某一自报告级别的 OpenGL ES，则表明它可以Pass此级别和更早版本的所有测试列表中的 dEQP 测试。

如果设备实现支持任何 OpenGL ES 版本，则它们

  • [C-2-1] 必须通过 OpenGL ES 托管 API 和原生 API 报告它们已实现的任何其他 OpenGL ES 扩展程序，并且相反，不得报告它们不支持的扩展程序字符串。
  • [C-2-2] 必须支持 EGL_KHR_image、EGL_KHR_image_base、EGL_ANDROID_image_native_buffer、EGL_ANDROID_get_native_client_buffer、EGL_KHR_wait_sync、EGL_KHR_get_all_proc_addresses、EGL_ANDROID_presentation_time、EGL_KHR_swap_buffers_with_damage、EGL_ANDROID_recordable 和 EGL_ANDROID_GLES_layers 扩展程序。
  • [C-2-3] 必须通过 android.software.opengles.deqp.level 功能标记报告所支持的 OpenGL ES dEQP 测试的最高版本。
  • [C-2-4] 必须至少支持版本 132383489（来自 2020 年 3 月 1 日），如 android.software.opengles.deqp.level 功能标记中所报告的那样。
  • [C-2-5] 必须通过针对每个支持的 OpenGL ES 版本，所有版本介于 132383489 和 android.software.opengles.deqp.level 功能标记中指定的版本之间的测试列表中的 OpenGL ES dEQP 测试。
  • [C-SR-2] 强烈建议支持 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 函数符号外，还必须导出这些版本的相应函数符号。
  • [C-SR-3] 强烈建议支持 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 的支持，这是一种用于高性能 3D 图形的低开销、跨平台 API。

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

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

If device implementations include a screen or video output, they

  • 应该包含对 Vulkan 1.1 的支持。

Vulkan dEQP 测试被划分为多个测试列表，每个列表都有一个关联的日期/版本。这些列表位于 Android 源代码树中的 external/deqp/android/cts/main/vk-master-YYYY-MM-DD.txt。如果设备支持某一自报告级别的 Vulkan，则表明它可以Pass此级别和更早版本的所有测试列表中的 dEQP 测试。

如果设备实现包含对 Vulkan 1.0 或更高版本的支持，则它们

  • [C-1-1] 必须使用 android.hardware.vulkan.level 和 android.hardware.vulkan.version 功能标记报告正确的整数值。
  • [C-1-2] 必须为 Vulkan 原生 API vkEnumeratePhysicalDevices() 枚举至少一个 VkPhysicalDevice。
  • [C-1-3] 必须为每个枚举的 VkPhysicalDevice 完全实现 Vulkan 1.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-1-8] 必须通过 android.software.vulkan.deqp.level 功能标记报告所支持的 Vulkan dEQP 测试的最高版本。
  • [C-1-9] 必须至少支持版本 132317953（来自 2019 年 3 月 1 日），如 android.software.vulkan.deqp.level 功能标记中所报告的那样。
  • [C-1-10] 必须通过针对所有版本介于 132317953 和 android.software.vulkan.deqp.level 功能标记中指定的版本之间的测试列表中的 Vulkan dEQP 测试。
  • [C-1-11] 不得枚举对 VK_KHR_video_queue、VK_KHR_video_decode_queue 或 VK_KHR_video_encode_queue 扩展程序的支持。
  • [C-SR-2] 强烈建议支持 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
7.1.4.4 2D 图形加速

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

设备实现

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

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

设备实现

  • [C-0-3] 必须支持 TextureView API，并且必须表现出与上游 Android 实现一致的行为。
7.1.4.5 广色域显示屏

如果设备实现通过 Configuration.isScreenWideColorGamut() 声称支持广色域显示屏，则它们

  • [C-1-1] 必须具有颜色校准的显示屏。
  • [C-1-2] 必须具有色域完全覆盖 CIE 1931 xyY 空间中 sRGB 色域的显示屏。
  • [C-1-3] 必须具有色域在 CIE 1931 xyY 空间中至少覆盖 DCI-P3 90% 面积的显示屏。
  • [C-1-4] 必须支持 OpenGL ES 3.1 或 3.2 并正确报告。
  • [C-1-5] 必须声明支持 EGL_KHR_no_config_context、EGL_EXT_pixel_format_float、EGL_KHR_gl_colorspace、EGL_EXT_gl_colorspace_scrgb、EGL_EXT_gl_colorspace_scrgb_linear、EGL_EXT_gl_colorspace_display_p3、EGL_EXT_gl_colorspace_display_p3_linear 和 EGL_EXT_gl_colorspace_display_p3_passthrough 扩展程序。
  • [C-SR-1] 强烈建议支持 GL_EXT_sRGB。

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

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

7.1.5. 旧版应用兼容模式

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

7.1.6. 屏幕技术

Android 平台包含一些 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] 必须实现 DisplayManager 系统服务和 API，如 Android SDK 文档中所述。

7.2. 输入设备

设备实现

7.2.1. 键盘

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

设备实现

7.2.2. 非触摸导航

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

设备实现

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

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

7.2.3. 导航键

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

  • [C-0-1] 必须提供用户操作来启动已安装的应用程序，这些应用程序具有使用 ACTION=MAIN 和 CATEGORY=LAUNCHER 或电视设备实现的 CATEGORY=LEANBACK_LAUNCHER 设置的 <intent-filter> 的 Activity。“主页”功能应该是此用户操作的机制。
  • 应该为“最近任务”和“返回”功能提供按钮。

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

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

设备实现

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

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

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

如果设备实现不提供“菜单”功能，为了向后兼容，它们

  • [C-3-1] 当 targetSdkVersion 小于 10 时，必须通过物理按钮、软件键或手势使应用程序可以使用“菜单”功能。除非与其他导航功能一起隐藏，“菜单”功能应可访问。

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

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

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

  • [C-5-1] 导航键必须使用屏幕的独特部分，应用程序不可用，并且不得遮挡或以其他方式干扰应用程序可用的屏幕部分。
  • [C-5-2] 必须向应用程序提供显示屏的一部分，该部分满足 第 7.1.1 节中定义的要求。
  • [C-5-3] 必须遵守应用程序通过 View.setSystemUiVisibility() API 方法设置的标志，以便屏幕的此独特部分（又名导航栏）按照 SDK 中的文档正确隐藏。

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

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

  • [C-7-1] 导航功能必须是“返回”，并作为从屏幕当前方向的左边缘和右边缘滑动手势提供。
  • [C-7-2] 如果在左边缘或右边缘提供自定义可滑动系统面板，它们必须放置在屏幕顶部 1/3 区域内，并具有清晰、持久的视觉指示，表明向内拖动将调用上述面板，而不是“返回”。系统面板可以由用户配置为位于屏幕边缘的顶部 1/3 区域下方，但系统面板不得使用超过边缘的 1/3 区域。
  • [C-7-3] 当前台应用程序设置了 View.SYSTEM_UI_FLAG_IMMERSIVE、View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY、WindowInsetsController.BEHAVIOR_DEFAULT 或 WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE 标志时，从边缘滑动必须表现得与 AOSP 中的实现相同，这在 SDK 中有文档记录。
  • [C-7-4] 当前台应用程序设置了 View.SYSTEM_UI_FLAG_IMMERSIVE、View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY、WindowInsetsController.BEHAVIOR_DEFAULT 或 WindowInsetsController.BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE 标志时，自定义可滑动系统面板必须保持隐藏状态，直到用户调出或取消系统栏（又名导航栏和状态栏）的暗淡状态，如 AOSP 中实现的那样。

7.2.4. 触摸屏输入

Android 包括对各种指针输入系统的支持，例如触摸屏、触摸板和伪触摸输入设备。基于触摸屏的设备实现与显示屏相关联，使用户产生直接操作屏幕上项目的印象。由于用户直接触摸屏幕，因此系统不需要任何额外的操作来指示正在操作的对象。

设备实现

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

如果设备实现主要 Android 兼容显示屏上的触摸屏（单点触摸或更好），则它们

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

如果设备实现包括可以跟踪主要 Android 兼容显示屏上多个触摸点的触摸屏，则它们

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

如果设备实现依赖鼠标或轨迹球等外部输入设备（即不直接触摸屏幕）在主要 Android 兼容显示屏上进行输入，并且满足 第 7.2.5 节中的伪触摸要求，则它们

  • [C-3-1] 不得报告任何以 android.hardware.touchscreen 开头的功能标记。
  • [C-3-2] 必须仅报告 android.hardware.faketouch。
  • [C-3-3] 必须为 Configuration.touchscreen API 字段报告 TOUCHSCREEN_NOTOUCH。

7.2.5. 伪触摸输入

伪触摸界面提供了一种用户输入系统，该系统近似于触摸屏功能的子集。例如，鼠标或遥控器驱动屏幕光标近似于触摸，但需要用户先指向或聚焦，然后再单击。诸如鼠标、触控板、基于陀螺仪的空中鼠标、陀螺仪指针、操纵杆和多点触控板等多种输入设备可以支持伪触摸交互。Android 包括功能常量 android.hardware.faketouch，它对应于高保真非触摸（基于指针）输入设备（例如鼠标或触控板），该设备可以充分模拟基于触摸的输入（包括基本手势支持），并指示设备支持触摸屏功能的模拟子集。

如果设备实现不包含触摸屏，但包含它们想要提供的另一种指针输入系统，则它们

  • 应该声明支持 android.hardware.faketouch 功能标记。

如果设备实现声明支持 android.hardware.faketouch，则它们

  • [C-1-1] 必须报告指针位置的 绝对 X 和 Y 屏幕位置，并在屏幕上显示可视指针。
  • [C-1-2] 必须报告触摸事件，其操作代码指定指针 在屏幕上按下或抬起 时发生的状态更改。
  • [C-1-3] 必须支持在屏幕上对象的指针按下和抬起，这允许用户模拟点按屏幕上的对象。
  • [C-1-4] 必须支持指针按下、指针抬起、指针按下然后在时间阈值内再次在屏幕上对象的同一位置抬起，这允许用户 模拟双击 屏幕上的对象。
  • [C-1-5] 必须支持指针在屏幕上的任意点按下、指针移动到屏幕上的任何其他任意点，然后指针抬起，这允许用户模拟触摸拖动。
  • [C-1-6] 必须支持指针按下，然后允许用户快速将对象移动到屏幕上的不同位置，然后在屏幕上抬起指针，这允许用户在屏幕上快速滑动对象。

如果设备实现声明支持 android.hardware.faketouch.multitouch.distinct，则它们

  • [C-2-1] 必须声明支持 android.hardware.faketouch。
  • [C-2-2] 必须支持对两个或多个独立指针输入的不同跟踪。

如果设备实现声明支持 android.hardware.faketouch.multitouch.jazzhand，则它们

  • [C-3-1] 必须声明支持 android.hardware.faketouch。
  • [C-3-2] 必须支持完全独立地不同跟踪 5 个（跟踪一只手的手指）或更多指针输入。

7.2.6. 游戏控制器支持

7.2.6.1. 按钮映射

设备实现

  • [C-1-1] 必须能够将 HID 事件映射到下表列出的相应 InputEvent 常量。上游 Android 实现满足此要求。

如果设备实现嵌入了控制器或在包装盒中随附了单独的控制器，该控制器将提供输入下表列出的所有事件的方式，则它们

  • [C-2-1] 必须声明功能标记 android.hardware.gamepad
按钮 HID 用法2 Android 按钮
A1 0x09 0x0001 KEYCODE_BUTTON_A (96)
B1 0x09 0x0002 KEYCODE_BUTTON_B (97)
X1 0x09 0x0004 KEYCODE_BUTTON_X (99)
Y1 0x09 0x0005 KEYCODE_BUTTON_Y (100)
D-pad 上1
D-pad 下1		 0x01 0x00393 AXIS_HAT_Y4
D-pad 左1
D-pad 右1		 0x01 0x00393 AXIS_HAT_X4
左肩键1 0x09 0x0007 KEYCODE_BUTTON_L1 (102)
右肩键1 0x09 0x0008 KEYCODE_BUTTON_R1 (103)
左摇杆点击1 0x09 0x000E KEYCODE_BUTTON_THUMBL (106)
右摇杆点击1 0x09 0x000F KEYCODE_BUTTON_THUMBR (107)
返回1 0x0c 0x0224 KEYCODE_BACK (4)

1 KeyEvent

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

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

4 MotionEvent

模拟控件1 HID 用法 Android 按钮
左扳机 0x02 0x00C5 AXIS_LTRIGGER
右扳机 0x02 0x00C4 AXIS_RTRIGGER
左摇杆 0x01 0x0030
0x01 0x0031		 AXIS_X
AXIS_Y
右摇杆 0x01 0x0032
0x01 0x0035		 AXIS_Z
AXIS_RZ

1 MotionEvent

7.2.7. 遥控器

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

7.3. 传感器

如果设备实现包含特定传感器类型，且该类型具有针对第三方开发者的相应 API，则设备实现必须按照 Android SDK 文档和关于 传感器 的 Android 开源文档中所述实现该 API。

设备实现

  • [C-0-1] 必须根据 android.content.pm.PackageManager 类准确报告传感器的存在与否。
  • [C-0-2] 必须通过 SensorManager.getSensorList() 和类似方法返回受支持传感器的准确列表。
  • [C-0-3] 必须对所有其他传感器 API 表现合理行为（例如，当应用程序尝试注册侦听器时返回 true 或 false，当相应的传感器不存在时不调用传感器侦听器等）。

如果设备实现包含特定传感器类型，且该类型具有针对第三方开发者的相应 API，则它们

  • [C-1-1] 必须使用 Android SDK 文档中定义的每种传感器类型的相关国际单位制 (公制) 值 报告所有传感器测量值。
  • [C-1-2] 当应用程序处理器处于活动状态时，对于最大请求延迟为 0 毫秒的传感器流，必须以最大延迟 100 毫秒 + 2 * sample_time 报告传感器数据。此延迟不包括任何滤波延迟。
  • [C-1-3] 必须在传感器激活后的 400 毫秒 + 2 * sample_time 内报告第一个传感器样本。此样本的精度为 0 是可以接受的。
  • [C-1-4] 对于 Android SDK 文档中指示为连续传感器的任何 API，设备实现必须持续提供周期性数据样本，这些样本的抖动应该低于 3%，其中抖动定义为连续事件之间报告的时间戳值差异的标准偏差。
  • [C-1-5] 必须确保传感器事件流不得阻止设备 CPU 进入挂起状态或从挂起状态唤醒。
  • [C-1-6] 必须按照 Android SDK 文档中的定义，以纳秒为单位 报告事件时间，表示事件发生的时间并与 SystemClock.elapsedRealtimeNano() 时钟同步。
  • [C-SR-1] 强烈建议时间戳同步误差低于 100 毫秒，并且应该时间戳同步误差低于 1 毫秒。
  • 当激活多个传感器时，功耗不应超过各个传感器报告的功耗之和。

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

如果设备实现包含特定传感器类型，且该类型具有针对第三方开发者的相应 API，则它们

  • [C-1-6] 必须为所有传感器设置非零分辨率，并通过 Sensor.getResolution() API 方法报告该值。

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

设备实现

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

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

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

如果设备实现包含具有第三方开发者对应 API 的特定传感器类型，且该传感器仅报告一个值，则设备实现

  • [C-3-1] 必须将该传感器的分辨率设置为 1，并通过 Sensor.getResolution() API 方法报告该值。

如果设备实现包含支持 SensorAdditionalInfo#TYPE_VEC3_CALIBRATION 的特定传感器类型，并且该传感器向第三方开发者公开，则

  • [C-4-1] 不得在提供的数据中包含任何固定的、出厂确定的校准参数。

如果设备实现包含 3 轴加速度计、3 轴陀螺仪传感器或磁力计传感器的组合，则

  • [C-SR-2] 强烈建议确保加速度计、陀螺仪和磁力计具有固定的相对位置，这样，如果设备是可变形的（例如，可折叠的），则在所有可能的设备变形状态下，传感器轴仍保持对齐并与传感器坐标系一致。

7.3.1. 加速度计

设备实现

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

如果设备实现包含 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^ 的标准偏差，其中标准偏差应在以最快采样率收集的至少 3 秒的样本基础上按轴计算。
  • [C-SR-2] 强烈建议 实现 TYPE_SIGNIFICANT_MOTION 复合传感器。
  • [C-SR-3] 强烈建议实现并报告 TYPE_ACCELEROMETER_UNCALIBRATED 传感器。强烈建议 Android 设备满足此要求，以便能够升级到未来平台版本，届时这可能成为必需项。
  • 应实现 TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR、TYPE_STEP_COUNTER 复合传感器，如 Android SDK 文档中所述。
  • 应报告频率至少为 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-4] 强烈建议实现 TYPE_GAME_ROTATION_VECTOR 复合传感器。

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

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

7.3.2. 磁力计

设备实现

  • [C-SR-1] 强烈建议包含 3 轴磁力计（指南针）。

如果设备实现包含 3 轴磁力计，则

  • [C-1-1] 必须实现 TYPE_MAGNETIC_FIELD 传感器。
  • [C-1-2] 必须能够以至少 10 Hz 的频率报告事件，并且应以至少 50 Hz 的频率报告事件。
  • [C-1-3] 必须遵守 Android API 中详述的 Android 传感器坐标系。
  • [C-1-4] 必须能够在每个轴上测量 -900 µT 到 +900 µT 之间的磁场而不饱和。
  • [C-1-5] 通过将磁力计放置在远离动态（电流感应）和静态（磁铁感应）磁场的位置，必须具有小于 700 µT 的硬铁偏移值，并且应具有低于 200 µT 的值。
  • [C-1-6] 必须具有等于或高于 0.6 µT 的分辨率。
  • [C-1-7] 必须支持硬铁偏置的在线校准和补偿，并在设备重启之间保留补偿参数。
  • [C-1-8] 必须应用软铁补偿——校准可以在使用时或在设备生产期间完成。
  • [C-1-9] 必须具有标准偏差，该标准偏差在以最快采样率收集的至少 3 秒的样本基础上按轴计算，不大于 1.5 µT；应具有不大于 0.5 µT 的标准偏差。
  • [C-1-10] 必须实现 TYPE_MAGNETIC_FIELD_UNCALIBRATED 传感器。

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

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

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

  • 可以实现 TYPE_GEOMAGNETIC_ROTATION_VECTOR 传感器。

如果设备实现包含 3 轴磁力计、加速度计和 TYPE_GEOMAGNETIC_ROTATION_VECTOR 传感器，则

  • [C-3-1] 功耗必须小于 10 mW。
  • 当传感器以 10 Hz 批量模式注册时，功耗应小于 3 mW。

7.3.3. GPS

设备实现

  • [C-SR-1] 强烈建议包含 GPS/GNSS 接收器。

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

  • [C-1-1] 当通过 LocationManager#requestLocationUpdate 请求时，必须支持至少 1 Hz 的位置输出速率。
  • [C-1-2] 当连接到 0.5 Mbps 或更快的网速互联网连接时，必须能够在开阔天空条件下（信号强、多径可忽略不计、HDOP < 2）在 10 秒内确定位置（快速首次定位时间）。此要求通常通过使用某种形式的辅助或预测 GPS/GNSS 技术来满足，以最大限度地缩短 GPS/GNSS 锁定时间（辅助数据包括参考时间、参考位置和卫星星历/时钟）。
    • [C-1-6] 在进行这样的位置计算后，设备实现在开阔天空下必须在 5 秒内确定其位置，当位置请求重新启动时，在初始位置计算后最多一小时内，即使后续请求是在没有数据连接和/或断电重启后发出的。

  • 在开阔天空条件下，在确定位置后，当静止或以小于每秒平方米 1 米的加速度移动时

    • [C-1-3] 必须能够在 20 米内确定位置，并且在至少 95% 的时间内，速度在每秒 0.5 米以内。
    • [C-1-4] 必须通过 GnssStatus.Callback 同时跟踪和报告来自一个星座的至少 8 颗卫星。
    • 应能够同时跟踪来自多个星座（例如，GPS + 格洛纳斯、北斗、伽利略中的至少一个）的至少 24 颗卫星。

  • [C-SR-2] 强烈建议在紧急电话呼叫期间，通过 GNSS 位置提供程序 API 继续提供正常的 GPS/GNSS 位置输出。

  • [C-SR-3] 强烈建议报告来自所有跟踪星座的 GNSS 测量值（如 GnssStatus 消息中所报告），SBAS 除外。

  • [C-SR-4] 强烈建议报告 GNSS 测量的 AGC 和频率。

  • [C-SR-5] 强烈建议报告所有精度估计值（包括方位角、速度和垂直精度）作为每个 GPS/GNSS 位置的一部分。

  • [C-SR-6] 强烈建议在找到 GNSS 测量值后立即报告，即使尚未报告从 GPS/GNSS 计算的位置。

  • [C-SR-7] 强烈建议报告 GNSS 伪距和伪距率，这些伪距和伪距率在开阔天空条件下，在确定位置后，当静止或以小于每秒平方米 0.2 米的加速度移动时，足以在 20 米内计算位置，并且在至少 95% 的时间内，速度在每秒 0.2 米以内。

7.3.4. 陀螺仪

设备实现

  • [C-SR-1] 强烈建议包含陀螺仪传感器。

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

  • [C-1-1] 必须能够以至少 50 Hz 的频率报告事件。
  • [C-1-2] 必须实现 TYPE_GYROSCOPE 传感器。
  • [C-1-4] 必须具有 12 位或更高的分辨率。
  • [C-1-5] 必须进行温度补偿。
  • [C-1-6] 必须在使用时进行校准和补偿，并在设备重启之间保留补偿参数。
  • [C-1-7] 必须具有不超过 1e-7 rad^2 / s^2 每 Hz 的方差（每 Hz 方差，或 rad^2 / s）。方差允许随采样率变化，但必须受此值约束。换句话说，如果您测量 1 Hz 采样率下陀螺仪的方差，它应不大于 1e-7 rad^2/s^2。
  • [C-SR-2] 强烈建议当设备在室温下静止时，校准误差小于 0.01 rad/s。
  • [C-SR-3] 强烈建议实现 TYPE_GYROSCOPE_UNCALIBRATED 传感器。
  • [C-SR-4] 强烈建议具有 16 位或更高的分辨率。
  • 应报告频率至少为 200 Hz 的事件。

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

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

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

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

7.3.5. 气压计

设备实现

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

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

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

7.3.6. 温度计

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

  • [C-1-1] 必须为环境温度传感器定义 SENSOR_TYPE_AMBIENT_TEMPERATURE，并且该传感器必须测量用户与设备交互的环境（房间/车厢）温度，单位为摄氏度。

如果设备实现包含测量环境温度以外温度的温度计传感器，例如 CPU 温度，则

如果设备实现包含用于监测皮肤温度的传感器，则

7.3.7. 光度计

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

7.3.8. 接近传感器

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

如果设备实现包含接近传感器并且它们仅报告二进制“近”或“远”读数，则

  • [C-1-1] 必须测量屏幕同一方向上物体的接近程度。也就是说，接近传感器必须定向为检测靠近屏幕的物体，因为此传感器类型的主要目的是检测用户正在使用的手机。如果设备实现包含任何其他方向的接近传感器，则不得通过此 API 访问它。
  • [C-1-2] 必须具有 1 位或更高的精度。
  • [C-1-3] 必须使用 0 厘米作为“近”读数，使用 5 厘米作为“远”读数。
  • [C-1-4] 必须报告最大范围和分辨率为 5。

7.3.9. 高保真传感器

如果设备实现包含本节中定义的一组更高质量的传感器，并将其提供给第三方应用，则

  • [C-1-1] 必须通过 android.hardware.sensor.hifi_sensors 功能标志来标识该功能。

如果设备实现声明 android.hardware.sensor.hifi_sensors，则

  • [C-2-1] 必须具有 TYPE_ACCELEROMETER 传感器，该传感器

    • 必须具有至少 -8g 和 +8g 之间的测量范围，并且强烈建议具有至少 -16g 和 +16g 之间的测量范围。
    • 必须具有至少 2048 LSB/g 的测量分辨率。
    • 必须具有 12.5 Hz 或更低的最小测量频率。
    • 必须具有 400 Hz 或更高的最大测量频率；应支持 SensorDirectChannel RATE_VERY_FAST。
    • 必须具有不超过 400 μg/√Hz 的测量噪声。
    • 必须实现此传感器的非唤醒形式，且具有至少 3000 个传感器事件的缓冲能力。
    • 必须具有不差于 3 mW 的批量处理功耗。
    • [C-SR-1] 强烈建议具有至少为奈奎斯特频率 80% 的 3dB 测量带宽，以及此带宽内的白噪声频谱。
    • 在室温下测试时，加速度随机游走应小于 30 μg √Hz。
    • 偏置随温度的变化应 ≤ +/- 1 mg/°C。
    • 最佳拟合线非线性应 ≤ 0.5%，灵敏度随温度的变化应 ≤ 0.03%/C°。
    • 交叉轴灵敏度应 < 2.5 %，交叉轴灵敏度变化应 < 0.2 % 在设备工作温度范围内。

  • [C-2-2] 必须具有 TYPE_ACCELEROMETER_UNCALIBRATED，其质量要求与 TYPE_ACCELEROMETER 相同。

  • [C-2-3] 必须具有 TYPE_GYROSCOPE 传感器，该传感器

    • 必须具有至少 -1000 和 +1000 dps 之间的测量范围。
    • 必须具有至少 16 LSB/dps 的测量分辨率。
    • 必须具有 12.5 Hz 或更低的最小测量频率。
    • 必须具有 400 Hz 或更高的最大测量频率；应支持 SensorDirectChannel RATE_VERY_FAST。
    • 必须具有不超过 0.014°/s/√Hz 的测量噪声。
    • [C-SR-2] 强烈建议具有至少为奈奎斯特频率 80% 的 3dB 测量带宽，以及此带宽内的白噪声频谱。
    • 在室温下测试时，速率随机游走应小于 0.001 °/s √Hz。
    • 偏置随温度的变化应 ≤ +/- 0.05 °/ s / °C。
    • 灵敏度随温度的变化应 ≤ 0.02% / °C。
    • 最佳拟合线非线性应 ≤ 0.2%。
    • 噪声密度应 ≤ 0.007 °/s/√Hz。
    • 在设备静止时，10 ~ 40 ℃ 温度范围内的校准误差应小于 0.002 rad/s。
    • 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-3] 强烈建议当报告速率为 50 Hz 或更高时，具有从 1 Hz 到至少 10 Hz 的白噪声频谱。

  • [C-2-7] 必须具有 TYPE_PRESSURE 传感器，该传感器

    • 必须具有至少 300 和 1100 hPa 之间的测量范围。
    • 必须具有至少 80 LSB/hPa 的测量分辨率。
    • 必须具有 1 Hz 或更低的最小测量频率。
    • 必须具有 10 Hz 或更高的最大测量频率。
    • 必须具有不超过 2 Pa/√Hz 的测量噪声。
    • 必须实现此传感器的非唤醒形式，且具有至少 300 个传感器事件的缓冲能力。
    • 必须具有不差于 2 mW 的批量处理功耗。

  • [C-2-8] 必须具有 TYPE_GAME_ROTATION_VECTOR 传感器。

  • [C-2-9] 必须具有 TYPE_SIGNIFICANT_MOTION 传感器，该传感器

    • 必须具有不差于 0.5 mW（设备静态时）和 1.5 mW（设备移动时）的功耗。

  • [C-2-10] 必须具有 TYPE_STEP_DETECTOR 传感器，该传感器

    • 必须实现此传感器的非唤醒形式，且具有至少 100 个传感器事件的缓冲能力。
    • 必须具有不差于 0.5 mW（设备静态时）和 1.5 mW（设备移动时）的功耗。
    • 必须具有不差于 4 mW 的批量处理功耗。

  • [C-2-11] 必须具有 TYPE_STEP_COUNTER 传感器，该传感器

    • 必须具有不差于 0.5 mW（设备静态时）和 1.5 mW（设备移动时）的功耗。

  • [C-2-12] 必须具有 TILT_DETECTOR 传感器，该传感器

    • 必须具有不差于 0.5 mW（设备静态时）和 1.5 mW（设备移动时）的功耗。

  • [C-2-13] 加速度计、陀螺仪和磁力计报告的同一物理事件的事件时间戳必须彼此在 2.5 毫秒内。加速度计和陀螺仪报告的同一物理事件的事件时间戳应彼此在 0.25 毫秒内。

  • [C-2-14] 陀螺仪传感器事件时间戳必须与摄像头子系统在同一时基上，并且误差在 1 毫秒内。

  • [C-2-15] 必须在数据在上述任何物理传感器上可用时起的 5 毫秒内将样本传递给应用程序。

  • [C-2-16] 当启用以下传感器的任意组合时，静态时功耗不得高于 0.5 mW，移动时功耗不得高于 2.0 mW

    • SENSOR_TYPE_SIGNIFICANT_MOTION
    • SENSOR_TYPE_STEP_DETECTOR
    • SENSOR_TYPE_STEP_COUNTER
    • SENSOR_TILT_DETECTORS

  • [C-2-17] 可以具有 TYPE_PROXIMITY 传感器，但如果存在，则必须具有至少 100 个传感器事件的最小缓冲能力。

请注意，本节中的所有功耗要求均不包括应用处理器的功耗。它包括整个传感器链（传感器、任何支持电路、任何专用传感器处理系统等）的功耗。

如果设备实现包含直接传感器支持，则

  • [C-3-1] 必须通过 isDirectChannelTypeSupported 和 getHighestDirectReportRateLevel API 正确声明对直接通道类型和直接报告速率级别的支持。
  • [C-3-2] 对于声明支持传感器直接通道的所有传感器，必须支持两种传感器直接通道类型中的至少一种。
  • 应支持通过传感器直接通道报告以下类型的主传感器（非唤醒变体）的事件
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. 生物识别传感器

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

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

  • 应包含生物识别传感器

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

如果设备实现通过 android.hardware.biometrics.BiometricManager、android.hardware.biometrics.BiometricPrompt 和 android.provider.Settings.ACTION_BIOMETRIC_ENROLL 向第三方应用程序提供生物识别传感器，则

  • [C-4-1] 必须满足本文档中定义的 3 级或 2 级 生物识别的要求。
  • [C-4-2] 必须识别并遵守在 Authenticators 类中定义为常量的每个参数名称及其任意组合。相反，不得遵守或识别传递给 canAuthenticate(int) 和 setAllowedAuthenticators(int) 方法的整数常量，除非这些常量在 Authenticators 中记录为公共常量及其任意组合。
  • [C-4-3] 必须在具有 3 级或 2 级 生物识别技术的设备上实现 ACTION_BIOMETRIC_ENROLL 操作。此操作必须仅显示 3 级或 2 级 生物识别的注册入口点。

如果设备实现支持被动生物识别，则

  • [C-5-1] 默认情况下必须要求额外的确认步骤（例如，按下按钮）。
  • [C-SR-1] 强烈建议设置一个设置，允许用户覆盖应用程序首选项，并始终要求附带确认步骤。
  • [C-SR-2] 强烈建议确认操作是安全的，这样操作系统或内核的妥协无法欺骗它。例如，这意味着基于物理按钮的确认操作通过安全元件 (SE) 的仅输入通用输入/输出 (GPIO) 引脚路由，该引脚只能通过物理按钮按下来驱动。
  • [C-5-2] 必须另外实现与 setConfirmationRequired(boolean) 对应的隐式身份验证流程（无需确认步骤），应用程序可以设置为用于登录流程。

如果设备实现有多个生物识别传感器，则

  • [C-SR-3] 强烈建议每次身份验证仅要求确认一个生物识别（例如，如果设备上同时提供指纹和面部传感器，则在确认其中任何一个后应发送 onAuthenticationSucceeded）。

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

  • [C-6-1] 必须满足下面本节中定义的 3 级 的要求。
  • [C-6-2] 当身份验证需要 BIOMETRIC_STRONG，或者身份验证是使用 CryptoObject 调用时，必须仅呈现 3 级 生物识别。

如果设备实现希望将生物识别传感器视为 1 级（以前称为 便捷），则

  • [C-1-1] 必须具有小于 0.002% 的误接受率。
  • [C-1-2] 如果欺骗和冒名顶替接受率高于 Android 生物识别测试协议 测量的 7%，则必须披露此模式可能不如强 PIN、图案或密码安全，并清楚地列举启用它的风险。
  • [C-1-9] 在不超过 20 次错误尝试后，且生物识别验证的回退时间不少于 90 秒时，必须质询用户以获得推荐的主要身份验证（例如，PIN 码、图案、密码）——其中错误尝试是指具有足够的捕获质量 (BIOMETRIC_ACQUIRED_GOOD) 但与已注册生物识别不匹配的一次尝试。
  • [C-SR-4] 如果欺骗和冒名顶替接受率高于 Android 生物识别测试协议测量的 7%，则强烈建议降低 [C-1-9] 中指定的生物识别验证的总错误尝试次数。
  • [C-1-3] 必须限制生物识别验证的尝试次数——其中错误尝试是指具有足够的捕获质量 (BIOMETRIC_ACQUIRED_GOOD) 但与已注册生物识别不匹配的一次尝试。
  • [C-SR-5] 强烈建议在 [C-1-9] 的最大错误尝试次数的生物识别验证的五次错误尝试后，至少限制尝试 30 秒——其中错误尝试是指具有足够的捕获质量 (BIOMETRIC_ACQUIRED_GOOD) 但与已注册生物识别不匹配的一次尝试。
  • [C-SR-6] 强烈建议将所有速率限制逻辑都放在 TEE 中。
  • [C-1-10] 一旦主要身份验证回退首次如第 9.11 节的 [C-0-2] 中所述触发，必须禁用生物识别。
  • [C-1-4] 在未首先通过让用户确认现有设备凭据或添加新的设备凭据（TEE 保护的 PIN/图案/密码）建立信任链的情况下，必须阻止添加新的生物识别；Android 开源项目实现提供了框架中的机制来执行此操作。
  • [C-1-5] 当用户帐户被删除时（包括通过恢复出厂设置），必须完全删除用户的所有可识别生物识别数据。
  • [C-1-6] 必须遵守该生物识别的单个标志（即 DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT、DevicePolicymanager.KEYGUARD_DISABLE_FACE 或 DevicePolicymanager.KEYGUARD_DISABLE_IRIS）。
  • [C-1-7] 必须质询用户以获得推荐的主要身份验证（例如，PIN 码、图案、密码）：a) 对于使用 Android 9 或更高版本启动的设备，每 24 小时或更短时间一次，或者 b) 对于从 Android 8 或更早版本升级的设备，每 72 小时或更短时间一次。

  • [C-1-8] 在发生以下情况之一后，必须质询用户以获得推荐的主要身份验证（例如：PIN 码、图案、密码）或 3 级（强）生物识别

    • 4 小时的空闲超时时间，或者

    • 3 次生物识别身份验证尝试失败。

  • [C-SR-7] 强烈建议使用 Android 开源项目提供的框架中的逻辑来强制执行 [C-1-7] 和 [C-1-8] 中为新设备指定的约束。

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

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

如果设备实现希望将生物识别传感器视为 2 级（以前称为 弱），则

  • [C-2-1] 必须满足上述 1 级 的所有要求。
  • [C-2-2] 必须具有不超过 Android 生物识别测试协议 测量的 20% 的欺骗和冒名顶替接受率。
  • [C-2-3] 必须在 Android 用户或内核空间之外的隔离执行环境（例如可信执行环境 (TEE)）中或在具有与隔离执行环境的安全通道的芯片上执行生物识别匹配。
  • [C-2-4] 必须对所有可识别数据进行加密和密码学身份验证，以便它们无法在隔离执行环境之外或在具有与隔离执行环境的安全通道的芯片上获取、读取或更改，如 Android 开源项目站点上的 实施指南 中所述。
  • [C-2-5] 对于基于摄像头的生物识别，在进行基于生物识别的身份验证或注册时
    • 必须在一种模式下操作摄像头，以防止在隔离的执行环境之外或具有通往隔离执行环境的安全通道的芯片上读取或更改摄像头帧。
    • 对于 RGB 单摄像头解决方案，摄像头帧可以在隔离的执行环境之外读取，以支持诸如注册预览之类的操作，但仍然绝不能被更改。
  • [C-2-6] 绝不能允许第三方应用程序区分单个生物识别注册。
  • [C-2-7] 绝不能允许在 TEE 环境之外，在应用程序处理器上以未加密的方式访问可识别的生物识别数据或从中衍生的任何数据（例如嵌入）。在 Android 9 或更早版本上推出的升级设备不免除 C-2-7 的要求。

  • [C-2-8] 必须具有安全的处理管道，以确保操作系统或内核的妥协不会允许直接注入数据以冒充用户进行身份验证。

  • [C-SR-10] 强烈建议为所有生物识别方式包含活体检测，并为面部生物识别包含注意力检测。

  • [C-2-9] 必须使生物识别传感器可供第三方应用程序使用。

如果设备实现希望将生物识别传感器视为Class 3（以前称为Strong），则它们

  • [C-3-1] 必须满足上述 Class 2 的所有要求，[C-1-7] 和 [C-1-8] 除外。
  • [C-3-2] 必须具有硬件支持的密钥库实现。
  • [C-3-3] 使用 Android 生物识别测试协议 测量，其欺骗和冒名顶替接受率不得高于 7%。
  • [C-3-4] 必须每 72 小时或更短时间向用户询问推荐的主要身份验证方式（例如 PIN 码、图案、密码）。
  • [C-3-5] 如果重新注册了设备上支持的任何 Class 3 生物识别方式，则必须为所有 Class 3 生物识别方式重新生成 Authenticator ID。
  • [C-3-6] 必须允许第三方应用程序使用生物识别支持的密钥库密钥。

如果设备实现包含屏下指纹传感器 (UDFPS)，则它们

  • [C-SR-11] 强烈建议防止 UDFPS 的可触摸区域干扰三键导航（某些用户可能出于辅助功能目的而需要三键导航）。

7.3.12. 姿势传感器

设备实现

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

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

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

7.3.13. 铰链角度传感器

如果设备实现支持铰链角度传感器，则它们

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。
  • 在紧急呼叫期间，应该允许所有可用的蜂窝服务类型（2G、3G、4G、5G 等）（无论 SetAllowedNetworkTypeBitmap() 设置的网络类型如何）。

如果设备实现不包含电话硬件，则它们

  • [C-2-1] 必须将完整的 API 实现为 no-ops。

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

如果设备实现未将系统属性 ro.telephony.iwlan\_operation\_mode 设置为“legacy”，则它们

如果设备实现支持用于多媒体电话服务 (MMTEL) 和富通信服务 (RCS) 功能的单个 IP 多媒体子系统 (IMS) 注册，并且预期符合蜂窝运营商关于对所有 IMS 信令流量使用单个 IMS 注册的要求，则它们

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

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

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

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

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

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

  • [C-SR-2] 强烈建议按如下方式处理音频耳机的 KEYCODE_MEDIA_PLAY_PAUSE 和 KEYCODE_HEADSETHOOK 事件，用于 android.telecom API

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 文档中描述的 多播 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-1-7] 必须在 STA 断开连接时，在每次扫描开始时随机化探测请求帧的源 MAC 地址和序列号。
  • [C-1-8] 必须使用一个一致的 MAC 地址（在扫描过程中不应随机化 MAC 地址）。
  • [C-1-9] 必须在扫描中的探测请求之间正常（顺序地）迭代探测请求序列号。
  • [C-1-10] 必须在扫描的最后一个探测请求和下一次扫描的第一个探测请求之间随机化探测请求序列号。
  • [C-SR-1] 强烈建议在关联和关联时，为所有 STA 与接入点 (AP) 的通信随机化源 MAC 地址。
    • 设备必须为与其通信的每个 SSID（Passpoint 的 FQDN）使用不同的随机 MAC 地址。
    • 设备必须为用户提供一个选项，以控制每个 SSID（Passpoint 的 FQDN）的随机化，包括非随机和随机选项，并且必须将新的 Wi-Fi 配置的默认模式设置为随机。
  • [C-SR-2] 强烈建议为他们创建的任何 AP 使用随机 BSSID。
    • MAC 地址必须针对 AP 使用的每个 SSID 进行随机化和持久化。
    • 设备可以为用户提供禁用此功能的选项。如果提供此类选项，则默认情况下必须启用随机化。

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

  • 每当应用程序通过 WifiManager.createWifiLock() 和 WifiManager.WifiLock.acquire() API 获取 WIFI_MODE_FULL_HIGH_PERF 锁或 WIFI_MODE_FULL_LOW_LATENCY 锁并且该锁处于活动状态时，应该关闭 Wi-Fi 省电模式。
  • [C-3-2] 当设备处于 Wi-Fi 低延迟锁 (WIFI_MODE_FULL_LOW_LATENCY) 模式时，设备与接入点之间的平均往返延迟必须小于 Wi-Fi 高性能锁 (WIFI_MODE_FULL_HIGH_PERF) 模式期间的延迟。
  • [C-SR-3] 强烈建议在获取并生效低延迟锁 (WIFI_MODE_FULL_LOW_LATENCY) 时，尽量减少 Wi-Fi 往返延迟。

如果设备实现支持 Wi-Fi 并使用 Wi-Fi 进行位置扫描，则它们

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 操作。
  • [C-SR-1] 强烈建议为所有新形成的 Wi-Fi Direct 连接随机化源 MAC 地址。

设备实现

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

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

设备实现

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

  • [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 管理接口地址，除非正在进行 Aware 测距操作或 Aware 数据路径处于活动状态（只要数据路径处于活动状态，就不需要随机化）。

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

7.4.2.4. Wi-Fi Passpoint

如果设备实现包含对 802.11 (Wi-Fi) 的支持，则它们

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

  • [C-1-2] 必须实现 SDK 文档中描述的与 Passpoint 相关的 WifiManager API。
  • [C-1-3] 必须支持 IEEE 802.11u 标准，特别是与网络发现和选择相关的标准，例如通用广告服务 (GAS) 和接入网络查询协议 (ANQP)。
  • [C-1-4] 必须声明 android.hardware.wifi.passpoint 功能标志。
  • [C-1-5] 必须遵循 AOSP 实现来发现、匹配和关联到 Passpoint 网络。
  • [C-1-6] 必须至少支持 Wi-Fi Alliance Passpoint R2 中定义的设备配置协议的以下子集：EAP-TTLS 身份验证和 SOAP-XML。
  • [C-1-7] 必须按照 Hotspot 2.0 R3 规范处理 AAA 服务器证书。
  • [C-1-8] 必须支持用户通过 Wi-Fi 选择器控制配置。
  • [C-1-9] 必须使 Passpoint 配置在重启后保持持久性。
  • [C-SR-1] 强烈建议支持条款和条件接受功能。
  • [C-SR-2] 强烈建议支持场所信息功能。

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

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

如果提供了全局 Passpoint 禁用用户控制开关，则实现

  • [C-3-1] 必须默认启用 Passpoint。
7.4.2.5. Wi-Fi 定位（Wi-Fi 往返时间 - RTT）

设备实现

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

  • [C-1-1] 必须实现 SDK 文档中描述的 WifiRttManager API。
  • [C-1-2] 必须声明 android.hardware.wifi.rtt 功能标志。
  • [C-1-3] 必须为每次 RTT 突发随机化源 MAC 地址，当执行 RTT 的 Wi-Fi 接口未关联到接入点时执行该突发。
  • [C-1-4] 在 80 MHz 带宽下，在第 68 个百分位（使用累积分布函数计算）时，必须精确到 2 米以内。
7.4.2.6. Wi-Fi Keepalive Offload

设备实现

  • 应该包括对 Wi-Fi keepalive offload 的支持。

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

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

  • [C-1-2] 必须支持 Wi-Fi 上至少三个并发 keepalive 插槽，以及蜂窝网络上至少一个 keepalive 插槽。

如果设备实现不包含对 Wi-Fi keepalive offload 的支持，则它们

7.4.2.7. Wi-Fi Easy Connect（设备配置协议）

设备实现

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

7.4.2.8. 企业 Wi-Fi 服务器证书验证

如果未验证 Wi-Fi 服务器证书或未设置 Wi-Fi 服务器域名，则设备实现

  • [C-SR-1] 强烈建议不要为用户提供在“设置”应用中手动添加 企业 Wi-Fi 网络 的选项。

7.4.3. 蓝牙

如果设备实现支持蓝牙音频配置文件，则它们

  • 应该支持高级音频编解码器和蓝牙音频编解码器（例如 LDAC）。

如果设备实现支持 HFP、A2DP 和 AVRCP，则它们

  • 应该支持至少 5 个已连接设备的总数。

如果设备实现声明 android.hardware.vr.high_performance 功能，则它们

  • [C-1-1] 必须支持蓝牙 4.2 和蓝牙 LE 数据长度扩展。

Android 包括对 蓝牙和蓝牙低功耗 的支持。

如果设备实现包含对蓝牙和蓝牙低功耗的支持，则它们

  • [C-2-1] 必须声明相关的平台功能（分别是 android.hardware.bluetooth 和 android.hardware.bluetooth_le）并实现平台 API。
  • 应该根据设备酌情实现相关的蓝牙配置文件，例如 A2DP、AVRCP、OBEX、HFP 等。

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

  • [C-3-1] 必须声明硬件功能 android.hardware.bluetooth_le。
  • [C-3-2] 必须启用基于 GATT（通用属性配置文件）的蓝牙 API，如 SDK 文档和 android.bluetooth 中所述。
  • [C-3-3] 必须报告 BluetoothAdapter.isOffloadedFilteringSupported() 的正确值，以指示是否实现了 ScanFilter API 类的过滤逻辑。
  • [C-3-4] 必须报告 BluetoothAdapter.isMultipleAdvertisementSupported() 的正确值，以指示是否支持低功耗广播。
  • [C-3-5] 必须实现可解析私有地址 (RPA) 超时，超时时间不超过 15 分钟，并在超时时轮换地址，以在设备主动使用 BLE 进行扫描或广播时保护用户隐私。为了防止定时攻击，超时间隔也必须在 5 到 15 分钟之间随机化。
  • 在实现 ScanFilter API 时，应该支持将过滤逻辑卸载到蓝牙芯片组。
  • 应该支持将批量扫描卸载到蓝牙芯片组。
  • 应该支持至少 4 个插槽的多播广播。

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

  • [C-4-1] 必须提供用户操作界面来启用/禁用通过系统 API BluetoothAdapter.isBleScanAlwaysAvailable() 读取的值。

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

如果设备实现包含对蓝牙或蓝牙低功耗的支持，则它们

  • [C-6-1] 除非请求的应用成功通过基于其当前前台/后台状态的 android.permission.ACCESS_FINE_LOCATION 权限检查，否则必须限制对任何蓝牙元数据（例如扫描结果）的访问，这些元数据可能用于推断设备的位置。

如果设备实现包含对蓝牙或蓝牙低功耗的支持，并且应用清单不包含来自开发者的声明，声明他们并非从蓝牙推断位置，那么，它们

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 论坛定义）

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

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

  • 当设备唤醒且屏幕处于活动状态且锁屏已解锁时，应该处于 NFC 发现模式。

  • 应该能够读取 Thinfilm NFC Barcode 产品的条形码和 URL（如果已编码）。

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

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

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

  • [C-2-1] 必须报告 android.hardware.nfc.hce 功能常量。
  • [C-2-2] 必须支持 Android SDK 中定义的 NFC HCE API。

如果设备实现包含能够进行 NfcF 的 HCE 的 NFC 控制器芯片组，并为第三方应用程序实现该功能，则它们

  • [C-3-1] 必须报告 android.hardware.nfc.hcef 功能常量。
  • [C-3-2] 必须实现 Android SDK 中定义的 NfcF 卡模拟 API。

如果设备实现包含本节中描述的通用 NFC 支持，并且在读取器/写入器角色中支持 MIFARE 技术（MIFARE Classic、MIFARE Ultralight、NDEF on MIFARE Classic），则它们

  • [C-4-1] 必须实现 Android SDK 文档中记录的相应 Android API。
  • [C-4-2] 必须从 android.content.pm.PackageManager.hasSystemFeature() 方法报告 com.nxp.mifare 功能。请注意，这不是标准的 Android 功能，因此不会作为常量出现在 android.content.pm.PackageManager 类中。

7.4.5. 网络协议和 API

7.4.5.1. 最低网络能力

设备实现

  • [C-0-1] 必须包含对一种或多种形式的数据网络的支持。具体而言，设备实现必须包含对至少一种能够达到 200 Kbit/秒或更高速度的数据标准的支持。满足此要求的技术示例包括 EDGE、HSPA、EV-DO、802.11g、以太网和蓝牙 PAN。
  • 当物理网络标准（例如以太网）是主要数据连接时，还应该包括对至少一种常见的无线数据标准（例如 802.11 (Wi-Fi)）的支持。
  • 可以实现多种形式的数据连接。
7.4.5.2. IPv6

设备实现

  • [C-0-2] 必须包含 IPv6 网络堆栈，并支持使用托管 API（例如 java.net.Socket 和 java.net.URLConnection）以及本机 API（例如 AF_INET6 套接字）的 IPv6 通信。
  • [C-0-3] 必须默认启用 IPv6。
    • 必须确保 IPv6 通信与 IPv4 一样可靠，例如
      • [C-0-4] 必须在打盹模式下保持 IPv6 连接。
      • [C-0-5] 速率限制绝不能导致设备在任何使用 RA 生存期至少为 180 秒的 IPv6 兼容网络上丢失 IPv6 连接。
  • [C-0-6] 当连接到 IPv6 网络时，必须为第三方应用程序提供到网络的直接 IPv6 连接，而无需在设备本地进行任何形式的地址或端口转换。托管 API（例如 Socket#getLocalAddress 或 Socket#getLocalPort）和 NDK API（例如 getsockname() 或 IPV6_PKTINFO）都必须返回实际用于在网络上发送和接收数据包的 IP 地址和端口，并且在互联网（Web）服务器上可见为源 IP 和端口。

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

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

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

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

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

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

  • [C-3-1] 必须支持蜂窝网络上的 IPv6 操作（仅 IPv6 和可能的双栈）。

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

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

强制门户是指需要登录才能获得互联网访问权限的网络。

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

  • [C-1-1] 必须提供一个强制门户应用程序来处理 intent ACTION_CAPTIVE_PORTAL_SIGN_IN，并通过在调用系统 API ConnectivityManager#startCaptivePortalApp(Network, Bundle) 时发送该 intent 来显示强制门户登录页面。
  • [C-1-2] 当设备连接到任何网络类型（包括蜂窝/移动网络、WiFi、以太网或蓝牙）时，必须执行强制门户检测并支持通过强制门户应用程序登录。
  • [C-1-3] 当设备配置为使用私有 DNS 严格模式时，必须支持使用明文 DNS 登录到强制门户。
  • [C-1-4] 必须按照 SDK 文档的规定，对所有非显式与强制门户通信的网络流量使用加密 DNS，具体请参考 android.net.LinkProperties.getPrivateDnsServerName 和 android.net.LinkProperties.isPrivateDnsActive。
  • [C-1-5] 必须确保在用户登录强制门户期间，应用程序使用的默认网络（由 ConnectivityManager.getActiveNetwork, ConnectivityManager.registerDefaultNetworkCallback 返回，并默认由 Java 网络 API（如 java.net.Socket）和原生 API（如 connect()）使用）是任何其他可用的、可提供互联网访问的网络（如果可用）。

7.4.6. 同步设置

设备实现

7.4.7. 流量节省程序

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

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

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

  • [C-1-1] 必须支持 ConnectivityManager 类中的所有 API，如 SDK 文档中所述

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

7.4.8. 安全元素

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

7.5. 摄像头

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

7.5.1. 后置摄像头

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

设备实现

  • 应该包含后置摄像头。

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

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

如果摄像头包含闪光灯

  • [C-2-1] 在 android.hardware.Camera.PreviewCallback 实例已在 Camera 预览 Surface 上注册时，闪光灯不得亮起，除非应用通过启用 Camera.Parameters 对象的 FLASH_MODE_AUTO 或 FLASH_MODE_ON 属性显式启用了闪光灯。请注意，此约束不适用于设备的内置系统摄像头应用，而仅适用于使用 Camera.PreviewCallback 的第三方应用。

7.5.2. 前置摄像头

前置摄像头是位于设备显示屏同一侧的摄像头；也就是说，它通常用于拍摄用户图像，例如用于视频会议和类似应用。

设备实现

  • 可以包含前置摄像头。

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

  • [C-1-1] 必须报告特性标志 android.hardware.camera.any 和 android.hardware.camera.front。
  • [C-1-2] 必须具有至少 VGA (640x480 像素) 的分辨率。
  • [C-1-3] 不得将前置摄像头用作 Camera API 的默认摄像头，也不得将 API 配置为将前置摄像头视为默认后置摄像头，即使它是设备上唯一的摄像头。
  • [C-1-4] 当当前应用已通过调用 android.hardware.Camera.setDisplayOrientation() 方法显式请求旋转摄像头显示时，摄像头预览必须相对于应用指定的方向水平镜像。相反，当当前应用未通过调用 android.hardware.Camera.setDisplayOrientation() 方法显式请求旋转摄像头显示时，预览必须沿设备的默认水平轴镜像。
  • [C-1-5] 不得镜像返回到应用回调或提交到媒体存储的最终捕获的静止图像或视频流。
  • [C-1-6] 必须以与摄像头预览图像流相同的方式镜像后视图显示的图像。
  • 可以包含后置摄像头可用的功能（例如自动对焦、闪光灯等），如第 7.5.1 节中所述。

如果设备实现能够由用户旋转（例如通过加速度计自动旋转或通过用户输入手动旋转）

  • [C-2-1] 摄像头预览必须相对于设备的当前方向水平镜像。

7.5.3. 外部摄像头

设备实现

  • 可以包含对不一定始终连接的外部摄像头的支持。

如果设备实现包含对外部摄像头的支持，则

  • [C-1-1] 必须声明平台特性标志 android.hardware.camera.external 和 android.hardware camera.any。
  • [C-1-2] 如果外部摄像头通过 USB 主机端口连接，则必须支持 USB 视频类 (UVC 1.0 或更高版本)。
  • [C-1-3] 必须通过连接物理外部摄像头设备的摄像头 CTS 测试。摄像头 CTS 测试的详细信息可在 source.android.com 上找到。
  • 应该支持 MJPEG 等视频压缩，以实现高质量未编码流（即原始或独立压缩的图片流）的传输。
  • 可以支持多个摄像头。
  • 可以支持基于摄像头的视频编码。

如果支持基于摄像头的视频编码

  • [C-2-1] 设备实现必须能够访问同步的未编码/MJPEG 流（QVGA 或更高分辨率）。

7.5.4. 摄像头 API 行为

Android 包括两个 API 包来访问摄像头，较新的 android.hardware.camera2 API 向应用公开较低级别的摄像头控制，包括高效的零拷贝突发/流式传输流以及曝光、增益、白平衡增益、色彩转换、去噪、锐化等逐帧控制。

较旧的 API 包 android.hardware.Camera 在 Android 5.0 中被标记为已弃用，但仍应可供应用使用。Android 设备实现必须确保继续支持该 API，如本节和 Android SDK 中所述。

在已弃用的 android.hardware.Camera 类和较新的 android.hardware.camera2 包之间通用的所有功能，在这两个 API 中必须具有相同的性能和质量。例如，在同等设置下，自动对焦速度和准确度必须相同，并且捕获的图像质量必须相同。依赖于两个 API 的不同语义的功能不需要具有匹配的速度或质量，但应该尽可能接近。

设备实现必须为所有可用摄像头实现与摄像头相关的 API 的以下行为。设备实现

  • [C-0-1] 当应用从未调用 android.hardware.Camera.Parameters.setPreviewFormat(int) 时，必须使用 android.hardware.PixelFormat.YCbCr_420_SP 作为提供给应用回调的预览数据。
  • [C-0-2] 当应用注册 android.hardware.Camera.PreviewCallback 实例并且系统调用 onPreviewFrame() 方法，且预览格式为 YCbCr_420_SP 时，onPreviewFrame() 中传递的 byte[] 中的数据必须进一步采用 NV21 编码格式。也就是说，NV21 必须是默认格式。
  • [C-0-3] 必须支持 YV12 格式（由 android.graphics.ImageFormat.YV12 常量表示），以便 android.hardware.Camera 的前置和后置摄像头进行摄像头预览。（硬件视频编码器和摄像头可以使用任何原生像素格式，但设备实现必须支持转换为 YV12。）
  • [C-0-4] 必须支持 android.hardware.ImageFormat.YUV_420_888 和 android.hardware.ImageFormat.JPEG 格式，作为通过 android.media.ImageReader API 为 android.hardware.camera2 设备提供的输出，这些设备在 android.request.availableCapabilities 中声明了 REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE 功能。
  • [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 上记录为常量。也就是说，如果硬件允许，设备实现必须支持所有标准 Camera 参数，并且不得支持自定义 Camera 参数类型。例如，支持使用高动态范围 (HDR) 成像技术捕获图像的设备实现必须支持摄像头参数 Camera.SCENE_MODE_HDR。
  • [C-0-7] 必须使用 android.info.supportedHardwareLevel 属性报告适当的支持级别，如 Android SDK 中所述，并报告相应的 框架特性标志。
  • [C-0-8] 还必须通过 android.request.availableCapabilities 属性声明其 android.hardware.camera2 的各个摄像头功能，并声明相应的 特性标志；如果其任何连接的摄像头设备支持该功能，则必须定义该特性标志。
  • [C-0-9] 每当摄像头拍摄新照片且照片条目已添加到媒体存储时，必须广播 Camera.ACTION_NEW_PICTURE intent。
  • [C-0-10] 每当摄像头录制新视频且视频条目已添加到媒体存储时，必须广播 Camera.ACTION_NEW_VIDEO intent。
  • [C-0-11] 必须使通过已弃用的 android.hardware.Camera API 访问的所有摄像头也可通过 android.hardware.camera2 API 访问。
  • [C-0-12] 必须确保对于任何 android.hardware.camera2 或 android.hardware.Camera API，面部外观不得被更改，包括但不限于更改面部几何形状、面部肤色或面部皮肤平滑度。
  • [C-SR-1] 对于具有多个朝向同一方向的 RGB 摄像头的设备，强烈建议支持逻辑摄像头设备，该设备列出功能 CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA，其中包含朝向该方向的所有 RGB 摄像头作为物理子设备。

如果设备实现向第三方应用提供专有摄像头 API，则

7.5.5. 摄像头方向

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

  • [C-1-1] 必须定向，使摄像头的长尺寸与屏幕的长尺寸对齐。也就是说，当设备以横向方向握持时，摄像头必须以横向方向捕获图像。这适用于设备的自然方向，也就是说，它既适用于横向主设备，也适用于纵向主设备。

满足以下所有条件的设备可免除上述要求

  • 设备实现可变几何形状屏幕，例如可折叠或铰链式显示屏。
  • 当设备的折叠或铰链状态改变时，设备在纵向主方向和横向主方向之间切换（或反之亦然）。

7.6. 内存和存储

7.6.1. 最低内存和存储空间

设备实现

  • [C-0-1] 必须包含 下载管理器，应用可以使用该管理器下载数据文件，并且它们必须能够将至少 100MB 大小的单个文件下载到默认 “缓存” 位置。

7.6.2. 应用共享存储空间

设备实现

  • [C-0-1] 必须提供存储空间供应用共享，通常也称为 “共享外部存储空间”、“应用共享存储空间” 或其挂载的 Linux 路径 “/sdcard”。
  • [C-0-2] 必须配置为默认情况下挂载共享存储空间，换句话说，即 “开箱即用”，无论存储空间是在内部存储组件还是可移动存储介质（例如安全数字卡插槽）上实现的。
  • [C-0-3] 必须将应用共享存储空间直接挂载在 Linux 路径 sdcard 上，或包含从 sdcard 到实际挂载点的 Linux 符号链接。
  • [C-0-4] 必须默认对所有面向 API 级别 29 或更高级别的应用启用 分区存储，但在以下情况下除外
    • 当应用在其清单中请求 android:requestLegacyExternalStorage="true" 时。
  • [C-0-5] 当通过 MediaStore 访问媒体文件时，必须编辑存储在媒体文件中的位置元数据（例如 GPS Exif 标记），除非调用应用持有 ACCESS_MEDIA_LOCATION 权限。

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

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

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

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

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

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

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

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

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

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

7.6.3. 可采纳的存储空间

如果设备预计具有移动性（与电视不同），则设备实现

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

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

7.7. USB

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

  • 应该支持 USB 外围设备模式，并且应该支持 USB 主机模式。
  • 应该支持禁用通过 USB 的数据信令。

7.7.1. USB 外围设备模式

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

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

如果设备实现包含支持主机模式和 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 访问。

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

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

7.8. 音频

7.8.1. 麦克风

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

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

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

  • [C-2-1] 不得报告 android.hardware.microphone 特性常量。
  • [C-2-2] 必须至少将音频录制 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 节中的音频延迟要求。
  • [C-SR-1] 强烈建议支持近超声播放，如第 7.8.3 节中所述。

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

  • [C-2-1] 不得报告 android.hardware.audio.output 特性。
  • [C-2-2] 必须至少将音频输出相关 API 实现为无操作。

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

7.8.2.1. 模拟音频端口

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

  • [C-SR-1] 强烈建议至少包含一个音频端口为 4 导体 3.5 毫米音频插孔。

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

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

如果设备实现具有 4 导体 3.5 毫米音频插孔并支持麦克风，并且广播 android.intent.action.HEADSET_PLUG，并将额外值 microphone 设置为 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 频段。

设备实现

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

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

如果 PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND 为 “true”

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

7.8.4. 信号完整性

设备实现

  • 对于手持设备上的输入和输出流，应该提供无故障音频信号路径，定义为每个路径一分钟的测试期间测得的零故障。使用 OboeTester “自动故障测试” 进行测试。

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

OboeTester 目前支持 AAudio 路径，因此应该使用 AAudio 测试以下组合的故障

性能模式共享输出采样率输入通道输出通道
LOW_LATENCY EXCLUSIVE UNSPECIFIED 1 2
LOW_LATENCY EXCLUSIVE UNSPECIFIED 2 1
LOW_LATENCY SHARED UNSPECIFIED 1 2
LOW_LATENCY SHARED UNSPECIFIED 2 1
NONE SHARED 48000 1 2
NONE SHARED 48000 2 1
NONE SHARED 44100 1 2
NONE SHARED 44100 2 1
NONE SHARED 16000 1 2
NONE SHARED 16000 2 1

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

传感器 THD SNR
主内置扬声器，使用外部参考麦克风进行测量 < 3.0% >= 50 分贝
主内置麦克风，使用外部参考扬声器进行测量 < 3.0% >= 50 分贝
内置模拟 3.5 毫米插孔，使用环回适配器进行测试 < 1% >= 60 分贝
手机随附的 USB 适配器，使用环回适配器进行测试 < 1.0% >= 60 分贝

7.9. 虚拟现实

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

7.9.1. 虚拟现实模式

Android 包含对 VR 模式的支持，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_EXT_protected_textures，并在可用 GL 扩展列表中公开这些扩展。
  • [C-SR-1] 强烈建议实现 GL_EXT_external_buffer、GL_EXT_EGL_image_array、GL_OVR_multiview_multisampled_render_to_texture，并在可用 GL 扩展列表中公开这些扩展。
  • [C-SR-2] 强烈建议支持 Vulkan 1.1。
  • [C-SR-3] 强烈建议实现 VK_ANDROID_external_memory_android_hardware_buffer、VK_GOOGLE_display_timing、VK_KHR_shared_presentable_image，并在可用 Vulkan 扩展列表中公开它。
  • [C-SR-4] 强烈建议公开至少一个 Vulkan 队列族，其中 flags 同时包含 VK_QUEUE_GRAPHICS_BIT 和 VK_QUEUE_COMPUTE_BIT，并且 queueCount 至少为 2。
  • [C-1-7] GPU 和显示屏必须能够同步对共享前缓冲区的访问，以便在两个渲染上下文中以 60fps 速率交替眼睛渲染 VR 内容时，不会出现明显的撕裂伪影。
  • [C-1-9] 必须实现对 NDK 中描述的 AHardwareBuffer 标志 AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER、AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA 和 AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT 的支持。
  • [C-1-10] 必须实现对 AHardwareBuffer 的支持，这些 AHardwareBuffer 具有 AHARDWAREBUFFER_USAGE_GPU_COLOR_OUTPUT、AHARDWAREBUFFER_USAGE_GPU_SAMPLED_IMAGE、AHARDWAREBUFFER_USAGE_PROTECTED_CONTENT 用途标志的任意组合，至少对于以下格式：AHARDWAREBUFFER_FORMAT_R5G6B5_UNORM、AHARDWAREBUFFER_FORMAT_R8G8B8A8_UNORM、AHARDWAREBUFFER_FORMAT_R10G10B10A2_UNORM、AHARDWAREBUFFER_FORMAT_R16G16B16A16_FLOAT。
  • [C-SR-5] 强烈建议支持分配具有多个图层以及 C-1-10 中指定的标志和格式的 AHardwareBuffer。
  • [C-1-11] 必须支持 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-6] 强烈建议显示分辨率至少为 2560 x 1440。
  • [C-1-15] 显示屏在 VR 模式下必须至少以 60 Hz 的频率更新。
  • [C-1-17] 显示屏必须支持低余晖模式，余晖 ≤ 5 毫秒，余晖定义为像素发光的时间量。
  • [C-1-18] 必须支持 Bluetooth 4.2 和 Bluetooth LE 数据长度扩展 第 7.4.3 节。
  • [C-1-19] 必须支持并正确报告以下所有默认传感器类型的直接通道类型
    • TYPE_ACCELEROMETER
    • TYPE_ACCELEROMETER_UNCALIBRATED
    • TYPE_GYROSCOPE
    • TYPE_GYROSCOPE_UNCALIBRATED
    • TYPE_MAGNETIC_FIELD
    • TYPE_MAGNETIC_FIELD_UNCALIBRATED
  • [C-SR-7] 强烈建议为上面列出的所有直接通道类型支持 TYPE_HARDWARE_BUFFER 直接通道类型。
  • [C-1-21] 必须满足 第 7.3.9 节中指定的 android.hardware.hifi_sensors 的陀螺仪、加速度计和磁力计相关要求。
  • [C-SR-8] 强烈建议支持 android.hardware.sensor.hifi_sensors 功能。
  • [C-1-22] 必须具有不高于 28 毫秒的端到端运动到光子延迟。
  • [C-SR-9] 强烈建议具有不高于 20 毫秒的端到端运动到光子延迟。
  • [C-1-23] 必须具有第一帧比率，即从黑到白过渡后的第一帧像素亮度与稳态白像素亮度之间的比率，至少为 85%。
  • [C-SR-10] 强烈建议具有至少 90% 的第一帧比率。
  • 可以为前台应用程序提供独占核心，并且可以支持 Process.getExclusiveCores API 以返回专用于顶部前台应用程序的 CPU 核心编号。

如果支持独占核心，则该核心

  • [C-2-1] 必须不允许任何其他用户空间进程在其上运行（应用程序使用的设备驱动程序除外），但可以允许一些内核进程根据需要运行。

7.10. 触感

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

7.11. 媒体性能等级

设备实现的媒体性能等级可以从 android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS 中获得。媒体性能等级的要求是为每个 Android 版本定义的，从 R 版本（版本 30）开始。特殊值 0 表示设备不属于媒体性能等级。

如果设备实现为 android.os.Build.VERSION.MEDIA_PERFORMANCE_CLASS 返回非零值，则它们

  • [C-1-1] 必须至少返回值 android.os.Build.VERSION_CODES.R。

  • [C-1-2] 必须是手持设备实现。

  • [C-1-3] 必须满足 第 2.2.7 节中描述的“媒体性能等级”的所有要求。

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

8. 性能和功耗

一些最低性能和功耗标准对于用户体验至关重要，并且会影响开发人员在开发应用程序时所做的基线假设。

8.1. 用户体验一致性

如果有某些最低要求以确保应用程序和游戏的一致帧速率和响应时间，则可以为最终用户提供流畅的用户界面。设备实现可以根据设备类型，对用户界面延迟和任务切换具有可衡量的要求，如 第 2 节中所述。

8.2. 文件 I/O 访问性能

在应用程序私有数据存储 (/data 分区) 上为一致的文件访问性能提供通用基线，使应用程序开发人员能够设定适当的期望，这将有助于他们的软件设计。设备实现可以根据设备类型，对以下读取和写入操作具有 第 2 节中描述的某些要求

  • 顺序写入性能。通过使用 10MB 写入缓冲区写入 256MB 文件来测量。
  • 随机写入性能。通过使用 4KB 写入缓冲区写入 256MB 文件来测量。
  • 顺序读取性能。通过使用 10MB 写入缓冲区读取 256MB 文件来测量。
  • 随机读取性能。通过使用 4KB 写入缓冲区读取 256MB 文件来测量。

8.3. 节电模式

如果设备实现包含用于改进设备电源管理的 AOSP 中包含的功能（例如，应用待机模式分段、Doze 模式）或扩展这些功能以应用比 RESTRICTED 应用待机模式分段更严格的限制，则它们

  • [C-1-1] 对于应用待机模式和 Doze 节电模式的触发、维护、唤醒算法以及全局系统设置或 DeviceConfig 的使用，不得偏离 AOSP 实现。
  • [C-1-2] 对于使用全局设置或 DeviceConfig 管理应用待机模式下每个分段中应用的作业、警报和网络节流，不得偏离 AOSP 实现。
  • [C-1-3] 对于用于应用待机模式的 应用待机模式分段的数量，不得偏离 AOSP 实现。
  • [C-1-4] 必须实现 应用待机模式分段和 Doze 模式，如电源管理中所述。
  • [C-1-5] 当设备处于节电模式时，必须为 PowerManager.isPowerSaveMode() 返回 true。
  • [C-1-6] 必须提供用户界面，以显示所有从应用待机模式和 Doze 节电模式或任何电池优化中豁免的应用，并且必须实现 ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS intent，以请求用户允许应用忽略电池优化。
  • [C-SR-1] 强烈建议提供用户界面，以启用和禁用省电功能。
  • [C-SR-2] 强烈建议提供用户界面，以显示所有从应用待机模式和 Doze 节电模式中豁免的应用。

如果设备实现扩展了 AOSP 中包含的电源管理功能，并且该扩展应用了比 Rare 应用待机模式分段更严格的限制，请参阅 第 3.5.1 节。

除了节电模式外，Android 设备实现还可以实现高级配置和电源接口 (ACPI) 定义的 4 种睡眠电源状态中的任何一种或全部。

如果设备实现实现了 ACPI 定义的 S4 电源状态，则它们

  • [C-1-1] 必须仅在用户采取明确操作将设备置于非活动状态之后（例如，通过关闭设备物理部件的盖子或关闭车辆或电视），并在用户重新激活设备之前（例如，通过打开盖子或重新打开车辆或电视）进入此状态。

如果设备实现实现了 ACPI 定义的 S3 电源状态，则它们

  • [C-2-1] 必须满足上面的 C-1-1，或者，必须仅在第三方应用程序不需要系统资源（例如，屏幕、CPU）时才进入 S3 状态。

    相反，当第三方应用程序需要系统资源时，必须退出 S3 状态，如本 SDK 中所述。

    例如，当第三方应用程序请求通过 FLAG_KEEP_SCREEN_ON 保持屏幕开启或通过 PARTIAL_WAKE_LOCK 保持 CPU 运行时，设备不得进入 S3 状态，除非如 C-1-1 中所述，用户已采取明确操作将设备置于非活动状态。相反，当通过 JobScheduler 实现的第三方应用程序的任务被触发或 Firebase Cloud Messaging 传递给第三方应用程序时，设备必须退出 S3 状态，除非用户已将设备置于非活动状态。这些并非详尽的示例，AOSP 实现了广泛的唤醒信号，这些信号会触发从此状态唤醒。

8.4. 功耗核算

更准确的功耗核算和报告为应用程序开发人员提供了优化应用程序功耗模式的激励和工具。

设备实现

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

8.5. 一致的性能

对于高性能长时间运行的应用程序，性能可能会大幅波动，这可能是由于在后台运行的其他应用程序或由于温度限制导致的 CPU 节流。Android 包含编程接口，以便在设备有能力时，顶部前台应用程序可以请求系统优化资源分配以解决此类波动。

设备实现

如果设备实现报告支持持续性能模式，则它们

  • [C-1-1] 当应用程序请求时，必须为顶部前台应用程序提供至少 30 分钟的一致性能水平。
  • [C-1-2] 必须遵守 Window.setSustainedPerformanceMode() API 和其他相关 API。

如果设备实现包含两个或更多 CPU 核心，则它们

  • 应该提供至少一个独占核心，该核心可以由顶部前台应用程序保留。

如果设备实现支持为顶部前台应用程序保留一个独占核心，则它们

  • [C-2-1] 必须通过 Process.getExclusiveCores() API 方法报告可以由顶部前台应用程序保留的独占核心的 ID 编号。
  • [C-2-2] 必须不允许任何用户空间进程（应用程序使用的设备驱动程序除外）在独占核心上运行，但可以允许一些内核进程根据需要运行。

如果设备实现不支持独占核心，则它们

9. 安全模型兼容性

设备实现

  • [C-0-1] 必须实现与 Android 平台安全模型一致的安全模型，如 Android 开发人员文档中安全和权限参考文档中的 API 所定义。

  • [C-0-2] 必须支持安装自签名应用程序，而无需来自任何第三方/机构的任何其他权限/证书。

如果设备实现声明了 android.hardware.security.model.compatible 功能，则它们

  • [C-1-1] 必须支持以下小节中列出的要求。

9.1. 权限

设备实现

  • [C-0-1] 必须支持 Android 权限模型和 Android 角色模型，如 Android 开发人员文档中所定义。具体而言，它们必须强制执行 SDK 文档中描述的每个权限和角色；不得省略、更改或忽略任何权限和角色。

  • 可以添加其他权限，前提是新的权限 ID 字符串不在 android.\* 命名空间中。

  • [C-0-2] PROTECTION_FLAG_PRIVILEGED 的 protectionLevel 的权限必须仅授予预安装在系统映像的特权路径和每个应用程序的显式允许列表权限子集中的应用程序。AOSP 实现通过从 etc/permissions/ 路径中的文件中读取并遵守每个应用程序的允许列表权限，并将 system/priv-app 路径用作特权路径来满足此要求。

保护级别为危险的权限是运行时权限。 targetSdkVersion > 22 的应用程序在运行时请求它们。

设备实现

  • [C-0-3] 必须显示专用界面，供用户决定是否授予请求的运行时权限，并提供界面供用户管理运行时权限。
  • [C-0-4] 必须只有一个用户界面的实现。
  • [C-0-5] 除非满足以下条件，否则不得向预安装的应用程序授予任何运行时权限
    • 在应用程序使用运行时权限之前，可以获得用户的同意。
    • 运行时权限与预安装的应用程序设置为默认处理程序的 intent 模式相关联。
  • [C-0-6] 必须仅向注册了正确保护的恢复代理的系统应用程序授予 android.permission.RECOVER_KEYSTORE 权限。正确保护的恢复代理定义为与设备外远程存储同步的设备上软件代理，该代理配备了安全硬件，其保护级别等同于或高于 Google Cloud Key Vault Service 中描述的级别，以防止对锁屏知识因素的暴力攻击。

设备实现

  • [C-0-7] 当应用程序通过标准 Android API 或专有机制请求位置或身体活动数据时，必须遵守 Android 位置权限属性。此类数据包括但不限于

    • 设备的位置（例如，纬度和经度），如第 9.8.8 节中所述。
    • 可用于确定或估计设备位置的信息（例如，SSID、BSSID、小区 ID 或设备连接到的网络位置）。
    • 用户的身体活动或身体活动分类。

更具体地说，设备实现

  • [C-0-8] 必须获得用户同意，以允许应用程序访问位置或身体活动数据。
  • [C-0-9] 必须仅向持有 SDK 中描述的足够权限的应用程序授予运行时权限。例如，TelephonyManager#getServiceState 需要 android.permission.ACCESS_FINE_LOCATION。

上述 Android 位置权限属性的唯一例外是对于未访问位置以推导或识别用户位置的应用程序；具体而言

  • 当应用程序持有 RADIO_SCAN_WITHOUT_LOCATION 权限时。
  • 对于设备配置和设置目的，系统应用程序持有 NETWORK_SETTINGS 或 NETWORK_SETUP_WIZARD 权限。

权限可以标记为受限，从而改变其行为。

  • [C-0-10] 标记有 hardRestricted 标志的权限不得授予应用程序，除非

    • 应用程序 APK 文件位于系统分区中。
    • 用户将与 hardRestricted 权限关联的角色分配给应用程序。
    • 安装程序将 hardRestricted 授予应用程序。
    • 应用程序在较早的 Android 版本上被授予 hardRestricted。

  • [C-0-11] 持有 softRestricted 权限的应用程序必须仅获得有限的访问权限，并且在 SDK 中描述的允许列表之前不得获得完全访问权限，其中为每个 softRestricted 权限定义了完全访问权限和有限访问权限（例如，READ_EXTERNAL_STORAGE）。

  • [C-0-12] 不得提供任何自定义功能或 API 来绕过 setPermissionPolicy 和 setPermissionGrantState API 中定义的权限限制。

  • [C-0-13] 必须使用 AppOpsManager API 来记录和跟踪来自 Android 活动和服务的数据的每次程序化访问，这些数据受 Android 危险权限保护。

  • [C-0-14] 必须仅将角色分配给具有满足角色要求的功能的应用程序。

  • [C-0-15] 不得定义与平台定义的角色重复或超集功能的角色。

如果设备报告 android.software.managed_users，则它们

  • [C-1-1] 不得静默授予管理员以下权限
    • 位置（ACCESS_BACKGROUND_LOCATION、ACCESS_COARSE_LOCATION、ACCESS_FINE_LOCATION）。
    • 相机 (CAMERA)
    • 麦克风 (RECORD_AUDIO)
    • 身体传感器 (BODY_SENSORS)
    • 身体活动 (ACTIVITY_RECOGNITION)

如果设备实现提供了用户界面来选择哪些应用程序可以使用处理 ACTION_MANAGE_OVERLAY_PERMISSION intent 的 activity 在其他应用程序之上绘图，则它们

  • [C-2-1] 必须确保所有具有 ACTION_MANAGE_OVERLAY_PERMISSION intent 的 intent 过滤器的 activity 都具有相同的 UI 屏幕，无论启动应用程序或其提供的任何信息如何。

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

  • [C-3-1] 必须在完全托管设备设置（设备所有者设置）期间显示免责声明，声明 IT 管理员将有权允许应用程序控制手机上的设置，包括麦克风、相机和位置，并提供用户继续设置或退出设置的选项，除非管理员选择不控制设备上的权限。

如果设备实现预安装了持有 System UI Intelligence、System Ambient Audio Intelligence、System Audio Intelligence、System Notification Intelligence、System Text Intelligence 或 System Visual Intelligence 角色中的任何一个角色的任何软件包，则这些软件包

  • [C-4-1] 必须满足“9.8.6 内容捕获”节中为设备实现概述的所有要求。
  • [C-4-2] 不得具有 android.permission.INTERNET 权限。这比 9.8.6 节中列出的强烈建议更严格。
  • [C-4-3] 不得绑定到其他应用程序，但以下系统应用程序除外：蓝牙、联系人、媒体、电话、SystemUI 以及提供 Internet API 的组件。这比 9.8.6 节中列出的强烈建议更严格。

9.2. UID 和进程隔离

设备实现

  • [C-0-1] 必须支持 Android 应用程序沙盒模型，其中每个应用程序都作为唯一的 Unix 风格 UID 并在单独的进程中运行。
  • [C-0-2] 必须支持以相同的 Linux 用户 ID 运行多个应用程序，前提是这些应用程序已正确签名和构造，如安全和权限参考中所定义。

9.3. 文件系统权限

设备实现

9.4. 备用执行环境

即使设备实现包含使用 Dalvik 可执行格式或本机代码以外的其他软件或技术执行应用程序的运行时环境，设备实现也必须保持 Android 安全和权限模型的一致性。换句话说

  • [C-0-1] 备用运行时本身必须是 Android 应用程序，并遵守标准的 Android 安全模型，如 第 9 节中的其他地方所述。

  • [C-0-2] 不得授予备用运行时访问权限，以访问受运行时 AndroidManifest.xml 文件中未通过 <uses-permission> 机制请求的权限保护的资源。

  • [C-0-3] 备用运行时不得允许应用程序使用受限于系统应用程序的 Android 权限保护的功能。

  • [C-0-4] 备用运行时必须遵守 Android 沙盒模型，并且使用备用运行时安装的应用程序不得重用设备上安装的任何其他应用程序的沙盒，除非通过共享用户 ID 和签名证书的标准 Android 机制。

  • [C-0-5] 不得启动备用运行时，不得授予其访问权限，也不得授予其他应用程序访问权限，以访问与其他 Android 应用程序对应的沙盒。

  • [C-0-6] 不得使用超级用户 (root) 或任何其他用户 ID 的任何权限启动备用运行时，不得授予其权限，也不得将其授予其他应用程序。

  • [C-0-7] 当备用运行时的 .apk 文件包含在设备实现的系统映像中时，它必须使用与用于对设备实现中包含的其他应用程序进行签名的密钥不同的密钥进行签名。

  • [C-0-8] 安装应用程序时，备用运行时必须获得用户对应用程序使用的 Android 权限的同意。

  • [C-0-9] 当应用程序需要使用设备资源（其具有相应的 Android 权限，例如相机、GPS 等）时，备用运行时必须告知用户应用程序将能够访问该资源。

  • [C-0-10] 当运行时环境未以这种方式记录应用程序功能时，运行时环境必须在安装使用该运行时的任何应用程序时列出运行时本身拥有的所有权限。

  • 备用运行时应通过 PackageManager 将应用程序安装到单独的 Android 沙盒（Linux 用户 ID 等）中。

  • 备用运行时可以提供由使用备用运行时的所有应用程序共享的单个 Android 沙盒。

9.5. 多用户支持

Android 包含对多用户的支持，并提供对完全用户隔离和具有部分隔离的克隆用户配置文件（即 android.os.usertype.profile.CLONE 类型的单个附加用户配置文件）的支持。

  • 如果设备实现使用可移动媒体作为主要外部存储，则设备实现可以启用多用户，但不应启用。

如果设备实现包含对多用户的支持，则它们

  • [C-1-2] 对于每个用户，必须实现与 Android 平台安全模型一致的安全模型，如 API 中安全和权限参考文档中所定义。
  • [C-1-3] 必须为每个用户实例提供单独且隔离的共享应用程序存储（又名 /sdcard）目录。
  • [C-1-4] 必须确保由给定用户拥有并代表该用户运行的应用程序无法列出、读取或写入任何其他用户拥有的文件，即使两个用户的数据都存储在同一卷或文件系统上。
  • [C-1-5] 如果设备实现使用可移动介质进行外部存储 API，则当启用多用户时，必须使用仅存储在仅系统可访问的非可移动介质上的密钥来加密 SD 卡的内容。由于这将使主机 PC 无法读取介质，因此设备实现将需要切换到 MTP 或类似的系统，以便为主机 PC 提供对当前用户数据的访问。

如果设备实现包含对多用户的支持，那么对于所有用户（专门为运行同一应用程序的双实例而创建的用户除外），他们

  • [C-2-1] 必须为每个用户实例提供单独且隔离的共享应用程序存储（也称为 /sdcard）目录。
  • [C-2-2] 必须确保由给定用户拥有并代表该用户运行的应用程序无法列出、读取或写入任何其他用户拥有的文件，即使两个用户的数据都存储在同一卷或文件系统上。

设备实现可以针对主要用户（且仅针对主要用户）创建一个类型为 android.os.usertype.profile.CLONE 的额外用户配置文件，用于运行同一应用程序的双实例。这些双实例共享部分隔离的存储，同时在启动器中呈现给最终用户，并出现在同一最近使用视图中。例如，这可以用于支持用户在双 SIM 卡设备上安装单个应用程序的两个单独实例。

如果设备实现创建了上述额外的用户配置文件，那么他们

  • [C-3-1] 必须仅提供对父用户配置文件已可访问的存储或数据的访问权限，或者此额外用户配置文件直接拥有的存储或数据。
  • [C-3-2] 不得将其作为工作配置文件。
  • [C-3-3] 必须隔离与父用户帐户的私有应用程序数据目录。
  • [C-3-4] 如果已配置设备所有者（请参阅第 3.9.1 节），则不得允许创建额外的用户配置文件，或者在不首先删除额外的用户配置文件的情况下允许配置设备所有者。

9.6. 高级短信警告

Android 包括对用户发出任何外发高级短信消息警告的支持。高级短信是发送到运营商注册的服务的短信，可能会向用户收取费用。

如果设备实现声明支持 android.hardware.telephony，他们

  • [C-1-1] 必须在向设备中 /data/misc/sms/codes.xml 文件中定义的正则表达式标识的号码发送短信消息之前警告用户。上游 Android 开源项目提供了一个满足此要求的实现。

9.7. 安全功能

设备实现必须确保内核和平台中安全功能的合规性，如下所述。

Android 沙箱包括使用 Security-Enhanced Linux (SELinux) 强制访问控制 (MAC) 系统、seccomp 沙箱以及 Linux 内核中的其他安全功能的功能。设备实现

  • [C-0-1] 即使在 Android 框架下实现了 SELinux 或任何其他安全功能，也必须保持与现有应用程序的兼容性。
  • [C-0-2] 当安全功能在 Android 框架下检测到并成功阻止安全违规时，不得具有可见的用户界面，但是当发生未阻止的安全违规导致成功利用时，可以具有可见的用户界面。
  • [C-0-3] 不得使用户或应用程序开发人员可以配置 SELinux 或在 Android 框架下实现的任何其他安全功能。
  • [C-0-4] 不得允许可以通过 API（例如设备管理 API）影响另一个应用程序的应用程序配置破坏兼容性的策略。
  • [C-0-5] 必须将媒体框架拆分为多个进程，以便可以更严格地授予每个进程的访问权限，如 Android 开源项目站点中的描述。
  • [C-0-6] 必须实现内核应用程序沙箱机制，该机制允许使用来自多线程程序的可配置策略过滤系统调用。上游 Android 开源项目通过启用 seccomp-BPF 与线程组同步 (TSYNC) 来满足此要求，如 source.android.com 的内核配置部分中所述。

内核完整性和自我保护功能是 Android 安全不可或缺的一部分。设备实现

  • [C-0-7] 必须实现内核堆栈缓冲区溢出保护机制。此类机制的示例包括 CC_STACKPROTECTOR_REGULAR 和 CONFIG_CC_STACKPROTECTOR_STRONG。
  • [C-0-8] 必须实现严格的内核内存保护，其中可执行代码是只读的，只读数据是不可执行且不可写的，可写数据是不可执行的（例如 CONFIG_DEBUG_RODATA 或 CONFIG_STRICT_KERNEL_RWX）。
  • [C-0-9] 必须在最初随 API 级别 28 或更高版本一起提供的设备上，实现用户空间和内核空间之间复制的静态和动态对象大小边界检查（例如 CONFIG_HARDENED_USERCOPY）。
  • [C-0-10] 在最初随 API 级别 28 或更高版本一起提供的设备上，在内核模式下执行时，不得执行用户空间内存（例如硬件 PXN，或通过 CONFIG_CPU_SW_DOMAIN_PAN 或 CONFIG_ARM64_SW_TTBR0_PAN 模拟）。
  • [C-0-11] 在最初随 API 级别 28 或更高版本一起提供的设备上，不得在内核中正常 usercopy 访问 API 之外读取或写入用户空间内存（例如硬件 PAN，或通过 CONFIG_CPU_SW_DOMAIN_PAN 或 CONFIG_ARM64_SW_TTBR0_PAN 模拟）。
  • [C-0-12] 如果硬件容易受到 CVE-2017-5754 的攻击，则必须在最初随 API 级别 28 或更高版本一起提供的所有设备上实现内核页表隔离（例如 CONFIG_PAGE_TABLE_ISOLATION 或 CONFIG_UNMAP_KERNEL_AT_EL0）。
  • [C-0-13] 如果硬件容易受到 CVE-2017-5715 的攻击，则必须在最初随 API 级别 28 或更高版本一起提供的所有设备上实现分支预测强化（例如 CONFIG_HARDEN_BRANCH_PREDICTOR）。
  • [C-SR-1] 强烈建议在初始化后将仅在初始化期间写入的内核数据标记为只读（例如 __ro_after_init）。

  • [C-SR-2] 强烈建议随机化内核代码和内存的布局，并避免会损害随机化的暴露（例如，通过 /chosen/kaslr-seed 设备树节点 或 EFI_RNG_PROTOCOL 的引导加载程序熵的 CONFIG_RANDOMIZE_BASE）。

  • [C-SR-3] 强烈建议在内核中启用控制流完整性 (CFI)，以提供针对代码重用攻击的额外保护（例如 CONFIG_CFI_CLANG 和 CONFIG_SHADOW_CALL_STACK）。

  • [C-SR-4] 强烈建议不要在已启用控制流完整性 (CFI)、影子调用堆栈 (SCS) 或整数溢出消毒 (IntSan) 的组件上禁用它们。

  • [C-SR-5] 强烈建议为任何其他安全敏感的用户空间组件启用 CFI、SCS 和 IntSan，如 CFI 和 IntSan 中所述。

  • [C-SR-6] 强烈建议在内核中启用堆栈初始化，以防止使用未初始化的局部变量（CONFIG_INIT_STACK_ALL 或 CONFIG_INIT_STACK_ALL_ZERO）。此外，设备实现不应假设编译器用于初始化局部变量的值。

  • [C-SR-7] 强烈建议在内核中启用堆初始化，以防止使用未初始化的堆分配（CONFIG_INIT_ON_ALLOC_DEFAULT_ON），并且它们不应假设内核用于初始化这些分配的值。

如果设备实现使用的 Linux 内核能够支持 SELinux，他们

  • [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 策略，并且仅针对其自己的设备特定配置进一步添加到此策略。

如果设备实现使用的内核不是 Linux 或没有 SELinux 的 Linux，他们

  • [C-2-1] 必须使用等效于 SELinux 的强制访问控制系统。

如果设备实现使用能够 DMA 的 I/O 设备，他们

  • [C-SR-8] 强烈建议使用 IOMMU（例如 ARM SMMU）隔离每个能够 DMA 的 I/O 设备。

Android 包含多项深度防御功能，这些功能对于设备安全至关重要。此外，Android 专注于减少导致低质量和安全性的关键常见错误类别。

为了减少内存错误，设备实现

  • [C-SR-9] 强烈建议使用用户空间内存错误检测工具进行测试，例如 ARMv9 设备的 MTE、ARMv8+ 设备的 HWASan 或其他设备类型的 ASan。
  • [C-SR-10] 强烈建议使用内核内存错误检测工具进行测试，例如 KASAN（ARMv9 设备的 CONFIG_KASAN、CONFIG_KASAN_HW_TAGS、ARMv8 设备的 CONFIG_KASAN_SW_TAGS 或其他设备类型的 CONFIG_KASAN_GENERIC）。
  • [C-SR-11] 强烈建议在生产中使用内存错误检测工具，例如 MTE、GWP-ASan 和 KFENCE。

如果设备实现使用基于 Arm TrustZone 的 TEE，他们

  • [C-SR-12] 强烈建议在 Android 和 TEE 之间使用标准协议进行内存共享，例如 Armv8-A 的 Arm 固件框架 (FF-A)。
  • [C-SR-13] 强烈建议将受信任的应用程序限制为仅访问已通过上述协议显式共享给它们的内存。如果设备支持 Arm S-EL2 异常级别，则应由安全分区管理器强制执行此操作。否则，应由 TEE 操作系统强制执行此操作。

9.8. 隐私

9.8.1. 使用历史记录

Android 存储用户的选择历史记录，并通过 UsageStatsManager 管理此类历史记录。

设备实现

  • [C-0-1] 必须保留此类用户历史记录的合理保留期限。
  • [C-SR-1] 强烈建议保留 14 天的保留期限，这与 AOSP 实现中的默认配置相同。

Android 使用 StatsLog 标识符存储系统事件，并通过 StatsManager 和 IncidentManager 系统 API 管理此类历史记录。

设备实现

  • [C-0-2] 必须仅在系统 API 类 IncidentManager 创建的事件报告中包含标记为 DEST_AUTOMATIC 的字段。
  • [C-0-3] 不得使用系统事件标识符记录除 StatsLog SDK 文档中描述的事件以外的任何其他事件。如果记录了其他系统事件，它们可以使用 100,000 到 200,000 范围内的不同原子标识符。

9.8.2. 录制

设备实现

  • [C-0-1] 不得预加载或分发开箱即用的软件组件，这些组件在未经用户同意或没有明确的持续通知的情况下，将用户的私人信息（例如，击键、屏幕上显示的文本、错误报告）发送到设备外。
  • [C-0-2] 每当通过 MediaProjection 或专有 API 启用屏幕投射或屏幕录制时，必须显示并获得明确的用户同意，允许捕获用户屏幕上显示的任何敏感信息。不得为用户提供禁用未来显示用户同意的选项。
  • [C-0-3] 在启用屏幕投射或屏幕录制时，必须向用户显示持续通知。AOSP 通过在状态栏中显示持续通知图标来满足此要求。

如果设备实现包含系统中捕获屏幕上显示的内容和/或录制设备上播放的音频流的功能（通过系统 API ContentCaptureService 或 第 9.8.6 节内容捕获中描述的其他专有方式除外），他们

  • [C-1-1] 每当启用此功能并主动捕获/录制时，必须向用户显示持续通知。

如果设备实现包含开箱即用的组件，该组件能够录制环境音频和/或录制设备上播放的音频，以推断有关用户上下文的有用信息，他们

  • [C-2-1] 除非获得用户的明确同意，否则不得在持久性设备存储中存储或传输到设备外录制的原始音频或任何可以转换回原始音频或近似副本的格式。

“麦克风指示器”是指屏幕上的视图，该视图始终对用户可见且无法遮挡，用户理解为正在使用麦克风（通过独特的文本、颜色、图标或某种组合）。

“摄像头指示器”是指屏幕上的视图，该视图始终对用户可见且无法遮挡，用户理解为正在使用摄像头（通过独特的文本、颜色、图标或某种组合）。

在显示后的第一个一秒钟后，指示器可以进行视觉更改，例如变得更小，并且不需要像最初呈现和理解的那样显示。

麦克风指示器可以与主动显示的摄像头指示器合并，前提是文本、图标或颜色向用户指示麦克风使用已开始。

摄像头指示器可以与主动显示的麦克风指示器合并，前提是文本、图标或颜色向用户指示摄像头使用已开始。

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

  • [C-SR-1] 强烈建议在应用程序正在访问来自麦克风的音频数据时显示麦克风指示器，但仅当麦克风仅由 HotwordDetectionService、SOURCE_HOTWORD、ContentCaptureService 或第 9.1 节权限中 CDD 标识符为 [C-3-X] 的角色中调用的应用程序访问时除外。
  • [C-SR-2] 强烈建议显示从 PermissionManager.getIndicatorAppOpUsageData() 返回的最近和活动应用程序的列表，以及与它们关联的任何归因消息。
  • [C-SR-3] 强烈建议不要隐藏具有可见用户界面或直接用户交互的系统应用程序的麦克风指示器。

如果设备实现声明 android.hardware.camera.any，他们

  • [C-SR-4] 强烈建议在应用程序正在访问实时摄像头数据时显示摄像头指示器，但仅当摄像头仅由第 9.1 节权限中 CDD 标识符为 [C-3-X] 的角色中调用的应用程序访问时除外。
  • [C-SR-5] 强烈建议显示从 PermissionManager.getIndicatorAppOpUsageData() 返回的最近和活动应用程序的列表，以及与它们关联的任何归因消息。
  • [C-SR-6] 强烈建议不要隐藏具有可见用户界面或直接用户交互的系统应用程序的摄像头指示器。

9.8.3. 连接

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

  • [C-1-1] 必须在允许通过 USB 端口访问共享存储的内容之前，显示用户界面以征求用户的同意。

9.8.4. 网络流量

设备实现

  • [C-0-1] 必须预安装与上游 Android 开源项目中提供的系统信任的证书颁发机构 (CA) 存储相同的根证书。
  • [C-0-2] 必须出厂时附带一个空的用户根 CA 存储。
  • [C-0-3] 当添加用户根 CA 时，必须向用户显示警告，指示网络流量可能受到监控。

如果设备流量通过 VPN 路由，设备实现

  • [C-1-1] 必须向用户显示警告，指示以下任一项
    • 网络流量可能受到监控。
    • 网络流量正在通过提供 VPN 的特定 VPN 应用程序路由。

如果设备实现具有开箱即用默认启用的机制，该机制通过代理服务器或 VPN 网关路由网络数据流量（例如，预加载授予 android.permission.CONTROL_VPN 的 VPN 服务），他们

  • [C-2-1] 必须在启用该机制之前征求用户的同意，除非该 VPN 由设备策略控制器通过 DevicePolicyManager.setAlwaysOnVpnPackage() 启用，在这种情况下，用户无需提供单独的同意，但必须仅被通知。

如果设备实现实现了用户界面以切换第三方 VPN 应用程序的“始终开启 VPN”功能，他们

  • [C-3-1] 必须为不支持 AndroidManifest.xml 文件中始终开启 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、AugmentedAutofillService、AppSearchGlobalManager.query 或其他专有方式，支持设备实现捕获以下应用程序数据交互的机制（应用程序和用户之间）

  • 屏幕上渲染的文本和图形，包括但不限于通知和通过 AssistStructure API 获得的辅助数据。
  • 媒体数据，例如设备录制或播放的音频或视频。
  • 输入事件（例如，按键、鼠标、手势、语音、视频和辅助功能）。
  • 应用程序通过 内容捕获 API 或 AppSearchManager API 或类似功能的 Android 和专有 API 提供给系统的任何其他事件。
  • 通过 TextClassifier API 发送到系统 TextClassifier 的任何文本或其他数据，即发送到系统服务以理解文本的含义，以及基于文本生成预测的下一个操作。
  • 平台 AppSearch 实现索引的数据，包括但不限于文本、图形、媒体数据或其他类似数据。

如果设备实现捕获上述数据，他们

  • [C-1-1] 必须在设备中存储时加密所有此类数据。此加密可以使用 Android 基于文件的加密，或 Cipher SDK 中描述的 API 版本 26+ 中列出的任何密码。
  • [C-1-2] 不得使用 Android 备份方法或任何其他备份方法备份原始数据或加密数据。
  • [C-1-3] 必须仅使用隐私保护机制发送所有此类数据和设备日志。隐私保护机制定义为“那些仅允许聚合分析并防止将记录的事件或导出的结果与单个用户匹配的机制”，以防止任何按用户数据可内省（例如，使用差异隐私技术实现，例如 RAPPOR）。
  • [C-1-4] 不得将此类数据与设备上的任何用户身份（例如 Account）相关联，除非每次关联数据时都获得用户的明确同意。
  • [C-1-5] 不得与不遵循本节（9.8.6 内容捕获）中概述要求的其他 OS 组件共享此类数据，除非每次共享时都获得用户的明确同意。
  • [C-1-6] 必须提供用户界面，以擦除 ContentCaptureService 或专有方式收集的此类数据（如果数据以任何形式存储在设备上）。
  • [C-1-7] 必须提供用户界面，以选择不将通过 AppSearch 或专有方式收集的数据显示在 Android 平台（例如启动器）中。
  • [C-SR-1] 强烈建议不要请求 INTERNET 权限。
  • [C-SR-2] 强烈建议仅通过公开可用的开源实现支持的结构化 API 访问互联网。

如果设备实现包含实现系统 API ContentCaptureService、AppSearchManager.index 或任何专有服务（捕获上述数据）的服务，他们

  • [C-2-1] 不得允许用户使用用户可安装的应用程序或服务替换这些服务，并且必须仅允许预安装的服务捕获此类数据。
  • [C-2-2] 不得允许除预安装的服务机制以外的任何应用程序能够捕获此类数据。
  • [C-2-3] 必须提供用户界面以禁用这些服务。
  • [C-2-4] 不得省略用户界面以管理服务持有的 Android 权限，并遵循 第 9.1 节权限中描述的 Android 权限模型。

  • [C-SR-3] 强烈建议将这些服务与其他系统组件分开（例如，不绑定服务或共享进程 ID），以下组件除外

    • 电话、联系人、系统 UI 和媒体

Android 通过 SpeechRecognizer#onDeviceSpeechRecognizer() 提供在设备上执行语音识别的能力，而无需涉及网络。任何设备上 SpeechRecognizer 的实现都必须遵循本节中概述的策略。

9.8.7. 剪贴板访问

设备实现

  • [C-0-1] 除非应用程序是默认 IME 或当前具有焦点的应用程序，否则不得返回剪贴板上的剪切数据（例如，通过 ClipboardManager API）。

9.8.8. 位置

位置包括 Android 位置类中的信息（例如纬度、经度、海拔），以及可以转换为位置的标识符。位置可以精确到 DGPS（差分全球定位系统），也可以粗略到国家/地区级别的位置（例如国家/地区代码位置 - MCC - 移动国家/地区代码）。

以下是可以直接导出用户位置或可以转换为用户位置的位置类型列表。这不是一个全面的列表，但应用作示例说明位置可以直接或间接从何处导出

  • GPS/GNSS/DGPS/PPP
    • 全球定位解决方案或全球导航卫星系统或差分全球定位解决方案
    • 这还包括原始 GNSS 测量值和 GNSS 状态
      • 可以从原始 GNSS 测量值导出精细位置
  • 具有唯一标识符的无线技术，例如
    • Wi-Fi 接入点（MAC、BSSID、名称或 SSID）
    • 蓝牙/BLE（MAC、BSSID、名称或 SSID）
    • UWB（MAC、BSSID、名称或 SSID）
    • 蜂窝塔 ID（3G、4G、5G… 包括所有具有唯一标识符的未来蜂窝调制解调器技术）

作为主要参考点，请参阅需要 ACCESS_FINE_Location 或 ACCESS_COARSE_Location 权限的 Android API。

设备实现

  • [C-0-1] 未经用户明确同意或用户发起，不得打开/关闭设备位置设置和 Wi-Fi/蓝牙扫描设置。
  • [C-0-2] 必须向用户提供界面以访问位置相关信息，包括最近的位置请求、应用程序级别权限以及用于确定位置的 Wi-Fi/蓝牙扫描的使用情况。
  • [C-0-3] 必须确保使用紧急位置绕过 API [LocationRequest.setLocationSettingsIgnored()] 的应用程序是用户发起的紧急会话（例如拨打 911 或短信发送至 911）。但是，对于汽车，在检测到碰撞/事故的情况下，车辆可以发起紧急会话，而无需主动用户交互（例如，为了满足 eCall 要求）。
  • [C-0-4] 必须保留紧急位置绕过 API 绕过设备位置设置的能力，而无需更改设置。
  • [C-0-5] 必须在后台应用程序使用 [ACCESS_BACKGROUND_LOCATION] 权限访问其位置后，安排通知以提醒用户。

9.8.9. 已安装的应用程序

以 API 级别 30 或更高版本为目标的 Android 应用程序默认情况下无法查看有关其他已安装应用程序的详细信息（请参阅 Android SDK 文档中的软件包可见性）。

设备实现

  • [C-0-1] 不得向任何以 API 级别 30 或更高版本为目标的应用程序公开有关任何其他已安装应用程序的详细信息，除非该应用程序已经能够通过托管 API 查看有关其他已安装应用程序的详细信息。这包括但不限于设备实现者添加的任何自定义 API 公开的详细信息，或通过文件系统访问的详细信息。
  • [C-0-2] 不得向任何应用程序授予读取或写入访问权限，以访问外部存储中任何其他应用程序的专用、应用程序特定的目录中的文件。唯一的例外情况如下
    • 外部存储提供程序权限（例如，DocumentsUI 等应用程序）。
    • 下载提供程序，它使用“downloads”提供程序权限将文件下载到应用程序存储。
    • 平台签名的媒体传输协议 (MTP) 应用程序，它们使用特权权限 ACCESS_MTP 来启用将文件传输到另一台设备。
    • 安装其他应用程序并具有权限 INSTALL_PACKAGES 的应用程序只能访问 “obb” 目录，以便管理 APK 扩展文件。

9.8.10. 连接性错误报告

如果设备实现声明 android.hardware.telephony 功能标志，他们

  • [C-1-1] 必须支持通过 BugreportManager 使用 BUGREPORT_MODE_TELEPHONY 生成连接性错误报告。
  • [C-1-2] 每次使用 BUGREPORT_MODE_TELEPHONY 生成报告时都必须获得用户同意，并且不得提示用户同意来自应用程序的所有未来请求。
  • [C-1-3] 未经用户明确同意，不得将生成的报告返回给请求应用程序。
  • [C-1-4] 使用 BUGREPORT_MODE_TELEPHONY 生成的报告必须至少包含以下信息
    • TelephonyDebugService 转储
    • TelephonyRegistry 转储
    • WifiService 转储
    • ConnectivityService 转储
    • 调用程序包的 CarrierService 实例的转储（如果已绑定）
    • 无线电日志缓冲区
  • [C-1-5] 不得在生成的报告中包含以下内容
    • 任何与连接性调试没有直接关系的信息。
    • 任何类型的用户安装的应用程序流量日志或用户安装的应用程序/软件包的详细配置文件（UID 可以，软件包名称不可以）。
  • 可以包含与任何用户身份无关的其他信息。（例如，供应商日志）。

如果设备实现在错误报告中包含其他信息（例如，供应商日志），并且该信息对隐私/安全/电池/存储/内存有影响，他们

  • [C-SR-1] 强烈建议具有默认禁用的开发者设置。AOSP 参考实现通过在开发者设置中提供 启用详细供应商日志记录 选项来满足此要求，以便在错误报告中包含其他设备特定的供应商日志。

9.8.11. 数据 Blob 共享

Android 通过 BlobStoreManager 允许应用程序向系统贡献数据 Blob，以便与选定的一组应用程序共享。

如果设备实现支持 SDK 文档中描述的共享数据 Blob，他们

9.8.12. 音乐识别

Android 通过系统 API MusicRecognitionManager 支持一种机制，供设备实现请求音乐识别，给定音频记录，并将音乐识别委托给实现 MusicRecognitionService API 的特权应用程序。

如果设备实现包含实现系统 API MusicRecognitionManager 或任何专有服务（流式传输上述音频数据）的服务，他们

  • [C-1-1] 必须强制 MusicRecognitionManager 的调用者持有 MANAGE_MUSIC_RECOGNITION 权限
  • [C-1-2] 必须强制单个预安装的音乐识别应用程序实现 MusicRecognitionService。
  • [C-1-3] 不得允许用户使用用户可安装的应用程序或服务替换 MusicRecognitionManagerService 或 MusicRecognitionService。
  • [C-1-4] 必须确保当 MusicRecognitionManagerService 访问音频记录并将其转发到实现 MusicRecognitionService 的应用程序时，音频访问通过调用 AppOpsManager.noteOp / startOp 进行跟踪。

如果 MusicRecognitionManagerService 或 MusicRecognitionService 的设备实现存储任何捕获的音频数据，他们

  • [C-2-1] 绝对不得在磁盘上存储任何原始音频或音频指纹，或在内存中存储超过 14 天。
  • [C-2-2] 不得将此类数据共享到 MusicRecognitionService 之外，除非每次共享时都获得用户的明确同意。

9.8.13. SensorPrivacyManager

如果设备实现为用户提供软件界面以关闭设备实现的摄像头和/或麦克风输入，他们

  • [C-1-1] 对于相关的 supportsSensorToggle() API 方法，必须准确返回“true”。
  • [C-1-2] 当应用程序尝试访问被阻止的麦克风或摄像头时，必须向用户呈现一个不可关闭的用户界面，该界面清楚地指示传感器已被阻止，并且需要选择继续阻止或解除阻止，如满足此要求的 AOSP 实现所示。
  • [C-1-3] 必须仅将空白（或虚假）摄像头和音频数据传递给应用程序，并且不得报告错误代码，因为用户没有通过上面 [C-1-2] 中呈现的用户界面打开摄像头或麦克风。

9.9. 数据存储加密

所有设备都必须满足第 9.9.1 节的要求。API 级别早于本文档发布设备的设备可豁免于第 9.9.2 节和 9.9.3 节的要求；但它们必须满足与设备发布的 API 级别相对应的 Android 兼容性定义文档中第 9.9 节的要求。

9.9.1. 直接启动

设备实现

9.9.2. 加密要求

设备实现

  • [C-0-1] 必须加密应用私有数据（/data 分区），以及应用共享存储分区（/sdcard 分区）（如果它是设备的永久性、不可移除的部分）。
  • [C-0-2] 必须在用户完成开箱即用设置体验时默认启用数据存储加密。

  • [C-0-3] 必须通过实施以下两种加密方法之一来满足上述数据存储加密要求

9.9.3. 加密方法

如果设备实现已加密，则它们

  • [C-1-1] 必须在启动时无需用户提供凭据，并允许感知直接启动的应用在 ACTION_LOCKED_BOOT_COMPLETED 消息广播后访问设备加密 (DE) 存储。
  • [C-1-2] 只有在用户通过提供其凭据（例如，密码、PIN 码、图案或指纹）解锁设备且 ACTION_USER_UNLOCKED 消息广播后，才允许访问凭据加密 (CE) 存储。
  • [C-1-13] 不得提供任何方法在没有用户提供的凭据、注册的托管密钥或满足 第 9.9.4 节 要求的重启后恢复实现的情况下解锁 CE 保护的存储。
  • [C-1-4] 必须使用已验证启动。
9.9.3.1. 基于文件的加密和元数据加密

如果设备实现使用基于文件的加密和元数据加密，则它们

  • [C-1-5] 必须使用 AES-256-XTS 或 Adiantum 加密文件内容和文件系统元数据。AES-256-XTS 指的是高级加密标准，具有 256 位密码密钥长度，在 XTS 模式下运行；密钥的总长度为 512 位。Adiantum 指的是 Adiantum-XChaCha12-AES，如 https://github.com/google/adiantum 中所述。文件系统元数据是诸如文件大小、所有权、模式和扩展属性 (xattrs) 之类的数据。
  • [C-1-6] 必须使用 AES-256-CBC-CTS 或 Adiantum 加密文件名。
  • [C-1-12] 如果设备具有高级加密标准 (AES) 指令（例如，基于 ARM 的设备上的 ARMv8 密码学扩展，或基于 x86 的设备上的 AES-NI），则必须使用上述基于 AES 的选项进行文件名、文件内容和文件系统元数据加密，而不是 Adiantum。
  • [C-1-13] 必须使用密码学上强度高且不可逆的密钥派生函数（例如 HKDF-SHA512）从 CE 和 DE 密钥派生任何所需的子密钥（例如，每个文件的密钥）。“密码学上强度高且不可逆”意味着密钥派生函数具有至少 256 位的安全强度，并且在其输入上表现为 伪随机函数族。
  • [C-1-14] 不得将相同的基于文件的加密 (FBE) 密钥或子密钥用于不同的加密目的（例如，既用于加密又用于密钥派生，或用于两种不同的加密算法）。
  • [C-1-15] 必须确保持久性存储上所有未删除的加密文件内容块都使用加密密钥和初始化向量 (IV) 的组合进行加密，这些组合取决于文件和文件内的偏移量。此外，所有此类组合都必须是不同的，除非加密是使用仅支持 32 位 IV 长度的内联加密硬件完成的。
  • [C-1-16] 必须确保持久性存储上不同目录中所有未删除的加密文件名都使用加密密钥和初始化向量 (IV) 的不同组合进行加密。

  • [C-1-17] 必须确保持久性存储上所有加密的文件系统元数据块都使用加密密钥和初始化向量 (IV) 的不同组合进行加密。

  • 保护 CE 和 DE 存储区域以及文件系统元数据的密钥

    • [C-1-7] 必须以密码学方式绑定到硬件支持的密钥库。此密钥库必须绑定到已验证启动和设备的硬件信任根。
    • [C-1-8] CE 密钥必须绑定到用户的锁屏凭据。
    • [C-1-9] 当用户未指定锁屏凭据时，CE 密钥必须绑定到默认密码。
    • [C-1-10] 必须是唯一且不同的，换句话说，没有用户的 CE 或 DE 密钥与任何其他用户的 CE 或 DE 密钥匹配。
    • [C-1-11] 必须使用强制支持的密码、密钥长度和模式。
    • [C-1-12] 必须在引导加载程序解锁和锁定时安全擦除，如 此处 所述。

  • 建议预安装的基本应用（例如，闹钟、电话、消息应用）感知直接启动。

上游 Android 开源项目提供了基于 Linux 内核“fscrypt”加密功能的基于文件的加密的首选实现，以及基于 Linux 内核“dm-default-key”功能的元数据加密的首选实现。

9.9.3.2. 按用户块级加密

如果设备实现使用按用户块级加密，则它们

  • [C-1-1] 必须启用第 9.5 节中描述的多用户支持。
  • [C-1-2] 必须提供按用户分区，可以使用原始分区或逻辑卷。
  • [C-1-3] 必须对底层块设备的加密使用每个用户唯一且不同的加密密钥。

  • [C-1-4] 必须对用户分区的块级加密使用 AES-256-XTS。

  • 保护按用户块级加密设备的密钥

    • [C-1-5] 必须以密码学方式绑定到硬件支持的密钥库。此密钥库必须绑定到已验证启动和设备的硬件信任根。
    • [C-1-6] 必须绑定到相应用户的锁屏凭据。

按用户块级加密可以使用 Linux 内核“dm-crypt”功能在按用户分区上实现。

9.9.4. 重启后恢复

重启后恢复允许在 OTA 发起的重启后解锁所有应用的 CE 存储，包括那些尚不支持直接启动的应用。此功能使用户能够在重启后接收来自已安装应用的通知。

重启后恢复的实现必须继续确保，当设备落入攻击者手中时，即使设备已开机、CE 存储已解锁且用户在收到 OTA 后已解锁设备，攻击者也极难恢复用户的 CE 加密数据。为了抵抗内部攻击，我们还假设攻击者获得了对广播加密签名密钥的访问权限。

具体来说

  • [C-0-1] CE 存储即使对于实际拥有设备并具有以下能力和限制的攻击者来说也必须是不可读的

    • 可以使用任何供应商或公司的签名密钥来签署任意消息。
    • 可以导致设备接收 OTA。
    • 可以修改任何硬件（AP、闪存等）的操作，但如下所述除外，但此类修改涉及至少一小时的延迟和破坏 RAM 内容的断电重启。
    • 无法修改防篡改硬件（例如 Titan M）的操作。
    • 无法读取活动设备的 RAM。
    • 无法获取用户的凭据（PIN 码、图案、密码）或以其他方式导致其被输入。

例如，符合 此处 找到的所有描述的设备实现将符合 [C-0-1]。

9.10. 设备完整性

以下要求确保设备完整性状态的透明度。设备实现

  • [C-0-1] 必须通过 System API 方法 PersistentDataBlockManager.getFlashLockState() 正确报告其引导加载程序状态是否允许刷写系统映像。

  • [C-0-2] 必须支持已验证启动以确保设备完整性。

如果设备实现已在早期版本的 Android 上发布，而未支持已验证启动，并且无法通过系统软件更新添加对此功能的支持，则可以豁免此要求。

已验证启动是一项保证设备软件完整性的功能。如果设备实现支持此功能，则它们

  • [C-1-1] 必须声明平台功能标志 android.software.verified_boot。
  • [C-1-2] 必须在每个启动序列上执行验证。
  • [C-1-3] 必须从作为信任根的不可变硬件密钥开始验证，并一直向上验证到系统分区。
  • [C-1-4] 必须实现验证的每个阶段，以检查下一阶段中所有字节的完整性和真实性，然后再执行下一阶段中的代码。
  • [C-1-5] 必须使用与 NIST 当前对哈希算法 (SHA-256) 和公钥大小 (RSA-2048) 的建议一样强大的验证算法。
  • [C-1-6] 当系统验证失败时，必须不允许完成启动，除非用户同意尝试仍然启动，在这种情况下，不得使用来自任何未验证存储块的数据。
  • [C-1-7] 除非用户已显式解锁引导加载程序，否则不得允许修改设备上的已验证分区。
  • [C-SR-1] 如果设备中有多个离散芯片（例如，无线电、专用图像处理器），则强烈建议每个芯片的启动过程在启动时验证每个阶段。
  • [C-1-8] 必须使用防篡改存储：用于存储引导加载程序是否已解锁。防篡改存储意味着引导加载程序可以检测到存储是否已从 Android 内部被篡改。
  • [C-1-9] 必须在使用设备时提示用户，并需要物理确认，然后才允许从引导加载程序锁定模式转换为引导加载程序解锁模式。
  • [C-1-10] 必须为 Android 使用的分区（例如，启动分区、系统分区）实现回滚保护，并使用防篡改存储来存储用于确定允许的最低操作系统版本的元数据。
  • [C-1-11] 必须在引导加载程序解锁和锁定时安全擦除所有用户数据，按照“9.12. 数据删除”（包括 userdata 分区和任何 NVRAM 空间）。
  • [C-SR-2] 强烈建议使用根植于受已验证启动保护的分区中的信任链来验证所有特权应用 APK 文件。
  • [C-SR-3] 强烈建议在执行任何特权应用从其 APK 文件外部加载的可执行文件（例如动态加载的代码或编译后的代码）之前对其进行验证，或者强烈建议根本不要执行它们。
  • 建议为具有持久性固件的任何组件（例如，调制解调器、摄像头）实现回滚保护，并且建议使用防篡改存储来存储用于确定允许的最低版本的元数据。

如果设备实现已在早期版本的 Android 上发布，而未支持 C-1-8 到 C-1-11，并且无法通过系统软件更新添加对这些要求的支持，则可以豁免这些要求。

上游 Android 开源项目在 external/avb/ 存储库中提供了此功能的首选实现，可以将其集成到用于加载 Android 的引导加载程序中。

设备实现

  • [C-0-3] 必须支持针对可信密钥以密码学方式验证文件内容，而无需读取整个文件。
  • [C-0-4] 当读取的内容未针对可信密钥进行验证时，必须不允许对受保护文件的读取请求成功。

如果设备实现已在早期版本的 Android 上发布，而没有针对可信密钥验证文件内容的能力，并且无法通过系统软件更新添加对此功能的支持，则可以豁免此要求。上游 Android 开源项目提供了基于 Linux 内核 fs-verity 功能的此功能的首选实现。

设备实现

如果设备实现支持 Android 受保护确认 API，则它们

  • [C-3-1] 必须为 ConfirmationPrompt.isSupported() API 报告 true。

  • [C-3-2] 必须确保在 Android 操作系统（包括其内核）中运行的代码（无论是否恶意）都无法在没有用户交互的情况下生成肯定响应。

  • [C-3-3] 必须确保即使在 Android 操作系统（包括其内核）受到攻击的情况下，用户也能够查看和批准提示的消息。

9.11. 密钥和凭据

Android 密钥库系统 允许应用开发者将加密密钥存储在容器中，并通过 KeyChain API 或 Keystore API 在加密操作中使用它们。设备实现

  • [C-0-1] 必须允许导入或生成至少 8,192 个密钥。
  • [C-0-2] 锁屏身份验证必须在失败的尝试之间实现时间间隔。以 n 作为失败的尝试计数，对于 9 < n < 30，时间间隔必须至少为 30 秒。对于 n > 29，时间间隔值必须至少为 30*2^floor((n-30)/10)) 秒或至少 24 小时，以较小者为准。
  • 建议不要限制可以生成的密钥数量

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

  • [C-1-1] 必须使用隔离的执行环境来支持密钥库实现。
  • [C-1-2] 必须具有 RSA、AES、ECDSA 和 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 秒。当主机单元关闭或用户切换时锁定屏幕的汽车设备可能没有睡眠超时配置。
  • [C-1-6] 必须支持以下之一
    • IKeymasterDevice 3.0，
    • IKeymasterDevice 4.0，
    • IKeymasterDevice 4.1，或
    • IKeyMintDevice 版本 1。
  • [C-SR-1] 强烈建议支持 IKeyMintDevice 版本 1。

9.11.1. 安全锁屏和身份验证

AOSP 实现遵循分层身份验证模型，其中基于知识因子的主要身份验证可以由辅助强生物识别技术或较弱的三级模式支持。

设备实现

  • [C-SR-1] 强烈建议仅将以下方法之一设置为主要身份验证方法
    • 数字 PIN 码
    • 字母数字密码
    • 在正好 3x3 个点的网格上的滑动图案

请注意，以上身份验证方法在本文件中被称为推荐的主要身份验证方法。

如果设备实现添加或修改了推荐的主要身份验证方法，并使用新的身份验证方法作为锁定屏幕的安全方式，则新的身份验证方法

如果设备实现添加或修改了基于已知秘密解锁锁屏的身份验证方法，并使用新的身份验证方法被视为锁定屏幕的安全方式

  • [C-3-1] 最短允许输入长度的熵必须大于 10 位。
  • [C-3-2] 所有可能输入的最大熵必须大于 18 位。
  • [C-3-3] 新的身份验证方法不得替换 AOSP 中实现和提供的任何推荐的主要身份验证方法（即，PIN 码、图案、密码）。
  • [C-3-4] 当设备策略控制器 (DPC) 应用已通过 DevicePolicyManager.setRequiredPasswordComplexity() 设置了密码要求策略，且复杂性常数比 PASSWORD_COMPLEXITY_NONE 更严格，或者通过 DevicePolicyManager.setPasswordQuality() 方法设置了密码要求策略，且常数比 PASSWORD_QUALITY_BIOMETRIC_WEAK 更严格时，必须禁用新的身份验证方法。
  • [C-3-5] 新的身份验证方法必须每 72 小时或更短的时间内回退到推荐的主要身份验证方法（即，PIN 码、图案、密码），或者明确向用户披露为了保护其数据的隐私，某些数据将不会备份。

如果设备实现添加或修改了推荐的用于解锁锁屏的主要身份验证方法，并使用基于生物识别技术的新身份验证方法被视为锁定屏幕的安全方式，则新方法

  • [C-4-1] 必须满足 第 7.3.10 节 中针对1 类（以前为便捷）描述的所有要求。
  • [C-4-2] 必须具有回退机制，以使用基于已知秘密的推荐主要身份验证方法之一。
  • [C-4-3] 当设备策略控制器 (DPC) 应用通过调用方法 DevicePolicyManager.setKeyguardDisabledFeatures()) 设置了锁屏保护功能策略，且带有任何关联的生物识别标志（即，KEYGUARD_DISABLE_BIOMETRICS、KEYGUARD_DISABLE_FINGERPRINT、KEYGUARD_DISABLE_FACE 或 KEYGUARD_DISABLE_IRIS）时，必须禁用新方法，并且只允许推荐的主要身份验证方法解锁屏幕。

如果生物识别身份验证方法不满足 第 7.3.10 节 中描述的3 类（以前为强）的要求

  • [C-5-1] 如果设备策略控制器 (DPC) 应用已通过 DevicePolicyManager.setRequiredPasswordComplexity() 设置了密码要求质量策略，且复杂性桶比 PASSWORD_COMPLEXITY_LOW 更严格，或者使用 DevicePolicyManager.setPasswordQuality() 方法设置了密码要求质量策略，且常数比 PASSWORD_QUALITY_BIOMETRIC_WEAK 更严格，则必须禁用这些方法。
  • [C-5-2] 必须按照 第 7.3.10 节 中的 [C-1-7] 和 [C-1-8] 中的描述，要求用户进行推荐的主要身份验证（例如：PIN 码、图案、密码）。
  • [C-5-3] 这些方法不得被视为安全锁屏，并且必须满足本节中以 C-8 开头的要求。

如果设备实现添加或修改了用于解锁锁屏的身份验证方法，并且新的身份验证方法基于物理令牌或位置

  • [C-6-1] 它们必须具有回退机制，以使用基于已知秘密的推荐主要身份验证方法之一，并满足被视为安全锁屏的要求。
  • [C-6-2] 当设备策略控制器 (DPC) 应用已通过以下任一方法设置策略时，必须禁用新方法，并且只允许推荐的主要身份验证方法之一解锁屏幕
  • [C-6-3] 必须至少每 4 小时或更短的时间内要求用户进行推荐的主要身份验证方法之一（例如，PIN 码、图案、密码）。
  • [C-6-4] 新方法不得被视为安全锁屏，并且必须遵循下面 C-8 中列出的约束。

如果设备实现具有安全锁屏并包含一个或多个信任代理（实现 TrustAgentService System 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] 必须按照 第 7.3.10 节 中的 [C-1-7] 和 [C-1-8] 中的描述，要求用户进行推荐的主要身份验证方法之一（例如：PIN 码、图案、密码），除非用户的安全（例如，驾驶员分心）受到关注。
  • [C-7-10] 不得被视为安全锁屏，并且必须遵循下面 C-8 中列出的约束。
  • [C-7-11] 不得允许主要个人设备（例如：手持设备）上的 TrustAgent 解锁设备，并且只能使用它们将已解锁的设备保持在解锁状态最多 4 小时。AOSP 中 TrustManagerService 的默认实现满足此要求。
  • [C-7-12] 必须使用密码学上安全的（例如 UKEY2）通信通道将托管令牌从存储设备传递到目标设备。

如果设备实现添加或修改了用于解锁锁屏的身份验证方法，该方法不是如上所述的安全锁屏，并且使用新的身份验证方法来解锁键盘锁

如果设备实现通过 DeviceStateManager 支持单独的显示屏电源状态，并且通过 KeyguardDisplayManager 支持单独的显示屏锁定状态，则它们

  • [C-SR-2] 强烈建议使用满足第 9.11.1 节中定义的凭据要求或满足第 7.3.10 节中定义的至少 1 类规范的生物识别技术，以允许从默认设备显示屏独立解锁。
  • [C-SR-3] 强烈建议通过定义的显示屏超时时间来约束单独的显示屏解锁。
  • [C-SR-4] 强烈建议允许用户通过主要手持设备的锁定功能全局锁定所有显示屏。

9.11.2. StrongBox

Android 密钥库系统 允许应用开发者将加密密钥存储在专用安全处理器以及上述隔离的执行环境中。这种专用安全处理器称为“StrongBox”。以下 C-1-3 到 C-1-11 要求定义了设备必须满足才能符合 StrongBox 资格的要求。

具有专用安全处理器的设备实现

  • [C-SR-1] 强烈建议支持 StrongBox。StrongBox 很可能在未来的版本中成为一项要求。

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

  • [C-1-1] 必须声明 FEATURE_STRONGBOX_KEYSTORE。

  • [C-1-2] 必须提供专用的安全硬件，用于支持密钥库和安全用户身份验证。专用安全硬件也可以用于其他目的。

  • [C-1-3] 必须具有一个独立的 CPU，该 CPU 与应用处理器 (AP) 不共享缓存、DRAM、协处理器或其他核心资源。

  • [C-1-4] 必须确保与 AP 共享的任何外围设备都不能以任何方式更改 StrongBox 处理，或从 StrongBox 获取任何信息。AP 可以禁用或阻止对 StrongBox 的访问。

  • [C-1-5] 必须具有内部时钟，该时钟具有合理的精度 (+-10%)，并且不受 AP 的操纵。

  • [C-1-6] 必须具有真随机数生成器，该生成器产生均匀分布且不可预测的输出。

  • [C-1-7] 必须具有防篡改能力，包括抵抗物理穿透和毛刺。

  • [C-1-8] 必须具有侧信道抗性，包括抵抗通过功率、时序、电磁辐射和热辐射侧信道泄漏信息。

  • [C-1-9] 必须具有安全存储，以确保内容的机密性、完整性、真实性、一致性和新鲜度。除非 StrongBox API 允许，否则存储不得被读取或更改。

  • 为了验证是否符合 [C-1-3] 到 [C-1-9]，设备实现

    • [C-1-10] 必须包含已通过安全 IC 保护配置文件 BSI-CC-PP-0084-2014 认证的硬件，或由国家认可的测试实验室根据 通用准则对智能卡的应用攻击潜力 纳入高攻击潜力漏洞评估进行评估。
    • [C-1-11] 必须包含由国家认可的测试实验室根据 通用准则对智能卡的应用攻击潜力 纳入高攻击潜力漏洞评估进行评估的固件。
    • [C-SR-2] 强烈建议包含使用安全目标、评估保证级别 (EAL) 5 并通过 AVA_VAN.5 增强的硬件。EAL 5 认证可能会在未来版本中成为一项要求。

  • [C-SR-3] 强烈建议提供内部攻击抵抗 (IAR)，这意味着有权访问固件签名密钥的内部人员无法生成导致 StrongBox 泄露机密、绕过功能安全要求或以其他方式访问敏感用户数据的固件。实现 IAR 的推荐方法是仅当通过 IAuthSecret HAL 提供主用户密码时才允许固件更新。

9.11.3. 身份凭证

身份凭证系统通过实现 android.security.identity.* 包中的所有 API 来定义和实现。这些 API 允许应用开发者存储和检索用户身份文档。设备实现

  • [C-SR-1] 强烈建议实现身份凭证系统。

如果设备实现实现了身份凭证系统，则它们

  • [C-1-1] 必须为 IdentityCredentialStore#getInstance() 方法返回非空值。

  • [C-1-2] 必须实现身份凭证系统（例如 android.security.identity.* API），其代码与安全隔离于内核及以上代码的受信任应用程序中的代码进行通信。安全隔离必须阻止内核或用户空间代码可能访问隔离环境内部状态的所有潜在机制，包括 DMA。

  • [C-1-3] 实现身份凭证系统（例如 android.security.identity.* API）所需的加密操作必须完全在受信任的应用程序中执行，并且私钥材料绝不能离开隔离的执行环境，除非更高级别的 API 明确要求（例如 createEphemeralKeyPair() 方法）。

  • [C-1-4] 受信任的应用程序的实现方式必须使其安全属性不受影响（例如，除非满足访问控制条件，否则凭据数据不会被释放，MAC 不能为任意数据生成），即使 Android 行为不当或遭到入侵也是如此。

9.12. 数据删除

所有设备实现

  • [C-0-1] 必须为用户提供执行“恢复出厂设置”的机制。
  • [C-0-2] 执行“恢复出厂设置”时，必须删除 userdata 文件系统上的所有数据。
  • [C-0-3] 执行“恢复出厂设置”时，必须以满足相关行业标准（如 NIST SP800-88）的方式删除数据。
  • [C-0-4] 当主用户的设备策略控制器应用调用 DevicePolicyManager.wipeData() API 时，必须触发上述“恢复出厂设置”过程。
  • 可以提供快速数据擦除选项，该选项仅执行逻辑数据擦除。

9.13. 安全启动模式

Android 提供安全启动模式，允许用户启动到仅允许预装系统应用运行且禁用所有第三方应用的模式。此模式（称为“安全启动模式”）为用户提供了卸载潜在有害第三方应用的功能。

设备实现

  • [C-SR-1] 强烈建议实现安全启动模式。

如果设备实现实现了安全启动模式，则它们

  • [C-1-1] 必须为用户提供一种进入安全启动模式的选项，该选项不会被设备上安装的第三方应用中断，除非第三方应用是设备策略控制器并已将 UserManager.DISALLOW_SAFE_BOOT 标志设置为 true。

  • [C-1-2] 必须为用户提供在安全模式下卸载任何第三方应用的功能。

  • 应该为用户提供从启动菜单中使用与正常启动不同的工作流程进入安全启动模式的选项。

9.14. 汽车车辆系统隔离

Android Automotive 设备预计将通过使用车辆 HAL在车辆网络（如 CAN 总线）上发送和接收消息来与关键车辆子系统交换数据。

数据交换可以通过在 Android 框架层下实现安全功能来保护，以防止与这些子系统的恶意或意外交互。

9.15. 订阅计划

“订阅计划”是指移动运营商通过 SubscriptionManager.setSubscriptionPlans() 提供的计费关系计划详细信息。

所有设备实现

  • [C-0-1] 必须仅向最初提供订阅计划的移动运营商应用返回订阅计划。
  • [C-0-2] 绝不能远程备份或上传订阅计划。
  • [C-0-3] 必须仅允许来自当前提供有效订阅计划的移动运营商应用的覆盖，例如 SubscriptionManager.setSubscriptionOverrideCongested()。

9.16. 应用数据迁移

如果设备实现包含将数据从一台设备迁移到另一台设备的功能，并且不限制其复制的应用数据为应用开发者在清单文件中通过 android:fullBackupContent 属性配置的内容，则它们

  • [C-1-1] 绝不能从用户未在 9.11.1 安全锁屏和身份验证 中描述的方式设置主身份验证的设备上启动应用数据传输。
  • [C-1-2] 必须安全地确认源设备上的主身份验证，并在传输任何数据之前与用户确认在源设备上复制数据的意图。
  • [C-1-3] 必须使用安全密钥认证来确保设备到设备迁移中的源设备和目标设备都是合法的 Android 设备，并且具有锁定的引导加载程序。
  • [C-1-4] 必须仅将应用数据迁移到目标设备上的同一应用，且包名和签名证书必须相同。
  • [C-1-5] 必须在设置菜单中显示指示，表明源设备已通过设备到设备数据迁移迁移了数据。用户不应能够删除此指示。

10. 软件兼容性测试

设备实现必须通过本节中描述的所有测试。但是，请注意，没有软件测试包是完全全面的。因此，强烈建议设备实现者尽可能少地更改 Android 开源项目中提供的 Android 参考实现和首选实现。这将最大限度地降低引入错误的风险，这些错误会产生不兼容性，需要返工和潜在的设备更新。

10.1. 兼容性测试套件

设备实现

  • [C-0-1] 必须通过 Android 开源项目中提供的 Android 兼容性测试套件 (CTS)，使用设备上的最终发布软件。

  • [C-0-2] 必须确保在 CTS 中存在歧义的情况下以及对于参考源代码的任何重新实现都具有兼容性。

CTS 旨在在实际设备上运行。与任何软件一样，CTS 本身可能包含错误。CTS 的版本将独立于此兼容性定义，并且可能会为 Android 12 发布 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] 设备实现必须包含替换整个系统软件的机制。该机制不需要执行“实时”升级 - 也就是说，可能需要重启设备。可以使用任何方法，前提是它可以替换设备上预装的整个软件。例如，以下任何方法都将满足此要求

    • 通过重启进行离线更新的“Over-the-air (OTA)”下载。
    • 通过 USB 从主机 PC 进行“ tethered”更新。
    • 通过重启和从可移动存储上的文件进行更新的“离线”更新。

  • [C-0-2] 使用的更新机制必须支持在不擦除用户数据的情况下进行更新。也就是说，更新机制必须保留应用私有数据和应用共享数据。请注意，上游 Android 软件包含满足此要求的更新机制。

  • [C-0-3] 整个更新必须签名，并且设备上的更新机制必须根据设备上存储的公钥验证更新和签名。

  • [C-SR-1] 强烈建议签名机制使用 SHA-256 对更新进行哈希处理，并使用 ECDSA NIST P-256 根据公钥验证哈希值。

如果设备实现包括支持非计量数据连接（如 802.11 或蓝牙 PAN（个人区域网络）配置文件）的功能，则它们

  • [C-1-1] 必须支持通过重启进行离线更新的 OTA 下载。

设备实现应该验证系统镜像在 OTA 后是否与预期结果二进制相同。自 Android 5.1 以来添加的上游 Android 开源项目中的基于块的 OTA 实现满足此要求。

此外，设备实现应该支持 A/B 系统更新。AOSP 使用启动控制 HAL 实现此功能。

如果在设备实现发布后但在其合理的产品生命周期内发现错误，并且经与 Android 兼容性团队协商后确定该错误会影响第三方应用的兼容性，则

  • [C-2-1] 设备实现者必须通过软件更新来纠正错误，该软件更新可以按照刚刚描述的机制应用。

Android 包含允许设备所有者应用（如果存在）控制系统更新安装的功能。如果设备的系统更新子系统报告 android.software.device_admin，则它们

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 论坛 并请求澄清或提出您认为文档未涵盖的任何问题。