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

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

1. 简介

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

“必须 (MUST)”、“禁止 (MUST NOT)”、“必需 (REQUIRED)”、“应 (SHALL)”、“不应 (SHALL NOT)”、“应该 (SHOULD)”、“不应该 (SHOULD NOT)”、“建议 (RECOMMENDED)”、“可以 (MAY)”和“可选 (OPTIONAL)”等术语的用法均符合 IETF 标准，该标准在 RFC2119 [资源 1] 中定义。

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

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

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

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

第 14 节中列出的许多资源直接或间接派生自 Android SDK，并且在功能上与该 SDK 文档中的信息相同。如果本兼容性定义或兼容性测试套件与 SDK 文档不一致，则以 SDK 文档为准。包含在第 14 节中的参考文献中提供的任何技术细节，都通过包含被视为本兼容性定义的一部分。

2. 设备类型

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

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

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

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

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

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

必须具有物理对角线长度在 1.1 到 2.5 英寸范围内的屏幕。
必须声明功能 android.hardware.type.watch。
必须支持 uiMode = UI_MODE_TYPE_WATCH [资源 4]。

Android 汽车实现是指将 Android 用作部分或全部系统和/或信息娱乐功能的车辆主机。Android 汽车实现必须支持 uiMode = UI_MODE_TYPE_CAR [资源 111]。

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

2.1 设备配置

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

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

3. 软件

3.1. 托管 API 兼容性

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

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

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

3.2. 软 API 兼容性

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

3.2.1. 权限

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

3.2.2. 构建参数

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

参数	详细信息
VERSION.RELEASE	当前正在运行的 Android 系统的版本，采用人类可读的格式。此字段必须具有 [资源 8] 中定义的字符串值之一。
VERSION.SDK	当前正在运行的 Android 系统的版本，采用第三方应用程序代码可访问的格式。对于 Android 5.1，此字段必须具有整数值 22。
VERSION.SDK_INT	当前正在运行的 Android 系统的版本，采用第三方应用程序代码可访问的格式。对于 Android 5.1，此字段必须具有整数值 22。
VERSION.INCREMENTAL	设备实现方选择的值，用于指定当前正在运行的 Android 系统的特定版本，采用人类可读的格式。此值不得重复用于向最终用户提供的不同版本。此字段的典型用途是指示用于生成版本的版本号或源代码控制更改标识符。对此字段的具体格式没有要求，但它不得为 null 或空字符串 ("")。
BOARD	设备实现方选择的值，用于标识设备使用的特定内部硬件，采用人类可读的格式。此字段的可能用途是指示设备供电的主板的特定修订版本。此字段的值必须编码为 7 位 ASCII 码，并与正则表达式“^[a-zA-Z0-9_-]+$”匹配。
BRAND	反映最终用户所知的与设备关联的品牌名称的值。必须采用人类可读的格式，并且应代表设备的制造商或设备销售的品牌公司。此字段的值必须编码为 7 位 ASCII 码，并与正则表达式“^[a-zA-Z0-9_-]+$”匹配。
SUPPORTED_ABIS	原生代码的指令集（CPU 类型 + ABI 约定）的名称。请参阅第 3.3 节：原生 API 兼容性。
SUPPORTED_32_BIT_ABIS	原生代码的指令集（CPU 类型 + ABI 约定）的名称。请参阅第 3.3 节：原生 API 兼容性。
SUPPORTED_64_BIT_ABIS	第二指令集（CPU 类型 + ABI 约定）的名称。请参阅第 3.3 节：原生 API 兼容性。
CPU_ABI	原生代码的指令集（CPU 类型 + ABI 约定）的名称。请参阅第 3.3 节：原生 API 兼容性。
CPU_ABI2	第二指令集（CPU 类型 + ABI 约定）的名称。请参阅第 3.3 节：原生 API 兼容性。
DEVICE	设备实现方选择的值，其中包含开发名称或代号，用于标识设备的硬件功能和工业设计的配置。此字段的值必须编码为 7 位 ASCII 码，并与正则表达式“^[a-zA-Z0-9_-]+$”匹配。
FINGERPRINT	唯一标识此版本的字符串。它应该是相当人类可读的。它必须遵循此模板 $(BRAND)/$(PRODUCT)/$(DEVICE):$(VERSION.RELEASE)/$(ID)/$(VERSION.INCREMENTAL):$(TYPE)/$(TAGS) 例如：acme/myproduct/mydevice:5.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	硬件序列号，必须可用。此字段的值必须编码为 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 或空字符串 ("")。

3.2.3. Intent 兼容性

设备实现必须遵循 Android 的松耦合 Intent 系统，如下节所述。“遵循”是指设备实现方必须提供一个 Android Activity 或 Service，该 Activity 或 Service 指定一个匹配的 Intent 过滤器，该过滤器绑定到每个指定的 Intent 模式并为其实现正确的行为。

3.2.3.1. 核心应用 Intent

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

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

设备实现应该酌情包含核心 Android 应用，但必须包含一个组件，该组件实现这些核心 Android 应用的所有“公共”Activity 或 Service 组件定义的相同 Intent 模式。请注意，当属性 android:exported 缺失或值为 true 时，Activity 或 Service 组件被视为“公共”。

3.2.3.2. Intent 替换

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

但是，如果默认 Activity 为数据 URI 提供更具体的过滤器，则设备实现可以为特定的 URI 模式（例如 http://play.google.com）提供默认 Activity。例如，指定数据 URI “http://www.android.com”的 Intent 过滤器比用于“http://”的浏览器过滤器更具体。设备实现必须为用户提供一个用户界面，以便用户修改 Intent 的默认 Activity。

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 [资源 10]，则必须遵循 android.settings.HOME_SETTINGS Intent 以显示主屏幕的默认应用设置菜单
如果设备实现报告 android.hardware.telephony [资源 9]，则必须提供一个设置菜单，该菜单将调用 android.provider.Telephony.ACTION_CHANGE_DEFAULT Intent 以显示一个用于更改默认短信应用的对话框
如果设备实现报告 android.hardware.nfc.hce [资源 10]，则必须遵循 android.settings.NFC_PAYMENT_SETTINGS Intent 以显示“点击支付”的默认应用设置菜单

3.3. 原生 API 兼容性

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（docs/ 目录中的“NDK Programmer’s Guide | ABI Management”）中记录的 ABI
应使用上游 Android 开源项目中提供的源代码和头文件进行构建

以下原生代码 API 必须可供包含原生代码的应用使用

libc（C 库）
libm（数学库）
对 C++ 的最低限度支持
JNI 接口
liblog（Android 日志记录）
libz（Zlib 压缩）
libdl（动态链接器）
libGLESv1_CM.so (OpenGL ES 1.x)
libGLESv2.so (OpenGL ES 2.0)
libGLESv3.so (OpenGL ES 3.x)
libEGL.so（原生 OpenGL 曲面管理）
libjnigraphics.so
libOpenSLES.so (OpenSL ES 1.0.1 音频支持)
libOpenMAXAL.so (OpenMAX AL 1.0.1 支持)
libandroid.so（原生 Android Activity 支持）
libmediandk.so（原生媒体 API 支持）
对 OpenGL 的支持，如下所述

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

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

原生代码兼容性具有挑战性。因此，强烈建议设备实现方使用上游 Android 开源项目中的上述库的实现。

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

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 时，设备必须包含以下行

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

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

3.4. Web 兼容性

3.4.1. WebView 兼容性

Android Watch 设备可以（MAY），但所有其他设备实现必须（MUST）提供 android.webkit.Webview API 的完整实现。

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

设备 android.webkit.WebView 实现必须基于 Android 5.1 的上游 Android 开源项目中的 Chromium 构建版本。此构建版本包含 WebView 的一组特定功能和安全修复程序 [资源 13]。
WebView 报告的用户代理字符串必须采用以下格式
Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD)$(WEBVIEW)) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 $(CHROMIUM_VER) Mobile Safari/537.36
- $(VERSION) 字符串的值必须与 android.os.Build.VERSION.RELEASE 的值相同。
- $(WEBVIEW) 字符串可以省略，但如果包含，则必须为“; wv”以注明这是一个 webview
- $(MODEL) 字符串的值必须与 android.os.Build.MODEL 的值相同。
- $(BUILD) 字符串的值必须与 android.os.Build.ID 的值相同。
- $(CHROMIUM_VER) 字符串的值必须是上游 Android 开源项目中的 Chromium 版本。
- 设备实现可以（MAY）在用户代理字符串中省略 Mobile。

