自 2025 年 3 月 27 日起，我们建议使用 android-latest-release 而不是 aosp-main 来构建 AOSP 并为其做贡献。有关更多信息，请参阅AOSP 变更。

Android 8.1 兼容性定义
使用合集保持井井有条根据您的偏好保存内容并进行分类。

1. 导言

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

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

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

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

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

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

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

1.1 文档结构

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

第 2 节包含适用于特定设备类型的所有“必须 (MUST)”和“强烈建议 (STRONGLY RECOMMENDED)”要求。第 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 汽车实现
条件 ID
- 当要求是无条件时，此 ID 设置为 0。
- 当要求是有条件时，第一个条件分配为 1，并且在同一章节和同一设备类型中，数字递增 1。
要求 ID
- 此 ID 从 1 开始，并在同一章节和同一条件下递增 1。

2. 设备类型

虽然 Android 开源项目提供了一个可用于各种设备类型和外形规格的软件堆栈，但有一些设备类型具有相对较完善的应用程序分发生态系统。

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

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

2.1 设备配置

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

2.2. 手持设备要求

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

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

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

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

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

2.2.1. 硬件

屏幕尺寸（第 7.1.1.1 节）

手持设备实现

[H-0-1] 必须拥有物理对角线尺寸至少为 2.5 英寸的屏幕。^*

屏幕密度（第 7.1.1.3 节）

手持设备实现

[H-SR] 强烈建议提供用户可更改显示尺寸的功能。

旧版应用兼容模式（第 7.1.5 节）

手持设备实现

[H-0-1] 必须包含对上游 Android 开源代码实现的旧版应用兼容模式的支持。也就是说，设备实现不得更改激活兼容模式的触发器或阈值，并且不得更改兼容模式本身的行为。

键盘（第 7.2.1 节）

手持设备实现

[H-0-1] 必须包含对第三方输入法编辑器 (IME) 应用的支持。

导航键（第 7.2.3 节）

手持设备实现

[H-0-1] 必须提供主屏幕、最近任务和返回功能。
[H-0-2] 必须将返回功能 (KEYCODE_BACK) 的正常和长按事件都发送到前台应用。

触摸屏输入（第 7.2.4 节）

手持设备实现

[H-0-1] 必须支持触摸屏输入。

加速度计（第 7.3.1 节）

手持设备实现

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

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

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

陀螺仪（第 7.3.4 节）

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

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

接近传感器（第 7.3.8 节）

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

应该包含接近传感器。

姿势传感器（第 7.3.12 节）

手持设备实现

建议支持具有 6 自由度的姿势传感器。

蓝牙（第 7.4.3 节）

手持设备实现

应该包含对蓝牙和低功耗蓝牙的支持。

流量节省程序（第 7.4.7 节）

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

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

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

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

[H-1-1] 如果默认显示使用高达 qHD（例如 FWVGA）的帧缓冲区分辨率，则内核和用户空间可用的内存必须至少为 416MB。
[H-2-1] 如果默认显示使用高达 HD+（例如 HD、WSVGA）的帧缓冲区分辨率，则内核和用户空间可用的内存必须至少为 592MB。
[H-3-1] 如果默认显示使用高达 FHD（例如 WSXGA+）的帧缓冲区分辨率，则内核和用户空间可用的内存必须至少为 896MB。
[H-4-1] 如果默认显示使用高达 QHD（例如 QWXGA）的帧缓冲区分辨率，则内核和用户空间可用的内存必须至少为 1344MB。

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

[H-5-1] 如果默认显示使用高达 qHD（例如 FWVGA）的帧缓冲区分辨率，则内核和用户空间可用的内存必须至少为 816MB。
[H-6-1] 如果默认显示使用高达 HD+（例如 HD、WSVGA）的帧缓冲区分辨率，则内核和用户空间可用的内存必须至少为 944MB。
[H-7-1] 如果默认显示使用高达 FHD（例如 WSXGA+）的帧缓冲区分辨率，则内核和用户空间可用的内存必须至少为 1280MB。
[H-8-1] 如果默认显示使用高达 QHD（例如 QWXGA）的帧缓冲区分辨率，则内核和用户空间可用的内存必须至少为 1824MB。

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

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

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

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

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

应用共享存储空间（第 7.6.2 节）

手持设备实现

[H-0-1] 不得提供小于 1 GiB 的应用共享存储空间。

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

手持设备实现

应该包含支持外围设备模式的 USB 端口。

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

[H-1-1] 必须实现 Android 开放配件 (AOA) API。^*

麦克风（第 7.8.1 节）

手持设备实现

[H-0-1] 必须包含麦克风。

音频输出（第 7.8.2 节）

手持设备实现

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

虚拟现实模式（第 7.9.1 节）

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

[H-1-1] 必须声明 android.software.vr.mode 功能。^*

如果设备实现声明 android.software.vr.mode 功能，则它们

[H-2-1] 必须包含一个实现 android.service.vr.VrListenerService 的应用，该应用可以由 VR 应用通过 android.app.Activity#setVrModeEnabled 启用。^*

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

如果手持设备实现能够满足声明 android.hardware.vr.high_performance 功能标志的所有要求，则它们

[H-1-1] 必须声明 android.hardware.vr.high_performance 功能标志。^*

2.2.2. 多媒体

音频编码（第 5.1.1 节）

手持设备实现必须支持以下音频编码

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

音频解码（第 5.1.2 节）

手持设备实现必须支持以下音频解码

[H-0-1] AMR-NB
[H-0-2] AMR-WB

视频编码（第 5.2 节）

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

[H-0-1] H.264 AVC
[H-0-2] VP8

视频解码（第 5.3 节）

手持设备实现必须支持以下视频解码

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

2.2.3. 软件

WebView 兼容性（第 3.4.1 节）

手持设备实现

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

浏览器兼容性（第 3.4.2 节）

手持设备实现

[H-0-1] 必须包含一个独立的浏览器应用，用于常规用户网页浏览。

启动器（第 3.8.1 节）

手持设备实现

[H-SR] 强烈建议实现一个默认启动器，该启动器支持应用内固定快捷方式和小部件。
[H-SR] 强烈建议实现一个默认启动器，该启动器可以通过 ShortcutManager API 快速访问第三方应用提供的其他快捷方式。
[H-SR] 强烈建议包含一个默认启动器应用，该应用显示应用图标的徽章。

小部件（第 3.8.2 节）

手持设备实现

[H-SR] 强烈建议支持第三方应用小部件。

通知（第 3.8.3 节）

手持设备实现

[H-0-1] 必须允许第三方应用通过 Notification 和 NotificationManager API 类通知用户重要事件。
[H-0-2] 必须支持富通知。
[H-0-3] 必须支持浮动通知。
[H-0-4] 必须包含通知栏，使用户能够通过用户功能（例如操作按钮或 AOSP 中实现的控制面板）直接控制（例如回复、暂停、关闭、阻止）通知。

搜索（第 3.8.4 节）

手持设备实现

[H-SR] 强烈建议在设备上实现一个助手来处理 Assist 操作。

锁屏媒体控件（第 3.8.10 节）

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

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

设备管理（第 3.9 节）

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

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

辅助功能（第 3.10 节）

手持设备实现

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

文本转语音（第 3.11 节）

手持设备实现

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

快速设置（第 3.13 节）

手持设备实现

[H-SR] 强烈建议包含快速设置 UI 组件。

伴侣设备配对（第 3.15 节）

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

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

2.2.4. 性能和功耗

用户体验一致性（第 8.1 节）

对于手持设备实现

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

文件 I/O 访问性能（第 8.2 节）

手持设备实现

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

省电模式（第 8.3 节）

对于手持设备实现

[H-0-1] 所有免于应用待机和省电模式的应用都必须对最终用户可见。
[H-0-2] 应用待机和省电模式的触发、维护、唤醒算法以及全局系统设置的使用不得偏离 Android 开源项目。

功耗核算（第 8.4 节）

手持设备实现

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

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

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

2.2.5. 安全模型

权限（第 9.1 节）

手持设备实现

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

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] 必须提供主屏幕和返回功能。
[T-0-2] 必须将返回功能 (KEYCODE_BACK) 的正常和长按事件都发送到前台应用。

按钮映射（第 7.2.6.1 节）

电视设备实现

[T-0-1] 必须包含对游戏控制器的支持并声明 android.hardware.gamepad 功能标志。

遥控器（第 7.2.7 节）

电视设备实现

应该提供一个遥控器，用户可以通过该遥控器访问非触摸导航和核心导航键输入。

陀螺仪（第 7.3.4 节）

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

[T-1-1] 必须能够报告频率至少为 100 Hz 的事件。

蓝牙（第 7.4.3 节）

电视设备实现

[T-0-1] 必须支持蓝牙和低功耗蓝牙。

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

电视设备实现

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

麦克风（第 7.8.1 节）

电视设备实现

应该包含麦克风。

音频输出（第 7.8.2 节）

电视设备实现

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

2.3.2. 多媒体

音频编码（第 5.1 节）

电视设备实现必须支持以下音频编码

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

视频编码（第 5.2 节）

电视设备实现必须支持以下视频编码

[T-0-1] H.264 AVC
[T-0-2] VP8

H-264 (第 5.2.2 节)

电视设备实现应

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

视频解码（第 5.3 节）

电视设备实现**必须**支持以下视频解码

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

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

[T-SR] MPEG-2

H.264 (第 5.3.4 节)

如果电视设备实现支持 H.264 解码器，则它们

[T-1-1] **必须** 支持 High Profile Level 4.2 和 HD 1080p (60 fps) 解码配置文件。
[T-1-2] **必须** 能够解码以下表格中指示的两种高清配置文件的视频，并且使用 Baseline Profile、Main Profile 或 High Profile Level 4.2 中的任何一种进行编码

H.265 (HEVC) (第 5.3.5 节)

如果电视设备实现支持 H.265 编解码器和 HD 1080p 解码配置文件，则它们

[T-1-1] **必须** 支持 Main Profile Level 4.1 Main tier。
[T-SR] **强烈建议** 支持 HD 1080p 的 60 fps 视频帧率。

如果电视设备实现支持 H.265 编解码器和 UHD 解码配置文件，则

[T-2-1] 编解码器**必须**支持 Main10 Level 5 Main Tier 配置文件。

VP8 (第 5.3.6 节)

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

[T-1-1] **必须** 支持 HD 1080p60 解码配置文件。

如果电视设备实现支持 VP8 编解码器并支持 720p，则它们

[T-2-1] **必须** 支持 HD 720p60 解码配置文件。

VP9 (第 5.3.7 节)

如果电视设备实现支持 VP9 编解码器和 UHD 视频解码，则它们

[T-1-1] **必须** 支持 8 位色彩深度，**并且应该** 支持 VP9 Profile 2 (10 位)。

如果电视设备实现支持 VP9 编解码器、1080p 配置文件和 VP9 硬件解码，则它们

[T-2-1] **必须** 支持 1080p 的 60 fps。

安全媒体（第 5.8 节）

如果设备实现是 Android 电视设备并支持 4K 分辨率，则它们

[T-1-1] **必须** 支持所有有线外部显示器的 HDCP 2.2。

如果电视设备实现不支持 4K 分辨率，则它们

[T-2-1] **必须** 支持所有有线外部显示器的 HDCP 1.4。

电视设备实现

[T-SR] **强烈建议** 支持安全流的同步解码。至少，**强烈建议** 同步解码两个流。

音频输出音量（第 5.5.3 节）

电视设备实现

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

2.3.3. 软件

电视设备实现

[T-0-1] **必须** 声明 android.software.leanback 和 android.hardware.type.television 功能。

WebView 兼容性（第 3.4.1 节）

电视设备实现

[T-0-1] **必须** 提供 android.webkit.Webview API 的完整实现。

锁屏媒体控件（第 3.8.10 节）

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

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

多窗口（第 3.8.14 节）

电视设备实现

[T-SR] **强烈建议** 支持画中画 (PIP) 模式多窗口。

辅助功能（第 3.10 节）

电视设备实现

[T-SR] **必须** 支持第三方辅助功能服务。
[T-SR] Android 电视设备实现**强烈建议**在设备上预加载辅助功能服务，其功能与 talkback 开源项目中提供的 Switch Access 和 TalkBack（对于预加载的文本转语音引擎支持的语言）辅助功能服务相当或超出。

文本转语音（第 3.11 节）

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

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

电视输入框架（第 3.12 节）

电视设备实现

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

2.2.4. 性能和功耗

用户体验一致性（第 8.1 节）

对于电视设备实现

[T-0-1] **一致的帧延迟**。不一致的帧延迟或渲染帧的延迟**不得**超过每秒 5 帧，**并且应该**低于每秒 1 帧。

文件 I/O 访问性能（第 8.2 节）

电视设备实现

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

省电模式（第 8.3 节）

对于电视设备实现

[T-0-1] 所有从应用待机和 Doze 省电模式中豁免的应用**必须**对最终用户可见。
[T-0-2] 应用待机和 Doze 省电模式的触发、维护、唤醒算法以及全局系统设置的使用**不得**偏离 Android 开源项目。

功耗核算（第 8.4 节）

电视设备实现

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

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-2] **必须** 支持触摸屏输入。

加速度计（第 7.3.1 节）

手表设备实现

[W-SR] **强烈建议** 包括 3 轴加速度计。

蓝牙（第 7.4.3 节）

手表设备实现

[W-0-1] **必须** 支持蓝牙。

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

手表设备实现

[W-0-1] **必须** 具有至少 1GB 的非易失性存储空间，可用于应用私有数据（又名“/data”分区）
[W-0-2] **必须** 具有至少 416MB 的内存可供内核和用户空间使用。

麦克风（第 7.8.1 节）

手表设备实现

[W-0-1] **必须** 包括麦克风。

音频输出（第 7.8.1 节）

手表设备实现

可以**但应避免**具有音频输出。

2.4.2. 多媒体

无其他要求。

2.4.3. 软件

手表设备实现

[W-0-1] **必须** 声明 android.hardware.type.watch 功能。
[W-0-2] **必须** 支持 uiMode = UI_MODE_TYPE_WATCH。

搜索（第 3.8.4 节）

手表设备实现

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

辅助功能（第 3.10 节）

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

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

文本转语音（第 3.11 节）

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

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

2.5. 汽车要求

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

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

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

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

2.5.1. 硬件

屏幕尺寸（第 7.1.1.1 节）

Automotive 设备实现

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

导航键（第 7.2.3 节）

Automotive 设备实现

[A-0-1] **必须** 提供“主页”功能，并且**可以**提供“返回”和“最近使用”功能。
[A-0-2] **必须** 将“返回”功能（KEYCODE_BACK）的正常和长按事件都发送到前台应用。

加速度计（第 7.3.1 节）

Automotive 设备实现

[A-SR] **强烈建议** 包括 3 轴加速度计。

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

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

GPS（第 7.3.3 节）

如果 Automotive 设备实现包括 GPS/GNSS 接收器并通过 android.hardware.location.gps 功能标志向应用报告此功能

[A-1-1] GNSS 技术世代**必须**为“2017”年或更新。

陀螺仪（第 7.3.4 节）

如果 Automotive 设备实现包括陀螺仪，则它们

[A-1-1] **必须** 能够报告高达至少 100 Hz 频率的事件。

**Android Automotive 专用传感器（第 7.3.11 节）****当前档位（第 7.3.11.1 节）**

Automotive 设备实现

**应该**将当前档位作为 SENSOR_TYPE_GEAR 提供。

日夜模式（第 7.3.11.2 节）

Automotive 设备实现

[A-0-1] **必须** 支持定义为 SENSOR_TYPE_NIGHT 的日/夜模式。
[A-0-2] SENSOR_TYPE_NIGHT 标志的值**必须**与仪表板日/夜模式一致，**并且应该**基于环境光传感器输入。
底层环境光传感器**可以**与光度计相同。

驾驶状态（第 7.3.11.3 节）

Automotive 设备实现

[A-0-1] **必须** 支持定义为 SENSOR_TYPE_DRIVING_STATUS 的驾驶状态，当车辆完全停止并停放时，默认值为 DRIVE_STATUS_UNRESTRICTED。设备制造商有责任配置 SENSOR_TYPE_DRIVING_STATUS，使其符合适用于产品发货市场的所有法律和法规。

车轮速度（第 7.3.11.4 节）

Automotive 设备实现

[A-0-1] **必须** 提供定义为 SENSOR_TYPE_CAR_SPEED 的车速。

蓝牙（第 7.4.3 节）

Automotive 设备实现

[A-0-1] **必须** 支持蓝牙，**并且应该**支持蓝牙 LE。
[A-0-2] Android Automotive 实现**必须**支持以下蓝牙配置文件
- 通过免提配置文件 (HFP) 进行电话呼叫。
- 通过音频分发配置文件 (A2DP) 进行媒体播放。
- 通过远程控制配置文件 (AVRCP) 进行媒体播放控制。
- 使用电话簿访问配置文件 (PBAP) 进行联系人共享。
**应该**支持消息访问配置文件 (MAP)。

最低网络能力（第 7.4.5 节）

Automotive 设备实现

**应该**包括对基于蜂窝网络的數據连接的支持。

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

Automotive 设备实现

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

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

Automotive 设备实现

应该包含支持外围设备模式的 USB 端口。

麦克风（第 7.8.1 节）

Automotive 设备实现

[A-0-1] **必须** 包括麦克风。

音频输出（第 7.8.2 节）

Automotive 设备实现

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

2.5.2. 多媒体

音频编码（第 5.1 节）

Automotive 设备实现**必须**支持以下音频编码

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

视频编码（第 5.2 节）

Automotive 设备实现**必须**支持以下视频编码

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

视频解码（第 5.3 节）

Automotive 设备实现**必须**支持以下视频解码

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

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

[A-SR] H.265 HEVC

2.5.3. 软件

Automotive 设备实现

[A-0-1] **必须** 声明 android.hardware.type.automotive 功能。
[A-0-2] **必须** 支持 uiMode = UI_MODE_TYPE_CAR。
[A-0-3] Android Automotive 实现**必须**支持 android.car.* 命名空间中的所有公共 API。

WebView 兼容性（第 3.4.1 节）

Automotive 设备实现

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

通知（第 3.8.3 节）

Android Automotive 设备实现

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

搜索（第 3.8.4 节）

Automotive 设备实现

[A-0-1] **必须** 在设备上实现助手以处理 Assist 操作。

媒体 UI（第 3.14 节）

Automotive 设备实现

[A-0-1] **必须** 包括 UI 框架，以支持使用第 3.14 节中所述媒体 API 的第三方应用。

2.2.4. 性能和功耗

省电模式（第 8.3 节）

对于 Automotive 设备实现

[A-0-1] 所有从应用待机和 Doze 省电模式中豁免的应用**必须**对最终用户可见。
[A-0-2] 应用待机和 Doze 省电模式的触发、维护、唤醒算法以及全局系统设置的使用**不得**偏离 Android 开源项目。

功耗核算（第 8.4 节）

Automotive 设备实现

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

2.2.5. 安全模型

多用户支持（第 9.5 节）

如果 Automotive 设备实现包括多用户，则它们

[A-1-1] **必须** 包括访客帐户，该帐户允许车辆系统提供的所有功能，而无需用户登录。

Automotive 车辆系统隔离（第 9.14 节）

Automotive 设备实现

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

2.6. 平板电脑要求

“**Android 平板电脑设备**”是指通常用双手握持而不是翻盖式外形的 Android 设备实现。

如果 Android 设备实现满足以下所有条件，则归类为平板电脑

具有提供移动性的电源，例如电池。
物理对角线屏幕尺寸在 7 到 18 英寸之间。

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

2.4.1. 硬件

屏幕尺寸（第 7.1.1.1 节）

平板电脑设备实现

[Ta-0-1] **必须** 具有 7 到 18 英寸范围内的屏幕。

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

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

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

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

**可以**实现 Android 开放配件 (AOA) API。

虚拟现实模式（第 7.9.1 节）

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

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

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

3.1.1. Android 扩展

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

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

