在 Android 10 中,根檔案系統不再是
包含在 ramdisk.img
中,而會合併為
system.img
(也就是說,system.img
一律會建立為
(如果已設定 BOARD_BUILD_SYSTEM_ROOT_IMAGE
)。裝置數
Android 10 推出:
- 使用系統即根分區配置 (由系統自動執行 沒有變更行為的選項)。
- 必須使用 ramdisk,這是 dm-Linear 必用的 ramdisk。
- 必須將
BOARD_BUILD_SYSTEM_ROOT_IMAGE
設為false
。 這項設定僅供用來區分使用 ramdisk 的裝置 以及不使用 ramdisk 的裝置 (並改為透過system.img
)。
系統以根層級設定在 Android 9 和
Android 10。在 Android 9 系統層級中
設定,BOARD_BUILD_SYSTEM_ROOT_IMAGE
已設為
true
,可強制建構將根檔案系統合併為
system.img
,然後將 system.img
掛接為根檔案
系統 (rootfs) 來管理系統。裝置必須啟用這項設定
啟動版本為 Android 9,但如果是升級至 Android 9 的裝置,則可選用。
Android 9 和搭載較舊 Android 版本的裝置。在 Android 中
10 項系統設為根設定,建構作業一律會
將 $TARGET_SYSTEM_OUT
和 $TARGET_ROOT_OUT
合併至
system.img
;這項設定是所有裝置的預設行為
搭載 Android 10
Android 10 進一步調整支援功能 動態分區 使用者空間分區系統能進行無線更新 (OTA), 建立、調整分區大小或刪除分區變更當中 核心無法再將邏輯系統分區掛接到 Android 10,所以這項作業會由第一個 階段 init
以下各節將說明容器的「系統式根層級」要求 系統專用 OTA,提供更新裝置相關指引,以使用系統化的機制 (包括分區版面配置變更和 dm-verity 核心需求)。適用對象 有關 ramdisk 變動的詳細資訊,請參閱 Ramdisk 分區。
關於系統專用 OTA
系統專用 OTA,讓 Android 版本能夠更新
system.img
和product.img
未變更其他
需要採用「從系統設為根層級分區配置」所有搭載 Android 的裝置
10 必須使用系統式根分區配置來達成
啟用系統專用 OTA。
- 將
system
分區掛接為 rootf 的 A/B 裝置。 原本就採用系統權限機制,因此不必進行變更來支援系統 OTA。 - 掛接
system
分區的非 A/B 裝置/system
,必須更新才能使用 採用系統化根分區配置來支援系統 OTA。
如要進一步瞭解 A/B 和非 A/B 裝置,請參閱 A/B (流暢) 系統更新。
使用廠商重疊元素 (<= AOSP 14)
供應商重疊元素可讓您將變更內容重疊至 vendor
分割為多個備份檔案廠商重疊元素是
對 vendor
上重疊的 product
分區
分割區。
裝置啟動時,init
程序會完成第一個程序
暫存器並讀取預設屬性接著會搜尋
/product/vendor_overlay/<target_vendor_version>
和掛接項目
具備相應 vendor
分區目錄的每個子目錄,
如果符合下列條件:
/vendor/<overlay_dir>
已存在。/product/vendor_overlay/<target_vendor_version>/<overlay_dir>
具有與/vendor/<overlay_dir>
相同的檔案結構定義。init
可以掛接在以下的檔案環境:/vendor/<overlay_dir>
。
實作廠商重疊元素
在以下位置安裝廠商重疊檔案:
/product/vendor_overlay/<target_vendor_version>
。這些檔案
在裝置啟動時覆蓋 vendor
分區,以取代檔案
並使用相同名稱加入任何新檔案供應商附加資訊無法移除檔案
來自 vendor
分區。
供應商重疊檔案必須與目標檔案具有相同的檔案結構定義
並取代於 vendor
分區中根據預設,
/product/vendor_overlay/<target_vendor_version>
目錄
並透過 vendor_file
結構定義如果發現檔案結構定義不符
之間的關聯,請在
特定裝置的通用政策檔案內容是在目錄層級設定。如果
廠商疊加層目錄的檔案內容與目標目錄不符。
且檔案情境並未在裝置專屬政策中指定
該廠商覆蓋目錄不會重疊在目標目錄中。
如要使用廠商重疊元素,核心必須藉由設定
CONFIG_OVERLAY_FS=y
。此外,核心必須與
通用核心 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
-
將預先建立的供應商檔案安裝至
product/vendor_overlay
英吋device/google/device/device.mk
: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
更新至系統權限
如要將 A/B 以外裝置更新為使用系統權限,請更新應用程式的
boot.img
和 system.img
的分區配置,已設定
設定 dm-verity,並移除裝置專屬根層級中所有的啟動依附元件
資料夾。
更新分區
不同於將 /boot
做為
復原分區
非 A/B 裝置必須保留 /recovery
分區
因為不含備用運算單元分區 (例如
從 boot_a
改為 boot_b
)。如果 /recovery
是
在非 A/B 裝置上移除,並採用類似 A/B 配置、復原模式
會在無法更新 /boot
分區時中斷。適用對象
因此,/recovery
分區必須是
將非 A/B 裝置的分區與 /boot
分開,也就是說,
還原映像檔是否持續以延遲方式更新 (
與搭載 Android 8.1.0 以下版本的裝置相同)。
下表列出非 A/B 裝置的圖片分區差異 包括 Android 9 以下版本
圖片 | Ramdisk (9 以下版本) | 系統層級 (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.img
掛接在
/
(掛接點),
dm-verity。Android 開放原始碼計畫支援下列 dm-verity 版本
system.img
的實作。
vboot 1.0
如果是 vboot 1.0,核心必須剖析
Android 專用
開啟中繼資料
/system
,然後轉換成
dm-verity 參數來設定 dm-verity (必要設定:
這些核心修補程式)。
以下範例顯示「系統層級 - 根層級」與 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 參數,最後將參數傳遞至
進行核心指令列(/system
的 Hashtree 描述元
可能位於 /vbmeta
或 /system
)。
vboot 2.0 需要下列核心修補程式:
,瞭解如何調查及移除這項存取權。以下範例顯示「系統層級 - 根層級」與 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"
使用裝置專屬的根資料夾
將通用系統映像檔之後
(GSI) 會在裝置執行前刷新
供應商測試套件測試),任何
已新增裝置專屬根資料夾,並加上 BOARD_ROOT_EXTRA_FOLDERS
這是因為整個根目錄內容已由
將系統視為根層級 GSI移除這些資料夾可能會導致裝置無法
如果有裝置專屬根資料夾的依附元件存在,則無法啟動
(例如用做掛接點)。
如要避免這個問題,請不要使用 BOARD_ROOT_EXTRA_FOLDERS
新增裝置專屬的根資料夾如需指定裝置專用的掛接
點數,請使用 /mnt/vendor/<mount point>
(已在
變更清單)。這些供應商專屬的掛接點
同時在 fstab
裝置樹狀結構中直接指定 (適用於第一階段)
掛接) 和 /vendor/etc/fstab.{ro.hardware}
檔案 (沒有
其他設定 (因為 fs_mgr
會在
/mnt/vendor/*
)。