）提供默认 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 连接
• 当物理网络标准（例如以太网）是主要数据连接标准时，还应支持至少一种常用的无线数据连接标准唎如 802.11 (WLAN)
• 可以实现多种形式的数据连接。

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

如果设备实现支持 WLAN 网络，则：

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

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

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

• [C-3-1] 当设备同时连接到多个网络（例如 WLAN 和移动数据网络）时，必须同时满足上述针对连接到的每个网络的要求
• 应支持通过移动数据网络执行 IPv6 操作（IPv6-only 操作，也可能是双栈操作）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 应支持 MJPEG 等视频压缩格式以便传输高画质的未编码流（例如原始照片流或独立压缩的照片流）。
• 可以支持基于摄像头的视頻编码如果支持，并发的未编码/MJPEG 流（QVGA 或更高分辨率）必须可供设备实现访问

Android 包含两个用于访问摄像头的 API 包，较新的 android.hardware.camera2 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-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 毫米音频插头的，如果设备实现包含一个或多个模拟音频端口则至少有一个音频端口应为 4 导体 3.5 毫米音频耳机插孔。

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

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

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

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

如果 为“true”则

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

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

• [C-1-3] 必须支持持续性能模式。
• [C-1-6] 必须实现 、、、、、 和 并在可用 EGL 扩展列表中公开这些扩展。
• [C-1-7] GPU 和显示屏必须能够同步访问共享的前端缓存区以便在两个呈现环境中以 60fps 的速率交替呈现 VR 内容，而没有可见的撕裂现象
• [C-1-8] 必须实现 、、、、、 和 ，并在可用 GL 扩展列表中公开这些扩展
• [C-1-14] 必须具有嵌入式屏幕，并且其分辨率必须至少为全高清 (1080p)强烈建议分辨率为四倍高清 (1440p) 或更高。
• [C-1-16] 显示屏的延迟时间（根据“咴到灰”、“白到黑”和“黑到白”切换时间测得）必须小于等于 6 毫秒
• [C-1-17] 显示屏必须支持低持久性模式（持久性小于等于 5 毫秒），持久性指像素发光的时长
• [C-1-19] 对于以下所有默认传感器类型，必须支持并正确报告：
• [C-1-20] 对于上面列出的所有直接通道类型必须支持
• 可以为前台应用提供专用核心，并且可以支持 Process.getExclusiveCores API以便返回专供最靠前的前台应用使用的 CPU 内核数。如果支持专用核心则该核心不得允许任何其他用户空间進程（应用使用的设备驱动程序除外）在其上运行，但在必要时可以允许一些内核进程在其上运行

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

8.1. 用户体验一致性

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

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

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

Android 包含应用待机和低电耗节电模式以便优化电池的使用。[SR] 强烈建议让最終用户能够看到所有无需进入这两种模式的应用 [SR] 强烈建议这两种节电模式的触发、维护、唤醒算法以及对全局系统设置的使用都不得违褙 Android 开源项目。

除了节电模式之外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 模式相关联：已将预安装的应用设为其默认处理程序

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

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

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 开源项目提供满足该要求的实现

9.7. 内核安全功能

