自 2025 年 3 月 27 日起，我們建議您使用 android-latest-release 而非 aosp-main 建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
驗證啟動
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
在使用 Android 版本前，Verified Boot 會透過密碼編譯法驗證所有可執行的程式碼和資料。包括核心 (從 boot 分區載入)、裝置樹狀結構 (從 dtbo 分區載入)、system 分區、vendor 分區等等。
只讀取一次的小型分割區 (例如 boot 和 dtbo)，通常會透過將整個內容載入記憶體，然後計算其雜湊值來驗證。系統會將計算出的雜湊值與預期的雜湊值進行比較。如果值不相符，Android 就不會載入。詳情請參閱「啟動流程」。
較大的分割區無法放入記憶體 (例如檔案系統)，因此可能會使用雜湊樹狀圖，在資料載入記憶體時，驗證會是持續進行的程序。在這種情況下，雜湊樹根的雜湊值會在執行期間計算，並與預期的根雜湊值進行比對。Android 包含 dm-verity 驅動程式，可驗證較大的分區。如果計算出的根雜湊不符合預期的根雜湊值，系統就不會使用該資料，Android 也會進入錯誤狀態。詳情請參閱「dm-verity 損毀」。
預期雜湊值通常會儲存在每個已驗證分區的結尾或開頭，或儲存在專屬分區，或兩者皆是。重要的是，這些雜湊是由信任根 (直接或間接) 簽署。舉例來說，AVB 實作方式支援這兩種方法，詳情請參閱「Android 驗證開機程序」。
復原保護
即使更新程序完全安全，非持續性 Android 核心漏洞利用程式仍可能手動安裝較舊且較容易遭到攻擊的 Android 版本，重新啟動至容易遭到攻擊的版本，然後使用該 Android 版本安裝持續性漏洞利用程式。從那時起，攻擊者就永久擁有裝置，可以執行任何操作，包括停用更新。
防範這類攻擊的保護機制稱為「Rollback Protection」。回溯保護功能通常會使用防竄改儲存空間來記錄最新的 Android 版本，並在 Android 版本低於記錄版本時拒絕啟動 Android。版本通常是依分區追蹤。
如要進一步瞭解 AVB 如何處理回溯保護機制，請參閱 AVB README。
處理驗證錯誤
驗證可能會在啟動時 (例如，如果 boot 分區上計算的雜湊不符合預期的雜湊) 或執行期間 (例如，如果 dm-verity 在 system 分區上遇到驗證錯誤) 失敗。如果驗證在開機時失敗，裝置就無法啟動，使用者必須採取步驟來復原裝置。
如果驗證在執行階段失敗，流程就會變得複雜一些。如果裝置使用 dm-verity，則應在 restart 模式下進行設定。在 restart 模式中，如果遇到驗證錯誤，裝置會立即重新啟動，並設定特定標記來指出原因。啟動載入器應會注意到這個標記，並將 dm-verity 切換為使用 I/O 錯誤 (eio) 模式，並在安裝新更新之前保持這個模式。
在 eio 模式下啟動時，裝置會顯示錯誤畫面，通知使用者已偵測到資料毀損，且裝置可能無法正常運作。畫面會持續顯示，直到使用者關閉為止。在 eio 模式中，如果遇到驗證錯誤，dm-verity 驅動程式就不會重新啟動裝置，而是傳回 EIO 錯誤，應用程式需要處理該錯誤。
意圖是讓系統更新程式執行 (以便安裝沒有損毀錯誤的新 OS)，或讓使用者盡可能從裝置中取得資料。安裝新作業系統後，啟動載入程式會注意到新安裝的作業系統，並切換回 restart 模式。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間：2025-07-27 (世界標準時間)。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-07-27 (世界標準時間)。"],[],[],null,["# Verify Boot\n\nVerified Boot requires cryptographically verifying all executable code and data\nthat is part of the Android version being booted before it is used. This includes\nthe kernel (loaded from the `boot` partition), the device tree (loaded\nfrom the `dtbo` partition), `system` partition,\n`vendor` partition, and so on.\n\n\nSmall partitions, such as `boot` and `dtbo`, that are read\nonly once are typically verified by loading the entire contents into memory and\nthen calculating its hash. This calculated hash value is then compared to the\n*expected hash value* . If the value doesn't match, Android won't load.\nFor more details, see [Boot Flow](/docs/security/features/verifiedboot/boot-flow).\n\n\nLarger partitions that won't fit into memory (such as, file systems) may use\na hash tree where verification is a continuous process happening as data is\nloaded into memory. In this case, the root hash of the hash tree is calculated\nduring run time and is checked against the *expected root hash value* .\nAndroid includes the [dm-verity\ndriver](/docs/security/features/verifiedboot/dm-verity) to verify larger partitions. If at some point the calculated root\nhash doesn't match the *expected root hash value* , the data isn't used\nand Android enters an error state. For more details, see\n[dm-verity\ncorruption](/docs/security/features/verifiedboot/boot-flow#dm-verity-corruption).\n\n\nThe *expected hashes* are typically stored at either the end or beginning\nof each verified partition, in a dedicated partition, or both. Crucially, these\nhashes are signed (either directly or indirectly) by the root of trust. As an\nexample, the AVB implementation supports both approaches, see\n[Android Verified Boot](/docs/security/features/verifiedboot/avb) for details.\n\nRollback protection\n-------------------\n\n\nEven with a completely secure update process, it's possible for a non-persistent\nAndroid kernel exploit to manually install an older, more vulnerable version of\nAndroid, reboot into the vulnerable version, and then use that Android version to\ninstall a persistent exploit. From there the attacker permanently owns the device\nand can do anything, including disabling updates.\n\n\nThe protection against this class of attacks is called *Rollback\nProtection*. Rollback protection is typically implemented by using\ntamper-evident storage to record the most recent version of the Android and\nrefusing to boot Android if it's lower than the recorded version. Versions\nare typically tracked on a per-partition basis.\n\n\nFor more details on how AVB handles rollback protections, see the AVB\n[README](https://android.googlesource.com/platform/external/avb/+/android16-release/README.md#Rollback-Protection).\n\nHandle verification errors\n--------------------------\n\n\nVerification can fail either at boot time (such as, if the calculated hash on\n`boot` partition doesn't match the expected hash) or at run time\n(such as, if dm-verity encounters a verification error on the\n`system` partition). If verification fails at boot time, the device\ncan't boot and the end user needs to go through steps to recover the device.\n\n\nIf verification fails at run-time the flow is a bit more complicated. If the\ndevice uses dm-verity, it should be configured in `restart` mode. In\n`restart` mode, if a verification error is encountered, the device is\nimmediately restarted with a specific flag set to indicate the reason. The boot\nloader should notice this flag and switch dm-verity over to use I/O Error\n(`eio`) mode and stay in this mode until a new update has been\ninstalled.\n\n\nWhen booting in `eio` mode, the device shows an error screen\ninforming the user that corruption has been detected and the device might not\nfunction correctly. The screen shows until the user dismisses it. In\n`eio` mode the dm-verity driver won't restart the device if a\nverification error is encountered, instead an EIO error is returned and the\napp needs to deal with the error.\n\n\nThe intent is that either the system updater will run (so a new OS without\ncorruption errors can be installed) or the user can get as much of their data\noff the device as possible. Once the new OS has been installed, the boot loader\nnotices the newly installed OS and switches back to `restart` mode."]]
