2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main 대신 android-latest-release를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
부트로더 개요
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
부트로더는 기기에 커널을 불러오는 공급업체 독점 이미지입니다. 부트로더는 기기 상태를 보호하고 신뢰할 수 있는 실행 환경(TEE)의 초기화 및 신뢰할 수 있는 루트의 결합을 담당합니다. 또한 부트로더는 실행을 커널로 이동하기 전에 boot 및 recovery 파티션의 무결성을 확인합니다.
부트로더 흐름의 예
다음은 부트로더 흐름의 예입니다.
메모리를 로드하고 초기화합니다.
자체 검사 부팅 흐름에 따라 기기를 확인합니다.
자체 검사 부팅 흐름에 따라 boot, dtbo, init_boot, recovery를 포함한 부팅 파티션을 확인합니다. 이 단계의 일부로 부팅 이미지 헤더 버전을 확인하고 그에 따라 헤더를 파싱합니다.
A/B 업데이트를 사용하는 경우 부팅할 현재 슬롯을 결정합니다.
복구 모드를 부팅해야 하는지 결정합니다. 자세한 내용은 OTA 업데이트 지원을 참고하세요.
부팅 이미지(예: boot.img, vendor_boot.img, init_boot.img, 기타 독점 공급업체 부팅 이미지)를 로드합니다. 이러한 부팅 이미지에는 커널 및 램디스크 이미지가 포함됩니다.
자체적으로 실행할 수 있는 압축된 바이너리로 커널을 메모리에 로드합니다. 커널은 자체적으로 압축을 풀고 메모리로의 실행을 시작합니다.
램디스크와 bootconfig 섹션을 메모리에 로드하여 initramfs를 만듭니다.
추가 부트로더 관련 기능
다음은 구현할 수 있는 추가 부트로더 관련 기능 목록입니다.
기기 트리 오버레이(DTO).
기기 트리 오버레이를 사용하면 부트로더가 다양한 하드웨어 구성을 지원할 수 있습니다. DTO는 부트로더에서 사용하는 기기 트리 blob(DTB)으로 컴파일됩니다.
커널 이미지 가상 주소 무작위 지정. 부트로더는 커널 이미지가 로드되는 가상 주소의 무작위 지정을 지원합니다. 주소를 무작위로 지정하려면 커널 구성에서 RANDOMIZE_BASE를 true로 설정합니다.
부트로더는 /chosen/kaslr-seed 기기 트리 노드에서 임의의 u64 값을 전달하여 엔트로피를 제공해야 합니다.
자체 검사 부팅. 자체 검사 부팅을 사용하면 실행된 모든 코드의 출처가 신뢰할 수 있는 소스인지 부트로더에서 확인할 수 있습니다.
부팅 구성.
부팅 구성은 Android 12 이상에서 사용할 수 있으며 빌드 및 부트로더에서 운영체제로 구성 세부정보를 전달하는 메커니즘입니다.
Android 12 전에는 androidboot 접두사가 있는 커널 명령줄 매개변수가 사용되었습니다.
무선 업데이트(OTA). 일반 Android 기기는 시스템, 앱 소프트웨어, 시간대 규칙에 관한 OTA 업데이트를 수신하여 설치할 수 있습니다. 이 기능은 부트로더 구현에 영향을 미칩니다. OTA에 관한 일반 정보는 OTA 업데이트를 참고하세요. 부트로더별 OTA 구현 세부정보는 OTA 업데이트 지원을 참고하세요.
버전 결합.
버전 결합은 보안 키를 운영체제 및 패치 수준 버전에 결합합니다. 버전 결합을 사용하면 이전 버전의 시스템 또는 TEE 소프트웨어에서 취약점을 발견한 공격자가 기기를 취약한 버전으로 롤백하여 최신 버전으로 만든 키를 사용할 수 없습니다. 부트로더는 버전 결합을 지원하기 위해 특정 정보를 제공해야 합니다. 자세한 내용은 AVB 속성의 버전 정보를 참고하세요.
커널 명령줄
다음 위치에서 커널 명령줄을 연결합니다.
부트로더 명령줄: 부트로더에 의해 결정되는 정적 및 동적 매개변수 집합
기기 트리: chosen/bootargs 노드에서
defconfig: CONFIG_CMDLINE에서
boot.img: 명령줄에서(오프셋 및 크기는 system/core/mkbootimg/bootimg.h 참고)
Android 12부터는 Android 사용자 공간에 전달해야 하는 androidboot.* 매개변수의 경우 커널 명령줄 대신 bootconfig를 사용할 수 있습니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 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,["# Bootloader overview\n\nA *bootloader* is a vendor-proprietary image responsible for bringing up the\nkernel on a device. The bootloader guards the device state and is responsible\nfor initializing the [Trusted Execution Environment (TEE)](/docs/security/features/trusty)\nand binding its root of trust. The bootloader also verifies the integrity of the\n`boot` and `recovery` partitions before moving execution to the kernel.\n\nExample bootloader flow\n-----------------------\n\nHere's an example bootloader flow:\n\n1. Load and initialize memory.\n\n2. Verify the device according to [Verified Boot flow](/docs/security/features/verifiedboot).\n\n3. Verify the boot partitions, including `boot`, `dtbo`, `init_boot`, and\n `recovery`, according to the Verified Boot flow. As part of this step, check the\n [boot image header](/docs/core/architecture/bootloader/boot-image-header)\n version and parse the header accordingly.\n\n4. If [A/B updates](/docs/core/ota/ab) are used, determine the current slot to\n boot.\n\n5. Determine if recovery mode should be booted. For more\n information, see\n [Supporting OTA Updates](/docs/core/architecture/bootloader/updating).\n\n6. Load the boot images, such as `boot.img`, `vendor_boot.img`,\n `init_boot.img`, and other proprietary vendor boot images. These boot images\n contain the kernel and ramdisk images.\n\n 1. Load the kernel into memory as a self-executable compressed\n binary. The kernel decompresses itself and starts executing into memory.\n\n 2. Load ramdisks and the bootconfig section into memory\n to create `initramfs`.\n\nAdditional bootloader-related features\n--------------------------------------\n\nFollowing is a list of additional bootloader-related features that you can\nimplement:\n\n- *Device tree overlay (DTO).*\n A [device tree overlay](/docs/core/architecture/dto) lets the bootloader to\n support different hardware configurations. A DTO is compiled into a *device\n tree blob (DTB)* which is used by the bootloader.\n\n- *Kernel image virtual address randomization.* The bootloader supports\n randomizing the virtual address at which the kernel image is loaded. To\n randomize the address, set `RANDOMIZE_BASE` to `true` in the kernel config.\n The bootloader must provide entropy by passing a random u64 value in the\n `/chosen/kaslr-seed` device tree node.\n\n- *Verified Boot.* [Verified Boot](/docs/security/features/verifiedboot) lets\n the bootloader to ensure all executed code comes from a trusted source.\n\n- *Boot config.*\n [Boot config](/docs/core/architecture/bootloader/implementing-bootconfig)\n is available in Android 12 and higher and is a mechanism for passing\n configuration details from the build and bootloader to the operating system.\n Prior to Android 12, kernel command-line parameters with the prefix of\n `androidboot` are used.\n\n- *Over-the-air (OTA) updates.* Android devices in the field can receive and\n install OTA updates to the system, app software, and\n time zone rules. This feature has implications on your bootloader\n implementation. For general information on OTA, see\n [OTA updates](/docs/core/ota). For bootloader-specific OTA implementation\n details, see\n [Supporting OTA updates](/docs/core/architecture/bootloader/updating).\n\n- *Version binding* .\n [Version binding](/docs/security/features/keystore/version-binding) binds\n security keys to the operating system and patch level version. Version binding\n ensures that an attacker who discovers a weakness in an old version of the\n system or the TEE software can't roll a device back to the vulnerable version\n and use keys created with the newer version. The bootloader must provide certain\n information to support version binding. For further information, see\n [Version information in AVB properties](/docs/core/architecture/bootloader/version-info-avb).\n\nKernel command line\n-------------------\n\nConcatenate the kernel command line from the following locations:\n\n- Bootloader command line: set of static and dynamic parameters determined by\n the bootloader\n\n- Device tree: from the `chosen/bootargs` node\n\n- `defconfig`: from `CONFIG_CMDLINE`\n\n- `boot.img`: from the command line (for offsets and sized, refer to\n [`system/core/mkbootimg/bootimg.h`](https://android.googlesource.com/platform/system/tools/mkbootimg/+/refs/heads/android16-release/include/bootimg/bootimg.h)\n\nAs of Android 12, for `androidboot.*` parameters that\nwe need to pass to Android userspace, we can use\n[bootconfig](/docs/core/architecture/bootloader/implementing-bootconfig) instead\nof the kernel command line."]]
