1. 简介

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

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

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

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

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

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

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

2. 设备类型

虽然 Android 开放源代码项目已用于各种设备类型和外形规格的实现，但架构和兼容性要求的许多方面都针对手持设备进行了优化。从 Android 5.0 开始，Android 开放源代码项目的目标是涵盖更广泛的设备类型，如本节所述。

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

• 必须在设备中嵌入触摸屏。
• 必须具有提供移动性的电源，例如电池。

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

• 必须具有嵌入式屏幕或包含视频输出端口，例如 VGA、HDMI 或用于显示的无线端口。
• 必须声明 android.software.leanback 和 android.hardware.type.television 功能。

Android 手表设备是指旨在佩戴在身上（可能在手腕上）的 Android 设备实现，并且

• 必须具有屏幕，其物理对角线长度范围为 1.1 到 2.5 英寸。
• 必须声明 android.hardware.type.watch 功能。
• 必须支持 uiMode = UI_MODE_TYPE_WATCH。

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

• 必须具有屏幕，其物理对角线长度等于或大于 6 英寸。
• 必须声明 android.hardware.type.automotive 功能。
• 必须支持 uiMode = UI_MODE_TYPE_CAR。
• Android Automotive 实现必须支持 android.car.* 命名空间中的所有公共 API。

所有不属于上述任何设备类型的 Android 设备实现仍必须满足本文档中的所有要求才能与 Android 7.1 兼容，除非相关要求明确说明仅适用于上述特定 Android 设备类型。

2.1 设备配置

这是按设备类型划分的硬件配置主要差异摘要。（空单元格表示“可以 (MAY) ”）。并非所有配置都包含在此表中；有关更多详细信息，请参阅相关的硬件章节。

类别	功能	章节	手持设备	电视	手表	汽车	其他
输入	方向键	7.2.2. 非触摸导航		必须 (MUST)
	触摸屏	7.2.4. 触摸屏输入	必须 (MUST)		必须 (MUST)		应该 (SHOULD)
	麦克风	7.8.1. 麦克风	必须 (MUST)	应该 (SHOULD)	必须 (MUST)	必须 (MUST)	应该 (SHOULD)
传感器	加速度计	7.3.1 加速度计	应该 (SHOULD)		应该 (SHOULD)		应该 (SHOULD)
	GPS	7.3.3. GPS	应该 (SHOULD)			应该 (SHOULD)
连接	Wi-Fi	7.4.2. IEEE 802.11	应该 (SHOULD)	应该 (SHOULD)		应该 (SHOULD)	应该 (SHOULD)
	Wi-Fi Direct	7.4.2.1. Wi-Fi Direct	应该 (SHOULD)	应该 (SHOULD)			应该 (SHOULD)
	蓝牙	7.4.3. 蓝牙	应该 (SHOULD)	必须 (MUST)	必须 (MUST)	必须 (MUST)	应该 (SHOULD)
	蓝牙低功耗	7.4.3. 蓝牙	应该 (SHOULD)	必须 (MUST)	应该 (SHOULD)	应该 (SHOULD)	应该 (SHOULD)
	蜂窝无线	7.4.5. 最低网络能力				应该 (SHOULD)
	USB 外围设备/主机模式	7.7. USB	应该 (SHOULD)			应该 (SHOULD)	应该 (SHOULD)
输出	扬声器和/或音频输出端口	7.8.2. 音频输出	必须 (MUST)	必须 (MUST)		必须 (MUST)	必须 (MUST)

3. 软件

3.1. 托管 API 兼容性

托管的 Dalvik 字节码执行环境是 Android 应用的主要载体。Android 应用程序编程接口 (API) 是为在托管运行时环境中运行的应用公开的一组 Android 平台接口。设备实现必须提供 Android SDK 公开的任何已记录 API 或上游 Android 源代码中任何使用“@SystemApi”标记装饰的 API 的完整实现，包括所有已记录的行为。

设备实现必须支持/保留 TestApi 注解 (@TestApi) 标记的所有类、方法和关联元素。

设备实现不得省略任何托管 API，不得更改 API 接口或签名，不得偏离已记录的行为，也不得包含空操作，除非本兼容性定义明确允许。

本兼容性定义允许设备实现省略 Android 在 API 中包含的某些类型的硬件。在这种情况下，API 仍必须存在并以合理的方式运行。请参阅第 7 节，了解此场景的具体要求。

3.1.1. Android 扩展程序

Android 包含在保持相同 API 级别版本的同时扩展托管 API 的支持。Android 设备实现必须预加载共享库 ExtShared 和服务 ExtServices 的 AOSP 实现，其版本必须高于或等于每个 API 级别允许的最低版本。例如，运行 API 级别 24 的 Android 7.0 设备实现必须至少包含版本 1。

3.2. 软 API 兼容性

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

3.2.1. 权限

设备实现方必须支持和强制执行 权限参考页中记录的所有权限常量。请注意，第 9 节列出了与 Android 安全模式相关的其他要求。

3.2.2. 构建参数

Android API 在 android.os.Build 类中包含许多常量，这些常量旨在描述当前设备。为了在设备实现之间提供一致且有意义的值，下表包含对这些值的格式的额外限制，设备实现必须遵守这些限制。

参数	详细信息
VERSION.RELEASE	当前正在执行的 Android 系统的版本，采用人类可读的格式。此字段必须具有 7.1 中定义的字符串值之一。
VERSION.SDK	当前正在执行的 Android 系统的版本，采用第三方应用程序代码可访问的格式。对于 Android 7.1，此字段必须具有整数值 7.1_INT。
VERSION.SDK_INT	当前正在执行的 Android 系统的版本，采用第三方应用程序代码可访问的格式。对于 Android 7.1，此字段必须具有整数值 7.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 节：Native API 兼容性。
SUPPORTED_32_BIT_ABIS	本机代码的指令集名称（CPU 类型 + ABI 约定）。请参阅第 3.3 节：Native API 兼容性。
SUPPORTED_64_BIT_ABIS	第二个本机代码指令集名称（CPU 类型 + ABI 约定）。请参阅第 3.3 节：Native API 兼容性。
CPU_ABI	本机代码的指令集名称（CPU 类型 + ABI 约定）。请参阅第 3.3 节：Native API 兼容性。
CPU_ABI2	第二个本机代码指令集名称（CPU 类型 + ABI 约定）。请参阅第 3.3 节：Native API 兼容性。
DEVICE	设备实现方选择的值，其中包含开发名称或代码名称，用于标识设备的硬件功能和工业设计配置。此字段的值必须可编码为 7 位 ASCII 码，并且与正则表达式“^[a-zA-Z0-9_-]+$”匹配。此设备名称在产品生命周期内不得更改。
FINGERPRINT	唯一标识此版本的字符串。它应该具有合理的可读性。它必须遵循以下模板 $(BRAND)/$(PRODUCT)/     $(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) 例如 acme/myproduct/     mydevice:7.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 公开安全公告中提供的补丁除外。它必须报告正确的值，如果不存在此类构建，则报告空字符串 ("")。

3.2.3. Intent 兼容性

3.2.3.1. 核心应用 Intent

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

• 时钟
• 浏览器
• 日历
• 联系人
• 图库
• 全局搜索
• 启动器
• 音乐
• 设置

设备实现必须根据需要包含核心 Android 应用，或者包含实现与这些核心 Android 应用的所有 Activity 或 Service 组件定义的相同 Intent 模式的组件，这些组件通过 android:exported 属性隐式或显式地向其他应用公开。

3.2.3.2. Intent 解析

由于 Android 是一个可扩展的平台，设备实现必须允许 第 3.2.3.1 节 中引用的每个 Intent 模式被第三方应用覆盖。上游 Android 开源实现默认允许这样做；设备实现方不得为系统应用使用这些 Intent 模式附加特殊权限，或阻止第三方应用绑定并接管这些模式的控制权。此项禁止特别包括但不限于禁用“选择器”用户界面，该界面允许用户在处理同一 Intent 模式的多个应用之间进行选择。

设备实现必须为用户提供用户界面，以修改 Intent 的默认 Activity。

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

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

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

3.2.3.3. Intent 命名空间

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

3.2.3.4. 广播 Intent

第三方应用依赖于平台广播某些 Intent，以通知它们硬件或软件环境的变化。兼容 Android 的设备必须响应适当的系统事件广播公共广播 Intent。广播 Intent 在 SDK 文档中进行了描述。

3.2.3.5. 默认应用设置

Android 包含一些设置，这些设置为用户提供了一种简便的方法来选择其默认应用，例如用于主屏幕或短信。在有意义的情况下，设备实现必须提供类似的设置菜单，并且必须与 SDK 文档中描述的 Intent 过滤器模式和 API 方法兼容，如下所示。

设备实现

• 如果设备实现报告 android.software.home_screen，则必须响应 android.settings.HOME_SETTINGS Intent 以显示主屏幕的默认应用设置菜单。
• 如果设备实现报告 android.hardware.telephony，则必须提供一个设置菜单，该菜单将调用 android.provider.Telephony.ACTION_CHANGE_DEFAULT Intent 以显示用于更改默认短信应用的对话框。
• 如果设备实现报告 android.hardware.nfc.hce，则必须响应 android.settings.NFC_PAYMENT_SETTINGS Intent 以显示用于“点击支付”的默认应用设置菜单。
• 如果设备实现报告 android.hardware.telephony，则必须响应 android.telecom.action.CHANGE_DEFAULT_DIALER Intent 以显示一个对话框，允许用户更改默认电话应用。
• 当设备支持 VoiceInteractionService 时，必须响应 android.settings.ACTION_VOICE_INPUT_SETTINGS Intent，并显示用于语音输入和辅助功能的默认应用设置菜单。

3.3. Native API 兼容性

本地代码兼容性具有挑战性。因此，**强烈建议**设备实现方使用来自上游 Android 开源项目的以下库的实现。

3.3.1. 应用二进制接口

托管的 Dalvik 字节码可以调用应用程序 .apk 文件中提供的本地代码，作为为适当的设备硬件架构编译的 ELF .so 文件。由于本地代码高度依赖于底层处理器技术，Android 在 Android NDK 中定义了多个应用程序二进制接口 (ABI)。设备实现必须与一个或多个定义的 ABI 兼容，并且必须实现与 Android NDK 的兼容性，如下所示。

如果设备实现包含对 Android ABI 的支持，则它

• 必须包含对在托管环境中运行的代码的支持，以使用标准 Java 本地接口 (JNI) 语义调用本地代码。
• 必须与下面列表中的每个必需库在源代码级别（即标头兼容）和二进制级别（对于 ABI）兼容。
• 如果支持任何 64 位 ABI，则必须支持等效的 32 位 ABI。
• 必须通过 android.os.Build.SUPPORTED_ABIS、android.os.Build.SUPPORTED_32_BIT_ABIS 和 android.os.Build.SUPPORTED_64_BIT_ABIS 参数准确报告设备支持的本机应用程序二进制接口 (ABI)，每个参数都是以逗号分隔的 ABI 列表，从最优先到最不优先的顺序排列。
• 必须通过上述参数仅报告 Android NDK ABI 管理文档 最新版本中记录和描述的 ABI，并且必须包含对 高级 SIMD（又名 NEON）扩展的支持。
• 应该使用上游 Android 开源项目中提供的源代码和头文件进行构建

请注意，未来版本的 Android NDK 可能会引入对其他 ABI 的支持。如果设备实现与现有的预定义 ABI 不兼容，则绝不能报告对任何 ABI 的支持。

以下本地代码 API 必须可供包含本地代码的应用使用

• 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 接口
• 对 OpenGL 的支持，如下所述

对于上面列出的本地库，设备实现不得添加或删除公共函数。

未在上面列出但在 AOSP 中实现并作为系统库提供的本地库是保留的，并且不得向以 API 级别 24 或更高级别为目标的第三方应用公开。

设备实现可以添加非 AOSP 库并将其直接作为 API 向第三方应用公开，但其他库应位于 /vendor/lib 或 /vendor/lib64 中，并且必须在 /vendor/etc/public.libraries.txt 中列出。

请注意，设备实现必须包含 libGLESv3.so，并且反过来，必须导出 NDK 版本 android-24 中定义的所有 OpenGL ES 3.1 和 Android 扩展包 函数符号。虽然所有符号都必须存在，但只有设备实际支持的 OpenGL ES 版本和扩展的相应函数才必须完全实现。

3.3.1.1. 图形库

Vulkan 是用于高性能 3D 图形的低开销、跨平台 API。即使设备实现不包含对 Vulkan API 的支持，也必须满足以下要求

• 它必须始终提供一个名为 libvulkan.so 的本地库，该库导出核心 Vulkan 1.0 API 以及 VK_KHR_surface、VK_KHR_android_surface 和 VK_KHR_swapchain 扩展的函数符号。

如果设备实现包含对 Vulkan API 的支持

• 则必须通过 vkEnumeratePhysicalDevices 调用报告一个或多个 VkPhysicalDevices。
• 每个枚举的 VkPhysicalDevices 必须完全实现 Vulkan 1.0 API。
• 必须报告正确的 PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL 和 PackageManager#FEATURE_VULKAN_HARDWARE_VERSION 功能标志。
• 必须通过 libvulkan.so 中的 vkEnumerateInstanceLayerProperties 和 vkEnumerateDeviceLayerProperties 函数枚举包含在应用程序包的本地库目录中名为 libVkLayer*.so 的本地库中的层。
• 除非应用程序具有 android:debuggable=”true” 属性，否则不得枚举应用程序包外部的库提供的层，或提供其他跟踪或拦截 Vulkan API 的方法。

如果设备实现不包含对 Vulkan API 的支持

• 则必须通过 vkEnumeratePhysicalDevices 调用报告 0 个 VkPhysicalDevices。
• 不得声明任何 Vulkan 功能标志 PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL 和 PackageManager#FEATURE_VULKAN_HARDWARE_VERSION。

3.3.2. 32 位 ARM Native 代码兼容性

ARMv8 架构弃用了一些 CPU 操作，包括现有本地代码中使用的一些操作。在 64 位 ARM 设备上，以下已弃用的操作必须仍然可用于 32 位原生 ARM 代码，可以通过原生 CPU 支持或通过软件模拟来实现

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

旧版本的 Android NDK 使用 /proc/cpuinfo 从 32 位原生 ARM 代码中发现 CPU 功能。为了与使用此 NDK 构建的应用兼容，当 32 位 ARM 应用读取 /proc/cpuinfo 时，设备必须在 /proc/cpuinfo 中包含以下行

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

这些要求仅在 32 位 ARM 应用读取 /proc/cpuinfo 时适用。当 64 位 ARM 或非 ARM 应用读取 /proc/cpuinfo 时，设备不应更改 /proc/cpuinfo。

3.4. Web 兼容性

3.4.1. WebView 兼容性

平台功能 android.software.webview 必须在提供 android.webkit.WebView API 完整实现的任何设备上报告，并且不得在未完整实现 API 的设备上报告。Android 开源实现使用来自 Chromium 项目的代码来实现 android.webkit.WebView。由于为 Web 呈现系统开发全面的测试套件不可行，因此设备实现方必须在 WebView 实现中使用 Chromium 的特定上游构建。具体来说

• 设备 android.webkit.WebView 实现必须基于来自 Android 7.1 上游 Android 开源项目的 Chromium 构建。此构建包括 WebView 的特定功能集和安全修复程序。

• 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. 浏览器兼容性

独立的浏览器可以基于 WebKit 以外的浏览器技术。但是，即使使用了备用浏览器应用，提供给第三方应用的 android.webkit.WebView 组件也必须基于 WebKit，如 第 3.4.1 节 中所述。

实现可以在独立的浏览器应用中附带自定义用户代理字符串。

独立的浏览器应用（无论是基于上游 WebKit 浏览器应用还是第三方替代品）应尽可能多地支持 HTML5。最低限度，设备实现必须支持与 HTML5 相关的以下每个 API

• 应用程序缓存/离线操作
• <video> 标记
• 地理位置

此外，设备实现必须支持 HTML5/W3C Web Storage API，并且应支持 HTML5/W3C IndexedDB API。请注意，由于 Web 开发标准机构正在过渡到倾向于使用 IndexedDB 而不是 Web Storage，因此 IndexedDB 预计将在未来版本的 Android 中成为必需组件。

3.5. API 行为兼容性

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

• 设备不得更改标准 Intent 的行为或语义。
• 设备不得更改特定类型的系统组件（例如 Service、Activity、ContentProvider 等）的生命周期或生命周期语义。
• 设备不得更改标准权限的语义。

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

3.6. API 命名空间

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

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

禁止的修改包括 :

• 设备实现不得通过更改任何方法或类签名，或通过删除类或类字段来修改 Android 平台上公开公开的 API。
• 设备实现方可以修改 API 的底层实现，但此类修改不得影响任何公开公开的 API 的声明行为和 Java 语言签名。
• 设备实现方不得在上述 API 中添加任何公开公开的元素（例如类或接口，或现有类或接口的字段或方法）。

“公开公开的元素”是指任何未在 Android 上游源代码中使用的“@hide”标记修饰的构造。换句话说，设备实现方不得在上述命名空间中公开新的 API 或更改现有 API。设备实现方可以进行仅限内部的修改，但这些修改不得向开发者宣传或以其他方式公开。

设备实现方可以添加自定义 API，但任何此类 API 不得位于另一个组织拥有或引用的命名空间中。例如，设备实现方不得将 API 添加到 com.google.* 或类似命名空间：只有 Google 可以这样做。同样，Google 不得将 API 添加到其他公司的命名空间。此外，如果设备实现包含标准 Android 命名空间之外的自定义 API，则这些 API 必须打包在 Android 共享库中，以便只有显式使用它们的应用程序（通过 <uses-library> 机制）才会受到此类 API 增加内存使用量的影响。

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

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

3.7. 运行时兼容性

设备实现必须支持完整的 Dalvik Executable (DEX) 格式和 Dalvik 字节码规范和语义。设备实现方应使用 ART，即 Dalvik Executable 格式的参考上游实现，以及参考实现的包管理系统。

设备实现必须根据上游 Android 平台配置 Dalvik 运行时以分配内存，并按照下表指定。（有关屏幕尺寸和屏幕密度的定义，请参阅 第 7.1.1 节。）请注意，下面指定的内存值被认为是最小值，设备实现方可以为每个应用程序分配更多内存。

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

3.8. 用户界面兼容性

3.8.1. 启动器（主屏幕）

Android 包括启动器应用（主屏幕）和对第三方应用替换设备启动器（主屏幕）的支持。允许第三方应用替换设备主屏幕的设备实现必须声明平台功能 android.software.home_screen。

3.8.2. 微件

Android 定义了一种组件类型以及相应的 API 和生命周期，允许应用程序向最终用户公开 “AppWidget”，强烈建议在掌上设备实现上支持此功能。支持在主屏幕上嵌入小部件的设备实现必须满足以下要求并声明对平台功能 android.software.app_widgets 的支持。

• 设备启动器必须包括对 AppWidget 的内置支持，并公开用户界面以便在启动器内直接添加、配置、查看和删除 AppWidget。
• 设备实现必须能够呈现标准网格尺寸为 4 x 4 的小部件。有关详细信息，请参阅 Android SDK 文档中的 App Widget 设计指南。
• 包含锁屏支持的设备实现可以在锁屏上支持应用程序小部件。

3.8.3. 通知

Android 包含允许开发者使用设备的硬件和软件功能 通知用户重要事件 的 API。

一些 API 允许应用程序使用硬件（特别是声音、振动和灯光）执行通知或引起注意。设备实现必须支持使用硬件功能的通知，如 SDK 文档中所述，并在设备实现硬件允许的范围内支持。例如，如果设备实现包含振动器，则必须正确实现振动 API。如果设备实现缺少硬件，则相应的 API 必须实现为无操作。此行为在 第 7 节 中进行了更详细的说明。

此外，实现必须正确呈现 API 中提供的所有 资源（图标、动画文件等），或状态栏/系统栏 图标样式指南 中提供的资源，对于 Android 电视设备而言，这包括不显示通知的可能性。设备实现方可以为通知提供与参考 Android 开源实现提供的用户体验不同的替代用户体验；但是，此类替代通知系统必须支持现有的通知资源，如上所述。

Android 包括对各种通知的支持，例如

• 富通知。用于正在进行的通知的交互式视图。
• 浮动通知。用户可以在不离开当前应用的情况下操作或关闭的交互式视图。
• 锁屏通知。在锁屏上显示的通知，具有对可见性的精细控制。