WebView 组件应尽可能多地支持 HTML5 功能，如果支持该功能，则应符合 HTML5 规范 [资源 14]。

3.4.2. 浏览器兼容性

Android Television、Watch 和 Android Automotive 实现可以（MAY）省略浏览器应用程序，但必须（MUST）支持第 3.2.3.1 节中描述的公共 Intent 模式。所有其他类型的设备实现必须（MUST）包含一个独立的浏览器应用程序，用于常规用户 Web 浏览。

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

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

独立的浏览器应用程序（无论是基于上游 WebKit 浏览器应用程序还是第三方替代品）都应（SHOULD）尽可能多地支持 HTML5 [资源 14]。至少，设备实现必须（MUST）支持与 HTML5 相关的以下每个 API

应用程序缓存/离线操作 [资源 15]
<video> 标签 [资源 16]
地理位置 [资源 17]

此外，设备实现必须（MUST）支持 HTML5/W3C webstorage API [资源 18]，并且应（SHOULD）支持 HTML5/W3C IndexedDB API [资源 19]。请注意，由于 Web 开发标准机构正在转向倾向于 IndexedDB 而不是 webstorage，因此 IndexedDB 预计将在未来版本的 Android 中成为必需组件。

3.5. API 行为兼容性

每种 API 类型（托管、软件、原生和 Web）的行为必须与上游 Android 开源项目的首选实现保持一致 [资源 2]。一些具体的兼容性领域包括

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

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

3.6. API 命名空间

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

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

禁止的修改包括:

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

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

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

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

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

3.7. 运行时兼容性

设备实现必须（MUST）支持完整的 Dalvik Executable (DEX) 格式和 Dalvik 字节码规范和语义 [资源 20]。设备实现者应（SHOULD）使用 ART，Dalvik Executable Format 的参考上游实现，以及参考实现的包管理系统。

设备实现必须（MUST）按照上游 Android 平台配置 Dalvik 运行时以分配内存，并按照下表指定。（有关屏幕尺寸和屏幕密度定义，请参阅第 7.1.1 节。）

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

屏幕布局	屏幕密度	最小应用程序内存
小/普通	120 dpi (ldpi)	32MB
	160 dpi (mdpi)	32MB
	213 dpi (tvdpi)	48MB
	240 dpi (hdpi)
	280 dpi (280dpi)
	320 dpi (xhdpi)	80MB
	400 dpi (400dpi)	96MB
	480 dpi (xxhdpi)	128MB
	560 dpi (560dpi)	192MB
	640 dpi (xxxhdpi)	256MB
大	120 dpi (ldpi)	32MB
	160 dpi (mdpi)	48MB
	213 dpi (tvdpi)	80MB
	240 dpi (hdpi)	80MB
	280 dpi (280dpi)	96MB
	320 dpi (xhdpi)	128MB
	400 dpi (400dpi)	192MB
	480 dpi (xxhdpi)	256MB
	560 dpi (560dpi)	384MB
	640 dpi (xxxhdpi)	512MB
超大	120 dpi (ldpi)	48MB
	160 dpi (mdpi)	80MB
	213 dpi (tvdpi)	96MB
	240 dpi (hdpi)	96MB
	280 dpi (280dpi)	144MB
	320 dpi (xhdpi)	192MB
	400 dpi (400dpi)	288MB
	480 dpi (xxhdpi)	384MB
	560 dpi (560dpi)	576MB
	640 dpi (xxxhdpi)	768MB

3.8. 用户界面兼容性

3.8.1. 启动器（主屏幕）

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

3.8.2. Widget

小部件对于所有 Android 设备实现都是可选的，但应（SHOULD）在 Android 手持设备上支持。

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

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

3.8.3. 通知

Android 包括允许开发者通知用户重要事件的 API [资源 22]，使用设备的硬件和软件功能。

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

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

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

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

当这些通知可见时，Android 设备实现必须（MUST）正确执行富通知和浮动通知，并包含 Android API [资源 25] 中记录的标题/名称、图标、文本。

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

3.8.4. 搜索

Android 包括 API [资源 26]，允许开发者将搜索功能集成到他们的应用程序中，并将他们应用程序的数据暴露到全局系统搜索中。一般来说，此功能由一个单一的、系统范围的用户界面组成，允许用户输入查询，在用户键入时显示建议，并显示结果。Android API 允许开发者重用此界面以在他们自己的应用程序中提供搜索功能，并允许开发者向公共全局搜索用户界面提供结果。

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

3.8.5. Toast

应用程序可以使用“Toast”API 向最终用户显示简短的非模态字符串，这些字符串会在短暂的时间后消失 [资源 27]。设备实现必须（MUST）以某种高可见性的方式向最终用户显示来自应用程序的 Toast。

3.8.6. 主题

Android 提供“主题”作为应用程序跨整个 Activity 或应用程序应用样式的机制。

Android 包括“Holo”主题系列，作为一组定义的样式，供应用程序开发者使用，如果他们想要匹配 Android SDK [资源 28] 定义的 Holo 主题外观和感觉。设备实现不得（MUST NOT）更改暴露给应用程序的任何 Holo 主题属性 [资源 29]。

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

Android 还包括“Device Default”主题系列，作为一组定义的样式，供应用程序开发者使用，如果他们想要匹配设备实现者定义的设备主题的外观和感觉。设备实现可以（MAY）修改暴露给应用程序的 Device Default 主题属性 [资源 29]。

Android 支持带有半透明系统栏的新变体主题，允许应用程序开发者用他们的应用程序内容填充状态栏和导航栏后面的区域。为了在这种配置中实现一致的开发者体验，保持不同设备实现中的状态栏图标样式非常重要。因此，Android 设备实现必须（MUST）对系统状态图标（例如信号强度和电池电量）以及系统发出的通知使用白色，除非该图标指示有问题状态 [资源 29]。

3.8.7. 动态壁纸

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

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

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

3.8.8. Activity 切换

由于最近使用的功能导航键是可选的（OPTIONAL），因此对于 Android Television 设备和 Android Watch 设备，实现概览屏幕的要求是可选的（OPTIONAL）。

上游 Android 源代码包括概览屏幕 [资源 32]，这是一个系统级用户界面，用于任务切换和显示最近访问的活动和任务，使用用户上次离开应用程序时应用程序图形状态的缩略图图像。包含第 7.2.3 节中详述的最近使用功能导航键的设备实现可以（MAY）更改界面，但必须（MUST）满足以下要求

必须（MUST）将关联的最近使用项显示为一个一起移动的组。
必须（MUST）支持至少最多 20 个显示的活动。
应（SHOULD）至少一次显示 4 个活动的标题。
应（SHOULD）在最近使用项中显示高亮颜色、图标、屏幕标题。
必须（MUST）实现屏幕固定行为 [资源 33]，并为用户提供一个设置菜单来切换该功能。
应（SHOULD）显示关闭功能 (“x”)，但可以（MAY）延迟到用户与屏幕交互时再显示。

强烈鼓励（STRONGLY ENCOURAGED）设备实现对概览屏幕使用上游 Android 用户界面（或类似的基于缩略图的界面）。

3.8.9. 输入管理

Android 包括对输入管理和第三方输入法编辑器的支持 [资源 34]。允许用户在设备上使用第三方输入法的设备实现必须（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，它允许媒体应用程序与锁屏上显示的播放控件集成 [资源 35]。除非是 Android Automotive 或 Watch 实现，否则支持锁屏的设备实现必须（MUST）显示锁屏通知，包括 Media Notification Template。

3.8.11. 互动屏保

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

3.8.12. 位置信息

当设备具有能够提供位置坐标的硬件传感器（例如 GPS）时，必须（MUST）在“设置”中的“位置”菜单中显示位置模式 [资源 37]。

3.8.13. Unicode 和字体

