Wspieranie aktualizacji OTA

Aby obsługiwać aktualizacje OTA , program ładujący musi mieć dostęp do dysku RAM odzyskiwania podczas uruchamiania. Jeśli urządzenie korzysta z niezmodyfikowanego obrazu odzyskiwania AOSP, program ładujący odczytuje pierwsze 32 bajty z partycji misc ; jeśli znajdujące się tam dane odpowiadają boot-recovery , program ładujący uruchomi się z obrazem recovery . Ta metoda umożliwia kontynuowanie wszelkich oczekujących prac związanych z odzyskiwaniem (na przykład zastosowanie OTA lub usunięcie danych).

Aby uzyskać szczegółowe informacje na temat zawartości bloku we flashu używanego do komunikacji przez odzyskiwanie i program ładujący, zobacz bootable/recovery/bootloader_message/bootloader_message.h .

Urządzenia z aktualizacjami A/B

Aby obsługiwać aktualizacje OTA na urządzeniach korzystających z aktualizacji A/B , upewnij się, że program ładujący urządzenia spełnia następujące kryteria.

Kryteria ogólne

  • Wszystkie partycje aktualizowane przez OTA powinny być aktualizowane podczas uruchamiania głównego systemu (a nie aktualizowane podczas odzyskiwania).

  • Aby uruchomić partycję system , program ładujący przekazuje następującą wartość w wierszu poleceń jądra: ro root=/dev/[node] rootwait init=/init .

  • Wywoływanie markBootSuccessful z warstwy HAL jest obowiązkiem platformy Android. Program ładujący nigdy nie powinien oznaczać partycji jako pomyślnie uruchomionej.

Obsługa kontroli rozruchu HAL

Program ładujący musi obsługiwać warstwę HAL boot_control zdefiniowaną w hardware/libhardware/include/hardware/boot_control.h ). Aktualizator wysyła zapytanie do warstwy sterującej rozruchem , aktualizuje aktualnie nieużywane gniazdo rozruchowe, zmienia aktywne gniazdo za pomocą warstwy HAL i ponownie uruchamia zaktualizowany system operacyjny. Aby uzyskać szczegółowe informacje, zobacz Implementowanie kontroli rozruchu HAL .

Wsparcie dla slotów

Program ładujący musi obsługiwać funkcjonalność związaną z partycjami i gniazdami, w tym:

  • Nazwy partycji muszą zawierać przyrostek identyfikujący, które partycje należą do konkretnego gniazda w programie ładującym. Dla każdej takiej partycji istnieje odpowiednia zmienna has-slot: partition base name o wartości yes . Sloty nazywane są alfabetycznie jako a, b, c itd., co odpowiada partycjom z przyrostkiem _a , _b , _c itd. Program ładujący powinien poinformować system operacyjny, który slot został uruchomiony, korzystając z właściwości wiersza poleceń androidboot.slot_suffix . Ta właściwość jest ustawiana poprzez bootconfig dla urządzeń uruchamianych z systemem Android 12 lub nowszym.

  • Wartość slot-retry-count jest resetowana do wartości dodatniej (zwykle 3 ) albo przez kontrolę rozruchu HAL poprzez wywołanie zwrotne setActiveBootSlot , albo przez polecenie fastboot set_active . Podczas modyfikowania partycji będącej częścią gniazda program ładujący kasuje komunikat „Uruchomienie zakończone pomyślnie” i resetuje licznik ponownych prób dla tego gniazda.

Program ładujący powinien również określić, które gniazdo załadować. Rysunek przedstawia przykładowy proces decyzyjny.

Przepływ szczelinowania bootloadera
Rysunek 1. Przebieg szczelinowania programu ładującego

  1. Określ, który slot wypróbować. Nie próbuj ładować gniazda oznaczonego jako slot-unbootable . To gniazdo powinno być zgodne z wartościami zwracanymi przez fastboot i jest nazywane bieżącym gniazdem.

  2. Jeśli bieżące gniazdo nie jest oznaczone jako slot-successful i ma slot-retry-count = 0 , oznacz bieżące gniazdo jako slot-unbootable . Następnie wybierz inne gniazdo, które nie jest oznaczone unbootable i jest oznaczone jako slot-successful ; to gniazdo jest teraz wybranym gniazdem. Jeśli żadne bieżące gniazdo nie jest dostępne, uruchom system w trybie odzyskiwania lub wyświetl użytkownikowi znaczący komunikat o błędzie.

  3. Wybierz odpowiedni boot.img i podaj ścieżkę do prawidłowej partycji systemowej w wierszu poleceń jądra.

  4. Wypełnij parametr slot_suffix wiersza poleceń jądra.

  5. Uruchomić. Jeśli nie oznaczono slot-successful , slot-retry-count gnieździe.

Narzędzie fastboot określa, która partycja ma zostać flashowana podczas uruchamiania jakichkolwiek poleceń flash. Na przykład uruchomienie polecenia fastboot flash system system.img najpierw wysyła zapytanie do zmiennej current-slot a następnie łączy wynik z systemem w celu wygenerowania nazwy partycji, która powinna zostać sflashowana ( system_a , system_b itp.).

Podczas ustawiania bieżącego gniazda za pomocą polecenia fastboot set_active lub polecenia kontroli rozruchu HAL setActiveBootSlot , program ładujący powinien zaktualizować bieżące gniazdo, wyczyścić slot-unbootable i slot-successful oraz zresetować licznik ponownych 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 bez aktualizacji A/B ), upewnij się, że program ładujący urządzenia spełnia następujące kryteria.

  • Partycja recovery powinna zawierać obraz umożliwiający odczytanie obrazu systemu z obsługiwanej partycji ( cache , userdata ) i zapisanie go na partycji system .

  • Program ładujący powinien obsługiwać ponowne uruchamianie bezpośrednio w trybie odzyskiwania.

  • Jeśli obsługiwane są aktualizacje obrazu radia, partycja recovery powinna również umożliwiać flashowanie radia. Można to osiągnąć na jeden z dwóch sposobów:

    • Bootloader flashuje radio. W takim przypadku powinno być możliwe ponowne uruchomienie komputera z partycji odzyskiwania do programu ładującego w celu dokończenia aktualizacji.

    • Obraz odzyskiwania miga radiem. Funkcjonalność tę można udostępnić w postaci biblioteki binarnej lub narzędzia.