当 Android 设备实现使此类通知可见时，必须正确执行富通知和浮动通知，并包含 Android API 中记录的 标题/名称、图标、文本。

Android 包括通知侦听器服务 API，允许应用（一旦用户明确启用）接收所有已发布或更新的通知的副本。设备实现必须正确且及时地将完整的通知发送到所有此类已安装且用户已启用的侦听器服务，包括附加到 Notification 对象的所有元数据。

掌上设备实现必须支持更新、删除、回复和捆绑通知的行为，如本 节 中所述。

此外，掌上设备实现必须提供

• 直接在通知栏中控制通知的能力。
• 在通知栏中触发控制面板的视觉提示。
• 在内联控制面板和设置应用中，阻止、静音和重置来自软件包的通知首选项的能力。

必须支持 Notification.Style class 的所有 6 个直接子类，如 SDK 文档 中所述。

支持 DND（请勿打扰）功能的设备实现必须满足以下要求

• 必须实现一个 Activity，该 Activity 将响应 Intent ACTION_NOTIFICATION_POLICY_ACCESS_SETTINGS，对于具有 UI_MODE_TYPE_NORMAL 的实现，它必须是一个 Activity，用户可以在其中授予或拒绝应用访问 DND 策略配置。
• 对于设备实现已为用户提供了一种授予或拒绝第三方应用访问 DND 策略配置的方法的情况，必须显示应用程序创建的 自动 DND 规则 以及用户创建和预定义的规则。
• 必须遵守沿着 suppressedVisualEffects NotificationManager.Policy 传递的值，并且如果应用设置了 SUPPRESSED_EFFECT_SCREEN_OFF 或 SUPPRESSED_EFFECT_SCREEN_ON 标志中的任何一个，则 SHOULD 向用户表明视觉效果在“请勿打扰”设置菜单中被抑制。

3.8.4. 搜索

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

Android 设备实现 SHOULD 包括全局搜索，这是一个单一的、共享的、系统范围的搜索用户界面，能够实时响应用户输入提供建议。设备实现 SHOULD 实现 API，允许开发者重用此用户界面，以便在其自己的应用中提供搜索功能。实现全局搜索界面的设备实现 MUST 实现 API，允许第三方应用在全局搜索模式下运行时，向搜索框添加建议。如果没有安装任何利用此功能的第三方应用，则默认行为 SHOULD 是显示 Web 搜索引擎结果和建议。

Android 设备实现 SHOULD，而 Android Automotive 实现 MUST，在设备上实现一个助手来处理 Assist action。

Android 还包括 Assist API，允许应用选择与设备上的助手共享多少当前上下文信息。支持 Assist action 的设备实现 MUST 在上下文共享时，通过在屏幕边缘周围显示白光来向最终用户清楚地指示。为了确保最终用户的清晰可见性，指示 MUST 达到或超过 Android 开源项目实现的持续时间和亮度。

如果满足以下所有要求，则对于使用 Assist 和 VoiceInteractionService API 预安装的应用，此指示 MAY 默认禁用

• 仅当用户通过以下方式之一调用应用且应用在前台运行时，预安装的应用 MUST 请求共享上下文

  • 热词调用
  • 输入 ASSIST 导航键/按钮/手势

• 设备实现 MUST 提供一种启用指示的方式，距离（默认语音输入和助手应用设置菜单）第 3.2.3.5 节 不超过两次导航。

3.8.5. Toast

应用可以使用 “Toast” API 向最终用户显示简短的非模态字符串，这些字符串会在短暂的时间后消失。设备实现 MUST 以某种高可见度方式向最终用户显示来自应用的 Toast。

3.8.6. 主题

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

Android 包括一个“Holo”主题系列，作为一组定义的样式，供应用开发者使用，如果他们想要匹配 Android SDK 定义的 Holo 主题外观。设备实现 MUST NOT 更改暴露给应用的任何 Holo 主题属性。

Android 包括一个“Material”主题系列，作为一组定义的样式，供应用开发者使用，如果他们想要在各种不同的 Android 设备类型中匹配设计主题的外观。设备实现 MUST 支持“Material”主题系列，并且 MUST NOT 更改暴露给应用的任何 Material 主题属性或其资源。

Android 还包括一个“Device Default”主题系列，作为一组定义的样式，供应用开发者使用，如果他们想要匹配设备实现者定义的设备主题的外观。设备实现 MAY 修改暴露给应用的 Device Default 主题属性。

Android 支持具有半透明系统栏的变体主题，这允许应用开发者用其应用内容填充状态栏和导航栏后面的区域。为了在这种配置中实现一致的开发者体验，重要的是跨不同的设备实现保持状态栏图标样式。因此，Android 设备实现 MUST 对系统状态图标（例如信号强度和电池电量）以及系统发出的通知使用白色，除非图标指示有问题状态或应用使用 SYSTEM_UI_FLAG_LIGHT_STATUS_BAR 标志请求浅色状态栏。当应用请求浅色状态栏时，Android 设备实现 MUST 将系统状态图标的颜色更改为黑色（有关详细信息，请参阅 R.style）。

3.8.7. 动态壁纸

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

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

能够如上所述可靠地运行动态壁纸的设备实现 SHOULD 实现动态壁纸，并且在实现时 MUST 报告平台功能标志 android.software.live_wallpaper。

3.8.8. Activity 切换

上游 Android 源代码包括 overview screen，这是一个系统级的用户界面，用于任务切换和显示最近访问过的活动和任务，方法是在用户上次离开应用时使用应用图形状态的缩略图图像。包括第 7.2.3 节中详述的“最近”功能导航键的设备实现 MAY 更改界面，但 MUST 满足以下要求

• MUST 支持至少显示多达 20 个活动。
• SHOULD 至少一次显示 4 个活动的标题。
• MUST 实现 screen pinning behavior，并为用户提供一个设置菜单来切换该功能。
• SHOULD 在“最近”中显示高亮颜色、图标、屏幕标题。
• SHOULD 显示关闭方式 (“x”)，但 MAY 将其延迟到用户与屏幕交互时。
• SHOULD 实现一个快捷方式，以便轻松切换到上一个活动
• MAY 将关联的“最近”显示为一起移动的组。
• SHOULD 在轻按“最近”功能键两次时，触发最近使用最多的两个应用之间的快速切换操作。
• SHOULD 在长按“最近”功能键时，触发分屏多窗口模式（如果支持）。

强烈建议设备实现使用上游 Android 用户界面（或类似的基于缩略图的界面）作为概述屏幕。

3.8.9. 输入管理

Android 包括对 Input Management 和对第三方输入法编辑器的支持。允许用户在设备上使用第三方输入法的设备实现 MUST 声明平台功能 android.software.input_methods，并支持 Android SDK 文档中定义的 IME API。

声明 android.software.input_methods 功能的设备实现 MUST 提供用户可访问的机制来添加和配置第三方输入法。设备实现 MUST 响应 android.settings.INPUT_METHOD_SETTINGS intent 显示设置界面。

3.8.10. 锁屏媒体控件

Remote Control Client API 已从 Android 5.0 中弃用，取而代之的是 Media Notification Template，它允许媒体应用与锁定屏幕上显示的播放控件集成。除非是 Android Automotive 或 Watch 实现，否则支持锁定屏幕的设备实现 MUST 显示锁定屏幕通知，包括 Media Notification Template。

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

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

3.8.12. 位置信息

当设备具有能够提供位置坐标的硬件传感器（例如 GPS）时，location modes MUST 在“设置”中的“位置”菜单中显示。

3.8.13. Unicode 和字体

Android 包括对 Unicode 9.0 中定义的表情符号字符的支持。所有设备实现 MUST 能够以彩色字形渲染这些表情符号字符，并且当 Android 设备实现包括 IME 时，它 SHOULD 为用户提供这些表情符号字符的输入法。

Android 手持设备 SHOULD 支持 Unicode 技术报告 #51 中指定的肤色和多元家庭表情符号。

Android 包括对具有不同粗细的 Roboto 2 字体（sans-serif-thin、sans-serif-light、sans-serif-medium、sans-serif-black、sans-serif-condensed、sans-serif-condensed-light）的支持，这些字体 MUST 全部包含在设备上可用的语言中，并且完全覆盖 Unicode 7.0 的拉丁语、希腊语和西里尔语，包括拉丁语扩展 A、B、C 和 D 范围，以及 Unicode 7.0 的货币符号块中的所有字形。

3.8.14. 多窗口

设备实现 MAY 选择不实现任何多窗口模式，但如果它具有同时显示多个活动的能力，则 MUST 按照 Android SDK multi-window mode support documentation 中描述的应用行为和 API 实现此类多窗口模式，并满足以下要求

• 应用可以在 AndroidManifest.xml 文件中指示它们是否能够在多窗口模式下运行，可以通过 android:resizeableActivity 属性显式指示，也可以通过 targetSdkVersion > 24 隐式指示。在其清单文件中将此属性显式设置为 false 的应用 MUST NOT 在多窗口模式下启动。在其清单文件中未设置该属性的应用（targetSdkVersion < 24）可以在多窗口模式下启动，但系统 MUST 提供警告，说明该应用可能在多窗口模式下无法按预期工作。
• 如果屏幕高度和宽度均小于 440 dp，则设备实现 MUST NOT 提供分屏或自由窗口模式。
• 屏幕尺寸为 xlarge 的设备实现 SHOULD 支持自由窗口模式。
• Android Television 设备实现 MUST 支持画中画 (PIP) 模式多窗口，并在 PIP 开启时将 PIP 多窗口放置在右上角。
• 支持 PIP 模式多窗口的设备实现 MUST 为 PIP 窗口分配至少 240x135 dp。
• 如果支持 PIP 多窗口模式，则 KeyEvent.KEYCODE_WINDOW 键 MUST 用于控制 PIP 窗口；否则，该键 MUST 可用于前台活动。

3.9. 设备管理

Android 包括一些功能，允许具有安全意识的应用通过 Android 设备管理 API 执行系统级别的设备管理功能，例如强制密码策略或执行远程擦除。设备实现 MUST 提供 DevicePolicyManager 类的实现。支持安全锁定屏幕的设备实现 MUST 实现 Android SDK 文档中定义的全部 device administration 策略，并报告平台功能 android.software.device_admin。

3.9.1 设备配置

3.9.1.1 设备所有者配置

如果设备实现声明了 android.software.device_admin 功能，则它 MUST 实现 Device Owner app 的 Device Policy Client (DPC) 应用的配置，如下所示

• 当设备实现尚无用户数据配置时，它
  • MUST 为 DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) 报告 true。
  • MUST 响应 android.app.action.PROVISION_MANAGED_DEVICE intent action，将 DPC 应用注册为 Device Owner app。
  • 如果设备通过功能标志 android.hardware.nfc 声明支持近场通信 (NFC) 并接收到包含 MIME 类型为 MIME_TYPE_PROVISIONING_NFC 的记录的 NFC 消息，则 MUST 将 DPC 应用注册为 Device Owner app。
• 当设备实现具有用户数据时，它
  • MUST 为 DevicePolicyManager.isProvisioningAllowed(ACTION_PROVISION_MANAGED_DEVICE) 报告 false。
  • MUST not 再将任何 DPC 应用注册为 Device Owner App。

设备实现 MAY 具有执行设备管理功能的预安装应用，但未经用户或设备管理员的明确同意或操作，此应用 MUST NOT 设置为 Device Owner app。

3.9.1.2 托管配置文件配置

如果设备实现声明了 android.software.managed_users，则必须能够将 Device Policy Controller (DPC) 应用注册为新的Managed Profile 的所有者。

托管配置文件配置过程（由 android.app.action.PROVISION_MANAGED_PROFILE 启动的流程）用户体验 MUST 与 AOSP 实现保持一致。

设备实现 MUST 在“设置”用户界面中提供以下用户方式，以向用户指示设备策略控制器 (DPC) 何时禁用了特定系统功能

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

3.9.2 托管配置文件支持

支持托管配置文件的设备是那些

• 声明 android.software.device_admin（请参阅第 3.9 节 设备管理）。
• 不是低 RAM 设备（请参阅第 7.6.1 节）。
• 将内部（不可移动）存储分配为共享存储（请参阅第 7.6.2 节）。

支持托管配置文件的设备 MUST

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

3.10. 无障碍功能

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

设备实现包括以下要求

• Android Automotive 实现 SHOULD 提供与默认 Android 实现一致的 Android 辅助功能框架的实现。
• 设备实现（Android Automotive 除外）MUST 提供与默认 Android 实现一致的 Android 辅助功能框架的实现。
• 设备实现（Android Automotive 除外）MUST 通过 android.accessibilityservice API 支持第三方辅助功能服务实现。
• 设备实现（Android Automotive 除外）MUST 生成 AccessibilityEvents，并以与默认 Android 实现一致的方式将这些事件传递给所有已注册的 AccessibilityService 实现

• 设备实现（Android Automotive 和没有音频输出的 Android Watch 设备除外），MUST 提供用户可访问的机制来启用和禁用辅助功能服务，并且 MUST 响应 android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS intent 显示此界面。

• 具有音频输出的 Android 设备实现强烈建议提供设备上辅助功能服务的实现，其功能可与 TalkBack** 和 Switch Access 辅助功能服务（https://github.com/google/talkback）的功能相当或超过。

• 具有音频输出的 Android Watch 设备 SHOULD 提供设备上辅助功能服务的实现，其功能可与 TalkBack 辅助功能服务（https://github.com/google/talkback）的功能相当或超过。
• 设备实现 SHOULD 在开箱即用设置流程中为用户提供启用相关辅助功能服务以及调整字体大小、显示大小和放大手势的选项的机制。

** 对于文本到语音转换支持的语言。

另请注意，如果存在预加载的辅助功能服务，则如果设备具有使用基于文件的加密 (FBE) 的加密存储，则它 MUST 是一个Direct Boot aware {directBootAware} 应用。

3.11. 文本转语音

Android 包括 API，允许应用使用文本到语音转换 (TTS) 服务，并允许服务提供商提供 TTS 服务的实现。报告功能 android.hardware.audio.output 的设备实现 MUST 满足与 Android TTS 框架 相关的这些要求。

Android Automotive 实现

• MUST 支持 Android TTS 框架 API。
• MAY 支持安装第三方 TTS 引擎。如果支持，合作伙伴 MUST 提供用户可访问的界面，允许用户选择要在系统级别使用的 TTS 引擎。

所有其他设备实现

• MUST 支持 Android TTS 框架 API，并且 SHOULD 包括支持设备上可用语言的 TTS 引擎。请注意，上游 Android 开源软件包括功能齐全的 TTS 引擎实现。
• MUST 支持安装第三方 TTS 引擎。
• MUST 提供用户可访问的界面，允许用户选择要在系统级别使用的 TTS 引擎。

3.12. 电视输入框架

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

支持 TIF 的设备实现 MUST 声明平台功能 android.software.live_tv。

3.12.1. 电视应用

任何声明支持直播电视的设备实现 MUST 都安装电视应用（TV App）。Android 开源项目提供了 TV App 的实现。

TV App MUST 提供安装和使用 TV Channels 的功能，并满足以下要求

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

3.12.1.1. 电子节目指南

Android 电视设备实现 MUST 显示信息性和交互式叠加层，其中 MUST 包括从 TvContract.Programs 字段中的值生成的电子节目指南 (EPG)。EPG MUST 满足以下要求

• EPG MUST 显示来自所有已安装输入和第三方输入的信息。
• EPG MAY 在已安装输入和第三方输入之间提供视觉分隔。
• 强烈建议 EPG 以同等突出的方式显示已安装输入和第三方输入。EPG MUST NOT 将第三方输入显示在距离 EPG 上已安装输入超过一次导航操作的位置。
• 在频道更改时，设备实现 MUST 显示当前播放节目的 EPG 数据。

3.12.1.2. 导航

TV App MUST 允许通过 Android 电视设备的输入设备（即遥控器、遥控器应用或游戏控制器）上的 D-pad、“返回”和“主页”键进行以下功能的导航

• 更改电视频道
• 打开 EPG
• 配置和调谐到基于第三方 TIF 的输入
• 打开“设置”菜单

TV App SHOULD 通过 CEC 将按键事件传递到 HDMI 输入。

3.12.1.3. 电视输入应用关联

Android 电视设备实现 MUST 支持 TV input app linking，这允许所有输入提供从当前活动到另一个活动的活动链接（即，从直播节目到相关内容的链接）。当提供 TV input app linking 时，TV App MUST 显示它。

3.12.1.4. 时移

Android 电视设备实现 MUST 支持时移，这允许用户暂停和恢复直播内容。如果该节目的时移可用，则设备实现 MUST 为用户提供暂停和恢复当前播放节目的方法。

3.12.1.5. 电视录制

强烈建议 Android 电视设备实现支持电视录制。如果电视输入支持录制，则 EPG MAY 提供一种录制节目的方法，如果录制此类节目未被禁止。设备实现 SHOULD 提供一个用户界面来播放录制的节目。

3.13. 快捷设置

Android 设备实现 SHOULD 包括“快速设置”UI 组件，该组件允许快速访问常用或紧急需要的操作。

Android 包括 quicksettings API，允许第三方应用实现在“快速设置”UI 组件中用户可以在系统提供的图块旁边添加的图块。如果设备实现具有“快速设置”UI 组件，则它

• MUST 允许用户从第三方应用向“快速设置”添加或删除图块。
• MUST NOT 将第三方应用的图块直接自动添加到“快速设置”。
• MUST 在系统提供的快速设置图块旁边显示来自第三方应用的所有用户添加的图块。

3.14. 车辆 UI API

3.14.1. 车辆媒体 UI

任何声明支持汽车的设备实现 MUST 都包含一个 UI 框架，以支持第三方应用使用 MediaBrowser 和 MediaSession API。

支持依赖于 MediaBrowser 和 MediaSession 的第三方应用的 UI 框架具有以下视觉要求

• MUST 显示 MediaItem 图标和通知图标，且不得更改。
• MUST 显示 MediaSession 描述的那些项目，例如，元数据、图标、图像。
• MUST 显示应用标题。
• MUST 具有抽屉来呈现 MediaBrowser 层次结构。

4. 应用封装兼容性

设备实现 MUST 安装和运行由 官方 Android SDK 中包含的“aapt”工具生成的 Android “.apk”文件。因此，设备实现 SHOULD 使用参考实现的软件包管理系统。

软件包管理器 MUST 支持使用 APK Signature Scheme v2 和 JAR signing 验证 “.apk”文件。

设备实现 MUST NOT 以阻止这些文件在其他兼容设备上正确安装和运行的方式扩展 .apk、Android 清单、Dalvik 字节码 或 RenderScript 字节码格式。

设备实现MUST NOT允许软件包的当前“记录安装程序”以外的应用在没有任何提示的情况下静默卸载应用，正如 DELETE_PACKAGE 权限的 SDK 文档中所述。唯一的例外是处理 PACKAGE_NEEDS_VERIFICATION intent 的系统软件包验证程序应用和处理 ACTION_MANAGE_STORAGE intent 的存储管理器应用。

5. 多媒体兼容性

5.1. 媒体编解码器

设备实现—

• MUST 支持 Android SDK 文档中指定的核心媒体格式，除非本文档中明确允许。

• MUST 支持下表定义的并通过 MediaCodecList 报告的媒体格式、编码器、解码器、文件类型和容器格式。

• MUST 也能够解码其 CamcorderProfile 中报告的所有配置文件

• MUST 能够解码它可以编码的所有格式。这包括其编码器生成的所有比特流。

编解码器SHOULD 以最小编解码器延迟为目标，换句话说，编解码器—

• SHOULD NOT 消耗和存储输入缓冲区，并且仅在处理后返回输入缓冲区
• SHOULD NOT 持有解码后的缓冲区的时间超过标准（例如 SPS）规定的时间。
• SHOULD NOT 持有编码后的缓冲区的时间超过 GOP 结构要求的时间。

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

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

5.1.1. 音频编解码器

