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 in Flash, der für die Kommunikation von der Wiederherstellung und dem Bootloader verwendet wird, finden Sie unter bootable/recovery/bootloader_message/bootloader_message.h.

Geräte mit A/B-Updates

Damit OTA-Updates auf Geräten mit A/B-Updates unterstützt werden können, muss der Geräte-Bootloader die folgenden Kriterien erfüllen.

Allgemeine Kriterien

  • Alle Partitionen, die über ein OTA aktualisiert werden, sollten aktualisierbar sein, während das Hauptsystem gestartet wird (und nicht bei der Wiederherstellung).

  • 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 aus dem 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 Bootsteuerungs-HAL implementieren.

Unterstützung für Slots

Der Bootloader muss unter anderem folgende Funktionen für Partitionen und Slots unterstützen:

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

  • Der Wert slot-retry-count wird entweder durch die HAL der Bootsteuerung über den setActiveBootSlot-Callback oder über den Befehl fastboot set_active auf einen positiven Wert zurückgesetzt (normalerweise 3). Beim Ändern einer Partition, die Teil eines Slots ist, löscht der Bootloader den Status „Successfully booted“ (Erfolgreich gestartet) und setzt die Anzahl der Wiederholungen für den Slot zurück.

Der Bootloader sollte auch bestimmen, welcher Slot geladen werden soll. Die Abbildung zeigt ein Beispiel für einen Entscheidungsprozess.

Bootloader-Slotting-Ablauf
Abbildung 1: Bootloader-Slotting-Ablauf

  1. Ermitteln Sie, welcher Slot verwendet 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 gekennzeichnet ist und ein slot-retry-count = 0 enthält, markieren Sie den aktuellen Slot als slot-unbootable. Wählen Sie dann einen anderen Slot aus, der nicht als unbootable, sondern als slot-successful gekennzeichnet ist. Dieser Slot ist jetzt der ausgewählte Slot. Wenn kein aktueller Slot verfügbar ist, starten Sie zur 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 slot-successful markiert, verringern Sie 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 verkettet, um den Namen der Partition zu generieren, die geflasht werden soll (system_a, system_b usw.).

Wenn Sie den aktuellen Slot mit dem Fastboot-Befehl set_active oder dem HAL-Befehl setActiveBootSlot zur Startsteuerung festlegen, sollte der Bootloader den aktuellen Slot 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 OTA-Updates auf Geräten unterstützt werden können, die keine A/B-Updates verwenden (siehe Nicht-A/B-Aktualisierungen auf Geräten), muss der Geräte-Bootloader die folgenden Kriterien erfüllen.

  • Die Partition recovery sollte ein Image enthalten, das ein System-Image aus einer unterstützten Partition (cache, userdata) lesen und in die Partition system schreiben kann.

  • Der Bootloader sollte das Starten im Wiederherstellungsmodus unterstützen.

  • Wenn Updates für Radio-Images unterstützt werden, sollte die Partition recovery auch das Flashen des Radios unterstützen können. Dies kann auf zwei Arten erreicht werden:

    • Der Bootloader startet das Radio. In diesem Fall sollte es möglich sein, einen Neustart von der Wiederherstellungspartition in den Bootloader zu starten, um die Aktualisierung abzuschließen.

    • Durch das Wiederherstellungsabbild wird das Funksignal aktiviert.Diese Funktion kann als binäre Bibliothek oder als Dienstprogramm bereitgestellt werden.