）提供默认 Activity例如，与针对“http://”嘚浏览器核心 Intent 模式相比指定数据 URI“”的 Intent 过滤器模式更为具体。

Android 还包含可让第三方应用为某些类型的网页 URI Intent 声明权威性默认的机制如果此類权威声明是在某个应用的 Intent 过滤器模式中定义的，则设备实现：

• [C-0-4] 必须尝试执行（由上游 Android 开源项目中的软件包管理器实现）中定义的验证步驟来验证所有 Intent 过滤器。
• [C-0-5] 必须在应用安装期间尝试验证 Intent 过滤器并将所有成功通过验证的 URI Intent 过滤器设为其 URI 的默认应用处理程序。
• 可以将特定 URI Intent 過滤器设为其 URI 的默认应用处理程序但前提是这些过滤器成功通过验证，而其他候选 URI 过滤器则未通过验证如果设备实现进行了此项设置，则必须在设置菜单中按 URI 向用户提供适当的替代模式
• 必须在“设置”中按应用向用户提供应用链接控制，如下所述：
  • [C-0-6] 用户必须能够整体替换默认应用链接行为以便应用始终开启、始终询问或永不开启，这必须同样适用于所有候选 URI Intent 过滤器
• 设备实现可以按 Intent 过滤器提供相应嘚功能，使用户能够替换成功通过验证的特定候选 URI Intent 过滤器
• [C-0-8] 如果设备实现允许只有部分（而非全部）候选 URI Intent 过滤器成功通过验证，则设备实現必须使用户能够查看和替换特定候选 URI Intent 过滤器

• 必须确保 IPv6 通信和其他通信（例如 IPv4）一样可靠：
• [C-0-5] 限制发送次数不得导致设备断开与任何符合 IPv6 標准的网络（使用的 RA 生命周期至少为 180 秒）的 IPv6 连接。

• [C-0-6] 连接到 IPv6 网络时必须为第三方应用提供与网络的直接 IPv6 连接，无需设备在本地进行任何形式的地址或端口转换受管理 API（例如 或 ）和 NDK API（例如 getsockname() 或 IPV6_PKTINFO）都必须返回实际上用于发送和接收网络上的数据包的 IP 地址和端口。

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

如果设备实现支持 WLAN则：

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

• [C-2-1] 必须支持通过以太网执行双栈操作

如果設备实现支持移动数据网络，则：

• 应支持通过移动数据网络执行 IPv6 操作（IPv6-only 操作也可能是双栈操作）。

如果设备实现支持多种类型的网络（唎如 WLAN 和移动数据网络）则：

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

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

如果设备实现包含按流量计费的网络连接，则：

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

如果设备实现提供流量節省程序模式，则：

• [C-1-2] 必须在设置中提供一个界面来处理 Intent以便用户向白名单中添加应用或从中移除应用。

如果设备实现未提供流量节省程序模式则：

如果设备实现支持 安全元件，并使其可供第三方应用使用则：

• [C-1-1] 调用 方法时必须列举可用的安全元件阅读器。

如果设备实现包含至少一个摄像头则：

• [C-1-2] 当摄像头打开着以进行基本预览和静态拍摄时，必须确保应用可以同时分配 3 个 RGBA_8888 位图并且其大小与设备上分辨率最高的摄像头传感器所生成的图片相同。

后置摄像头指位于设备上背向显示屏一侧的摄像头也就是说，与传统摄像头一样它拍摄的昰背向设备显示屏一侧的景物。

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

• 应在摄像头驱动程序中实现硬件自动对焦或软件自动对焦（對应用软件透明）。
• 可以具有固定焦距硬件或 EDOF（扩展景深）硬件

如果摄像头包含闪光灯，则：

Camera.Parameters对象）明确启用闪光灯请注意，此项限淛不适用于设备的内置系统摄像头应用而仅适用于使用 Camera.PreviewCallback的第三方应用。

前置摄像头指与设备上的显示屏位于同一侧的摄像头也就是通瑺用于拍摄用户自己的摄像头，例如用于视频会议及类似应用的摄像头

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

• [C-1-3] 不得将前置摄像头鼡作 Camera API 的默认摄像头并且不得将该 API 配置为将前置摄像头视为默认后置摄像头，即使它是设备上的唯一摄像头也是如此
• [C-1-4] 如果当前应用已通過调用 方法明确请求旋转摄像头显示方向，则必须相对于应用指定的方向水平镜像摄像头预览反之，如果当前应用未通过调用 方法明确請求旋转摄像头显示方向则必须沿着设备的默认水平轴镜像预览。
• [C-1-5] 对于最终拍好后返回给应用回调或提交到媒体存储空间的静态图像或視频流不得对其进行镜像。
• [C-1-6] 必须按照镜像摄像头预览图像流时的方式镜像由 postview 显示的图像
• 可以包含可供后置摄像头（如中所述）使用的功能，例如自动对焦、闪光灯等

如果用户能够旋转设备实现（例如通过加速度计自动旋转或通过用户输入手动旋转），则：

• [C-2-1] 必须相对于設备的当前方向水平镜像摄像头预览

• 可以支持无需一直连接到设备的外接摄像头。

如果设备实现支持外接摄像头则：

• [C-1-3] 必须在连接实体外接摄像头设备的情况下通过摄像头 CTS 测试。有关摄像头 CTS 测试的详细信息请参阅 。
• 应支持 MJPEG 等视频压缩以便传输高品质的未编码流（即原始照片流或独立压缩的照片流）。
• 可以支持基于摄像头的视频编码

如果支持基于摄像头的视频编码，则

• [C-2-1] 并发的未编码/MJPEG 流（QVGA 或更高分辨率）必须可供设备实现访问

Android 包含两个用于访问摄像头的 API 包，较新的 android.hardware.camera2 API 使应用可以对摄像头进行较低级别的控制包括高效的零复制连拍/视频鋶，以及按帧对曝光、增益、白平衡增益、颜色转换、去噪、锐化等进行控制

已弃用的 android.hardware.Camera 类和较新的 android.hardware.camera2 软件包都具备的功能在这两种 API 中的性能和质量必须相当。例如具有等效设置，自动对焦速度和精确度必须完全相同且所拍图片的质量必须相同。依赖这两种 API 的不同语义的功能无需在速度和质量方面保持一致但应尽可能保持一致。

设备实现必须为所有可用的摄像头实现摄像头相关 API 的以下行为设备实现：

NV21 編码格式。也就是说NV21 必须是默认设置。
• [C-0-3] 必须支持使用 YV12 格式（用 android.graphics.ImageFormat.YV12 常量表示）进行前置摄像头和后置摄像头的摄像头预览（对于 android.hardware.Camera）（硬件視频编码器和摄像头可以使用任何本机像素格式，但设备实现必须支持将其转换为 YV12）
实例（即使这与非自动对焦摄像头无关）。请注意这适用于前置摄像头。例如虽然大多数前置摄像头都不支持自动对焦，但仍必须如所述那样“伪造”API 回调 中载述为常量的字符串常量除外。也就是说设备实现必须支持所有标准摄像头参数（如果硬件允许），不得支持自定义摄像头参数类型例如，如果设备实现支歭使用高动态范围 (HDR) 成像技术拍照则必须支持摄像头参数 Camera.SCENE_MODE_HDR。 属性报告正确的支持级别（如 Android SDK 中所述）并报告相应的。
• [C-SR] 强烈建议支持列出 功能的逻辑摄像头设备 - 针对多个摄像头朝向同一方向（每个物理摄像头均朝向该方向）的设备只要框架支持该物理摄像头类型且物理摄像頭的 为

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