格式/编解码器	编码器	解码器	详细信息	支持的文件类型/容器格式
MPEG-4 AAC 配置文件 (AAC LC)	REQUIRED 1	REQUIRED	支持单声道/立体声/5.0/5.1 2 内容，标准采样率从 8 到 48 kHz。	3GPP (.3gp) MPEG-4 (.mp4, .m4a) ADTS 原始 AAC (.aac，Android 3.1+ 中解码，Android 4.0+ 中编码，不支持 ADIF) MPEG-TS (.ts，不可搜索，Android 3.0+)
MPEG-4 HE AAC 配置文件 (AAC+)	REQUIRED 1 (Android 4.1+)	REQUIRED	支持单声道/立体声/5.0/5.1 2 内容，标准采样率从 16 到 48 kHz。
MPEG-4 HE AACv2 配置文件（增强型 AAC+）		REQUIRED	支持单声道/立体声/5.0/5.1 2 内容，标准采样率从 16 到 48 kHz。
AAC ELD（增强型低延迟 AAC）	REQUIRED 1 (Android 4.1+)	REQUIRED (Android 4.1+)	支持单声道/立体声内容，标准采样率从 16 到 48 kHz。
AMR-NB	REQUIRED 3	REQUIRED 3	4.75 至 12.2 kbps，采样率 @ 8 kHz	3GPP (.3gp)
AMR-WB	REQUIRED 3	REQUIRED 3	9 种速率，从 6.60 kbit/s 到 23.85 kbit/s，采样率 @ 16 kHz
FLAC		REQUIRED (Android 3.1+)	单声道/立体声（无多声道）。采样率高达 48 kHz（但在具有 44.1 kHz 输出的设备上，RECOMMENDED 高达 44.1 kHz，因为 48 到 44.1 kHz 的降采样器不包含低通滤波器）。RECOMMENDED 16 位；24 位不应用抖动。	仅 FLAC (.flac)
MP3		REQUIRED	单声道/立体声 8-320Kbps 恒定 (CBR) 或可变比特率 (VBR)	MP3 (.mp3)
MIDI		REQUIRED	MIDI 类型 0 和 1。DLS 版本 1 和 2。XMF 和 Mobile XMF。支持铃声格式 RTTTL/RTX、OTA 和 iMelody	类型 0 和 1 (.mid, .xmf, .mxmf) RTTTL/RTX (.rtttl, .rtx) OTA (.ota) iMelody (.imy)
Vorbis		REQUIRED		Ogg (.ogg) Matroska (.mkv, Android 4.0+)
PCM/WAVE	REQUIRED 4 (Android 4.1+)	REQUIRED	16 位线性 PCM（速率高达硬件限制）。设备 MUST 支持原始 PCM 录音的采样率，频率为 8000、11025、16000 和 44100 Hz。	WAVE (.wav)
Opus		REQUIRED (Android 5.0+)		Matroska (.mkv), Ogg(.ogg)

¹ 定义 android.hardware.microphone 的设备实现是必需的，但 Android Watch 设备实现是可选的。

² 录音或播放MAY 以单声道或立体声执行，但通过 android.media.MediaCodec API 中的默认 AAC 音频解码器将多声道流（即，超过两个声道）的 AAC 输入缓冲区解码为 PCM 时，MUST 支持以下内容

• 执行解码时不进行向下混合（例如，5.0 AAC 流必须解码为五个声道的 PCM，5.1 AAC 流必须解码为六个声道的 PCM），
• 动态范围元数据，如 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

³ Android 手持设备实现是必需的。

⁴ 定义 android.hardware.microphone 的设备实现是必需的，包括 Android Watch 设备实现。

5.1.2. 图像编解码器

格式/编解码器	编码器	解码器	详细信息	支持的文件类型/容器格式
JPEG	REQUIRED	REQUIRED	基线+渐进	JPEG (.jpg)
GIF		REQUIRED		GIF (.gif)
PNG	REQUIRED	REQUIRED		PNG (.png)
BMP		REQUIRED		BMP (.bmp)
WebP	REQUIRED	REQUIRED		WebP (.webp)
Raw		REQUIRED		ARW (.arw), CR2 (.cr2), DNG (.dng), NEF (.nef), NRW (.nrw), ORF (.orf), PEF (.pef), RAF (.raf), RW2 (.rw2), SRW (.srw)

5.1.3. 视频编解码器

• 声明 HDR 配置文件支持的编解码器 MUST 支持 HDR 静态元数据解析和处理。

• 如果媒体编解码器声明支持帧内刷新，则它 MUST 支持 10 - 60 帧范围内的刷新周期，并在配置的刷新周期的 20% 范围内准确运行。

• 视频编解码器 MUST 支持输出和输入字节缓冲区大小，这些大小应适应标准和配置规定的最大可行压缩和未压缩帧，但也不应过度分配。

• 视频编码器和解码器 MUST 支持 YUV420 灵活颜色格式 (COLOR_FormatYUV420Flexible)。

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

¹ 对于包含摄像头硬件并定义 android.hardware.camera 或 android.hardware.camera.front 的设备实现是必需的。

² 除了 Android Watch 设备之外的设备实现是必需的。

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

⁴ 设备实现SHOULD 支持写入 Matroska WebM 文件。

⁵ Android Automotive STRONGLY RECOMMENDED，Android Watch 可选，所有其他设备类型 REQUIRED。

⁶ 仅适用于 Android 电视设备实现。

5.2. 视频编码

H.264、VP8、VP9 和 HEVC 视频编码器—

• MUST 支持动态可配置比特率。
• SHOULD 支持可变帧率，其中视频编码器SHOULD 根据输入缓冲区的时间戳确定瞬时帧持续时间，并根据该帧持续时间分配其位桶。

H.263 和 MPEG-4 视频编码器 SHOULD 支持动态可配置比特率。

所有视频编码器 SHOULD 在两个滑动窗口上满足以下比特率目标

• 在帧内帧 (I 帧) 间隔之间，它SHOULD 不超过比特率的 ~15%。
• 在 1 秒的滑动窗口上，它SHOULD 不超过比特率的 ~100%。

5.2.1. H.263

具有 H.263 编码器的 Android 设备实现 MUST 支持 Baseline Profile Level 45。

5.2.2. H-264

具有 H.264 编解码器支持的 Android 设备实现

• MUST 支持 Baseline Profile Level 3。
  但是，对 ASO（任意切片顺序）、FMO（灵活宏块顺序）和 RS（冗余切片）的支持是 OPTIONAL 的。此外，为了保持与其他 Android 设备的兼容性，RECOMMENDED 编码器不要将 ASO、FMO 和 RS 用于 Baseline Profile。
• MUST 支持下表中的 SD（标准清晰度）视频编码配置文件。
• SHOULD 支持 Main Profile Level 4。
• SHOULD 支持下表中指示的 HD（高清）视频编码配置文件。
• 此外，强烈建议 Android 电视设备以 30 fps 编码 HD 1080p 视频。

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

¹ 如果硬件支持，但对于 Android 电视设备STRONGLY RECOMMENDED。

5.2.3. VP8

具有 VP8 编解码器支持的 Android 设备实现 MUST 支持 SD 视频编码配置文件，并且 SHOULD 支持以下 HD（高清）视频编码配置文件。

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

设备实现—

• MUST 支持通过标准 Android API 在同一流中实时动态视频分辨率和帧率切换，适用于设备上每个编解码器支持的最大分辨率的 VP8、VP9、H.264 和 H.265 编解码器。

• 支持 Dolby Vision 解码器的实现—

• MUST 提供支持 Dolby Vision 的提取器。

• MUST 在设备屏幕上或标准视频输出端口（例如 HDMI）上正确显示 Dolby Vision 内容。

• 提供支持 Dolby Vision 的提取器的实现 MUST 将向后兼容的基层的轨道索引（如果存在）设置为与组合的 Dolby Vision 层的轨道索引相同。

5.3.1. MPEG-2

具有 MPEG-2 解码器的 Android 设备实现必须支持 Main Profile High Level。

5.3.2. H.263

具有 H.263 解码器的 Android 设备实现 MUST 支持 Baseline Profile Level 30 和 Level 45。

5.3.3. MPEG-4

具有 MPEG-4 解码器的 Android 设备实现 MUST 支持 Simple Profile Level 3。

5.3.4. H.264

具有 H.264 解码器的 Android 设备实现

• MUST 支持 Main Profile Level 3.1 和 Baseline Profile。
  对 ASO（任意切片顺序）、FMO（灵活宏块顺序）和 RS（冗余切片）的支持是 OPTIONAL 的。
• MUST 能够解码下表中列出的 SD（标准清晰度）配置文件的视频，这些视频使用 Baseline Profile 和 Main Profile Level 3.1（包括 720p30）进行编码。
• SHOULD 能够解码下表中指示的 HD（高清）配置文件的视频。
• 此外，Android 电视设备—
  • MUST 支持 High Profile Level 4.2 和 HD 1080p60 解码配置文件。
  • MUST 能够解码下表中指示的两个 HD 配置文件的视频，并使用 Baseline Profile、Main Profile 或 High Profile Level 4.2 进行编码

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

¹ 当 Display.getSupportedModes() 方法报告的高度等于或大于视频分辨率时，REQUIRED。

² Android 电视设备实现是 REQUIRED 的。

5.3.5. H.265 (HEVC)

Android 设备实现，当支持 第 5.1.3 节 中描述的 H.265 编解码器时

• MUST 支持 Main Profile Level 3 Main tier 和下表中指示的 SD 视频解码配置文件。
• SHOULD 支持下表中指示的 HD 解码配置文件。
• MUST 支持下表中指示的 HD 解码配置文件（如果存在硬件解码器）。
• 此外，Android 电视设备
• MUST 支持 HD 720p 解码配置文件。
• STRONGLY RECOMMENDED 支持 HD 1080p 解码配置文件。如果支持 HD 1080p 解码配置文件，则它 MUST 支持 Main Profile Level 4.1 Main tier。
• SHOULD 支持 UHD 解码配置文件。如果支持 UHD 解码配置文件，则编解码器 MUST 支持 Main10 Level 5 Main Tier 配置文件。

	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 fps (60 fps 1 )	60 fps
视频比特率	600 Kbps	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

¹ 对于具有 H.265 硬件解码的 Android 电视设备实现，REQUIRED。

5.3.6. VP8

Android 设备实现，当支持 第 5.1.3 节 中描述的 VP8 编解码器时

• MUST 支持下表中的 SD 解码配置文件。
• SHOULD 支持下表中的 HD 解码配置文件。
• Android 电视设备 MUST 支持 HD 1080p60 解码配置文件。

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

¹ 当 Display.getSupportedModes() 方法报告的高度等于或大于视频分辨率时，REQUIRED。

² Android 电视设备实现是 REQUIRED 的。

5.3.7. VP9

Android 设备实现，当支持 第 5.1.3 节 中描述的 VP9 编解码器时

• MUST 支持下表中指示的 SD 视频解码配置文件。
• SHOULD 支持下表中指示的 HD 解码配置文件。
• MUST 支持下表中指示的 HD 解码配置文件（如果存在硬件解码器）。

• 此外，Android 电视设备

  • MUST 支持 HD 720p 解码配置文件。
  • STRONGLY RECOMMENDED 支持 HD 1080p 解码配置文件。
  • SHOULD 支持 UHD 解码配置文件。如果支持 UHD 视频解码配置文件，则它 MUST 支持 8 位颜色深度，并且 SHOULD 支持 VP9 Profile 2（10 位）。

	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 1 )	60 fps
视频比特率	600 Kbps	1.6 Mbps	4 Mbps	5 Mbps	20 Mbps

¹ 对于具有 VP9 硬件解码的 Android 电视设备实现，REQUIRED。

5.4. 音频录制

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

5.4.1. 原始音频捕获

声明 android.hardware.microphone 的设备实现 MUST 允许捕获具有以下特征的原始音频内容

• Format：线性 PCM，16 位
• 采样率 : 8000, 11025, 16000, 44100
• Channels：单声道

上述采样率的捕获 MUST 在没有上采样的情况下完成，任何下采样 MUST 包括适当的抗混叠滤波器。

声明 android.hardware.microphone 的设备实现 SHOULD 允许捕获具有以下特征的原始音频内容

• Format：线性 PCM，16 位
• 采样率 : 22050, 48000
• Channels：立体声

如果支持上述采样率的捕获，则捕获 MUST 在任何高于 16000:22050 或 44100:48000 的比率下均在没有上采样的情况下完成。任何上采样或下采样 MUST 包括适当的抗混叠滤波器。

5.4.2. 语音识别捕获

android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION 音频源 MUST 支持以 44100 和 48000 之一的采样率进行捕获。

除了上述录音规范外，当应用程序已开始使用 android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION 音频源开始录制音频流时

• 设备 SHOULD 表现出大致平坦的幅度与频率特性：具体而言，在 100 Hz 至 4000 Hz 范围内为 ±3 dB。
• 音频输入灵敏度 SHOULD 设置为使 1000 Hz 时 90 dB 声功率级 (SPL) 源产生 16 位样本的 RMS 为 2500。
• PCM 幅度电平 SHOULD 在至少 30 dB 范围内线性跟踪输入 SPL 变化，范围从 -18 dB 到 +12 dB re 90 dB SPL 在麦克风处。
• 总谐波失真 SHOULD 在麦克风处 1 kHz 时 90 dB SPL 输入电平下小于 1%。
• 噪声降低处理（如果存在）MUST 禁用。
• 自动增益控制（如果存在）MUST 禁用。

如果平台支持针对语音识别调整的噪声抑制技术，则必须可以从 android.media.audiofx.NoiseSuppressor API 控制该效果。此外，噪声抑制器的效果描述符的 UUID 字段 MUST 唯一标识噪声抑制技术的每个实现。

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

android.media.MediaRecorder.AudioSource 类包括 REMOTE_SUBMIX 音频源。声明 android.hardware.audio.output 的设备必须正确实现 REMOTE_SUBMIX 音频源，以便当应用程序使用 android.media.AudioRecord API 从此音频源录制时，它可以捕获除以下各项之外的所有音频流的混合

• STREAM_RING
• STREAM_ALARM
• STREAM_NOTIFICATION

5.5. 音频播放

声明 android.hardware.audio.output 的设备实现 MUST 符合本节中的要求。

5.5.1. 原始音频播放

设备 MUST 允许播放具有以下特征的原始音频内容

• Format：线性 PCM，16 位
• 采样率 : 8000, 11025, 16000, 22050, 32000, 44100
• Channels：单声道、立体声

设备 SHOULD 允许播放具有以下特征的原始音频内容

• 采样率 : 24000, 48000

5.5.2. 音频效果

Android 提供了一个用于设备实现的音频效果 API。声明 android.hardware.audio.output 功能的设备实现

• MUST 支持可通过 AudioEffect 子类 Equalizer、LoudnessEnhancer 控制的 EFFECT_TYPE_EQUALIZER 和 EFFECT_TYPE_LOUDNESS_ENHANCER 实现。
• MUST 支持可通过 Visualizer 类控制的可视化工具 API 实现。
• SHOULD 支持可通过 AudioEffect 子类 BassBoost、EnvironmentalReverb、PresetReverb 和 Virtualizer 控制的 EFFECT_TYPE_BASS_BOOST、EFFECT_TYPE_ENV_REVERB、EFFECT_TYPE_PRESET_REVERB 和 EFFECT_TYPE_VIRTUALIZER 实现。

5.5.3. 音频输出音量

Android 电视设备实现 MUST 包括对受支持输出上的系统主音量和数字音频输出音量衰减的支持，压缩音频直通输出（设备上未完成音频解码）除外。

Android Automotive 设备实现 SHOULD 允许使用 AudioAttributes 和 android.car.CarAudioManager 中公开定义的汽车音频使用情况，分别调整每个音频流的音频音量。

5.6. 音频延迟

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

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

• output latency。应用程序写入 PCM 编码数据帧的时间与相应的声音在设备上传感器处呈现给环境或信号通过端口离开设备并可在外部观察到的时间之间的时间间隔。
• cold output latency。音频输出系统在请求之前一直处于空闲和断电状态时，第一帧的输出延迟。
• continuous output latency。设备正在播放音频后，后续帧的输出延迟。
• input latency。声音由环境通过设备上传感器呈现给设备或信号通过端口进入设备的时间与应用程序读取相应的 PCM 编码数据帧的时间之间的时间间隔。
• lost input。输入信号的初始部分，不可用或不可用。
• cold input latency。当音频输入系统在请求之前一直处于空闲和断电状态时，丢失的输入时间和第一帧的输入延迟的总和。
• continuous input latency。当设备正在捕获音频时，后续帧的输入延迟。
• cold output jitter。冷输出延迟值的不同测量的变异性。
• cold input jitter。冷输入延迟值的不同测量的变异性。
• continuous round-trip latency。连续输入延迟加上连续输出延迟加上一个缓冲区周期的总和。缓冲区周期允许应用程序处理信号的时间以及应用程序缓解输入和输出流之间相位差的时间。
• OpenSL ES PCM buffer queue API。Android NDK 中的 PCM 相关 OpenSL ES API 集。

声明 android.hardware.audio.output 的设备实现 STRONGLY RECOMMENDED 满足或超过这些音频输出要求

• 冷输出延迟为 100 毫秒或更短
• 连续输出延迟为 45 毫秒或更短
• 最大限度地减少冷输出抖动

如果设备实现在使用 OpenSL ES PCM buffer queue API 进行任何初始校准后，在至少一个受支持的音频输出设备上满足本节的连续输出延迟和冷输出延迟的要求，则强烈建议通过 android.content.pm.PackageManager 类报告对低延迟音频的支持，方法是报告 android.hardware.audio.low_latency 功能。相反，如果设备实现不满足这些要求，则 MUST NOT 报告对低延迟音频的支持。

包含 android.hardware.microphone 的设备实现 STRONGLY RECOMMENDED 满足这些输入音频要求

• 冷输入延迟为 100 毫秒或更短
• 连续输入延迟为 30 毫秒或更短
• 连续往返延迟为 50 毫秒或更短
• 最大限度地减少冷输入抖动

5.7. 网络协议

设备 MUST 支持 Android SDK 文档中指定的音频和视频播放的媒体网络协议。具体而言，设备 MUST 支持以下媒体网络协议

• HTTP(S) 渐进式流式传输
  第 5.1 节中的所有必需编解码器和容器格式 MUST 通过 HTTP(S) 支持

• HTTP Live Streaming 草案协议，版本 7
  必须支持以下媒体段格式

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

• RTSP (RTP, SDP)

  必须支持以下 RTP 音频视频配置文件和相关编解码器。有关例外情况，请参阅 第 5.1 节 中的表格脚注。

配置文件名称	参考	必需的编解码器支持
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. 安全媒体

支持安全视频输出并能够支持安全表面的设备实现 MUST 声明支持 Display.FLAG_SECURE。声明支持 Display.FLAG_SECURE 的设备实现，如果它们支持无线显示协议，则 MUST 使用密码学强度高的机制（例如 HDCP 2.x 或更高版本，用于 Miracast 无线显示器）来保护链接。同样，如果它们支持有线外部显示器，则设备实现 MUST 支持 HDCP 1.2 或更高版本。Android 电视设备实现 MUST 为支持 4K 分辨率的设备支持 HDCP 2.2，为较低分辨率的设备支持 HDCP 1.4 或更高版本。上游 Android 开源实现包括对满足此要求的无线 (Miracast) 和有线 (HDMI) 显示器的支持。

5.9. 乐器数字接口 (MIDI)

如果设备实现支持应用间 MIDI 软件传输（虚拟 MIDI 设备），并且它支持为其提供通用非 MIDI 连接的以下所有支持 MIDI 的硬件传输上的 MIDI，则强烈建议通过 android.content.pm.PackageManager 类报告对 android.software.midi 功能的支持。

支持 MIDI 的硬件传输包括

• USB 主机模式（第 7.7 节 USB）
• USB 外围模式（第 7.7 节 USB）
• 通过蓝牙 LE 以中央角色运行的 MIDI（第 7.4.3 节 蓝牙）

相反，如果设备实现在上面列出的特定支持 MIDI 的硬件传输上提供通用非 MIDI 连接，但不支持在该硬件传输上的 MIDI，则 MUST NOT 报告对 android.software.midi 功能的支持。

5.10. 专业音频

如果设备实现满足所有以下要求，则强烈建议通过 android.content.pm.PackageManager 类报告对 android.hardware.audio.pro 功能的支持。