3.2. 软 API 兼容性

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

3.2.1. 权限

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

3.2.2. 构建参数

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

[C-0-1] 为了在设备实现中提供一致且有意义的值，下表包含对设备实现**必须**符合的这些值的格式的其他限制。

参数	详情
VERSION.RELEASE	当前正在执行的 Android 系统的版本，采用人类可读的格式。此字段必须具有 8.1 中定义的字符串值之一。
VERSION.SDK	当前正在执行的 Android 系统的版本，采用第三方应用程序代码可访问的格式。对于 Android 8.1，此字段必须具有整数值 8.1_INT。
VERSION.SDK_INT	当前正在执行的 Android 系统的版本，采用第三方应用程序代码可访问的格式。对于 Android 8.1，此字段必须具有整数值 8.1_INT。
VERSION.INCREMENTAL	设备实现者选择的值，用于指定当前正在执行的 Android 系统的特定版本，采用人类可读的格式。此值不得用于提供给最终用户的不同版本。此字段的典型用途是指示用于生成版本的内部版本号或源代码控制更改标识符。对此字段的具体格式没有要求，但不得为 null 或空字符串 ("")。
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:8.1/LMYXX/3359:userdebug/test-keys 指纹不得包含空格字符。如果上面模板中包含的其他字段包含空格字符，则必须在构建指纹中将其替换为另一个字符，例如下划线 ("_") 字符。此字段的值必须可编码为 7 位 ASCII。
HARDWARE	硬件名称（来自内核命令行或 /proc）。它应该具有合理的人类可读性。此字段的值必须可编码为 7 位 ASCII，并与正则表达式“^[a-zA-Z0-9_-]+$”匹配。
HOST	唯一标识构建在其上构建的主机的字符串，采用人类可读的格式。对此字段的具体格式没有要求，但不得为 null 或空字符串 ("")。
ID	设备实现者选择的标识符，用于引用特定版本，采用人类可读的格式。此字段可以与 android.os.Build.VERSION.INCREMENTAL 相同，但应该是一个对最终用户来说足够有意义的值，以便区分软件版本。此字段的值必须可编码为 7 位 ASCII，并与正则表达式“^[a-zA-Z0-9._-]+$”匹配。
MANUFACTURER	产品的原始设备制造商 (OEM) 的商标名称。对此字段的具体格式没有要求，但不得为 null 或空字符串 ("")。此字段在产品的生命周期内不得更改。
MODEL	设备实现者选择的值，其中包含最终用户已知的设备名称。这应该是设备销售给最终用户的名称。对此字段的具体格式没有要求，但不得为 null 或空字符串 ("")。此字段在产品的生命周期内不得更改。
PRODUCT	设备实现者选择的值，其中包含特定产品 (SKU) 的开发名称或代码名称，该名称在同一品牌内必须是唯一的。必须是人类可读的，但不一定供最终用户查看。此字段的值必须可编码为 7 位 ASCII，并与正则表达式“^[a-zA-Z0-9_-]+$”匹配。此产品名称在产品的生命周期内不得更改。
SERIAL	硬件序列号，在具有相同 MODEL 和 MANUFACTURER 的设备之间必须可用且唯一。此字段的值必须可编码为 7 位 ASCII，并与正则表达式“^([a-zA-Z0-9]{6,20})$”匹配。
TAGS	设备实现者选择的标签的逗号分隔列表，用于进一步区分版本。此字段必须具有与三个典型的 Android 平台签名配置之一对应的值：release-keys、dev-keys、test-keys。
TIME	表示构建发生时间的时间戳的值。
TYPE	设备实现者选择的值，用于指定版本的运行时配置。此字段必须具有与三个典型的 Android 运行时配置之一对应的值：user、userdebug 或 eng。
USER	生成版本的用户（或自动化用户）的名称或用户 ID。对此字段的具体格式没有要求，但不得为 null 或空字符串 ("")。
SECURITY_PATCH	指示版本安全补丁程序级别的值。它必须表示该版本在任何方面都不容易受到指定 Android 公共安全公告中描述的任何问题的影响。它必须采用 [YYYY-MM-DD] 格式，与 Android 公共安全公告或Android 安全公告中记录的已定义字符串匹配，例如“2015-11-01”。
BASE_OS	表示版本的 FINGERPRINT 参数的值，该版本在其他方面与此版本相同，除了 Android 公共安全公告中提供的补丁程序。它必须报告正确的值，如果此类版本不存在，则报告空字符串 ("")。
BOOTLOADER	设备实现者选择的值，用于标识设备中使用的特定内部引导加载程序版本，采用人类可读的格式。此字段的值必须可编码为 7 位 ASCII，并与正则表达式“^[a-zA-Z0-9._-]+$”匹配。
getRadioVersion()	必须（是或返回）设备实现者选择的值，用于标识设备中使用的特定内部无线电/调制解调器版本，采用人类可读的格式。如果设备没有任何内部无线电/调制解调器，则必须返回 NULL。此字段的值必须可编码为 7 位 ASCII，并与正则表达式“^[a-zA-Z0-9._-,]+$”匹配。

3.2.3. Intent 兼容性

3.2.3.1. 核心应用 Intent

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

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

3.2.3.2. Intent 解析

[C-0-1] 由于 Android 是一个可扩展平台，设备实现**必须**允许第三方应用覆盖第 3.2.3.1 节中引用的每个 intent 模式。上游 Android 开源实现默认允许这样做。
[C-0-2] 设备实现者**不得**将特殊权限附加到系统应用对这些 intent 模式的使用，或阻止第三方应用绑定和控制这些模式。此禁令特别包括但不限于禁用“选择器”用户界面，该界面允许用户在所有处理相同 intent 模式的多个应用之间进行选择。
[C-0-3] 设备实现**必须**为用户提供用户界面，以修改 intent 的默认活动。
但是，当默认活动为数据 URI 提供更具体的属性时，设备实现**可以**为特定 URI 模式（例如 http://play.google.com）提供默认活动。例如，指定数据 URI“http://www.android.com”的 intent 过滤器模式比浏览器的“http://”核心 intent 模式更具体。

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

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

3.2.3.3. Intent 命名空间

[C-0-1] 设备实现绝不能包含任何 Android 组件，该组件使用 android. 或 com.android. 命名空间中的 ACTION、CATEGORY 或其他键字符串来响应任何新的 Intent 或广播 Intent 模式。
[C-0-2] 设备实现者绝不能包含任何 Android 组件，该组件使用属于其他组织的包空间中的 ACTION、CATEGORY 或其他键字符串来响应任何新的 Intent 或广播 Intent 模式。
[C-0-3] 设备实现者绝不能更改或扩展第 3.2.3.1 节中列出的核心应用程序使用的任何 Intent 模式。
设备实现可以包含使用与其自身组织明确且明显相关的命名空间的 Intent 模式。此项禁止类似于第 3.6 节中为 Java 语言类指定的禁止。

3.2.3.4. 广播 Intent

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

设备实现

[C-0-1] 必须响应 SDK 文档中描述的适当系统事件来广播公共广播 Intent。请注意，此要求与第 3.5 节不冲突，因为 SDK 文档中也描述了后台应用程序的限制。

3.2.3.5. 默认应用设置

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

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

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

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

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

[C-2-1] 必须提供一个设置菜单，该菜单将调用 android.provider.Telephony.ACTION_CHANGE_DEFAULT Intent，以显示用于更改默认 SMS 应用程序的对话框。
[C-2-2] 必须遵循 android.telecom.action.CHANGE_DEFAULT_DIALER Intent，以显示一个对话框，允许用户更改默认的电话应用程序。
[C-2-3] 必须遵循 android.telecom.action.CHANGE_PHONE_ACCOUNTS Intent，以提供用户界面来配置与 PhoneAccounts 关联的 ConnectionServices，以及电信服务提供商将用于拨出电话的默认 PhoneAccount。AOSP 实现通过在“通话”设置菜单中包含“通话帐户选项”菜单来满足此要求。

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

[C-3-1] 必须遵循 android.settings.NFC_PAYMENT_SETTINGS Intent，以显示用于触碰付款的默认应用程序设置菜单。

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

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

3.2.4. 二级显示屏上的 Activity

如果设备实现允许在二级显示屏上启动正常的 Android Activity，则它们

[C-1-1] 必须设置 android.software.activities_on_secondary_displays 功能标志。
[C-1-2] 必须保证 API 兼容性，类似于在主显示屏上运行的 Activity。
[C-1-3] 当启动新 Activity 时未通过 ActivityOptions.setLaunchDisplayId() API 指定目标显示屏时，必须将新 Activity 放置在与启动它的 Activity 相同的显示屏上。
[C-1-4] 当移除带有 Display.FLAG_PRIVATE 标志的显示屏时，必须销毁所有 Activity。
[C-1-5] 如果 VirtualDisplay 本身被调整大小，则必须相应地调整其上的所有 Activity 的大小。
当二级显示屏上的文本输入字段获得焦点时，可以在主显示屏上显示 IME（输入法编辑器，一种允许用户输入文本的用户控件）。
当支持触摸或按键输入时，应在二级显示屏上独立于主显示屏实现输入焦点。
为了正确显示、运行并保持兼容性（如果在二级显示屏上启动 Activity），应具有与该显示屏相对应的 android.content.res.Configuration。

如果设备实现允许在二级显示屏上启动正常的 Android Activity，并且主显示屏和二级显示屏具有不同的 android.util.DisplayMetrics

[C-2-1] 不可调整大小的 Activity（在 AndroidManifest.xml 中具有 resizeableActivity=false）以及目标 API 级别为 23 或更低的应用程序绝不能在二级显示屏上允许。

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

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

3.3. 原生 API 兼容性

设备实现者是

原生代码兼容性具有挑战性。因此，设备实现者是

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

3.3.1. 应用程序二进制接口

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

设备实现

[C-0-1] 必须与一个或多个定义的 ABI 兼容，并实现与 Android NDK 的兼容性。
[C-0-2] 必须包含对在托管环境中运行的代码的支持，以使用标准 Java 原生接口 (JNI) 语义调用原生代码。
[C-0-3] 对于下面列表中的每个必需库，必须在源代码级别（即标头兼容）和二进制级别（对于 ABI）上兼容。
[C-0-4] 如果支持任何 64 位 ABI，则必须支持等效的 32 位 ABI。
[C-0-5] 必须通过 android.os.Build.SUPPORTED_ABIS、android.os.Build.SUPPORTED_32_BIT_ABIS 和 android.os.Build.SUPPORTED_64_BIT_ABIS 参数准确报告设备支持的原生应用程序二进制接口 (ABI)，每个参数都是以逗号分隔的 ABI 列表，从最优先到最不优先排序。
[C-0-6] 必须通过上述参数，仅报告 Android NDK ABI 管理文档最新版本中记录和描述的那些 ABI，并且必须包含对高级 SIMD（又名 NEON）扩展的支持。
[C-0-7] 必须使以下所有提供原生 API 的库可用于包含原生代码的应用程序
- libaaudio.so (AAudio 原生音频支持)
- libandroid.so (原生 Android Activity 支持)
- libc (C 库)
- libcamera2ndk.so
- libdl (动态链接器)
- libEGL.so (原生 OpenGL 表面管理)
- libGLESv1_CM.so (OpenGL ES 1.x)
- libGLESv2.so (OpenGL ES 2.0)
- libGLESv3.so (OpenGL ES 3.x)
- libicui18n.so
- libicuuc.so
- libjnigraphics.so
- liblog (Android 日志记录)
- libmediandk.so (原生媒体 API 支持)
- libm (数学库)
- libOpenMAXAL.so (OpenMAX AL 1.0.1 支持)
- libOpenSLES.so (OpenSL ES 1.0.1 音频支持)
- libRS.so
- libstdc++ (对 C++ 的最低限度支持)
- libvulkan.so (Vulkan)
- libz (Zlib 压缩)
- JNI 接口
[C-0-8] 绝不能添加或删除上述原生库的公共函数。
[C-0-9] 必须在 /vendor/etc/public.libraries.txt 中列出直接向第三方应用程序公开的其他非 AOSP 库。
[C-0-10] 绝不能向目标 API 级别为 24 或更高的第三方应用程序公开任何其他在 AOSP 中作为系统库实现和提供的原生库，因为它们是保留的。
[C-0-11] 必须通过 libGLESv3.so 库导出所有 OpenGL ES 3.1 和 Android 扩展包函数符号，如 NDK 中定义的那样。请注意，虽然所有符号都必须存在，但第 7.1.4.1 节更详细地描述了何时期望每个相应函数的完整实现。
[C-0-12] 必须通过 libvulkan.so 库导出核心 Vulkan 1.0 函数符号以及 VK_KHR_surface、VK_KHR_android_surface、VK_KHR_swapchain、VK_KHR_maintenance1 和 VK_KHR_get_physical_device_properties2 扩展的函数符号。请注意，虽然所有符号都必须存在，但第 7.1.4.2 节更详细地描述了何时期望每个相应函数的完整实现。
应使用上游 Android 开源项目中提供的源代码和头文件构建

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

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

如果设备实现是 64 位 ARM 设备，则

[C-1-1] 虽然 ARMv8 架构弃用了一些 CPU 操作，包括现有原生代码中使用的一些操作，但以下弃用的操作必须仍然可用于 32 位原生 ARM 代码，无论是通过原生 CPU 支持还是通过软件模拟
- SWP 和 SWPB 指令
- SETEND 指令
- CP15ISB、CP15DSB 和 CP15DMB 屏障操作

如果设备实现包含 32 位 ARM ABI，则它们

[C-2-1] 当 32 位 ARM 应用程序读取 /proc/cpuinfo 时，必须在其中包含以下行，以确保与使用旧版本 Android NDK 构建的应用程序的兼容性。
- Features:，后跟设备支持的任何可选 ARMv7 CPU 功能的列表。
- CPU architecture:，后跟一个整数，描述设备支持的最高 ARM 架构（例如，ARMv8 设备的“8”）。
当 64 位 ARM 或非 ARM 应用程序读取 /proc/cpuinfo 时，不应更改它。

3.4. Web 兼容性

3.4.1. WebView 兼容性

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

[C-1-1] 必须报告 android.software.webview。
[C-1-2] 对于 android.webkit.WebView API 的实现，必须使用来自上游 Android 开源项目的 Android 8.1 分支的 Chromium 项目构建。
[C-1-3] WebView 报告的用户代理字符串必须采用以下格式

Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD); wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- $(VERSION) 字符串的值必须与 android.os.Build.VERSION.RELEASE 的值相同。
- $(MODEL) 字符串的值必须与 android.os.Build.MODEL 的值相同。
- $(BUILD) 字符串的值必须与 android.os.Build.ID 的值相同。
- $(CHROMIUM_VER) 字符串的值必须是上游 Android 开源项目中 Chromium 的版本。
- 设备实现可以省略用户代理字符串中的 Mobile。
WebView 组件应包括对尽可能多的 HTML5 功能的支持，如果它支持该功能，则应符合 HTML5 规范。

3.4.2. 浏览器兼容性

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

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

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

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

3.5. API 行为兼容性

每种 API 类型（托管、软、原生和 Web）的行为必须与上游 Android 开源项目的首选实现保持一致。一些特定的兼容性领域是

[C-0-1] 设备绝不能更改标准 Intent 的行为或语义。
[C-0-2] 设备绝不能更改特定类型的系统组件（例如 Service、Activity、ContentProvider 等）的生命周期或生命周期语义。
[C-0-3] 设备绝不能更改标准权限的语义。
设备绝不能更改对后台应用程序强制执行的限制。更具体地说，对于后台应用程序
- [C-0-4] 它们必须停止执行由应用程序注册的回调，以接收来自 GnssMeasurement 和 GnssNavigationMessage 的输出。
- [C-0-5] 它们必须限制通过 LocationManager API 类或 WifiManager.startScan() 方法提供给应用程序的更新频率。
- [C-0-6] 如果应用程序的目标 API 级别为 25 或更高，则除非广播 Intent 需要 "signature" 或 "signatureOrSystem" protectionLevel 权限或在豁免列表上，否则它们绝不能允许在应用程序的清单文件中注册用于标准 Android Intent 的隐式广播的广播接收器。
- [C-0-7] 如果应用程序的目标 API 级别为 25 或更高，则它们必须停止应用程序的后台服务，就像应用程序已调用服务的 stopSelf() 方法一样，除非该应用程序被放置在临时允许列表中以处理对用户可见的任务。
- [C-0-8] 如果应用程序的目标 API 级别为 25 或更高，则它们必须释放应用程序持有的唤醒锁。

以上列表并非详尽无遗。兼容性测试套件 (CTS) 测试了平台行为兼容性的重要部分，但并非全部。设备实现者有责任确保与 Android 开源项目的行为兼容性。因此，设备实现者应尽可能使用通过 Android 开源项目提供的源代码，而不是重新实现系统的重要部分。

3.6. API 命名空间

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

java.*
javax.*
sun.*
android.*
com.android.*

也就是说，它们

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

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

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

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

[C-0-5] 绝不能位于由另一组织拥有或引用另一组织的命名空间中。例如，设备实现者绝不能向 com.google.* 或类似的命名空间添加 API：只有 Google 可以这样做。同样，Google 绝不能向其他公司的命名空间添加 API。
[C-0-6] 必须打包在 Android 共享库中，以便只有显式使用它们的应用程序（通过 <uses-library> 机制）才会受到此类 API 增加内存使用量的影响。

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

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

3.7. 运行时兼容性

设备实现

[C-0-1] 必须支持完整的 Dalvik 可执行文件 (DEX) 格式和 Dalvik 字节码规范和语义。
[C-0-2] 必须根据上游 Android 平台配置 Dalvik 运行时以分配内存，并按照下表指定。（有关屏幕尺寸和屏幕密度定义，请参阅第 7.1.1 节。）
应使用 Android RunTime (ART)，它是 Dalvik 可执行文件格式的参考上游实现，以及参考实现的包管理系统。
应在各种执行模式和目标架构下运行模糊测试，以确保运行时的稳定性。请参阅 Android 开源项目网站中的 JFuzz 和 DexFuzz。

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

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

3.8. 用户界面兼容性

3.8.1. 启动器（主屏幕）

Android 包含一个启动器应用程序（主屏幕）以及对第三方应用程序替换设备启动器（主屏幕）的支持。

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

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

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

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

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

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

如果设备实现实现了默认启动器，该启动器通过 ShortcutManager API 提供对第三方应用程序提供的其他快捷方式的快速访问，则它们

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

如果设备实现包含默认启动器应用程序，该应用程序显示应用程序图标的徽章，则它们

[C-5-1] 必须遵守 NotificationChannel.setShowBadge() API 方法。换句话说，如果值设置为 true，则显示与应用程序图标关联的可视化指示，并且当应用程序的所有通知通道都将值设置为 false 时，不显示任何应用程序图标徽章方案。
当第三方应用程序通过使用专有 API 指示支持专有徽章方案时，可以覆盖应用程序图标徽章，但应使用 SDK 中描述的通知徽章 API 提供的资源和值，例如 Notification.Builder.setNumber() 和 Notification.Builder.setBadgeIconType() API。

3.8.2. 小部件

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

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

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

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

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

3.8.3. 通知

Android 包含 Notification 和 NotificationManager API，这些 API 允许第三方应用程序开发人员使用设备的硬件组件（例如声音、振动和灯光）和软件功能（例如通知阴影、系统栏）来通知用户重要事件并吸引用户的注意力。

3.8.3.1. 通知的呈现

如果设备实现允许第三方应用程序通知用户重要事件，则它们

