Od 27 marca 2025 r. zalecamy używanie android-latest-release zamiast aosp-main do kompilowania i wspołtworzenia AOSP. Więcej informacji znajdziesz w artykule o zmianach w AOSP.
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Aby wdrożyć aktualizacje bezprzewodowe (OTA), program rozruchowy musi mieć dostęp do dysku RAM odzyskiwania podczas uruchamiania. Jeśli urządzenie używa niezmodyfikowanego obrazu odzyskiwania AOSP, program rozruchowy odczytuje pierwsze 32 bajty na partycji misc. Jeśli dane są zgodne z wartością boot-recovery, program rozruchowy uruchomi obraz recovery. Ta metoda umożliwia kontynuowanie nieukończonych działań związanych z przywracaniem (np. stosowaniem OTA lub usuwaniem danych).
Aby obsługiwać aktualizacje OTA na urządzeniach, które korzystają z aktualizacji A/B, upewnij się, że program rozruchowy urządzenia spełnia te kryteria.
Kryteria ogólne
Wszystkie partycje zaktualizowane przez OTA powinny być aktualizowane podczas uruchamiania głównego systemu (a nie w trybie odzyskiwania).
Aby uruchomić partycję system, bootloader przekazuje tę wartość w wierszu poleceń jądra: ro root=/dev/[node] rootwait init=/init.
Wywołania funkcji markBootSuccessfulz poziomu HAL należy do frameworka Androida. Program rozruchowy nigdy nie powinien oznaczać partycji jako uruchomionej.
Obsługa interfejsu HAL do sterowania rozruchem
Program rozruchowy musi obsługiwać interfejs boot_control HAL zgodnie z definicją w dokumentacji hardware/libhardware/include/hardware/boot_control.h. Aktualizator wysyła zapytanie do sterownika uruchamiania (HAL), aktualizuje nieużywany slot uruchamiania, zmienia aktywny slot za pomocą sterownika HAL i uruchamia ponownie zaktualizowany system operacyjny. Więcej informacji znajdziesz w artykule Implementacja kontroli uruchamiania HAL.
Obsługa przedziałów
Program rozruchowy musi obsługiwać funkcje związane z partycjami i gniazdami, w tym:
Nazwy partycji muszą zawierać przyrostek, który wskazuje, które partycje należą do konkretnego gniazda w bootloaderze. W przypadku każdej takiej partycji istnieje odpowiednia zmienna has-slot:partition base name o wartości yes. Miejsca są nazywane alfabetycznie (a, b, c itd.), co odpowiada partycjom z sufiksem _a, _b, _c itd. Ładowarka powinna poinformować system operacyjny, z którego miejsca na dane została załadowana pamięć, za pomocą właściwości wiersza poleceń androidboot.slot_suffix. Ta właściwość jest ustawiana za pomocą bootconfig na urządzeniach z Androidem 12 lub nowszym.
Wartość slot-retry-count jest resetowana do wartości dodatniej (zazwyczaj 3),
czy to przez interfejs HAL sterowania rozruchem za pomocą wywołania zwrotnego setActiveBootSlot, czy za pomocą polecenia fastboot set_active. Podczas modyfikowania partycji, która jest częścią slotu, bootloader usuwa flagę „booted successfully” i resetuje liczbę prób dla slotu.
Program rozruchowy powinien też określić, który slot ma być wczytany. Rysunek przedstawia przykładowy proces podejmowania decyzji.
Rysunek 1. Procedura tworzenia slotu dla programu rozruchowego
Określ, z którego slotu chcesz skorzystać. Nie próbuj wczytywać gniazda oznaczonego jako slot-unbootable. Ten slot powinien być zgodny z wartościami zwróconymi przez fastboot i jest nazywany bieżącym slotem.
Jeśli bieżący slot nie jest oznaczony jako slot-successful i ma wartość slot-retry-count = 0, oznacz go jako slot-unbootable. Następnie wybierz inne gniazdo, które nie jest oznaczone jako unbootable, ale jako slot-successful. To gniazdo będzie teraz wybrane. Jeśli nie ma dostępnego bieżącego slotu, należy uruchomić tryb odzyskiwania lub wyświetlić użytkownikowi odpowiedni komunikat o błędzie.
Wybierz odpowiednią wartość boot.img i dołącz ścieżkę do odpowiedniej partycji systemu w wierszu poleceń jądra.
Rozruch. Jeśli nie jest zaznaczone slot-successful, zmniejsz slot-retry-count.
Narzędzie fastboot określa, który partycji ma być flashowany podczas wykonywania poleceń flash. Na przykład wykonanie polecenia fastboot flash system system.img najpierw wysyła zapytanie do zmiennej current-slot, a potem łączy wynik z systemem, aby wygenerować nazwę partycji, którą należy zaprogramować (system_a, system_b itp.).
Podczas ustawiania bieżącego slotu za pomocą polecenia fastboot set_active lub polecenia kontroli uruchamiania setActiveBootSlot bootloader powinien zaktualizować bieżący slot, wyczyścić slot-unbootable i slot-successful oraz zresetować liczbę prób (jest to jedyny sposób na wyczyszczenie slot-unbootable).
Urządzenia bez aktualizacji A/B
Aby obsługiwać aktualizacje OTA na urządzeniach, które nie korzystają z aktualizacji A/B (patrz Urządzenia z możliwością aktualizacji A/B), upewnij się, że bootloader urządzenia spełnia poniższe kryteria.
Partycja recovery powinna zawierać obraz, który umożliwia odczytanie obrazu systemu z jakiejś obsługiwanej partycji (cache, userdata) i zapisanie go na partycji system.
Program rozruchowy powinien obsługiwać uruchamianie bezpośrednio w trybie odzyskiwania.
Jeśli aktualizacje obrazu radia są obsługiwane, partycja recovery powinna umożliwiać również flashowanie radia. Można to zrobić na 2 sposoby:
Program rozruchowy aktualizuje oprogramowanie radia. W takim przypadku można ponownie uruchomić urządzenie z partycji odzyskiwania, aby uruchomić program rozruchowy i dokończyć aktualizację.
Obraz odzyskiwania powoduje miganie radia. Może ona być udostępniana jako biblioteka binarna lub narzędzie.
Treść strony i umieszczone na niej fragmenty kodu podlegają licencjom opisanym w Licencji na treści. Java i OpenJDK są znakami towarowymi lub zastrzeżonymi znakami towarowymi należącymi do firmy Oracle lub jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2025-07-27 UTC.
[[["Łatwo zrozumieć","easyToUnderstand","thumb-up"],["Rozwiązało to mój problem","solvedMyProblem","thumb-up"],["Inne","otherUp","thumb-up"]],[["Brak potrzebnych mi informacji","missingTheInformationINeed","thumb-down"],["Zbyt skomplikowane / zbyt wiele czynności do wykonania","tooComplicatedTooManySteps","thumb-down"],["Nieaktualne treści","outOfDate","thumb-down"],["Problem z tłumaczeniem","translationIssue","thumb-down"],["Problem z przykładami/kodem","samplesCodeIssue","thumb-down"],["Inne","otherDown","thumb-down"]],["Ostatnia aktualizacja: 2025-07-27 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."]]