• 设备实现 MUST 报告对 android.hardware.audio.low_latency 功能的支持。
• 连续往返音频延迟（如第 5.6 节音频延迟中所定义）MUST 为 20 毫秒或更短，并且 SHOULD 在至少一条受支持的路径上为 10 毫秒或更短。
• 如果设备包括 4 导体 3.5 毫米音频插孔，则音频插孔路径上的连续往返音频延迟 MUST 为 20 毫秒或更短，并且在音频插孔路径上 SHOULD 为 10 毫秒或更短。
• 设备实现 MUST 包括支持 USB 主机模式和 USB 外围模式的 USB 端口。
• USB 主机模式 MUST 实现 USB 音频类。
• 如果设备包括 HDMI 端口，则设备实现 MUST 支持以立体声和八声道输出，位深为 20 位或 24 位，频率为 192 kHz，且无位深损失或重采样。
• 设备实现 MUST 报告对 android.software.midi 功能的支持。
• 如果设备包括 4 导体 3.5 毫米音频插孔，则强烈建议设备实现符合 移动设备（插孔）规范 部分的 有线音频耳机规范 (v1.1)。

延迟和 USB 音频要求 MUST 使用 OpenSL ES PCM 缓冲区队列 API 来满足。

此外，报告支持此功能的设备实现 SHOULD

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

5.11. 用于未处理的捕获

从 Android 7.0 开始，添加了一个新的录音源。可以使用 android.media.MediaRecorder.AudioSource.UNPROCESSED 音频源访问它。在 OpenSL ES 中，可以使用录音预设 SL_ANDROID_RECORDING_PRESET_UNPROCESSED 访问它。

设备必须满足以下所有要求，才能通过 android.media.AudioManager 属性 PROPERTY_SUPPORT_AUDIO_SOURCE_UNPROCESSED 报告对未处理音频源的支持

• 设备在中频范围内必须表现出近似平坦的幅度-频率特性：具体而言，在 100 Hz 至 7000 Hz 范围内为 ±10dB。

• 设备在低频范围内必须表现出幅度水平：具体而言，与中频范围相比，在 5 Hz 至 100 Hz 范围内为 ±20 dB。

• 设备在高频范围内必须表现出幅度水平：具体而言，与中频范围相比，在 7000 Hz 至 22 KHz 范围内为 ±30 dB。

• 音频输入灵敏度必须设置为：当以 94 dB 声压级 (SPL) 播放 1000 Hz 正弦波音源时，对于 16 位采样，产生的响应 RMS 值为 520（或对于浮点/双精度采样，为 -36 dB 满量程）。

• 信噪比 (SNR) > 60 dB（94 dB SPL 与自噪声等效 SPL 之间的差值，A 计权）。

• 在麦克风处，对于 90 dB SPL 输入电平下的 1 kHz 信号，总谐波失真必须小于 1%。

• 路径中唯一允许的信号处理是将电平调整到所需范围的电平乘法器。此电平乘法器绝不能在信号路径中引入延迟或时延。

• 路径中不允许进行其他信号处理，例如自动增益控制、高通滤波器或回声消除。如果出于任何原因，架构中存在任何信号处理，则必须禁用它，并有效引入零延迟或额外时延到信号路径。

所有 SPL 测量均在被测麦克风旁边直接进行。

对于多麦克风配置，这些要求适用于每个麦克风。

强烈建议设备满足未处理录音源信号路径的尽可能多的要求；但是，如果设备声称支持未处理音频源，则必须满足所有上述要求。

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

6.1. 开发者工具

设备实现必须支持 Android SDK 中提供的 Android 开发者工具。Android 兼容设备必须与以下工具兼容

• Android 调试桥 (adb)
  • 设备实现必须支持 Android SDK 中记录的所有 adb 功能，包括 dumpsys 。
  • 设备端的 adb 守护程序默认必须处于非活动状态，并且必须有用户可访问的机制来启用 Android 调试桥。如果设备实现省略了 USB 外围设备模式，则必须通过局域网（例如以太网或 802.11）实现 Android 调试桥。
  • Android 包括对安全 adb 的支持。安全 adb 允许在已知的经过身份验证的主机上使用 adb。设备实现必须支持安全 adb。
• Dalvik 调试监视器服务 (ddms)
  • 设备实现必须支持 Android SDK 中记录的所有 ddms 功能。
  • 由于 ddms 使用 adb，因此默认情况下对 ddms 的支持应该处于非活动状态，但是只要用户如上所述激活了 Android 调试桥，就必须支持 ddms。
• Monkey 设备实现必须包含 Monkey 框架，并使其可供应用程序使用。
• SysTrace
  • 设备实现必须支持 Android SDK 中记录的 systrace 工具。Systrace 默认必须处于非活动状态，并且必须有用户可访问的机制来启用 Systrace。
  • 大多数基于 Linux 的系统和 Apple Macintosh 系统都可以使用标准 Android SDK 工具识别 Android 设备，而无需额外支持；但是，Microsoft Windows 系统通常需要新 Android 设备的驱动程序。（例如，新的供应商 ID，有时还有新的设备 ID，需要 Windows 系统的自定义 USB 驱动程序。）
  • 如果标准 Android SDK 中提供的 adb 工具无法识别设备实现，则设备实现者必须提供 Windows 驱动程序，使开发者能够使用 adb 协议连接到设备。这些驱动程序必须为 Windows XP、Windows Vista、Windows 7、Windows 8 和 Windows 10 的 32 位和 64 位版本提供。

6.2. 开发者选项

Android 包括对开发者配置应用程序开发相关设置的支持。设备实现必须遵循 android.settings.APPLICATION_DEVELOPMENT_SETTINGS Intent，以显示应用程序开发相关设置。上游 Android 实现默认隐藏“开发者选项”菜单，并允许用户在连续点击七 (7) 次设置 > 关于设备 > 版本号菜单项后启动“开发者选项”。设备实现必须为“开发者选项”提供一致的体验。具体而言，设备实现默认必须隐藏“开发者选项”，并且必须提供一种与上游 Android 实现一致的机制来启用“开发者选项”。

7. 硬件兼容性

如果设备包含特定的硬件组件，并且该组件具有第三方开发者可用的相应 API，则设备实现必须按照 Android SDK 文档中的描述实现该 API。如果 SDK 中的 API 与声明为可选的硬件组件交互，并且设备实现不具备该组件

• 组件 API 的完整类定义（如 SDK 文档中所述）必须仍然存在。
• API 的行为必须以某种合理的方式实现为无操作。
• 在 SDK 文档允许的情况下，API 方法必须返回空值。
• 在 SDK 文档不允许返回空值的情况下，API 方法必须返回类的无操作实现。
• API 方法绝不能抛出 SDK 文档中未记录的异常。

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

设备实现必须始终如一地通过同一构建指纹的 android.content.pm.PackageManager 类上的 getSystemAvailableFeatures() 和 hasSystemFeature(String) 方法报告准确的硬件配置信息。

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 框架支持各种不同的屏幕尺寸，并允许应用程序通过 android.content.res.Configuration.screenLayout 和 SCREENLAYOUT_SIZE_MASK 查询设备屏幕尺寸（也称为“屏幕布局”）。设备实现必须报告正确的 屏幕尺寸，如 Android SDK 文档中所定义，并由上游 Android 平台确定。具体而言，设备实现必须根据以下逻辑密度无关像素 (dp) 屏幕尺寸报告正确的屏幕尺寸。

• 设备必须具有至少 426 dp x 320 dp（“小”）的屏幕尺寸，除非它是 Android 手表设备。
• 报告屏幕尺寸为“正常”的设备必须具有至少 480 dp x 320 dp 的屏幕尺寸。
• 报告屏幕尺寸为“大”的设备必须具有至少 640 dp x 480 dp 的屏幕尺寸。
• 报告屏幕尺寸为“超大”的设备必须具有至少 960 dp x 720 dp 的屏幕尺寸。

此外

• Android 手表设备必须具有物理对角线尺寸在 1.1 到 2.5 英寸范围内的屏幕。
• Android Automotive 设备必须具有物理对角线尺寸大于或等于 6 英寸的屏幕。
• Android Automotive 设备必须具有至少 750 dp x 480 dp 的屏幕尺寸。
• 其他类型的 Android 设备实现（具有物理集成屏幕）必须具有物理对角线尺寸至少为 2.5 英寸的屏幕。

设备在任何时候都不得更改其报告的屏幕尺寸。

应用程序可以选择通过 AndroidManifest.xml 文件中的 <supports-screens> 属性指示它们支持的屏幕尺寸。设备实现必须正确遵循应用程序声明的对小、正常、大和超大屏幕的支持，如 Android SDK 文档中所述。

7.1.1.2. 屏幕宽高比

虽然物理屏幕显示器的屏幕纵横比值没有限制，但第三方应用程序在其上呈现的表面以及可以从通过 DisplayMetrics 报告的值派生的表面的屏幕纵横比必须满足以下要求

• 如果 uiMode 配置为 UI_MODE_TYPE_WATCH，则纵横比值可以设置为 1.0 (1:1)。
• 如果第三方应用程序通过 android:resizeableActivity 属性指示它是可调整大小的，则纵横比值没有限制。
• 对于所有其他情况，纵横比必须是 1.3333 (4:3) 和 1.86（大约 16:9）之间的值，除非应用程序通过 maxAspectRatio 元数据值明确指示它支持更高的屏幕纵横比。

7.1.1.3. 屏幕密度

Android UI 框架定义了一组标准逻辑密度，以帮助应用程序开发者定位应用程序资源。默认情况下，设备实现必须仅通过 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 框架密度。

强烈建议设备实现为用户提供更改显示尺寸的设置。如果存在更改设备显示尺寸的实现，则它必须与如下所示的 AOSP 实现保持一致

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

7.1.2. 显示指标

设备实现必须报告 android.util.DisplayMetrics 中定义的所有显示指标的正确值，并且无论使用嵌入式屏幕还是外部屏幕作为默认显示器，都必须报告相同的值。

7.1.3. 屏幕方向

设备必须报告它们支持的屏幕方向（android.hardware.screen.portrait 和/或 android.hardware.screen.landscape），并且必须报告至少一个支持的方向。例如，具有固定方向横向屏幕的设备（如电视或笔记本电脑）应仅报告 android.hardware.screen.landscape。

报告两种屏幕方向的设备必须支持应用程序动态地设置为纵向或横向屏幕方向。也就是说，设备必须尊重应用程序对特定屏幕方向的请求。设备实现可以选择纵向或横向方向作为默认方向。

设备必须在通过 android.content.res.Configuration.orientation、android.view.Display.getOrientation() 或其他 API 查询时，报告设备当前方向的正确值。

设备在更改方向时不得更改报告的屏幕尺寸或密度。

7.1.4. 2D 和 3D 图形加速

设备实现必须支持 OpenGL ES 1.0 和 2.0，如 Android SDK 文档中所体现和详细说明。设备实现应在能够支持 OpenGL ES 3.0、3.1 或 3.2 的设备上支持它们。设备实现还必须支持 Android RenderScript ，如 Android SDK 文档中所述。

设备实现还必须正确标识自身支持 OpenGL ES 1.0、OpenGL ES 2.0、OpenGL ES 3.0、OpenGL 3.1 或 OpenGL 3.2。也就是说

• 托管 API（例如通过 GLES10.getString() 方法）必须报告对 OpenGL ES 1.0 和 OpenGL ES 2.0 的支持。
• 本机 C/C++ OpenGL API（通过 libGLES_v1CM.so、libGLES_v2.so 或 libEGL.so 向应用程序提供的 API）必须报告对 OpenGL ES 1.0 和 OpenGL ES 2.0 的支持。
• 声明支持 OpenGL ES 3.0、3.1 或 3.2 的设备实现必须支持相应的托管 API，并包括对本机 C/C++ API 的支持。在声明支持 OpenGL ES 3.0、3.1 或 3.2 的设备实现上，libGLESv2.so 除了 OpenGL ES 2.0 函数符号外，还必须导出相应的函数符号。

Android 提供了一个 OpenGL ES 扩展包，其中包含 Java 接口和对高级图形功能（如曲面细分和 ASTC 纹理压缩格式）的本机支持。如果设备支持 OpenGL ES 3.2，则 Android 设备实现必须支持扩展包，否则可以支持它。如果完整支持扩展包，则设备必须通过 android.hardware.opengles.aep 功能标志来标识支持。

此外，设备实现可以实现任何所需的 OpenGL ES 扩展。但是，设备实现必须通过 OpenGL ES 托管和本机 API 报告它们支持的所有扩展字符串，反之，绝不能报告它们不支持的扩展字符串。

请注意，Android 包括对应用程序选择性地指定它们需要特定的 OpenGL 纹理压缩格式的支持。这些格式通常是供应商特定的。Android 不要求设备实现实现任何特定的纹理压缩格式。但是，它们应通过 OpenGL API 中的 getString() 方法准确报告它们支持的任何纹理压缩格式。

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

设备实现必须默认启用硬件加速，并且如果开发者通过设置 android:hardwareAccelerated="false”或直接通过 Android View API 禁用硬件加速来提出请求，则必须禁用硬件加速。

此外，设备实现必须表现出与 Android SDK 文档中关于 硬件加速 一致的行为。

Android 包括一个 TextureView 对象，允许开发者将硬件加速的 OpenGL ES 纹理直接集成到 UI 层次结构中作为渲染目标。设备实现必须支持 TextureView API，并且必须表现出与上游 Android 实现一致的行为。

Android 包括对 EGL_ANDROID_RECORDABLE 的支持，这是一种 EGLConfig 属性，指示 EGLConfig 是否支持渲染到将图像记录到视频的 ANativeWindow。设备实现必须支持 EGL_ANDROID_RECORDABLE 扩展。

7.1.5. 旧版应用兼容模式

Android 指定了一种“兼容模式”，其中框架以“正常”屏幕尺寸等效模式（320dp 宽度）运行，以使旧版应用程序受益，这些应用程序不是为早于屏幕尺寸独立的旧版 Android 开发的。

• Android Automotive 不支持旧版兼容模式。
• 所有其他设备实现必须包括对旧版应用程序兼容模式的支持，如上游 Android 开源代码所实现的那样。也就是说，设备实现绝不能更改兼容模式激活的触发器或阈值，并且绝不能更改兼容模式本身的行为。

7.1.6. 屏幕技术

Android 平台包括允许应用程序将丰富的图形渲染到显示器的 API。除非本文档中特别允许，否则设备必须支持 Android SDK 定义的所有这些 API。

• 设备必须支持能够渲染 16 位彩色图形的显示器，并且应支持能够渲染 24 位彩色图形的显示器。
• 设备必须支持能够渲染动画的显示器。
• 所使用的显示技术必须具有介于 0.9 和 1.15 之间的像素纵横比 (PAR)。也就是说，像素纵横比必须接近正方形 (1.0)，公差为 10 ~ 15%。

7.1.7. 辅助显示屏

Android 包括对辅助显示器的支持，以启用媒体共享功能和开发者 API，以访问外部显示器。如果设备通过有线、无线或嵌入式附加显示器连接支持外部显示器，则设备实现必须实现 显示管理器 API，如 Android SDK 文档中所述。

7.2. 输入设备

设备必须支持触摸屏或满足 7.2.2 中列出的非触摸导航的要求。

7.2.1. 键盘

设备实现

• 必须包括对输入管理框架的支持（该框架允许第三方开发者创建输入法编辑器，即软键盘），详见 https://developer.android.com.cn 。
• 必须提供至少一个软键盘实现（无论是否存在硬键盘），但 Android 手表设备除外，因为其屏幕尺寸使得拥有软键盘不太合理。
• 可以包括其他软键盘实现。
• 可以包括硬件键盘。
• 绝不能包括与 android.content.res.Configuration.keyboard （QWERTY 或 12 键）中指定的格式之一不匹配的硬件键盘。

7.2.2. 非触摸导航

设备实现

• 如果设备实现不是 Android 电视设备，则可以省略非触摸导航选项（轨迹球、D-pad 或滚轮）。
• 必须报告 android.content.res.Configuration.navigation 的正确值。
• 必须为文本的选择和编辑提供合理的替代用户界面机制，与输入管理引擎兼容。上游 Android 开源代码实现包括一种选择机制，适用于缺乏非触摸导航输入的设备。

7.2.3. 导航键

Home、Recents 和 Back 功能（分别映射到按键事件 KEYCODE_HOME、KEYCODE_APP_SWITCH、KEYCODE_BACK）对于 Android 导航范例至关重要，因此

• Android 手持设备实现必须提供 Home、Recents 和 Back 功能。
• Android 电视设备实现必须提供 Home 和 Back 功能。
• Android 手表设备实现必须使用户可以使用 Home 功能，并且可以使用 Back 功能，除非它处于 UI_MODE_TYPE_WATCH 状态。
• Android 手表设备实现，并且没有其他 Android 设备类型，可以消耗按键事件 KEYCODE_BACK 上的长按事件，并省略将其发送到前台应用程序。
• Android Automotive 实现必须提供 Home 功能，并且可以提供 Back 和 Recent 功能。
• 所有其他类型的设备实现必须提供 Home 和 Back 功能。

这些功能可以通过专用物理按钮（例如机械按钮或电容式触摸按钮）来实现，或者可以使用屏幕不同部分上的专用软件按键、手势、触摸面板等来实现。Android 支持这两种实现。当可见时，所有这些功能都必须通过单个操作（例如点击、双击或手势）来访问。

Recents 功能（如果提供）必须具有可见的按钮或图标，除非在全屏模式下与其他导航功能一起隐藏。这不适用于从早期 Android 版本升级的设备，这些设备具有用于导航的物理按钮，但没有 Recents 键。

Home 和 Back 功能（如果提供）必须各自具有可见的按钮或图标，除非在全屏模式下或当 uiMode UI_MODE_TYPE_MASK 设置为 UI_MODE_TYPE_WATCH 时与其他导航功能一起隐藏。

Menu 功能自 Android 4.0 起已被弃用，取而代之的是操作栏。因此，搭载 Android 7.1 及更高版本的新设备实现绝不能为 Menu 功能实现专用物理按钮。较旧的设备实现不应为 Menu 功能实现专用物理按钮，但是如果实现了物理 Menu 按钮，并且设备正在运行 targetSdkVersion > 10 的应用程序，则设备实现

• 当操作栏可见且生成的操作溢出菜单弹出窗口不为空时，必须在操作栏上显示操作溢出按钮。对于在 Android 4.4 之前发布但升级到 Android 7.1 的设备实现，建议这样做。
• 绝不能修改通过选择操作栏中的溢出按钮显示的操作溢出弹出窗口的位置。
• 当通过选择物理菜单按钮显示操作溢出弹出窗口时，可以修改屏幕上操作溢出弹出窗口的呈现位置。

为了向后兼容，当 targetSdkVersion 小于 10 时，设备实现必须通过物理按钮、软件按键或手势使 Menu 功能可供应用程序使用。除非与其他导航功能一起隐藏，否则应显示此 Menu 功能。

支持 Assist 操作 和/或 VoiceInteractionService 的 Android 设备实现必须能够在其他导航键可见时，通过单次交互（例如点击、双击或手势）启动辅助应用。强烈建议使用长按 Home 键作为此交互。指定的交互必须启动用户选择的辅助应用，换句话说，即实现 VoiceInteractionService 的应用，或处理 ACTION_ASSIST Intent 的 Activity。

设备实现可以使用屏幕的不同部分来显示导航键，但如果是这样，则必须满足以下要求

• 设备实现导航键必须使用屏幕的不同部分，应用程序不可用，并且绝不能遮挡或以其他方式干扰应用程序可用的屏幕部分。
• 设备实现必须向应用程序提供满足 第 7.1.1 节 中定义的屏幕配置要求的显示器部分。
• 当应用程序未指定系统 UI 模式或指定 SYSTEM_UI_FLAG_VISIBLE 时，设备实现必须显示导航键。
• 当应用程序指定 SYSTEM_UI_FLAG_LOW_PROFILE 时，设备实现必须以不显眼的“低调”（例如，变暗）模式呈现导航键。
• 当应用程序指定 SYSTEM_UI_FLAG_HIDE_NAVIGATION 时，设备实现必须隐藏导航键。

7.2.4. 触摸屏输入

设备实现应具有某种类型的指针输入系统（鼠标式或触摸式）。但是，如果设备实现不支持指针输入系统，则绝不能报告 android.hardware.touchscreen 或 android.hardware.faketouch 功能常量。包含指针输入系统的设备实现

• 如果设备输入系统支持多个指针，则应支持完全独立跟踪的指针。
• 必须报告 android.content.res.Configuration.touchscreen 的值，该值对应于设备上特定触摸屏的类型。