Android 包括对彩色表情符号字符的支持。当 Android 设备实现包含 IME 时，设备应（SHOULD）为用户提供一种输入法，用于输入 Unicode 6.1 中定义的表情符号字符 [资源 38]。所有设备都必须（MUST）能够以彩色字形渲染这些表情符号字符。

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 的拉丁文、希腊文和西里尔文，包括 Latin Extended A、B、C 和 D 范围，以及 Unicode 7.0 货币符号块中的所有字形。

3.9. 设备管理

Android 包括一些功能，允许具有安全意识的应用程序在系统级别执行设备管理功能，例如强制密码策略或执行远程擦除，通过 Android 设备管理 API [资源 39]。设备实现必须（MUST）提供 DevicePolicyManager 类 [资源 40] 的实现。包含对基于 PIN (数字) 或 PASSWORD (字母数字) 的锁屏支持的设备实现必须（MUST）支持 Android SDK 文档 [资源 39] 中定义的全部设备管理策略，并报告平台功能 android.software.device_admin。

设备实现可以（MAY）拥有一个预安装的应用程序来执行设备管理功能，但此应用程序不得（MUST NOT）在开箱即用时设置为默认设备所有者应用程序 [资源 41]。

3.10. 无障碍功能

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

设备实现包括以下要求

Android Automotive 实现应（SHOULD）提供与默认 Android 实现一致的 Android 辅助功能框架的实现。
设备实现（Android Automotive 除外）必须（MUST）提供与默认 Android 实现一致的 Android 辅助功能框架的实现。
设备实现（Android Automotive 除外）必须（MUST）通过 android.accessibilityservice API [资源 43] 支持第三方辅助功能服务实现
设备实现（Android Automotive 除外）必须（MUST）生成 AccessibilityEvents 并以与默认 Android 实现一致的方式将这些事件传递给所有已注册的 AccessibilityService 实现
设备实现（Android Automotive 和没有音频输出的 Android Watch 设备除外）必须（MUST）提供用户可访问的机制来启用和禁用辅助功能服务，并且必须（MUST）响应 android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS Intent 显示此界面。

此外，设备实现应（SHOULD）在设备上提供辅助功能服务的实现，并应（SHOULD）为用户提供在设备设置期间启用辅助功能服务的机制。辅助功能服务的开源实现可从 Eyes Free 项目获得 [资源 44]。

3.11. 文本转语音

Android 包括允许应用程序使用文本转语音 (TTS) 服务的 API，并允许服务提供商提供 TTS 服务的实现 [资源 45]。报告功能 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 Television Input Framework (TIF) 简化了向 Android Television 设备交付直播内容的过程。TIF 提供了一个标准 API 来创建控制 Android Television 设备的输入模块。Android Television 设备实现必须（MUST）支持 Television Input Framework [资源 46]。

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

4. 应用软件包兼容性

设备实现必须（MUST）安装和运行由官方 Android SDK 中包含的 “aapt” 工具生成的 Android “.apk” 文件 [资源 47]。

设备实现不得（MUST NOT）扩展 .apk [资源 48]、Android Manifest [资源 49]、Dalvik 字节码 [资源 20] 或 RenderScript 字节码格式，以防止这些文件在其他兼容设备上正确安装和运行。

5. 多媒体兼容性

5.1. 媒体编解码器

设备实现必须（MUST）支持 Android SDK 文档 [资源 50] 中指定的核心媒体格式，除非本文档明确允许。具体来说，设备实现必须（MUST）支持下表定义并通过 MediaCodecList [资源 112] 报告的媒体格式、编码器、解码器、文件类型和容器格式。设备实现还必须（MUST）能够解码其 CamcorderProfile [资源 113] 中报告的所有配置文件。所有这些编解码器都在 Android 开源项目中首选的 Android 实现中作为软件实现提供。

请注意，Google 和 Open Handset Alliance 均未表示这些编解码器不受第三方专利的约束。那些打算在硬件或软件产品中使用此源代码的人员应注意，此代码的实现，包括在开源软件或共享软件中，可能需要获得相关专利持有人的专利许可。

5.1.1. 音频编解码器

格式/编解码器	编码器	解码器	详细信息	支持的文件类型/容器格式
MPEG-4 AAC Profile (AAC LC)	必需¹	必需	支持单声道/立体声/5.0/5.1² 内容，标准采样率从 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 Profile (AAC+)	必需¹ (Android 4.1+)	必需	支持单声道/立体声/5.0/5.1² 内容，标准采样率从 16 到 48 kHz。
MPEG-4 HE AACv2 Profile (增强型 AAC+)		必需	支持单声道/立体声/5.0/5.1² 内容，标准采样率从 16 到 48 kHz。
AAC ELD (增强型低延迟 AAC)	必需¹ (Android 4.1+)	必需 (Android 4.1+)	支持单声道/立体声内容，标准采样率从 16 到 48 kHz。
AMR-NB	必需³	必需³	4.75 至 12.2 kbps，以 8kHz 采样	3GPP (.3gp)
AMR-WB	必需³	必需³	9 种速率，从 6.60 kbit/s 到 23.85 kbit/s，以 16kHz 采样
FLAC		必需 (Android 3.1+)	单声道/立体声（无多声道）。采样率高达 48 kHz（但在具有 44.1 kHz 输出的设备上建议高达 44.1 kHz，因为 48 到 44.1 kHz 降采样器不包括低通滤波器）。建议使用 16 位；24 位不应用抖动。	仅限 FLAC (.flac)
MP3		必需	单声道/立体声 8-320Kbps 恒定比特率 (CBR) 或可变比特率 (VBR)	MP3 (.mp3)
MIDI		必需	MIDI 类型 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		必需		Ogg (.ogg) Matroska (.mkv, Android 4.0+)
PCM/WAVE	必需⁴ (Android 4.1+)	必需	16 位线性 PCM（速率高达硬件限制）。设备必须（MUST）支持原始 PCM 录音的采样率，频率为 8000、11025、16000 和 44100 Hz。	WAVE (.wav)
Opus		必需 (Android 5.0+)		Matroska (.mkv)

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

² 仅需要 5.0/5.1 内容的混音；录制或渲染超过 2 个声道是可选的。

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

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

5.1.2. 图像编解码器

格式/编解码器	编码器	解码器	详细信息	支持的文件类型/容器格式
JPEG	必需	必需	基本+渐进	JPEG (.jpg)
GIF		必需		GIF (.gif)
PNG	必需	必需		PNG (.png)
BMP		必需		BMP (.bmp)
WebP	必需	必需		WebP (.webp)

5.1.3. 视频编解码器

视频编解码器对于 Android Watch 设备实现是可选的。

