Meta 将 Android 虚拟设备框架 Cuttlefish 移植到 Apple Silicon Mac

Meta 的 Reality Labs 负责构建 AI 眼镜等产品。模拟器让我们无需依赖稀缺的物理硬件，也能规模化地进行开发和测试。

针对非手机类 Android 设备的软件测试，其效果取决于虚拟设备能在多大程度上复现物理产品的软件行为。像 Goldfish 这样的轻量级模拟器能解决一部分问题，但它与真实设备的差异可能会把 bug 隐藏到开发后期才暴露。这种保真度的不足也会削弱人们对设备模拟的信任，从而更加依赖稀缺的物理硬件。

Cuttlefish 是 Android 开源项目（AOSP）的虚拟设备框架，用于在虚拟硬件上测试 Android 软件。它启动的系统镜像与真实硬件相同，并在虚拟硬件上运行逼真的软件栈。因此，相比轻量级模拟器，Cuttlefish 能更紧密地跟踪物理设备的行为。

遗憾的是，Cuttlefish 仅支持 Linux，而我们的应用和库开发者使用的是搭载 Apple 芯片的 Mac。这迫使我们同时支持 Goldfish 和 Cuttlefish。

我们知道，如果能整合到单一的基于 Cuttlefish 的平台，就能让所有开发者都受益于同一个高保真虚拟设备。挑战在于移植整个技术栈，让 Cuttlefish 在 macOS 上原生运行。

维护两套模拟器平台带来了沉重的运维负担：它消耗计算资源、让开发者感到困惑，也拖慢了模拟器团队。每个工具都需要支持两个独立平台，基础设施和工程能力也被一分为二。此外，开发者还必须根据自己的工作方式选择模拟器目标：Goldfish 到处都能运行，但保真度较低；Cuttlefish 则需要 Linux。

AOSP 也反映了这种完全相同的分野：Goldfish 面向应用开发者，而 Cuttlefish 服务于 Android 平台开发者。只要维持这种分割，我们就会承受碎片化带来的后果。

Cuttlefish 是编排层，而真正运行客户机操作系统的组件是虚拟机监视器（VMM）。在 Linux 上，Cuttlefish 通常使用 crosvm，但以前也包含对 QEMU 作为替代 VMM 的支持。随着时间推移，那套集成已经不再活跃。为了在 macOS 上实现原生 Apple 芯片支持，我们重新启用了 QEMU 支持。

Cuttlefish 的许多虚拟设备使用 vhost-user 后端，这些独立进程通过 socket 向 QEMU 提供 virtio 设备。这种架构很清晰，但其中很大一部分是按照 Linux 的硬性假设编写的。其中三个假设在 macOS 上不成立。vhost-user 机制被限定在 Linux 上，无法构建或运行。Apple hypervisor 施加了 QEMU 未曾预料到的资源限制。最后，原生显示、构建和签名路径都不存在。我们逐一解决了这三个问题。

结构上最重要的改动在 QEMU 的 vhost-user 路径中。前端、libvhost-user 以及 vhost-user-blk 等 contrib 后端此前都被限定在 Linux 上。我们放宽了这些构建限制，使 vhost-user 前端和库既能在 Linux 上构建，也能在 macOS 上构建。这样一来，Cuttlefish 的设备后端在 Mac 上就能像在 Linux 上一样移交给 QEMU。没有这一点，让 Cuttlefish 值得使用的高保真设备模型就无法在 Linux 之外使用。

在 Apple 芯片上，QEMU 通过 HVF（Hypervisor.framework）而不是 KVM 来加速。QEMU 的 HVF 后端未能跟踪足够多的内存区域，无法支持更大的 Cuttlefish 配置。我们增加了其跟踪槽位数量，使这些配置能够正确运行。

本地应用开发需要交互式显示，让开发者能够查看虚拟设备并直接与之交互。为了实现直接交互并摆脱对 WebRTC 接口的依赖，我们转向了 QEMU 原生的 Cocoa 显示。相关改动包括：

我们还启用了不稳定的 Rutabaga 结构体，以便在 gfxstream/rutabaga 配置中匹配 Rust 侧的图形 ABI。

最后是构建和打包工作：初步的 Darwin 构建支持、在 macOS 上为 arm64 构建 QEMU，以及工具链修复。macOS 构建除了需要代码签名和公证支持外，还需要 JIT entitlement。在 Cuttlefish 方面，我们增加了 macOS 宿主支持，使该框架的编排层能在 Mac 上构建和运行，而不是假定宿主为 Linux。

通过转向统一平台，我们减少了维护需求、降低了基础设施要求、消除了冗余工具、提升了保真度，并确保开发者在 CI 中运行的是完全相同的 Cuttlefish 虚拟设备。

单一平台也让在共享技术栈上支持各种能力变得更容易，包括：

除了支持 Reality Labs 的工程师，这个相同的虚拟设备也与为我们的生态构建应用的外部开发者共享。这种一致性保证了第三方团队测试所用的平台，与我们开发和验证操作系统本身所用的基于 Cuttlefish 的平台完全相同。

随着 AI agent 在 Android 开发中扮演越来越重要的角色，验证执行和运行时行为与代码生成同样关键。虚拟设备让工程师和自动化 agent 都能在隔离环境中并发运行，促进应用执行和快速迭代。通过支持即时状态重置和重复测试运行，团队消除了对共享物理硬件的依赖，避免了工作流中断。最终，高保真模拟确保这些持续反馈循环既快速又有意义。

尽管我们是为 Reality Labs 内部的开发而构建这一方案，但 macOS 支持的价值并不限于我们的产品。我们与社区分享这项工作，以便其他开发者能够在我们所依托的 QEMU 和 AOSP 基础上继续构建。

我们分两部分发布这项工作：

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）