Android 包括对各种触摸屏、触摸板和伪触摸输入设备的支持。 基于触摸屏的设备实现 与显示器相关联，使用户感觉是在直接操作屏幕上的项目。由于用户直接触摸屏幕，因此系统不需要任何额外的手段来指示正在操作的对象。相比之下，伪触摸界面提供了一种用户输入系统，该系统近似于触摸屏功能的一个子集。例如，鼠标或遥控器驱动屏幕上的光标近似于触摸，但需要用户首先指向或聚焦，然后单击。许多输入设备（如鼠标、触控板、基于陀螺仪的空中鼠标、陀螺仪指针、操纵杆和多点触控触控板）可以支持伪触摸交互。Android 包括功能常量 android.hardware.faketouch，它对应于高保真非触摸（基于指针）输入设备，例如可以充分模拟基于触摸的输入（包括基本手势支持）的鼠标或触控板，并指示设备支持触摸屏功能的模拟子集。声明伪触摸功能的设备实现必须满足 第 7.2.5 节 中的伪触摸要求。

设备实现必须报告与所用输入类型对应的正确功能。包含触摸屏（单点触摸或更好）的设备实现必须报告平台功能常量 android.hardware.touchscreen。报告平台功能常量 android.hardware.touchscreen 的设备实现还必须报告平台功能常量 android.hardware.faketouch。不包含触摸屏（并且仅依赖指针设备）的设备实现绝不能报告任何触摸屏功能，并且如果它们满足 第 7.2.5 节 中的伪触摸要求，则必须仅报告 android.hardware.faketouch。

7.2.5. 伪触摸输入

声明支持 android.hardware.faketouch 的设备实现

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

声明支持 android.hardware.faketouch.multitouch.distinct 的设备必须满足上述伪触摸的要求，并且必须还支持对两个或多个独立的指针输入进行区分跟踪。

7.2.6. 游戏控制器支持

Android 电视设备实现必须支持以下列出的游戏控制器的按钮映射。上游 Android 实现包括满足此要求的游戏控制器的实现。

7.2.6.1. 按钮映射

Android 电视设备实现必须支持以下按键映射

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

¹ KeyEvent

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

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

⁴ MotionEvent

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

¹ MotionEvent

7.2.7. 遥控器

Android 电视设备实现应该提供一个遥控器，以允许用户访问电视界面。遥控器可以是物理遥控器，也可以是从手机或平板电脑访问的基于软件的遥控器。遥控器必须满足以下定义的要求。

• 搜索功能。当用户在物理或基于软件的遥控器上调用语音搜索时，设备实现必须触发 KEYCODE_SEARCH（如果设备支持助手，则触发 KEYCODE_ASSIST）。
• 导航。所有 Android 电视遥控器必须包括 返回、主页和选择按钮以及对 D-pad 事件的支持。

7.3. 传感器

Android 包含用于访问各种传感器类型的 API。设备实现通常可以省略这些传感器，如下面的小节所述。如果设备包含具有第三方开发人员的相应 API 的特定传感器类型，则设备实现必须按照 Android SDK 文档和 传感器 上的 Android 开源文档中的描述来实现该 API。例如，设备实现

• 必须根据 android.content.pm.PackageManager 类准确报告传感器的存在或缺失。
• 必须通过 SensorManager.getSensorList() 和类似方法返回受支持传感器的准确列表。
• 必须对所有其他传感器 API 表现合理（例如，当应用程序尝试注册侦听器时，适当地返回 true 或 false；当相应的传感器不存在时，不调用传感器侦听器；等等）。
• 必须使用 Android SDK 文档中定义的每种传感器类型的相关国际单位制（公制）值 报告所有传感器测量值。
• 应该按照 Android SDK 文档中的定义，以纳秒为单位 报告事件时间戳，表示事件发生的时间并与 SystemClock.elapsedRealtimeNano() 时钟同步。强烈建议现有和新的 Android 设备满足这些要求，以便它们能够升级到未来平台版本，因为在未来平台版本中，这可能会成为必需的组件。同步误差应该低于 100 毫秒。
• 对于以 5 毫秒 + 2 * sample_time 的最小所需延迟流式传输的传感器，当应用程序处理器处于活动状态时，必须报告传感器数据，最大延迟为 100 毫秒 + 2 * sample_time。此延迟不包括任何滤波延迟。
• 必须在传感器激活后的 400 毫秒 + 2 * sample_time 内报告第一个传感器样本。此样本的精度为 0 是可以接受的。

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

某些传感器类型是复合的，这意味着它们可以从一个或多个其他传感器提供的数据中派生出来。（示例包括方向传感器和线性加速度传感器。）当设备包括 传感器类型 中描述的先决物理传感器时，设备实现应该实现这些传感器类型。如果设备实现包括复合传感器，则必须按照 复合传感器 上的 Android 开源文档中的描述来实现该传感器。

某些 Android 传感器支持 “连续”触发模式，该模式持续返回数据。对于 Android SDK 文档指示为连续传感器的任何 API，设备实现必须持续提供周期性数据样本，这些样本应该具有低于 3% 的抖动，其中抖动定义为连续事件之间报告的时间戳值之差的标准偏差。

请注意，设备实现必须确保传感器事件流不得阻止设备 CPU 进入挂起状态或从挂起状态唤醒。

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

7.3.1. 加速度计

设备实现应该包括一个 3 轴加速度计。强烈建议 Android 手持设备、Android 车载系统实现和 Android 手表设备包括此传感器。如果设备实现确实包括 3 轴加速度计，则它

• 必须实现和报告 TYPE_ACCELEROMETER 传感器。
• 对于 Android 手表设备（因为此类设备具有更严格的功耗约束）必须能够报告高达至少 50 Hz 的频率的事件，对于所有其他设备类型，必须能够报告高达 100 Hz 的事件。
• 应该报告高达至少 200 Hz 的事件。
• 必须遵守 Android API 中详细描述的 Android 传感器坐标系。Android 车载系统实现必须遵守 Android 汽车传感器坐标系。
• 必须能够在任何轴上测量从自由落体到四倍重力 (4g) 或更大的范围。
• 必须具有至少 12 位的分辨率，并且应该具有至少 16 位的分辨率。
• 如果特性在生命周期内发生变化，应该在使用时进行校准和补偿，并在设备重启之间保留补偿参数。
• 应该进行温度补偿。
• 必须具有不大于 0.05 m/s^2 的标准偏差，其中标准偏差应基于以最快采样率在至少 3 秒的时间段内收集的样本，在每个轴的基础上计算。
• 应该实现 Android SDK 文档中描述的 TYPE_SIGNIFICANT_MOTION、TYPE_TILT_DETECTOR、TYPE_STEP_DETECTOR、TYPE_STEP_COUNTER 复合传感器。强烈建议现有和新的 Android 设备实现 TYPE_SIGNIFICANT_MOTION 复合传感器。如果实现了这些传感器中的任何一个，则它们的功耗总和必须始终小于 4 mW，并且在设备处于动态或静态状态时，每个传感器的功耗应该低于 2 mW 和 0.5 mW。
• 如果包含陀螺仪传感器，则必须实现 TYPE_GRAVITY 和 TYPE_LINEAR_ACCELERATION 复合传感器，并且应该实现 TYPE_GAME_ROTATION_VECTOR 复合传感器。强烈建议现有和新的 Android 设备实现 TYPE_GAME_ROTATION_VECTOR 传感器。
• 如果还包括陀螺仪传感器和磁力计传感器，则必须实现 TYPE_ROTATION_VECTOR 复合传感器。

7.3.2. 磁力计

设备实现应该包括一个 3 轴磁力计（指南针）。如果设备确实包括 3 轴磁力计，则它

• 必须实现 TYPE_MAGNETIC_FIELD 传感器，并且应该还实现 TYPE_MAGNETIC_FIELD_UNCALIBRATED 传感器。强烈建议现有和新的 Android 设备实现 TYPE_MAGNETIC_FIELD_UNCALIBRATED 传感器。
• 必须能够报告高达至少 10 Hz 的频率的事件，并且应该报告高达至少 50 Hz 的事件。
• 必须遵守 Android API 中详细描述的 Android 传感器坐标系。
• 必须能够在饱和之前测量每个轴上 -900 µT 到 +900 µT 之间的范围。
• 通过将磁力计放置在远离动态（电流感应）和静态（磁铁感应）磁场的位置，必须具有小于 700 µT 的硬磁偏移值，并且应该具有低于 200 µT 的值。
• 必须具有等于或大于 0.6 µT 的分辨率，并且应该具有等于或大于 0.2 µT 的分辨率。
• 应该进行温度补偿。
• 必须支持硬磁偏置的在线校准和补偿，并在设备重启之间保留补偿参数。
• 必须应用软磁补偿 — 校准可以在使用时或在设备生产期间完成。
• 应该具有标准偏差，该标准偏差基于以最快采样率在至少 3 秒的时间段内收集的样本，在每个轴的基础上计算，不大于 0.5 µT。
• 如果还包括加速度计传感器和陀螺仪传感器，则必须实现 TYPE_ROTATION_VECTOR 复合传感器。
• 如果还实现了加速度计传感器，则可以实现 TYPE_GEOMAGNETIC_ROTATION_VECTOR 传感器。但是，如果实现，则当传感器以 10 Hz 批量模式注册时，其功耗必须小于 10 mW，并且应该小于 3 mW。

7.3.3. GPS

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

• 强烈建议设备在紧急电话呼叫期间继续向应用程序传递正常的 GPS/GNSS 输出，并且在紧急电话呼叫期间不阻止位置输出。
• 当通过 LocationManager#requestLocationUpdate 请求时，它必须支持至少 1 Hz 的位置输出速率。
• 当连接到 0.5 Mbps 或更快的数据速度互联网连接时，它必须能够在 10 秒内（快速首次定位时间）确定开阔天空条件（强信号、可忽略的多径、HDOP < 2）下的位置。此要求通常通过使用某种形式的辅助或预测 GPS/GNSS 技术来满足，以最大限度地缩短 GPS/GNSS 锁定时间（辅助数据包括参考时间、参考位置和卫星星历/时钟）。
  • 在进行此类位置计算后，强烈建议设备能够在开阔天空下，在位置请求重新启动后 10 秒内确定其位置，在初始位置计算后最多一小时，即使在没有数据连接和/或断电重启后发出后续请求也是如此。
• 在开阔天空条件下，在确定位置后，当静止或以小于每秒平方米 1 米的加速度移动时
  • 必须能够至少在 95% 的时间内将位置确定在 20 米以内，并将速度确定在每秒 0.5 米以内。
  • 它必须通过 GnssStatus.Callback 同时跟踪和报告来自一个星座的至少 8 颗卫星。
  • 它应该能够同时跟踪来自多个星座（例如 GPS + 至少一个 Glonass、北斗、伽利略）的至少 24 颗卫星。
• 它必须通过测试 API ‘getGnssYearOfHardware’ 报告 GNSS 技术代数。
• 如果 GNSS 技术代数报告为 “2016” 年或更新年份，则强烈建议满足并且必须满足以下所有要求。
  • 它必须报告 GPS 测量值，一旦找到就立即报告，即使尚未报告从 GPS/GNSS 计算出的位置也是如此。
  • 它必须报告 GPS 伪距和伪距率，在开阔天空条件下，在确定位置后，当静止或以小于每秒平方米 0.2 米的加速度移动时，这些伪距和伪距率足以在至少 95% 的时间内将位置计算在 20 米以内，并将速度计算在每秒 0.2 米以内。

请注意，虽然上面的一些 GPS 要求被声明为强烈建议，但下一主要版本的兼容性定义预计会将这些要求更改为必须。

7.3.4. 陀螺仪

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

• 必须实现 TYPE_GYROSCOPE 传感器，并且应该还实现 TYPE_GYROSCOPE_UNCALIBRATED 传感器。强烈建议现有和新的 Android 设备实现 SENSOR_TYPE_GYROSCOPE_UNCALIBRATED 传感器。
• 必须能够测量高达每秒 1,000 度的方向变化。
• 对于 Android 手表设备（因为此类设备具有更严格的功耗约束）必须能够报告高达至少 50 Hz 的频率的事件，对于所有其他设备类型，必须能够报告高达 100 Hz 的事件。
• 应该报告高达至少 200 Hz 的事件。
• 必须具有 12 位或更高的分辨率，并且应该具有 16 位或更高的分辨率。
• 必须进行温度补偿。
• 必须在使用时进行校准和补偿，并在设备重启之间保留补偿参数。
• 必须具有不超过 1e-7 rad^2 / s^2 每 Hz 的方差（每 Hz 方差，或 rad^2 / s）。方差允许随采样率变化，但必须受此值约束。换句话说，如果您测量 1 Hz 采样率下陀螺仪的方差，则它应不大于 1e-7 rad^2/s^2。
• 如果还包括加速度计传感器和磁力计传感器，则必须实现 TYPE_ROTATION_VECTOR 复合传感器。
• 如果包含加速度计传感器，则必须实现 TYPE_GRAVITY 和 TYPE_LINEAR_ACCELERATION 复合传感器，并且应该实现 TYPE_GAME_ROTATION_VECTOR 复合传感器。强烈建议现有和新的 Android 设备实现 TYPE_GAME_ROTATION_VECTOR 传感器。

7.3.5. 气压计

设备实现应该包括气压计（环境气压传感器）。如果设备实现包括气压计，则它

• 必须实现和报告 TYPE_PRESSURE 传感器。
• 必须能够以 5 Hz 或更高的频率传递事件。
• 必须具有足够的精度以实现估计海拔高度。
• 必须进行温度补偿。

7.3.6. 温度计

设备实现可以包括环境温度计（温度传感器）。如果存在，则必须将其定义为 SENSOR_TYPE_AMBIENT_TEMPERATURE，并且必须测量摄氏度的环境（室温）温度。

设备实现可以但不应该包括 CPU 温度传感器。如果存在，则必须将其定义为 SENSOR_TYPE_TEMPERATURE，它必须测量设备 CPU 的温度，并且不得测量任何其他温度。请注意，SENSOR_TYPE_TEMPERATURE 传感器类型已在 Android 4.0 中弃用。

7.3.7. 光度计

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

7.3.8. 接近传感器

设备实现可以包括接近传感器。可以进行语音通话并在 getPhoneType 中指示 PHONE_TYPE_NONE 以外的任何值的设备应该包括接近传感器。如果设备实现确实包括接近传感器，则它

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

7.3.9. 高保真传感器

支持一组更高质量的传感器（可以满足本节中列出的所有要求）的设备实现必须通过 android.hardware.sensor.hifi_sensors 功能标志来识别支持。

声明 android.hardware.sensor.hifi_sensors 的设备必须支持所有以下传感器类型，并满足以下质量要求

• SENSOR_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° 的灵敏度随温度变化。

• SENSOR_TYPE_GYROSCOPE

  • 必须具有至少 -1000 和 +1000 dps 之间的测量范围。
  • 必须具有至少 16 LSB/dps 的测量分辨率。
  • 必须具有 12.5 Hz 或更低的最小测量频率。
  • 必须具有 400 Hz 或更高的最大测量频率。
  • 必须具有不超过 0.014°/s/√Hz 的测量噪声。
  • 应该具有来自 24 小时静态数据集的 < 0.0002 °/s √Hz 的静态偏置稳定性。
  • 应该具有 ≤ +/- 0.05 °/ s / °C 的偏置随温度变化。
  • 应该具有 ≤ 0.02% / °C 的灵敏度随温度变化。
  • 应该具有 ≤ 0.2% 的最佳拟合线非线性。
  • 应该具有 ≤ 0.007 °/s/√Hz 的噪声密度。

• 具有与 SENSOR_TYPE_GYROSCOPE 相同质量要求的 SENSOR_TYPE_GYROSCOPE_UNCALIBRATED。

• SENSOR_TYPE_GEOMAGNETIC_FIELD
  • 必须具有至少 -900 和 +900 uT 之间的测量范围。
  • 必须具有至少 5 LSB/uT 的测量分辨率。
  • 必须具有 5 Hz 或更低的最小测量频率。
  • 必须具有 50 Hz 或更高的最大测量频率。
  • 必须具有不超过 0.5 uT 的测量噪声。
• 具有与 SENSOR_TYPE_GEOMAGNETIC_FIELD 相同质量要求的 SENSOR_TYPE_MAGNETIC_FIELD_UNCALIBRATED，此外
  • 必须实现此传感器的非唤醒形式，并具有至少 600 个传感器事件的缓冲能力。
• SENSOR_TYPE_PRESSURE
  • 必须具有至少 300 和 1100 hPa 之间的测量范围。
  • 必须具有至少 80 LSB/hPa 的测量分辨率。
  • 必须具有 1 Hz 或更低的最小测量频率。
  • 必须具有 10 Hz 或更高的最大测量频率。
  • 必须具有不超过 2 Pa/√Hz 的测量噪声。
  • 必须实现此传感器的非唤醒形式，并具有至少 300 个传感器事件的缓冲能力。
  • 必须具有不差于 2 mW 的批量处理功耗。
• SENSOR_TYPE_GAME_ROTATION_VECTOR
  • 必须实现此传感器的非唤醒形式，并具有至少 300 个传感器事件的缓冲能力。
  • 必须具有不差于 4 mW 的批量处理功耗。
• SENSOR_TYPE_SIGNIFICANT_MOTION
  • 当设备静态时，必须具有不差于 0.5 mW 的功耗，当设备移动时，必须具有不差于 1.5 mW 的功耗。
• SENSOR_TYPE_STEP_DETECTOR
  • 必须实现此传感器的非唤醒形式，并具有至少 100 个传感器事件的缓冲能力。
  • 当设备静态时，必须具有不差于 0.5 mW 的功耗，当设备移动时，必须具有不差于 1.5 mW 的功耗。
  • 必须具有不差于 4 mW 的批量处理功耗。
• SENSOR_TYPE_STEP_COUNTER
  • 当设备静态时，必须具有不差于 0.5 mW 的功耗，当设备移动时，必须具有不差于 1.5 mW 的功耗。
• SENSOR_TILT_DETECTOR
  • 当设备静态时，必须具有不差于 0.5 mW 的功耗，当设备移动时，必须具有不差于 1.5 mW 的功耗。

此外，此类设备必须满足以下传感器子系统要求

• 加速度计、陀螺仪传感器和磁力计报告的同一物理事件的事件时间戳必须彼此相差在 2.5 毫秒以内。
• 陀螺仪传感器事件时间戳必须与摄像头子系统在同一时基上，并且误差在 1 毫秒以内。
• 高保真传感器必须在数据在物理传感器上可用到应用程序的 5 毫秒内将样本传递到应用程序。
• 当启用以下传感器的任何组合时，当设备静态时，功耗必须不高于 0.5 mW，当设备移动时，功耗必须不高于 2.0 mW
  • SENSOR_TYPE_SIGNIFICANT_MOTION
  • SENSOR_TYPE_STEP_DETECTOR
  • SENSOR_TYPE_STEP_COUNTER
  • SENSOR_TILT_DETECTORS

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

声明 android.hardware.sensor.hifi_sensors 的设备实现可以还支持以下传感器类型，但如果存在这些传感器类型，则它们必须满足以下最小缓冲能力要求

• SENSOR_TYPE_PROXIMITY：100 个传感器事件

7.3.10. 指纹传感器

具有安全锁屏的设备实现应该包括指纹传感器。如果设备实现包括指纹传感器并具有第三方开发人员的相应 API，则它

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

7.3.11. 仅限 Android Automotive 的传感器

汽车专用传感器在 android.car.CarSensorManager API 中定义。

7.3.11.1. 当前档位

Android 车载系统实现应该提供当前档位作为 SENSOR_TYPE_GEAR。

7.3.11.2. 日夜模式

Android 车载系统实现必须支持定义为 SENSOR_TYPE_NIGHT 的日/夜模式。此标志的值必须与仪表盘日/夜模式一致，并且应该基于环境光传感器输入。底层的环境光传感器可以与 光度计 相同。

7.3.11.3. 驾驶状态

Android 车载系统实现必须支持驾驶状态，该状态定义为 SENSOR_TYPE_DRIVING_STATUS，当车辆完全停止并停放时，默认值为 DRIVE_STATUS_UNRESTRICTED。设备制造商有责任根据适用于产品发货市场的所有法律和法规配置 SENSOR_TYPE_DRIVING_STATUS。

7.3.11.4. 轮速

Android 车载系统实现必须提供定义为 SENSOR_TYPE_CAR_SPEED 的车速。

7.3.12. 姿势传感器

设备实现可以支持具有 6 个自由度的姿态传感器。建议 Android 手持设备支持此传感器。如果设备实现确实支持具有 6 个自由度的姿态传感器，则它