格式/编解码器	编码器	解码器	详细信息	支持的文件类型/ 容器格式
H.263	必需¹	必需²		3GPP (.3gp) MPEG-4 (.mp4)
H.264 AVC	必需²	必需²	有关详细信息，请参阅第 5.2 节和 5.3	3GPP (.3gp) MPEG-4 (.mp4) MPEG-TS (.ts, 仅 AAC 音频，不可搜索，Android 3.0+)
H.265 HEVC		必需⁵	有关详细信息，请参阅第 5.3 节	MPEG-4 (.mp4)
MPEG-4 SP		必需²		3GPP (.3gp)
VP8³	必需² (Android 4.3+)	必需² (Android 2.3.3+)	有关详细信息，请参阅第 5.2 节和 5.3	WebM (.webm) [资源 110 Matroska (.mkv, Android 4.0+)⁴
VP9		必需² (Android 4.4+)	有关详细信息，请参阅第 5.3 节	WebM (.webm) [资源 110] Matroska (.mkv, Android 4.0+)⁴

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

² 对于设备实现是必需的，Android Watch 设备除外。

³ 为了保证 Web 视频流和视频会议服务的可接受质量，设备实现应（SHOULD）使用满足 [资源 51] 中要求的硬件 VP8 编解码器。

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

⁵ 强烈建议 Android Automotive 使用，Android Watch 可选，所有其他设备类型都必需。

5.2. 视频编码

视频编解码器对于 Android Watch 设备实现是可选的。

支持 H.264 编解码器的 Android 设备实现必须（MUST）支持 Baseline Profile Level 3 和以下 SD（标准清晰度）视频编码配置文件，并且应（SHOULD）支持 Main Profile Level 4 和以下 HD（高清）视频编码配置文件。强烈建议（STRONGLY RECOMMENDED）Android Television 设备以 30 fps 编码 HD 1080p 视频。

	SD（低质量）	SD（高质量）	HD 720p¹	HD 1080p¹
视频分辨率	320 x 240 像素	720 x 480 像素	1280 x 720 像素	1920 x 1080 像素
视频帧率	20 fps	30 fps	30 fps	30 fps
视频比特率	384 Kbps	2 Mbps	4 Mbps	10 Mbps

¹ 如果硬件支持，但强烈建议 Android Television 设备使用。

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

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

¹ 如果硬件支持。

5.3. 视频解码

视频编解码器对于 Android Watch 设备实现是可选的。

设备实现必须（MUST）支持在同一流内为通过标准 Android API 暴露给开发者的所有 VP8、VP9、H.264 和 H.265 编解码器动态切换视频分辨率。

具有 H.264 解码器的 Android 设备实现**必须**支持 Baseline Profile Level 3 以及以下 SD 视频解码配置文件，**应该**支持 HD 解码配置文件。Android 电视设备**必须**支持 High Profile Level 4.2 和 HD 1080p 解码配置文件。

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

1 Android 电视设备实现**必须**要求，但对于其他设备类型，仅当硬件支持时才要求。

2 Android 电视设备实现**必须**要求。

当 Android 设备实现支持第 5.1.3 节中描述的 VP8 编解码器时，**必须**支持以下 SD 解码配置文件，**应该**支持 HD 解码配置文件。Android 电视设备**必须**支持 HD 1080p 解码配置文件。

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

1 Android 电视设备实现**必须**要求，但对于其他类型的设备，仅当硬件支持时才要求。

2 Android 电视设备实现**必须**要求。

当 Android 设备实现支持第 5.1.3 节中描述的 VP9 编解码器时，**必须**支持以下 SD 视频解码配置文件，**应该**支持 HD 解码配置文件。**强烈建议** Android 电视设备支持 HD 1080p 解码配置文件，**应该**支持 UHD 解码配置文件。当支持 UHD 视频解码配置文件时，**必须**支持 8 位色深。

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

1 Android 电视设备实现**必须**要求，但对于其他类型的设备，仅当硬件支持时才要求。

2 **强烈建议** Android 电视设备实现（当硬件支持时）。

当 Android 设备实现支持第 5.1.3 节中描述的 H.265 编解码器时，**必须**支持 Main Profile Level 3 Main tier 以及以下 SD 视频解码配置文件，**应该**支持 HD 解码配置文件。Android 电视设备**应该**支持 Main10 Level 5 Main Tier 配置文件和 UHD 解码配置文件。**强烈建议** Android 电视设备支持 HD 1080p 解码配置文件。如果支持 HD 1080p 解码配置文件，则**必须**支持 Main Profile Level 4.1 Main tier。

	SD（低质量）	SD（高质量）	HD 720p 1	HD 1080p 2	UHD 2
视频分辨率	352 x 288 像素	640 x 360 像素	1280 x 720 像素	1920 x 1080 像素	3840 x 2160 像素
视频帧率	30 fps	30 fps	30 fps	30 fps	30 fps
视频比特率	600 Kbps	1.6 Mbps	4 Mbps	10 Mbps	20 Mbps

1 Android 电视设备实现**必须**要求，但对于其他类型的设备，仅当硬件支持时才要求。

2 **强烈建议** Android 电视设备实现（当硬件支持时）。

5.4. 音频录制

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

5.4.1. 原始音频捕获

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

格式：线性 PCM，16 位
采样率: 8000, 11025, 16000, 44100
声道：单声道

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

格式：线性 PCM，16 位
采样率: 22050, 48000
声道：立体声

5.4.2. 语音识别捕获

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

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

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

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 的设备实现**必须**符合本节中的要求。

5.5.1. 原始音频播放

设备**必须**允许播放具有以下特性的原始音频内容

格式：线性 PCM，16 位
采样率: 8000, 11025, 16000, 22050, 32000, 44100
声道：单声道，立体声

设备**应该**允许播放具有以下特性的原始音频内容

采样率: 24000, 48000

5.5.2. 音频效果

Android 为设备实现提供了音频效果 API [资源，52]。声明 android.hardware.audio.output 功能的设备实现

**必须**支持通过 AudioEffect 子类 Equalizer、LoudnessEnhancer 可控制的 EFFECT_TYPE_EQUALIZER 和 EFFECT_TYPE_LOUDNESS_ENHANCER 实现。
**必须**支持可视化工具 API 实现，可通过 Visualizer 类控制。
**应该**支持通过 AudioEffect 子类 BassBoost、EnvironmentalReverb、PresetReverb 和 Virtualizer 可控制的 EFFECT_TYPE_BASS_BOOST、EFFECT_TYPE_ENV_REVERB、EFFECT_TYPE_PRESET_REVERB 和 EFFECT_TYPE_VIRTUALIZER 实现。

5.5.3. 音频输出音量

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

5.6. 音频延迟

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

为了本节的目的，请使用以下定义

输出延迟。应用程序写入一帧 PCM 编码数据到外部收听者可以听到相应声音或传感器观察到相应声音之间的时间间隔。
冷启动输出延迟。音频输出系统在请求之前一直处于空闲和断电状态时，第一帧的输出延迟。
持续输出延迟。设备正在播放音频后，后续帧的输出延迟。
输入延迟。外部声音呈现给设备到应用程序读取相应帧 PCM 编码数据之间的时间间隔。
冷启动输入延迟。音频输入系统在请求之前一直处于空闲和断电状态时，丢失的输入时间和第一帧的输入延迟之和。
持续输入延迟。设备正在捕获音频时，后续帧的输入延迟。
冷启动输出抖动。冷启动输出延迟值的不同测量值之间的差异。
冷启动输入抖动。冷启动输入延迟值的不同测量值之间的差异。
持续往返延迟。持续输入延迟加上持续输出延迟再加上 5 毫秒的总和。
OpenSL ES PCM 缓冲区队列 API。Android NDK 内与 PCM 相关的 OpenSL ES API 集；请参阅 NDK_root/docs/opensles/index.html。

声明 android.hardware.audio.output 的设备实现**应该**满足或超过以下音频输出要求

冷启动输出延迟为 100 毫秒或更短
持续输出延迟为 45 毫秒或更短
最小化冷启动输出抖动

如果设备实现在使用 OpenSL ES PCM 缓冲区队列 API 进行任何初始校准后，对于至少一个受支持的音频输出设备上的持续输出延迟和冷启动输出延迟，满足本节的要求，则它**可以**通过 android.content.pm.PackageManager 类 [资源，53] 报告 android.hardware.audio.low_latency 功能来报告对低延迟音频的支持。相反，如果设备实现不满足这些要求，则**不得**报告对低延迟音频的支持。

包含 android.hardware.microphone 的设备实现**应该**满足以下输入音频要求

冷启动输入延迟为 100 毫秒或更短
持续输入延迟为 30 毫秒或更短
持续往返延迟为 50 毫秒或更短
最小化冷启动输入抖动

5.7. 网络协议

设备**必须**支持 Android SDK 文档 [资源，50] 中指定的音频和视频播放媒体网络协议。具体而言，设备**必须**支持以下媒体网络协议

RTSP (RTP, SDP)
HTTP(S) 渐进式流媒体
HTTP(S) Live Streaming 草案协议，版本 3 [资源，54]

5.8. 安全媒体

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

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

6.1. 开发者工具

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

Android 调试桥 (adb) [资源，55]

设备实现**必须**支持 Android SDK 中记录的所有 adb 功能，包括 dumpsys [资源，56]。设备端 adb 守护程序**默认必须**处于非活动状态，并且**必须**存在用户可访问的机制来打开 Android 调试桥。如果设备实现省略了 USB 外围设备模式，则**必须**通过局域网（例如以太网或 802.11）实现 Android 调试桥。

Android 包括对安全 adb 的支持。安全 adb 允许在已知的经过身份验证的主机上使用 adb。设备实现**必须**支持安全 adb。

Dalvik 调试监视服务 (ddms) [资源，57]

设备实现**必须**支持 Android SDK 中记录的所有 ddms 功能。由于 ddms 使用 adb，因此默认情况下对 ddms 的支持**应该**处于非活动状态，但只要用户如上所述激活了 Android 调试桥，就**必须**支持 ddms。

Monkey [资源，58]

设备实现**必须**包含 Monkey 框架，并使其可供应用程序使用。

SysTrace [资源，59]

设备实现**必须**支持 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 9 的 32 位和 64 位版本提供。

6.2. 开发者选项

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

7. 硬件兼容性

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

组件 API 的完整类定义（如 SDK 文档所述）**仍然必须**呈现。
API 的行为**必须**以某种合理的方式实现为 no-op。
在 SDK 文档允许的情况下，API 方法**必须**返回 null 值。
在 SDK 文档不允许 null 值的情况下，API 方法**必须**返回类的 no-op 实现。
API 方法**不得**抛出 SDK 文档中未记录的异常。

这些要求适用的场景的一个典型示例是电话 API：即使在非电话设备上，也必须将这些 API 实现为合理的 no-op。

对于相同的构建指纹，设备实现**必须**通过 android.content.pm.PackageManager 类上的 getSystemAvailableFeatures() 和 hasSystemFeature(String) 方法一致地报告准确的硬件配置信息。 [资源，53]

7.1. 显示和图形

Android 包括自动为设备适当调整应用程序资源和 UI 布局的功能，以确保第三方应用程序在各种硬件配置上良好运行 [资源，61]。设备**必须**正确实现这些 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 手表设备（在第 2 节中详细介绍）**可以**具有本节中描述的较小屏幕尺寸。

Android UI 框架支持各种不同的屏幕尺寸，并允许应用程序通过 android.content.res.Configuration.screenLayout 和 SCREENLAYOUT_SIZE_MASK 查询设备屏幕尺寸（也称为“屏幕布局”）。设备实现**必须**报告 Android SDK 文档 [资源，61] 中定义并由上游 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 设备实现**必须**具有物理对角线尺寸至少为 2.5 英寸的屏幕。

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

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

7.1.1.2. 屏幕宽高比

Android 手表设备**可以**具有 1.0 (1:1) 的纵横比。

屏幕纵横比**必须**是 1.3333 (4:3) 到 1.86（大约 16:9）之间的值，但 Android 手表设备**可以**具有 1.0 (1:1) 的纵横比，因为此类设备实现将使用 UI_MODE_TYPE_WATCH 作为 android.content.res.Configuration.uiMode。

7.1.1.3. 屏幕密度

Android UI 框架定义了一组标准逻辑密度，以帮助应用程序开发人员定位应用程序资源。设备实现**必须**通过 android.util.DisplayMetrics API 仅报告以下逻辑 Android 框架密度之一，并且**必须**以这种标准密度执行应用程序，并且**不得**在任何时候更改默认显示的值。

120 dpi (ldpi)
160 dpi (mdpi)
213 dpi (tvdpi)
240 dpi (hdpi)
280 dpi (280dpi)
320 dpi (xhdpi)
400 dpi (400dpi)
480 dpi (xxhdpi)
560 dpi (560dpi)
640 dpi (xxxhdpi)

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

7.1.2. 显示指标

设备**必须**报告 android.util.DisplayMetrics [资源，62] 中定义的所有显示指标的正确值，并且无论嵌入式屏幕还是外部屏幕用作默认显示，**必须**报告相同的值。

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。设备实现**还必须**支持 Android RenderScript，如 Android SDK 文档 [资源，63] 中详细所述。

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

托管 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 的设备实现**必须**支持相应的托管 API，并包括对本机 C/C++ API 的支持。在声明支持 OpenGL ES 3.0 或 3.1 的设备实现上，libGLESv2.so **必须**导出相应的函数符号以及 OpenGL ES 2.0 函数符号。

除了 OpenGL ES 3.1 之外，Android 还提供了一个扩展包，其中包含 Java 接口 [资源，64] 和对高级图形功能（例如细分曲面和 ASTC 纹理压缩格式）的本机支持。Android 设备实现**可以**支持此扩展包，并且——仅在完全实现的情况下——**必须**通过 android.hardware.opengles.aep 功能标志来标识支持。

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

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

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

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

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

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

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

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。如果设备通过有线、无线或嵌入式附加显示器连接支持外部显示器，则设备实现**必须**实现 Android SDK 文档 [资源，67] 中描述的显示管理器 API。

7.2. 输入设备

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

7.2.1. 键盘

Android 手表和 Android Automotive 实现**可以**实现软键盘。所有其他设备实现**必须**实现软键盘，并且

设备实现

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

7.2.2. 非触摸导航

Android 电视设备**必须**支持 D-pad。

设备实现

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

7.2.3. 导航键

Home、Recents 和 Back 功能的可用性和可见性要求因设备类型而异，如本节所述。

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 Automotive 实现**必须**提供 Home 功能，**可以**提供 Back 和 Recent 功能。
所有其他类型的设备实现**必须**提供 Home 和 Back 功能。

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

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

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

自 Android 4.0 以来，Menu 功能已被弃用，转而使用操作栏。因此，随 Android 5.0 及更高版本一起发布的新设备实现**不得**为 Menu 功能实现专用物理按钮。较旧的设备实现**应该**不要为 Menu 功能实现专用物理按钮，但如果实现了物理 Menu 按钮，并且设备正在运行 targetSdkVersion > 10 的应用程序，则设备实现

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

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

Android 支持 Assist 操作 [资源，69]。除 Android 手表设备外，Android 设备实现**必须**在运行应用程序时始终向用户提供 Assist 操作。Assist 操作**应该**实现为长按 Home 按钮或在软件 Home 键上向上滑动的手势。此功能**可以**通过另一个物理按钮、软件键或手势实现，但在其他导航键可见时**必须**可通过单个操作（例如，点击、双击或手势）访问。

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

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

7.2.4. 触摸屏输入

Android 手持设备和手表设备**必须**支持触摸屏输入。

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

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

Android 系统支持各种触摸屏、触摸板和伪触摸输入设备。基于触摸屏的设备实现与显示屏相关联 [参考资料 70]，使用户感觉好像直接在屏幕上操作项目。由于用户直接触摸屏幕，因此系统不需要任何额外的提示来指示正在操作的对象。相比之下，伪触摸界面提供了一种用户输入系统，该系统近似于触摸屏功能的一个子集。例如，鼠标或遥控器驱动屏幕上的光标以近似触摸，但需要用户首先指向或聚焦，然后单击。许多输入设备，如鼠标、触控板、基于陀螺仪的空中鼠标、陀螺仪指针、操纵杆和多点触控板，都可以支持伪触摸交互。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 屏幕坐标，并在屏幕上显示可视指针 [参考资料 71]。
必须报告触摸事件，其动作代码指定指针在屏幕上按下或抬起时发生的状态变化 [参考资料 71]。
必须支持在屏幕上的对象上按下和抬起指针，这允许用户模拟点击屏幕上的对象。
必须支持在屏幕上的对象上按下指针、抬起指针、按下指针然后在同一位置抬起指针（在时间阈值内），这允许用户模拟双击屏幕上的对象 [参考资料 71]。
必须支持在屏幕上的任意点按下指针，将指针移动到屏幕上的任何其他任意点，然后抬起指针，这允许用户模拟触摸拖动。
必须支持按下指针，然后允许用户快速将对象移动到屏幕上的不同位置，然后在屏幕上抬起指针，这允许用户在屏幕上快速滑动对象。

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

7.2.6. 游戏控制器支持

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

7.2.6.1. 按钮映射

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

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

¹ [参考资料 72]

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

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

⁴ [参考资料 71]

模拟控件¹	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

¹ [参考资料 71]

7.2.7. 遥控器

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

搜索提示。当用户在物理或基于软件的遥控器上调用语音搜索时，设备实现必须触发 KEYCODE_SEARCH。
导航。所有 Android 电视遥控器必须包括“返回”、“主页”和“选择”按钮，并支持方向键事件 [参考资料 72]。

7.3. 传感器

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

必须根据 android.content.pm.PackageManager 类 [参考资料 53] 准确报告传感器的存在或缺失。
必须通过 SensorManager.getSensorList() 和类似方法返回支持传感器的准确列表。
必须对所有其他传感器 API 表现合理（例如，当应用程序尝试注册侦听器时，返回 true 或 false，当相应的传感器不存在时，不调用传感器侦听器等）。
必须使用 Android SDK 文档 [参考资料 74] 中定义的每种传感器类型的相关国际单位制 (公制) 值报告所有传感器测量值。
应以纳秒为单位报告事件时间，如 Android SDK 文档中所定义，表示事件发生的时间，并与 SystemClock.elapsedRealtimeNano() 时钟同步。强烈建议现有和新的 Android 设备满足这些要求，以便它们能够升级到未来平台版本，因为这可能会成为必需的组件。同步误差应低于 100 毫秒 [参考资料 75]。

上面的列表并非详尽无遗；Android SDK 的文档和关于传感器的 Android 开源文档 [参考资料 73] 中的记录行为应被视为权威。

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

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

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

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

7.3.1. 加速度计

设备实现应包含 3 轴加速度计。强烈建议 Android 手持设备和 Android 手表设备包含此传感器。如果设备实现确实包含 3 轴加速度计，则

必须实现并报告 TYPE_ACCELEROMETER 传感器 [参考资料 78]。
对于 Android 手表设备，必须能够报告高达至少 50 Hz 频率的事件，因为此类设备具有更严格的功耗限制；对于所有其他设备类型，则为 100 Hz。
应报告高达至少 200 Hz 的事件。
必须遵守 Android 传感器坐标系，如 Android API [参考资料 74] 中详述。
必须能够测量从自由落体到任何轴上重力四倍 (4g) 或更大的加速度。
必须具有至少 8 位的分辨率，并且应具有至少 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 传感器坐标系，如 Android API [参考资料 74] 中详述。
必须能够在每个轴上测量 -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 接收器。如果设备实现确实包含 GPS 接收器，则应包含某种形式的“辅助 GPS”技术，以最大限度地缩短 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.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.2. IEEE 802.11 (Wi-Fi)

Android 电视设备实现必须包含 Wi-Fi 支持。

Android 电视设备实现必须包含对一种或多种形式的 802.11（b/g/a/n 等）的支持，其他类型的 Android 设备实现应包含对一种或多种形式的 802.11 的支持。如果设备实现确实包含对 802.11 的支持并将功能公开给第三方应用程序，则必须实现相应的 Android API 和

必须报告硬件特性标志 android.hardware.wifi。
必须实现 SDK 文档 [参考资料 79] 中描述的多播 API。
必须支持多播 DNS (mDNS)，并且在任何操作时间（包括屏幕未处于活动状态时）不得过滤 mDNS 数据包 (224.0.0.251)。

7.4.2.1. Wi-Fi Direct

设备实现应包含对 Wi-Fi Direct (Wi-Fi 对等网络) 的支持。如果设备实现确实包含对 Wi-Fi Direct 的支持，则必须实现 SDK 文档 [参考资料 80] 中描述的相应 Android API。如果设备实现包含对 Wi-Fi Direct 的支持，那么它

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

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

Android 电视设备实现必须包含对 Wi-Fi Tunneled Direct Link Setup (TDLS) 的支持。

Android 电视设备实现必须包含对 Wi-Fi Tunneled Direct Link Setup (TDLS) 的支持，其他类型的 Android 设备实现应包含对 Android SDK 文档 [参考资料 81] 中描述的 Wi-Fi TDLS 的支持。如果设备实现确实包含对 TDLS 的支持，并且 WiFiManager API 启用了 TDLS，则设备

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

7.4.3. 蓝牙

Android 手表和汽车实现必须支持蓝牙。Android 电视实现必须支持蓝牙和低功耗蓝牙。

Android 包括对蓝牙和低功耗蓝牙 [参考资料 82] 的支持。包含对蓝牙和低功耗蓝牙支持的设备实现必须声明相关的平台特性（分别为 android.hardware.bluetooth 和 android.hardware.bluetooth_le）并实现平台 API。设备实现应根据设备的适用性实现相关的蓝牙配置文件，例如 A2DP、AVCP、OBEX 等。Android 电视设备实现必须支持蓝牙和低功耗蓝牙。

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

必须声明硬件特性 android.hardware.bluetooth_le。
必须启用基于 GATT（通用属性配置文件）的蓝牙 API，如 SDK 文档和 [参考资料 82] 中所述。
当实现 ScanFilter API [参考资料 83] 时，应支持将过滤逻辑卸载到蓝牙芯片组，并且每当通过 android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported() 方法查询时，必须报告过滤逻辑实现位置的正确值。
应支持将批量扫描卸载到蓝牙芯片组，但如果不受支持，则每当通过 android.bluetooth.BluetoothAdapater.isOffloadedScanBatchingSupported() 方法查询时，必须报告“false”。
应支持至少 4 个插槽的多重播发，但如果不受支持，则每当通过 android.bluetooth.BluetoothAdapter.isMultipleAdvertisementSupported() 方法查询时，必须报告“false”。

7.4.4. 近场通信

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

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

（请注意，JIS、ISO 和 NFC Forum 规范的公开链接不可用。）

Android 包括对 NFC 主机卡模拟 (HCE) 模式的支持。如果设备实现确实包含能够进行 HCE 和应用程序 ID (AID) 路由的 NFC 控制器芯片组，则它

必须报告 android.hardware.nfc.hce 特性常量。
必须支持 Android SDK [参考资料 10] 中定义的 NFC HCE 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 特性 od [参考资料 53]。请注意，这不是标准的 Android 特性，因此不会作为 PackageManager 类上的常量出现。
除非设备实现还实现本节中描述的通用 NFC 支持，否则不得实现相应的 Android API，也不得报告 com.nxp.mifare 特性。

如果设备实现不包含 NFC 硬件，则不得从 android.content.pm.PackageManager.hasSystemFeature() 方法 [参考资料 53] 声明 android.hardware.nfc 特性，并且必须将 Android NFC API 实现为无操作。

由于类 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)。

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