[C-1-1] 必须支持使用硬件功能的通知，如 SDK 文档中所述，并在设备实现硬件允许的范围内。例如，如果设备实现包含振动器，则必须正确实现振动 API。如果设备实现缺少硬件，则必须将相应的 API 实现为无操作。此行为在第 7 节中进一步详细说明。
[C-1-2] 必须正确渲染 API 或状态/系统栏图标样式指南中提供的所有资源（图标、动画文件等），尽管它们可以为通知提供与参考 Android 开源实现提供的用户体验不同的用户体验。
[C-1-3] 必须遵守并正确实现 API 中描述的更新、删除和分组通知的行为。
[C-1-4] 必须提供 SDK 中记录的 NotificationChannel API 的完整行为。
[C-1-5] 必须为用户提供界面，以阻止和修改特定第三方应用程序的每个通道和应用程序包级别的通知。
[C-1-6] 还必须为用户提供界面来显示已删除的通知通道。
应支持富通知。
应将一些更高优先级的通知显示为浮动通知。
应具有用户界面来延迟通知。
可以仅管理第三方应用程序何时可以通知用户重要事件的可见性和时间，以减轻驾驶员分心等安全问题。

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

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

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

[C-3-1] 当呈现浮动通知时，必须使用 Notification.Builder API 类中描述的浮动通知视图和资源。

3.8.3.2. 通知侦听器服务

Android 包含 NotificationListenerService API，这些 API 允许应用程序（一旦用户明确启用）接收所有通知的副本，因为它们被发布或更新。

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

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

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

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

3.8.3.3. DND（请勿打扰）

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

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

3.8.4. 搜索

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

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

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

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

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

默认行为应是显示网络搜索引擎结果和建议。

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

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

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

3.8.5. 警报和 Toast

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

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

[C-1-1] 必须提供用户操作入口，以阻止应用显示使用 TYPE_APPLICATION_OVERLAY 的警报窗口。AOSP 实现通过在通知栏中设置控件来满足此要求。
[C-1-2] 必须遵守 Toast API，并以某种高度可见的方式向最终用户显示来自应用程序的 Toast。

3.8.6. 主题

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

Android 包含 “Holo” 和 “Material” 主题系列，作为一组定义的样式，供应用程序开发者在希望匹配 Android SDK 定义的 Holo 主题外观时使用。

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

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

Android 还包含 “Device Default” 主题系列，作为一组定义的样式，供应用程序开发者在希望匹配设备实现者定义的设备主题外观时使用。

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

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

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

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

3.8.7. 动态壁纸

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

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

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

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

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

3.8.8. Activity 切换

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

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

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

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

3.8.9. 输入管理

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

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

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

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

[C-2-1] 必须完全实现 AutofillService 和 AutofillManager API，并遵守 android.settings.REQUEST_SET_AUTOFILL_SERVICE Intent 以显示默认应用设置菜单，供用户启用和停用自动填充以及更改默认自动填充服务。

3.8.10. 锁屏媒体控件

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

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

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

3.8.12. 位置信息

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

[C-1-1] 位置信息模式必须显示在“设置”中的“位置信息”菜单中。

3.8.13. Unicode 和字体

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

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

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

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

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

3.8.14. 多窗口

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

[C-1-1] 必须根据 Android SDK 多窗口模式支持文档中描述的应用程序行为和 API 实现此类多窗口模式，并满足以下要求
[C-1-2] 应用程序可以在 AndroidManifest.xml 文件中指示它们是否能够在多窗口模式下运行，可以通过显式地将 android:resizeableActivity 属性设置为 true 或隐式地将 targetSdkVersion 设置为 > 24。在其清单中显式地将此属性设置为 false 的应用不得在多窗口模式下启动。targetSdkVersion < 24 且未设置此 android:resizeableActivity 属性的旧版应用可以在多窗口模式下启动，但系统必须提供警告，提示该应用在多窗口模式下可能无法按预期工作。
[C-1-3] 如果屏幕高度 < 440 dp 且屏幕宽度 < 440 dp，则不得提供分屏或自由窗口模式。
屏幕尺寸为 xlarge 的设备实现应支持自由窗口模式。

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

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

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

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

3.9. 设备管理

Android 包括允许具有安全意识的应用程序在系统级别执行设备管理功能的功能，例如通过 Android 设备管理 API] 执行强制密码策略或执行远程擦除。

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

[C-1-1] 必须声明 android.software.device_admin。
[C-1-2] 必须支持第 3.9.1 节和第 3.9.1.1 节中描述的设备所有者配置。
[C-1-3] 必须通过 android.software.managed_users 功能标志声明对托管配置文件的支持，除非设备配置为使其报告自身为低 RAM 设备，或者配置为将其内部（不可移动）存储分配为共享存储。

3.9.1 设备配置

3.9.1.1 设备所有者配置

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

[C-1-1] 必须支持将设备策略客户端 (DPC) 注册为设备所有者应用，如下所述：。
- 当设备实现尚无用户数据配置时，它
  - [C-1-3] 必须为 DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) 报告 true。
  - [C-1-4] 必须响应 Intent 操作 android.app.action.PROVISION_MANAGED_DEVICE 将 DPC 应用程序注册为设备所有者应用程序。
  - [C-1-5] 如果设备通过功能标志 android.hardware.nfc 声明支持近场通信 (NFC)，并且接收到包含 MIME 类型为 MIME_TYPE_PROVISIONING_NFC 的记录的 NFC 消息，则必须将 DPC 应用程序注册为设备所有者应用程序。
- 当设备实现具有用户数据时，它
  - [C-1-6] 必须为 DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) 报告 false。
  - [C-1-7] 不得再将任何 DPC 应用程序注册为设备所有者应用程序。
[C-1-2] 未经用户或设备管理员的明确同意或操作，不得将应用程序（包括预安装的应用）设置为设备所有者应用。

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

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

3.9.1.2 托管配置文件配置

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

[C-1-1] 必须实现 API，以允许设备策略控制器 (DPC) 应用程序成为新的托管配置文件的所有者。
[C-1-2] 托管配置文件配置流程（由 android.app.action.PROVISION_MANAGED_PROFILE 发起的流程）用户体验必须与 AOSP 实现保持一致。
[C-1-3] 必须在“设置”中提供以下用户操作入口，以向用户指示设备策略控制器 (DPC) 何时禁用了特定的系统功能
- 一致的图标或其他用户操作入口（例如上游 AOSP 信息图标）来表示特定设置何时受到设备管理员的限制。
- 简短的解释消息，由设备管理员通过 setShortSupportMessage 提供。
- DPC 应用程序的图标。

3.9.2 托管配置文件支持

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

[C-1-1] 必须通过 android.app.admin.DevicePolicyManager API 支持托管配置文件。
[C-1-2] 必须允许创建且仅允许创建一个托管配置文件。
[C-1-3] 必须使用图标徽章（类似于 AOSP 上游工作徽章）来表示托管的应用程序和小部件以及其他带有徽章的 UI 元素，如最近使用应用和通知。
[C-1-4] 必须显示通知图标（类似于 AOSP 上游工作徽章）以指示用户何时在托管配置文件应用程序中。
[C-1-5] 如果设备唤醒 (ACTION_USER_PRESENT) 并且前台应用程序在托管配置文件中，则必须显示 Toast，指示用户在托管配置文件中。
[C-1-6] 如果存在托管配置文件，则必须在意图“选择器”中显示可视操作入口，以允许用户在设备策略控制器启用时将意图从托管配置文件转发到主用户，反之亦然。
[C-1-7] 如果存在托管配置文件，则必须为主要用户和托管配置文件公开以下用户操作入口
- 分别计算主要用户和托管配置文件的电池、位置信息、移动数据和存储使用情况。
- 独立管理主要用户或托管配置文件中安装的 VPN 应用程序。
- 独立管理主要用户或托管配置文件中安装的应用程序。
- 独立管理主要用户或托管配置文件中的帐户。
[C-1-8] 必须确保预装的拨号器、联系人和消息应用程序可以从托管配置文件（如果存在）以及主配置文件中搜索和查找呼叫者信息，如果设备策略控制器允许这样做。
[C-1-9] 必须确保它满足适用于启用多用户的设备的所有安全要求（请参阅第 9.5 节），即使托管配置文件不被计为除主要用户之外的另一个用户。
[C-1-10] 必须支持指定一个单独的锁屏，以满足以下要求，从而授予对在托管配置文件中运行的应用的访问权限。
- 设备实现必须遵守 DevicePolicyManager.ACTION_SET_NEW_PASSWORD Intent，并显示一个界面来为托管配置文件配置单独的锁屏凭据。
- 托管配置文件的锁屏凭据必须使用与父配置文件相同的凭据存储和管理机制，如 Android 开源项目站点上所述
- DPC 密码策略必须仅适用于托管配置文件的锁屏凭据，除非对 getParentProfileInstance 返回的 DevicePolicyManager 实例调用时。
当来自托管配置文件的联系人显示在预装的通话记录、通话中 UI、进行中和未接来电通知、联系人和消息应用中时，它们应带有与指示托管配置文件应用程序相同的徽章。

3.10. 无障碍功能

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

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

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

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

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

3.11. 文本转语音

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

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

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

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

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

3.12. 电视输入框架

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

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

[C-1-1] 必须声明平台功能 android.software.live_tv。
[C-1-2] 必须预加载电视应用程序（电视应用）并满足第 3.12.1 节中描述的所有要求。

3.12.1. 电视应用

如果设备实现支持 TIF

[C-1-1] 电视应用必须提供安装和使用电视频道的功能，并满足以下要求

声明了 android.software.live_tv 功能标志的 Android 设备实现所需的电视应用必须满足以下要求

设备实现应允许安装和管理基于第三方 TIF 的输入 (第三方输入)。
设备实现可以预安装的基于 TIF 的输入（已安装的输入）和第三方输入之间提供视觉分隔。
设备实现不应将第三方输入显示在距离电视应用超过一次导航操作的位置（即，从电视应用展开第三方输入列表）。

Android 开源项目提供了满足上述要求的电视应用的实现。

3.12.1.1. 电子节目指南

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

[C-1-1] 必须显示信息性且交互式的叠加层，该叠加层必须包括从 TvContract.Programs 字段中的值生成的电子节目指南 (EPG)。
[C-1-2] 频道切换时，设备实现**必须**为当前播放的节目显示 EPG 数据。
[SR] **强烈建议** EPG 以同等突出的方式显示已安装的输入源和第三方输入源。 **建议** EPG 上第三方输入源与已安装输入源之间的导航操作不应超过一次。
EPG **应该**显示来自所有已安装输入源和第三方输入源的信息。
EPG **可以**在已安装的输入源和第三方输入源之间提供视觉分隔。

3.12.1.2. 导航

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

[C-1-1] **必须**允许通过 Android 电视设备的输入设备（即遥控器、遥控器应用程序或游戏控制器）上的 D-pad、返回和主页键进行以下功能的导航
- 更改电视频道
- 打开 EPG
- 配置和调谐到第三方基于 TIF 的输入源（如果支持这些输入源）
- 打开设置菜单
**应该**通过 CEC 将按键事件传递到 HDMI 输入。

3.12.1.3. 电视输入应用链接

Android 电视设备实现**应该**支持电视输入应用链接，这允许所有输入源从当前活动提供到另一个活动的活动链接（即，从直播节目到相关内容的链接）。电视应用**应该**在提供电视输入应用链接时显示它。

3.12.1.4. 时移

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

[SR] **强烈建议**支持时移，这允许用户暂停和恢复直播内容。
**应该**为用户提供一种暂停和恢复当前播放节目的方法，如果该节目的时移可用。

3.12.1.5. 电视录制

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

[SR] **强烈建议**支持电视录制。
如果电视输入源支持录制，并且节目的录制未被禁止，则 EPG **可以**提供一种录制节目的方式。

3.13. 快速设置

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

如果设备实现包含快速设置 UI 组件，则它们

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

3.14. 媒体 UI

如果设备实现包含支持依赖于 MediaBrowser 和 MediaSession 的第三方应用的 UI 框架，则它们

[C-1-1] **必须** **不更改**地显示 MediaItem 图标和通知图标。
[C-1-2] **必须**按照 MediaSession 的描述显示这些项目，例如，元数据、图标、图像。
[C-1-3] **必须**显示应用标题。
[C-1-4] **必须**具有用于呈现 MediaBrowser 层次结构的抽屉。
[C-1-5] **必须**将双击 KEYCODE_HEADSETHOOK 或 KEYCODE_MEDIA_PLAY_PAUSE 视为 KEYCODE_MEDIA_NEXT 用于 MediaSession.Callback#onMediaButtonEvent。

3.15. 即时应用

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

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

3.16. 伴侣设备配对

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

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

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

4. 应用程序包兼容性

设备实现

[C-0-1] **必须**能够安装和运行由官方 Android SDK 中包含的 “aapt” 工具生成的 Android “.apk” 文件。
由于以上要求可能具有挑战性，**建议**设备实现使用 AOSP 参考实现的包管理系统设备实现。
[C-0-2] **必须**支持使用 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 的存储管理器应用。

设备实现**必须** **不能**从未知来源安装应用程序包，除非请求安装的应用满足以下所有要求

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

设备实现**必须**具有一个处理 android.settings.MANAGE_UNKNOWN_APP_SOURCES Intent 的活动。它们**应该**提供用户界面，以允许每个应用程序授予/撤销从未知来源安装应用的权限，但**可以**选择将其实现为无操作并为 startActivityForResult() 返回 RESULT_CANCELED，如果设备实现不想允许用户拥有此选择权。但是，即使在这样的情况下，它们**应该**向用户说明为什么没有提供这种选择。

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

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-5] FLAC
[C-1-6] MP3
[C-1-7] MIDI
[C-1-8] Vorbis
[C-1-9] PCM/WAVE
[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

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, 不可搜索)
MPEG-4 HE AAC Profile (AAC+)	支持单声道/立体声/5.0/5.1 内容，标准采样率从 16 到 48 kHz。
MPEG-4 HE AACv2 Profile (增强型 AAC+)	支持单声道/立体声/5.0/5.1 内容，标准采样率从 16 到 48 kHz。
AAC ELD (增强型低延迟 AAC)	支持单声道/立体声内容，标准采样率从 16 到 48 kHz。
AMR-NB	4.75 到 12.2 kbps，采样率 @ 8 kHz	3GPP (.3gp)
AMR-WB	9 个速率，从 6.60 kbit/s 到 23.85 kbit/s，采样率 @ 16 kHz
FLAC	单声道/立体声（无多声道）。采样率高达 48 kHz（但在具有 44.1 kHz 输出的设备上建议高达 44.1 kHz，因为 48 到 44.1 kHz 的降采样器不包括低通滤波器）。建议 16 位； 24 位不应用抖动。	仅限 FLAC (.flac)
MP3	单声道/立体声 8-320Kbps 恒定 (CBR) 或可变比特率 (VBR)	MP3 (.mp3)
MIDI	MIDI Type 0 和 1。 DLS Version 1 和 2。 XMF 和 Mobile XMF。支持铃声格式 RTTTL/RTX、OTA 和 iMelody	Type 0 和 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelody (.imy)
Vorbis		Ogg (.ogg) Matroska (.mkv, Android 4.0+)
PCM/WAVE	16 位线性 PCM（速率高达硬件限制）。设备必须支持原始 PCM 录音的采样率，频率为 8000、11025、16000 和 44100 Hz。	WAVE (.wav)
Opus		Matroska (.mkv), Ogg(.ogg)

5.1.4. 图像编码

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

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

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

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

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)

5.1.7. 视频编解码器

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

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

[C-1-1] 视频编解码器**必须**支持输出和输入字节缓冲区大小，这些大小可以容纳标准和配置所规定但又不过度分配的最大可行压缩和未压缩帧。
[C-1-2] 视频编码器和解码器**必须**支持 YUV420 灵活颜色格式 (COLOR_FormatYUV420Flexible)。

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

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

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

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

5.1.8. 视频编解码器列表

格式/编解码器	详情	支持的文件类型/ 容器格式
H.263		3GPP (.3gp) MPEG-4 (.mp4)
H.264 AVC	有关详细信息，请参见第 5.2 节和 5.3	3GPP (.3gp) MPEG-4 (.mp4) MPEG-2 TS (.ts, 仅 AAC 音频, 不可搜索, Android 3.0+)
H.265 HEVC	有关详细信息，请参见第 5.3 节	MPEG-4 (.mp4)
MPEG-2	Main Profile	MPEG2-TS
MPEG-4 SP		3GPP (.3gp)
VP8	有关详细信息，请参见第 5.2 节和 5.3	WebM (.webm) Matroska (.mkv)
VP9	有关详细信息，请参见第 5.3 节	WebM (.webm) Matroska (.mkv)

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 视频编码器并使其可供第三方应用使用，则它们

**应该**支持受支持的编码器的动态可配置比特率。

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 像素	720 x 480 像素	1280 x 720 像素	1920 x 1080 像素
视频帧率	20 fps	30 fps	30 fps	30 fps
视频比特率	384 Kbps	2 Mbps	4 Mbps	10 Mbps

5.2.3. VP8

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

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

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

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

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

5.2.4. VP9

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

**应该**支持写入 Matroska WebM 文件。

5.3. 视频解码

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

[C-1-1] **必须**实时支持所有 VP8、VP9、H.264 和 H.265 编解码器的同一流中的动态视频分辨率和帧率切换，并支持设备上每个编解码器支持的最大分辨率。

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

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

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 像素	720 x 480 像素	1280 x 720 像素	1920 x 1080 像素
视频帧率	30 fps	30 fps	60 fps	30 fps (60 fps^电视)
视频比特率	800 Kbps	2 Mbps	8 Mbps	20 Mbps

5.3.5. H.265 (HEVC)

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

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

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

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

	SD（低质量）	SD（高质量）	HD 720p	HD 1080p	UHD
视频分辨率	352 x 288 像素	720 x 480 像素	1280 x 720 像素	1920 x 1080 像素	3840 x 2160 像素
视频帧率	30 fps	30 fps	30 fps	30/60 fps (60 fps^{具有 H.265 硬件解码的电视})	60 fps
视频比特率	600 Kbps	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

5.3.6. VP8

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

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

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

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

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

5.3.7. VP9

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

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

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

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

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

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

	SD（低质量）	SD（高质量）	HD 720p	HD 1080p	UHD
视频分辨率	320 x 180 像素	640 x 360 像素	1280 x 720 像素	1920 x 1080 像素	3840 x 2160 像素
视频帧率	30 fps	30 fps	30 fps	30 fps (60 fps^{具有 VP9 硬件解码的电视})	60 fps
视频比特率	600 Kbps	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

5.4. 音频录制

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

5.4.1. 原始音频捕获

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

[C-1-1] **必须**允许捕获具有以下特征的原始音频内容
**格式**: 线性 PCM，16 位
**采样率**: 8000、11025、16000、44100 Hz
**声道**: 单声道
[C-1-2] **必须**以高于上述采样率进行捕获，而无需上采样。
[C-1-3] 当使用降采样捕获上述采样率时，**必须**包含适当的抗混叠滤波器。
**应该**允许 AM 无线电和 DVD 质量的原始音频内容捕获，这意味着以下特征
**格式**: 线性 PCM，16 位
**采样率**: 22050、48000 Hz
**声道**: 立体声

如果设备实现允许 AM 无线电和 DVD 质量的原始音频内容捕获，则它们

[C-2-1] **必须**在任何高于 16000:22050 或 44100:48000 的比率下进行捕获，而无需上采样。
[C-2-2] 对于任何上采样或降采样，**必须**包含适当的抗混叠滤波器。

5.4.2. 语音识别捕获

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

[C-1-1] **必须**以采样率 44100 和 48000 中的一个捕获 android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION 音频源。
[C-1-2] 默认情况下，当从 AudioSource.VOICE_RECOGNITION 音频源录制音频流时，**必须**禁用任何降噪音频处理。
[C-1-3] 默认情况下，当从 AudioSource.VOICE_RECOGNITION 音频源录制音频流时，**必须**禁用任何自动增益控制。
**应该**以近似平坦的幅度与频率特性记录语音识别音频流：具体而言，在 100 Hz 到 4000 Hz 范围内为 ±3 dB。
**应该**将语音识别音频流的输入灵敏度设置为，在 1000 Hz 时 90 dB 声功率级 (SPL) 源产生 16 位样本的 RMS 为 2500。
**应该**记录语音识别音频流，以便 PCM 幅度电平在线性跟踪输入 SPL 变化，范围至少为 30 dB，从 -18 dB 到 +12 dB re 90 dB SPL 在麦克风处。
**应该**记录语音识别音频流，对于 1 kHz 在麦克风处 90 dB SPL 输入电平的总谐波失真 (THD) 小于 1%。

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

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

