Nahtlose A / B-Updates in Android: Wie sie funktionieren

Hallo. Bei SberDevices beschäftigt sich unser Team mit der Entwicklung verschiedener Hardware und Firmware für AOSP.



Ab Android 8 (einige Anbieter ab 7.1) verfügt das System über einen neuen Mechanismus zum Rollen von OTA-Updates, den sogenannten. Nahtlose A / B-OTA-Updates - nahtlose Updates. In diesem Beitrag werde ich die allgemeinen Funktionsprinzipien beschreiben, den Mechanismus aus Sicht des Entwicklers betrachten und ihn auch mit dem alten (wir nennen ihn wiederherstellungsbasierten) Ansatz zum Anwenden von Updates vergleichen. Alle folgenden Punkte gelten nur für reines AOSP, da die spezifische Implementierung vom Hersteller abhängt.

Wiederherstellungsbasiertes OTA

Updates für Android werden in Form eines Zip-Archivs mit blockbasierten Updates geliefert. In den Tagen von KitKat waren es nur eine Reihe von Dateien, die vom enthaltenen Skript auf das Gerät kopiert wurden. Ich werde nicht im Detail auf diesen Modus eingehen, sondern kurz die Grundprinzipien seiner Funktionsweise beschreiben:

• Das Zip-Archiv wird vom System auf das Gerät heruntergeladen.
• Das System wird im Wiederherstellungsmodus neu gestartet .
• Überprüfen der Kompatibilität des Updates mit dem Gerät, seiner Signatur;
• Wenn alles in Ordnung ist, wird das Updater-Skript aus dem Zip-Archiv ausgeführt .
• Während des Updates wird das Gerät möglicherweise mehrmals neu gestartet (z. B. um den Gerätebaum zu aktualisieren ).
• Wenn alles gut gegangen ist, starten Sie die neue Firmware.

Was sind die Nachteile dieses Schemas?

• Die Notwendigkeit, eine ausreichende Menge an internem Speicher für das OTA-Archiv zu reservieren. Hierfür wird der Abschnitt / cache verwendet . Einige Anbieter verwenden / data , dies ist jedoch selten. Infolgedessen bleibt dem Benutzer weniger Speicherplatz (ja, Anwendungen können weiterhin Speicherplatz in der / cache- Partition verwenden , jedoch mit einigen Einschränkungen).
• Das Neustarten und Anwenden des Updates erfordert Zeit, was für einige Gerätetypen, z. B. für Smart-TVs, von entscheidender Bedeutung sein kann.
• Das Unterbrechen des Aktualisierungsprozesses kann zu einer Startschleife führen .
• Es gibt keine Möglichkeit, ein Rollback auf die alte Firmware-Version durchzuführen.

Diese Unannehmlichkeit ermöglicht es Ihnen, die nahtlose Upgrade-Methode zu umgehen. Mal sehen, wie es funktioniert.

Nahtlose A / B OTA

Wichtige Komponenten und Mechanismen für die Implementierung nahtloser A / B-Updates :

• Steckplatzmarkierung des Flash-Speichers; 
• Interaktion mit dem Lader, Verwaltung des Slot- Status ;
• System Daemon update_engine ;
• Generieren eines Zip-Archivs mit einem Update. Dieser Aspekt wird in diesem Artikel nicht berücksichtigt.

Schlüssel

Das Grundprinzip von A / B OTA ist das  Schlitzen . Alle Partitionen, die aktualisiert werden müssen (dies können beliebige Partitionen sein, nicht nur Systempartitionen), müssen in zwei Kopien oder auf andere Weise in Steckplätzen vorliegen. Bei Android wird die Realisierung von zwei Slots unterstützt, die jeweils A und B heißen . Das System startet und arbeitet vom aktuellen Steckplatz aus, der zweite wird nur zum Zeitpunkt des Updates verwendet. Dem Abschnittsnamen wird ein Suffix mit dem Steckplatznamen hinzugefügt.



In der folgenden Tabelle werden die beiden Optionen zum Organisieren von Partitionen auf einem Gerät verglichen. Alle geschlitzten Partitionen sind mit der Option zum Einstellen der Steckplatzauswahl gekennzeichnet ,  damit das System den richtigen Steckplatz auswählen kann. Je nachdem, wo sie beschrieben werden, kann dies fstab sein





oder dts .

Änderungen an der Partitionstabelle

