OTA-Updates implementieren

Damit Over-the-Air-Updates (OTA) implementiert werden können, muss der Bootloader während des Starts auf eine Wiederherstellungs-RAM-Disk zugreifen können. Wenn auf dem Gerät ein unverändertes AOSP-Wiederherstellungs-Image verwendet wird, liest der Bootloader die ersten 32 Byte der Partition misc. Wenn die Daten mit boot-recovery übereinstimmen, startet der Bootloader das recovery-Image. Mit dieser Methode können alle ausstehenden Wiederherstellungsarbeiten (z. B. das Anwenden eines Over-the-air-Updates oder das Entfernen von Daten) fortgesetzt 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 gibt der Bootloader den folgenden Wert an die Kernel-Befehlszeile weiter: 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 HAL zur Bootsteuerung

Der Bootloader muss die boot_control HAL gemäß hardware/libhardware/include/hardware/boot_control.h unterstützen. Der Aktualisierer fragt die Boot Control HAL ab, aktualisiert den nicht verwendeten Boot-Steckplatz, ändert den aktiven Steckplatz mithilfe der 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 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. Diese Eigenschaft wird über die Boot-Konfiguration für Geräte festgelegt, die mit Android 12 oder höher gestartet werden.

  • Der Wert von slot-retry-count wird entweder über die HAL der Bootsteuerung ü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 sollte auch festlegen, welcher Steckplatz 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 eine 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 den entsprechenden boot.img aus und geben Sie den Pfad zur richtigen Systempartition in der Kernel-Befehlszeile an.

  4. Geben Sie den Parameter slot_suffix in 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 direkte Starten 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äre Bibliothek oder Dienstprogramm bereitgestellt werden.