5.4.3. 重定向播放的捕获

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

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

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

5.5. 音频播放

Android 包括允许应用通过 7.8.2 节中定义的音频输出外围设备播放音频的支持。

5.5.1. 原始音频播放

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

[C-1-1] **必须**允许播放具有以下特征的原始音频内容
- **格式**: 线性 PCM，16 位
- 采样率: 8000, 11025, 16000, 22050, 32000, 44100
- **声道**: 单声道、立体声
**应该**允许播放具有以下特征的原始音频内容
- 采样率: 24000, 48000

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] **必须**支持通过 Visualizer 类控制的可视化工具 API 实现。
**应该**支持可通过 AudioEffect 子类 BassBoost、EnvironmentalReverb、PresetReverb 和 Virtualizer 控制的 EFFECT_TYPE_BASS_BOOST、EFFECT_TYPE_ENV_REVERB、EFFECT_TYPE_PRESET_REVERB 和 EFFECT_TYPE_VIRTUALIZER 实现。

5.5.3. 音频输出音量

Automotive 设备实现

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

5.6. 音频延迟

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

在本节中，使用以下定义

**输出延迟**。应用程序写入 PCM 编码数据帧的时间与在设备上传感器处将相应的声音呈现给环境或信号通过端口离开设备并在外部可观察到的时间之间的时间间隔。
**冷启动输出延迟**。当音频输出系统在请求之前处于空闲状态并已断电时，第一帧的输出延迟。
**连续输出延迟**。设备播放音频后，后续帧的输出延迟。
**输入延迟**。环境通过设备上传感器向设备呈现声音或信号通过端口进入设备的时间与应用程序读取相应的 PCM 编码数据帧的时间之间的时间间隔。
**丢失的输入**。输入信号的初始部分，不可用或不可用。
**冷启动输入延迟**。当音频输入系统在请求之前处于空闲状态并已断电时，丢失的输入时间和第一帧的输入延迟之和。
**连续输入延迟**。设备捕获音频时，后续帧的输入延迟。
**冷启动输出抖动**。冷启动输出延迟值的不同测量值之间的可变性。
**冷启动输入抖动**。冷启动输入延迟值的不同测量值之间的可变性。
**连续往返延迟**。连续输入延迟加上连续输出延迟加上一个缓冲区周期的总和。缓冲区周期允许应用程序处理信号的时间以及应用程序减轻输入和输出流之间相位差的时间。
**OpenSL ES PCM 缓冲区队列 API**。 OpenSL ES API 在 Android NDK 中的 PCM 相关 API 集。
AAudio 原生音频 API。 AAudio API 集位于 Android NDK 中。

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

[SR] 冷启动输出延迟为 100 毫秒或更短
[SR] 持续输出延迟为 45 毫秒或更短
[SR] 尽量减少冷启动输出抖动

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

[SR] 强烈建议通过声明 android.hardware.audio.low_latency 功能标志来报告低延迟音频。
[SR] 强烈建议也通过 AAudio API 满足低延迟音频的要求。

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

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

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

[SR] 冷启动输入延迟为 100 毫秒或更短
[SR] 持续输入延迟为 30 毫秒或更短
[SR] 持续环路延迟为 50 毫秒或更短
[SR] 尽量减少冷启动输入抖动

5.7. 网络协议

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

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

[C-1-1] 必须支持第 5.1 节中所有必需的编解码器和容器格式（通过 HTTP(S)）。
[C-1-2] 必须支持下方的“媒体分段格式”表中所显示的媒体分段格式（通过 HTTP Live Streaming 草案协议，版本 7）。
[C-1-3] 必须支持下方的 RTSP 表中列出的以下 RTP 音频视频配置文件和相关编解码器。例外情况请参阅第 5.1 节中的表格脚注。

媒体分段格式

分段格式	参考资料	必需的编解码器支持
MPEG-2 传输流	ISO 13818	视频编解码器 H264 AVC MPEG-4 SP MPEG-2 有关 H264 AVC、MPEG2-4 SP 和 MPEG-2 的详细信息，请参阅第 5.1.3 节。音频编解码器 AAC 有关 AAC 及其变体的详细信息，请参阅第 5.1.1 节。
带有 ADTS 帧和 ID3 标签的 AAC	ISO 13818-7	有关 AAC 及其变体的详细信息，请参阅第 5.1.1 节
WebVTT	WebVTT

分段格式

参考资料

必需的编解码器支持

MPEG-2 传输流

ISO 13818

视频编解码器

H264 AVC
MPEG-4 SP
MPEG-2

有关 H264 AVC、MPEG2-4 SP 和
MPEG-2 的详细信息，请参阅第 5.1.3 节。

音频编解码器

有关 AAC 及其变体的详细信息，请参阅第 5.1.1 节。

带有 ADTS 帧和 ID3 标签的 AAC

ISO 13818-7

有关 AAC 及其变体的详细信息，请参阅第 5.1.1 节

WebVTT

RTSP (RTP, SDP)

配置文件名称	参考资料	必需的编解码器支持
H264 AVC	RFC 6184	有关 H264 AVC 的详细信息，请参阅第 5.1.3 节
MP4A-LATM	RFC 6416	有关 AAC 及其变体的详细信息，请参阅第 5.1.1 节
H263-1998	RFC 3551 RFC 4629 RFC 2190	有关 H263 的详细信息，请参阅第 5.1.3 节
H263-2000	RFC 4629	有关 H263 的详细信息，请参阅第 5.1.3 节
AMR	RFC 4867	有关 AMR-NB 的详细信息，请参阅第 5.1.1 节
AMR-WB	RFC 4867	有关 AMR-WB 的详细信息，请参阅第 5.1.1 节
MP4V-ES	RFC 6416	有关 MPEG-4 SP 的详细信息，请参阅第 5.1.3 节
mpeg4-generic	RFC 3640	有关 AAC 及其变体的详细信息，请参阅第 5.1.1 节
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 连接，这些传输包括
- USB 主机模式，第 7.7 节
- USB 外围设备模式，第 7.7 节
- 蓝牙低功耗 MIDI（充当中央角色），第 7.4.3 节
[C-1-2] 必须支持应用间 MIDI 软件传输（虚拟 MIDI 设备）

5.10. 专业音频

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

[C-1-1] 必须报告支持 android.hardware.audio.low_latency 功能。
[C-1-2] 必须具有持续环路音频延迟，如第 5.6 节音频延迟中所定义，必须为 20 毫秒或更短，并且应该在至少一个受支持的路径上为 10 毫秒或更短。
[C-1-3] 必须包含支持 USB 主机模式和 USB 外围设备模式的 USB 端口。
[C-1-4] 必须报告支持 android.software.midi 功能。
[C-1-5] 必须使用 OpenSL ES PCM 缓冲区队列 API 满足延迟和 USB 音频要求。
[SR] 强烈建议在音频处于活动状态且 CPU 负载变化时，提供一致的 CPU 性能水平。应使用 SimpleSynth commit 1bd6391 对此进行测试。SimpleSynth 应用需要在以下参数下运行，并在 10 分钟后实现零次欠载运行
- 工作周期：200,000
- 可变负载：开启（这将在工作周期值的 100% 和 10% 之间每 2 秒切换一次，旨在测试 CPU 调速器行为）
- 稳定负载：关闭
应该尽量减少音频时钟相对于标准时间的不准确性和漂移。
应该尽量减少音频时钟相对于 CPU CLOCK_MONOTONIC 的漂移（当两者都处于活动状态时）。
应该尽量减少通过设备内置传感器传输音频的延迟。
应该尽量减少通过 USB 数字音频传输音频的延迟。
应该记录所有路径上的音频延迟测量值。
应该尽量减少音频缓冲区完成回调条目时间中的抖动，因为这会影响回调可用的完整 CPU 带宽百分比。
应该在正常使用情况下，在报告的延迟下提供零次音频欠载运行（输出）或过载运行（输入）。
应该提供零通道间延迟差。
应该尽量减少所有传输上的 MIDI 平均延迟。
应该尽量减少负载下所有传输上的 MIDI 延迟可变性（抖动）。
应该在所有传输上提供准确的 MIDI 时间戳。
应该尽量减少设备内置传感器上的音频信号噪声，包括冷启动后立即出现的噪声。
应该在对应的端点的输入侧和输出侧之间提供零音频时钟差（当两者都处于活动状态时）。对应的端点的示例包括设备内置麦克风和扬声器，或音频插孔输入和输出。
应该在同一线程上处理对应的端点的输入侧和输出侧的音频缓冲区完成回调（当两者都处于活动状态时），并在从输入回调返回后立即进入输出回调。或者，如果无法在同一线程上处理回调，则在进入输入回调后不久进入输出回调，以允许应用具有输入侧和输出侧的一致时序。
应该尽量减少对应的端点的输入侧和输出侧的 HAL 音频缓冲之间的相位差。
应该尽量减少触摸延迟。
应该尽量减少负载下的触摸延迟可变性（抖动）。

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

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

如果设备实现通过 OpenSL ES PCM 缓冲区队列 API 满足要求，则

[SR] 强烈建议也通过 AAudio API 满足相同的要求。

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

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

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

[C-3-1] 必须实现 USB 音频类。
[C-3-2] 必须使使用 USB 音频类通过 USB 主机模式端口的持续环路音频延迟为 20 毫秒或更短。
使用 USB 音频类通过 USB 主机模式端口的持续环路音频延迟应该为 10 毫秒或更短。

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

[C-4-1] 必须支持以立体声和八声道输出，位深为 20 位或 24 位，频率为 192 kHz，且无位深损失或重采样。

5.11. 针对未处理的捕获

Android 包括通过 android.media.MediaRecorder.AudioSource.UNPROCESSED 音频源记录未处理音频的支持。在 OpenSL ES 中，可以使用记录预设 SL_ANDROID_RECORDING_PRESET_UNPROCESSED 访问它。

如果设备实现打算支持未处理音频源并使其可供第三方应用使用，则

[C-1-1] 必须通过 android.media.AudioManager 属性 PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED 报告支持情况。
[C-1-2] 必须在中频范围内表现出近似平坦的幅度-频率特性：具体而言，对于用于录制未处理音频源的每个麦克风，在 100 Hz 到 7000 Hz 范围内为 ±10dB。
[C-1-3] 必须在低频范围内表现出幅度水平：具体而言，对于用于录制未处理音频源的每个麦克风，在 5 Hz 到 100 Hz 范围内，相对于中频范围为 ±20 dB。
[C-1-4] 必须在高频范围内表现出幅度水平：具体而言，对于用于录制未处理音频源的每个麦克风，在 7000 Hz 到 22 KHz 范围内，相对于中频范围为 ±30 dB。
[C-1-5] 必须设置音频输入灵敏度，使得以 94 dB 声压级 (SPL) 播放的 1000 Hz 正弦波音源产生响应，对于用于录制未处理音频源的每个麦克风，16 位采样的 RMS 为 520（或者对于浮点/双精度采样，为 -36 dB Full Scale）。
[C-1-6] 必须对于用于录制未处理音频源的每个麦克风，具有 60 dB 或更高的信噪比 (SNR)。（其中 SNR 测量为 94 dB SPL 与自噪声的等效 SPL 之间的差值，A 加权）。
[C-1-7] 必须对于用于录制未处理音频源的每个麦克风，在 90 dB SPL 输入电平下，1 kHZ 的总谐波失真 (THD) 小于 1%。
不得在路径中进行任何其他信号处理（例如，自动增益控制、高通滤波器或回声消除），除了将电平调整到所需范围的电平乘法器。换句话说
[C-1-8] 如果架构中出于任何原因存在任何信号处理，则必须禁用它，并有效地为信号路径引入零延迟或额外延迟。
[C-1-9] 电平乘法器虽然允许在路径上，但不得为信号路径引入延迟或额外延迟。

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

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

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

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

6.1. 开发者工具

设备实现

[C-0-1] 必须支持 Android SDK 中提供的 Android 开发者工具。
Android 调试桥 (adb)
- [C-0-2] 必须支持 Android SDK 中记录的所有 adb 功能，包括 dumpsys。
- [C-0-3] 不得更改通过 dumpsys 记录的设备系统事件（batterystats、diskstats、fingerprint、graphicsstats、netstats、notification、procstats）的格式或内容。
- [C-0-4] 必须默认禁用设备端 adb 守护程序，并且必须提供用户可访问的机制来启用 Android 调试桥。
- [C-0-5] 必须支持安全 adb。Android 包括对安全 adb 的支持。安全 adb 允许在已知的经过身份验证的主机上启用 adb。
- [C-0-6] 必须提供一种机制，允许从主机连接 adb。例如
  - 没有支持外围设备模式的 USB 端口的设备实现必须通过局域网（例如以太网或 Wi-Fi）实现 adb。
  - 必须提供适用于 Windows 7、9 和 10 的驱动程序，允许开发者使用 adb 协议连接到设备。
Dalvik 调试监控服务 (ddms)
- [C-0-7] 必须支持 Android SDK 中记录的所有 ddms 功能。由于 ddms 使用 adb，因此默认情况下应该禁用对 ddms 的支持，但只要用户已激活 Android 调试桥（如上所述），就必须支持 ddms。
Monkey
- [C-0-8] 必须包含 Monkey 框架并使其可供应用使用。
SysTrace
- [C-0-9] 必须支持 Android SDK 中记录的 systrace 工具。Systrace 必须默认处于禁用状态，并且必须提供用户可访问的机制来启用 Systrace。

6.2. 开发者选项

Android 包括对开发者配置应用开发相关设置的支持。

设备实现必须为开发者选项提供一致的体验，它们

[C-0-1] 必须遵守 android.settings.APPLICATION_DEVELOPMENT_SETTINGS Intent 以显示应用开发相关设置。上游 Android 实现默认隐藏“开发者选项”菜单，并允许用户在点击设置 > 关于设备 > 版本号 菜单项七 (7) 次后启动“开发者选项”。
[C-0-2] 必须默认隐藏“开发者选项”，并且必须提供一种机制来启用“开发者选项”，而无需任何特殊的许可列表。
可以临时限制对“开发者选项”菜单的访问，方法是视觉上隐藏或禁用该菜单，以防止在用户安全受到关注的情况下分心。

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 布局以适应设备的工具，以确保第三方应用在各种硬件配置上良好运行。设备必须正确实现本节中详细介绍的这些 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 文档中所述。

7.1.1.2. 屏幕宽高比

虽然物理屏幕显示器的屏幕宽高比值没有限制，但第三方应用在其中渲染的逻辑显示器的屏幕宽高比（可以从通过 view.Display API 和 Configuration API 报告的高度和宽度值推导得出）必须满足以下要求

[C-0-1] Configuration.uiMode 设置为 UI_MODE_TYPE_NORMAL 的设备实现必须具有介于 1.3333 (4:3) 和 1.86（大致 16:9）之间的宽高比值，除非可以认为应用已准备好通过满足以下条件之一来拉伸得更长
- 应用已通过 android.max_aspect 元数据值声明它支持更大的屏幕宽高比。
- 应用通过 android:resizeableActivity 属性声明它是可调整大小的。
- 应用以 API 级别 26 或更高版本为目标，并且未声明会限制允许的宽高比的 android:MaxAspectRatio。
[C-0-2] Configuration.uiMode 设置为 UI_MODE_TYPE_WATCH 的设备实现必须将宽高比值设置为 1.0 (1:1)。

7.1.1.3. 屏幕密度

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

[C-0-1] 默认情况下，设备实现必须仅通过 DENSITY_DEVICE_STABLE API 报告以下逻辑 Android 框架密度之一，并且此值不得在任何时候更改；但是，设备可以根据用户在初始启动后设置的显示配置更改（例如，显示尺寸）报告不同的任意密度。
- 120 dpi (ldpi)
- 160 dpi (mdpi)
- 213 dpi (tvdpi)
- 240 dpi (hdpi)
- 260 dpi (260dpi)
- 280 dpi (280dpi)
- 300 dpi (300dpi)
- 320 dpi (xhdpi)
- 340 dpi (340dpi)
- 360 dpi (360dpi)
- 400 dpi (400dpi)
- 420 dpi (420dpi)
- 480 dpi (xxhdpi)
- 560 dpi (560dpi)
- 640 dpi (xxxhdpi)
设备实现应该定义在数值上最接近屏幕物理密度的标准 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. 显示指标

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

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

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

[C-2-1] 必须为 android.util.DisplayMetrics API 中定义的模拟默认 view.Display 的所有显示指标报告合理的值。

7.1.3. 屏幕方向

设备实现

[C-0-1] 必须报告它们支持的屏幕方向（android.hardware.screen.portrait 和/或 android.hardware.screen.landscape），并且必须报告至少一个受支持的方向。例如，具有固定方向横向屏幕的设备（如电视或笔记本电脑）应该仅报告 android.hardware.screen.landscape。
[C-0-2] 必须报告设备当前方向的正确值，无论何时通过 android.content.res.Configuration.orientation、android.view.Display.getOrientation() 或其他 API 查询时。

如果设备实现支持两种屏幕方向，则

[C-1-1] 必须支持应用对纵向或横向屏幕方向的动态方向。也就是说，设备必须尊重应用对特定屏幕方向的请求。
[C-1-2] 不得在更改方向时更改报告的屏幕尺寸或密度。
可以选择纵向或横向方向作为默认方向。

7.1.4. 2D 和 3D 图形加速

7.1.4.1 OpenGL ES

设备实现

[C-0-1] 必须通过托管 API（例如通过 GLES10.getString() 方法）和原生 API 正确识别受支持的 OpenGL ES 版本（1.1、2.0、3.0、3.1、3.2）。
[C-0-2] 必须为它们标识为支持的每个 OpenGL ES 版本包含对所有相应的托管 API 和原生 API 的支持。

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

[C-1-1] 必须支持 OpenGL ES 1.0 和 2.0，如 Android SDK 文档中所体现和详述。
[SR] 强烈建议支持 OpenGL ES 3.0。
应该支持 OpenGL ES 3.1 或 3.2。

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

[C-2-1] 必须通过 OpenGL ES 托管 API 和原生 API 报告它们已实现的任何其他 OpenGL ES 扩展，反之，不得报告它们不支持的扩展字符串。
[C-2-2] 必须支持 EGL_KHR_image、EGL_KHR_image_base、EGL_ANDROID_image_native_buffer、EGL_ANDROID_get_native_client_buffer、EGL_KHR_wait_sync、EGL_KHR_get_all_proc_addresses、EGL_ANDROID_presentation_time、EGL_KHR_swap_buffers_with_damage 和 EGL_ANDROID_recordable 扩展。
[SR] 强烈建议支持 EGL_KHR_partial_update。
应该通过 getString() 方法准确报告它们支持的任何纹理压缩格式，这通常是供应商特定的。

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

[C-3-1] 必须在 libGLESv2.so 库中导出这些版本的相应函数符号，以及 OpenGL ES 2.0 函数符号。

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

[C-4-1] 必须完全支持 OpenGL ES Android Extension Pack。

如果设备实现完全支持 OpenGL ES Android Extension Pack，则

[C-5-1] 必须通过 android.hardware.opengles.aep 功能标志识别支持情况。

如果设备实现公开支持 EGL_KHR_mutable_render_buffer 扩展，则

[C-6-1] 必须也支持 EGL_ANDROID_front_buffer_auto_refresh 扩展。

7.1.4.2 Vulkan

Android 包括对 Vulkan 的支持，Vulkan 是一种用于高性能 3D 图形的低开销、跨平台 API。

如果设备实现支持 OpenGL ES 3.0 或 3.1，则

[SR] 强烈建议包括对 Vulkan 1.0 的支持。

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

应该包括对 Vulkan 1.0 的支持。

