Microdroid 是執行在 pVM 中的迷你 Android 作業系統。您不必使用 Microdroid，也可以使用任何作業系統啟動 VM。不過，pVM 的主要用途並非執行獨立的作業系統，而是提供隔離的執行環境，用於執行應用程式的部分內容，並提供比 Android 更強的機密性和完整性保證。
在傳統作業系統中，要提供強大的機密性和完整性，需要進行大量 (通常是重複) 的工作，因為傳統作業系統不符合整體 Android 架構。舉例來說，在標準 Android 架構中，開發人員需要實作一種方法，以便在 pVM 中安全地載入及執行部分應用程式，而酬載則是根據 glibc 建構。Android 應用程式使用 Bionic，通訊需要透過 vsock 使用自訂協定，使用 ADB 進行偵錯相當困難。
Microdroid 提供現成的作業系統映像檔，可讓開發人員以最少的力氣將應用程式的一部分卸載至 pVM，以填補這些空白。原生程式碼是針對 Bionic 建構，通訊會透過 Binder 進行，且允許從 Android 主機匯入 APEX，並公開 Android API 的子集，例如使用硬體支援金鑰的加密運算的 KeyStore。總體而言，開發人員應該會發現 Microdroid 是個熟悉的環境，因為他們已習慣在完整的 Android 作業系統中使用這些工具。
功能
Microdroid 是精簡版 Android，其中包含一些專屬於 pVM 的額外元件。Microdroid 支援：
- NDK API 的子集 (提供 Android 實作 libc 和 Bionic 的所有 API)
- 偵錯功能，例如 ADB、Logcat、Tombstone 和 gdb
- 驗證開機程序和 SELinux
- 載入及執行嵌入 APK 的二進位檔和共用程式庫
- 透過 vsock 進行 Binder RPC，並透過隱含完整性檢查交換檔案
- 載入 APEX
Microdroid 不支援以下項目：
android.\*套件中的 Android Java APISystemServer 和 Zygote
圖像/使用者介面
HAL
Microdroid 架構
Microdroid 與 Cuttlefish 相似，兩者都具有與標準 Android 相似的架構。Microdroid 包含下列分區映像檔，這些映像檔會在複合磁碟映像檔中分組：
bootloader：驗證並啟動核心。boot.img：包含核心和初始化 RAM 磁碟。vendor_boot.img：包含 VM 專屬的核心模組，例如 virtio。super.img：包含系統和供應商邏輯磁碟分割區。vbmeta.img：包含驗證開機程序中繼資料。
分割區映像檔會在 Virtualization APEX 中出貨，並由 VirtualizationService 封裝為複合磁碟映像檔。除了主要 OS 組合磁碟映像檔外，VirtualizationService 還負責建立下列其他分割區：
payload- 由 Android 的 APEX 和 APK 支援的一組分割區instance：用於保存每個執行個體已驗證的啟動資料 (例如每個執行個體的鹽值、信任的 APEX 公開金鑰和復原計數器) 的加密分割區
開機順序
Microdroid 啟動序列會在裝置啟動後發生。請參閱「架構」文件中的「pVM 韌體」一節，瞭解裝置啟動程序。圖 1 顯示 Microdroid 啟動序列期間執行的步驟：
以下說明這些步驟：
系統會透過 crosvm 將引導程式載入記憶體，並開始執行 pvmfw。在跳轉至啟動載入程式之前，pvmfw 會執行兩項工作：
- 驗證啟動載入器，檢查是否來自可信任的來源 (Google 或 OEM)。
- 透過使用執行個體映像檔，確保在同一個 pVM 的多個啟動作業中，一律使用相同的啟動載入程式。具體來說，pVM 最初會使用空白的執行個體映像檔啟動。pvmfw 會在執行個體映像檔中儲存啟動載入程式的身分，並對其進行加密。因此，下次以相同執行個體映像檔啟動 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/<name>目錄中掛接 APEX。Android 和 Microdroid 掛載 APEX 的方式唯一的差異在於，在 Microdroid 中，APEX 檔案來自虛擬區塊裝置 (/dev/vdc1、…)，而非一般檔案 (/system/apex/*.apex)。zipfuse是 Microdroid 的 FUSE 檔案系統。zipfuse會掛接用戶端 APK，而 APK 本質上是做為檔案系統的 ZIP 檔案。在底下，APK 檔案會以虛擬區塊裝置的形式，由使用 dm-verity 的 pVM 傳遞，這與 APEX 相同。APK 包含設定檔，其中列出應用程式開發人員為此 pVM 例項要求的 APEX 清單。apexd會在啟用 APEX 時使用這份清單。啟動流程會傳回至 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 驗證的簽章。
Binder RPC
大多數 Android 介面都是以 AIDL 表示，而 AIDL 是建構在 Binder Linux 核心驅動程式之上。為了支援 pVM 之間的介面，Binder 通訊協定已重新編寫，以便透過 Socket 運作，在 pVM 的情況下為 vsock。透過 Socket 運作可讓 Android 現有的 AIDL 介面在這個新環境中使用。
如要設定連線，一個端點 (例如 pVM 酬載) 會建立 RpcServer 物件、註冊根物件，並開始監聽新的連線。用戶端可以使用 RpcSession 物件連線至此伺服器，取得 Binder 物件，然後如同使用核心繫結器驅動程式中的 Binder 物件一樣使用該物件。