MetaがAndroid仮想デバイスのCuttlefishをApple siliconのMacへ移植

MetaがCuttlefishをApple siliconのMacへ

2026年11月13日、Metaのエンジニアリングブログは、Reality LabsがAndroid Open Source Projectの仮想デバイスフレームワークであるCuttlefishを、macOSとApple silicon上でネイティブに動かした経緯を紹介しました。筆者はHadrien Zalek氏、Joe Knox氏、Alex Chong氏、Marcel Apfelbaum氏です。Reality LabsはAIグラスなどの製品を開発しており、希少な実機に頼らず開発とテストを拡大するためにエミュレーターを使っています。ただし、これはGoogleやAOSPの公式リリースではありません。MetaはQEMUのフォークとパッチ一式として公開し、変更を上流へ提供する方法をまだ探っていると述べています。

なぜ1つのプラットフォームにしたかったのか

スマートフォン以外のAndroid機器のソフトウェアをテストするには、仮想デバイスが実機のソフトウェア挙動をどこまで再現できるかが重要です。Goldfishのような軽量エミュレーターは一部を補えますが、実機との違いが原因の不具合が開発後半まで見つからないことがあります。Cuttlefishは実機と同じシステムイメージを起動し、仮想ハードウェア上で現実的なソフトウェアスタックを動かすため、物理デバイスにより近い動作をします。問題は、CuttlefishがLinuxでしか動かないのに、Metaのアプリやライブラリの開発者はApple siliconのMacで作業していることでした。そのためMetaはGoldfishとCuttlefishを並行して支えるしかありませんでした。記事は、これが計算資源を消耗させ、開発者を混乱させ、エミュレーターチームの動きを遅くし、すべてのツールに2つのプラットフォーム対応を求めたと述べています。AOSPも同じ線引きをしており、Goldfishはアプリ開発者向け、Cuttlefishはプラットフォーム開発者向けだとしています。

macOSで足りなかった3点

Cuttlefishはオーケストレーション層で、ゲストOSを実際に動かすのは仮想マシンモニターです。LinuxではCuttlefishは通常crosvmを使い、以前は代替としてQEMUにも対応していましたが、その統合は動かなくなっていました。Apple siliconでネイティブに動かすため、MetaはQEMU対応を復活させました。Cuttlefishの多くの仮想デバイスはvhost-userバックエンドを使います。これはソケット経由でQEMUにvirtioデバイスを提供する別プロセスです。この設計の大部分はLinuxを前提にしていました。macOSでは3つの前提が崩れます。vhost-userの仕組みがLinux限定で、ビルドも実行もできないこと。Appleのハイパーバイザーに、QEMUが想定していないリソース制限があること。ネイティブの表示、ビルド、署名の経路が存在しなかったことです。

Metaが加えた変更

最も重要な変更は、QEMUのvhost-userの経路にありました。フロントエンド、libvhost-user、vhost-user-blkのようなcontribバックエンドは、すべてLinuxに限定されていました。Metaはこれらのビルド制限を緩め、macOSでもビルドできるようにしました。これで、CuttlefishのデバイスバックエンドがLinuxと同じようにMac上でQEMUへ処理を渡せます。Apple siliconでは、QEMUはKVMではなくHypervisor.framework、つまりHVFで高速化します。HVFバックエンドは大きめのCuttlefish構成に対してメモリ領域の追跡数が足りなかったため、Metaは追跡スロット数を増やしました。

表示については、WebRTCの画面に頼らず、QEMUのネイティブなCocoa表示へ移行しました。変更には、表示の乱れをなくすBGRAピクセル形式への対応、マウスクリックをタッチ入力へ変換する機能、-gフラグによる表示サイズの指定が含まれます。さらに、gfxstreamとrutabagaの構成でRust側のグラフィックスABIに合わせるため、不安定なRutabaga構造体を有効にしました。最後にビルドとパッケージングの作業があります。Darwinのビルド対応、macOS上でのarm64向けQEMUのビルド、ツールチェーンの修正、JITのエンタイトルメント、コード署名と公証です。Cuttlefish側では、macOSホストへの対応を加え、オーケストレーション層がMac上でビルドして動くようにしました。

Metaが報告する効果

Metaは、1つのプラットフォームに統合したことで、保守の手間が減り、必要なインフラが減り、重複したツールがなくなり、忠実度が上がり、開発者がCIと同じ仮想デバイスを使えるようになったと述べています。単一のプラットフォームのおかげで、Bluetoothのペアリング、Wi-Fi、モバイル通信、3Dグラフィックス、OTAアップデートのテスト、Fastboot、CIや開発で使うスナップショットにも対応しやすくなりました。これらはMeta自身の主張です。記事にはベンチマーク、コストの数字、測定した忠実度のスコアは示されていません。また、同じ仮想デバイスはMetaのエコシステム向けに開発する外部の開発者にも共有されるため、サードパーティのチームはMetaが自社OSの検証に使うのと同じプラットフォームでテストできると説明しています。

記事はAIエージェントについても論じています。Android開発でエージェントの役割が大きくなるほど、コードを生成することと同じくらい、実行と実行時の挙動を検証することが重要になります。仮想デバイスがあれば、エンジニアと自動化エージェントが隔離された環境で同時に作業でき、状態を即座に戻し、実機を共有せずにテストを繰り返せます。

入手方法と、まだ足りないもの

Metaはこの成果を2つに分けて配布しています。qemu-wearablesはMetaが保守するQEMUのフォークで、同社のコミットを含みます。cuttlefish-wearablesはパッチファイルの集まりで、AndroidとAOSPにパッチを当てる手順が付いています。どちらもGitHubのfacebookincubator配下にあり、ビルドとパッチ適用の手順を含みます。Metaは、QEMUとCuttlefishのコミュニティ、特にmacOS統合を直接可能にしたStefano Garzarella氏のvsock-user実装に謝意を示しています。

「全面対応」という言い方には注意が必要です。記事が述べているのは、Meta自身の用途で動いている移植を、フォークとパッチとして共有したということです。変更がQEMUやAOSPに取り込まれたとは書かれておらず、非対応の機能や既知の不具合の一覧もありません。上流が受け入れるまでは、導入する側がパッチを当て、再ビルドし、その作業を最新に保つ必要があります。