무선 업데이트(OTA)를 지원하려면 부트로더가 부팅 중에 복구 RAM 디스크에 액세스할 수 있어야 합니다. 기기에서 수정되지 않은 AOSP 복구 이미지를 사용하면 부트로더는 misc 파티션의 처음 32바이트를 읽습니다. 그 데이터가 boot-recovery와 일치하면 부트로더는 recovery 이미지로 부팅됩니다. 이 메서드를 사용하면 대기 중인 복구 작업(예: OTA 적용 또는 데이터 삭제)이 계속 완료될 수 있습니다.
A/B 업데이트를 사용하는 기기에서 OTA 업데이트를 지원하려면 기기 부트로더가 다음 기준을 충족해야 합니다.
일반 기준
OTA를 통해 업데이트된 모든 파티션은 기본 시스템이 부팅되는 동안 업데이트할 수 있어야 합니다(복구 시 업데이트되지 않음).
system 파티션을 부팅하기 위해 부트로더는 커널 명령줄에 다음 값을 전달합니다. ro root=/dev/[node] rootwait init=/init
HAL에서 markBootSuccessful을 호출하는 것은 Android 프레임워크의 책임입니다. 부트로더는 파티션을 부팅 완료로 절대 표시해서는 안 됩니다.
부팅 제어 HAL 지원
부트로더는 hardware/libhardware/include/hardware/boot_control.h에 정의된 boot_control HAL을 지원해야 합니다. 업데이터는 부팅 제어 HAL을 쿼리하고 현재 사용하지 않는 부팅 슬롯을 업데이트하며 HAL을 사용하여 활성 슬롯을 변경한 후 업데이트된 운영체제로 재부팅합니다. 자세한 내용은 부팅 제어 HAL 구현을 참고하세요.
슬롯 지원
부트로더는 다음을 비롯하여 파티션 및 슬롯과 관련된 기능을 지원해야 합니다.
파티션 이름에는 부트로더에서 특정 슬롯에 속하는 파티션을 식별하는 접미사가 포함되어야 합니다. 이러한 각 파티션에는 값이 yes인 상응하는 변수 has-slot:partition base name이 있습니다. 슬롯의 이름은 접미사가 _a, _b, _c 등인 파티션에 상응하는 a, b, c 등 알파벳순으로 지정됩니다. 부트로더는 명령줄 속성 androidboot.slot_suffix를 사용하여 부팅된 슬롯을 운영체제에 알려야 합니다. 이 속성은 Android 12 이상으로 출시되는 기기의 bootconfig를 통해 설정됩니다.
slot-retry-count 값은 setActiveBootSlot 콜백을 통해 부팅 제어 HAL에서 또는 fastboot set_active 명령어를 통해 양의 값(보통 3)으로 재설정됩니다. 슬롯의 일부인 파티션을 수정할 때 부트로더는 'successfully booted'를 삭제하고 슬롯의 재시도 횟수를 재설정합니다.
부트로더는 로드할 슬롯도 결정합니다. 그림은 결정 프로세스 예를 보여 줍니다.
그림 1. 부트로더 슬롯 처리 흐름
시도할 슬롯을 결정합니다. slot-unbootable로 표시된 슬롯을 로드해서는 안 됩니다. 이 슬롯은 빠른 부팅에서 반환한 값과 일치해야 하고 현재 슬롯이라고 합니다.
현재 슬롯이 slot-successful로 표시되지 않고 slot-retry-count = 0을 보유하면 현재 슬롯을 slot-unbootable로 표시합니다. 그런 다음 unbootable로 표시되지 않고 slot-successful로 표시된 다른 슬롯을 선택합니다. 이제 이 슬롯이 선택된 슬롯입니다. 사용 가능한 현재 슬롯이 없는 경우 복구로 부팅하거나 사용자에게 도움이 되는 오류 메시지를 표시합니다.
적절한 boot.img를 선택하고 커널 명령줄에서 올바른 시스템 파티션 경로를 포함합니다.
커널 명령줄 slot_suffix 매개변수를 채웁니다.
부팅합니다. slot-successful로 표시되지 않으면 slot-retry-count를 줄입니다.
fastboot 유틸리티는 플래시 명령어를 실행할 때 플래시할 파티션을 결정합니다. 예를 들어 fastboot flash system system.img 명령어를 실행하면 먼저 current-slot 변수를 쿼리하고 결과를 시스템에 연결하여 플래시해야 하는 파티션의 이름을 생성합니다(system_a, system_b 등).
빠른 부팅 set_active 명령어나 부팅 제어 HAL setActiveBootSlot 명령어를 사용하여 현재 슬롯을 설정할 때 부트로더는 현재 슬롯을 업데이트하고 slot-unbootable과 slot-successful을 삭제하고 재시도 횟수를 재설정합니다(slot-unbootable을 삭제하는 유일한 방법).
A/B 업데이트가 없는 기기
A/B 업데이트를 사용하지 않는 기기에서 OTA 업데이트를 지원하려면(A/B 업데이트가 불가능한 기기 참고) 기기 부트로더가 다음 기준을 충족해야 합니다.
recovery 파티션에는 지원되는 일부 파티션 (cache, userdata)에서 시스템 이미지를 읽고 system 파티션에 쓸 수 있는 이미지가 있어야 합니다.
부트로더는 복구 모드로 바로 재부팅할 수 있도록 지원해야 합니다.
라디오 이미지 업데이트가 지원된다면 recovery 파티션도 라디오를 플래시할 수 있어야 합니다. 이는 다음 두 가지 방법 중 하나를 통해 이루어질 수 있습니다.
부트로더가 라디오를 플래시합니다. 이 경우 복구 파티션에서 부트로더로 재부팅하여 업데이트를 완료합니다.
복구 이미지가 라디오를 플래시합니다. 이 기능은 바이너리 라이브러리나 유틸리티로 제공될 수 있습니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2024-05-02(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"]],["최종 업데이트: 2024-05-02(UTC)"],[],[],null,["# Implement OTA updates\n\nTo implement the [over-the-air (OTA) updates](/docs/core/ota), the\nbootloader must be able to access a recovery RAM disk during boot. If the device\nuses an unmodified AOSP recovery image, the bootloader reads the first 32 bytes\non the `misc` partition; if the data there matches `boot-recovery`, the\nbootloader boots into the `recovery` image. This method enables any pending\nrecovery work (for example, applying an OTA or removing data) to continue to\ncompletion.\n\nFor details on the content of a block in flash used for communications by\nrecovery and the bootloader, refer to\n[bootable/recovery/bootloader_message/bootloader_message.h](https://android.googlesource.com/platform/bootable/recovery/+/android16-release/bootloader_message/include/bootloader_message/bootloader_message.h#64).\n\nDevices with A/B updates\n------------------------\n\nTo support OTA updates on devices that use [A/B\nupdates](/docs/core/ota/ab), ensure that the device bootloader meets\nthe following criteria.\n\n### General criteria\n\n- All partitions updated through an OTA should be updatable while the main\n system is booted (and not updated in recovery).\n\n- To boot the `system` partition, the bootloader passes the following value on\n kernel command line: `ro root=/dev/[node] rootwait init=/init`.\n\n- It's the responsibility of the Android framework to call `markBootSuccessful`\n from the HAL. The bootloader should never mark a partition as successfully\n booted.\n\n### Support for boot control HAL\n\nThe bootloader must support the `boot_control` HAL as defined in\n`hardware/libhardware/include/hardware/boot_control.h`. The updater queries the\n[boot control\nHAL](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/boot/1.0/IBootControl.hal),\nupdates the boot slot not in use, changes the active slot using the\nHAL, and reboots into the updated operating system. For details, see\n[Implementing the boot control\nHAL](/docs/core/ota/ab/ab_implement#bootcontrol).\n\n### Support for slots\n\nThe bootloader must support functionality related to partitions and slots,\nincluding:\n\n- Partition names must include a suffix that identifies which partitions\n belong to a particular slot in the bootloader. For each such partition,\n there's a corresponding variable\n `has-slot:`\u003cvar translate=\"no\"\u003epartition base name\u003c/var\u003e with a value of\n `yes`. Slots are named alphabetically as a, b, c, etc. corresponding to\n partitions with the suffix `_a`, `_b`, `_c`, etc. The bootloader should inform\n the operating system which slot was booted using the command line property\n `androidboot.slot_suffix`. This property is set through bootconfig for devices\n launching with Android 12 or higher.\n\n- The `slot-retry-count` value is reset to a positive value (usually `3`),\n either by the boot control HAL through the `setActiveBootSlot` callback or\n through the `fastboot set_active` command. When modifying a partition that's\n part of a slot, the bootloader clears \"successfully booted\" and resets the\n retry count for the slot.\n\nThe bootloader should also determine which slot to load. The figure shows an\nexample decision process.\n**Figure 1.** Bootloader slotting flow\n\n1. Determine which slot to attempt. Don't attempt to load a slot marked\n `slot-unbootable`. This slot should be consistent with the values returned by\n fastboot, and is referred to as the current slot.\n\n2. If the current slot isn't marked as `slot-successful` and has a\n `slot-retry-count = 0`, mark the current slot as `slot-unbootable`. Then\n select a different slot that is not marked `unbootable` and is marked as\n `slot-successful`; this slot is now the selected slot. If no current slot is\n available, boot to recovery or display a meaningful error message to the\n user.\n\n3. Select the appropriate `boot.img` and include the path to correct system\n partition on the kernel command line.\n\n4. Populate the kernel command line `slot_suffix` parameter.\n\n5. Boot. If not marked `slot-successful`, decrement `slot-retry-count`.\n\nThe `fastboot` utility determines which partition to flash when running any\nflash commands. For example, running the `fastboot flash system system.img`\ncommand first queries the `current-slot` variable then concatenates the result\nto system to generate the name of the partition that should be flashed\n(`system_a`, `system_b`, etc.).\n\nWhen setting the current slot using the fastboot `set_active` command or the\nboot control HAL `setActiveBootSlot` command, the bootloader should update\nthe current slot, clear `slot-unbootable` and `slot-successful`, and reset the\nretry count (this is the only way to clear `slot-unbootable`).\n\nDevices without A/B updates\n---------------------------\n\nTo support OTA updates on devices that don't use A/B updates (see [Non-A/B\nupdatable devices](/docs/core/ota/nonab)), ensure that the device\nbootloader meets the following criteria.\n\n- The `recovery` partition should contain an image that is capable of reading a\n system image from some supported partition (`cache`, `userdata`) and writing\n it to the `system` partition.\n\n- The bootloader should support booting directly into recovery mode.\n\n- If radio image updates are supported, the `recovery` partition should also be\n able to flash the radio. This can be accomplished in one of two ways:\n\n - The bootloader flashes the radio. In this case, it should be possible to\n reboot from the recovery partition back into the bootloader to complete the\n update.\n\n - The recovery image flashes the radio. This functionality can be provided as\n a binary library or utility."]]