7.4.6. 同步设置

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

7.5. 相机

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

如果设备实现至少包含一个摄像头，则应用程序应能够同时分配 3 个位图，这些位图的大小等于设备上最大分辨率摄像头传感器生成的图像大小。

7.5.1. 后置摄像头

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

必须报告特性标志 android.hardware.camera 和 android.hardware.camera.any。
必须具有至少 200 万像素的分辨率。
应在摄像头驱动程序中实现硬件自动对焦或软件自动对焦（对应用软件透明）。
可以具有固定焦点或 EDOF（扩展景深）硬件。
可以包含闪光灯。如果相机包含闪光灯，则在 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 中的 Camera API 对前置摄像头有特定的支持，设备实现必须不得配置 API，将前置摄像头视为默认的后置摄像头，即使它是设备上唯一的摄像头。
可以包含后置摄像头可用的功能（例如自动对焦、闪光灯等），如第 7.5.1 节所述。
必须水平反射（即镜像）应用程序在 CameraPreview 中显示的流，如下所示
- 如果设备实现能够由用户旋转（例如通过加速度计自动旋转或通过用户输入手动旋转），则相机预览必须相对于设备的当前方向水平镜像。
- 如果当前应用程序已通过调用 android.hardware.Camera.setDisplayOrientation()[资源 90] 方法显式请求旋转 Camera 显示，则相机预览必须相对于应用程序指定的方向水平镜像。
- 否则，预览必须沿设备的默认水平轴镜像。
必须以与相机预览图像流相同的方式镜像后视图显示的图像。如果设备实现不支持后视图，则此要求显然不适用。
必须不得镜像返回到应用程序回调或提交到媒体存储的最终捕获的静止图像或视频流。

