自 2025 年 3 月 27 日起，我们建议您使用 android-latest-release 而非 aosp-main 构建 AOSP 并为其做出贡献。如需了解详情，请参阅 AOSP 的变更。

Microdroid

Microdroid 是在 pVM 中运行的迷你版 Android OS。您可以启动运行任何操作系统的虚拟机，并非必须使用 Microdroid。但是，pVM 的主要用例不是运行独立的操作系统，而是提供一个隔离的执行环境，以比常规 Android 环境更高的机密性和完整性运行应用的某一部分。

在传统操作系统中，要想提供强大的机密性和完整性保护，就必须进行大量的工作（而且通常是重复性的工作）。这是因为传统操作系统无法与整体 Android 架构保持良好兼容。例如，就标准 Android 架构而言，开发者需要实现一种方法，以便在 pVM 中安全地加载和执行应用的某个部分，同时也需要依据 glibc 来构建载荷。但是，Android 应用需要使用 Bionic，通信需要使用基于 vsock 的自定义协议，而调试则需要使用 adb 且颇具难度。

Microdroid 可以轻松弥合这些差异。它提供了一个精心设计的现成操作系统映像，让开发者能以最省力的方式把应用的某个部分分流到 pVM 中。Microdroid 的原生代码基于 Bionic，通信则是通过 Binder 来实现。它支持从主机 Android 导入 APEX，并且公开了一部分 Android API，例如在使用由硬件支持的密钥进行加密操作时需要用到的密钥库。总而言之，Microdroid 为开发者提供了一个熟悉的环境，其中包含他们早已熟知的完整版 Android OS 中的各种工具。

功能

Microdroid 是 Android 的精简版本，并且添加了一些专门面向 pVM 的组件。Microdroid 支持以下功能：

一部分 NDK API（Android 用于实现 libc 和 Bionic 的所有 API 均包括在内）
调试功能，例如 adb、logcat、tombstone 和 gdb
启动时验证和 SELinux
加载和执行二进制文件以及 APK 中嵌入的共享库
通过 vsock 支持 Binder RPC；在交换文件时执行隐式完整性检查
加载 APEX

Microdroid 不支持以下功能：

android.\* 文件包中的 Android Java API

注意：java.\* 文件包中的 Core Java API 属于支持的功能，但需要在虚拟机中激活 ART APEX。
SystemServer 和 Zygote
图形/界面
HAL

Microdroid 架构

Microdroid 与 Cuttlefish 十分相似，二者都具有类似标准 Android 的架构。Microdroid 包含以下分区映像，这些映像在一个复合磁盘映像中进行了分组：

bootloader - 验证并启动内核。
boot.img - 包含内核和 init ramdisk。
vendor_boot.img - 包含虚拟机专用的内核模块，例如 virtio。
super.img - 包含系统和供应商逻辑分区。
vbmeta.img - 包含经过验证的启动元数据。

这些分区映像整合在一个虚拟化 APEX 中，并通过 VirtualizationService 打包成一个复合磁盘映像。VirtualizationService 不仅用于生成这个主操作系统复合磁盘映像，还负责创建下面列出的其他分区：

payload - 一组由 Android 的 APEX 和 APK 支持的分区
instance - 用于按实例持久保留启动时验证数据的加密分区，这类数据包括每个示例的 salt 值、可信的 APEX 公钥、回滚计数器等

启动序列

Microdroid 启动序列在设备启动后触发。关于设备启动的具体内容，在架构文档的“pVM 固件”部分中有详细的讨论。图 1 显示了 Microdroid 启动序列过程中的具体步骤：

Microdroid 实例的安全启动流程

图 1. Microdroid 实例的安全启动流程

以下是对这些步骤的说明：

