2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main ではなく android-latest-release を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。

Microdroid

Microdroid は pVM で動作する小型の Android OS です。Microdroid を使用する必要はなく、VM は任意の OS で起動できます。しかし、pVM の主なユースケースはスタンドアロン OS を実行することではなく、Android が提供するよりも優れた機密性と整合性が確保された、アプリの一部を実行するための分離された実行環境を提供することです。

従来のオペレーティングシステムでは、優れた機密性と整合性を確保するためにかなりの作業が必要になります（多くの場合、重複します）。なぜなら、従来型オペレーティングシステムは包括的な Android アーキテクチャに適していないためです。たとえば、標準の Android アーキテクチャでは、デベロッパーはアプリの一部を pVM で安全に読み込んで実行する手段を実装する必要があり、ペイロードは glibc に対してビルドされます。Android アプリは Bionic を使用し、通信には vsock にカスタムプロトコルが必要で、adb を使用してデバッグするのは困難です。

Microdroid は、こうしたギャップを埋めるために、デベロッパーがアプリの一部を pVM にオフロードするための最小労力で設計された既製の OS イメージを提供しています。ネイティブコードは 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.\* パッケージのコア Java API は、VM で ART APEX を有効にすることでサポートされます。
SystemServer と Zygote
グラフィック / UI
HAL

Microdroid アーキテクチャ

Microdroid は Cuttlefish と類似しており、どちらも標準の Android に似たアーキテクチャを備えています。Microdroid は、以下のパーティションイメージから構成され、複合ディスクイメージにグループ化されています。

bootloader - カーネルを検証して起動します。
boot.img - カーネルと init RAM ディスクが含まれます。
vendor_boot.img - virtio などの VM 固有のカーネルモジュールが含まれます。
super.img - システムとベンダーの論理パーティションで構成されます。
vbmeta.img - 確認付きブートのメタデータが含まれます。

パーティションイメージは Virtualization APEX で提供され、VirtualizationService によって複合ディスクイメージにパッケージ化されます。VirtualizationService は、メインの OS 複合ディスクイメージだけでなく、次のパーティションも作成します。

payload - Android の APEX と APK に基づくパーティションのセット
instance - インスタンスごとのソルト、信頼できる APEX 公開鍵、ロールバックカウンタなど、インスタンスごとの確認付きブートデータを保持するための暗号化されたパーティション

起動シーケンス

Microdroid の起動シーケンスは、デバイスの起動の後に行われます。デバイスの起動については、アーキテクチャのドキュメントの pVM ファームウェアセクションをご覧ください。図 1 は、Microdroid の起動シーケンスで発生する手順を示しています。

microdroid インスタンスの安全なブートフロー

図 1. microdroid インスタンスの安全なブートフロー

以下に手順を説明します。

