自 2025 年 3 月 27 日起，我們建議您使用 android-latest-release 而非 aosp-main 建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
裝置狀態
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
裝置狀態會指出軟體可以自由地刷新至裝置，以及是否強制執行驗證。裝置狀態為 LOCKED 和 UNLOCKED。LOCKED 裝置會禁止您將新軟體刷新至裝置，而 UNLOCKED 裝置則允許修改。
裝置開機時，Bootloader 會先檢查裝置是否為 LOCKED 或 UNLOCKED。如果裝置為 UNLOCKED，即使已載入的作業系統未經信任根簽署，引導程式也會向使用者顯示警告，然後繼續啟動作業系統。
如果裝置為 LOCKED，系統啟動載入程式會按照「驗證開機程序」中的步驟驗證裝置軟體。LOCKED 裝置只會在載入的作業系統已由信任根鍵正確簽署的情況下啟動。詳情請參閱「啟動流程」。
變更裝置狀態
如要變更裝置狀態，請使用 fastboot flashing [unlock | lock] 指令。為保護使用者資料，所有狀態轉換都會清除資料分區，並在刪除資料前要求使用者確認。
使用者購買二手開發人員裝置時，系統會預期 UNLOCKED 到 LOCKED 的轉換。由於裝置已鎖定，只要沒有警告，使用者就能放心，裝置處於裝置製造商所產生的狀態。開發人員如要為了開發目的在裝置上停用驗證功能，就會預期 LOCKED 到 UNLOCKED 的轉換。
信任根
信任根是用來簽署儲存在裝置上的 Android 副本的加密編譯金鑰。信任根的私密部分只有裝置製造商知道，用於簽署每個要發布的 Android 版本。信任根的公開部分會嵌入裝置中，並儲存在不會遭到竄改的位置 (通常是唯讀儲存空間)。
載入 Android 時，Bootloader 會使用信任根來驗證真實性。如要進一步瞭解這項程序，請參閱「驗證開機程序」。裝置可能有多個啟動載入器，因此可能會使用多個加密編譯金鑰。
使用者可設定的信任根
裝置可選擇允許使用者設定信任根 (例如公開金鑰)。除了內建的信任根之外，裝置 (Google Pixel 裝置就是一例) 也可以使用這個可由使用者設定的信任根，用於驗證啟動功能。
如果實作可由使用者設定的信任根，應以以下方式進行：
- 如要設定/清除使用者可設定的信任根，必須進行實體確認。
- 只有使用者可以設定信任的根。在終端使用者取得裝置之前，無法在工廠或任何中途點設定此值。
- 使用者可設定的信任根會儲存在防竄改儲存空間中。「Tamper-evident」是指可偵測 Android 是否竄改資料，例如資料是否遭到覆寫或變更。
- 如果設定了使用者可設定的信任根，裝置應允許使用內建信任根或使用者可設定的信任根簽署的 Android 版本啟動。
- 每次使用者設定信任根目錄來啟動裝置時，系統都應通知使用者裝置正在載入自訂版 Android。如需警告畫面等範例，請參閱「
LOCKED 裝置使用自訂鍵組合」。
實作使用者可設定信任根的一種方法，是建立虛擬分區，該分區只能在裝置處於 UNLOCKED 狀態時刷新或清除。Google Pixel 2 裝置採用這種做法，虛擬分區稱為 avb_custom_key。這個分割區中的資料格式是 avbtool extract_public_key 指令的輸出內容。以下是如何設定使用者可設定的信任根的範例：
avbtool extract_public_key --key key.pem --output pkmd.bin
fastboot flash avb_custom_key pkmd.bin
您可以透過下列方式清除使用者可設定的信任根：
fastboot erase avb_custom_key
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。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,["# Device state\n\nThe device state indicates how freely software can be flashed to a device and\nwhether verification is enforced. Device states are `LOCKED` and\n`UNLOCKED`. `LOCKED` devices prevent you from flashing new\nsoftware to the device, whereas `UNLOCKED` devices allow\nmodification.\n\n\nWhen a device powers on, the bootloader first checks if a device is\n`LOCKED` or `UNLOCKED`. If a device is\n`UNLOCKED`, the bootloader shows the user a warning and then proceeds\nto boot even if the loaded OS isn't signed by the root of trust.\n\n\nIf the device is `LOCKED`, the bootloader goes through the steps in\n[Verifying Boot](/docs/security/features/verifiedboot/verified-boot) to verify\nthe device's software. `LOCKED` devices boot *only* if the\nloaded OS is properly signed by the root of trust. For more details, see\n[The boot flow](/docs/security/features/verifiedboot/boot-flow).\n\nChange device state\n-------------------\n\n\nTo [change a device's state](/docs/core/architecture/bootloader/locking_unlocking), use\nthe `fastboot flashing [unlock | lock]` command. To protect user\ndata, *all* state transitions wipe the data partitions and ask for user\nconfirmation before data is deleted.\n\n\nThe `UNLOCKED` to `LOCKED` transition is anticipated when\na user buys a used development device. As a result of locking the device, the\nuser should have confidence that it is in a state produced by the device\nmanufacturer, as long as there is no warning. The `LOCKED` to\n`UNLOCKED` transition is expected when a developer wishes to disable\nverification on the device for development purposes.\n\nRoot of trust\n-------------\n\n\n*Root of trust* is the cryptographic key used to sign the copy of Android\nstored on the device. The private part of the root of trust is known only to the\ndevice manufacturer and is used to sign every version of Android intended for\ndistribution. The public part of the root of trust is embedded in the device and\nis stored in a place so it can't be tampered with (typically read-only\nstorage).\n\n\nWhen it loads Android, the bootloader uses the root of trust to verify\nauthenticity. For more details on this process, see\n[Verifying Boot](/docs/security/features/verifiedboot/verified-boot). Devices may have\nmultiple boot loaders and as such multiple cryptographic keys may be in play.\n\n### User-settable root of trust\n\n\nDevices can optionally allow the user to configure the root of trust (for\nexample, a public key). Devices can, and Google Pixel devices do, use this\nuser-settable root of trust for Verified Boot in addition to the built-in\nroot of trust.\n\n\nIf user-settable root of trust is implemented, it should be done in a way such\nthat:\n\n- Physical confirmation is required to set/clear the user-settable root of trust.\n- The user-settable root of trust can only be set by the end user. It can't be set at the factory or any intermediate point before the end user gets the device.\n- The user-settable root of trust is stored in tamper-evident storage. *Tamper-evident* means that it's possible to detect if Android has tampered with the data, for example, if it has been overwritten or changed.\n- If a user-settable root of trust is set, the device should allow a version of Android signed with either the built-in root of trust or the user-settable root of trust to boot.\n- Every time the device boots using the user-settable root of trust, the user should be notified that the device is loading a custom version of Android. For example, warning screens, see [`LOCKED`\n devices with custom key set](/docs/security/features/verifiedboot/boot-flow#locked-devices-with-custom-key-set).\n\n\nOne way of implementing user-settable root of trust is to have a virtual\npartition that can only be flashed or cleared when the device is in the\n`UNLOCKED` state. The Google Pixel 2 devices use this approach and\nthe virtual partition is called `avb_custom_key`. The format of the\ndata in this partition is the output of the\n`avbtool extract_public_key` command. Here's an example of how to set\nthe user-settable root of trust: \n\n avbtool extract_public_key --key key.pem --output pkmd.bin\n fastboot flash avb_custom_key pkmd.bin\n\n\nThe user-settable root of trust can be cleared by issuing: \n\n```\nfastboot erase avb_custom_key\n```"]]
