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.
Get into the bootloader
To issue fastboot commands, you must be in the bootloader mode. One
way to do this is to send the adb command adb reboot bootloader. Some phones
also allow you to reboot into the bootloader by pressing a key combination
(commonly volume down) while booting the device.
Unlock the bootloader
Once in the bootloader mode, 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.
Lock 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.
Set lock and 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_supportedto1. - If the device doesn't support flashing unlock, set
ro.oem_unlock_supportedto0.
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.
Protect 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.