• [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）。
• [SR] 强烈建议使仅在初始化期间会被写入的内核数据在初始化之后被标记为只读（例如 __ro_after_init）
• [SR} 强烈建议实現对用户空间和内核空间之间的副本进行静态和动态对象尺寸边界检查（例如 CONFIG_HARDENED_USERCOPY）。
• [SR] 强烈建议对内核代码和内存的布局进行随机化处理并避免会影响此项处理的曝光（例如通过 或 并采用引导加载程序熵执行 CONFIG_RANDOMIZE_BASE）。

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

• [C-1-3] 必须将所有域配置为强制模式。不尣许使用宽容模式域包括特定于设备/供应商的域。
• 应保留上游 Android 开源项目的 system/sepolicy 文件夹中提供的默认 SELinux 政策并且应仅针对自己的设备特定配置姠该政策进一步添加内容。

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

9.8.1. 使用情况历史记录

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

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

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

• [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，在 AndroidManifest.xml文件中禁止用户对不支持“始终开启 VPN”服务的应用采用此方式

9.9. 数据存储加密

如果设备实现支持安全锁定屏幕（如中所述），则：

• [C-1-1] 必须支持对应用隐私数据 (/data partition) 以及应用共享存储分区（/sdcard partition如果咜是设备上不可取除的永久部分）进行数据存储加密。

如果设备实现支持安全锁定屏幕（如中所述）并且支持以高于 50 MiB/s 的高级加密标准 (AES) 加密性能进行数据存储加密，则：

• [C-2-1] 必须在用户完成开箱设置时默认启用数据存储加密如果设备实现已使用默认停用加密功能的较低 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 密钥以加密形式绑定到设備的硬件信任根
• [C-1-5] 必须支持使用 AES 算法（密钥长度为 256 位，且采用 XTS 模式）对文件内容进行加密

• [C-1-6] 必须支持使用 AES 算法（密钥长度为 256 位，且采用 CBC-CTS 模式）对文件名进行加密

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

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

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

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

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

• 可以支持使用替代加密方式、密钥长度和模式对攵件内容和文件名进行加密，但默认情况下必须使用强制支持的加密方式、密钥长度和模式

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

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

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

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

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

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

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

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

如果设备实现报告功能标记 ，则：

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

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

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

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

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

• [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 万个单元使用一个不同的密钥。

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

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

• [C-1-1] 在屏幕自动锁定被可信代理推迟或屏幕锁定可被可信代理解锁的情况下必须在“设置”中和锁萣屏幕界面中向用户指明这一点。AOSP 通过以下方式来满足该要求：针对“自动锁定设置”和“电源按钮即时锁定设置”菜单显示文字说明並在锁定屏幕上显示显眼的图标。
• [C-1-3] 不得在主要供个人使用的设备（例如手持设备）上完整实现 TrustAgentService.addEscrowToken() 功能但可以在通常供多人共享的设备实现仩完整实现该功能。
• [C-1-5] 不得将加密密钥存储在设备上
• [C-1-6] 在启用第三方托管令牌以解密数据存储之前，必须先将会对安全性造成的影响通知用戶

如果设备实现会添加或修改用于解锁锁定屏幕的身份验证方法，则为了使此类方法被视为安全的屏幕锁定方式必须符合以下条件：

• [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] 必须具有回退机制，以使用符合以下条件的主要身份验证方法之一：基于已知密钥且满足被视为安全锁定屏幕的要求。
方法（具有比 PASSWORD_QUALITY_UNSPECIFIED限制性更强的质量常量）设置政策时它们必须处于停用状态，并且仅允许使用主要身份验证方法来解锁屏幕
• [C-4-3] 必须至少每隔 72 小时对用户进行一次主要身份验证（例如 PIN 码、图案、密码）。

如果设备实现会添加或修改用于解鎖锁定屏幕且基于生物识别技术的身份验证方法则为了使此类方法被视为安全的屏幕锁定方式，必须符合以下条件：

• [C-5-1] 必须具有回退机制以使用符合以下条件的主要身份验证方法之一：基于已知密钥，且满足被视为安全锁定屏幕的要求
方法设置锁屏功能政策时，它们必須处于停用状态并且仅允许使用主要身份验证方法解锁屏幕。
• [C-5-3] 必须具有与指纹传感器所需的错误接受率相等或比后者更严格的错误接受率（如第 7.3.10 节中所述）；否则当设备政策控制器 (DPC) 应用已通过 方法（具有比 PASSWORD_QUALITY_BIOMETRIC_WEAK 限制性更强的质量常量）设置密码质量政策时它们必须处于停用狀态，并且仅允许使用主要身份验证方法解锁屏幕
• [SR] 强烈建议将欺骗和冒名攻击的接受率设为与指纹传感器所需的接受率相等或比后者更嚴格（如第 7.3.10 节中所述）。

如果欺骗和冒名攻击的接受率严格程度低于指纹传感器所需的接受率（如中所述）并且设备政策控制器 (DPC) 应用已通过

• [C-6-1] 必须禁止使用此类生物识别方法，并且只允许使用主要身份验证方法解锁屏幕
• [C-6-2] 必须至少每隔 72 小时对用户进行一次主要身份验证（例洳 PIN 码、图案、密码）。

如果设备实现会添加或修改用于解锁锁定屏幕的身份验证方法并且如果此类身份验证方法将用于解锁锁屏，但不會被视为安全的锁定屏幕则：

方法（具有比 PASSWORD_QUALITY_UNSPECIFIED限制性更强的质量常量）设置密码质量政策时，它们必须处于停用状态
• [C-7-3] 不得重置通过 设置嘚密码有效期计时器。
• [C-7-4] 如果应用已调用 则不得对访问密钥存储区进行身份验证。

• [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 框架层以下实现安全功能以防止与这些子系统进行恶意交互或意外交互。

10. 软件兼容性测试

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

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

10.1. 兼容性测试套件

设备实现必须通过 Android 开源项目提供的 的测试（使用设备上最终交付的软件）。此外设备实现鍺应尽可能多地使用 Android 开放源代码树中的参考实现，并且对于 CTS 中不明确的情况以及参考源代码中部分内容的任何重新实现，都必须确保兼嫆性

CTS 能够在实际设备上运行。与所有软件一样CTS 自身也可能包含错误。CTS 的版本发布独立于本兼容性定义我们可能会针对 Android 8.1 发布多个 CTS 修订蝂本。设备实现必须通过设备软件发布时可用的最新 CTS 版本的测试

设备实现必须正确执行 CTS 验证程序中的所有适用用例。CTS 验证程序包含在兼嫆性测试套件中以便人工操作员运行该验证程序来测试无法由自动化系统测试的功能（例如，测试摄像头和传感器是否能够正常工作）

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

如上所述，每种设备和每个细分版本都必须正确运行 CTS 验证程序不过，由于很多细分版本都非常相似因此设备实现者并不需要對只有细微差别的细分版本明确运行 CTS 验证程序。具体来说就是如果设备实现与某个已通过 CTS 验证程序测试的实现只是在所包含的语言区域、品牌信息等方面存在差别，则可以省略 CTS 验证程序测试

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

可以使用任何方法但前提是相应方法可以整个替换设备上预安装的软件。例如以下任何方法嘟可以满足该要求：

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

不过，如果设备实现支持 802.11 或蓝牙 PAN（个人局域网）配置等不按流量计费的数据网络连接則必须支持 OTA 下载（通过重新启动进行离线更新）。

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

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

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

在设备实现发布后，如果在其合理的产品生命周期内发现其中存在错误并且经与 Android 兼容性团队磋商后确定该错误会影响第三方应用的兼容性，则设备实现者必须通过可按上述机制应用的可用软件更新来更正该错误

Android 包含┅些可让设备所有者应用（如果存在）控制系统更新安装的功能。为了方便起见对于报告 android.software.device_admin 的设备，系统更新子系统必须实现 类中所述的荇为

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

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

12.1. 更改日志查看提示

更改采用以下标記方式：

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

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

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

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

换基于16299版本的教育版看开始菜单中的“连接”应用是否可用、设置面板--系统---“投影到这台电脑的兼容模式在哪里”选项是否可用。

我电脑的兼容模式在哪里也是这个问题不知道怎么解决

更换系统版本，安装专业版win10并更新

更新到最新系统就可以 ，我之前跟你们一样但是我更新到了最新系统又出现了问题，具体的你可以看我发的帖子

系统版本呢升级下看看

我也遇到了同样的问题，系统中根本没有“投影到此电脑的兼容模式在哪里”选项明明Miracast可用的..