• 必须实现和报告 TYPE_POSE_6DOF 传感器。
• 必须比仅旋转矢量更准确。

7.4. 数据连接

7.4.1. 电话

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

Android 可以在不包括电话硬件的设备上使用。也就是说，Android 与非电话设备兼容。但是，如果设备实现确实包括 GSM 或 CDMA 电话功能，则它必须完全实现该技术的 API 支持。不包括电话硬件的设备实现必须将完整 API 实现为空操作。

7.4.1.1. 号码屏蔽兼容性

Android 电话设备实现必须包括号码屏蔽支持，并且

• 必须完全实现 BlockedNumberContract 和 SDK 文档中描述的相应 API。
• 必须屏蔽来自 ‘BlockedNumberProvider’ 中的电话号码的所有呼叫和消息，而无需与应用程序进行任何交互。唯一的例外是 SDK 文档中描述的临时取消号码屏蔽的情况。
• 对于被屏蔽的呼叫，不得写入 平台通话记录提供程序。
• 对于被屏蔽的消息，不得写入 Telephony 提供程序。
• 必须实现被屏蔽号码管理 UI，该 UI 通过 TelecomManager.createManageBlockedNumbersIntent() 方法返回的 intent 打开。
• 不得允许辅助用户查看或编辑设备上的被屏蔽号码，因为 Android 平台假定主要用户对设备上的电话服务（单个实例）具有完全控制权。所有屏蔽相关的 UI 必须对辅助用户隐藏，并且仍必须遵守被屏蔽列表。
• 当设备更新到 Android 7.0 时，应该将被屏蔽号码迁移到提供程序中。

7.4.2. IEEE 802.11 (Wi-Fi)

所有 Android 设备实现应该包括对一种或多种形式的 802.11 的支持。如果设备实现确实包括对 802.11 的支持并将功能公开给第三方应用程序，则它必须实现相应的 Android API 并

• 必须报告硬件功能标志 android.hardware.wifi。
• 必须实现 SDK 文档中描述的 多播 API。
• 必须支持多播 DNS (mDNS)，并且在任何操作时间（包括
  • 即使屏幕未处于活动状态时）不得过滤 mDNS 数据包 (224.0.0.251)。
  • 对于 Android 电视设备实现，即使在待机功耗状态下也是如此。

7.4.2.1. Wi-Fi Direct

设备实现应该包括对 Wi-Fi Direct（Wi-Fi 对等网络）的支持。如果设备实现确实包括对 Wi-Fi Direct 的支持，则它必须实现 SDK 文档中描述的 相应 Android API。如果设备实现包括对 Wi-Fi Direct 的支持，则它

• 必须报告硬件功能 android.hardware.wifi.direct。
• 必须支持常规 Wi-Fi 操作。
• 应该支持并发 Wi-Fi 和 Wi-Fi Direct 操作。

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

设备实现应该包括对 Android SDK 文档中描述的 Wi-Fi 隧道式直接链路设置 (TDLS) 的支持。如果设备实现确实包括对 TDLS 的支持并且 TDLS 由 WiFiManager API 启用，则设备

• 应该仅在可能且有利时使用 TDLS。
• 应该具有一些启发式方法，并且在 TDLS 的性能可能比通过 Wi-Fi 接入点更差时不使用 TDLS。

7.4.3. 蓝牙

支持 android.hardware.vr.high_performance 功能的设备实现必须支持蓝牙 4.2 和蓝牙低功耗数据长度扩展。

Android 包括对 蓝牙和蓝牙低功耗 的支持。包括对蓝牙和蓝牙低功耗支持的设备实现必须声明相关的平台功能（分别为 android.hardware.bluetooth 和 android.hardware.bluetooth_le）并实现平台 API。设备实现应该实现相关的蓝牙配置文件，例如 A2DP、AVCP、OBEX 等，以适应设备。

Android 车载系统实现应该支持消息访问配置文件 (MAP)。Android 车载系统实现必须支持以下蓝牙配置文件

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

包括对蓝牙低功耗支持的设备实现

• 必须声明硬件功能 android.hardware.bluetooth_le。
• 必须启用基于 GATT（通用属性配置文件）的蓝牙 API，如 SDK 文档和 android.bluetooth 中所述。
• 强烈建议实现不超过 15 分钟的可解析私有地址 (RPA) 超时，并在超时时轮换地址以保护用户隐私。
• 在实现 ScanFilter API 时，应该支持将过滤逻辑卸载到蓝牙芯片组，并且每当通过 android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported() 方法查询时，必须报告过滤逻辑实现的正确值。
• 应该支持将批量扫描卸载到蓝牙芯片组，但如果不支持，则每当通过 android.bluetooth.BluetoothAdapter.isOffloadedScanBatchingSupported() 方法查询时，必须报告 ‘false’。
• 应该支持至少 4 个插槽的多重广播，但如果不支持，则每当通过 android.bluetooth.BluetoothAdapter.isMultipleAdvertisementSupported() 方法查询时，必须报告 ‘false’。

7.4.4. 近场通信

设备实现应该包括用于近场通信 (NFC) 的收发器和相关硬件。如果设备实现确实包括 NFC 硬件并计划将其提供给第三方应用程序，则它

• 必须从 android.content.pm.PackageManager.hasSystemFeature() 方法 报告 android.hardware.nfc 功能。
• 必须能够通过以下 NFC 标准读取和写入 NDEF 消息
  • 必须能够通过以下 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（由 NFC 论坛定义）
  • 强烈建议能够通过以下 NFC 标准读取和写入 NDEF 消息以及原始数据。请注意，虽然以下 NFC 标准被声明为强烈建议，但未来版本的兼容性定义计划将这些标准更改为必须。这些标准在此版本中是可选的，但在未来版本中将是必需的。强烈鼓励运行此版本 Android 的现有和新设备现在满足这些要求，以便它们能够升级到未来平台版本。
    • NfcV (ISO 15693)
  • 应该能够读取 Thinfilm NFC 条形码 产品的条形码和 URL（如果已编码）。
  • 必须能够通过以下对等网络标准和协议传输和接收数据
    • ISO 18092
    • LLCP 1.2（由 NFC 论坛定义）
    • SDP 1.0（由 NFC 论坛定义）
    • NDEF 推送协议
    • SNEP 1.0（由 NFC 论坛定义）
  • 必须包含对 Android Beam 的支持。
  • 必须实现 SNEP 默认服务器。默认 SNEP 服务器接收到的有效 NDEF 消息必须使用 android.nfc.ACTION_NDEF_DISCOVERED intent 分派到应用。在设置中禁用 Android Beam 不得禁用传入 NDEF 消息的分派。
  • 必须遵守 android.settings.NFCSHARING_SETTINGS intent 以显示 NFC 共享设置。
  • 必须实现 NPP 服务器。NPP 服务器接收的消息必须以与 SNEP 默认服务器相同的方式处理。
  • 必须实现 SNEP 客户端，并在启用 Android Beam 时尝试将出站 P2P NDEF 发送到默认 SNEP 服务器。如果未找到默认 SNEP 服务器，则客户端必须尝试发送到 NPP 服务器。
  • 必须允许前台 Activity 使用 android.nfc.NfcAdapter.setNdefPushMessage、android.nfc.NfcAdapter.setNdefPushMessageCallback 和 android.nfc.NfcAdapter.enableForegroundNdefPush 设置出站 P2P NDEF 消息。
  • 在发送出站 P2P NDEF 消息之前，应使用手势或屏幕确认，例如“触摸以共享 (Touch to Beam)”。
  • 应默认启用 Android Beam，并且即使在启用另一种专有的 NFC P2p 模式时，也必须能够使用 Android Beam 发送和接收。
  • 当设备支持蓝牙对象推送配置文件时，必须支持 NFC 连接切换到蓝牙。当使用 android.nfc.NfcAdapter.setBeamPushUris 时，设备实现必须支持连接切换到蓝牙，方法是实现 NFC 论坛的“ Connection Handover version 1.2 ”和“ Bluetooth Secure Simple Pairing Using NFC version 1.0 ”规范。此类实现必须实现切换 LLCP 服务，服务名称为“urn:nfc:sn:handover”，以便通过 NFC 交换切换请求/选择记录，并且必须使用蓝牙对象推送配置文件进行实际的蓝牙数据传输。出于传统原因（为了与 Android 4.1 设备保持兼容），该实现仍应接受 SNEP GET 请求，以便通过 NFC 交换切换请求/选择记录。但是，实现本身不应发送 SNEP GET 请求来执行连接切换。
  • 在 NFC 发现模式下，必须轮询所有受支持的技术。
  • 当设备处于唤醒状态、屏幕处于活动状态且锁屏已解锁时，应处于 NFC 发现模式。

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

Android 包括对 NFC 主机卡模拟 (HCE) 模式的支持。如果设备实现包含能够进行 HCE（对于 NfcA 和/或 NfcB）的 NFC 控制器芯片组，并且支持应用 ID (AID) 路由，则

• 必须报告 android.hardware.nfc.hce 功能常量。
• 必须支持 Android SDK 中定义的 NFC HCE API。

如果设备实现包含能够进行 NfcF HCE 的 NFC 控制器芯片组，并且为第三方应用实现了该功能，则

• 必须报告 android.hardware.nfc.hcef 功能常量。
• 必须实现 Android SDK 中定义的 NfcF 卡模拟 API。

此外，设备实现可以包含对以下 MIFARE 技术的读/写器支持。

• MIFARE Classic
• MIFARE Ultralight
• MIFARE Classic 上的 NDEF

请注意，Android 包含用于这些 MIFARE 类型的 API。如果设备实现支持读/写器角色中的 MIFARE，则

• 必须实现 Android SDK 文档中记录的相应 Android API。
• 必须从 android.content.pm.PackageManager.hasSystemFeature() 方法报告功能 com.nxp.mifare。请注意，这不是标准的 Android 功能，因此不会作为常量出现在 android.content.pm.PackageManager 类中。
• 除非设备实现还实现了本节中描述的通用 NFC 支持，否则不得实现相应的 Android API，也不得报告 com.nxp.mifare 功能。

如果设备实现不包含 NFC 硬件，则不得从 android.content.pm.PackageManager.hasSystemFeature() 方法声明 android.hardware.nfc 功能，并且必须将 Android NFC API 实现为无操作 (no-op)。

由于类 android.nfc.NdefMessage 和 android.nfc.NdefRecord 表示与协议无关的数据表示格式，因此即使设备实现不包含对 NFC 的支持或未声明 android.hardware.nfc 功能，也必须实现这些 API。

7.4.5. 最低网络能力

设备实现必须包含对一种或多种形式的数据网络的支持。具体来说，设备实现必须包含对至少一种能够达到 200Kbit/秒或更高速度的数据标准的支持。满足此要求的技术示例包括 EDGE、HSPA、EV-DO、802.11g、以太网、蓝牙 PAN 等。

物理网络标准（如以太网）是主要数据连接的设备实现还应包含对至少一种常见的无线数据标准（如 802.11 (Wi-Fi)）的支持。

设备可以实现多种形式的数据连接。

设备必须包含 IPv6 网络堆栈，并支持使用托管 API（例如 java.net.Socket 和 java.net.URLConnection ）以及原生 API（例如 AF_INET6 套接字）的 IPv6 通信。所需的 IPv6 支持级别取决于网络类型，如下所示

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

IPv6 必须默认启用。

为了确保 IPv6 通信与 IPv4 一样可靠，发送到设备的单播 IPv6 数据包不得被丢弃，即使屏幕未处于活动状态也是如此。如果为了节省电量而有必要，则可以对冗余的组播 IPv6 数据包（例如，重复的相同路由器通告）进行硬件或固件速率限制。在这种情况下，速率限制不得导致设备在任何使用 RA 生存期至少为 180 秒的符合 IPv6 标准的网络上失去 IPv6 连接。

IPv6 连接必须在低电耗模式下保持。

7.4.6. 同步设置

设备实现必须默认启用主自动同步设置，以便 getMasterSyncAutomatically() 方法返回“true”。

7.4.7. 省流量模式

强烈建议采用按流量计费连接的设备实现提供数据保护程序模式。

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

• 必须支持 ConnectivityManager 类中的所有 API，如 SDK 文档中所述

• 必须在设置中提供用户界面，允许用户将应用添加到允许列表或从允许列表中移除应用。

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

• 对于 ConnectivityManager.getRestrictBackgroundStatus()，必须返回值 RESTRICT_BACKGROUND_STATUS_DISABLED

• 不得广播 ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED

• 必须具有一个 Activity 来处理 Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS intent，但可以将其实现为无操作 (no-op)。

7.5. 相机

设备实现应包含后置摄像头，并且可以包含前置摄像头。后置摄像头是位于设备显示屏对面一侧的摄像头；也就是说，它像传统相机一样拍摄设备远侧的场景。前置摄像头是位于设备显示屏同一侧的摄像头；也就是说，它是通常用于拍摄用户图像的摄像头，例如用于视频会议和类似应用。

如果设备实现包含至少一个摄像头，则在摄像头打开以进行基本预览和静止图像拍摄时，应用必须能够同时分配 3 个 RGBA_8888 位图，其大小等于设备上最大分辨率摄像头传感器生成的图像大小。

7.5.1. 后置摄像头

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

• 必须报告功能标志 android.hardware.camera 和 android.hardware.camera.any。
• 必须具有至少 200 万像素的分辨率。
• 应在摄像头驱动程序中实现硬件自动对焦或软件自动对焦（对应用软件透明）。
• 可以具有固定对焦或 EDOF（扩展景深）硬件。
• 可以包含闪光灯。如果摄像头包含闪光灯，则在 Camera 预览图面上注册了 android.hardware.Camera.PreviewCallback 实例时，闪光灯不得亮起，除非应用通过启用 Camera.Parameters 对象的 FLASH_MODE_AUTO 或 FLASH_MODE_ON 属性显式启用了闪光灯。请注意，此约束不适用于设备的内置系统摄像头应用，而仅适用于使用 Camera.PreviewCallback 的第三方应用。

7.5.2. 前置摄像头

设备实现可以包含前置摄像头。如果设备实现包含至少一个前置摄像头，则

• 必须报告功能标志 android.hardware.camera.any 和 android.hardware.camera.front。
• 必须具有至少 VGA (640x480 像素) 的分辨率。
• 不得将前置摄像头用作 Camera API 的默认摄像头。Android 中的摄像头 API 对前置摄像头有特定的支持，即使前置摄像头是设备上唯一的摄像头，设备实现也不得将 API 配置为将前置摄像头视为默认的后置摄像头。
• 可以包含 第 7.5.1 节 中描述的后置摄像头可用的功能（例如自动对焦、闪光灯等）。
• 必须水平反射（即镜像）应用在 CameraPreview 中显示的流，如下所示
  • 如果设备实现能够由用户旋转（例如通过加速度计自动旋转或通过用户输入手动旋转），则摄像头预览必须相对于设备的当前方向水平镜像。
  • 如果当前应用已通过调用 android.hardware.Camera.setDisplayOrientation() 方法显式请求旋转 Camera 显示，则摄像头预览必须相对于应用指定的方向水平镜像。
  • 否则，预览必须沿设备的默认水平轴镜像。
• 必须以与摄像头预览图像流相同的方式镜像后视图 (postview) 显示的图像。如果设备实现不支持后视图，则此要求显然不适用。
• 不得镜像返回到应用回调或提交到媒体存储的最终捕获的静止图像或视频流。

7.5.3. 外部摄像头

设备实现可以包含对外置摄像头的支持，该摄像头不一定始终连接。如果设备包含对外置摄像头的支持，则

• 必须声明平台功能标志 android.hardware.camera.external 和 android.hardware camera.any。
• 可以支持多个摄像头。
• 如果外置摄像头通过 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 实现以下行为

• 如果应用从未调用过 android.hardware.Camera.Parameters.setPreviewFormat(int)，则设备必须对提供给应用回调的预览数据使用 android.hardware.PixelFormat.YCbCr_420_SP。
• 如果应用注册了 android.hardware.Camera.PreviewCallback 实例，并且当预览格式为 YCbCr_420_SP 时系统调用了 onPreviewFrame() 方法，则传递到 onPreviewFrame() 中的 byte[] 中的数据必须进一步采用 NV21 编码格式。也就是说，NV21 必须是默认格式。
• 对于 android.hardware.Camera，设备实现必须支持 YV12 格式（由 android.graphics.ImageFormat.YV12 常量表示），用于前置和后置摄像头的摄像头预览。（硬件视频编码器和摄像头可以使用任何原生像素格式，但设备实现必须支持转换为 YV12。）
• 对于 android.hardware.camera2，设备实现必须支持 android.hardware.ImageFormat.YUV_420_888 和 android.hardware.ImageFormat.JPEG 格式作为通过 android.media.ImageReader API 的输出。

设备实现必须仍然实现 Android SDK 文档中包含的完整 Camera API，无论设备是否包含硬件自动对焦或其他功能。例如，缺少自动对焦功能的摄像头必须仍然调用任何已注册的 android.hardware.Camera.AutoFocusCallback 实例（即使这与非自动对焦摄像头无关）。请注意，这确实适用于前置摄像头；例如，即使大多数前置摄像头不支持自动对焦，API 回调也必须按所述“伪造”。

如果底层硬件支持该功能，设备实现必须识别并遵守在 android.hardware.Camera.Parameters 类上定义为常量的每个参数名称。如果设备硬件不支持某项功能，则 API 必须按文档中的说明运行。相反，设备实现不得遵守或识别传递给 android.hardware.Camera.setParameters() 方法的字符串常量，除非这些常量在 android.hardware.Camera.Parameters 上记录为常量。也就是说，如果硬件允许，设备实现必须支持所有标准 Camera 参数，并且不得支持自定义 Camera 参数类型。例如，支持使用高动态范围 (HDR) 成像技术进行图像捕获的设备实现必须支持摄像头参数 Camera.SCENE_MODE_HDR。

由于并非所有设备实现都可以完全支持 android.hardware.camera2 API 的所有功能，因此设备实现必须使用 android.info.supportedHardwareLevel 属性报告适当的支持级别，如 Android SDK 中所述，并报告相应的 框架功能标志。

设备实现还必须通过 android.request.availableCapabilities 属性声明其 android.hardware.camera2 的各个摄像头功能，并声明相应的 功能标志；如果任何连接的摄像头设备支持该功能，则设备必须定义该功能标志。

每当摄像头拍摄新照片并将照片条目添加到媒体存储时，设备实现必须广播 Camera.ACTION_NEW_PICTURE intent。

每当摄像头录制新视频并将视频条目添加到媒体存储时，设备实现必须广播 Camera.ACTION_NEW_VIDEO intent。

7.5.5. 相机方向

如果存在前置和后置摄像头，则必须对其进行定向，使摄像头的长边与屏幕的长边对齐。也就是说，当设备处于横向方向时，摄像头必须以横向方向捕获图像。这适用于设备的自然方向，即适用于横向主设备以及纵向主设备。

7.6. 内存和存储

7.6.1. 最低内存和存储空间

设备实现上内核和用户空间可用的内存必须至少等于或大于下表指定的最小值。（有关屏幕尺寸和密度定义，请参阅第 7.1.1 节。）

密度和屏幕尺寸	32 位设备	64 位设备
Android Watch 设备（由于屏幕较小）	416MB	不适用
小型/普通屏幕上 280dpi 或更低 大型屏幕上 mdpi 或更低 超大屏幕上 ldpi 或更低	512MB	816MB
小型/普通屏幕上 xhdpi 或更高 大型屏幕上 hdpi 或更高 超大屏幕上 mdpi 或更高	608MB	944MB
小型/普通屏幕上 400dpi 或更高 大型屏幕上 xhdpi 或更高 超大屏幕上 tvdpi 或更高	896MB	1280MB
小型/普通屏幕上 560dpi 或更高 大型屏幕上 400dpi 或更高 超大屏幕上 xhdpi 或更高	1344MB	1824MB

最小内存值必须是在内核控制之外已专用于硬件组件（如无线电、视频等）的任何内存空间之外的额外内存。

除非是 Android Watch，否则内核和用户空间可用的内存少于 512MB 的设备实现必须为 ActivityManager.isLowRamDevice() 返回值“true”。

Android 电视设备必须具有至少 4GB 的非易失性存储空间，其他设备实现必须具有至少 3GB 的非易失性存储空间，可用于应用私有数据。也就是说，Android 电视设备的 /data 分区必须至少为 4GB，其他设备实现的 /data 分区必须至少为 3GB。强烈建议运行 Android 的设备实现具有至少 4GB 的非易失性存储空间用于应用私有数据，以便能够升级到未来的平台版本。