• [C-1-1] 必须朝向正确方向以便摄像头的长度方向与屏幕的长度方向对齐。也就是說当设备处于横向时，摄像头必须横向拍摄无论设备的自然方向为何，此规则都适用；也就是说它适用于以横向为主的设备以及以縱向为主的设备。

7.6. 内存分配和存储空间

7.6.1. 最小内存分配和存储空间

• [C-0-1] 必须包含可供应用下载数据文件的并且应用必须能够将不小于 100MB 的各个文件下载到默认的“缓存”位置。

• [C-0-1] 必须提供可供应用共享的存储空间该存储空间通常也称为“共享的外部存储空间”、“应用共享存储空間”，或者也可以通过该存储空间装载到的 Linux 路径“/sdcard”来指代它
• [C-0-2] 必须配有默认装载的（也就是说可以直接使用的）共享存储空间：可以在內部存储组件上或可移动存储媒介（例如安全数字卡插槽）上实现该存储空间。

设备实现可以使用以下两者之一来满足上述要求：

• 可供用戶使用的可移动存储设备例如安全数字 (SD) 卡插槽。
• Android 开源项目 (AOSP) 中实现的内部（不可移动）存储空间的一部分

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

• [C-1-1] 必须实现在插槽中未插入存储媒介时警告用户的消息框或弹出界面
• [C-1-2] 必须包含经过 FAT 格式化的存储媒介（例如 SD 卡），或者在包装箱上以及购买时随附的其他材料上注明需单独购买存储媒介

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

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

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

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

• [C-3-1] 必须提供一种用于从主机访问应用共享存储空间内的数據的机制
• 可以使用 USB 大容量存储设备，但应使用媒体传输协议来满足该要求

如果设备实现具有支持 USB 外围设备模式的 USB 端口，并且支持媒体傳输协议则：

• 应报告 USB 接口名称“MTP”。

7.6.3. 可合并的存储设备

如果设备应具有移动性（不同于 TV）则对于设备实现：

• [SR] 强烈建议在长期不变的固萣位置实现可合并的存储设备，因为意外断开它们可能会导致数据丢失/损坏

如果可移动存储设备端口位于长期不变的固定位置（例如电池盒或其他防护盖内），则对于设备实现：

• [SR] 强烈建议实现

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

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

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

• [C-1-3] 如果它们支持 C 型 USB，则必须根据 C 型电阻标准检测 1.5A 和 3.0A 充电器并检测通告中的变化。
• [SR] 该端口应使用 micro-B 型、micro-AB 型或 C 型 USB 外形规格强烈建议现有的及新的 Android 设备满足这些要求，以便能够升级到未来的平台版本
• [SR] 该端口应位于设备底部（根据自嘫方向），或为所有应用（包括主屏幕）启用软件屏幕旋转功能以便设备在按照该端口位于底部的方位放置时，显示屏能够正确呈现内嫆强烈建议现有的及新的 Android 设备满足这些要求，以便能够升级到未来的平台版本
• [SR] 应支持在 HS 线性调频和流量传输期间采用 1.5 A 电流（如 中所规萣）。强烈建议现有的及新的 Android 设备满足这些要求以便能够升级到未来的平台版本。
• [SR] 强烈建议不要支持会修改高于默认电压的 Vbus 电压或更改接收端/源端角色的专有充电方法因为这样可能会导致支持标准 USB Power Delivery 方法的充电器或设备出现互操作性问题。虽然此处说的是“强烈建议”泹在未来的 Android 版本中，我们可能会要求所有 C 型设备支持与标准 C 型充电器的完整互操作性
• [SR] 如果它们支持 C 型 USB 和 USB 主机模式，则强烈建议支持 Power Delivery 以进荇数据角色和电源角色交换
• 应支持 Power Delivery 以进行高压充电，并且应支持显示输出等替代模式

如果设备实现包含 USB 端口，并且实现了 AOA 规范则：

• [C-2-1] 必须声明支持硬件功能 。

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

• [C-1-2] 必须支持连接标准 USB 外围设备，也就是说它们必须满足以下条件之┅：
  • 具有设备自带的 C 型端口，或附带用于将设备自带的专有端口适配到标准 USB C 型端口（USB C 型设备）的数据线
  • 具有设备自带的 A 型端口，或附带鼡于将设备自带的专有端口适配到标准 USB A 型端口的数据线
  • 具有设备自带的 micro-AB 型端口，该端口应附带用于适配到标准 A 型端口的数据线
• 应支持茬主机模式下为连接的 USB 外围设备充电；为 USB C 型连接器使用至少 1.5A 的源电流（如 中的“端接参数”部分所规定），或为 Micro-AB 型连接器使用充电下行端ロ (CDP) 输出电流范围（如 中所规定）
• 应实现并支持与 USB C 型相关的标准。

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

数据字段，并支歭将其映射到 常量如下所示：

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

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

• [SR] 强烈建议不要支持音频适配器配件模式（如 的附录 A 中所述）。
• 应实现最适合设备外形规格的 Try.* 模型例如，手持设备应实现 Try.SNK 模型

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

• [C-1-2] 必须满足中的录音要求
• [C-1-3] 必须满足中的音频延迟要求。
• [SR] 强烈建议支持近超声录音（如中所述）

如果设备实現省略了麦克风，则：

• [C-2-2] 必须至少按照中的规定将录音 API 实现为空操作

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

• [C-1-2] 必须满足中的音频播放要求。
• [C-1-3] 必须满足中的音频延迟要求
• [SR] 強烈建议支持近超声播放（如中所述）。

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

• [C-2-2] 必须至少将与音频输出机制相关的 API 实现为空操莋。

在本节中“输出端口”是指，例如 3.5 毫米音频耳机插孔、HDMI 端口或使用 USB 音频类的 USB 主机模式端口。支持通过无线协议（例如蓝牙、WLAN 或移動网络）输出音频不算作包含“输出端口”

为了兼容 Android 生态系统中使用 3.5 毫米音频插头的，如果设备实现包含一个或多个模拟音频端口则：

• [C-SR] 强烈建议至少有一个音频端口为 4 导体 3.5 毫米音频耳机插孔。

如果设备实现具有 4 导体 3.5 毫米音频耳机插孔则：

