OTA-Updates implementieren

Zur Implementierung von Over-the-Air-Updates (OTA) muss der Bootloader während des Startvorgangs auf eine RAM-Disk für die Wiederherstellung zugreifen können. Verwendet das Gerät ein nicht modifiziertes AOSP-Wiederherstellungs-Image, liest der Bootloader die ersten 32 Byte auf der Partition misc. Wenn die vorhandenen Daten mit boot-recovery übereinstimmen, startet der Bootloader im Image recovery. Mit dieser Methode können alle ausstehenden Wiederherstellungen (z. B. das Anwenden eines OTA-Updates oder das Entfernen von Daten) abgeschlossen werden.

Details zum Inhalt eines Blocks im Flash-Speicher, der für die Kommunikation zwischen Recovery und Bootloader verwendet wird, finden Sie unter bootable/recovery/bootloader_message/bootloader_message.h.

Geräte mit A/B-Updates

Damit Over-the-air-Updates auf Geräten mit A/B-Updates unterstützt werden, muss der Bootloader des Geräts die folgenden Kriterien erfüllen.

Allgemeine Kriterien

  • Alle Partitionen, die über ein OTA-Update aktualisiert werden, sollten während des Startens des Hauptsystems aktualisiert werden können (und nicht im Wiederherstellungsmodus).

  • Zum Starten der Partition system übergibt der Bootloader den folgenden Wert an die Kernel-Befehlszeile: ro root=/dev/[node] rootwait init=/init.

  • Das Android-Framework ist dafür verantwortlich, markBootSuccessful über die HAL aufzurufen. Der Bootloader sollte eine Partition niemals als erfolgreich gestartet markieren.

Unterstützung für Bootsteuerungs-HAL

Der Bootloader muss den HAL boot_control gemäß der Definition in hardware/libhardware/include/hardware/boot_control.h unterstützen. Der Updater fragt den HAL-Modus für die Bootsteuerung ab, aktualisiert den nicht verwendeten Bootslot, ändert den aktiven Slot mithilfe des HAL und startet das aktualisierte Betriebssystem neu. Weitere Informationen finden Sie unter Implementieren der Boot Control HAL.

Unterstützung für Slots

Der Bootloader muss Funktionen für Partitionen und Slots unterstützen, darunter:

  • Partitionsnamen müssen ein Suffix enthalten, das angibt, welche Partitionen zu einem bestimmten Steckplatz im Bootloader gehören. Für jede solche Partition gibt es eine entsprechende Variable has-slot:partition base name mit dem Wert yes. Slots werden alphabetisch als a, b, c usw. benannt, was den Partitionen mit den Suffixen _a, _b, _c usw. entspricht. Der Bootloader sollte dem Betriebssystem mithilfe der Befehlszeileneigenschaft androidboot.slot_suffix mitteilen, welcher Slot gestartet wurde. Für Geräte mit Android 12 oder höher wird dieses Attribut über bootconfig festgelegt.

  • Der slot-retry-count-Wert wird entweder über die Boot Control HAL über den setActiveBootSlot-Callback oder über den Befehl fastboot set_active auf einen positiven Wert (normalerweise 3) zurückgesetzt. Wenn Sie eine Partition ändern, die zu einem Slot gehört, löscht der Bootloader den Eintrag „Successfully booted“ (Erfolgreich gestartet) und setzt die Anzahl der Wiederholungen für den Slot zurück.

Der Bootloader bestimmt auch, welcher Slot geladen werden soll. Die Abbildung zeigt einen Beispielentscheidungsprozess.

Bootloader-Slotting-Ablauf
Abbildung 1. Bootloader-Slotting-Vorgang

  1. Legen Sie fest, welcher Slot versucht werden soll. Versuchen Sie nicht, einen Slot zu laden, der mit slot-unbootable gekennzeichnet ist. Dieser Slot sollte mit den von Fastboot zurückgegebenen Werten übereinstimmen und wird als aktueller Slot bezeichnet.

  2. Wenn der aktuelle Slot nicht als slot-successful markiert ist und ein slot-retry-count = 0 hat, markieren Sie ihn als slot-unbootable. Wählen Sie dann einen anderen Slot aus, der nicht mit unbootable, sondern mit slot-successful markiert ist. Dieser Slot ist jetzt der ausgewählte Slot. Wenn kein aktueller Slot verfügbar ist, starten Sie das System in die Wiederherstellung oder zeigen Sie dem Nutzer eine aussagekräftige Fehlermeldung an.

  3. Wählen Sie die entsprechende boot.img aus und geben Sie in der Kernel-Befehlszeile den Pfad zur korrekten Systempartitionierung an.

  4. Geben Sie den Parameter slot_suffix der Kernel-Befehlszeile ein.

  5. Starten. Wenn nicht mit slot-successful markiert, verringere slot-retry-count.

Das Dienstprogramm fastboot bestimmt, welche Partition beim Ausführen von Flash-Befehlen geflasht werden soll. Wenn Sie beispielsweise den Befehl fastboot flash system system.img ausführen, wird zuerst die Variable current-slot abgefragt und dann das Ergebnis mit dem System verknüpft, um den Namen der Partition zu generieren, die geflasht werden soll (system_a, system_b usw.).

Wenn der aktuelle Steckplatz mit dem Befehl „fastboot set_active“ oder dem Befehl „boot control HAL setActiveBootSlot“ festgelegt wird, sollte der Bootloader den aktuellen Steckplatz aktualisieren, slot-unbootable und slot-successful löschen und die Anzahl der Wiederholungen zurücksetzen. Dies ist die einzige Möglichkeit, slot-unbootable zu löschen.

Geräte ohne A/B-Updates

Damit Over-the-air-Updates auf Geräten unterstützt werden, die keine A/B-Updates verwenden (siehe Geräte, die nicht per A/B-Update aktualisiert werden können), muss der Bootloader des Geräts die folgenden Kriterien erfüllen.

  • Die Partition recovery sollte ein Image enthalten, mit dem ein System-Image aus einer unterstützten Partition (cache, userdata) gelesen und in die Partition system geschrieben werden kann.

  • Der Bootloader sollte das Starten direkt in den Wiederherstellungsmodus unterstützen.

  • Wenn Radio-Image-Updates unterstützt werden, sollte das Radio auch über die Partition recovery geflasht werden können. Dazu gibt es zwei Möglichkeiten:

    • Der Bootloader flasht das Radio. In diesem Fall sollte es möglich sein, von der Wiederherstellungspartition aus neu zu starten und zum Bootloader zurückzukehren, um das Update abzuschließen.

    • Das Wiederherstellungs-Image flasht das Funkmodul.Diese Funktion kann als Binärbibliothek oder Dienstprogramm bereitgestellt werden.