Android API 包括 Download Manager，应用可以使用它来下载数据文件。Download Manager 的设备实现必须能够将至少 100MB 大小的单个文件下载到默认的“缓存”位置。

7.6.2. 应用共享存储空间

设备实现必须为应用提供共享存储，通常也称为“共享外部存储”。

设备实现必须配置为默认情况下“开箱即用”安装共享存储。如果共享存储未安装在 Linux 路径 /sdcard 上，则设备必须包含从 /sdcard 到实际挂载点的 Linux 符号链接。

设备实现可以具有用于用户可访问的可移动存储的硬件，例如安全数字 (SD) 卡插槽。如果此插槽用于满足共享存储要求，则设备实现

• 必须实现 toast 或弹出式用户界面，以便在没有 SD 卡时警告用户。
• 必须包含 1GB 或更大的 FAT 格式 SD 卡，或者在包装盒和购买时可用的其他材料上显示 SD 卡必须单独购买。
• 必须默认挂载 SD 卡。

或者，设备实现可以将内部（不可移动）存储分配为应用的共享存储，如上游 Android 开源项目中所包含的那样；设备实现应使用此配置和软件实现。如果设备实现使用内部（不可移动）存储来满足共享存储要求，虽然该存储可以与应用私有数据共享空间，但它的大小必须至少为 1GB，并且挂载在 /sdcard 上（或者，如果挂载在其他位置，则 /sdcard 必须是指向物理位置的符号链接）。

设备实现必须按照文档规定，在此共享存储上强制执行 android.permission.WRITE_EXTERNAL_STORAGE 权限。否则，获得该权限的任何应用都必须可写入共享存储。

包含多个共享存储路径（例如 SD 卡插槽和共享内部存储）的设备实现，必须仅允许具有 WRITE_EXTERNAL_STORAGE 权限的预安装和特权 Android 应用写入辅助外部存储，除非写入其软件包特定的目录或在触发 ACTION_OPEN_DOCUMENT_TREE intent 返回的 URI 中。

但是，设备实现应通过 Android 的媒体扫描程序服务和 android.provider.MediaStore 透明地公开来自两个存储路径的内容。

无论使用何种形式的共享存储，如果设备实现具有支持 USB 外围设备模式的 USB 端口，则必须提供某种机制来从主机计算机访问共享存储的内容。设备实现可以使用 USB 大容量存储，但应使用媒体传输协议来满足此要求。如果设备实现支持媒体传输协议，则

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

7.6.3. 可采纳的存储设备

如果可移动存储设备端口位于长期稳定的位置（例如在电池仓或其他保护盖内），则强烈建议设备实现实现 可采纳的存储。

电视等设备实现可以通过 USB 端口启用采纳，因为设备预计是静态的而不是移动的。但是，对于其他本质上是移动的设备实现，强烈建议在长期稳定的位置实现可采纳的存储，因为意外断开连接可能会导致数据丢失/损坏。

7.7. USB

设备实现应支持 USB 外围设备模式，并应支持 USB 主机模式。

7.7.1. USB 外围设备模式

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

• 该端口必须可连接到具有标准 A 型或 C 型 USB 端口的 USB 主机。
• 该端口应使用 micro-B、micro-AB 或 Type-C USB 外形尺寸。强烈建议现有和新的 Android 设备满足这些要求，以便能够升级到未来的平台版本。
• 该端口应位于设备底部（根据自然方向）或为所有应用（包括主屏幕）启用软件屏幕旋转，以便当设备以端口位于底部的方式定向时，显示屏可以正确绘制。强烈建议现有和新的 Android 设备满足这些要求，以便能够升级到未来的平台版本。
• 它必须允许与 Android 设备连接的 USB 主机使用 USB 大容量存储或媒体传输协议访问共享存储卷的内容。
• 它应实现 Android 开放附件 (AOA) API 和规范，如 Android SDK 文档中所述，并且如果是 Android 手持设备，则必须实现 AOA API。实现 AOA 规范的设备实现
  • 必须声明对硬件功能 android.hardware.usb.accessory 的支持。
  • 必须实现 Android SDK 文档中记录的 USB 音频类。
  • USB 大容量存储类必须在 USB 大容量存储的接口描述 iInterface 字符串的末尾包含字符串“android”
• 它应实现支持在 HS 啁啾声和流量期间汲取 1.5 A 电流，如 USB 电池充电规范，修订版 1.2 中所指定。强烈建议现有和新的 Android 设备满足这些要求，以便能够升级到未来的平台版本。
• Type-C 设备必须根据 Type-C 电阻标准检测 1.5A 和 3.0A 充电器，并且必须检测广告中的变化。
• 还支持 USB 主机模式的 Type-C 设备强烈建议支持 Power Delivery 以进行数据和电源角色交换。
• Type-C 设备应支持 Power Delivery 以进行高压充电，并支持替代模式，例如显示输出。
• USB 标准设备描述符中 iSerialNumber 的值必须等于 android.os.Build.SERIAL 的值。
• Type-C 设备强烈建议不要支持超出默认级别的修改 Vbus 电压或更改接收器/源角色等专有充电方法，因为这可能会导致与支持标准 USB Power Delivery 方法的充电器或设备的互操作性问题。虽然这被称为“强烈建议”，但在未来的 Android 版本中，我们可能会要求所有 Type-C 设备都支持与标准 Type-C 充电器的完全互操作性。

7.7.2. USB 主机模式

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

• 如果设备实现支持 USB 3.1，则应使用 type-C USB 端口。
• 可以使用非标准端口外形尺寸，但如果是这样，则必须随附将端口适配到标准 A 型或 C 型 USB 端口的电缆或多个电缆。
• 可以使用 micro-AB USB 端口，但如果是这样，则应随附将端口适配到标准 A 型或 C 型 USB 端口的电缆或多个电缆。
• 强烈建议实现 Android SDK 文档中记录的 USB 音频类。
• 必须实现 Android SDK 文档中记录的 Android USB 主机 API，并且必须声明对硬件功能 android.hardware.usb.host 的支持。
• 应支持在主机模式下为设备充电；对于 USB Type-C 连接器，宣传至少 1.5A 的源电流，如 [USB Type-C 电缆和连接器规范修订版 1.2] (http://www.usb.org/developers/docs/usb_31_021517.zip) 的终止参数部分中所指定，或使用 USB 电池充电规范，修订版 1.2 中针对 Micro-AB 连接器指定的充电下游端口 (CDP) 输出电流范围。
• USB Type-C 设备强烈建议支持 DisplayPort，应支持 USB 超高速数据速率，并强烈建议支持 Power Delivery 以进行数据和电源角色交换。
• 具有任何 A 型或 AB 型端口的设备不得随附将此端口转换为 C 型插座的适配器。
• 如果支持存储访问框架 (SAF)，则必须识别任何远程连接的 MTP（媒体传输协议）设备，并通过 ACTION_GET_CONTENT、ACTION_OPEN_DOCUMENT 和 ACTION_CREATE_DOCUMENT intent 使其内容可访问。
• 如果使用 Type-C USB 端口并包含对外围设备模式的支持，则必须实现 USB Type-C 规范（第 4.5.1.3.3 节）定义的双重角色端口功能。
• 如果支持双重角色端口功能，则应实现最适合设备外形尺寸的 Try.* 模型。例如，手持设备应实现 Try.SNK 模型。

7.8. 音频

7.8.1. 麦克风

设备实现可以省略麦克风。但是，如果设备实现省略麦克风，则不得报告 android.hardware.microphone 功能常量，并且必须至少将音频录制 API 实现为无操作 (no-op)，如第 7 节中所述。相反，拥有麦克风的设备实现

• 必须报告 android.hardware.microphone 功能常量。
• 必须满足 第 5.4 节中的音频录制要求。
• 必须满足 第 5.6 节中的音频延迟要求。
• 强烈建议支持第 7.8.3 节中描述的近超声录制。

7.8.2. 音频输出

具有扬声器或带有用于音频输出外围设备（如耳机或外接扬声器）的音频/多媒体输出端口的设备实现

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

相反，如果设备实现不包含扬声器或音频输出端口，则必须不报告 android.hardware.audio 输出功能，并且必须至少将音频输出相关 API 实现为无操作。

Android 手表设备实现可以但不应具有音频输出，但其他类型的 Android 设备实现必须具有音频输出并声明 android.hardware.audio.output。

7.8.2.1. 模拟音频端口

为了与 Android 生态系统中使用 3.5 毫米音频插头的耳机和其他音频配件兼容，如果设备实现包含一个或多个模拟音频端口，则至少一个音频端口应为 4 芯 3.5 毫米音频插孔。如果设备实现具有 4 芯 3.5 毫米音频插孔，则

• 必须支持音频播放到立体声耳机和带麦克风的立体声耳机，并且应支持从带麦克风的立体声耳机进行音频录制。
• 必须支持具有 CTIA 引脚排列顺序的 TRRS 音频插头，并且应支持具有 OMTP 引脚排列顺序的音频插头。
• 如果设备实现支持麦克风，则必须支持检测插入的音频配件上的麦克风，并广播 android.intent.action.HEADSET_PLUG，并将附加值 microphone 设置为 1。
• 必须支持检测和映射到音频插头上麦克风和接地导体之间以下 3 个等效阻抗范围的键码
  • 70 欧姆或更小：KEYCODE_HEADSETHOOK
  • 210-290 欧姆：KEYCODE_VOLUME_UP
  • 360-680 欧姆：KEYCODE_VOLUME_DOWN
• 强烈建议检测和映射到音频插头上麦克风和接地导体之间以下范围的等效阻抗的键码
  • 110-180 欧姆：KEYCODE_VOICE_ASSIST
• 必须在插入插头时触发 ACTION_HEADSET_PLUG，但仅在插头上的所有触点都接触到插孔上的相关段之后。
• 必须能够在 32 欧姆扬声器阻抗上驱动至少 150mV ± 10% 的输出电压。
• 必须具有 1.8V ~ 2.9V 之间的麦克风偏置电压。

7.8.3. 近超声波

近超声音频是 18.5 kHz 到 20 kHz 频段。设备实现必须通过 AudioManager.getProperty API 正确报告对近超声音频能力的支持，如下所示

• 如果 PROPERTY_SUPPORT_MIC_NEAR_ULTRASOUND 为“true”，则 VOICE_RECOGNITION 和 UNPROCESSED 音频源必须满足以下要求
  • 麦克风在 18.5 kHz 到 20 kHz 频段的平均功率响应必须不低于 2 kHz 响应以下 15 dB。
  • 对于 -26 dBFS 的 19 kHz 音调，麦克风在 18.5 kHz 到 20 kHz 范围内的非加权信噪比必须不低于 50 dB。
• 如果 PROPERTY_SUPPORT_SPEAKER_NEAR_ULTRASOUND 为“true”，则扬声器在 18.5 kHz - 20 kHz 范围内的平均响应必须不低于 2 kHz 响应以下 40 dB。

7.9. 虚拟现实

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

7.9.1. 虚拟现实模式

支持 VR 应用程序模式的 Android 手持设备实现，该模式处理通知的立体渲染并在 VR 应用程序具有用户焦点时禁用单眼系统 UI 组件，必须声明 android.software.vr.mode 功能。声明此功能的设备必须包含一个应用程序，该应用程序实现 android.service.vr.VrListenerService，VR 应用程序可以通过 android.app.Activity#setVrModeEnabled 启用它。

7.9.2. 虚拟现实高性能

Android 手持设备实现必须通过 android.hardware.vr.high_performance 功能标志来标识对长时间用户使用的高性能虚拟现实的支持，并满足以下要求。

• 设备实现必须至少有 2 个物理核心。
• 设备实现必须声明 android.software.vr.mode 功能。
• 设备实现可以为前台应用程序提供独占核心，并且可以支持 Process.getExclusiveCores API 以返回专用于顶部前台应用程序的 CPU 核心编号。如果支持独占核心，则该核心绝不能允许任何其他用户空间进程在其上运行（应用程序使用的设备驱动程序除外），但可以允许一些内核进程根据需要运行。
• 设备实现必须支持持续性能模式。
• 设备实现必须支持 OpenGL ES 3.2。
• 设备实现必须支持 Vulkan Hardware Level 0，并且应支持 Vulkan Hardware Level 1。
• 设备实现必须实现 EGL_KHR_mutable_render_buffer 和 EGL_ANDROID_front_buffer_auto_refresh、EGL_ANDROID_create_native_client_buffer、EGL_KHR_fence_sync 和 EGL_KHR_wait_sync，以便它们可以用于共享缓冲区模式，并在可用的 EGL 扩展列表中公开这些扩展。
• GPU 和显示器必须能够同步对共享前缓冲区的访问，以便在两个渲染上下文以 60fps 交替渲染 VR 内容时，显示时不会出现明显的撕裂伪影。
• 设备实现必须实现 EGL_IMG_context_priority，并在可用的 EGL 扩展列表中公开该扩展。
• 设备实现必须实现 GL_EXT_multisampled_render_to_texture、GL_OVR_multiview、GL_OVR_multiview2 和 GL_OVR_multiview_multisampled_render_to_texture，并在可用的 GL 扩展列表中公开这些扩展。
• 设备实现必须实现 EGL_EXT_protected_content 和 GL_EXT_protected_textures，以便它可以用于安全纹理视频播放，并在可用的 EGL 和 GL 扩展列表中公开这些扩展。
• 设备实现必须支持 H.264 解码，至少支持 3840x2160@30fps-40Mbps（相当于 4 个 1920x1080@30fps-10Mbps 或 2 个 1920x1080@60fps-20Mbps）。
• 设备实现必须支持 HEVC 和 VP9，必须能够解码至少 1920x1080@30fps-10Mbps，并且应能够解码 3840x2160@30fps-20Mbps（相当于 4 个 1920x1080@30fps-5Mbps）。
• 强烈建议设备实现支持 android.hardware.sensor.hifi_sensors 功能，并且必须满足 android.hardware.hifi_sensors 的陀螺仪、加速度计和磁力计相关要求。
• 设备实现必须支持 HardwarePropertiesManager.getDeviceTemperatures API，并返回准确的皮肤温度值。
• 设备实现必须具有嵌入式屏幕，并且其分辨率必须至少为 FullHD(1080p)，并且强烈建议为 QuadHD (1440p) 或更高。
• 显示屏的对角线尺寸必须在 4.7 英寸到 6 英寸之间。
• 显示屏在 VR 模式下必须至少以 60 Hz 的频率更新。
• 显示屏在灰阶到灰阶、白到黑和黑到白切换时间的延迟必须 ≤ 3 毫秒。
• 显示屏必须支持低余晖模式，余晖 ≤ 5 毫秒，余晖定义为像素发光的时间量。
• 设备实现必须支持蓝牙 4.2 和蓝牙 LE 数据长度扩展 第 7.4.3 节。

8. 性能和功耗

一些最低性能和功耗标准对于用户体验至关重要，并且会影响开发人员在开发应用程序时的基线假设。Android 手表设备应满足以下标准，其他类型的设备实现必须满足以下标准。

8.1. 用户体验一致性

设备实现必须通过确保应用程序和游戏的一致帧速率和响应时间来提供流畅的用户界面。设备实现必须满足以下要求

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

8.2. 文件 I/O 访问性能

设备实现必须确保内部存储文件访问性能在读取和写入操作方面的一致性。

• 顺序写入。设备实现必须确保使用 10MB 写入缓冲区，对 256MB 文件进行顺序写入性能至少为 5MB/秒。
• 随机写入。设备实现必须确保使用 4KB 写入缓冲区，对 256MB 文件进行随机写入性能至少为 0.5MB/秒。
• 顺序读取。设备实现必须确保使用 10MB 写入缓冲区，对 256MB 文件进行顺序读取性能至少为 15MB/秒。
• 随机读取。设备实现必须确保使用 4KB 写入缓冲区，对 256MB 文件进行随机读取性能至少为 3.5MB/秒。

8.3. 省电模式

Android 6.0 引入了应用待机和省电模式，以优化电池使用。所有从这些模式中豁免的应用都必须对最终用户可见。此外，这些省电模式的触发、维护、唤醒算法以及全局系统设置的使用不得偏离 Android 开源项目。

除了省电模式外，Android 设备实现可以实现高级配置和电源接口 (ACPI) 定义的 4 种睡眠电源状态中的任何一种或全部，但如果它实现了 S3 和 S4 电源状态，则只能在关闭设备物理部件的盖子时才能进入这些状态。

8.4. 功耗核算

更准确地核算和报告功耗为应用开发者提供了激励和工具，以优化应用的功耗模式。因此，设备实现

• 必须能够跟踪硬件组件的功耗，并将功耗归因于特定应用程序。具体来说，实现
  • 必须提供每个组件的功率配置文件，该文件定义了每个硬件组件的电流消耗值以及组件随时间推移造成的大致电池消耗，如 Android 开源项目站点中所述。
  • 必须以毫安时 (mAh) 为单位报告所有功耗值。
  • 如果无法将硬件组件功耗归因于应用程序，则应归因于硬件组件本身。
  • 必须报告每个进程 UID 的 CPU 功耗。Android 开源项目通过 uid_cputime 内核模块实现满足此要求。
• 必须通过 adb shell dumpsys batterystats shell 命令向应用开发者提供此功耗信息。
• 必须遵守 android.intent.action.POWER_USAGE_SUMMARY intent，并显示一个设置菜单，显示此功耗信息。

8.5. 持续性能

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

设备实现应支持持续性能模式，当通过 Window.setSustainedPerformanceMode() API 方法请求时，该模式可以为顶部前台应用程序长时间提供一致的性能水平。设备实现必须通过 PowerManager.isSustainedPerformanceModeSupported() API 方法准确报告对持续性能模式的支持。

具有两个或多个 CPU 核心的设备实现应提供至少一个独占核心，该核心可以由顶部前台应用程序保留。如果提供，则实现必须满足以下要求

• 实现必须通过 Process.getExclusiveCores() API 方法报告可以由顶部前台应用程序保留的独占核心的 ID 编号。
• 设备实现不得允许任何用户空间进程（应用程序使用的设备驱动程序除外）在独占核心上运行，但可以允许一些内核进程根据需要运行。

如果设备实现不支持独占核心，则必须通过 Process.getExclusiveCores() API 方法返回一个空列表。

9. 安全模式兼容性

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

9.1. 权限

设备实现必须支持 Android 开发者文档中定义的 Android 权限模型。具体而言，实现必须强制执行 SDK 文档中描述的每个权限；不得省略、更改或忽略任何权限。实现可以添加额外的权限，前提是新的权限 ID 字符串不在 android.* 命名空间中。

具有 protectionLevel 为 'PROTECTION_FLAG_PRIVILEGED' 的权限只能授予预加载在系统映像的允许列表特权路径（例如 AOSP 实现中的 system/priv-app 路径）中的应用。

保护级别为危险的权限是运行时权限。targetSdkVersion > 22 的应用程序会在运行时请求它们。设备实现

• 必须显示一个专用界面，供用户决定是否授予请求的运行时权限，并提供一个界面供用户管理运行时权限。
• 必须具有用户界面的唯一实现。
• 除非满足以下条件，否则不得向预安装的应用程序授予任何运行时权限
  • 在应用程序使用运行时权限之前，可以获得用户的同意
  • 运行时权限与预安装的应用程序设置为默认处理程序的 intent 模式相关联

9.2. UID 和进程隔离

设备实现必须支持 Android 应用程序沙盒模型，其中每个应用程序都作为唯一的 Unix 风格 UID 并在单独的进程中运行。设备实现必须支持以相同的 Linux 用户 ID 运行多个应用程序，前提是这些应用程序已正确签名和构建，如安全性和权限参考中所定义。

9.3. 文件系统权限

设备实现必须支持安全性和权限参考中定义的 Android 文件访问权限模型。

9.4. 备选执行环境

设备实现可以包含运行时环境，这些环境使用 Dalvik 可执行格式或本机代码以外的其他软件或技术来执行应用程序。但是，此类备用执行环境不得损害 Android 安全模型或已安装 Android 应用程序的安全性，如本节中所述。

备用运行时本身必须是 Android 应用程序，并遵守标准的 Android 安全模型，如第 9 节中的其他地方所述。

备用运行时不得被授予访问权限，以访问受 runtime 的 AndroidManifest.xml 文件中未通过 <uses-permission> 机制请求的权限保护的资源。

备用运行时不得允许应用程序使用受限于系统应用程序的 Android 权限保护的功能。

备用运行时必须遵守 Android 沙盒模型。具体而言，备用运行时

• 应通过 PackageManager 将应用安装到单独的 Android 沙箱（Linux 用户 ID 等）中。
• 可以提供由所有使用备用运行时的应用程序共享的单个 Android 沙箱。
• 使用备用运行时的已安装应用程序不得重用设备上安装的任何其他应用程序的沙箱，除非通过共享用户 ID 和签名证书的标准 Android 机制。
• 不得启动、授予或被授予访问权限以访问与其他 Android 应用程序相对应的沙箱。
• 不得以超级用户 (root) 或任何其他用户 ID 的任何特权启动、被授予或授予其他应用程序任何特权。

备用运行时的 .apk 文件可以包含在设备实现的系统映像中，但必须使用与用于签署设备实现中包含的其他应用程序的密钥不同的密钥进行签名。

安装应用程序时，备用运行时必须获得用户对应用程序使用的 Android 权限的同意。如果应用程序需要使用设备资源，而该资源具有相应的 Android 权限（例如相机、GPS 等），则备用运行时必须告知用户该应用程序将能够访问该资源。如果运行时环境未以这种方式记录应用程序功能，则运行时环境在安装任何使用该运行时的应用程序时，必须列出运行时本身持有的所有权限。

9.5. 多用户支持

Android 包括 对多用户的支持，并提供对完全用户隔离的支持。设备实现可以启用多用户，但启用后必须满足与 多用户支持相关的以下要求

• 启用多用户支持的 Android Automotive 设备实现必须包含访客帐户，该帐户允许车辆系统提供的所有功能，而无需用户登录。
• 未声明 android.hardware.telephony 功能标志的设备实现必须支持受限配置文件，该功能允许设备所有者管理其他用户及其在设备上的功能。借助受限配置文件，设备所有者可以快速为其他用户设置单独的工作环境，并能够更精细地管理这些环境中可用的应用程序中的限制。
• 相反，声明 android.hardware.telephony 功能标志的设备实现不得支持受限配置文件，而必须与 AOSP 对启用/禁用其他用户访问语音通话和短信的控件的实现保持一致。
• 对于每个用户，设备实现都必须实现与 Android 平台安全模型一致的安全模型，如 安全性和权限参考文档中的 API 中所定义。
• Android 设备上的每个用户实例都必须具有单独且隔离的外部存储目录。设备实现可以将多个用户的数据存储在同一卷或文件系统上。但是，设备实现必须确保给定用户拥有并代表其运行的应用程序无法列出、读取或写入任何其他用户拥有的数据。请注意，可移动介质（例如 SD 卡插槽）可能允许一个用户通过主机 PC 访问另一个用户的数据。因此，如果启用了多用户，则对于将可移动介质用于外部存储 API 的设备实现，必须加密 SD 卡的内容，并使用仅存储在只有系统才能访问的不可移动介质上的密钥。由于这将使主机 PC 无法读取介质，因此设备实现将需要切换到 MTP 或类似的系统，以便为主机 PC 提供对当前用户数据的访问权限。因此，如果设备实现使用 可移动介质作为主外部存储，则可以但不应启用多用户。

9.6. 高级短信警告

Android 包括支持警告用户任何外发的增值短信。增值短信是发送给运营商注册的服务的短信，可能会向用户收取费用。声明支持 android.hardware.telephony 的设备实现必须在向设备中 /data/misc/sms/codes.xml 文件中定义的正则表达式标识的号码发送短信之前警告用户。上游 Android 开源项目提供了一种满足此要求的实现。

9.7. 内核安全功能

Android 沙箱包括使用安全增强型 Linux (SELinux) 强制访问控制 (MAC) 系统、seccomp 沙箱和 Linux 内核中的其他安全功能的功能。SELinux 或 Android 框架下实现的任何其他安全功能

• 必须保持与现有应用程序的兼容性。
• 当检测到安全违规并成功阻止时，不得有可见的用户界面，但当发生未阻止的安全违规导致成功利用时，可以有可见的用户界面。
• 不应由用户或开发者配置。

如果向可以影响另一个应用程序的应用程序公开任何策略配置 API（例如设备管理 API），则该 API 不得允许破坏兼容性的配置。

设备必须实现 SELinux，或者，如果使用 Linux 以外的内核，则实现等效的强制访问控制系统。设备还必须满足以下要求，这些要求由上游 Android 开源项目中的参考实现满足。

设备实现

• 必须将 SELinux 设置为全局强制模式。
• 必须在强制模式下配置所有域。不允许使用宽松模式域，包括特定于设备/供应商的域。
• 不得修改、省略或替换上游 Android 开源项目 (AOSP) 中提供的 system/sepolicy 文件夹中存在的 neverallow 规则，并且策略必须使用所有存在的 neverallow 规则进行编译，包括 AOSP SELinux 域以及设备/供应商特定的域。
• 必须将媒体框架拆分为多个进程，以便可以更严格地授予每个进程的访问权限，如 Android 开源项目站点中所述。

设备实现应保留上游 Android 开源项目的 system/sepolicy 文件夹中提供的默认 SELinux 策略，并且仅针对其自己的设备特定配置进一步添加到此策略。设备实现必须与上游 Android 开源项目兼容。

设备必须实现内核应用程序沙箱机制，该机制允许使用来自多线程程序的可配置策略过滤系统调用。上游 Android 开源项目通过启用 seccomp-BPF 和线程组同步 (TSYNC) 来满足此要求，如 source.android.com 的内核配置部分中所述。

9.8. 隐私权

如果设备在系统中实现了捕获屏幕上显示的内容和/或录制设备上播放的音频流的功能，则每当启用此功能并主动捕获/录制时，都必须持续通知用户。

如果设备实现具有默认情况下通过代理服务器或 VPN 网关路由网络数据流量的机制（例如，预加载授予 android.permission.CONTROL_VPN 的 VPN 服务），则设备实现必须在启用该机制之前征求用户的同意，除非 VPN 是由设备策略控制器通过 DevicePolicyManager.setAlwaysOnVpnPackage() 启用的，在这种情况下，用户无需提供单独的同意，但必须仅被通知。

设备实现必须附带一个空的用户添加的证书颁发机构 (CA) 存储，并且必须预安装与上游 Android 开源项目中提供的系统信任 CA 存储相同的根证书。

当设备通过 VPN 路由或安装了用户根 CA 时，实现必须显示警告，指示网络流量可能会受到监控。

如果设备实现具有支持 USB 外围设备模式的 USB 端口，则必须显示用户界面，在允许通过 USB 端口访问共享存储的内容之前征求用户的同意。

9.9. 数据存储加密

如果设备实现支持第 9.11.1 节中描述的安全锁屏，则设备必须支持应用程序私有数据（/data 分区）以及应用程序共享存储分区（/sdcard 分区，如果它是设备的永久性、不可移动部件）的数据存储加密。

对于支持数据存储加密且高级加密标准 (AES) 加密性能高于 50MiB/秒的设备实现，数据存储加密必须在用户完成开箱即用设置体验时默认启用。如果设备实现已在早期 Android 版本上启动，并且默认情况下禁用加密，则此类设备无法通过系统软件更新满足要求，因此可以获得豁免。

设备实现应通过实现 基于文件的加密 (FBE) 来满足上述数据存储加密要求。

9.9.1. 直接启动

所有设备都必须实现 直接启动模式 API，即使它们不支持存储加密。特别是，LOCKED_BOOT_COMPLETED 和 ACTION_USER_UNLOCKED Intent 仍然必须广播，以向直接启动感知应用程序发出信号，表明设备加密 (DE) 和凭据加密 (CE) 存储位置可供用户使用。

9.9.2. 基于文件的加密

支持 FBE 的设备实现

• 必须在不提示用户输入凭据的情况下启动，并允许直接启动感知应用程序在广播 LOCKED_BOOT_COMPLETED 消息后访问设备加密 (DE) 存储。
• 只有在用户通过提供其凭据（例如密码、PIN 码、图案或指纹）解锁设备并广播 ACTION_USER_UNLOCKED 消息后，才必须允许访问凭据加密 (CE) 存储。设备实现不得提供任何在没有用户提供凭据的情况下解锁 CE 保护存储的方法。
• 必须支持经过验证的启动，并确保 DE 密钥以加密方式绑定到设备的硬件信任根。
• 必须支持使用 AES 和 256 位密钥长度以 XTS 模式加密文件内容。
• 必须支持使用 AES 和 256 位密钥长度以 CBC-CTS 模式加密文件名。
• 可以支持用于文件内容和文件名加密的替代密码、密钥长度和模式，但默认情况下必须使用强制支持的密码、密钥长度和模式。
• 应使预加载的基本应用程序（例如闹钟、电话、消息程序）具有直接启动感知能力。

保护 CE 和 DE 存储区域的密钥

• 必须以加密方式绑定到硬件支持的密钥库。CE 密钥必须绑定到用户的锁屏凭据。如果用户未指定锁屏凭据，则 CE 密钥必须绑定到默认密码。
• 必须是唯一且不同的，换句话说，任何用户的 CE 或 DE 密钥都不得与任何其他用户的 CE 或 DE 密钥匹配。

上游 Android 开源项目基于 Linux 内核 ext4 加密功能提供了此功能的首选实现。

9.9.3. 全盘加密

支持全盘加密 (FDE) 的设备实现。必须使用密钥为 128 位（或更大）的 AES 和专为存储设计的模式（例如，AES-XTS、AES-CBC-ESSIV）。加密密钥在任何时候都不得在未加密的情况下写入存储。必须为用户提供使用 AES 加密加密密钥的可能性，除非在密钥处于活动使用状态时，使用慢速拉伸算法（例如 PBKDF2 或 scrypt）拉伸锁屏凭据。如果用户未指定锁屏凭据或已禁用密码用于加密，则系统应使用默认密码来包装加密密钥。如果设备提供硬件支持的密钥库，则密码拉伸算法必须以加密方式绑定到该密钥库。加密密钥不得发送到设备外（即使使用用户密码和/或硬件绑定密钥包装）。上游 Android 开源项目基于 Linux 内核功能 dm-crypt 提供了此功能的首选实现。

9.10. 设备完整性

以下要求确保设备完整性状态的透明度。

设备实现必须通过 System API 方法 PersistentDataBlockManager.getFlashLockState() 正确报告其引导加载程序状态是否允许刷写系统映像。FLASH_LOCK_UNKNOWN 状态保留用于从早期版本的 Android 升级的设备实现，在早期版本的 Android 中，此新的系统 API 方法不存在。

经过验证的启动是一项保证设备软件完整性的功能。如果设备实现支持此功能，则必须

• 声明平台功能标志 android.software.verified_boot。
• 在每个启动序列上执行验证。
• 从不可变的硬件密钥（信任根）开始验证，一直到系统分区。
• 实施每个验证阶段，以在执行下一阶段的代码之前，检查下一阶段中所有字节的完整性和真实性。
• 验证算法的强度必须与 NIST 当前关于哈希算法 (SHA-256) 和公钥大小 (RSA-2048) 的建议相同。
• 当系统验证失败时，必须不允许启动完成，除非用户同意尝试继续启动，在这种情况下，任何未验证的存储块中的数据都不得使用。
• 除非用户已明确解锁引导加载程序，否则不得允许修改设备上已验证的分区。

上游 Android 开源项目基于 Linux 内核功能 dm-verity 提供了此功能的首选实现。

从 Android 6.0 开始，高级加密标准 (AES) 加密性能高于 50 MiB/秒的设备实现必须支持已验证启动以确保设备完整性。

如果设备实现已在早期版本的 Android 上启动且未支持已验证启动，则此类设备无法通过系统软件更新添加对此功能的支持，因此可以免除此要求。

9.11. 密钥和凭据

Android Keystore 系统允许应用程序开发者将加密密钥存储在容器中，并通过 KeyChain API 或 Keystore API 在加密操作中使用它们。

所有 Android 设备实现都必须满足以下要求

• 不应限制可以生成的密钥数量，并且必须至少允许导入超过 8,192 个密钥。
• 锁屏身份验证必须限制尝试次数，并且必须具有指数退避算法。超过 150 次失败尝试后，每次尝试的延迟必须至少为 24 小时。
• 当设备实现支持安全锁屏时，它必须使用安全硬件备份密钥库实现，并满足以下要求
  • 必须实现 RSA、AES、ECDSA 和 HMAC 加密算法以及 MD5、SHA1 和 SHA-2 系列哈希函数，以便在安全隔离于内核及以上代码运行区域的环境中，正确支持 Android Keystore 系统支持的算法。安全隔离必须阻止内核或用户空间代码可能访问隔离环境内部状态的所有潜在机制，包括 DMA。上游 Android 开源项目 (AOSP) 通过使用 Trusty 实现来满足此要求，但另一个基于 ARM TrustZone 的解决方案或经过第三方审查的基于适当虚拟机监控程序的隔离的安全实现也是替代方案。
  • 必须在隔离的执行环境中执行锁屏身份验证，并且只有在成功时，才允许使用身份验证绑定的密钥。上游 Android 开源项目提供了 Gatekeeper 硬件抽象层 (HAL) 和 Trusty，可用于满足此要求。

请注意，如果设备实现已在早期版本的 Android 上启动，则此类设备可以免除拥有硬件支持的密钥库的要求，除非它声明了 android.hardware.fingerprint 功能，该功能需要硬件支持的密钥库。

9.11.1. 安全锁屏

设备实现可以添加或修改用于解锁锁屏的身份验证方法，但仍必须满足以下要求

• 如果身份验证方法基于已知密钥，则除非满足以下所有要求，否则不得将其视为安全锁屏
  • 最短允许输入长度的熵必须大于 10 位。
  • 所有可能输入的最大熵必须大于 18 位。
  • 不得替换 AOSP 中已实现和提供的任何现有身份验证方法（PIN 码、图案、密码）。
  • 当设备策略控制器 (DPC) 应用程序通过 DevicePolicyManager.setPasswordQuality() 方法设置了比 PASSWORD_QUALITY_SOMETHING 更严格的质量常量时，必须禁用此方法。
• 如果身份验证方法基于物理令牌或位置，则除非满足以下所有要求，否则不得将其视为安全锁屏
  • 它必须具有使用基于已知密钥的主要身份验证方法之一的回退机制，并且该方法满足被视为安全锁屏的要求。
  • 当设备策略控制器 (DPC) 应用程序通过 DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_TRUST_AGENTS) 方法或 DevicePolicyManager.setPasswordQuality() 方法设置了比 PASSWORD_QUALITY_UNSPECIFIED 更严格的质量常量时，必须禁用此方法，并且仅允许主要身份验证解锁屏幕。