设备实现（如果包括对 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] 不得枚举应用包外部的库提供的层，或提供其他跟踪或拦截 Vulkan API 的方式，除非应用将 android:debuggable 属性设置为 true。
[C-1-6] 必须通过 Vulkan 原生 API 报告它们确实支持的所有扩展字符串，反之，不得报告它们未正确支持的扩展字符串。

设备实现（如果不包括对 Vulkan 1.0 的支持）

[C-2-1] 不得声明任何 Vulkan 功能标志（例如 android.hardware.vulkan.level、android.hardware.vulkan.version）。
[C-2-2] 不得为 Vulkan 原生 API vkEnumeratePhysicalDevices() 枚举任何 VkPhysicalDevice。

7.1.4.3 RenderScript

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

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 广色域显示器

如果设备实现通过 Display.isWideColorGamut() 声称支持广色域显示器，则

[C-1-1] 必须具有颜色校准的显示器。
[C-1-2] 必须具有一个显示器，其色域在 CIE 1931 xyY 空间中完全覆盖 sRGB 色域。
[C-1-3] 必须具有一个显示器，其色域在 CIE 1931 xyY 空间中至少具有 90% 的 NTSC 1953 区域。
[C-1-4] 必须支持 OpenGL ES 3.0、3.1 或 3.2 并正确报告。
[C-1-5] 必须声明支持 EGL_KHR_no_config_context、EGL_EXT_pixel_format_float、EGL_KHR_gl_colorspace、EGL_EXT_colorspace_scrgb_linear 和 EGL_GL_colorspace_display_p3 扩展。
[SR] 强烈建议支持 GL_EXT_sRGB。

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

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

7.1.5. 旧版应用兼容性模式

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

7.1.6. 屏幕技术

Android 平台包含允许应用程序向显示屏渲染丰富图形的 API。除非本文档另有明确允许，否则设备必须支持 Android SDK 定义的所有这些 API。

设备实现

[C-0-1] 必须支持能够渲染 16 位彩色图形的显示屏。
应该支持能够渲染 24 位彩色图形的显示屏。
[C-0-2] 必须支持能够渲染动画的显示屏。
[C-0-3] 必须使用像素纵横比 (PAR) 在 0.9 到 1.15 之间的显示技术。也就是说，像素纵横比必须接近正方形 (1.0)，容差为 10% ~ 15%。

7.1.7. 辅助显示屏

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

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

[C-1-1] 必须实现 Android SDK 文档中描述的 DisplayManager 系统服务和 API。

7.2. 输入设备

设备实现

[C-0-1] 必须包含输入机制，例如触摸屏或非触摸导航，以在 UI 元素之间导航。

7.2.1. 键盘

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

[C-1-1] 必须声明 android.software.input_methods 功能标志。
[C-1-2] 必须完全实现 Input Management Framework
[C-1-3] 必须预装软件键盘。

设备实现：[C-0-1] 禁止包含与 android.content.res.Configuration.keyboard（QWERTY 或 12 键）中指定的格式之一不匹配的硬件键盘。 应该包含额外的软键盘实现。* 可以包含硬件键盘。

7.2.2. 非触摸导航

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

设备实现

[C-0-1] 必须为 android.content.res.Configuration.navigation 报告正确的值。

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

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

7.2.3. 导航键

通常通过与专用物理按钮或触摸屏的不同部分交互来提供的 Home、Recents 和 Back 功能对于 Android 导航范例至关重要，因此，设备实现

[C-0-1] 必须提供用户辅助功能，以启动已安装的应用程序，这些应用程序的 activity 设置了带有 <intent-filter> 和 ACTION=MAIN 和 CATEGORY=LAUNCHER 或 CATEGORY=LEANBACK_LAUNCHER（对于电视设备实现）。Home 功能应该是此用户辅助功能的机制。
应该为 Recents 和 Back 功能提供按钮。

如果提供了 Home、Recents 或 Back 功能，则它们

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

设备实现

[SR] 强烈建议不要为 Menu 功能提供输入机制，因为它自 Android 4.0 以来已被弃用，转而使用操作栏。

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

[C-2-1] 必须在操作溢出菜单弹出窗口不为空且操作栏可见时，显示操作溢出按钮。
[C-2-2] 禁止修改通过选择操作栏中的溢出按钮显示的操作溢出弹出窗口的位置，但是当通过选择 Menu 功能显示操作溢出弹出窗口时，可以在修改后的屏幕位置渲染操作溢出弹出窗口。

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

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

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

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

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

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

7.2.4. 触摸屏输入

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

设备实现

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

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

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

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

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

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

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

7.2.5. 伪触摸输入

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

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

应该声明对 android.hardware.faketouch 功能标志的支持。

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

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

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

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

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

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

7.2.6. 游戏控制器支持

7.2.6.1. 按钮映射

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

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

按钮	HID 用法²	Android 按钮
A¹	0x09 0x0001	KEYCODE_BUTTON_A (96)
B¹	0x09 0x0002	KEYCODE_BUTTON_B (97)
X¹	0x09 0x0004	KEYCODE_BUTTON_X (99)
Y¹	0x09 0x0005	KEYCODE_BUTTON_Y (100)
D-pad 上¹ D-pad 下¹	0x01 0x0039³	AXIS_HAT_Y⁴
D-pad 左1 D-pad 右¹	0x01 0x0039³	AXIS_HAT_X⁴
左肩按钮¹	0x09 0x0007	KEYCODE_BUTTON_L1 (102)
右肩按钮¹	0x09 0x0008	KEYCODE_BUTTON_R1 (103)
左摇杆点击¹	0x09 0x000E	KEYCODE_BUTTON_THUMBL (106)
右摇杆点击¹	0x09 0x000F	KEYCODE_BUTTON_THUMBR (107)
Home¹	0x0c 0x0223	KEYCODE_HOME (3)
Back¹	0x0c 0x0224	KEYCODE_BACK (4)

¹ KeyEvent

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

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

⁴ MotionEvent

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

¹ MotionEvent

7.2.7. 遥控器

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

7.3. 传感器

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

设备实现

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

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

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

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

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

设备实现

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

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

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

7.3.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 秒的时间段内收集的样本，按轴计算。
[SR] 强烈建议实现 TYPE_SIGNIFICANT_MOTION 复合传感器。
[SR] 如果在线加速度计校准可用，则强烈建议实现 TYPE_ACCELEROMETER_UNCALIBRATED 传感器。
应该实现 TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR、TYPE_STEP_COUNTER 复合传感器，如 Android SDK 文档中所述。
应该报告高达至少 200 Hz 的事件。
应该具有至少 16 位的分辨率。
如果在使用过程中特性发生变化，则应该在使用时进行校准和补偿，并在设备重启之间保留补偿参数。
应该进行温度补偿。
应该还实现 TYPE_ACCELEROMETER_UNCALIBRATED 传感器。

如果设备实现包括 3 轴加速度计以及任何 TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR、TYPE_STEP_COUNTER 复合传感器

[C-2-1] 它们的功耗总和必须始终小于 4 mW。
当设备处于动态或静态状态时，每个传感器的功耗应该低于 2 mW 和 0.5 mW。

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

[C-3-1] 必须实现 TYPE_GRAVITY 和 TYPE_LINEAR_ACCELERATION 复合传感器。
应该实现 TYPE_GAME_ROTATION_VECTOR 复合传感器。
[SR] 强烈建议现有和新的 Android 设备实现 TYPE_GAME_ROTATION_VECTOR 传感器。

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

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

7.3.2. 磁力计

设备实现应该包括 3 轴磁力计（指南针）。

如果设备实现包括 3 轴磁力计，则它们

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

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

