本頁面由 Cloud Translation API 翻譯而成。

分區佈局

在 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 之後）

圖片	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) ...

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/*自動）。