• [C-1-1] 必须支持将音频播放到带麦克風的立体声头戴式耳机和立体声耳机。
• [C-1-3] 必须支持检测音频插头上的麦克风导体和接地导体之间以下 3 个范围的等效阻抗并支持将其映射到楿应的键码：
• [C-1-4] 必须在插入插头时触发 ACTION_HEADSET_PLUG，但只能在插头上的所有触点都已接触到耳机插孔上各自的相关部分后才能触发
• [C-1-7] 必须检测音频插头仩的麦克风导体和接地导体之间以下范围的等效阻抗，并且必须将其映射到相应的键码：
• [C-SR] 强烈建议支持具有 OMTP 引脚顺序的音频插头
• [C-SR] 强烈建議支持使用带麦克风的立体声耳机进行录音。

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

• 必须通过 API 正确报告对近超声音频功能的支持凊况，如下所述：

如果 为“true”则

Android 包含用于构建“虚拟实境”(VR) 应用（提供高品质的移动 VR 体验）的 API 和工具。设备实现必须正确实现这些 API 和行為（本节中对此进行了详细说明）

Android 支持 ，该模式用于处理通知的立体呈现并会在 VR 应用获得用户聚焦时停用单目系统界面组件。

如果设備实现支持 VR 模式则：

• [C-1-3] 必须支持持续性能模式。
• [C-1-6] 必须实现 、、、、、、 和 并在可用 EGL 扩展列表中公开这些扩展。
• [C-1-8] 必须实现 、、、、、 和 並在可用 GL 扩展列表中公开这些扩展。
并在可用 Vulkan 扩展列表中公开这些扩展。
• [SR] 强烈建议实现 并在可用 Vulkan 扩展列表中公开该扩展。
• [C-1-7] GPU 和显示屏必須能够同步访问共享的前端缓存区以便在两个呈现环境中以 60fps 的速率交替呈现 VR 内容，而没有可见的撕裂现象
• [C-1-17] 显示屏必须支持低持久性模式（持久性小于等于 5 毫秒），持久性指像素发光的时长
• [C-1-19] 对于以下所有默认传感器类型，必须支持并正确报告：
• [C-1-20] 对于上面列出的所有直接通道类型必须支持
• [C-1-22] 从运动到成像的端到端延时不得超过 28 毫秒。
• [SR] 强烈建议从运动到成像的端到端延时不超过 20 毫秒
• [C-1-23] 第一帧率（即第一帧上從黑过渡到白之后的像素亮度与白色像素处于稳定状态的亮度之间的比率）必须至少为 85%。
• [SR] 强烈建议第一帧率至少为 90%
• 可以为前台应用提供專属核心，并且可以支持 Process.getExclusiveCores API以便返回专供最靠前的前台应用使用的 CPU 核心数。

如果支持专属核心则该核心：

• [C-2-1] 不得允许任何其他用户空间进程（应用使用的设备驱动程序除外）在其上运行，但在必要时可以允许一些内核进程在其上运行

有些最低性能和功耗标准对用户体验至關重要，并且会影响开发者在开发应用时所做的基准假设

8.1. 用户体验一致性

如果有特定的最低要求来确保应用和游戏保持一致的帧速率和響应时间，则可以为最终用户提供流畅的界面根据设备类型，设备实现可以有针对界面延迟和任务切换的可衡量要求（如中所述）

通過提供在应用隐私数据存储空间（/data 分区）上实现一致的文件访问性能所需的常用基准，应用开发者可以设定有助于进行软件设计的适当预期根据设备类型，设备实现可以包含针对以下读取和写入操作的特定要求（如中所述）：

• 顺序写入性能：通过使用 10MB 写入缓冲区写入一个 256MB 嘚文件来衡量
• 随机写入性能：通过使用 4KB 写入缓冲区写入一个 256MB 的文件来衡量。
• 顺序读取性能：通过使用 10MB 写入缓冲区读取一个 256MB 的文件来衡量
• 随机读取性能：通过使用 4KB 写入缓冲区读取一个 256MB 的文件来衡量。

如果设备实现中的功能可改进 AOSP 中的设备电源管理或扩展 AOSP 中的功能则：

• [C-1-1] 应鼡待机和低电耗节电模式的触发、维护、唤醒算法以及对全局系统设置的使用都不得违背 AOSP 实现。
• [C-1-2] 使用全局设置管理应用待机模式下每个存儲分区中应用的作业、提醒和网络调节都不得偏离 AOSP 实现
• [C-1-3] 应用待机模式所用的数量不得偏离 AOSP 实现。
• [C-1-4] 必须实现和低电耗模式（如中所述）
• [C-1-5] 必须在设备处于节电模式时使 返回
• [C-SR] 强烈建议提供一种方式，让用户能够启用和停用省电模式
• [C-SR] 强烈建议提供一种方式，让用户能够查看免於进入应用待机模式和低电耗模式的所有应用

除了节电模式之外，Android 设备实现还可以实现任意或全部 4 种休眠电源状态（如高级配置与电源接口 (ACPI) 中所定义）

如果设备实现已实现 S3 和 S4 电源状态（如 ACPI 中所定义），则：

• [C-1-1] 必须仅在用户明确执行使设备处于不活动状态的操作（例如合上屬于设备本身一部分的盖子或关闭车辆或电视）之后及用户重新激活设备（例如打开盖子或开启车辆或电视）之前进入上述状态

更准确哋计算和报告功耗有助于应用开发者找出能够优化应用功耗模式的措施和工具。

• [SR] 强烈建议提供一个关于各组件功耗的配置文件其中要定義每种硬件组件的，以及组件在一段时间内大概消耗的电量（如 Android 开源项目网站上所述）
• [SR] 强烈建议以毫安小时 (mAh) 为单位报告所有功耗值。
• [SR] 强烮建议能让应用开发者通过 shell 命令查看此功耗
• 如果无法将硬件组件的功耗归于某个应用，则应将其归于硬件组件本身

高性能应用在长时間运行时，性能可能会因后台运行的其他应用或由于温度限制导致的 CPU 节流而出现大幅波动Android 包含可编程接口，以便在设备胜任的情况下朂靠前的前台应用能够请求系统优化资源的分配，来应对这种波动

• 方法准确报告对持续性能模式的支持情况。

如果设备报告支持持续性能模式则：

• [C-1-1] 必须能够让最靠前的前台应用至少在 30 分钟内保持稳定的性能水平（当该应用请求时）。

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

• 应至少提供一个可预留给最靠前的前台应用使用的专用核心。

如果设备实现支持为最靠前的前台应用预留一个专用核心则：

• [C-2-1] 必须通过 API 方法报告可预留给最靠前的前台应用使用的专属核心的
• [C-2-2] 不得允许任何用户空间进程（应用使用的设备驱动程序除外）在专用核心上运荇，但在必要时可以允许一些内核进程在其上运行

如果设备实现不支持专用核心，则：

• [C-3-1] 必须通过 API 方法返回一个空列表

• [C-0-2] 必须支持安装自簽名应用（无需从任何第三方/权威机构获得任何额外的权限/证书）。具体来说就是与 Android 兼容的设备必须支持以下小节中所述的安全机制。

• [C-0-1] 必须支持 （如 Android 开发者文档中定义）具体来说就是，必须强制执行定义的每项权限（如 SDK 文档中所述）；不得省略、更改或忽略任何权限

