Android 虚拟化框架 (AVF) 提供安全且私密的执行环境来执行代码。AVF 非常适合以安全为导向的用例，这些用例需要比 Android 应用沙盒提供的安全系数更高、甚至经过正式验证的隔离保证。Android 提供了实现 AVF 所需的所有组件的参考实现。
- apexd 和 zipfuse 安全地装载从主机导入的 APEX 和 APK。
- authfs 用于确保在 Android 和 pVM（主机和客户机）之间共享多个文件时的安全性的融合文件系统。
- binder 虚拟机间通信的主要方式。
- crossvm 一个以 Rust 编写的虚拟机监视器。crossvm 分配虚拟机内存、创建虚拟 CPU 线程，以及实现虚拟设备的后端。
- 通用内核映像 (GKI) 经过 Google 认证的启动映像，其中包含基于 Android 通用内核 (ACK) 源代码树构建的 GKI 内核，适合刷写到 Android 设备的启动分区。如需了解详情，请参阅内核概览。
- Hypervisor AVF 使用的虚拟化技术，也称为 pKVM。即使 Android 或任何其他 pVM 遭到破解，Hypervisor 也会保持已执行代码的完整性和 pVM 资源的机密性。
- Java API
VirtualizationService Java API，仅存在于支持 AVF 的设备上。这些 API 是可选的，不属于
thebootclasspath。 - Microdroid Google 提供的在 pVM 中运行的迷你版 Android OS。
- Microdroid 管理器 管理 pVM 内的 pVM 生命周期，以及实例磁盘。
- 原生 API Android 原生开发者套件 (NDK) 的一个子集。
- 基于内核的受保护虚拟机 (pKVM) 请参阅 Hypervisor。
- pVM 固件 (
pvmfw) 在 pVM 上运行的第一个代码，pvmfw会验证载荷并推导每个虚拟机的 Secret。 - 受保护的虚拟机 (pVM) 与主 Android 操作系统（“主机”）一起运行的互不信任的隔离执行环境（“客户机”）。pVM 由 pKVM 管理。 与现有的可信执行环境 (TEE) 相比，pVM 可提供更丰富的环境，包括一个名为 Microdroid 的迷你版 Android 分发平台。pVM 可以动态使用，并且提供一组标准 API 供所有支持它们的设备使用。
- VirutalizationService 管理 pVM 生命周期的 Android 服务。
为什么需要AVF
AVF 的主要目标是为下一代用例提供安全、私密的执行环境。
移动计算设备处理的个人敏感数据的数量日益增加。这类敏感数据的存在，再加上经常与外界保持联络，有意利用漏洞进一步实现其目标的恶意攻击者更是加大力度搞破坏。
操作系统借助硬件内存管理单元 (MMU) 提供抽象化功能，以便让不相关的进程彼此隔离。只有 TCB 中包含的组件才能直接对这些 MMU 进行编程。
自推出类似 Unix 的操作系统以来，该模型一直是实现隐私保护和安全机制的基础。然而，如今的 TCB 过大，上述要求已很难满足：它包含大多数设备和总线驱动程序、复杂的调度程序、文件系统、网络堆栈和协议、缓存、可执行解析器和加载器以及套接字。确保这个复杂系统的方方面面都安全变得非常困难。
Linux 内核中有超过 2000 万行代码，更改和重写的速度令人惊讶。这一发展对 Android 和我们的生态系统而言具有极大的帮助。但是，其较大的 TCB 使得确保不存在可利用的漏洞很困难。
硬件供应商开发了一些解决方案，例如 Arm 的 TrustZone。它允许处理器在安全模式下运行，并将内存事务标记为“安全”或“非安全”。在此类系统中，敏感数据会存储在安全环境中，并且仅直接提供给安全环境，这类安全环境会按需向非安全环境提供服务。
此类解决方案的主要限制是情况分类过于粗略，仅分为安全和非安全。随着越来越多需要与操作系统隔离的用例的引入，攻击面越来越多，漏洞可能导致整个设备遭受破坏。
如今的解决方案的另一个限制是，其设计主要面向相对静态的环境，其中所有用例资源都有迹可循，并且提前分配。这些解决方案对于按需分配资源的动态用例不够友好。
此外，在 Android 操作系统以外使用的 API 比较分散，限制了我们在 Android 级别部署用例的能力，包括 Keymint 和 Gatekeeper 等基础组件。
为了解决这些限制并让 Android 为下一代用例提供强大的基础，Android 13 引入了安全的虚拟化，即 Android 虚拟化框架 (AVF)。