[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

设备实现

应该包括 GPS/GNSS 接收器。

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

[C-1-1] 通过 LocationManager#requestLocationUpdate 请求时，必须支持至少 1 Hz 速率的位置输出。
[C-1-2] 当连接到 0.5 Mbps 或更快的速度互联网连接时，必须能够在 10 秒内（首次定位的快速时间）确定空旷天空条件下的位置（强信号、可忽略的多路径、HDOP < 2）。此要求通常通过使用某种形式的辅助或预测 GPS/GNSS 技术来实现，以最大限度地缩短 GPS/GNSS 定位时间（辅助数据包括参考时间、参考位置和卫星星历/时钟）。
- [SR] 在进行此类位置计算后，强烈建议设备能够在 10 秒内在空旷天空条件下确定其位置，当位置请求在初始位置计算后最多一小时重新启动时，即使在随后的请求是在没有数据连接的情况下和/或断电循环后发出，也能确定位置。
在空旷天空条件下确定位置后，当静止或以小于每秒平方米 1 米的加速度移动时
- [C-1-3] 必须能够至少在 95% 的时间内，将位置确定在 20 米以内，速度确定在每秒 0.5 米以内。
- [C-1-4] 必须通过 GnssStatus.Callback 同步跟踪和报告来自一个星座的至少 8 颗卫星。
- 应该能够同时跟踪来自多个星座（例如 GPS + 至少 Glonass、北斗、伽利略之一）的至少 24 颗卫星。
- [C-1-5] 必须通过测试 API ‘getGnssYearOfHardware’ 报告 GNSS 技术世代。
- [SR] 在紧急电话呼叫期间继续提供正常的 GPS/GNSS 位置输出。
- [SR] 报告来自跟踪的所有星座（如 GnssStatus 消息中报告）的 GNSS 测量值，SBAS 除外。
- [SR] 报告 GNSS 测量的 AGC 和频率。
- [SR] 将所有精度估计值（包括方位角、速度和垂直精度）作为每个 GPS 位置的一部分报告。
- [SR] 强烈建议对于通过测试 API LocationManager.getGnssYearOfHardware() 报告年份“2016”或“2017”的设备，尽可能满足更多额外的强制性要求。

如果设备实现包括 GPS/GNSS 接收器并通过 android.hardware.location.gps 功能标志和 LocationManager.getGnssYearOfHardware() 测试 API 报告年份“2016”或更新年份，则它们

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

如果设备实现包括 GPS/GNSS 接收器并通过 android.hardware.location.gps 功能标志和 LocationManager.getGnssYearOfHardware() 测试 API 报告年份“2017”或更新年份，则它们

[C-3-1] 必须在紧急电话呼叫期间继续提供正常的 GPS/GNSS 位置输出。
[C-3-2] 必须报告来自跟踪的所有星座（如 GnssStatus 消息中报告）的 GNSS 测量值，SBAS 除外。
[C-3-3] 必须报告 GNSS 测量的 AGC 和频率。
[C-3-4] 必须将所有精度估计值（包括方位角、速度和垂直精度）作为每个 GPS 位置的一部分报告。

7.3.4. 陀螺仪

设备实现

应该包括陀螺仪（角变化传感器）。
除非还包括 3 轴加速度计，否则不应包括陀螺仪传感器。

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

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

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

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

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

[C-3-1] 必须实现 TYPE_GRAVITY 和 TYPE_LINEAR_ACCELERATION 复合传感器。
[SR] 强烈建议现有和新的 Android 设备实现 TYPE_GAME_ROTATION_VECTOR 传感器。
应该实现 TYPE_GAME_ROTATION_VECTOR 复合传感器。

7.3.5. 气压计

设备实现应该包括气压计（环境气压传感器）。

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

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

7.3.6. 温度计

设备实现：可以包括环境温度计（温度传感器）。 可以但不应包括 CPU 温度传感器。

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

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

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

7.3.7. 光度计

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

7.3.8. 接近传感器

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

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

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

7.3.9. 高保真传感器

如果设备实现包括本节中定义的一组更高质量的传感器，并向第三方应用程序提供它们，则它们

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

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

[C-2-1] 必须具有 TYPE_ACCELEROMETER 传感器，该传感器
- 必须具有至少 -8g 到 +8g 的测量范围。
- 必须具有至少 1024 LSB/G 的测量分辨率。
- 必须具有 12.5 Hz 或更低的最小测量频率。
- 必须具有 400 Hz 或更高的最大测量频率。
- 必须具有不超过 400 uG/√Hz 的测量噪声。
- 必须实现此传感器的非唤醒形式，其缓冲能力至少为 3000 个传感器事件。
- 必须具有不差于 3 mW 的批量处理功耗。
- 应该具有来自 24 小时静态数据集的 <15 μg √Hz 的静态噪声偏置稳定性。
- 应该具有 ≤ +/- 1mg / °C 的偏置变化与温度的关系。
- 应该具有 ≤ 0.5% 的最佳拟合线非线性，以及 ≤ 0.03%/C° 的灵敏度变化与温度的关系。
- 应该具有白噪声频谱，以确保传感器噪声完整性的充分鉴定。
[C-2-2] 必须具有与 TYPE_ACCELEROMETER 相同质量要求的 TYPE_ACCELEROMETER_UNCALIBRATED。
[C-2-3] 必须具有 TYPE_GYROSCOPE 传感器，该传感器
- 必须具有至少 -1000 到 +1000 dps 的测量范围。
- 必须具有至少 16 LSB/dps 的测量分辨率。
- 必须具有 12.5 Hz 或更低的最小测量频率。
- 必须具有 400 Hz 或更高的最大测量频率。
- 必须具有不超过 0.014°/s/√Hz 的测量噪声。
- 应具有来自 24 小时静态数据集的 < 0.0002 °/s √Hz 的静态偏置稳定性。
- 应具有 ≤ +/- 0.05 °/ 秒 / °C 的偏置随温度变化。
- 应具有 ≤ 0.02% / °C 的灵敏度随温度变化。
- 应具有 ≤ 0.2% 的最佳拟合线非线性。
- 应具有 ≤ 0.007 °/s/√Hz 的噪声密度。
- 应该具有白噪声频谱，以确保传感器噪声完整性的充分鉴定。
- 在设备静止时，温度范围为 10 ~ 40 ℃ 时，校准误差应小于 0.002 rad/s。
[C-2-4] 必须具有与 TYPE_GYROSCOPE 相同质量要求的 TYPE_GYROSCOPE_UNCALIBRATED。
[C-2-5] 必须具有 TYPE_GEOMAGNETIC_FIELD 传感器，该传感器
- 必须具有至少 -900 到 +900 uT 的测量范围。
- 必须具有至少 5 LSB/uT 的测量分辨率。
- 必须具有 5 Hz 或更低的最小测量频率。
- 必须具有 50 Hz 或更高的最大测量频率。
- 必须具有不超过 0.5 uT 的测量噪声。
[C-2-6] 必须具有与 TYPE_GEOMAGNETIC_FIELD 相同质量要求的 TYPE_MAGNETIC_FIELD_UNCALIBRATED，此外
- 必须实现此传感器的非唤醒形式，且缓冲能力至少为 600 个传感器事件。
- 应该具有白噪声频谱，以确保传感器噪声完整性的充分鉴定。
[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 传感器，该传感器
- 必须实现此传感器的非唤醒形式，且缓冲能力至少为 300 个传感器事件。
- 必须具有不差于 4 mW 的批处理功耗。
[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 毫秒以内。
[C-2-14] 陀螺仪传感器事件时间戳必须与摄像头子系统在同一时基上，且误差在 1 毫秒以内。
[C-2-15] 必须在数据在任何上述物理传感器上可用后 5 毫秒内将样本传递给应用程序。
[C-2-16] 当启用以下传感器的任意组合时，在设备静态时，功耗不得高于 0.5 mW；在设备移动时，功耗不得高于 2.0 mW。
- SENSOR_TYPE_SIGNIFICANT_MOTION
- SENSOR_TYPE_STEP_DETECTOR
- SENSOR_TYPE_STEP_COUNTER
- SENSOR_TILT_DETECTORS
[C-2-17] 可以具有 TYPE_PROXIMITY 传感器，但如果存在，则必须具有至少 100 个传感器事件的最小缓冲能力。

请注意，本节中的所有功耗要求均不包括应用处理器的功耗。它包括整个传感器链（传感器、任何支持电路、任何专用传感器处理系统等）消耗的功率。

如果设备实现包括直接传感器支持，则它们

[C-3-1] 必须通过 isDirectChannelTypeSupported 和 getHighestDirectReportRateLevel API 正确声明对直接通道类型和直接报告速率级别的支持。
[C-3-2] 对于声明支持传感器直接通道的所有传感器，必须至少支持两种传感器直接通道类型之一
TYPE_HARDWARE_BUFFER
TYPE_MEMORY_FILE
对于以下类型的基本传感器（非唤醒变体），应支持通过传感器直接通道进行事件报告
TYPE_ACCELEROMETER
TYPE_ACCELEROMETER_UNCALIBRATED
TYPE_GYROSCOPE
TYPE_GYROSCOPE_UNCALIBRATED
TYPE_MAGNETIC_FIELD
TYPE_MAGNETIC_FIELD_UNCALIBRATED

7.3.10. 指纹传感器

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

应包括指纹传感器。

如果设备实现包括指纹传感器并向第三方应用开放传感器，则它们

[C-1-1] 必须声明支持 android.hardware.fingerprint 功能。
[C-1-2] 必须完全实现 Android SDK 文档中描述的相应 API。
[C-1-3] 必须具有不高于 0.002% 的错误接受率。
[SR] 强烈建议具有不高于 7% 的欺骗和冒名顶替接受率。
[C-1-4] 如果欺骗和冒名顶替接受率高于 7%，则必须披露此模式可能不如强 PIN 码、图案或密码安全，并清楚列举启用它的风险。
[C-1-5] 对于指纹验证，在五次错误尝试后，必须限制尝试频率至少 30 秒。
[C-1-6] 必须具有硬件支持的密钥库实现，并在可信执行环境 (TEE) 或具有到 TEE 的安全通道的芯片上执行指纹匹配。
[C-1-7] 必须对所有可识别的指纹数据进行加密和密码学身份验证，以使其无法在可信执行环境 (TEE) 外部获取、读取或更改，如 Android 开源项目站点上的实现指南中所述。
[C-1-8] 必须防止在用户未先通过确认现有设备凭据（PIN 码/图案/密码）或添加由 TEE 保护的新设备凭据来建立信任链的情况下添加指纹；Android 开源项目实现提供了框架中执行此操作的机制。
[C-1-9] 不得使第三方应用程序能够区分各个指纹。
[C-1-10] 必须遵守 DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT 标志。
[C-1-11] 当从 Android 6.0 之前的版本升级时，必须安全地迁移指纹数据以满足上述要求或将其删除。
[SR] 强烈建议具有低于 10% 的错误拒绝率，在设备上测量。
[SR] 强烈建议对于一个已注册的指纹，从触摸指纹传感器到屏幕解锁的延迟低于 1 秒。
应使用 Android 开源项目中提供的 Android 指纹图标。

7.3.11. 仅限 Android Automotive 的传感器

特定于汽车的传感器在 android.car.CarSensorManager API 中定义。

7.3.11.1. 当前档位

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

7.3.11.2. 日夜模式

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

7.3.11.3. 驾驶状态

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

7.3.11.4. 轮速

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

7.3.12. 姿势传感器

设备实现

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

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

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

7.4. 数据连接

7.4.1. 电话

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

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

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

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

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

[C-2-1] 必须将所有 API 实现为无操作。

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

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

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

7.4.2. IEEE 802.11 (Wi-Fi)

设备实现

应包括对一种或多种形式的 802.11 的支持。

如果设备实现包括对 802.11 的支持并向第三方应用程序公开该功能，则它们

[C-1-1] 必须实现相应的 Android API。
[C-1-2] 必须报告硬件功能标志 android.hardware.wifi。
[C-1-3] 必须实现 SDK 文档中描述的多播 API。
[C-1-4] 必须支持多播 DNS (mDNS)，并且在任何操作时间（包括
- 即使屏幕未处于活动状态时）都不得过滤 mDNS 数据包 (224.0.0.251)。
- 对于 Android 电视设备实现，即使在待机电源状态下也是如此。
STA 断开连接时，应在每次扫描开始时随机化探测请求帧的源 MAC 地址和序列号。
- 组成一次扫描的每组探测请求帧应使用一个一致的 MAC 地址（不应在扫描过程中随机化 MAC 地址）。
- 探测请求序列号应在扫描中的探测请求之间正常迭代（顺序）。
- 探测请求序列号应在一次扫描的最后一个探测请求和下一次扫描的第一个探测请求之间随机化。
STA 断开连接时，应仅允许探测请求帧中的以下信息元素
- SSID 参数集 (0)
- DS 参数集 (3)

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 操作。
应支持 Wi-Fi 和 Wi-Fi Direct 操作并发。

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

设备实现

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

如果设备实现包括对 TDLS 的支持，并且 TDLS 由 WiFiManager API 启用，则它们

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

7.4.2.3. Wi-Fi Aware

设备实现

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

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

[C-1-1] 必须实现 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 管理接口地址。

7.4.2.4. Wi-Fi Passpoint

设备实现

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

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

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

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

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

7.4.3. 蓝牙

如果设备实现支持蓝牙音频配置文件，则它们

应支持高级音频编解码器和蓝牙音频编解码器（例如 LDAC）。

如果设备实现声明 android.hardware.vr.high_performance 功能，则它们

[C-1-1] 必须支持蓝牙 4.2 和蓝牙 LE 数据长度扩展。

Android 包括对蓝牙和蓝牙低功耗的支持。

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

[C-2-1] 必须声明相关的平台功能（分别为 android.hardware.bluetooth 和 android.hardware.bluetooth_le）并实现平台 API。
应根据设备的情况实现相关的蓝牙配置文件，例如 A2DP、AVCP、OBEX 等。

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

[C-3-1] 必须声明硬件功能 android.hardware.bluetooth_le。
[C-3-2] 必须启用基于 GATT（通用属性配置文件）的蓝牙 API，如 SDK 文档和 android.bluetooth 中所述。
[C-3-3] 必须报告 BluetoothAdapter.isOffloadedFilteringSupported() 的正确值，以指示是否实现了 ScanFilter API 类的过滤逻辑。
[C-3-4] 必须报告 BluetoothAdapter.isMultipleAdvertisementSupported() 的正确值，以指示是否支持低功耗广告。
在实现 ScanFilter API 时，应支持将过滤逻辑卸载到蓝牙芯片组。
应支持将批量扫描卸载到蓝牙芯片组。
应支持至少 4 个插槽的多重广告。
[SR] 强烈建议实现可解析的私有地址 (RPA) 超时时间，不超过 15 分钟，并在超时时轮换地址以保护用户隐私。

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 论坛读取器/写入器（由 NFC 论坛技术规范 NFCForum-TS-DigitalProtocol-1.0 定义）
NfcA (ISO14443-3A)
NfcB (ISO14443-3B)
NfcF (JIS X 6319-4)
IsoDep (ISO 14443-4)
NFC 论坛标签类型 1、2、3、4、5（由 NFC 论坛定义）
[SR] 强烈建议能够通过以下 NFC 标准读取和写入 NDEF 消息以及原始数据。请注意，虽然 NFC 标准被声明为强烈建议，但未来版本的兼容性定义计划将这些更改为必须。这些标准在此版本中是可选的，但在未来版本中将是必需的。强烈鼓励运行此版本 Android 的现有设备和新设备现在就满足这些要求，以便它们能够升级到未来的平台版本。
[C-1-3] 必须能够通过以下对等标准和协议传输和接收数据
ISO 18092
LLCP 1.2（由 NFC 论坛定义）
SDP 1.0（由 NFC 论坛定义）
NDEF 推送协议
SNEP 1.0（由 NFC 论坛定义）
[C-1-4] 必须包括对 Android Beam 的支持，并且应默认启用 Android Beam。
[C-1-5] 当 Android Beam 启用或另一个专有 NFC P2p 模式开启时，必须能够使用 Android Beam 发送和接收。
[C-1-6] 必须实现 SNEP 默认服务器。SNEP 默认服务器接收的有效 NDEF 消息必须使用 android.nfc.ACTION_NDEF_DISCOVERED Intent 分派到应用程序。在设置中禁用 Android Beam 不得禁用传入 NDEF 消息的分派。
[C-1-7] 必须遵守 android.settings.NFCSHARING_SETTINGS Intent 以显示 NFC 共享设置。
[C-1-8] 必须实现 NPP 服务器。NPP 服务器接收的消息必须以与 SNEP 默认服务器相同的方式处理。
[C-1-9] 必须实现 SNEP 客户端，并在 Android Beam 启用时尝试将出站 P2P NDEF 发送到默认 SNEP 服务器。如果未找到默认 SNEP 服务器，则客户端必须尝试发送到 NPP 服务器。
[C-1-10] 必须允许前台活动使用 android.nfc.NfcAdapter.setNdefPushMessage、android.nfc.NfcAdapter.setNdefPushMessageCallback 和 android.nfc.NfcAdapter.enableForegroundNdefPush 设置出站 P2P NDEF 消息。
在发送出站 P2P NDEF 消息之前，应使用手势或屏幕确认，例如“触摸以共享”。
[C-1-11] 当设备支持蓝牙对象推送配置文件时，必须支持 NFC 连接切换到蓝牙。
[C-1-12] 当使用 android.nfc.NfcAdapter.setBeamPushUris 时，必须支持连接切换到蓝牙，通过实现 NFC 论坛的“连接切换版本 1.2”和“使用 NFC 版本 1.0 的蓝牙安全简单配对”规范。此类实现必须实现服务名称为“urn:nfc:sn:handover”的切换 LLCP 服务，以便通过 NFC 交换切换请求/选择记录，并且必须使用蓝牙对象推送配置文件进行实际的蓝牙数据传输。出于遗留原因（为了与 Android 4.1 设备保持兼容性），该实现仍应接受 SNEP GET 请求以通过 NFC 交换切换请求/选择记录。但是，实现本身不应发送 SNEP GET 请求来执行连接切换。
[C-1-13] 在 NFC 发现模式下，必须轮询所有支持的技术。
当设备唤醒且屏幕处于活动状态且锁屏解锁时，应处于 NFC 发现模式。
应能够读取 Thinfilm NFC 条形码产品的条形码和 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、MIFARE Classic 上的 NDEF），则它们

[C-4-1] 必须实现 Android SDK 文档中描述的相应 Android API。
[C-4-2] 必须从 android.content.pm.PackageManager.hasSystemFeature() 方法报告功能 com.nxp.mifare。请注意，这不是标准的 Android 功能，因此不会作为常量出现在 android.content.pm.PackageManager 类中。

7.4.5. 最低网络能力

设备实现

[C-0-1] 必须包括对一种或多种形式的数据网络的支持。具体而言，设备实现必须包括对至少一种数据标准的支持，该标准能够达到 200Kbit/秒或更高。满足此要求的技术示例包括 EDGE、HSPA、EV-DO、802.11g、以太网、蓝牙 PAN 等。
[C-0-2] 必须包括 IPv6 网络堆栈，并使用托管 API（例如 java.net.Socket 和 java.net.URLConnection）以及本机 API（例如 AF_INET6 套接字）支持 IPv6 通信。
[C-0-3] 必须默认启用 IPv6。
必须确保 IPv6 通信与 IPv4 一样可靠，例如。
[C-0-4] 必须在 Doze 模式下保持 IPv6 连接。
[C-0-5] 速率限制不得导致设备在任何使用至少 180 秒 RA 生存期的 IPv6 兼容网络上丢失 IPv6 连接。
当物理网络标准（例如以太网）是主要数据连接时，还应包括对至少一种常见的无线数据标准（例如 802.11 (Wi-Fi)）的支持
可以实现多种形式的数据连接。

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

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

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

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

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

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

[C-3-1] 当设备同时连接到多个网络（例如，Wi-Fi 和蜂窝数据）时，必须同时满足设备连接到的每个网络上的这些要求。
应支持蜂窝数据上的 IPv6 操作（仅 IPv6 和可能的双栈）。

7.4.6. 同步设置

设备实现

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

7.4.7. 数据保护程序

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

[SR] 强烈建议提供数据保护程序模式。

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

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

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

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

7.5. 摄像头

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

[C-1-1] 必须声明 android.hardware.camera.any 功能标志。
[C-1-2] 当摄像头打开用于基本预览和静止图像捕获时，应用程序必须能够同时分配 3 个 RGBA_8888 位图，这些位图的大小等于设备上最大分辨率摄像头传感器生成的图像大小。

7.5.1. 后置摄像头

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

设备实现

应包括后置摄像头。

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

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

如果摄像头包括闪光灯

[C-2-1] 除非应用程序已通过启用 Camera.Parameters 对象的 FLASH_MODE_AUTO 或 FLASH_MODE_ON 属性显式启用闪光灯，否则当 android.hardware.Camera.PreviewCallback 实例已在摄像头预览表面上注册时，闪光灯不得点亮。请注意，此约束不适用于设备的内置系统摄像头应用程序，而仅适用于使用 Camera.PreviewCallback 的第三方应用程序。

7.5.2. 前置摄像头

前置摄像头是位于设备显示屏同一侧的摄像头；也就是说，通常用于拍摄用户图像的摄像头，例如用于视频会议和类似应用。

设备实现

可以包括前置摄像头

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

[C-1-1] 必须报告功能标志 android.hardware.camera.any 和 android.hardware.camera.front。
[C-1-2] 必须具有至少 VGA (640x480 像素) 的分辨率。
[C-1-3] 不得使用前置摄像头作为 Camera API 的默认摄像头，并且不得配置 API 将前置摄像头视为默认后置摄像头，即使它是设备上唯一的摄像头也是如此。
[C-1-5] 当当前应用程序已通过调用 android.hardware.Camera.setDisplayOrientation() 方法显式请求旋转摄像头显示时，摄像头预览必须相对于应用程序指定的方向水平镜像。相反，当当前应用程序未通过调用 android.hardware.Camera.setDisplayOrientation() 方法显式请求旋转摄像头显示时，预览必须沿设备的默认水平轴镜像。
[C-1-6] 不得镜像返回到应用程序回调或提交到媒体存储的最终捕获的静止图像或视频流。
[C-1-7] 必须以与摄像头预览图像流相同的方式镜像后视图显示的图像。
可以包括 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 或更高版本)。
应支持视频压缩（例如 MJPEG），以实现高质量未编码流（即原始或独立压缩的图片流）的传输。
可以支持多个摄像头。
可以支持基于摄像头的视频编码。如果支持，则设备实现必须可访问同步的未编码/MJPEG 流（QVGA 或更高分辨率）。

7.5.4. 摄像头 API 行为

Android 包含两个 API 软件包来访问摄像头，较新的 android.hardware.camera2 API 向应用公开更底层的摄像头控制，包括高效的零拷贝突发/流式传输流程以及曝光、增益、白平衡增益、色彩转换、降噪、锐化等逐帧控制。

旧的 API 软件包 android.hardware.Camera 在 Android 5.0 中被标记为已弃用，但它仍应可供应用使用。Android 设备实现必须确保按照本节和 Android SDK 中的描述继续支持该 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] 对于 android.hardware.Camera 的前置和后置摄像头，必须支持 YV12 格式（由 android.graphics.ImageFormat.YV12 常量表示）用于摄像头预览。（硬件视频编码器和摄像头可以使用任何原生像素格式，但设备实现必须支持转换为 YV12。）
[C-0-4] 对于声明 REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE 功能（在 android.request.availableCapabilities 中）的 android.hardware.camera2 设备，必须支持 android.hardware.ImageFormat.YUV_420_888 和 android.hardware.ImageFormat.JPEG 格式作为通过 android.media.ImageReader API 的输出。
[C-0-5] 必须仍然实现 Android SDK 文档中包含的完整 Camera API，无论设备是否包含硬件自动对焦或其他功能。例如，即使缺少自动对焦功能的摄像头，必须仍然调用任何已注册的 android.hardware.Camera.AutoFocusCallback 实例（即使这与非自动对焦摄像头无关。）请注意，这适用于前置摄像头；例如，即使大多数前置摄像头不支持自动对焦，API 回调也必须按照描述进行“伪造”。
[C-0-6] 必须识别并遵守在 android.hardware.Camera.Parameters 类上定义为常量的每个参数名称。相反，设备实现不得遵守或识别传递给 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。

7.5.5. 摄像头方向

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

[C-1-1] 必须定向，使摄像头的长尺寸与屏幕的长尺寸对齐。也就是说，当设备处于横向方向时，摄像头必须以横向方向捕获图像。这适用于设备的自然方向，即适用于横向主设备以及纵向主设备。

7.6. 内存和存储

7.6.1. 最低内存和存储

设备实现

[C-0-1] 必须包含下载管理器，应用程序可以使用该管理器下载数据文件，并且它们必须能够将至少 100MB 大小的单个文件下载到默认“缓存”位置。

7.6.2. 应用程序共享存储

设备实现

[C-0-1] 必须提供存储空间供应用程序共享，通常也称为“共享外部存储”、“应用程序共享存储”或其挂载的 Linux 路径“/sdcard”。
[C-0-2] 必须配置为默认挂载共享存储，换句话说，即“开箱即用”，无论存储是在内部存储组件还是可移动存储介质（例如安全数字卡插槽）上实现的。
[C-0-3] 必须将应用程序共享存储直接挂载到 Linux 路径 sdcard 上，或者包含从 sdcard 到实际挂载点的 Linux 符号链接。
[C-0-4] 必须对此共享存储强制执行 android.permission.WRITE_EXTERNAL_STORAGE 权限，如 SDK 中所述。否则，获得该权限的任何应用程序都必须可写入共享存储。

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

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

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

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

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

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

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

[C-3-1] 除了写入其特定于软件包的目录或 ACTION_OPEN_DOCUMENT_TREE intent 返回的 URI 内之外，必须仅允许预安装的和特权 Android 应用程序使用 WRITE_EXTERNAL_STORAGE 权限写入辅助外部存储。

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

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

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

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

7.6.3. 可采纳存储

如果设备预计具有移动性，而不是电视，则设备实现

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

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

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

7.7. USB

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

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

7.7.1. USB 外围设备模式

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

[C-1-1] 该端口必须可连接到具有标准 A 型或 C 型 USB 端口的 USB 主机。
[C-1-2] 必须通过 android.os.Build.SERIAL 报告 USB 标准设备描述符中 iSerialNumber 的正确值。
[C-1-3] 如果设备支持 C 型 USB，必须按照 C 型电阻器标准检测 1.5A 和 3.0A 充电器，并且必须检测广告中的更改。
[SR] 该端口应该使用 micro-B、micro-AB 或 C 型 USB 外形尺寸。现有和新的 Android 设备 强烈建议满足这些要求，以便它们能够升级到未来的平台版本。
[SR] 该端口应该位于设备底部（根据自然方向），或者为所有应用（包括主屏幕）启用软件屏幕旋转，以便当设备端口位于底部时，显示屏能够正确绘制。现有和新的 Android 设备 强烈建议满足这些要求，以便它们能够升级到未来的平台版本。
[SR] 应该实现支持在 HS 啁啾和流量期间汲取 1.5 A 电流，如 USB 电池充电规范修订版 1.2 中所述。现有和新的 Android 设备 强烈建议满足这些要求，以便它们能够升级到未来的平台版本。
[SR] 强烈建议 不支持修改超出默认水平的 Vbus 电压或更改接收器/源角色的专有充电方法，因为这可能会导致与支持标准 USB 电源交付方法的充电器或设备的互操作性问题。虽然这被称为“强烈建议”，但在未来的 Android 版本中，我们可能会要求所有 C 型设备都支持与标准 C 型充电器的完全互操作性。
[SR] 当设备支持 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 端口的电缆（USB C 型设备）。
- 具有设备上的 A 型端口，或随附将设备上的专有端口适配到标准 A 型 USB 端口的电缆。
- 具有设备上的 micro-AB 端口，应该随附将适配到标准 A 型端口的电缆。
[C-1-3] 不得随附将 USB A 型或 micro-AB 端口转换为 C 型端口（插座）的适配器。
[SR] 强烈建议 实现 USB 音频类，如 Android SDK 文档中所述。
应该支持在主机模式下为连接的 USB 外围设备充电；对于 C 型 USB 连接器，宣传至少 1.5A 的源电流，如 USB C 型电缆和连接器规范修订版 1.2 的终止参数部分中所述，或者对于 Micro-AB 连接器，使用 USB 电池充电规范修订版 1.2 中规定的充电下游端口 (CDP) 输出电流范围。
应该实现并支持 USB C 型标准。

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

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

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

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

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

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

7.8. 音频

7.8.1. 麦克风

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

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

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

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

7.8.2. 音频输出

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

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

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

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

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

7.8.2.1. 模拟音频端口

为了与整个 Android 生态系统中使用 3.5 毫米音频插头的耳机和其他音频配件兼容，如果设备实现包含一个或多个模拟音频端口，则至少一个音频端口应该是 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 之间的麦克风偏置电压。
[SR] 强烈建议 检测并映射到音频插头上麦克风和接地导体之间以下范围的等效阻抗的键代码：
- 110-180 欧姆： KEYCODE_VOICE_ASSIST
应该支持具有 OMTP 引脚排列顺序的音频插头。
应该支持从带有麦克风的立体声耳机进行音频录制。

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

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

7.8.3. 近超声波

近超声波音频是指 18.5 kHz 到 20 kHz 频带。

设备实现

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

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

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

如果 PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND 为“true”

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

7.9. 虚拟现实

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

7.9.1. 虚拟现实模式

Android 包含对 VR 模式的支持，VR 模式是一项功能，用于处理通知的立体渲染，并在 VR 应用程序具有用户焦点时禁用单眼系统 UI 组件。

7.9.2. 虚拟现实高性能

如果设备实现通过 android.hardware.vr.high_performance 功能标志标识对长时间用户使用的高性能 VR 的支持，则它们

[C-1-1] 必须至少具有 2 个物理核心。
[C-1-2] 必须声明 android.software.vr.mode feature。
[C-1-3] 必须支持持续性能模式。
[C-1-4] 必须支持 OpenGL ES 3.2。
[C-1-5] 必须支持 Vulkan Hardware Level 0，并且应该支持 Vulkan Hardware 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 扩展列表中公开这些扩展。
[C-1-7] GPU 和显示屏必须能够同步对共享前缓冲区的访问，以便使用两个渲染上下文以 60fps 进行 VR 内容的交替眼渲染将显示，且没有可见的撕裂伪影。
[C-1-8] 必须实现 GL_EXT_multisampled_render_to_texture、GL_OVR_multiview、GL_OVR_multiview2、GL_OVR_multiview_multisampled_render_to_texture、GL_EXT_protected_textures、GL_EXT_EGL_image_array、GL_EXT_external_buffer，并在可用的 GL 扩展列表中公开这些扩展。
[C-1-9] 必须实现对 AHardwareBuffer 标志 AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER 和 AHARDWAREBUFFER_USAGE_SENSOR_DIRECT_DATA 的支持，如 NDK 中所述。
[C-1-10] 必须实现对具有多个层的 AHardwareBuffers 的支持。
[C-1-11] 必须支持 H.264 解码，至少达到 3840x2160@30fps-40Mbps（相当于 4 个 1920x1080@30fps-10Mbps 实例或 2 个 1920x1080@60fps-20Mbps 实例）。
[C-1-12] 必须支持 HEVC 和 VP9，必须能够解码至少 1920x1080@30fps-10Mbps，并且应该能够解码 3840x2160@30fps-20Mbps（相当于 4 个 1920x1080@30fps-5Mbps 实例）。
[C-1-13] 必须支持 HardwarePropertiesManager.getDeviceTemperatures API，并返回皮肤温度的准确值。
[C-1-14] 必须具有嵌入式屏幕，并且其分辨率必须至少为 FullHD (1080p)，并且 强烈建议 为 QuadHD (1440p) 或更高。
[C-1-15] 显示屏在 VR 模式下必须以至少 60 Hz 的频率更新。
[C-1-16] 显示屏延迟（在灰到灰、白到黑和黑到白切换时间上测量）必须 ≤ 6 毫秒。
[C-1-17] 显示屏必须支持低持久性模式，持久性 ≤ 5 毫秒，持久性定义为像素发光的时间量。
[C-1-18] 必须支持蓝牙 4.2 和蓝牙 LE 数据长度扩展第 7.4.3 节。
[C-1-19] 必须支持并正确报告所有以下默认传感器类型的直接通道类型。
- TYPE_ACCELEROMETER
- TYPE_ACCELEROMETER_UNCALIBRATED
- TYPE_GYROSCOPE
- TYPE_GYROSCOPE_UNCALIBRATED
- TYPE_MAGNETIC_FIELD
- TYPE_MAGNETIC_FIELD_UNCALIBRATED
[C-1-20] 必须支持上面列出的所有直接通道类型的 TYPE_HARDWARE_BUFFER 直接通道类型。
[SR] 强烈建议 支持 android.hardware.sensor.hifi_sensors 功能，并且必须满足 android.hardware.hifi_sensors 的陀螺仪、加速度计和磁力计相关要求。
可以为前台应用程序提供独占核心，并且可以支持 Process.getExclusiveCores API 以返回专用于顶部前台应用程序的 CPU 核心编号。如果支持独占核心，则该核心不得允许任何其他用户空间进程在其上运行（应用程序使用的设备驱动程序除外），但可以允许运行一些必要的内核进程。

8. 性能和功耗

一些最低性能和功耗标准对于用户体验至关重要，并且会影响开发人员在开发应用程序时的基线假设。

8.1. 用户体验一致性

如果存在某些最低要求以确保应用程序和游戏的一致帧速率和响应时间，则可以为最终用户提供流畅的用户界面。设备实现可以根据设备类型，对于用户界面延迟和任务切换具有可测量的要求，如第 2 节中所述。

8.2. 文件 I/O 访问性能

在应用程序私有数据存储 (/data 分区) 上为一致的文件访问性能提供通用基线，使应用程序开发人员能够设置适当的期望，这将有助于他们的软件设计。设备实现可以根据设备类型，对于以下读取和写入操作具有第 2 节中描述的某些要求：

顺序写入性能。通过使用 10MB 写入缓冲区写入 256MB 文件来测量。
随机写入性能。通过使用 4KB 写入缓冲区写入 256MB 文件来测量。
顺序读取性能。通过使用 10MB 写入缓冲区读取 256MB 文件来测量。
随机读取性能。通过使用 4KB 写入缓冲区读取 256MB 文件来测量。

8.3. 省电模式

Android 包含应用待机和 Doze 省电模式，以优化电池使用。[SR] 强烈建议所有被排除在这些模式之外的应用对最终用户可见。 [SR] 强烈建议这些省电模式的触发、维护、唤醒算法以及全局系统设置的使用不要偏离 Android 开源项目。

除了省电模式，Android 设备实现可以（MAY）实现由高级配置和电源接口 (ACPI) 定义的 4 种睡眠电源状态中的任何一种或全部。

如果设备实现实现了 ACPI 定义的 S3 和 S4 电源状态，则它们

[C-1-1] 仅当关闭设备物理组成部分的盖子时，才必须（MUST）进入这些状态。

8.4. 功耗核算

更准确的功耗核算和报告为应用开发者提供了优化应用功耗模式的激励和工具。

设备实现

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

8.5. 一致的性能

对于高性能、长时间运行的应用，性能可能会大幅波动，这可能是由于在后台运行的其他应用或由于温度限制导致的 CPU 节流。Android 包含程序接口，以便在设备具备能力时，顶层前台应用可以请求系统优化资源分配，以解决此类波动。

设备实现

[C-0-1] 必须（MUST）通过 PowerManager.isSustainedPerformanceModeSupported() API 方法准确报告对持续性能模式的支持。
应该（SHOULD）支持持续性能模式。

如果设备实现报告支持持续性能模式，则它们

[C-1-1] 当顶层前台应用请求时，必须（MUST）为其提供至少 30 分钟的持续性能水平。
[C-1-2] 必须（MUST）遵循 Window.setSustainedPerformanceMode() API 和其他相关 API。

如果设备实现包含两个或更多 CPU 核心，则它们

应该（SHOULD）提供至少一个可供顶层前台应用保留的独占核心。

如果设备实现支持为顶层前台应用保留一个独占核心，则它们

[C-2-1] 必须（MUST）通过 Process.getExclusiveCores() API 方法报告可供顶层前台应用保留的独占核心的 ID 编号。
[C-2-2] 除应用使用的设备驱动程序外，必须（MUST NOT）允许任何用户空间进程在独占核心上运行，但可以（MAY）根据需要允许一些内核进程运行。

如果设备实现不支持独占核心，则它们

[C-3-1] 必须（MUST）通过 Process.getExclusiveCores() API 方法返回一个空列表。

9. 安全模型兼容性

设备实现

[C-0-1] 必须（MUST）实现与 Android 平台安全模型一致的安全模型，如 Android 开发者文档中安全和权限参考文档的 API 中所定义。
[C-0-2] 必须（MUST）支持安装自签名应用，而无需任何第三方/机构的额外权限/证书。具体而言，兼容设备必须（MUST）支持以下小节中描述的安全机制。

9.1. 权限

设备实现

[C-0-1] 必须（MUST）支持 Android 权限模型，如 Android 开发者文档中所定义。具体而言，它们必须（MUST）强制执行 SDK 文档中描述的每个权限；不得省略、更改或忽略任何权限。
可以（MAY）添加额外的权限，前提是新的权限 ID 字符串不在 android.\* 命名空间中。
[C-0-2] protectionLevel 为 PROTECTION_FLAG_PRIVILEGED 的权限必须（MUST）仅授予预加载在系统镜像特权路径中的应用，并且在每个应用的显式允许列表权限的子集中。AOSP 实现通过从 etc/permissions/ 路径中的文件读取并遵守每个应用的允许列表权限，并使用 system/priv-app 路径作为特权路径来满足此要求。

protection level 为 dangerous 的权限是运行时权限。 targetSdkVersion > 22 的应用在运行时请求它们。

设备实现

[C-0-3] 必须（MUST）显示一个专用界面，供用户决定是否授予请求的运行时权限，并提供一个界面供用户管理运行时权限。
[C-0-4] 必须（MUST）对这两个用户界面都只有一个实现。
[C-0-5] 除非满足以下条件，否则不得（MUST NOT）向预装应用授予任何运行时权限
在应用使用运行时权限之前，可以获得用户的同意
运行时权限与 intent 模式相关联，预装应用被设置为该 intent 模式的默认处理程序

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

[C-1-1] 强烈建议（STRONGLY RECOMMENDED）提供用户可访问的机制，以响应声明 android.permission.PACKAGE_USAGE_STATS 权限的应用的 android.settings.ACTION_USAGE_ACCESS_SETTINGS intent，从而授予或撤销对使用情况统计信息的访问权限。

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

[C-2-1] 仍然必须（MUST）有一个 activity 来处理 android.settings.ACTION_USAGE_ACCESS_SETTINGS intent 模式，但必须（MUST）将其实现为 no-op，即具有与用户拒绝访问时相同的行为。

9.2. UID 和进程隔离

设备实现

[C-0-1] 必须（MUST）支持 Android 应用沙箱模型，其中每个应用都以唯一的 Unix 风格 UID 并在单独的进程中运行。
[C-0-2] 如果应用已正确签名和构建，则必须（MUST）支持以相同的 Linux 用户 ID 运行多个应用，如安全和权限参考中所定义。

9.3. 文件系统权限

设备实现

[C-0-1] 必须（MUST）支持 Android 文件访问权限模型，如安全和权限参考中所定义。

9.4. 备选执行环境

即使设备实现包含使用 Dalvik 可执行格式或本机代码以外的其他软件或技术来执行应用的运行时环境，它们也必须（MUST）保持 Android 安全和权限模型的一致性。换句话说

[C-0-1] 备选运行时本身必须（MUST）是 Android 应用，并遵守标准的 Android 安全模型，如第 9 节的其他地方所述。
[C-0-2] 不得（MUST NOT）授予备选运行时访问权限，以访问受运行时 AndroidManifest.xml 文件中通过 <uses-permission> 机制未请求的权限保护的资源。
[C-0-3] 不得（MUST NOT）允许备选运行时允许应用使用受限于系统应用的 Android 权限保护的功能。
[C-0-4] 备选运行时必须（MUST）遵守 Android 沙箱模型，并且使用备选运行时安装的应用不得（MUST NOT）重用设备上安装的任何其他应用的沙箱，除非通过共享用户 ID 和签名证书的标准 Android 机制。
[C-0-5] 备选运行时不得（MUST NOT）启动、授予或被授予访问权限，以访问与其他 Android 应用对应的沙箱。
[C-0-6] 备选运行时不得（MUST NOT）以超级用户 (root) 或任何其他用户 ID 的任何特权启动、被授予或授予其他应用任何特权。
[C-0-7] 当备选运行时的 .apk 文件包含在设备实现的系统镜像中时，必须（MUST）使用与用于签名设备实现中包含的其他应用的密钥不同的密钥进行签名。
[C-0-8] 安装应用时，备选运行时必须（MUST）获得用户对应用使用的 Android 权限的同意。
[C-0-9] 当应用需要使用设备资源（例如摄像头、GPS 等），且该资源存在对应的 Android 权限时，备选运行时必须（MUST）告知用户，应用将能够访问该资源。
[C-0-10] 当运行时环境不以这种方式记录应用功能时，运行时环境必须（MUST）在安装任何使用该运行时的应用时，列出运行时本身持有的所有权限。
备选运行时应该（SHOULD）通过 PackageManager 将应用安装到单独的 Android 沙箱（Linux 用户 ID 等）中。
备选运行时可以（MAY）提供一个由所有使用该备选运行时的应用共享的 Android 沙箱。

9.5. 多用户支持

Android 包含对多用户的支持，并提供对完全用户隔离的支持。

如果设备实现使用可移动媒体作为主要外部存储，则可以（MAY）但应该（SHOULD NOT）启用多用户。

如果设备实现包含多用户，则它们

[C-1-1] 必须（MUST）满足与多用户支持相关的以下要求。
[C-1-2] 对于每个用户，必须（MUST）实现与 Android 平台安全模型一致的安全模型，如安全和权限参考文档的 API 中所定义。
[C-1-3] 对于每个用户实例，必须（MUST）具有单独且隔离的共享应用存储（也称为 /sdcard）目录。
[C-1-4] 必须（MUST）确保给定用户拥有和代表其运行的应用无法列出、读取或写入任何其他用户拥有的文件，即使两个用户的数据都存储在同一卷或文件系统上。
[C-1-5] 如果设备实现使用可移动媒体作为外部存储 API，则当启用多用户时，必须（MUST）使用仅存储在系统可访问的不可移动媒体上的密钥加密 SD 卡的内容。由于这将使主机 PC 无法读取媒体，因此设备实现将需要切换到 MTP 或类似系统，以便为主机 PC 提供对当前用户数据的访问权限。

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

[C-2-1] 必须（MUST）支持受限配置文件，该功能允许设备所有者管理设备上的其他用户及其功能。借助受限配置文件，设备所有者可以快速为其他用户设置单独的工作环境，并能够管理这些环境中可用应用的更细粒度的限制。

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

[C-3-1] 不得（MUST NOT）支持受限配置文件，但必须（MUST）与 AOSP 对启用/禁用其他用户访问语音通话和短信的控件的实现保持一致。

9.6. 高级短信警告

Android 包含对警告用户任何外发高级短信的支持。高级短信是发送到运营商注册的服务的短信，可能会向用户收费。

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

[C-1-1] 在向设备中 /data/misc/sms/codes.xml 文件中定义的正则表达式标识的号码发送短信之前，必须（MUST）警告用户。上游 Android 开源项目提供了满足此要求的实现。

9.7. 内核安全特性

Android 沙箱包含使用安全增强型 Linux (SELinux) 强制访问控制 (MAC) 系统、seccomp 沙箱和其他 Linux 内核安全特性的功能。设备实现

[C-0-1] 即使在 Android 框架下实现了 SELinux 或任何其他安全特性，也必须（MUST）保持与现有应用的兼容性。
[C-0-2] 当检测到安全违规并被 Android 框架下实现的安全特性成功阻止时，不得（MUST NOT）具有可见的用户界面，但是当发生未阻止的安全违规并导致成功利用时，可以（MAY）具有可见的用户界面。
[C-0-3] 不得（MUST NOT）使 SELinux 或任何其他在 Android 框架下实现的安全特性可供用户或应用开发者配置。
[C-0-4] 不得（MUST NOT）允许可以通过 API（例如设备管理 API）影响另一个应用的应用配置破坏兼容性的策略。
[C-0-5] 必须（MUST）将媒体框架拆分为多个进程，以便可以更精细地为每个进程授予访问权限，如 Android 开源项目站点所述。
[C-0-6] 必须（MUST）实现内核应用沙箱机制，该机制允许使用来自多线程程序的可配置策略过滤系统调用。上游 Android 开源项目通过启用具有线程组同步 (TSYNC) 的 seccomp-BPF 来满足此要求，如 source.android.com 的内核配置部分所述。

内核完整性和自我保护特性是 Android 安全性的组成部分。设备实现

[C-0-7] 必须（MUST）实现内核栈缓冲区溢出保护（例如，CONFIG_CC_STACKPROTECTOR_STRONG）。
[C-0-8] 必须（MUST）实现严格的内核内存保护，其中可执行代码是只读的，只读数据是不可执行且不可写的，可写数据是不可执行的（例如，CONFIG_DEBUG_RODATA 或 CONFIG_STRICT_KERNEL_RWX）。
[SR] 强烈建议（STRONGLY RECOMMENDED）在初始化后将仅在初始化期间写入的内核数据标记为只读（例如，__ro_after_init）。
[SR] 强烈建议（STRONGLY RECOMMENDED）实现用户空间和内核空间之间副本的静态和动态对象大小边界检查（例如，CONFIG_HARDENED_USERCOPY）。
[SR] 强烈建议（STRONGLY RECOMMENDED）在内核中运行时，永远不要执行用户空间内存（例如，硬件 PXN，或通过 CONFIG_CPU_SW_DOMAIN_PAN 或 CONFIG_ARM64_SW_TTBR0_PAN 模拟）。
[SR] 强烈建议（STRONGLY RECOMMENDED）在内核中，永远不要在正常的 usercopy 访问 API 之外读取或写入用户空间内存（例如，硬件 PAN，或通过 CONFIG_CPU_SW_DOMAIN_PAN 或 CONFIG_ARM64_SW_TTBR0_PAN 模拟）。
[SR] 强烈建议（STRONGLY RECOMMENDED）随机化内核代码和内存的布局，并避免会损害随机化的暴露（例如，CONFIG_RANDOMIZE_BASE，通过 /chosen/kaslr-seed 设备树节点 或 EFI_RNG_PROTOCOL 的引导加载程序熵）。

如果设备实现使用 Linux 内核，则它们

[C-1-1] 必须（MUST）实现 SELinux。
[C-1-2] 必须（MUST）将 SELinux 设置为全局强制模式。
[C-1-3] 必须（MUST）将所有域配置为强制模式。不允许任何宽容模式域，包括特定于设备/供应商的域。
[C-1-4] 不得（MUST NOT）修改、省略或替换上游 Android 开源项目 (AOSP) 提供的 system/sepolicy 文件夹中存在的 neverallow 规则，并且对于 AOSP SELinux 域以及设备/供应商特定域，策略必须（MUST）在所有 neverallow 规则都存在的情况下编译。
应该（SHOULD）保留上游 Android 开源项目的 system/sepolicy 文件夹中提供的默认 SELinux 策略，并且仅针对其自身的设备特定配置进一步添加到此策略。

如果设备实现使用 Linux 以外的内核，则它们

[C-2-1] 必须（MUST）使用等效于 SELinux 的强制访问控制系统。

9.8. 隐私

9.8.1. 使用历史记录

Android 存储用户的选择历史记录，并通过 UsageStatsManager 管理此类历史记录。

设备实现

[C-1-1] 必须（MUST）保持此类用户历史记录的合理保留期限。
[SR] 强烈建议（STRONGLY RECOMMENDED）保持 AOSP 实现中默认配置的 14 天保留期限。

9.8.2. 录制

如果设备实现包含系统中捕获屏幕上显示的内容和/或录制设备上播放的音频流的功能，则它们

[C-1-1] 每当启用此功能并主动捕获/录制时，必须（MUST）向用户发出持续通知。

如果设备实现包含一个开箱即用启用的组件，该组件能够录制环境音频以推断有关用户上下文的有用信息，则它们

[C-2-1] 除非获得用户的明确同意，否则不得（MUST NOT）在持久性设备存储中存储或在设备外传输录制的原始音频或任何可以转换回原始音频或近似副本的格式。

9.8.3. 连接性

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

[C-1-1] 在允许通过 USB 端口访问共享存储的内容之前，必须（MUST）呈现一个用户界面，询问用户的同意。

9.8.4. 网络流量

设备实现

[C-0-1] 必须（MUST）预安装与上游 Android 开源项目中提供的系统信任的证书颁发机构 (CA) 存储相同的根证书。
[C-0-2] 交付时必须（MUST）带有空的用户根 CA 存储。
[C-0-3] 当添加用户根 CA 时，必须（MUST）向用户显示警告，指示网络流量可能被监控。

如果设备流量通过 VPN 路由，则设备实现

[C-1-1] 必须（MUST）向用户显示警告，指示以下任一项
- 网络流量可能被监控。
- 网络流量正在通过提供 VPN 的特定 VPN 应用路由。

如果设备实现具有默认开箱即用启用的机制，该机制通过代理服务器或 VPN 网关路由网络数据流量（例如，预加载授予 android.permission.CONTROL_VPN 的 VPN 服务），则它们

[C-2-1] 在启用该机制之前，必须（MUST）征求用户的同意，除非 VPN 是由设备策略控制器通过 DevicePolicyManager.setAlwaysOnVpnPackage() 启用的，在这种情况下，用户不需要提供单独的同意，但必须（MUST）仅被通知。

如果设备实现实现了用户可操作的功能来切换第三方 VPN 应用的“始终开启 VPN”功能，则它们

[C-3-1] 对于在 AndroidManifest.xml 文件中通过将 SERVICE_META_DATA_SUPPORTS_ALWAYS_ON 属性设置为 false 而不支持始终开启 VPN 服务的应用，必须（MUST）禁用此用户可操作的功能。

9.9. 数据存储加密

如果设备实现支持第 9.11.1 节中描述的安全锁屏，则它们

[C-1-1] 必须（MUST）支持应用私有数据（/data 分区）以及应用共享存储分区（/sdcard 分区）（如果它是设备的永久性、不可移动部分）的数据存储加密。

如果设备实现支持第 9.11.1 节中描述的安全锁屏，并且支持高级加密标准 (AES) 加密性能高于 50MiB/秒的数据存储加密，则它们

[C-2-1] 必须（MUST）在用户完成开箱即用设置体验时默认启用数据存储加密。如果设备实现在早期 Android 版本上已启动且默认禁用加密，则此类设备无法通过系统软件更新满足该要求，因此可以（MAY）被豁免。
应该（SHOULD）通过实现基于文件的加密 (FBE) 来满足上述数据存储加密要求。

9.9.1. 直接启动

设备实现

[C-0-1] 即使设备实现不支持存储加密，也必须（MUST）实现直接启动模式 API。
[C-0-2] ACTION_LOCKED_BOOT_COMPLETED 和 ACTION_USER_UNLOCKED Intent 仍然必须（MUST）广播，以向感知直接启动的应用发出信号，表明设备加密 (DE) 和凭据加密 (CE) 存储位置可供用户使用。

9.9.2. 基于文件的加密

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

[C-1-1] 在 ACTION_LOCKED_BOOT_COMPLETED 消息广播后，必须（MUST）在启动时无需用户提供凭据，并允许感知直接启动的应用访问设备加密 (DE) 存储。
[C-1-2] 仅当用户通过提供凭据（例如，密码、PIN 码、图案或指纹）解锁设备并且 ACTION_USER_UNLOCKED 消息广播后，才必须（MUST）允许访问凭据加密 (CE) 存储。
[C-1-3] 不得（MUST NOT）提供任何在没有用户提供的凭据的情况下解锁 CE 保护存储的方法。
[C-1-4] 必须（MUST）支持已验证启动，并确保 DE 密钥在密码学上绑定到设备的硬件信任根。
[C-1-5] 必须（MUST）支持使用 AES 和 256 位密钥长度以 XTS 模式加密文件内容。
[C-1-6] 必须（MUST）支持使用 AES 和 256 位密钥长度以 CBC-CTS 模式加密文件名。
保护 CE 和 DE 存储区域的密钥
[C-1-7] 必须（MUST）在密码学上绑定到硬件支持的密钥库。
[C-1-8] CE 密钥必须（MUST）绑定到用户的锁屏凭据。
[C-1-9] 当用户未指定锁屏凭据时，CE 密钥必须（MUST）绑定到默认密码。
[C-1-10] 必须（MUST）是唯一的且不同的，换句话说，没有用户的 CE 或 DE 密钥与任何其他用户的 CE 或 DE 密钥匹配。
应该（SHOULD）使预加载的基本应用（例如，闹钟、电话、消息）感知直接启动。
可以（MAY）支持用于文件内容和文件名的加密的替代密码、密钥长度和模式，但默认情况下必须（MUST）使用强制支持的密码、密钥长度和模式。

上游 Android 开源项目基于 Linux 内核 ext4 加密功能提供了此功能的首选实现。

9.9.3. 全盘加密

如果设备实现支持全盘加密 (FDE)，则它们

[C-1-1] 必须（MUST）使用密钥长度为 128 位（或更大）的 AES 和专为存储设计的模式（例如，AES-XTS、AES-CBC-ESSIV）。
[C-1-2] 必须（MUST）使用默认密码来包装加密密钥，并且不得（MUST NOT）在未加密的情况下将加密密钥写入存储。
[C-1-3] 除非用户明确选择退出，否则默认情况下必须（MUST）使用 AES 加密加密密钥，但当密钥处于活动使用状态时除外，此时锁屏凭据使用慢速拉伸算法（例如，PBKDF2 或 scrypt）进行拉伸。
[C-1-4] 当用户未指定锁屏凭据或已禁用密码用于加密并且设备提供硬件支持的密钥库时，上述默认密码拉伸算法必须（MUST）在密码学上绑定到该密钥库。
[C-1-5] 不得（MUST NOT）将加密密钥发送到设备外（即使在使用用户密码和/或硬件绑定密钥包装时）。

上游 Android 开源项目基于 Linux 内核特性 dm-crypt 提供了此功能的首选实现。

9.10. 设备完整性

以下要求确保设备完整性状态的透明度。设备实现

[C-0-1] 必须（MUST）通过系统 API 方法 PersistentDataBlockManager.getFlashLockState() 正确报告其引导加载程序状态是否允许刷写系统镜像。FLASH_LOCK_UNKNOWN 状态保留用于从早期 Android 版本升级的设备实现，其中此新系统 API 方法不存在。

已验证启动是一项保证设备软件完整性的功能。如果设备实现支持此功能，则它

[C-1-1] 必须（MUST）声明平台功能标志 android.software.verified_boot。
[C-1-2] 必须（MUST）在每个启动序列上执行验证。
[C-1-3] 必须（MUST）从作为信任根的不可变硬件密钥开始验证，一直到系统分区。
[C-1-4] 必须（MUST）实现验证的每个阶段，以在执行下一阶段的代码之前检查下一阶段中所有字节的完整性和真实性。
[C-1-5] 必须（MUST）使用与 NIST 当前对哈希算法 (SHA-256) 和公钥大小 (RSA-2048) 的建议一样强大的验证算法。
[C-1-6] 当系统验证失败时，不得（MUST NOT）允许启动完成，除非用户同意尝试继续启动，在这种情况下，不得（MUST NOT）使用来自任何未验证存储块的数据。
[C-1-7] 除非用户已显式解锁引导加载程序，否则不得（MUST NOT）允许修改设备上的已验证分区。
[SR] 如果设备中有多个离散芯片（例如，无线电、专用图像处理器），则强烈建议（STRONGLY RECOMMENDED）在启动时验证每个芯片的启动过程的每个阶段。
[SR] 强烈建议（STRONGLY RECOMMENDED）使用防篡改存储：用于引导加载程序解锁时。防篡改存储意味着引导加载程序可以检测到存储是否已从 HLOS（高级操作系统）内部被篡改。
[SR] 强烈建议（STRONGLY RECOMMENDED）在使用设备时提示用户，并在允许从引导加载程序锁定模式过渡到引导加载程序解锁模式之前要求物理确认。
[SR] 强烈建议（STRONGLY RECOMMENDED）为 HLOS（例如，启动、系统分区）实现回滚保护，并使用防篡改存储来存储用于确定最低允许 OS 版本的元数据。
应该（SHOULD）为任何具有持久固件的组件（例如，调制解调器、摄像头）实现回滚保护，并且应该（SHOULD）使用防篡改存储来存储用于确定最低允许版本的元数据。

上游 Android 开源项目在 external/avb/ 存储库中提供了此功能的首选实现，该实现可以集成到用于加载 Android 的引导加载程序中。

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

[C-2-1] 必须（MUST）支持已验证启动以确保设备完整性。

如果设备实现已在早期版本的 Android 上启动而未支持已验证启动，则此类设备无法通过系统软件更新添加对此功能的支持，因此可以免除此要求。

9.11. 密钥和凭据

Android 密钥库系统允许应用开发者将加密密钥存储在容器中，并通过 KeyChain API 或 Keystore API 在加密操作中使用它们。设备实现

[C-0-1] 必须（MUST）至少允许导入超过 8,192 个密钥。
[C-0-2] 锁屏身份验证必须（MUST）限制尝试次数，并且必须（MUST）具有指数退避算法。超过 150 次失败尝试后，每次尝试的延迟必须（MUST）至少为 24 小时。
应该（SHOULD）不限制可以生成的密钥数量

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

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

请注意，如果设备实现已在较早的 Android 版本上发布，则此类设备可免除拥有硬件支持的密钥库的要求，除非它声明需要硬件支持的密钥库的 android.hardware.fingerprint 功能。

9.11.1. 安全锁屏

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

[C-1-1] 必须在“设置”和“锁屏”用户界面中指示以下情况：屏幕自动锁定被延迟或屏幕锁可以被信任代理解锁。 AOSP 通过为“自动锁定设置”和“电源按钮立即锁定设置”菜单显示文本描述以及在锁屏上显示可区分的图标来满足此要求。
[C-1-2] 必须尊重并完全实现在 DevicePolicyManager 类中的所有信任代理 API，例如 KEYGUARD_DISABLE_TRUST_AGENTS 常量。
[C-1-3] 不得在用作主要个人设备（例如，手持设备）的设备上完全实现 TrustAgentService.addEscrowToken() 函数，但可以在通常共享的设备实现上完全实现该函数。
[C-1-4] 必须在存储通过 TrustAgentService.addEscrowToken() 添加的令牌之前对其进行加密。
[C-1-5] 不得将加密密钥存储在设备上。
[C-1-6] 必须在启用托管令牌以解密数据存储之前，告知用户有关安全隐患的信息。

如果设备实现添加或修改了用于解锁锁屏的身份验证方法，那么为了使这种身份验证方法被视为安全的锁屏方式，它们

[C-2-1] 必须是要求用户进行密钥使用身份验证中描述的用户身份验证方法。
[C-2-2] 必须在用户解锁安全锁屏时解锁所有密钥，以供第三方开发人员应用使用。例如，所有密钥都必须通过相关的 API（例如 createConfirmDeviceCredentialIntent 和 setUserAuthenticationRequired）供第三方开发人员应用使用。

如果设备实现添加或修改了基于已知密钥来解锁锁屏的身份验证方法，那么为了使这种身份验证方法被视为安全的锁屏方式，它们

[C-3-1] 最短允许输入长度的熵必须大于 10 位。
[C-3-2] 所有可能输入的最大熵必须大于 18 位。
[C-3-3] 不得替换 AOSP 中实现和提供的任何现有身份验证方法（PIN 码、图案、密码）。
[C-3-4] 当设备策略控制器 (DPC) 应用通过 DevicePolicyManager.setPasswordQuality() 方法设置了比 PASSWORD_QUALITY_SOMETHING 更严格的质量常量的密码质量策略时，必须禁用此方法。

如果设备实现添加或修改了基于物理令牌或位置来解锁锁屏的身份验证方法，那么为了使这种身份验证方法被视为安全的锁屏方式，它们

[C-4-1] 必须具有回退机制，以使用基于已知密钥的主要身份验证方法之一，并且该方法满足被视为安全锁屏的要求。
[C-4-2] 当设备策略控制器 (DPC) 应用通过 DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) 方法或 DevicePolicyManager.setPasswordQuality() 方法设置了比 PASSWORD_QUALITY_UNSPECIFIED 更严格的质量常量的策略时，必须禁用此方法，并且仅允许主要身份验证解锁屏幕。
[C-4-3] 必须至少每 72 小时或更短时间要求用户进行主要身份验证（例如，PIN 码、图案、密码）。