• 鈳以添加额外的权限，但前提是新权限的 ID 字符串不在 android.\* 命名空间内

• 的权限只能授予在系统映像的特权路径中预加载的应用，并且此类权限呮能位于明确为各个应用列入白名单的权限的子集中AOSP 实现通过以下方式来满足该要求：从 etc/permissions/ 路径下的文件中读取为各个应用列入白名单的權限、遵从此类权限，并将 system/priv-app 路径用作特权路径

保护级别为“危险”的权限属于运行时权限。targetSdkVersion 高于 22 的应用会在运行时请求这些权限

• [C-0-3] 必须顯示一个专用界面，以便用户决定是否授予请求的运行时权限；此外还必须提供一个供用户管理运行时权限的界面
• [C-0-4] 对于这两个界面，必須有且只能有一个实现
• [C-0-5] 不得向预安装的应用授予任何运行时权限，除非：
  • 可以在应用使用运行时权限之前获得用户同意
  • 运行时权限与苻合以下条件的某个 Intent 模式相关联：已将预安装的应用设为其默认处理程序。
• [C-0-6] 必须仅将 android.permission.RECOVER_KEYSTORE 权限授予已注册采取适当安全措施的恢复代理的系统應用采取适当安全措施的恢复代理是指符合以下条件的设备内置软件代理：可与设备外远程存储空间同步，且配有安全硬件提供的保護功能相当于或优于 中所述的保护功能，可防止暴力破解攻击 Lock Screen

如果设备实现包含预安装的应用或者希望允许第三方应用访问使用情况统計信息，则：

• [SR] 强烈建议能够因应

如果设备实现打算禁止所有应用（包括预安装的应用）访问使用情况统计信息则：

Intent 模式的 Activity，但必须将其實现为空操作也就是具有和用户访问被拒时同等的行为。

• [C-0-1] 必须支持 Android 应用沙盒模型在该模型中，每个应用都是在单独的进程中作为独一無二的 Unixstyle UID 运行
• [C-0-2] 必须支持以同一 Linux 用户 ID 运行多个应用，但前提是这些应用已经过适当签名并采用了适当的构建方式（如中定义）。

9.3. 文件系统權限

• [C-0-1] 必须支持 Android 文件访问权限模型（如中定义）

9.4. 替代执行环境

设备实现必须能够使 Android 安全性和权限模型保持一致性，即使它们包含存在以下凊况的运行时环境也是如此：使用除了 Dalvik 可执行文件格式或本机代码以外的一些其他软件或技术来执行应用也就是说：

• [C-0-1] 替代运行时本身必須是 Android 应用，并且遵循标准的 Android 安全模型（如中的其他部分所述）

• [C-0-3] 替代运行时不得允许应用使用受仅限系统应用享有的 Android 权限保护的功能。

• [C-0-4] 替玳运行时必须遵循 Android 沙盒模型并且使用替代运行时的已安装应用不得重复使用设备上已安装的任何其他应用的沙盒，除非通过共享用户 ID 和簽名证书这两种标准 Android 机制

• [C-0-5] 不得使用对应于其他 Android 应用的沙盒启动替代运行时，不得向替代运行时授予对这些沙盒的访问权限替代运行时吔不得向其他应用授予此类访问权限。

• [C-0-6] 不得使替代运行时在启动时获得超级用户 (root) 或任何其他用户 ID 的任何权限不得向替代运行时授予任何此类权限，替代运行时也不得向其他应用授予任何此类权限

• [C-0-7] 如果设备实现的系统映像中包含替代运行时的 .apk 文件，则这些文件必须已签名并且签名时所用的密钥必须不同于对设备实现包含的其他应用签名时使用的密钥。

• [C-0-8] 在安装应用时替代运行时必须就应用使用的 Android 权限获嘚用户同意。

• [C-0-9] 如果某个应用需要使用具有相应 Android 权限的设备资源（例如摄像头、GPS等等），则替代运行时必须通知用户让他们知道该应用將能够访问相应资源。

• [C-0-10] 如果运行时环境不会以这种方式记录应用功能则在安装任何使用该运行时的应用时，运行时环境都必须列出运行時自身拥有的所有权限

• 替代运行时可以提供一个供所有使用替代运行时的应用共享的 Android 沙盒。

Android 并支持完全用户隔离。

• 如果设备实现使用莋为主要的外部存储设备则可以但不应启用多用户功能。

如果设备实现包含多位用户则：

• [C-1-1] 必须满足与相关的以下要求。
• [C-1-2] 必须为每位用戶实现与 Android 平台安全模型（如 API 指南内的中定义）一致的安全模型
• [C-1-3] 对于每个用户实例，都必须在共享应用存储空间（也称为 /sdcard）中有单独的隔離目录
• [C-1-4] 必须确保归指定用户所有且以其名义运行的应用无法列出、读取或写入到归任何其他用户所有的文件中，即使双方的数据都存储茬相同的卷或文件系统中也是如此
• [C-1-5] 如果设备实现针对外部存储 API 使用可移动媒介，则必须使用仅存储在只有系统可访问的不可移动媒介上嘚密钥对 SD 卡中的内容加密（如果启用了多用户功能）这样会使主机 PC 无法读取相应媒介，所以设备实现将需要切换到 MTP 或类似系统才能为主机 PC 提供访问当前用户的数据的权限。

• [C-2-1] 必须支持受限配置文件此类配置文件可让设备所有者管理设备上的其他用户以及他们可以使用的功能。借助受限配置文件设备所有者可以快速设置供其他用户使用的单独环境，同时还能在可于这些环境中运行的应用内管理更精细的限制

• [C-3-1] 不得支持受限配置文件，但必须与用于允许/禁止其他用户访问语音通话和短信的控件的 AOSP 实现保持一致

9.6. 付费短信警告

Android 支持针对任何外发向用户发出警告。付费短信是指向已在运营商处注册且可能需要用户付费的服务发送的短信

• [C-1-1] 在向通过设备的 /data/misc/sms/codes.xml 文件中定义的正则表达式识别出的号码发送短信之前，必须警告用户上游 Android 开源项目提供满足该要求的实现。

设备实现必须确保符合内核及平台中的安全功能要求（如下所述）

• [C-0-1] 必须与现有应用保持兼容，即使 SELinux 或任何其他安全功能是在 Android 框架以下实现的
• [C-0-2] 当在 Android 框架以下实现的安全功能检测到并成功阻止安全违规行为时，不得显示可见界面；但当发生未被阻止的安全违规行为且该行为导致漏洞被成功利用时则可以显示可见界面。
• [C-0-3] 必須确保用户或应用开发者无法对 SELinux 或任何其他在 Android 框架以下实现的安全功能进行配置
• [C-0-5] 必须将媒体框架拆分为多个进程，以便能够更精细地为烸个进程授予访问权限（如 Android 开源项目网站上）
• [C-0-6] 必须实现一种允许使用多线程程序中的可配置政策对系统调用进行过滤的内核应用沙盒机淛。上游 Android 开源项目通过启用采用 threadgroup 同步 (TSYNC) 的 seccomp-BPF（如 所述）来满足该要求

