自 2025 年 3 月 27 日起，我们建议您使用 android-latest-release 而非 aosp-main 构建 AOSP 并为其做出贡献。如需了解详情，请参阅 AOSP 的变更。
锁定和解锁引导加载程序
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
默认情况下，大多数 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 命令后，设备应提示用户，警告他们非官方映像可能存在问题。在用户确认收到警告后，设备应恢复出厂设置，以防止未经授权的数据访问。即使引导加载程序无法正确对设备执行重新格式化，也应重置设备。只有在恢复出厂设置后，才能设置持久标志，以便重新刷写设备。
所有尚未覆盖的 RAM 都应在 fastboot flashing unlock 过程中被重置。此措施可防止出现读取上次启动剩余 RAM 内容的攻击。同样，解锁的设备应在每次启动时清除 RAM（除非这样做会造成不可接受的延迟），但应保留供内核的 ramoops 使用的区域。
锁定引导加载程序
如需锁定引导加载程序并重置设备，请在设备上运行 fastboot flashing lock 命令。打算零售的设备应以锁定状态发货（让 get_unlock_ability 返回 0），确保攻击者不能通过安装新的系统或启动映像来入侵设备。
设置锁定和解锁属性
ro.oem_unlock_supported 属性应在构建时根据设备是否支持刷写解锁来设置。
- 如果设备支持刷写解锁，请将
ro.oem_unlock_supported 设置为 1。
- 如果设备不支持刷写解锁，请将
ro.oem_unlock_supported 设置为 0。
如果设备支持刷写解锁，引导加载程序应通过将内核命令行变量 androidboot.flash.locked 设置为 1（如果已锁定）或 0（如果已解锁）来指示锁定状态。在 Android 12 中，必须在 bootconfig（而非内核命令行）内设置此变量。
对于支持 dm-verity 的设备，请使用 ro.boot.verifiedbootstate 将 ro.boot.flash.locked 的值设置为 0；如果启动时验证状态显示为橙色，此操作可解锁引导加载程序。
保护关键部分
设备应支持锁定和解锁关键部分（指将设备启动到引导加载程序所需的任何部分）。这些部分可能包括 fuse、传感器中枢的虚拟分区、第一阶段引导加载程序等。如需锁定关键部分，您必须采用一种机制，阻止设备上运行的代码（内核、恢复映像和 OTA 代码等）故意修改任何关键部分。如果设备处于锁定关键部分状态，OTA 应无法更新关键部分。
从锁定状态转换为解锁状态应需要与设备进行物理交互。此类交互的效果类似于运行 fastboot flashing unlock 命令，但要求用户按下设备上的实体按钮。设备不应允许在没有进行物理交互的情况下以程序化方式从 lock critical 状态转换为 unlock critical 状态，并且设备不应以 unlock critical 状态推出。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-03-26。
[[["易于理解","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"]],["最后更新时间 (UTC)：2025-03-26。"],[],[],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."]]
