Unterstützung von OTA-Updates

Um die Over-the-Air-Updates (OTA) zu unterstützen, muss der Bootloader während des Bootens auf eine Wiederherstellungs-RAM-Disk zugreifen können. Wenn das Gerät ein unverändertes AOSP-Wiederherstellungsimage verwendet, liest der Bootloader die ersten 32 Bytes auf der misc Partition; Wenn die Daten dort mit boot-recovery übereinstimmen, bootet der Bootloader in das recovery . Mit dieser Methode können alle ausstehenden Wiederherstellungsarbeiten (z. B. das Anwenden eines OTA oder das Entfernen von Daten) bis zum Abschluss fortgesetzt werden.

Einzelheiten zum Inhalt eines Blocks im Flash, der für die Kommunikation durch Recovery und den Bootloader verwendet wird, finden Sie unter bootable/recovery/bootloader_message/bootloader_message.h .

Geräte mit A/B-Updates

Um OTA-Updates auf Geräten zu unterstützen, die A/B-Updates verwenden, stellen Sie sicher, dass der Geräte-Bootloader die folgenden Kriterien erfüllt.

Allgemeine Kriterien

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

  • Um die system zu booten, übergibt der Bootloader den folgenden Wert in der Kernel-Befehlszeile: ro root=/dev/[node] rootwait init=/init .

  • Es liegt in der Verantwortung des Android-Frameworks, markBootSuccessful aus der HAL aufzurufen. Der Bootloader sollte niemals eine Partition als erfolgreich gebootet markieren.

Unterstützung für Boot-Steuerung HAL

Der Bootloader muss die boot_control HAL unterstützen, wie in hardware/libhardware/include/hardware/boot_control.h definiert. Der Updater fragt die Boot-Steuerungs-HAL ab, aktualisiert den derzeit nicht verwendeten Boot-Slot, ändert den aktiven Slot mithilfe der HAL und führt einen Neustart mit dem aktualisierten Betriebssystem durch. Einzelheiten finden Sie unter Implementieren der Boot-Steuerungs-HAL .

Unterstützung für Slots

Der Bootloader muss Funktionen im Zusammenhang mit Partitionen und Slots unterstützen, einschließlich:

  • Partitionsnamen müssen ein Suffix enthalten, das angibt, welche Partitionen zu einem bestimmten Steckplatz im Bootloader gehören. Für jede dieser Partitionen gibt es eine entsprechende Variable has-slot: partition base name mit dem Wert „ yes . Slots werden alphabetisch als a, b, c usw. benannt und entsprechen Partitionen mit dem Suffix _a , _b , _c usw. Der Bootloader sollte das Betriebssystem über die Befehlszeileneigenschaft androidboot.slot_suffix darüber informieren, welcher Slot gestartet wurde. Diese Eigenschaft wird über bootconfig für Geräte festgelegt, die mit Android 12 oder höher gestartet werden.

  • Der slot-retry-count Wert wird auf einen positiven Wert (normalerweise 3 ) zurückgesetzt, entweder von der Boot-Steuerungs-HAL über den Rückruf setActiveBootSlot oder über den Befehl fastboot set_active . Beim Ändern einer Partition, die Teil eines Steckplatzes ist, löscht der Bootloader „erfolgreich gebootet“ und setzt den Wiederholungszähler für den Steckplatz zurück.

Der Bootloader sollte auch bestimmen, welcher Steckplatz geladen werden soll. Die Abbildung zeigt einen beispielhaften Entscheidungsprozess.

Bootloader-Slotting-Ablauf
Abbildung 1. Bootloader-Slotting-Ablauf
  1. Bestimmen Sie, welchen Slot Sie ausprobieren möchten. Versuchen Sie nicht, einen Slot zu laden, der als slot-unbootable gekennzeichnet ist. Dieser Steckplatz sollte mit den von Fastboot zurückgegebenen Werten übereinstimmen und wird als aktueller Steckplatz bezeichnet.

  2. Wenn der aktuelle Steckplatz nicht als slot-successful markiert ist und einen slot-retry-count = 0 aufweist, markieren Sie den aktuellen Steckplatz als slot-unbootable . Wählen Sie dann einen anderen Steckplatz aus, der nicht als unbootable markiert ist und als slot-successful markiert ist. Dieser Steckplatz ist nun der ausgewählte Steckplatz. Wenn kein aktueller Steckplatz verfügbar ist, starten Sie zur Wiederherstellung oder zeigen Sie dem Benutzer eine aussagekräftige Fehlermeldung an.

  3. Wählen Sie die entsprechende boot.img aus und geben Sie den Pfad zur richtigen Systempartition in die Kernel-Befehlszeile ein.

  4. Füllen Sie den Kernel-Befehlszeilenparameter slot_suffix aus.

  5. Stiefel. Wenn nicht als slot-successful markiert, dekrementieren Sie slot-retry-count .

Das fastboot Dienstprogramm bestimmt, welche Partition geflasht werden soll, wenn Flash-Befehle ausgeführt werden. Wenn Sie beispielsweise den Befehl fastboot flash system system.img ausführen, wird zunächst die Variable „ current-slot abgefragt und dann das Ergebnis mit „system“ verkettet, um den Namen der Partition zu generieren, die geflasht werden soll ( system_a , system_b usw.).

Wenn Sie den aktuellen Steckplatz mit dem Befehl fastboot set_active oder dem HAL-Befehl setActiveBootSlot für die Startsteuerung festlegen, sollte der Bootloader den aktuellen Steckplatz aktualisieren, slot-unbootable und slot-successful löschen und den Wiederholungszähler zurücksetzen (dies ist die einzige Möglichkeit, slot-unbootable zu löschen). slot-unbootable ).

Geräte ohne A/B-Updates

Um OTA-Updates auf Geräten zu unterstützen, die keine A/B-Updates verwenden (siehe Nicht-A/B-aktualisierbare Geräte ), stellen Sie sicher, dass der Geräte-Bootloader die folgenden Kriterien erfüllt.

  • Die recovery sollte ein Image enthalten, das ein Systemimage von einer unterstützten Partition ( cache , userdata ) lesen und auf die system schreiben kann.

  • Der Bootloader sollte einen Neustart direkt im Wiederherstellungsmodus unterstützen.

  • Wenn Radio-Image-Updates unterstützt werden, sollte die recovery auch in der Lage sein, das Radio zu flashen. Dies kann auf zwei Arten erreicht werden:

    • Der Bootloader flasht das Radio. In diesem Fall sollte ein Neustart von der Wiederherstellungspartition zurück in den Bootloader möglich sein, um das Update abzuschließen.

    • Das Wiederherstellungsbild blinkt im Radio. Diese Funktionalität kann als Binärbibliothek oder Dienstprogramm bereitgestellt werden.