如果设备实现添加或修改了基于生物识别技术来解锁锁屏的身份验证方法，那么为了使这种身份验证方法被视为安全的锁屏方式，它们

[C-5-1] 必须具有回退机制，以使用基于已知密钥的主要身份验证方法之一，并且该方法满足被视为安全锁屏的要求。
[C-5-2] 当设备策略控制器 (DPC) 应用通过调用方法 DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT) 设置了锁屏功能策略时，必须禁用此方法，并且仅允许主要身份验证解锁屏幕。
[C-5-3] 必须具有不高于第 7.3.10 节中描述的指纹传感器要求的误接受率，否则当设备策略控制器 (DPC) 应用通过 DevicePolicyManager.setPasswordQuality() 方法设置了比 PASSWORD_QUALITY_BIOMETRIC_WEAK 更严格的质量常量的密码质量策略时，必须禁用此方法，并且仅允许主要身份验证解锁屏幕。
[SR] 强烈建议具有不高于第 7.3.10 节中描述的指纹传感器要求的欺骗和冒名顶替接受率。

如果欺骗和冒名顶替接受率不高于第 7.3.10 节中描述的指纹传感器要求，并且设备策略控制器 (DPC) 应用通过 DevicePolicyManager.setPasswordQuality() 方法设置了比 PASSWORD_QUALITY_BIOMETRIC_WEAK 更严格的质量常量的密码质量策略，则

