使用者資料查核點

Android 10 推出了使用者資料查核點 (UDC),可讓 Android 在 Android 無線 (OTA) 更新失敗時,回復至先前的狀態。有了 UDC,如果 Android OTA 更新失敗,裝置就能安全地回復至先前的狀態。雖然 A/B 更新作業解決了這個問題,可用於早期啟動及復原 不支援修改使用者資料分區 (掛接於 /data)。

UDC 可讓裝置還原使用者資料分區 (即使在 遭到修改。UDC 功能可利用 檔案系統,在檔案系統不支援時替代實作方式 檢查點,與系統啟動載入程式 A/B 機制整合,同時支援 非 A/B 版本更新,且支援金鑰版本繫結和金鑰復原 預防措施

使用者影響

使用者資料保留功能可改善 OTA 更新體驗,因為 OTA 更新失敗時,使用者資料遺失的情況會減少。這麼做可以減少在更新過程中遇到問題的使用者所撥打的支援電話數量。但如果網路旅行社 更新失敗時,使用者可能會發現裝置多次重新啟動。

運作方式

不同檔案系統中的檢查點功能

針對 F2FS 檔案系統,UDC 會在上游 4.20 Linux 核心中新增檢查點功能,並將其回移至搭載 Android 10 的裝置支援的所有常見核心。

針對其他檔案系統,UDC 會使用名為 dm_bow 的裝置對應虛擬裝置 檢查點功能dm_bow位於裝置和檔案之間 有些人會將 Cloud Storage 視為檔案系統 但實際上不是分區在掛接時即會發出飾板,導致檔案系統 都發出修剪指令。「dm_bow」會攔截這類飾板和用途 並設定免費的封鎖清單然後讀取和寫入資料會傳送至裝置 未修改,不過在允許寫入之前,系統會備份還原所需的資料 免付費區塊

檢查點程序

當掛載具有 checkpoint=fs/block 標記的分割區時,Android 會在磁碟上呼叫 restoreCheckpoint,讓裝置還原任何目前的檢查點。接著,init 會呼叫 needsCheckpoint 函式來判斷 裝置處於系統啟動載入程式 A/B 狀態,或是已設定更新重試作業 數量。如果任一條件為 true,Android 會呼叫 createCheckpoint,藉此新增掛載標記或建構 dm_bow 裝置。

掛接分區後,系統會呼叫檢查點程式碼來發出剪輯。 接著,啟動程序將照常運作。在 LOCKED_BOOT_COMPLETE 時,Android 會呼叫 commitCheckpoint 來提交目前的查核點,並繼續正常更新。

管理 Keymaster 金鑰

Keymaster 金鑰可用於裝置加密或其他用途。為管理這些鍵,Android 會延遲鍵刪除呼叫,直到檢查點完成為止。

監控健康狀態

健康狀態 Daemon 會確認磁碟空間是否足夠 檢查點。健康守護程式位於 Checkpoint.cpp 中的 cp_healthDaemon

健康 Daemon 有下列可設定的行為:

Checkpoint API

Checkpoint API 由 UDC 功能使用。如要瞭解 UDC 使用的其他 API,請參閱 IVold.aidl

void startCheckpoint(int retry)

建立查核點。

架構會在準備開始更新時呼叫此方法。 系統會先建立查核點,再建立查核點 重新啟動後已掛接 R/W。如果重試次數為正值,API 會處理追蹤重試,更新程式會呼叫 needsRollback,檢查是否需要回復更新。如果重試次數為 -1,API 會延遲至 A/B 開機載入程式的判斷。

執行一般 A/B 更新時,不會呼叫此方法。

voidCommitChanges()

提交變更。

當變更準備就緒時,架構會在重新啟動後呼叫這個方法 。系統會在資料 (例如圖片、影片、簡訊、伺服器等) 之前呼叫這個方法 收據) 會在 BootComplete之前寫入使用者資料。

如果沒有任何執行中的查核點更新,此方法就不會有任何作用。

abortChanges()

強制重新啟動並還原至檢查點。放棄自首次重新啟動以來的所有使用者資料修改。

架構會在重新啟動後,但在 commitChanges 之前呼叫此方法。呼叫此方法時,retry_counter 會減少。記錄項目為 。

bool requirementsRollback()

決定是否需要復原。

在非檢查點裝置上,會傳回 false。在檢查點裝置上,在非檢查點啟動期間傳回 true

實作 UDC

參考實作

如需 UDC 實作方式的範例,請參閱 dm-bow.c。如需這項功能的其他說明文件,請參閱 dm-bow.txt

設定

init.hardware.rc 檔案的 on fs 中,請確認符合下列條件:

mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --early

init.hardware.rc 檔案的 on late-fs 中,請確認符合下列條件:

mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --late

fstab.hardware 檔案中,確認 /data 已標示為 latemount

/dev/block/bootdevice/by-name/userdata              /data              f2fs
noatime,nosuid,nodev,discard,reserve_root=32768,resgid=1065,fsync_mode=nobarrier
latemount,wait,check,fileencryption=ice,keydirectory=/metadata/vold/metadata_encryption,quota,formattable,sysfs_path=/sys/devices/platform/soc/1d84000.ufshc,reservedsize=128M,checkpoint=fs

新增中繼資料分區

UDC 需要中繼資料分區來儲存非啟動載入器的重試次數和鍵。設定中繼資料分割區,並提早將其掛載至 /metadata

在您的 fstab.hardware 檔案中,確定 /metadata 已標記為 earlymountfirst_stage_mount

/dev/block/by-name/metadata           /metadata           ext4
noatime,nosuid,nodev,discard,sync
wait,formattable,first_stage_mount

將分區初始化為所有零。

BoardConfig.mk 中新增以下幾行內容:

BOARD_USES_METADATA_PARTITION := true
BOARD_ROOT_EXTRA_FOLDERS := existing_folders metadata

更新系統

F2FS 系統

如果系統使用 F2FS 設定資料格式,請確認 F2FS 版本 支援查核點詳情請參閱「不同檔案系統中的檢查點功能」。

checkpoint=fs 標記新增至 Fstab 的 <fs_mgr_flags> 區段 裝置掛接位置為 /data

非 F2FS 系統

對於非 F2FS 系統,必須在核心設定中啟用 dm-bow

針對掛載在 /data 的裝置,將 checkpoint=block 旗標新增至 fstab 的 <fs_mgr_flags> 部分。

查看記錄

呼叫 Checkpoint API 時會產生記錄項目。

驗證

如要測試 UDC 實作方式,請執行 VtsKernelCheckpointTest 組的 VTS 測試。