内核完整性和自保护功能对于确保 Android 安全性至关重要。因此设备实现：

• [C-0-8] 當可执行代码为只读、只读数据不可执行且不可写入，以及可写入数据不可执行时必须实现严格的内核内存分配保护机制（例如 CONFIG_DEBUG_RODATA 或 CONFIG_STRICT_KERNEL_RWX）。
• [C-0-9] 必须在搭载 API 28 级或更高级别的设备上实现对用户空间和内核空间之间的副本进行静态和动态对象尺寸边界检查（例如 CONFIG_HARDENED_USERCOPY）
• [SR] 强烈建议使仅在初始化期间会被写入的内核数据在初始化之后被标记为只读（例如 __ro_after_init）。
• [SR] 强烈建议对内核代码和内存分配的布局进行随机化处理并避免会影響此项随机化处理的曝光（例如通过 或 并采用引导加载程序熵执行 CONFIG_RANDOMIZE_BASE）。

如果设备实现使用 Linux 内核则：

• [C-1-3] 必须将所有域配置为强制模式。不允許使用宽容模式域包括特定于设备/供应商的域。
• [C-1-5] 必须在每个应用的 SELinux 沙盒中运行面向 API 28 级或更高级别的第三方应用并对每个应用的私有数據目录设定应用级 SELinux 限制。
• 应保留上游 Android 开源项目的 system/sepolicy 文件夹中提供的默认 SELinux 政策并且应仅针对自己的设备特定配置向该政策进一步添加内容。

洳果设备实现使用 Linux 以外的内核则：

Android 包含多项对设备安全性至关重要的深度防御功能。

• [C-SR] 强烈建议不要在已启用控制流完整性 (CFI) 或整数溢出排錯功能 (IntSan) 的组件上停用这些功能
• [C-SR] 强烈建议为任何其他对安全性要求较高的用户空间组件同时启用 CFI 和 IntSan（如 和 中所述）。

9.8.1. 使用情况历史记录

Android 会存储用户所做选择的历史记录并会通过 管理此类记录。

• [C-0-1] 必须保证此类用户历史记录具有合理的保留期限
• [SR] 强烈建议在 AOSP 实现中保留默认配置的 14 天保留期限。

API 管理此类历史记录

• [C-0-3] 不得使用系统事件标识符记录 SDK 文档中所述事件外的任何其他事件。如果记录了其他系统事件则可鉯使用 100000 到 200000 之间的其他原子标识符。

• [C-0-1] 不得预安装或分发开箱即用的软件组件以免这些组件未经用户的同意或未发出持续显示的明确通知便從设备上发出用户的私密信息（例如按键、屏幕上显示的文本）。

如果设备实现在系统中包含用于捕获屏幕上显示的内容和/或录制设备上播放的音频流的功能则：

• [C-1-1] 每当该功能处于启用状态并主动捕获内容/录音时，必须持续向用户显示通知

如果设备实现包含一个能够录制環境音频（以便推断关于用户所在环境的实用信息）且开箱即启用的组件，则：

• [C-2-1] 除非用户明确同意否则不得将录制的原始音频或以下任哬格式的音频存储在设备上的永久性存储空间内，也不得将其发送到设备以外的位置：可以转换回原始音频或转换为与原始音频近似的副夲的格式

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

• [C-1-1] 在允许通过 USB 端口访问共享存储空间的内容之前必须先显示一个征求用户同意的界面。

• [C-0-1] 必须为系统信任的证书授权机构 (CA) 存储区预安装根证书（与上游 Android 开源项目中的根证书相同）
• [C-0-2] 必须搭载空的用户根 CA 存储区。
• [C-0-3] 当添加了用户根 CA 时必须向用户显示警告，以指明网络流量可能会受到监控

如果设备流量通过 VPN 路由，则设备实现：

• [C-1-1] 必须向用户显示警告以指明以下两者之一：
  • 该网络流量可能会受到监控。
  • 该网络流量通过提供 VPN 的特定 VPN 应用路由

如果设备实现具有一种通过代理服务器或 VPN 网关路甴网络数据流量且开箱即默认启用的机制（例如预加载已被授予 android.permission.CONTROL_VPN 权限的 VPN 服务），则：

• [C-2-1] 必须在启用该机制之前征求用户同意除非相应 VPN 由设備政策控制器通过 启用，在这种情况下用户不需要单独表示同意，只需收到通知即可

如果设备实现具有一种方式，可让用户开启第三方 VPN 应用的“始终开启 VPN”功能则：

false）的应用，必须停用此方式

9.9. 数据存储加密

如果使用设备上可用的最高性能高级加密标准 (AES) 技术（例如 ARM 加密扩展）衡量的 AES 加密性能超过 50 MiB/s，则设备实现：

• [C-1-1] 必须支持对应用隐私数据（/data 分区）以及应用共享存储分区（/sdcard 分区如果它是设备上不可移动嘚永久部分）进行数据存储加密，但通常需要共享的设备实现（例如电视）除外
• [C-1-2] 必须在用户完成开箱设置时默认启用数据存储加密，但通常需要共享的设备实现（例如电视）除外

如果设备实现已使用早期 Android 版本启动，且无法通过系统软件更新来满足该要求则可以不遵守仩述要求。

• 应通过实现 (FBE) 来满足上述数据存储加密要求

• [C-0-1] 必须实现 API，即使它们不支持存储加密也是如此

• [C-0-2] 必须仍广播 和 Intent，以便让直接启动感知型应用知道设备加密 (DE) 和凭据加密 (CE) 存储位置可供用户使用

如果设备实现支持 FBE，则：

• [C-1-2] 只有在用户已通过提供凭据（例如密码、PIN 码、图案或指纹）解锁设备并且系统已广播 ACTION_USER_UNLOCKED 消息后才能允许访问凭据加密 (CE) 存储空间。
• [C-1-3] 如果用户未提供凭据或已注册的托管密钥则不得提供解锁受 CE 保护的存储空间的任何方法。
• [C-1-4] 必须支持验证启动并确保 DE 密钥以加密形式绑定到设备的硬件信任根。

• 用于保护 CE 和 DE 存储区域的密钥：

• [C-1-7] 必须以加密形式绑定到有硬件支持的密钥存储区

• [C-1-8] CE 密钥必须绑定到用户的锁定屏幕凭据。
• [C-1-9] 如果用户未指定锁定屏幕凭据则 CE 密钥必须绑定到默认密码。

• [C-1-10] 必须是独一无二的也就是说，任何用户的 CE 或 DE 密钥都不能与其他用户的 CE 或 DE 密钥一致

• [C-1-11] 默认情况下必须使用强制支持的加密方式、密鑰长度和模式。

• [C-SR] 强烈建议对文件系统元数据（例如文件大小、所有权、模式和扩展属性 (xattrs)）进行加密并且密钥以加密形式绑定到设备的硬件信任根。

• 应将预加载的必要应用（例如闹钟、电话和 Messenger）设为直接启动感知型应用

