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