crosvm 将引导加载程序加载到内存，pvmfw 开始执行。在跳转到引导加载程序之前，pvmfw 会执行两项任务：
- 验证引导加载程序，检查其是否来自可信来源（Google 或 OEM）。
- 确保同一 pVM 在使用同一实例映像进行多次启动的过程中，会始终如一地使用相同的引导加载程序。具体而言，pVM 最初会使用空白的实例映像进行启动。pvmfw 会存储该实例映像中的引导加载程序的身份信息，并对其进行加密。当 pVM 下次使用同一实例映像启动时，pvmfw 会解密已保存的该实例映像的身份信息，并验证当前的身份信息是否与先前保存的信息完全相同。如果身份信息不同，pvmfw 将拒绝启动。
引导加载程序启动 Microdroid。
引导加载程序访问实例磁盘。与 pvmfw 类似，引导加载程序会在一个实例磁盘中存储同一实例上次启动时使用的分区映像的相关信息，包括公钥信息。
引导加载程序验证 vbmeta 和链式分区（例如 boot 和 super）。如果验证成功，则会推导出下一阶段的 pVM Secret。然后，Microdroid 会将控制权移交给内核。
由于引导加载程序已经在第 3 步验证了 super 分区，所以内核会无条件地安装 super 分区。与完整版 Android 一样，super 分区包含了多个通过 dm-verity 安装的逻辑分区。随后，控制权将移交给 init 进程，该进程会启动各种原生服务。init.rc 脚本也与完整版 Android 中的十分相似，只不过针对 Microdroid 的需求进行了一些调整。
init 进程启动 Microdroid 管理器，该管理器会访问实例映像。Microdroid 管理器服务使用前一阶段传递的密钥解密映像，并读取该 pVM 信任的客户端 APK 和 APEX 的公钥及回滚计数器信息。这些信息稍后会在安装客户端 APK 和请求的 APEX 时，分别用于 zipfuse 和 apexd。
Microdroid 管理器服务启动 apexd。
apexd 在 /apex/<name> 目录下安装 APEX。在 APEX 的安装方式上，Android 与 Microdroid 只有一个差别：在 Microdroid 中，APEX 文件来自虚拟块设备（例如 /dev/vdc1），而非来自常规文件 (/system/apex/*.apex)。
zipfuse 是 Microdroid 的 FUSE 文件系统。zipfuse 会将客户端 APK（基本上是一个 Zip 文件）作为文件系统进行安装。在底层，pVM 会将 APK 文件作为一个虚拟块设备通过 dm-verity 进行传递，就像 APEX 一样。APK 中包含一个配置文件，其中包括了应用开发者针对该 pVM 实例请求的 APEX 的列表。在激活 APEX 时，该列表会被 apexd 使用。
启动流程返回到 Microdroid 管理器服务。然后，管理器服务会使用 Binder RPC 与 Android 的 VirtualizationService 进行通信，以便能够报告崩溃或关闭等重要事件，并接受诸如终止 pVM 之类的请求。管理器服务还会从 APK 的配置文件中读取主二进制文件的位置，并加以执行。

文件交换 (AuthFS)

Android 组件使用文件进行输入、输出和状态记录，并将这些文件作为由 Android 内核控制访问的文件描述符（AIDL 中的 ParcelFileDescriptor 类型）进行传递，是十分常见的。AuthFS 就提供了这样的功能，以便能够跨 pVM 边界在互不信任的端点之间交换文件。

基本而言，AuthFS 是一个远程文件系统，它会对每次访问操作进行透明的完整性检查，类似于 fs-verity。这些检查使前端（例如 pVM 中运行的文件读取程序）能够检测不受信任的后端（通常为 Android）是否包含经过篡改的文件内容。

要进行文件交换，后端 (fd\_server) 会在通信开始时提供每个文件的配置，以表明它是输入（只读）还是输出（读写）。如果是输入，前端会强制要求相关内容与 Merkle 树顶层的已知哈希完全匹配，以实现访问时验证。如果是输出，AuthFS 会在内部将相关内容的哈希树保存为写入操作的观察结果，并在回读数据时强制执行完整性检查。

目前，底层传输是基于 Binder RPC 进行的。但是为了优化性能，此机制今后可能会有所变化。

密钥管理

pVM 具有一个稳定的密封密钥和一个认证密钥，前者非常适合用于受保护的持久性数据，后者非常适合用于生成由 pVM 验证生成的签名。

Binder RPC

大多数 Android 接口都用 AIDL 表示，而 AIDL 是基于 Binder Linux 内核驱动程序构建的。为了在 pVM 之间提供接口支持，Binder 协议经过重写，以便能够通过套接字使用（对于 pVM，该套接字为 vsock）。通过这种方式，Android 现有的 AIDL 接口就能在 pVM 这个新环境中使用。

要设置连接，终端（例如 pVM 载荷）需要创建一个 RpcServer 对象、注册一个 root 对象，并进入监听新连接的状态。要连接到该服务器，客户端需要使用 RpcSession 对象并获取 Binder 对象，然后像在 Binder 内核驱动程序中使用 Binder 对象一样使用该对象。