• B / Cache wird nicht mehr benötigt. Jetzt kann das Update entweder in / data gespeichert oder sofort in einen inaktiven Steckplatz geflasht werden (mehr dazu weiter unten). 
• Der Wiederherstellungsabschnitt wird ebenfalls nicht mehr verwendet. Der  Wiederherstellungsmodus ist jedoch   weiterhin vorhanden. Beispielsweise muss das Gerät auf die Werkseinstellungen zurückgesetzt werden (dies kann zu einer  Rettungsaktion führen ). Oder für die sogenannten. manuelles Update ( Seitenladen ) über adb . Die Wiederherstellungs-Ramdisk befindet sich  jetzt in der  Boot- Partition. Der Kernel wird gemeinsam genutzt.
• (android/recovery) cmdline ‑ skip_initramfs.

Auf den ersten Blick scheint ein solches Schema nicht optimal zu sein, da dem System doppelt so viel Platz zugewiesen werden muss. Aber wir haben / cache losgeworden  , was bedeutet, dass wir bereits viel Speicherplatz gespart haben. Daher benötigt das System etwas mehr als die Wiederherstellungsoption .



Der Hauptvorteil von A / B-Updates ist die Möglichkeit, die Firmware zu  streamen . Dies sorgt für nahtlose und transparente Updates für den Benutzer: Um das Gerät zu aktualisieren, reicht es aus, einen neuen Steckplatz neu zu starten. In diesem Modus muss das Zip-Archiv nicht im Voraus heruntergeladen werden, da Speicherplatz in / data belegt ist . Stattdessen schreibt das System sofort Datenblöcke aus einer speziell vorbereiteten Datei ( Nutzdaten), siehe unten) in jeden Abschnitt eines inaktiven Steckplatzes. Aus Sicht der Implementierung spielt es keine Rolle, ob wir das Update im Voraus herunterladen oder sofort in den Slot streamen.



Slots haben folgende Zustände:

• Aktiv - Aktiver Steckplatz, das System wird beim nächsten Neustart von diesem geladen.
• bootfähig - das Update wurde erfolgreich in den Steckplatz geflasht, validiert, Hash-Summen abgeglichen usw.;
• erfolgreich - das System konnte erfolgreich in den neuen Steckplatz booten;
• nicht bootfähig - der Steckplatz ist beschädigt. Das System markiert den Steckplatz immer als nicht bootfähig, bevor der Aktualisierungsvorgang gestartet wird.

Beide Slots können  bootfähig  und  erfolgreich sein , aber nur einer ist aktiv .



Der Algorithmus des Bootloaders bei der Auswahl eines Slots:

• Der Bootloader erkennt, dass ein oder mehrere  bootfähige Steckplätze vorhanden sind .
• Aus ihnen wird der aktive Steckplatz (oder der Steckplatz mit der höchsten Priorität) ausgewählt.
• Wenn das System erfolgreich gestartet wurde, wird der Steckplatz als erfolgreich  und  aktiv markiert  .
• Andernfalls wird der Steckplatz als nicht bootfähig markiert und das System neu gestartet.

Ändern des Steckplatzstatus während des Updates:

Voraussetzungen für Seamless A / B.

boot_control

Um A / B-Updates zu unterstützen, muss der Anbieter eine spezielle HAL-Schnittstelle implementieren - boot_control . Sie können den Status von Slots ändern und Informationen darüber abrufen. Für externe Arbeiten (z. B. über die adb-Shell ) wird das Dienstprogramm bootctl verwendet . Die Schnittstelle wird als Kommunikationsmittel zwischen dem Betriebssystem und dem Bootloader verwendet.

update_engine

Die Hauptkomponente der gesamten A / B-Schaltung. Erledigt das Herunterladen, Streaming von Updates, Überprüfen von Signaturen und vieles mehr. Ändert den Slot- Status über boot_control . Ermöglicht die Steuerung des Aktualisierungsprozesses des Geräts: Anhalten, Fortsetzen, Abbrechen.

Die Komponente kam von ChromeOS zu Android, wo sie seit einiger Zeit verwendet wird. AOSP verwaltet update_engine als statische Seitenladebaugruppe . Sie wird bei der Wiederherstellung verwendet , da dieser Modus keine dynamische Verknüpfung unterstützt.



Der Prozess dieser Komponente kann in die folgenden Schritte unterteilt werden:

• Laden des Updates in den Steckplatz. Sie können beide von einem zuvor heruntergeladenen Paket mit einem Update oder direkt über das Internet über http / https herunterladen. Während des Downloads wird die Signatur überprüft, der öffentliche Schlüssel befindet sich bereits auf dem Gerät (/system/etc/update_engine/update-payload-key.pub.pem).
• Überprüfung des heruntergeladenen Updates und Vergleich der Hash-Summen;
• Ausführung von Skripten nach der Installation . 

Service Pack-Struktur:

