Locking/Unlocking the Bootloader

By default, most Android devices ship with a locked bootloader, meaning that users can't flash the bootloader or device partitions. If needed, you (and device users with Developer options enabled) can unlock the bootloader to flash new images.

Unlocking the bootloader

To unlock the bootloader and enable partitions to be reflashed, run the fastboot flashing unlock command on the device. After setting, the unlock mode persists across reboots.

Devices should deny the fastboot flashing unlock command unless the get_unlock_ability is set to 1. If set to 0, the user needs to boot to the home screen, open the Settings > System > Developer options menu and enable the OEM unlocking option (which sets the get_unlock_ability to 1). After setting, this mode persists across reboots and factory data resets.

When the fastboot flashing unlock command is sent, the device should prompt users to warn them that they might encounter problems with unofficial images. After the user acknowledges the warning, the device should perform a factory data reset to prevent unauthorized data access. The bootloader should reset the device even if it can't reformat it properly. Only after a reset can the persistent flag be set so that the device can be reflashed.

All RAM not already overwritten should be reset during the fastboot flashing unlock process. This measure prevents attacks that read leftover RAM contents from the previous boot. Similarly, unlocked devices should clear RAM at every boot (unless this creates an unacceptable delay), but should leave the region used for the kernel's ramoops.

Locking the bootloader

To lock the bootloader and reset the device, run the fastboot flashing lock command on the device. Devices intended for retail should be shipped in the locked state (with get_unlock_ability returning 0) to ensure that attackers can't compromise the device by installing a new system or boot image.

Setting lock/unlock properties

The ro.oem_unlock_supported property should be set at build time based on whether the device supports flashing unlock.

  • If the device supports flashing unlock, set ro.oem_unlock_supported to 1.
  • If the device doesn't support flashing unlock, set ro.oem_unlock_supported to 0.

If the device supports flashing unlock, then the bootloader should indicate the lock status by setting the kernel command line variable androidboot.flash.locked to 1 if locked or to 0 if unlocked. This variable must be set in bootconfig instead of in the kernel command line in Android 12.

For devices that support dm-verity, use ro.boot.verifiedbootstate to set the value of ro.boot.flash.locked to 0; this unlocks the bootloader if the verified boot state is orange.

Protecting critical sections

Devices should support the locking and unlocking of critical sections, which are defined as whatever is needed to boot the device into the bootloader. Such sections might include fuses, virtual partitions for a sensor hub, first-stage bootloader, and more. To lock critical sections, you must use a mechanism that prevents code (kernel, recovery image, OTA code, etc.) that is running on the device from deliberately modifying any critical section. OTAs should fail to update critical sections if the device is in lock critical state.

Transitioning from locked to unlocked state should require a physical interaction with the device. This interaction is similar to what the effects of running the fastboot flashing unlock command but requires the user to press a physical button on the device. Devices shouldn't allow programmatically transitioning from lock critical to unlock critical without physical interaction, and devices shouldn't ship in the unlock critical state.