在 Android 10 中，根文件系統不再包含在ramdisk.img中，而是合併到system.img中（也就是說， system.img始終像設置了BOARD_BUILD_SYSTEM_ROOT_IMAGE一樣創建）。搭載 Android 10 的設備：
- 使用 system-as-root 分區佈局（由構建自動強制執行，沒有更改行為的選項）。
- 必須使用 ramdisk，這是 dm-linear 所必需的。
- 必須將
BOARD_BUILD_SYSTEM_ROOT_IMAGE設置為false。此設置僅用於區分使用 ramdisk 的設備和不使用 ramdisk 的設備（而是直接掛載system.img）。
system-as-root 配置的含義在 Android 9 和 Android 10 之間有所不同。在 Android 9 system-as-root 配置中， BOARD_BUILD_SYSTEM_ROOT_IMAGE設置為true ，這會強制構建將根文件系統合併到system.img然後掛載system.img作為根文件系統 (rootfs)。此配置對於搭載 Android 9 的設備是強制性的，但對於升級到 Android 9 的設備和運行較低版本 Android 的設備是可選的。在 Android 10 system-as-root 配置中，構建始終將$TARGET_SYSTEM_OUT和$TARGET_ROOT_OUT合併到system.img中；此配置是所有運行 Android 10 的設備的默認行為。
Android 10 進行了進一步更改以支持動態分區，這是一種用戶空間分區系統，可通過無線 (OTA) 更新來創建、調整大小或銷毀分區。作為此更改的一部分，Linux 內核無法再在運行 Android 10 的設備上掛載邏輯系統分區，因此此操作由第一階段 init 處理。
以下部分描述了僅系統 OTA 的 system-as-root 要求，提供有關更新設備以使用 system-as-root 的指南（包括分區佈局更改和 dm-verity 內核要求）。有關 ramdisk 更改的詳細信息，請參閱Ramdisk 分區。
關於僅限系統的 OTA
System-only OTA（允許 Android 版本更新system.img和product.img而無需更改其他分區）需要 system-as-root 分區佈局。所有運行 Android 10 的設備都必須使用 system-as-root 分區佈局來啟用僅限系統的 OTA。
- 將
system分區掛載為 rootfs 的 A/B 設備已經使用 system-as-root 並且不需要更改即可支持系統 OTA。 - 將
system分區掛載到/system的非 A/B 設備必須更新為使用 system-as-root 分區佈局來支持系統 OTA。
有關 A/B 和非 A/B 設備的詳細信息，請參閱A/B（無縫）系統更新。
使用供應商覆蓋
供應商覆蓋允許您在設備啟動時覆蓋對vendor分區的更改。供應商覆蓋是product分區中的一組供應商模塊，當設備啟動、替換和添加到現有模塊時，這些供應商模塊會覆蓋在vendor分區上。
當設備啟動時， init進程完成第一階段掛載並讀取默認屬性。然後它搜索/product/vendor_overlay/<target_vendor_version>並將每個子目錄掛載到其對應的vendor分區目錄，如果滿足以下條件：
-
/vendor/<overlay_dir>存在。 -
/product/vendor_overlay/<target_vendor_version>/<overlay_dir>與/vendor/<overlay_dir>overlay_dir> 具有相同的文件上下文。 - 允許
init掛載在/vendor/<overlay_dir>的文件上下文中。
實施供應商覆蓋
在/product/vendor_overlay/<target_vendor_version>中安裝供應商覆蓋文件。這些文件在設備啟動時覆蓋vendor分區，替換同名文件並添加任何新文件。供應商覆蓋無法從vendor分區中刪除文件。
供應商覆蓋文件必須與它們在vendor分區中替換的目標文件具有相同的文件上下文。默認情況下， /product/vendor_overlay/<target_vendor_version>目錄中的文件具有vendor_file上下文。如果供應商覆蓋文件和它們替換的文件之間存在文件上下文不匹配，請在特定於設備的 sepolicy 中指定。文件上下文在目錄級別設置。如果供應商覆蓋目錄的文件上下文與目標目錄不匹配，並且未在特定於設備的 sepolicy 中指定正確的文件上下文，則該供應商覆蓋目錄不會覆蓋到目標目錄上。
要使用供應商覆蓋，內核必須通過設置CONFIG_OVERLAY_FS=y來啟用 OverlayFS。此外，內核必須從通用內核 4.4 或更高版本合併，或使用"overlayfs: override_creds=off option bypass creator_cred"進行修補。
供應商覆蓋實施示例
此過程演示了實現覆蓋目錄/vendor/lib/* 、 /vendor/etc/*和/vendor/app/*的供應商覆蓋。
在
device/<vendor>/<target>/vendor_overlay/<target_vendor_version>/添加預構建的供應商文件：device/google/device/vendor_overlay/28/lib/libfoo.so device/google/device/vendor_overlay/28/lib/libbar.so device/google/device/vendor_overlay/28/etc/baz.xml device/google/device/vendor_overlay/28/app/qux.apk
將預構建的供應商文件安裝到
device/google/device/device.mk中的product/vendor_overlay：PRODUCT_COPY_FILES += \ $(call find-copy-subdir-files,*,device/google/device/vendor_overlay,$(TARGET_COPY_OUT_PRODUCT)/vendor_overlay)如果目標
vendor分區文件的上下文不是vendor_file，則定義文件上下文。因為/vendor/lib/*使用vendor_file上下文，所以此示例不包括該目錄。將以下內容添加到
device/google/device-sepolicy/private/file_contexts：/(product|system/product)/vendor_overlay/[0-9]+/etc(/.*)? u:object_r:vendor_configs_file:s0 /(product|system/product)/vendor_overlay/[0-9]+/app(/.*)? u:object_r:vendor_app_file:s0
允許
init進程在vendor_file以外的文件上下文中掛載供應商覆蓋。因為init進程已經擁有在vendor_file上下文中掛載的權限，所以這個示例沒有定義vendor_file的策略。將以下內容添加到
device/google/device-sepolicy/public/init.te：allow init vendor_configs_file:dir mounton; allow init vendor_app_file:dir mounton;
驗證供應商覆蓋
要驗證供應商覆蓋配置，請在/product/vendor_overlay/<target_vendor_version>/<overlay_dir>中添加文件，並檢查文件是否覆蓋在/vendor/<overlay_dir>中的文件上。
對於userdebug構建，有一個Atest的測試模塊：
$ atest -v fs_mgr_vendor_overlay_test
更新為 root 系統
要更新非 A/B 設備以使用 system-as-root，您必須更新boot.img和system.img的分區方案，設置 dm-verity，並刪除對設備特定根文件夾的任何引導依賴項。
更新分區
與將/boot重新用作恢復分區的 A/B 設備不同，非 A/B 設備必須將/recovery分區分開，因為它們沒有備用插槽分區（例如，從boot_a到boot_b ）。如果在非 A/B 設備上刪除/recovery並使其類似於 A/B 方案，則恢復模式可能會在/boot分區更新失敗期間中斷。因此，對於非 A/B 設備， /recovery分區必須是獨立於/boot的分區，這意味著恢復映像將繼續以延遲方式更新（即與運行 Android 的設備相同） 8.1.0 或更低版本）。
下表列出了 Android 9 前後非 A/B 設備的鏡像分區差異。
| 圖片 | Ramdisk（9 之前） | System-as-root（9 之後） |
|---|---|---|
boot.img | 包含一個內核和一個ramdisk.img ： ramdisk.img
-/
- init.rc
- init
- etc -> /system/etc
- system/ (mount point)
- vendor/ (mount point)
- odm/ (mount point)
... | 僅包含一個正常的引導內核。 |
recovery.img | 包含一個恢復內核和一個恢復ramdisk.img 。 | |
system.img | 包含以下內容： system.img
-/
- bin/
- etc
- vendor -> /vendor
- ... | 包含原始system.img和ramdisk.img的合併內容： system.img
-/
- init.rc
- init
- etc -> /system/etc
- system/
- bin/
- etc/
- vendor -> /vendor
- ...
- vendor/ (mount point)
- odm/ (mount point)
... |
分區本身不會改變； ramdisk 和 system-as-root 都使用以下分區方案：
-
/boot -
/system -
/system -
/recovery -
/vendor等
設置 dm-verity
在 system-as-root 中，內核必須使用dm-verity將system.img掛載到/ （掛載點）下。 AOSP 支持system.img的以下 dm-verity 實現。
vboot 1.0
對於vboot 1.0 ，內核必須在/system上解析 Android 特定的元數據，然後轉換為dm-verity 參數以設置 dm-verity（需要這些內核補丁）。以下示例顯示了內核命令行中 system-as-root 的 dm-verity 相關設置：
ro root=/dev/dm-0 rootwait skip_initramfs init=/init dm="system none ro,0 1 android-verity /dev/sda34" veritykeyid=id:7e4333f9bba00adfe0ede979e28ed1920492b40f
vboot 2.0
對於 vboot 2.0 ( AVB )，引導加載程序必須集成external/avb/libavb ，然後解析/system的哈希樹描述符，將其轉換為dm-verity params ，最後通過內核命令行將參數傳遞給內核。 （ /system的哈希樹描述符可能位於/vbmeta或/system本身。）
vboot 2.0 需要以下內核補丁：
以下示例顯示了內核命令行中 system-as-root 的 dm-verity 相關設置：
ro root=/dev/dm-0 rootwait skip_initramfs init=/init dm="1 vroot none ro 1,0 5159992 verity 1 PARTUUID=00000016-0000-0000-0000-000000000000 PARTUUID=00000016-0000-0000-0000-000000000000 4096 4096 644999 644999 sha1 d80b4a8be3b58a8ab86fad1b498640892d4843a2 8d08feed2f55c418fb63447fec0d32b1b107e42c 10 restart_on_corruption ignore_zero_blocks use_fec_from_device PARTUUID=00000016-0000-0000-0000-000000000000 fec_roots 2 fec_blocks 650080 fec_start 650080"
使用設備特定的根文件夾
使用 system-as-root，在設備上刷新通用系統映像 (GSI)之後（以及在運行供應商測試套件測試之前），任何使用BOARD_ROOT_EXTRA_FOLDERS添加的特定於設備的根文件夾都將消失，因為整個根目錄內容已被替換由系統作為根 GSI。如果存在對特定於設備的根文件夾的依賴項（例如，它們被用作安裝點），則刪除這些文件夾可能會導致設備無法啟動。
為避免此問題，請勿使用BOARD_ROOT_EXTRA_FOLDERS添加特定於設備的根文件夾。如果您需要指定特定於設備的掛載點，請使用/mnt/vendor/<mount point> （添加到這些更改列表中）。這些特定於供應商的掛載點可以直接在fstab設備樹（用於第一階段掛載）和/vendor/etc/fstab.{ro.hardware}文件中指定，無需額外設置（因為fs_mgr在/mnt/vendor/*下創建它們/mnt/vendor/*自動）。