• 如果身份验证方法基于生物识别技术，则除非满足以下所有要求，否则不得将其视为安全锁屏
  • 它必须具有使用基于已知密钥的主要身份验证方法之一的回退机制，并且该方法满足被视为安全锁屏的要求。
  • 当设备策略控制器 (DPC) 应用程序通过调用方法 DevicePolicyManager.setKeyguardDisabledFeatures(KEYGUARD_DISABLE_FINGERPRINT) 设置了锁屏保护功能策略时，必须禁用此方法，并且仅允许主要身份验证解锁屏幕。
  • 它的错误接受率必须等于或强于第 7.3.10 节中描述的指纹传感器所需的要求，否则当设备策略控制器 (DPC) 应用程序通过 DevicePolicyManager.setPasswordQuality() 方法设置了比 PASSWORD_QUALITY_BIOMETRIC_WEAK 更严格的质量常量时，必须禁用此方法，并且仅允许主要身份验证解锁屏幕。
• 如果身份验证方法不能被视为安全锁屏，则它
  • 对于 KeyguardManager.isKeyguardSecure() 和 KeyguardManager.isDeviceSecure() 方法都必须返回 false。
  • 当设备策略控制器 (DPC) 应用程序通过 DevicePolicyManager.setPasswordQuality() 方法设置了比 PASSWORD_QUALITY_UNSPECIFIED 更严格的质量常量时，必须禁用此方法。
  • 不得重置由 DevicePolicyManager.setPasswordExpirationTimeout() 设置的密码过期计时器。
  • 如果应用程序已调用 KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true) )，则不得验证对密钥库的访问。
• 如果身份验证方法基于物理令牌、位置或生物识别技术，并且其错误接受率高于第 7.3.10 节中描述的指纹传感器所需的要求，则它
  • 不得重置由 DevicePolicyManager.setPasswordExpirationTimeout() 设置的密码过期计时器。
  • 如果应用程序已调用 KeyGenParameterSpec.Builder.setUserAuthenticationRequired(true) )，则不得验证对密钥库的访问。

9.12. 数据删除

设备必须为用户提供一种执行“恢复出厂设置”的机制，该机制允许逻辑和物理删除所有数据，但以下内容除外

• 系统镜像
• 系统镜像所需的任何操作系统文件

所有用户生成的数据都必须删除。这必须满足数据删除的相关行业标准，例如 NIST SP800-88。这必须用于实现 第 3.9 节设备管理 中描述的 wipeData() API（Android 设备管理 API 的一部分）。

设备可以提供执行逻辑数据擦除的快速数据擦除功能。

9.13. 安全启动模式

Android 提供了一种模式，使用户可以启动进入仅允许预装系统应用程序运行且禁用所有第三方应用程序的模式。此模式称为“安全启动模式”，为用户提供了卸载可能有害的第三方应用程序的功能。

强烈建议 Android 设备实现实现安全启动模式并满足以下要求

• 设备实现应为用户提供从启动菜单进入安全启动模式的选项，该启动菜单可通过与正常启动不同的工作流程访问。

• 设备实现必须以以下方式为用户提供进入安全启动模式的选项：除非第三方应用程序是设备策略控制器并且已将 UserManager.DISALLOW_SAFE_BOOT 标志设置为 true，否则不得被设备上安装的第三方应用程序中断。

• 设备实现必须为用户提供在安全模式下卸载任何第三方应用程序的功能。

9.14. 汽车车辆系统隔离

Android Automotive 设备预计会与关键车辆子系统交换数据，例如，通过使用 vehicle HAL 在车辆网络（如 CAN 总线）上发送和接收消息。Android Automotive 设备实现必须在 Android 框架层以下实现安全功能，以防止 Android 框架或第三方应用程序与车辆子系统之间发生恶意或意外的交互。这些安全功能如下

• 门控来自 Android 框架车辆子系统的消息，例如，允许列出允许的消息类型和消息来源。
• 针对来自 Android 框架或第三方应用程序的拒绝服务攻击的看门狗。这可以防止恶意软件用流量淹没车辆网络，这可能导致车辆子系统发生故障。

10. 软件兼容性测试

设备实现必须通过本节中描述的所有测试。

但是，请注意，没有软件测试包是完全全面的。因此，强烈建议设备实现者尽可能少地更改 Android 开源项目提供的 Android 参考实现和首选实现。这将最大限度地降低引入错误（导致不兼容性，需要返工和潜在的设备更新）的风险。

10.1. 兼容性测试套件

设备实现必须使用设备上的最终交付软件通过来自 Android 开源项目的 Android 兼容性测试套件 (CTS)。此外，设备实现者应尽可能多地使用 Android 开源树中的参考实现，并且必须确保在 CTS 中存在歧义的情况下以及对于参考源代码任何重新实现的部分的兼容性。

CTS 旨在在实际设备上运行。与任何软件一样，CTS 本身可能包含错误。CTS 的版本将独立于此兼容性定义进行版本控制，并且可能会为 Android 7.1 发布 CTS 的多个修订版。设备实现必须通过设备软件完成时可用的最新 CTS 版本。

10.2. CTS 验证程序

设备实现必须正确执行 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. 文档更改日志

有关此版本中兼容性定义的更改摘要

• 文档变更日志

有关各个章节的更改摘要

1. 简介
2. 设备类型
3. 软件
4. 应用程序打包
5. 多媒体
6. 开发者工具和选项
7. 硬件兼容性
8. 性能和功耗
9. 安全模型
10. 软件兼容性测试
11. 可更新软件
12. 文档变更日志
13. 联系我们

12.1. 更改日志查看提示

更改标记如下

• CDD
  对兼容性要求的实质性更改。

• 文档
  外观或构建相关的更改。

为了获得最佳观看效果，请将 pretty=full 和 no-merges URL 参数附加到您的变更日志 URL。

13. 联系我们

您可以加入 android-compatibility 论坛，并要求澄清或提出您认为文档未涵盖的任何问题。