Microdroid 是在 pVM 中運行的迷你 Android 操作系統。您不必使用 Microdroid，您可以使用任何操作系統啟動 VM。但是，pVM 的主要用例不是運行獨立的操作系統，而是提供一個隔離的執行環境來運行應用程序的一部分，該環境具有比 Android 提供的更強的機密性和完整性保證。
對於傳統操作系統，提供強大的機密性和完整性需要大量工作（通常是重複的），因為傳統操作系統不適合總體 Android 架構。例如，使用標準的 Android 架構，開發人員需要實現一種在 pVM 中安全加載和執行部分應用程序的方法，並且有效負載是針對 glibc 構建的。 Android 應用使用仿生，通信需要基於 vsock 的自定義協議，使用 adb 進行調試具有挑戰性。
Microdroid 通過提供現成的操作系統映像來填補這些空白，該映像旨在要求開發人員以最少的工作量將其應用程序的一部分卸載到 pVM 中。本機代碼是針對 Bionic 構建的，通過 Binder 進行通信，它允許從 Android 導入 APEX 並公開 Android API 的子集，例如用於使用硬件支持的密鑰進行加密操作的密鑰庫。總體而言，開發人員應該會發現 Microdroid 是一個熟悉的環境，其中包含他們在完整 Android 操作系統中已經習慣的工具。
特徵
Microdroid 是一個精簡版的 Android，帶有一些特定於 pVM 的附加組件。 Microdroid 支持：
- NDK API 的子集（提供了 Android 實現 libc 和 Bionic 的所有 API）
- 調試特性，例如 adb、logcat、tombstone 和 gdb
- 已驗證啟動和 SELinux 已啟用
- 加載和執行嵌入在 APK 中的二進製文件以及共享庫
- Binder RPC over vsock 並通過隱式完整性檢查交換文件
- 加載 APEX
Microdroid 不支持：
android.\*包中的 Android Java APISystemServer 和 Zygote
圖形/用戶界面
HAL
微型機器人架構
Microdroid 與Cuttlefish的相似之處在於兩者都具有類似於標準 Android 的架構。 Microdroid 由以下分區映像組成，這些分區映像組合在一個複合磁盤映像中：
-
bootloader- 驗證並啟動內核。 -
boot.img- 包含內核和初始化 ramdisk。 -
vendor\_boot.img- 包含特定於 VM 的內核模塊，例如 virtio。 -
super.img- 由系統和供應商邏輯分區組成。 -
vbmeta.img- 包含經過驗證的啟動元數據。
分區映像在 Virtualization APEX 中提供，並由VirtualizationService打包在復合磁盤映像中。除了主 OS 複合磁盤映像之外， VirtualizationService還負責創建這些其他分區：
-
payload- 一組由 Android 的 APEX 和 APK 支持的分區 instance- 一個加密分區，用於保存每個實例驗證的引導數據，例如每個實例的 salt、受信任的 APEX 公鑰和回滾計數器
啟動順序
Microdroid 啟動順序發生在Device boot之後。架構文檔中討論了設備啟動。圖 1 顯示了在 Microdroid 啟動序列期間發生的步驟：
下面是對步驟的解釋：
bootloader被crossvm加載到內存中，pvmfw開始執行。在跳轉到引導加載程序之前，pvmfw 執行兩個任務：
- 驗證引導加載程序以檢查它是否來自受信任的來源（Google 或 OEM）。
- 通過使用實例映像，確保在同一 pVM 的多次引導中一致地使用相同的引導加載程序。具體來說，pVM 最初是使用空的實例映像啟動的。 pvmfw 將引導加載程序的身份存儲在實例映像中並對其進行加密。因此，下次使用相同的實例映像啟動 pVM 時，pvmfw 會從實例映像中解密保存的身份，並驗證它與之前保存的身份相同。如果身份不同，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 文件來自虛擬塊設備（/dev/vdc1，...），而不是來自常規文件（/system/apex/*.apex）。zipfuse是 Microdroid 的 FUSE 文件系統。zipfuse掛載客戶端 APK，本質上是一個 Zip 文件作為文件系統。在下面，APK 文件作為虛擬塊設備由 pVM 以 dm-verity 傳遞，與 APEX 相同。 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 ) 以每個文件的配置啟動，指定它是用於輸入（只讀）還是輸出（讀寫）。對於輸入，前端強制內容與已知哈希匹配，在 Merkle 樹的頂部進行訪問驗證。對於輸出，AuthFS 在內部維護從寫操作觀察到的內容的哈希樹，並且可以在讀回數據時強製完整性。
底層傳輸當前基於 Binder RPC，但將來可能會更改以優化性能。
密鑰管理
pVM 提供了一個穩定的密封密鑰，適用於受保護的持久數據，以及一個證明密鑰，適用於生成 pVM 可驗證生成的簽名。
活頁夾 RPC
Android 的大部分接口都用AIDL表示，它建立在 Binder Linux 內核驅動程序之上。為了支持 pVM 之間的接口，Binder 協議已被重寫以在套接字上工作，在 pVM 的情況下為vsock 。通過套接字操作允許在這個新環境中使用 Android 現有的 AIDL 接口。
為了建立連接，一個端點（例如 pVM 有效負載）創建一個RpcServer對象，註冊一個根對象，並開始偵聽新連接。客戶端可以使用RpcSession對象連接到該服務器，獲取Binder對象，並像使用Binder對象與內核 Binder 驅動程序一樣使用它。