7.5.3. 外部相机

具有 USB 主机模式的设备实现可以包含对连接到 USB 端口的外部摄像头的支持。如果设备包含对外部摄像头的支持，则它

必须声明平台功能 android.hardware.camera.external 和 android.hardware camera.any。
必须支持 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 文档 [资源 91] 中包含的完整 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 [资源 92]。

由于并非所有设备实现都能完全支持 android.hardware.camera2 API 的所有功能，因此设备实现必须使用 Android SDK [资源 93] 中描述的 android.info.supportedHardwareLevel 属性报告正确的支持级别，并报告适当的框架功能标志 [资源 94]。

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

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

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

7.5.5. 相机方向

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

7.6. 内存和存储

7.6.1. 最低内存和存储

Android 电视设备必须至少有 5GB 的非易失性存储空间可用于应用程序私有数据。

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

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

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

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

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

Android API 包括一个下载管理器，应用程序可以使用它来下载数据文件 [资源 95]。下载管理器的设备实现必须能够将至少 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 卡插槽和共享内部存储）的设备实现必须仅允许预安装的和特权 Android 应用程序使用 WRITE_EXTERNAL_STORAGE 权限写入辅助外部存储，除非写入其软件包特定的目录或在触发 ACTION_OPEN_DOCUMENT_TREE intent 返回的 URI 中。

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

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

