2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main 대신 android-latest-release를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
기기 상태
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
기기 상태는 소프트웨어가 기기에 얼마나 자유롭게 플래시될 수 있는지와 인증이 적용되는지 여부를 나타냅니다. 기기 상태는 LOCKED 및 UNLOCKED 상태가 있습니다. LOCKED 기기에서는 새 소프트웨어를 기기에 플래시하지 못하지만 UNLOCKED 기기에서는 수정할 수 있습니다.
기기 전원이 켜지면 부트로더는 먼저 기기가 LOCKED 또는 UNLOCKED 상태인지 확인합니다. 기기가 UNLOCKED 상태라면 부트로더는 사용자에게 경고를 표시한 후 로드된 OS가 신뢰할 수 있는 루트에 의해 서명되지 않았더라도 부팅을 진행합니다.
기기가 LOCKED 상태라면 부트로더는 자체 검사 부팅 단계를 거쳐 기기의 소프트웨어를 확인합니다. LOCKED 기기는 오직 로드된 OS가 신뢰할 수 있는 루트에 의해 올바르게 서명된 때에만 부팅됩니다. 자세한 내용은 부팅 흐름을 참조하세요.
기기 상태 변경
기기의 상태를 변경하려면 fastboot flashing [unlock | lock] 명령어를 사용합니다. 사용자 데이터를 보호하려면 모든 상태 전환 시 데이터 파티션을 완전 삭제하고 데이터를 삭제하기 전에 사용자 확인을 요청합니다.
사용자가 중고 개발 기기를 구매할 때는 UNLOCKED에서 LOCKED로 상태 전환이 예상됩니다. 기기 잠금의 결과로 사용자는 경고가 없는 한 기기가 기기 제조업체에서 제작한 상태임을 확신할 수 있습니다. 개발자가 개발 목적으로 기기에서 인증을 사용 중지하려는 때에는 LOCKED에서 UNLOCKED로의 상태 전환이 예상됩니다.
신뢰할 수 있는 루트
신뢰할 수 있는 루트는 기기에 저장된 Android 사본에 서명하는 데 사용되는 암호화 키입니다. 신뢰할 수 있는 루트의 비공개 부분은 기기 제조업체만 알고 있으며 모든 버전의 배포용 Android에 서명하는 데 사용됩니다. 신뢰할 수 있는 루트의 공개 부분은 기기에 내장되어 있으며 무단으로 변경할 수 없도록 적절한 위치 (일반적으로 읽기 전용 저장소)에 저장됩니다.
Android 로드 시 부트로더는 신뢰할 수 있는 루트를 사용하여 진위를 확인합니다. 이 프로세스에 관한 자세한 내용은 자체 검사 부팅을 참조하세요. 기기에 여러 부트로더가 있을 수 있으며 여러 개의 암호화 키가 작동 중일 수 있습니다.
사용자 설정 가능한 신뢰할 수 있는 루트
기기는 선택적으로 사용자가 신뢰할 수 있는 루트(예: 공개 키)를 구성할 수 있게 합니다. 기기는 내장된 신뢰할 수 있는 루트 외에도 자체 검사 부팅에 이 사용자 설정 가능한 신뢰할 수 있는 루트를 사용할 수 있으며 Google Pixel 기기는 이를 사용합니다.
사용자 설정 가능한 신뢰할 수 있는 루트를 구현한다면 다음과 같은 방식으로 진행해야 합니다.
- 사용자 설정 가능한 신뢰할 수 있는 루트를 설정/삭제하려면 실제 확인이 필요합니다.
- 사용자 설정 가능한 신뢰할 수 있는 루트는 최종 사용자만 설정할 수 있습니다. 최종 사용자가 기기를 얻기 전에 공장 출하 시에 또는 중간 지점에서 신뢰할 수 있는 루트를 설정할 수 없습니다.
- 사용자 설정 가능한 신뢰할 수 있는 루트는 변조 탐지 가능 저장소에 저장됩니다.
변조 탐지 가능은 예를 들어 데이터가 덮어 쓰이거나 변경되었다면 Android가 데이터를 변조했는지 여부를 감지할 수 있음을 의미합니다.
- 사용자 설정 가능한 신뢰할 수 있는 루트가 설정되었다면 기기는 내장된 신뢰할 수 있는 루트 또는 사용자 설정 가능한 신뢰할 수 있는 루트로 서명된 Android 버전을 허용해야 합니다.
- 사용자 설정 가능한 신뢰할 수 있는 루트를 사용하여 기기를 부팅할 때마다 기기에 맞춤 버전의 Android가 로드되고 있음을 사용자에게 알려야 합니다. 경고 화면의 예는 맞춤 키가 설정된
LOCKED 기기를 참조하세요.
사용자 설정 가능한 신뢰할 수 있는 루트를 구현하는 한 가지 방법은 기기가 UNLOCKED 상태일 때만 플래시하거나 삭제할 수 있는 가상 파티션을 갖는 것입니다. Google Pixel 2 기기는 이 방법을 사용하며 가상 파티션은 avb_custom_key라고 합니다. 이 파티션의 데이터 형식은 avbtool extract_public_key 명령어의 출력입니다. 다음은 사용자 설정 가능한 신뢰할 수 있는 루트를 설정하는 방법의 예입니다.
avbtool extract_public_key --key key.pem --output pkmd.bin
fastboot flash avb_custom_key pkmd.bin
사용자 설정 가능한 신뢰할 수 있는 루트는 다음을 실행하여 삭제할 수 있습니다.
fastboot erase avb_custom_key
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 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,["# Device state\n\nThe device state indicates how freely software can be flashed to a device and\nwhether verification is enforced. Device states are `LOCKED` and\n`UNLOCKED`. `LOCKED` devices prevent you from flashing new\nsoftware to the device, whereas `UNLOCKED` devices allow\nmodification.\n\n\nWhen a device powers on, the bootloader first checks if a device is\n`LOCKED` or `UNLOCKED`. If a device is\n`UNLOCKED`, the bootloader shows the user a warning and then proceeds\nto boot even if the loaded OS isn't signed by the root of trust.\n\n\nIf the device is `LOCKED`, the bootloader goes through the steps in\n[Verifying Boot](/docs/security/features/verifiedboot/verified-boot) to verify\nthe device's software. `LOCKED` devices boot *only* if the\nloaded OS is properly signed by the root of trust. For more details, see\n[The boot flow](/docs/security/features/verifiedboot/boot-flow).\n\nChange device state\n-------------------\n\n\nTo [change a device's state](/docs/core/architecture/bootloader/locking_unlocking), use\nthe `fastboot flashing [unlock | lock]` command. To protect user\ndata, *all* state transitions wipe the data partitions and ask for user\nconfirmation before data is deleted.\n\n\nThe `UNLOCKED` to `LOCKED` transition is anticipated when\na user buys a used development device. As a result of locking the device, the\nuser should have confidence that it is in a state produced by the device\nmanufacturer, as long as there is no warning. The `LOCKED` to\n`UNLOCKED` transition is expected when a developer wishes to disable\nverification on the device for development purposes.\n\nRoot of trust\n-------------\n\n\n*Root of trust* is the cryptographic key used to sign the copy of Android\nstored on the device. The private part of the root of trust is known only to the\ndevice manufacturer and is used to sign every version of Android intended for\ndistribution. The public part of the root of trust is embedded in the device and\nis stored in a place so it can't be tampered with (typically read-only\nstorage).\n\n\nWhen it loads Android, the bootloader uses the root of trust to verify\nauthenticity. For more details on this process, see\n[Verifying Boot](/docs/security/features/verifiedboot/verified-boot). Devices may have\nmultiple boot loaders and as such multiple cryptographic keys may be in play.\n\n### User-settable root of trust\n\n\nDevices can optionally allow the user to configure the root of trust (for\nexample, a public key). Devices can, and Google Pixel devices do, use this\nuser-settable root of trust for Verified Boot in addition to the built-in\nroot of trust.\n\n\nIf user-settable root of trust is implemented, it should be done in a way such\nthat:\n\n- Physical confirmation is required to set/clear the user-settable root of trust.\n- The user-settable root of trust can only be set by the end user. It can't be set at the factory or any intermediate point before the end user gets the device.\n- The user-settable root of trust is stored in tamper-evident storage. *Tamper-evident* means that it's possible to detect if Android has tampered with the data, for example, if it has been overwritten or changed.\n- If a user-settable root of trust is set, the device should allow a version of Android signed with either the built-in root of trust or the user-settable root of trust to boot.\n- Every time the device boots using the user-settable root of trust, the user should be notified that the device is loading a custom version of Android. For example, warning screens, see [`LOCKED`\n devices with custom key set](/docs/security/features/verifiedboot/boot-flow#locked-devices-with-custom-key-set).\n\n\nOne way of implementing user-settable root of trust is to have a virtual\npartition that can only be flashed or cleared when the device is in the\n`UNLOCKED` state. The Google Pixel 2 devices use this approach and\nthe virtual partition is called `avb_custom_key`. The format of the\ndata in this partition is the output of the\n`avbtool extract_public_key` command. Here's an example of how to set\nthe user-settable root of trust: \n\n avbtool extract_public_key --key key.pem --output pkmd.bin\n fastboot flash avb_custom_key pkmd.bin\n\n\nThe user-settable root of trust can be cleared by issuing: \n\n```\nfastboot erase avb_custom_key\n```"]]