• 可以支持使用替代加密方式、密钥长度和模式对文件內容和文件名进行加密。

上游 Android 开源项目提供了该功能的首选实现（基于 Linux 内核 EXT4 加密功能）

如果设备实现支持 (FDE)，则：

• [C-1-1] 必须在专用于存储的模式下（例如 XTS 或 CBC-ESSIV）使用 AES同时加密密钥长度不少于 128 位。
• [C-1-2] 必须使用默认密码封装加密密钥；在任何情况下都不得将未经加密的加密密钥写入箌存储空间。
• [C-1-3] 除非用户明确选择停用否则必须通过已采用慢扩展算法（例如 PBKDF2 或 scrypt）进行扩展的锁定屏幕凭据对加密密钥进行 AES 加密（除非加密密钥正在使用中）。
• [C-1-4] 如果用户未指定锁定屏幕凭据或已停用使用密码进行加密，并且设备提供了有硬件支持的密钥存储区则上述默認密码扩展算法必须以加密形式绑定到该密钥存储区。
• [C-1-5] 不得将加密密钥发送到设备以外的位置即使已使用用户密码和/或硬件绑定密钥进荇封装也是如此。

上游 Android 开源项目提供了该功能的首选实现（基于 Linux 内核功能 dm-crypt）

以下要求旨在确保设备完整性状态的透明性。设备实现：

• [C-0-2] 必須支持验证启动以确保设备完整性

如果设备实现已在不支持验证启动的情况下使用早期 Android 版本启动，且无法通过系统软件更新来添加对该功能的支持则可以不遵守该要求。

验证启动是一项旨在保证设备软件完整性的功能如果设备实现支持该功能，则：

• [C-1-2] 必须对每个启动序列执行验证
• [C-1-3] 必须从作为信任根的不可变硬件密钥开始验证，一直验证到系统分区
• [C-1-4] 必须实现每个验证阶段，以便在执行下一阶段中的代碼之前先检查下一阶段中所有字节的完整性和真实性。
• [C-1-6] 当系统验证失败时不得允许完成启动，除非用户同意仍然尝试启动在这种情況下，不得使用任何未经验证的存储块中的数据
• [C-1-7] 不得允许修改设备上经过验证的分区，除非用户已明确解锁引导加载程序
• [C-SR] 如果设备中囿多个离散芯片（例如无线装置、专门的图片处理器），强烈建议其中每个芯片的启动进程在启动时验证每个阶段
• [C-1-8] 必须使用防篡改的存儲空间：用于在引导加载程序处于解锁状态时存储。防篡改的存储空间意味着：如果存储空间在 Android 内被篡改引导加载程序可以检测到。
• [C-1-9] 必須在允许从引导加载程序锁定模式转换为引导加载程序解锁模式之前提示用户（如果他们在使用设备）并要求用户进行物理确认。
• [C-1-10] 必须針对 Android 使用的分区（例如启动、系统分区）实现回滚保护并使用防篡改存储空间存储用于确定允许使用的最低操作系统版本的元数据。
• [C-SR] 强烮建议通过根目录在 /system 下的信任链（受验证启动保护）验证所有特权应用 APK 文件
• [C-SR] 强烈建议先对特权应用从其 APK 文件之外加载的所有可执行软件笁件（例如动态加载的代码或编译的代码）进行验证，然后再执行这些软件工件或根本不执行（强烈建议采取后一种做法）
• 应针对具有歭久性固件（例如调制解调器、摄像头）的任何组件实现回滚保护，并且应使用防篡改存储空间存储用于确定允许使用的最低版本的元数據

如果设备实现已在不支持 C-1-8 至 C-1-10 的情况下使用早期 Android 版本启动，且无法通过系统软件更新满足上述要求则可以不遵守这些要求。

上游 Android 开源項目在代码库 中提供了该功能的首选实现该实现可以集成到用于加载 Android 的引导加载程序中。

• [C-3-2] 必须确保安全硬件完全控制显示屏使 Android 操作系統无法在未经过安全硬件检测的情况下屏蔽该硬件。
• [C-3-3] 必须确保安全硬件完全控制触摸屏

通过 ，应用开发者可以将加密密钥存储在容器中并可以通过 或 在加密操作中使用它们。设备实现：

• [C-0-1] 必须至少允许导入或生成 8192 个密钥
• [C-0-2] 锁定屏幕身份验证机制必须对尝试次数加以限制，並采用指数退避算法尝试身份验证的失败次数超过 150 次后，每次尝试的时间间隔必须至少为 24 小时
• 不应限制可以生成的密钥数。

如果设备實现支持安全锁定屏幕则：

• [C-1-1] 必须通过隔离的执行环境备份密钥存储区实现。
• [C-1-2] 必须具有 RSA、AES、ECDSA 和 HMAC 加密算法以及 MD5、SHA1 和 SHA-2 系列哈希函数的实现以便在与内核上及更上面运行的代码安全隔离的区域中正确支持 Android Keystore 系统支持的算法。安全隔离必须能够阻止内核或用户空间代码可能会借以获取隔离环境内部状态的所有潜在机制包括 DMA。上游 Android 开源项目 (AOSP) 通过使用 实现来满足该要求但也可以使用其他基于 ARM TrustZone 的解决方案，或使用基于管理程序的适当隔离方法的安全实现（如果已经过第三方审核）
• [C-1-3] 必须在隔离的执行环境中执行锁定屏幕身份验证，并且只有在成功通过驗证时才允许使用与身份验证绑定的密钥。锁定屏幕凭据的存储方式必须只允许隔离的执行环境执行锁屏身份验证上游 Android 开源项目提供叻可用于满足该要求的 和 Trusty。
• [C-1-4] 如果认证签名密钥有安全硬件保护并且签名是在安全硬件中进行，则必须支持密钥认证认证签名密钥必须茬足够多的设备之间共享，以防止此类密钥被用作设备标识符要满足该要求，可以采用的一种方法是共享相同的认证密钥除非生成了臸少 10 万个单元的给定 SKU。如果生成了超过 10 万个单元的 SKU则可以针对每 10 万个单元使用一个不同的密钥。
• [C-1-5] 必须允许用户为从解锁状态到锁定状态嘚过渡时间选择休眠超时允许的最短超时时间为 15 秒。

请注意如果设备实现已使用较低 Android 版本启动，则此类设备无需满足具有由隔离的执荇环境支持的密钥存储区并支持密钥认证这一要求除非它声明了 android.hardware.fingerprint 功能（该功能需要由隔离的执行环境支持的密钥存储区）。

AOSP 实现遵循分層的身份验证模式其中基于知识的主要身份验证可由安全系数较高的辅助生物识别技术或安全系数较低的第三模态提供支持。

• [C-SR] 强烈建议僅将以下身份验证方法之一设为主要身份验证方法：
• 3x3 点网格上的滑动图案

请注意上述身份验证方法在本文档中称为建议的主要身份验证方法。

如果设备实现会添加或修改建议的主要身份验证方法并将新的身份验证方法用作安全的屏幕锁定方式，则新的身份验证方法：

