自 2025 年 3 月 27 日起，我們建議您使用 android-latest-release 而非 aosp-main 建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
鎖定及解鎖系統啟動載入程式
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
根據預設，大多數 Android 裝置在出貨時都會鎖定系統啟動載入程式，也就是說使用者無法刷新系統啟動載入程式或裝置分區。如有需要，您 (以及已啟用開發人員選項的裝置使用者) 可以解鎖啟動載入程式，以便刷新新映像檔。
進入系統啟動載入程式
如要發出 fastboot 指令，您必須處於系統啟動載入程式模式。其中一種方法是傳送 ADB 指令 adb reboot bootloader。部分手機在開機時按下組合鍵 (通常是調低音量鍵)，也可以重新啟動至系統啟動載入程式。
解鎖系統啟動載入程式
進入系統啟動載入程式模式後，請在裝置上執行 fastboot flashing unlock 指令，以解鎖系統啟動載入程式並啟用可重新刷新的分區。設定完成後，解鎖模式會在重新啟動後保留。
除非 get_unlock_ability 設為 1，否則裝置應拒絕 fastboot flashing unlock 指令。如果設為 0，使用者需要啟動至主畫面，開啟「設定」>「系統」>「開發人員選項」選單，然後啟用「OEM 解鎖」選項 (將 get_unlock_ability 設為 1)。設定後，這個模式會在重新啟動和恢復原廠設定後持續存在。
傳送 fastboot flashing unlock 指令時，裝置應會提示使用者，警告他們可能會遇到非官方圖片的問題。使用者確認警告後，裝置應恢復原廠設定，以防未經授權的資料存取。即使系統啟動載入程式無法正確重新格式化裝置，也應重設裝置。只有在重設後才能設定持續標記，以便重新刷新裝置。
fastboot flashing unlock 程序中應會重設所有未覆寫的 RAM。這項措施可防止攻擊者讀取先前啟動時剩餘的 RAM 內容。同樣地，解鎖裝置應在每次啟動時清除 RAM (除非這會造成無法接受的延遲)，但應保留用於核心 ramoops 的區域。
鎖定系統啟動載入程式
如要鎖定系統啟動載入程式並重設裝置，請在裝置上執行 fastboot flashing lock 指令。零售版裝置應處於鎖定狀態 (get_unlock_ability 會傳回 0) 出貨，以確保攻擊者無法透過安裝新的系統或啟動映像檔來危害裝置。
設定鎖定和解鎖屬性
ro.oem_unlock_supported 屬性應在建構期間設定，並根據裝置是否支援刷新解鎖功能。
- 如果裝置支援閃燈解鎖功能，請將
ro.oem_unlock_supported 設為 1。
- 如果裝置不支援閃燈解鎖，請將
ro.oem_unlock_supported 設為 0。
如果裝置支援閃燈解鎖功能，則 Bootloader 應透過將核心指令列變數 androidboot.flash.locked 設為 1 (如果已鎖定) 或 0 (如果已解鎖)，來指出鎖定狀態。這個變數必須在 Android 12 的 bootconfig 中設定，而非在核心指令列中設定。
如果裝置支援 dm-verity，請使用 ro.boot.verifiedbootstate 將 ro.boot.flash.locked 的值設為 0；如果驗證開機程序狀態為橘色，這麼做就能解鎖啟動載入程式。
保護關鍵區段
裝置應支援鎖定及解鎖關鍵區塊，關鍵區塊是指裝置啟動至系統啟動載入程式時所需的任何內容。這類區段可能包括保險絲、感應器中樞的虛擬分區、第一階段的啟動載入程式等。如要鎖定關鍵區塊，您必須使用機制，防止在裝置上執行的程式碼 (核心、復原映像、OTA 程式碼等) 蓄意修改任何關鍵區塊。如果裝置處於鎖定重要狀態，OTA 應無法更新重要區段。
從鎖定狀態切換為解鎖狀態時，必須與裝置進行實體互動。這項互動類似於執行 fastboot flashing unlock 指令的效果，但需要使用者按下裝置上的實體按鈕。裝置不應允許在沒有實體互動情況下，以程式輔助方式從 lock critical 轉換為 unlock critical，且裝置不應以 unlock critical 狀態出貨。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。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,["# Lock and unlock the bootloader\n\nBy default, most Android devices ship with a locked bootloader, meaning that\nusers can't flash the bootloader or device partitions. If needed, you (and\ndevice users with Developer options enabled) can unlock the bootloader to flash\nnew images.\n\nGet into the bootloader\n-----------------------\n\nTo issue `fastboot` commands, you must be in the bootloader mode. One\nway to do this is to send the adb command `adb reboot bootloader`. Some phones\nalso allow you to reboot into the bootloader by pressing a key combination\n(commonly volume down) while booting the device.\n\nUnlock the bootloader\n---------------------\n\nOnce in the bootloader mode, to unlock the bootloader and enable partitions to\nbe reflashed, run the `fastboot flashing unlock` command on the device. After\nsetting, the unlock mode persists across reboots.\n\nDevices should deny the `fastboot flashing unlock` command unless the\n`get_unlock_ability` is set to `1`. If set to `0`, the user needs to boot to the\nhome screen, open the *Settings \\\u003e System \\\u003e Developer options* menu\nand enable the **OEM unlocking** option (which sets the `get_unlock_ability`\nto `1`). After setting, this mode persists across reboots and factory data\nresets.\n\nWhen the `fastboot flashing unlock` command is sent, the device should prompt\nusers to warn them that they might encounter problems with unofficial images.\nAfter the user acknowledges the warning, the device should perform a factory\ndata reset to prevent unauthorized data access. The bootloader should reset the\ndevice even if it can't reformat it properly. Only after a reset can the\npersistent flag be set so that the device can be reflashed.\n\nAll RAM not already overwritten should be reset during the\n`fastboot flashing unlock` process. This measure prevents attacks that read\nleftover RAM contents from the previous boot. Similarly, unlocked devices should\nclear RAM at every boot (unless this creates an unacceptable delay), but\nshould leave the region used for the kernel's\n[`ramoops`](https://www.kernel.org/doc/html/v4.12/admin-guide/ramoops.html).\n\nLock the bootloader\n-------------------\n\nTo lock the bootloader and reset the device, run the `fastboot flashing lock`\ncommand on the device. Devices intended for retail should be shipped in the\nlocked state (with `get_unlock_ability` returning `0`) to ensure that attackers\ncan't compromise the device by installing a new system or boot image.\n\nSet lock and unlock properties\n------------------------------\n\nThe `ro.oem_unlock_supported` property should be set at build time based on\nwhether the device supports flashing unlock.\n\n- If the device supports flashing unlock, set `ro.oem_unlock_supported` to `1`.\n- If the device doesn't support flashing unlock, set `ro.oem_unlock_supported` to `0`.\n\nIf the device supports flashing unlock, then the bootloader should indicate the\nlock status by setting the kernel command line variable\n`androidboot.flash.locked` to `1` if locked or to `0` if unlocked. This variable\nmust be set in bootconfig instead of in the kernel command line in Android 12.\n\nFor devices that support [dm-verity](/docs/security/features/verifiedboot/dm-verity),\nuse `ro.boot.verifiedbootstate` to set the value of `ro.boot.flash.locked` to\n`0`; this unlocks the bootloader if the verified boot state is orange.\n\nProtect critical sections\n-------------------------\n\nDevices should support the locking and unlocking of critical sections, which are\ndefined as whatever is needed to boot the device into the bootloader. Such\nsections might include fuses, virtual partitions for a sensor hub, first-stage\nbootloader, and more. To lock critical sections, you must use a mechanism that\nprevents code (kernel, recovery image, OTA code, etc.) that is running on the\ndevice from deliberately modifying any critical section. OTAs should fail to\nupdate critical sections if the device is in lock critical state.\n\nTransitioning from locked to unlocked state should require a physical\ninteraction with the device. This interaction is similar to what the effects of\nrunning the `fastboot flashing unlock` command but requires the user to press\na physical button on the device. Devices shouldn't allow programmatically\ntransitioning from `lock critical` to `unlock critical` without physical\ninteraction, and devices shouldn't ship in the `unlock critical` state."]]