应与参考 Android MTP 主机 Android File Transfer [资源 96] 兼容。
应报告 USB 设备类 0x00。
应报告 USB 接口名称 'MTP'。

7.7. USB

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

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

该端口必须可连接到具有标准 A 型或 C 型 USB 端口的 USB 主机。
该端口应使用 micro-B、micro-AB 或 Type-C USB 外形尺寸。现有和新的 Android 设备**强烈建议满足这些要求**，以便它们能够升级到未来的平台版本。
该端口应位于设备的底部（根据自然方向），或者为所有应用程序（包括主屏幕）启用软件屏幕旋转，以便当设备以端口在底部方向定向时，显示能够正确绘制。现有和新的 Android 设备**强烈建议满足这些要求**，以便它们能够升级到未来的平台版本。
它应实现 Android 开放附件 (AOA) API 和规范，如 Android SDK 文档中所述，如果是 Android 手持设备，则必须实现 AOA API。实现 AOA 规范的设备实现
- 必须声明对硬件功能 android.hardware.usb.accessory 的支持 [资源 97]。
- 必须实现 Android SDK 文档 [资源 98] 中记录的 USB 音频类。
它应支持在 HS 啁啾和流量期间汲取 1.5 A 电流，如 USB 电池充电规范修订版 1.2 [资源 99] 中所规定。现有和新的 Android 设备**强烈建议满足这些要求**，以便它们能够升级到未来的平台版本。
USB 标准设备描述符中的 iSerialNumber 值必须等于 android.os.Build.SERIAL 的值。

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

如果设备实现支持 USB 3.1，则应使用 C 型 USB 端口。
可以使用非标准端口外形尺寸，但如果是这样，则必须随附将端口适配为标准 A 型或 C 型 USB 端口的线缆或多个线缆。
可以使用 micro-AB USB 端口，但如果是这样，则应随附将端口适配为标准 A 型或 C 型 USB 端口的线缆或多个线缆。
**强烈建议**实现 Android SDK 文档 [资源 98] 中记录的 USB 音频类。
必须实现 Android USB 主机 API，如 Android SDK 文档中所述，并且必须声明对硬件功能 android.hardware.usb.host 的支持 [资源 100]。
应支持 1.5 A ~ 5 A 的充电下游端口输出电流范围，如 USB 电池充电规范修订版 1.2 [资源 99] 中所规定。

7.8. 音频

7.8.1. 麦克风

Android 手持设备、手表和汽车实现必须包含麦克风。

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

必须报告 android.hardware.microphone 功能常量
必须满足第 5.4 节中的音频录制要求
必须满足第 5.6 节中的音频延迟要求

7.8.2. 音频输出

Android 手表设备可以包含音频输出。

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

必须报告 android.hardware.audio.output 功能常量。
必须满足第 5.5 节中的音频播放要求。
必须满足第 5.6 节中的音频延迟要求。

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

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

7.8.2.1. 模拟音频端口

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

必须支持音频播放到立体声耳机和带有麦克风的立体声耳机，并且应支持从带有麦克风的立体声耳机进行音频录制。
必须支持具有 CTIA 引脚排列顺序的 TRRS 音频插头，并且应支持具有 OMTP 引脚排列顺序的音频插头。
如果设备实现支持麦克风，则必须支持检测插入的音频配件上的麦克风，并广播 android.intent.action.HEADSET_PLUG，并将附加值麦克风设置为 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 的麦克风偏置电压。

8. 性能兼容性

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

8.1. 用户体验一致性

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

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

8.2. 文件 I/O 访问性能

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

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

9. 安全模型兼容性

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

9.1. 权限

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

9.2. UID 和进程隔离

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

9.3. 文件系统权限

设备实现必须支持 Android 文件访问权限模型，如安全性和权限参考 [资源 102] 中定义的那样。

9.4. 备选执行环境

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

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

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

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

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

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

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

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

9.5. 多用户支持

此功能对于所有设备类型都是可选的。

Android 包括对多用户的支持，并提供对完整用户隔离的支持 [资源 103]。设备实现可以启用多用户，但启用时必须满足与多用户支持相关的以下要求 [资源 104]

未声明 android.hardware.telephony 功能标志的设备实现必须支持受限配置文件，此功能允许设备所有者管理设备上的其他用户及其功能。借助受限配置文件，设备所有者可以快速为其他用户设置单独的工作环境，并能够在这些环境中可用的应用程序中管理更精细的限制。
相反，声明 android.hardware.telephony 功能标志的设备实现必须不得支持受限配置文件，但必须与 AOSP 实现的控件对齐，以启用/禁用其他用户访问语音呼叫和短信。
对于每个用户，设备实现必须实现与 Android 平台安全模型一致的安全模型，如 Android 开发人员文档中 API 中的安全性和权限参考文档 [资源 102] 中定义的那样。
设备实现可以支持通过 android.app.admin.DevicePolicyManager API 创建用户和托管配置文件，如果支持，则必须声明平台功能标志 android.software.managed_users。
声明功能标志 android.software.managed_users 的设备实现必须使用上游 AOSP 图标徽章来表示托管应用程序和其他徽章 UI 元素，如“最近使用”和“通知”。
Android 设备上的每个用户实例都必须具有单独且隔离的外部存储目录。设备实现可以将多个用户的数据存储在同一卷或文件系统上。但是，设备实现必须确保给定用户拥有和代表其运行的应用程序无法列出、读取或写入任何其他用户拥有的数据。请注意，可移动媒体（如 SD 卡插槽）可能允许一个用户通过主机 PC 访问另一个用户的数据。因此，如果多用户已启用，使用可移动媒体作为主要外部存储 API 的设备实现必须加密 SD 卡的内容，并使用仅存储在只有系统才能访问的不可移动媒体上的密钥。由于这将使主机 PC 无法读取媒体，因此设备实现将需要切换到 MTP 或类似的系统，以便为主机 PC 提供对当前用户数据的访问。因此，如果设备实现使用可移动媒体 [资源 105] 作为主要外部存储，则可以但不应启用多用户。

9.6. 高级短信警告

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

9.7. 内核安全功能

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

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

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

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

设备实现

必须支持 SELinux 策略，该策略允许按域设置 SELinux 模式，并且必须强制模式配置所有域。不允许任何宽容模式域，包括特定于设备/供应商的域。
应从设备上的 /sepolicy 文件加载策略。
必须不得修改、省略或替换上游 Android 开源项目 (AOSP) 中提供的 sepolicy 文件中存在的 neverallow 规则，并且策略必须使用所有存在的 neverallow 进行编译，对于 AOSP SELinux 域以及设备/供应商特定的域。
必须支持 SELinux 策略文件的动态更新，而无需系统映像更新。

设备实现应保留上游 Android 开源项目中提供的默认 SELinux 策略，直到他们首先审核了对其 SELinux 策略的添加。设备实现必须与上游 Android 开源项目兼容。

9.8. 隐私

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

如果设备实现具有默认通过代理服务器或 VPN 网关路由网络数据流量的机制（例如，预加载已授予 android.permission.CONTROL_VPN 的 VPN 服务），则设备实现必须在启用该机制之前征求用户的同意。

9.9. 全盘加密

对于没有锁屏的 Android 设备实现是可选的。