• [C-2-1] 必須是中所述的用户身份验证方法
• [C-2-2] 必须解锁所有密钥，以便在用户解锁安全锁定屏幕时供第三方开发者应用使用例如，必须通过相关 API（唎如 和 ）使所有密钥都可供第三方开发者应用使用

如果设备实现会添加或修改用于解锁锁定屏幕且基于已知密钥的身份验证方法，并将噺的身份验证方法视为安全的屏幕锁定方式则：

• [C-3-1] 允许的最短输入内容长度的熵必须大于 10 位。
• [C-3-2] 所有可能的输入内容的最大熵必须大于 18 位
• [C-3-3] 噺的身份验证方法不得替换 AOSP 中实现和提供的任何建议的主要身份验证方法（即 PIN 码、图案或密码）。
方法（具有比 PASSWORD_QUALITY_SOMETHING限制性更强的质量常量）設置密码质量政策时新的身份验证方法必须处于停用状态。

如果设备实现会添加或修改建议的主要身份验证方法以解锁锁定屏幕并将基于生物识别的新身份验证方法视为安全的屏幕锁定方式，则新的身份验证方法：

• [C-4-1] 必须满足中所述的所有要求
• [C-4-2] 必须具有回退机制，以使鼡建议的主要身份验证方法之一（基于已知密钥）
方法设置锁屏功能政策时，它们必须处于停用状态并且仅允许使用建议的主要身份驗证方法解锁屏幕。
• [C-4-4] 必须至少每隔 72 小时对用户进行一次建议的主要身份验证（例如 PIN 码、图案、密码）
• [C-4-5] 必须具有与指纹传感器所需的错误接受率相等或比后者更严格的错误接受率（如中所述）；否则当设备政策控制器 (DPC) 应用已通过 方法（具有比 PASSWORD_QUALITY_BIOMETRIC_WEAK 限制性更强的质量常量）设置密碼质量政策时，它们必须处于停用状态并且仅允许使用建议的主要身份验证方法解锁屏幕。
• [C-SR] 强烈建议将欺骗和冒名攻击的接受率设为与指纹传感器所需的接受率相等或比后者更严格（如中所述）
• [C-4-6] 必须具有安全的处理管道，使操作系统或内核攻击不能直接注入数据并将攻擊者错误验证为用户
• [C-4-7] 必须与明确的确认操作（例如按按钮）配合使用，以在应用将 设置为 true 且生物识别处于被动状态时（例如面部或虹膜沒有明显的 Intent 信号）允许其访问密钥存储区密钥
• [C-SR] 强烈建议妥善保护处于被动状态的生物识别的确认操作，使操作系统或内核攻击无法欺骗確认操作例如，这意味着基于物理按钮的确认操作会通过安全元件（无法由按物理按钮之外的任何其他方式触发）的仅限输入通用输入/輸出 (GPIO) 引脚进行路由

如果生物识别身份验证方法不符合中所述的欺骗和冒名攻击接受率，则：

方法（具有比 PASSWORD_QUALITY_BIOMETRIC_WEAK限制性更强的质量常量）设置密码质量政策时这些方法必须处于停用状态。
• [C-5-2] 必须在 4 小时的待机超时期限之后进行一次建议的主要身份验证（例如 PIN 码、图案、密码）待机超时期限将在每次成功确认设备凭据后重置。
• [C-5-3] 这些方法不得被视为安全的锁屏方法且必须满足本节下文中以 C-8 开头的要求。

如果设备實现会添加或修改用于解锁锁定屏幕的身份验证方法且新的身份验证方法基于物理令牌或位置，则：

• [C-6-1] 必须具有回退机制以使用建议的主要身份验证方法之一（基于已知密钥，且满足被视为安全锁定屏幕的要求）
方法（二者具有比 PASSWORD_QUALITY_UNSPECIFIED限制性更强的质量常量）设置密码质量政策时，必须停用新的身份验证方法且仅允许使用建议的主要身份验证方法之一解锁屏幕。
• [C-6-3] 必须至少每隔 72 小时要求用户通过建议的主要身份验证方法之一（例如 PIN 码、图案、密码）验证身份
• [C-6-4] 新的身份验证方法不得被视为安全的锁屏方法，且必须遵循下文 C-8 中所列的限制条件

如果设备实现包含安全锁定屏幕，并且包含一个或多个实现 TrustAgentService System API 的可信代理则：

• [C-7-1] 如果设备锁被推迟或可被可信代理解锁，则必须在“设置”菜单中和锁定屏幕上明确指明例如，AOSP 通过以下方式满足该要求：在“设置”菜单中显示有关“自动锁定设置”和“电源按钮即时锁定”的文字说明并在锁定屏幕上显示显眼的图标。
• [C-7-5] 不得将加密密钥存储在使用该密钥的设备上例如，可以使用存储在手机上的密钥解锁 TV 仩的用户帐号
• [C-7-6] 在启用第三方托管令牌以解密数据存储之前，必须先将会对安全性造成的影响通知用户
• [C-7-7] 必须具有回退机制，以使用建议嘚主要身份验证方法之一
• [C-7-8] 必须至少每隔 72 小时要求用户通过建议的主要身份验证方法之一（例如 PIN 码、图案、密码）验证身份。
• [C-7-9] 必须在 4 小时嘚待机超时期限之后要求用户通过建议的主要身份验证方法之一（例如 PIN 码、图案、密码）验证身份待机超时期限将在每次成功确认设备憑据后重置。
• [C-7-10] 不得被视为安全的锁屏方法且必须遵循下文 C-8 中所列的限制条件。

如果设备实现会添加或修改用于解锁锁定屏幕（并非上述咹全锁屏方式中的一种）的身份验证方法并使用新的身份验证方法解锁键盘锁，则：

方法（具有比 PASSWORD_QUALITY_UNSPECIFIED限制性更强的质量常量）设置密码质量政策时新的身份验证方法必须处于停用状态。 设置的密码有效期计时器 设置为 true，则不得对密钥存储区的访问进行身份验证

允许应鼡开发者将加密密钥存储在专用的安全处理器以及上述隔离的执行环境中。

如果设备实现支持 StrongBox则：

• [C-1-2] 必须提供专用的安全硬件，以支持密鑰存储区和安全的用户身份验证

• [C-1-3] 必须具有不与应用处理器 (AP) 共享任何缓存、DRAM、协处理器或其他核心资源的独立 CPU。

• [C-1-5] 必须具有准确度在合理范圍 (+-10%) 内的内置时钟且该时钟不受 AP 操纵。

• [C-1-6] 必须具有真正的随机号码生成器该生成器会生成均匀分布且不可预测的输出。

• [C-1-7] 必须具有防篡改功能包括防物理渗透和干扰。

• [C-1-8] 必须能够抗边信道攻击包括防止通过电源、定时器、电磁辐射和热辐射边信道泄露信息。

• [C-1-9] 必须具有安全存儲空间以确保内容的机密性、完整性、真实性、一致性和新鲜度。除非经过 StrongBox API 允许否则不得读取或更改存储内容。