2009-01-01 00:00:00 .....          360          360  META-INF/com/android/metadata
2009-01-01 00:00:00 .....          107          107  care_map.txt
2009-01-01 00:00:00 .....    384690699    384690699  payload.bin
2009-01-01 00:00:00 .....          154          154  payload_properties.txt
2009-01-01 00:00:00 .....         1675          943  META-INF/com/android/otacert

• care_map.txt - wird von update_verifier verwendet (siehe unten);
• payload_properties.txt - enthält Hashes und Datengrößen innerhalb der Payload .
• payload.bin - Update-Paket, enthält Blöcke aller Abschnitte, Metadaten , Signatur.

update_engine_client

Client zum Verwalten des Daemon update_engine . Kann direkt vom Anbieter aufgerufen werden, um das Update anzuwenden.

update_verifier

Dienstprogramm zum Überprüfen der Integrität des Systems beim ersten Start (Steckplatz mit dem aktiven Flag  , aber noch nicht  erfolgreich ). Die Integritätssteuerung wird mithilfe des Kernelmoduls dm-verity implementiert . Wenn die Prüfung erfolgreich ist, markiert das Dienstprogramm den aktuellen Steckplatz als  erfolgreich . Andernfalls wird das System im alten Steckplatz neu gestartet. Es werden nur die in der Datei care_map.txt angegebenen Blöcke überprüft .

UpdateEngineApi

Es gibt eine Java-API zum Implementieren von Herstelleraktualisierungsdiensten . Es gibt auch ein Beispiel für eine solche Service- Implementierung .



Schauen wir uns ein Beispiel für ein A / B-Update in AOSP an. Bearbeiten Sie dazu das Makefile der Zielplattform:

#  A/B
AB_OTA_UPDATER := true
#    :
AB_OTA_PARTITIONS := boot system vendor
#  
PRODUCT_PACKAGES := update_engine update_engine_client update_verifier
#  recovery
TARGET_NO_RECOVERY := true
#,       cache:
#BOARD_CACHEIMAGE_PARTITION_SIZE := ...
#BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE := ...

Nach dem Aufruf von make otapackage erhalten wir mit dem Update ein Zip-Archiv. In dieser Form ist es bereits für den Seitenlademodus geeignet . Wir können die Wiederherstellung neu starten und adb sideload ota.zip aufrufen . Diese Methode eignet sich zum Debuggen.



Das Anwenden eines Updates aus einem Produktionssystem heraus ist normalerweise herstellerspezifisch. Am einfachsten ist es, payload.bin auf einen http-Server hochzuladen und update_engine_client direkt aufzurufen .



Beispiel aufrufen:

update_engine_client \
--payload=http://path/to/payload.bin \
--update \
--headers=" \
FILE_HASH=ozGgyQEddkI5Zax+Wbjo6I/PCR8PEZka9gGd0nWa+oY= \
FILE_SIZE=282344983 \
METADATA_HASH=GLIKfE6KRwylWMHsNadG/Q8iy5f786WTatvMdBlpOPg= \
METADATA_SIZE=26723"

Der Inhalt der payload_properties.txt - Datei wird auf den übergebenen Header Parameter . In logcat können Sie den Fortschritt des Updates sehen. Wenn Sie den Schalter --follow übergeben, wird der Fortschritt in stdout dupliziert .

Fazit

Die Vorteile des neuen Update-Mechanismus liegen auf der Hand:

• Die Systemaktualisierung erfolgt im Hintergrund, ohne die Arbeit des Benutzers zu unterbrechen. Ja, Sie müssen noch neu starten (in einen neuen Steckplatz), aber es ist  viel  schneller als ein Neustart bei der Wiederherstellung, um das Update anzuwenden.
• Die Wahrscheinlichkeit einer Boot-Schleife wird minimiert (niemand ist immun gegen Fehler in der Implementierung). Der Aktualisierungsvorgang kann unterbrochen werden. Der aktive Steckplatz wird dadurch in keiner Weise beeinträchtigt.
• Es wird möglich, ein Rollback auf die vorherige Firmware-Version durchzuführen. Auch wenn das Update aus irgendeinem Grund nicht erfolgreich war, kehrt das System einfach zur alten Version zurück.
• Dank Streaming wird das Gerät schneller aktualisiert.
• Abhängig von der Implementierung können Sie den Benutzer vollständig vom Aktualisierungsprozess ausschließen.

Von den Minuspunkten würde ich zwei Punkte herausgreifen:

• A / B OTA hängt vom aktuellen Festplattenlayout ab, da die Aktualisierung während der Ausführung des Systems erfolgt. Das heißt, es wird unmöglich, das Update mit den geänderten Partitionen zu rollen.
• die relative Komplexität der Implementierung.

Und doch überwiegen meiner Meinung nach die Profis. Übrigens verwenden wir in unserem kürzlich angekündigten Gerät A / B-OTA-Updates.