如果设备实现支持带有 PIN 码（数字）或密码（字母数字）的锁屏，则设备必须支持应用程序私有数据（/data 分区）以及 SD 卡分区（如果它是设备的永久性、不可移动部件 [资源 107]）的全盘加密。对于支持全盘加密的设备，在用户完成开箱即用体验后，应始终启用全盘加密。虽然此要求在本 Android 平台版本中被声明为“应”，但**强烈建议**这样做，因为我们预计这将在未来的 Android 版本中更改为“必须”。加密必须使用密钥为 128 位（或更大）的 AES 以及为存储设计的模式（例如，AES-XTS、AES-CBC-ESSIV）。加密密钥在任何时候都不得在未加密的情况下写入存储。除了在主动使用时，加密密钥应使用使用慢速拉伸算法（例如 PBKDF2 或 scrypt）拉伸的锁屏密码进行 AES 加密。如果用户未指定锁屏密码或已禁用密码用于加密，则系统应使用默认密码来包装加密密钥。如果设备提供硬件支持的密钥库，则密码拉伸算法必须以加密方式绑定到该密钥库。加密密钥不得发送到设备外部（即使在使用用户密码和/或硬件绑定密钥包装时也是如此）。上游 Android 开源项目提供了基于 Linux 内核功能 dm-crypt 的此功能的首选实现。

9.10. 启动时验证

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

声明平台功能标志 android.software.verified_boot
在每次启动序列时执行验证
从作为信任根的硬件密钥开始验证，一直到系统分区
实施验证的每个阶段，以检查下一阶段所有字节的完整性和真实性，然后再执行下一阶段的代码
使用与 NIST 当前关于哈希算法 (SHA-256) 和公钥大小 (RSA-2048) 的建议一样强大的验证算法

设备实现**应**支持用于设备完整性的已验证启动。虽然对于此版本的 Android 平台，此要求为**应**，但**强烈建议**这样做，因为我们预计在未来版本的 Android 中，此要求将更改为**必须**。上游 Android 开源项目基于 Linux 内核功能 dm-verity 提供了此功能的首选实现。

10. 软件兼容性测试

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

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

10.1. 兼容性测试套件

设备实现**必须**使用设备上的最终交付软件通过 Android 兼容性测试套件 (CTS) [资源 108：兼容性]，该套件可从 Android 开源项目获得。此外，设备实现者**应**尽可能使用 Android 开源树中的参考实现，并且**必须**确保在 CTS 中存在歧义以及对参考源代码的任何重新实现的情况下保持兼容性。

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

10.2. CTS 验证程序

设备实现**必须**正确执行 CTS 验证程序中的所有适用案例。CTS 验证程序包含在兼容性测试套件中，旨在由人工操作员运行，以测试无法通过自动化系统测试的功能，例如摄像头和传感器的正确运行。

CTS 验证程序具有针对多种硬件的测试，包括一些可选硬件。设备实现**必须**通过其拥有的硬件的所有测试；例如，如果设备拥有加速度计，则**必须**正确执行 CTS 验证程序中的加速度计测试案例。对于本兼容性定义文档中注明为可选的功能的测试案例，**可以**跳过或省略。

如上所述，每个设备和每个版本**必须**正确运行 CTS 验证程序。但是，由于许多版本非常相似，因此不希望设备实现者在仅在细微方面不同的版本上显式运行 CTS 验证程序。具体而言，仅在包含的语言区域、品牌等方面与已通过 CTS 验证程序的实现不同的设备实现**可以**省略 CTS 验证程序测试。

11. 可更新软件

设备实现**必须**包含一种机制来替换整个系统软件。该机制不需要执行“实时”升级，也就是说，可能需要重新启动设备。

可以使用任何方法，前提是它可以替换设备上预装的整个软件。例如，以下任何方法都将满足此要求：

通过重新启动进行离线更新的“无线下载 (OTA)”
通过 USB 从主机 PC 进行“网络共享”更新
通过重新启动和从可移动存储设备上的文件进行更新的“离线”更新

但是，如果设备实现包括对不计量数据连接（如 802.11 或蓝牙 PAN（个人区域网络）配置文件）的支持

Android Automotive 实现**应**支持通过重新启动进行离线更新的 OTA 下载。
所有其他设备实现**必须**支持通过重新启动进行离线更新的 OTA 下载。

所使用的更新机制**必须**支持在不擦除用户数据的情况下进行更新。也就是说，更新机制**必须**保留应用程序私有数据和应用程序共享数据。请注意，上游 Android 软件包含满足此要求的更新机制。

对于使用 Android 5.1 及更高版本启动的设备实现，更新机制**应**支持验证系统映像在 OTA 后是否与预期结果完全相同。自 Android 5.1 以来添加的上游 Android 开源项目中的基于块的 OTA 实现满足此要求。

如果在设备实现发布后但在其合理的产品生命周期内发现错误，并且经与 Android 兼容性团队协商后确定该错误会影响第三方应用程序的兼容性，则设备实现者**必须**通过可根据刚刚描述的机制应用的软件更新来纠正该错误。

12. 文档更新日志

下表包含此版本中兼容性定义的更改摘要。

章节	更改摘要
2. 设备类型	为 Android Automotive 实现添加了定义。
2.1 设备配置	为 Android Automotive 实现添加了列。
3.3.2. 32 位 ARM 原生代码兼容性	添加了新部分。
3.4.1. WebView 兼容性	更新了 webview 用户代理字符串要求，以适应上游实现更改。
3.4.2. 浏览器兼容性	添加了 Android Automotive 实现作为可以省略浏览器应用程序的另一种情况。
3.7. 运行时兼容性	更新了较小屏幕的所需运行时堆大小，并为新的 dpi 存储桶 (280dpi) 添加了要求。
3.8.3. 通知	阐明了 Android Watch、电视和 Automotive 实现的通知要求。
3.8.8. Activity 切换	放宽了概览标题计数要求。
3.8.10. 锁屏媒体控件	阐明了 Android Watch 和 Automotive 实现的要求。
3.8.13. Unicode 和字体	放宽了 Emoji 字符输入法要求。
3.9. 设备管理	阐明了何时必须支持全范围的设备管理策略的条件。
3.10. 无障碍功能	添加了 Android Automotive 要求。
3.11. 文本转语音	添加了 Android Automotive 要求。
5.1. 媒体编解码器	强制要求解码 CamcorderProfile 报告的编解码器的支持。
5.1.3 视频编解码器	添加了 Android Automotive 要求。
5.4. 音频录制	在部分开头阐明了语言，以确保将必须要求理解为REQUIRED。
7.1.1.3. 屏幕密度	添加了新的屏幕 dpi (280dpi)。
7.1.5. 旧版应用兼容模式	添加了 Android Automotive 要求。
7.2 输入设备	添加了一般介绍性声明。
7.2.1. 键盘	添加了 Android Automotive 要求。
7.2.3. 导航键	添加了 Android Automotive 要求。
7.3.1. 加速度计	放宽了 Android Watch 上报告频率的要求。
7.3.4. 陀螺仪	放宽了 Android Watch 上报告频率的要求。
7.4.3 蓝牙	添加了 Android Automotive 要求。
7.4.4. 近场通信	阐明了何时 Host Card Emulation 成为要求的条件。
7.6.1. 最低内存和存储	更新了较低分辨率屏幕设备的最低内存要求，并添加了硬限制要求 isLowRamDevice()。
7.6.2. 应用共享存储	更新了何时强制要求支持主机访问的要求。
7.7 USB	修复了 USB 部分中的错别字
7.6.2. 应用共享存储	更新了预安装的系统应用程序可以写入辅助外部存储的要求。
7.6.2. 应用共享存储	应用程序可以使用 ACTION_OPEN_DOCUMENT_TREE 写入辅助外部存储
7.6.2. 应用共享存储	阐明了 /sdcard 可以与 /data 共享存储
7.7 USB	从 7.7 中删除了关于 UMS/MTP 的冗余要求
7.8.1. 麦克风	添加了 Android Automotive 要求。
8.2. 文件 I/O 访问性能	阐明了要求。
9.5. 多用户支持	主外部存储需要 SD 卡加密。
9.8. 隐私	为预加载的 VPN 添加了隐私要求。
9.9. 全盘加密	阐明了何时强制要求全盘加密支持的条件。
9.10. 启动时验证	阐明了已验证启动的定义。
11. 可更新软件	阐明了 OTA 下载要求对于 Android Automotive 实现是允许的，但不是强制性的。