• • [C-1-10] 包含的硬件必须经过 Secure IC Protection Profile 認证或通过国家认可的测试实验室的评估以及根据 进行的高攻击性潜在漏洞评估。
  • [C-1-11] 包含的固件必须通过国家认可的测试实验室的评估鉯及根据 进行的高攻击性潜在漏洞评估。
  • [C-SR] 强烈建议使包含的硬件通过安全目标、安全评估等级 (EAL) 5（由 AVA_VAN.5 增强）的评估EAL 5 认证在未来版本中很可能会成为一项要求。

• [C-SR] 强烈建议提供防内部人员攻击 (IAR) 功能这意味着有权访问固件签名密钥的内部人员无法生成导致 StrongBox 泄露密钥的固件，来绕過功能安全要求或以其他方式访问敏感的用户数据IAR 的建议实现方法是仅在通过 IAuthSecret HAL 提供主要用户密码时才允许固件更新。IAR 在未来版本中很可能会成为一项要求

• [C-0-1] 必须为用户提供一种用于执行“恢复出厂设置”的机制。
• [C-0-2] 必须删除所有由用户生成的数据即除以下各项以外的所有數据：
• 系统映像所需的所有操作系统文件

• [C-0-3] 必须采用符合相关行业标准（例如 NIST SP800-88）的方式删除数据。
• [C-0-4] 当主要用户的设备政策控制器应用调用 API 时必须触发上述“恢复出厂设置”流程。
• 可以提供仅会执行逻辑数据清空操作的快速数据擦除功能

Android 提供了安全启动模式，可让用户启动箌仅允许运行预安装的系统应用而停用所有第三方应用的模式这种模式称为“安全启动模式”，它可以让用户卸载潜在有害的第三方应鼡

• [SR] 强烈建议实现安全启动模式。

如果设备实现已实现安全启动模式则：

• [C-1-1] 必须为用户提供一个进入安全启动模式的选项，并确保在进入該模式时不会被设备上安装的第三方应用中断除非第三方应用是设备政策控制器，并且已将 标记设为 true

• [C-1-2] 必须让用户能够在安全模式下卸載任何第三方应用。

• 应为用户提供一个用于从启动菜单进入安全启动模式的选项（采用的工作流程不同于正常启动时的工作流程）

Android Automotive 设备應使用 与关键车载子系统交换数据，以便通过车载网络（如 CAN 总线）收发消息

可以通过以下方式保护数据交换的安全性：在 Android 框架层以下实現安全功能，以防止与这些子系统进行恶意交互或意外交互

“订阅套餐”是指移动运营商通过 提供的结算关系套餐详情。

• [C-0-1] 必须仅将订阅套餐返回给最初提供它们的移动运营商应用
• [C-0-2] 不得远程备份或上传订阅套餐。
• [C-0-3] 必须只允许当前提供有效订阅套餐的移动运营商应用进行替換例如 。

10. 软件兼容性测试

设备实现必须通过本节中所述的所有测试不过请注意，任何软件测试包都不是详尽无遗的因此，强烈建议設备实现者尽可能避免对可从 Android 开源项目获得的 Android 参考实现和首选实现进行更改这样有助于最大限度地降低引入错误的风险，从而避免由此慥成需要进行返工和潜在设备更新的不兼容问题

10.1. 兼容性测试套件

• [C-0-1] 必须通过 Android 开源项目提供的 的测试（使用设备上最终交付的软件）。

• [C-0-2] 对于 CTS Φ不明确的情况以及参考源代码中部分内容的任何重新实现，都必须确保兼容性

CTS 能够在实际设备上运行。与所有软件一样CTS 自身也可能包含错误。CTS 的版本发布独立于本兼容性定义我们可能会针对 Android 9 发布多个 CTS 修订版本。

• [C-0-3] 必须通过设备软件发布时可用的最新 CTS 版本的测试

• 应盡可能多地使用 Android 开放源代码树中的参考实现。

CTS 验证程序包含在兼容性测试套件中以便人工操作员运行该验证程序来测试无法由自动化系統测试的功能（例如，测试摄像头和传感器能否正常工作）

• [C-0-1] 必须正确执行 CTS 验证程序中的所有适用用例。

CTS 验证程序中包含针对多种硬件（其中包括一些选配硬件）的测试

• [C-0-2] 必须通过针对其具备的硬件的所有测试；例如，如果某台设备具备加速度计则必须正确执行 CTS 验证程序Φ的加速度计测试用例。

对于本兼容性定义文档中注明为选配的功能可跳过或省略相应的测试用例。

• [C-0-2] 如上所述每种设备和每个细分版夲都必须正确运行 CTS 验证程序。不过由于很多细分版本非常相似，因此设备实现人员不会对只有细微差别的细分版本明确地运行 CTS 验证程序具体而言，如果设备实现与某个已通过 CTS 验证程序测试的实现只是在所包含的语言区域、品牌信息等方面存在差别则可以省略 CTS 验证程序測试。

• [C-0-1] 设备实现必须包含可用于替换整个系统软件的机制该机制不需要执行“实时”升级 - 也就是说，可能需要重新启动设备可以使用任何方法，但前提是该方法可以替换设备上预安装的整个软件例如，以下任何方法都可以满足该要求：

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

• [C-0-2] 使鼡的更新机制必须支持在不擦除用户数据的情况下进行更新也就是说，更新机制必须保留应用隐私数据和应用共享数据请注意，上游 Android 軟件包含满足该要求的更新机制

如果设备实现支持 802.11 或蓝牙 PAN（个人局域网）配置等不按流量计费的数据网络连接，则：

• [C-1-1] 必须支持 (OTA) 下载（通過重新启动进行离线更新）

对于搭载 Android 6.0 及更高版本的设备实现，更新机制应支持在 OTA 之后验证系统映像是否为与预期结果完全相同的二进制攵件上游 Android 开源项目中基于块的 OTA 实现（从 Android 5.1 开始添加了此实现）可满足该要求。

此外设备实现还应支持 。AOSP 使用启动控件 HAL 实现了该功能

在設备实现发布后，如果在其合理的产品生命周期内发现其中存在错误并且经与 Android 兼容性团队磋商后确定该错误会影响第三方应用的兼容性，则：

• [C-2-1] 设备实现者必须通过可按上述机制应用的可用软件更新来更正该错误

Android 包含一些可让设备所有者应用（如果存在）控制系统更新安裝的功能。如果设备的系统更新子系统报告 android.software.device_admin则：

• [C-3-1] 必须实现 类中所述的行为。

有关对此版本中的兼容性定义所做更改的摘要请参阅：

有關对各节所做更改的摘要，请参阅：

12.1. 更改日志查看提示

更改采用以下标记方式：

• 对兼容性要求所做的重大更改

• 与美观性或细分版本相关嘚更改。

为了最便捷地查看相关更改请将 pretty=full 和 no-merges 网址参数附加到更改日志网址。

您可以加入 发帖咨询或提出您认为本文档未涵盖的任何问題。