2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main 대신 android-latest-release를 사용하는 것이 좋습니다. 자세한 내용은 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으로 설정합니다. 그러면 자체 검사 부팅 상태가 주황색일 때 부트로더의 잠금이 해제됩니다.
중요 섹션 보호
기기는 부트로더로 기기를 부팅하는 데 필요한 모든 것으로 정의되는 중요 섹션의 잠금 및 잠금 해제를 지원해야 합니다. 이러한 섹션에는 퓨즈, 센서 허브용 가상 파티션, 1단계 부트로더 등이 포함될 수 있습니다. 중요 섹션을 잠그려면 기기에서 실행 중인 코드(커널, 복구 이미지, OTA 코드 등)가 중요 섹션을 의도적으로 수정하지 못하게 방지하는 메커니즘을 사용해야 합니다. 기기가 잠금 중요 상태인 경우 OTA는 중요 섹션을 업데이트하지 못합니다.
잠금 상태에서 잠금 해제 상태로 전환하려면 기기와의 물리적 상호작용이 필요합니다. 이 상호작용은 fastboot flashing unlock 명령어를 실행한 결과와 유사하지만 사용자가 기기의 실제 버튼을 눌러야 합니다. 기기는 물리적 상호작용 없이 프로그래매틱 방식으로 lock critical에서 unlock critical로 전환하는 것을 허용해서는 안 되고 unlock critical 상태로 배송되면 안 됩니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(UTC)
[[["이해하기 쉬움","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(UTC)"],[],[],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."]]