[C-6-1] 必须禁用这些生物识别方法，并且仅允许主要身份验证解锁屏幕。
[C-6-2] 必须至少每 72 小时或更短时间要求用户进行主要身份验证（例如，PIN 码、图案、密码）。

如果设备实现添加或修改了用于解锁锁屏的身份验证方法，并且如果这种身份验证方法将用于解锁 Keyguard，但不会被视为安全的锁屏，则它们

[C-7-1] 必须为 KeyguardManager.isKeyguardSecure() 和 KeyguardManager.isDeviceSecure() 方法都返回 false。
[C-7-2] 当设备策略控制器 (DPC) 应用通过 DevicePolicyManager.setPasswordQuality() 方法设置了比 PASSWORD_QUALITY_UNSPECIFIED 更严格的质量常量的密码质量策略时，必须禁用此方法。
[C-7-3] 不得重置 DevicePolicyManager.setPasswordExpirationTimeout() 设置的密码过期计时器。
[C-7-4] 如果应用已调用 KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true))，则不得验证对密钥库的访问。

9.12. 数据删除

所有设备实现

[C-0-1] 必须为用户提供执行“恢复出厂设置”的机制。
[C-0-2] 必须删除所有用户生成的数据。即，除以下数据之外的所有数据
- 系统映像
- 系统映像所需的任何操作系统文件
[C-0-3] 必须以满足相关行业标准（例如 NIST SP800-88）的方式删除数据。
[C-0-4] 当主用户的设备策略控制器应用调用 DevicePolicyManager.wipeData() API 时，必须触发上述“恢复出厂设置”过程。
可以提供快速数据擦除选项，该选项仅执行逻辑数据擦除。

9.13. 安全启动模式

Android 提供了安全启动模式，该模式允许用户启动到仅允许运行预安装的系统应用且禁用所有第三方应用的模式。这种模式（称为“安全启动模式”）为用户提供了卸载潜在有害的第三方应用的功能。

设备实现应：

[SR] 强烈建议实现安全启动模式。

如果设备实现实现了安全启动模式，则它们

[C-1-1] 必须为用户提供进入安全启动模式的选项，该选项不会被设备上安装的第三方应用中断，除非第三方应用是设备策略控制器并且已将 UserManager.DISALLOW_SAFE_BOOT 标志设置为 true。
[C-1-2] 必须为用户提供在安全模式下卸载任何第三方应用的功能。
应该为用户提供从启动菜单进入安全启动模式的选项，其工作流程与正常启动的工作流程不同。

9.14. 汽车车辆系统隔离

Android Automotive 设备预计通过使用车辆 HAL 在车辆网络（例如 CAN 总线）上发送和接收消息，从而与关键车辆子系统交换数据。

可以通过在 Android 框架层以下实现安全功能来保护数据交换，以防止恶意或意外地与这些子系统交互。

10. 软件兼容性测试

设备实现必须通过本节中描述的所有测试。

但是，请注意，没有哪个软件包测试是完全全面的。因此，**强烈建议** 设备实现者尽可能少地更改 Android 开放源代码项目中提供的 Android 参考和首选实现。这将最大限度地降低引入错误的风险，这些错误会造成不兼容性，需要返工和潜在的设备更新。

10.1. 兼容性测试套件

设备实现必须通过 Android 开放源代码项目中提供的 Android 兼容性测试套件 (CTS)，并在设备上使用最终发布的软件。此外，设备实现者应尽可能多地使用 Android 开放源代码树中的参考实现，并且必须确保 CTS 中存在歧义以及对参考源代码的任何重新实现的情况下保持兼容性。

CTS 旨在在实际设备上运行。与任何软件一样，CTS 本身可能包含错误。 CTS 的版本将独立于此兼容性定义进行版本控制，并且可能会为 Android 8.1 发布 CTS 的多个修订版本。设备实现必须通过设备软件完成时可用的最新 CTS 版本。

10.2. CTS Verifier

设备实现必须正确执行 CTS Verifier 中的所有适用案例。 CTS Verifier 包含在兼容性测试套件中，旨在由人工操作员运行，以测试无法通过自动化系统测试的功能，例如摄像头和传感器的正确功能。

CTS Verifier 具有针对多种硬件的测试，包括一些可选硬件。设备实现必须通过其拥有的硬件的所有测试；例如，如果设备拥有加速度计，则必须正确执行 CTS Verifier 中的加速度计测试案例。此兼容性定义文档中标记为可选的功能的测试案例可以跳过或省略。

如上所述，每个设备和每个版本都必须正确运行 CTS Verifier。但是，由于许多版本非常相似，因此不希望设备实现者在仅在细微方面不同的版本上显式运行 CTS Verifier。具体而言，仅在包含的语言环境、品牌等方面与已通过 CTS Verifier 的实现不同的设备实现可以省略 CTS Verifier 测试。

11. 可更新软件

设备实现必须包含一种替换整个系统软件的机制。该机制不需要执行“实时”升级——也就是说，可能需要重启设备。

可以使用任何方法，只要它可以替换设备上预安装的全部软件即可。例如，以下任何方法都将满足此要求：

通过重启进行离线更新的“无线下载 (OTA)”。
通过 USB 从主机 PC 进行“有线”更新。
通过重启和从可移动存储设备上的文件进行“离线”更新。

但是，如果设备实现包含对未计量数据连接（例如 802.11 或蓝牙 PAN（个人区域网络）配置文件）的支持，则它必须支持通过重启进行离线更新的 OTA 下载。

使用的更新机制必须支持在不擦除用户数据的情况下进行更新。也就是说，更新机制必须保留应用程序私有数据和应用程序共享数据。请注意，上游 Android 软件包含满足此要求的更新机制。

对于使用 Android 6.0 及更高版本启动的设备实现，更新机制应支持验证系统映像在 OTA 后是否与预期结果在二进制上相同。自 Android 5.1 以来添加的上游 Android 开放源代码项目中的基于块的 OTA 实现满足此要求。

此外，设备实现应支持 A/B 系统更新。 AOSP 使用启动控制 HAL 来实现此功能。

如果在设备实现发布后但在其合理的产品生命周期内发现错误，并且该错误经与 Android 兼容性团队协商后确定会影响第三方应用程序的兼容性，则设备实现者必须通过可根据刚刚描述的机制应用的软件更新来纠正该错误。

Android 包括允许设备所有者应用（如果存在）控制系统更新安装的功能。为了方便起见，报告 android.software.device_admin 的设备的系统更新子系统必须实现 SystemUpdatePolicy 类中描述的行为。

12. 文档变更日志

有关此版本中兼容性定义的更改摘要：

文档变更日志

有关各个部分更改的摘要：

12.1. 变更日志查看提示

更改标记如下：

CDD
对兼容性要求的实质性更改。
文档
外观或构建相关的更改。

为了获得最佳查看效果，请将 pretty=full 和 no-merges URL 参数附加到您的变更日志 URL。

13. 联系我们

您可以加入 android-compatibility 论坛，并询问澄清或提出您认为文档未涵盖的任何问题。

Android 8.1 兼容性定义 使用合集保持井井有条 根据您的偏好保存内容并进行分类。

1. 导言

1.1 文档结构

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

1.1.2. 要求 ID

2. 设备类型

2.1 设备配置

2.2. 手持设备要求

2.2.1. 硬件

2.2.2. 多媒体

2.2.3. 软件

2.2.4. 性能和功耗

2.2.5. 安全模型

2.3. 电视要求

2.3.1. 硬件

2.3.2. 多媒体

2.3.3. 软件

2.2.4. 性能和功耗

2.4. 手表要求

2.4.1. 硬件

2.4.2. 多媒体

2.4.3. 软件

2.5. 汽车要求

2.5.1. 硬件

2.5.2. 多媒体

2.5.3. 软件

2.2.4. 性能和功耗

2.2.5. 安全模型

2.6. 平板电脑要求

2.4.1. 硬件

3. 软件

3.1. 托管 API 兼容性

3.1.1. Android 扩展

3.2. 软 API 兼容性

3.2.1. 权限

3.2.2. 构建参数

3.2.3. Intent 兼容性

3.2.3.1. 核心应用 Intent

3.2.3.2. Intent 解析

3.2.3.3. Intent 命名空间

3.2.3.4. 广播 Intent

3.2.3.5. 默认应用设置

3.2.4. 二级显示屏上的 Activity

3.3. 原生 API 兼容性

3.3.1. 应用程序二进制接口

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

3.4. Web 兼容性

3.4.1. WebView 兼容性

3.4.2. 浏览器兼容性

3.5. API 行为兼容性

3.6. API 命名空间

3.7. 运行时兼容性

3.8. 用户界面兼容性

3.8.1. 启动器（主屏幕）

3.8.2. 小部件

3.8.3. 通知

3.8.3.1. 通知的呈现

3.8.3.2. 通知侦听器服务

3.8.3.3. DND（请勿打扰）

3.8.4. 搜索

3.8.5. 警报和 Toast

3.8.6. 主题

3.8.7. 动态壁纸

3.8.8. Activity 切换

3.8.9. 输入管理

3.8.10. 锁屏媒体控件

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

3.8.12. 位置信息

3.8.13. Unicode 和字体

3.8.14. 多窗口

3.9. 设备管理

3.9.1 设备配置

3.9.1.1 设备所有者配置

3.9.1.2 托管配置文件配置

3.9.2 托管配置文件支持

3.10. 无障碍功能

3.11. 文本转语音

3.12. 电视输入框架

3.12.1. 电视应用

3.12.1.1. 电子节目指南

Android 8.1 兼容性定义
使用合集保持井井有条根据您的偏好保存内容并进行分类。