ブートローダーが crosvm によってメモリに読み込まれ、pvmfw が実行を開始します。pvmfw は、ブートローダーにアクセスする前に次の 2 つのタスクを実行します。
- ブートローダーが信頼できるソース（Google または OEM）からのものかどうかを確認します。
- インスタンスイメージを使用して、同じ pVM の複数回のブートにわたって同じブートローダーを一貫して使用するようにします。具体的には、pVM は最初に空のインスタンスイメージで起動します。pvmfw は、ブートローダーの ID をインスタンスイメージに格納し、暗号化します。このため、次回同じインスタンスイメージを使用して pVM を起動すると、pvmfw はインスタンスイメージから保存された ID を復号し、以前に保存された ID と同じであることを確認します。ID が異なる場合、pvmfw は起動を拒否します。
ブートローダーによって Microdroid が起動します。
ブートローダーはインスタンスディスクにアクセスします。pvmfw と同様に、ブートローダーにはインスタンスディスクドライブがあり、前回のブート時にこのインスタンスで使用されていたパーティションイメージに関する情報（公開鍵を含む）が格納されています。
ブートローダーが vbmeta とチェーンされたパーティション（boot や super など）を検証し、成功すると、次のステージの pVM のシークレットを取得します。その後、Microdroid はカーネルに制御を引き継ぎます。
スーパーパーティションはブートローダーによってすでに検証されているため（ステップ 3）、カーネルはスーパーパーティションを無条件にマウントします。完全な Android と同様に、スーパーパーティションは dm-verity でマウントされた複数の論理パーティションで構成されています。次に、コントロールが init プロセスに渡され、さまざまなネイティブサービスが開始されます。init.rc スクリプトは、完全な Android のスクリプトに似ていますが、Microdroid のニーズに合わせて調整されています。
init プロセスは、インスタンスイメージにアクセスする Microdroid マネージャーを起動します。Microdroid マネージャーサービスは、前のステージから渡された鍵を使用してイメージを復号し、この pVM が信頼するクライアント APK と APEX の公開鍵とロールバックカウンタを読み取ります。この情報は、後で zipfuse と apexd がクライアント APK をマウントし、APEX をリクエストしたときに使用されます。
Microdroid マネージャーサービスは apexd から開始します。
apexd は、APEX を /apex/<name> ディレクトリにマウントします。Android と Microdroid による APEX のマウントの唯一の違いは、Microdroid では APEX ファイルが通常のファイル（/system/apex/*.apex）ではなく、仮想ブロックデバイス（/dev/vdc1, …）から取得される点です。
zipfuse は Microdroid の FUSE ファイルシステムです。zipfuse は、基本的には ZIP ファイルをファイルシステムとするクライアント APK をマウントします。この APK ファイルは、APEX と同様、dm-verity を使用した pVM によって仮想ブロックデバイスとして渡されます。この APK には、アプリデベロッパーがこの pVM インスタンスについてリクエストした APEX のリストを含む構成ファイルが含まれています。このリストは、APEX を有効にするときに apexd によって使用されます。
起動フローは Microdroid マネージャーサービスに戻ります。マネージャーサービスは、Binder RPC を使用して Android の VirtualizationService と通信し、クラッシュやシャットダウンなどの重要なイベントをレポートしたり、pVM の終了などのリクエストを承認したりできるようにします。マネージャーサービスが APK の構成ファイルからメインバイナリの場所を読み取って実行します。

ファイル交換（AuthFS）

Android コンポーネントでは、入力、出力、状態のファイルを使用し、これらをファイル記述子（AIDL では ParcelFileDescriptor 型）として渡し、Android カーネルでアクセスを制御するのが一般的です。AuthFS を使用すると、pVM の境界を越えて相互に信頼していないエンドポイント間でファイルを交換する際に、同様の機能を実現できます。

基本的に、AuthFS はリモートファイルシステムで fs-verity と同様に、個々のアクセスオペレーションの透明性の高い整合性チェックを行います。このチェックにより、pVM で実行されるファイル読み取りプログラムなどのフロントエンドは、信頼できないバックエンド（通常は Android）がファイルの内容を改ざんしたかどうかを検出できます。

ファイルを交換するために、バックエンド（fd\_server）は入力用（読み取り専用）か出力用（読み取りと書き込み）かを指定するファイルごとの構成で開始されます。入力の場合、アクセス時の検証用のマークルツリーに加え、フロントエンドはコンテンツを既知のハッシュと一致させます。出力の場合、AuthFS は書き込みオペレーションから観測されたコンテンツのハッシュツリーを内部的に維持し、データが読み取られるときに整合性を適用します。

基盤となるトランスポートは現在 Binder RPC に基づいていますが、将来的にはパフォーマンスを最適化するために変更される可能性があります。

鍵の管理

pVM は、保護対象の永続データに適している安定したシーリングキーや、pVM によって検証可能な方法で生成された署名を生成するのに適している証明書鍵によって提供されます。

Binder リモートプロシージャコール

Android のインターフェースの大部分は AIDL で表現されており、Binder Linux カーネルドライバ上に構築されています。pVM 間のインターフェースをサポートするため、Binder プロトコルは、ソケット（vsock、pVM の場合）で動作するように書き換えられました。ソケットを介して操作すると、Android の既存の AIDL インターフェースをこの新しい環境で使用できます。

接続を設定するために、pVM ペイロードなどの 1 つのエンドポイントが RpcServer オブジェクトを作成し、ルートオブジェクトを登録して、新しい接続をリッスンします。クライアントは、RpcSession オブジェクトを使用してこのサーバーに接続し、Binder オブジェクトを取得します。カーネル Binder ドライバで Binder オブジェクトを使用する場合と同じように使用できます。