Nicht A/B-Systemupdates

Nicht-AB-Updates sind eine veraltete OTA-Methode, die auf älteren Android-Geräten (Android 6 und älter) verwendet wird. Diese Geräte haben eine spezielle Wiederherstellungspartition mit der Software, die zum Entpacken eines heruntergeladenen Update-Pakets und zum Anwenden des Updates auf die anderen Partitionen erforderlich ist.

Auf älteren Android-Geräten ohne A/B-Partitionen enthält der Flash-Speicherplatz in der Regel die folgenden Partitionen:

Boot
Enthält den Linux-Kernel und ein minimales Root-Dateisystem, das in ein RAM-Laufwerk geladen wird. Es bindet das System und andere Partitionen und startet die Laufzeitumgebung, die sich auf der Systempartition befindet.
Infotainmentsystem
Enthält Systemanwendungen und ‑bibliotheken, deren Quellcode im Android Open Source Project (AOSP) verfügbar ist. Im Normalbetrieb ist diese Partition schreibgeschützt bereitgestellt. Ihr Inhalt ändert sich nur bei einem Over-the-air-Update.
Anbieter
Enthält Systemanwendungen und ‑bibliotheken, deren Quellcode nicht im Android Open Source Project (AOSP) verfügbar ist. Im Normalbetrieb ist diese Partition schreibgeschützt bereitgestellt. Ihr Inhalt ändert sich nur bei einem Over-the-air-Update.
userdata
Hier werden die von den vom Nutzer installierten Anwendungen gespeicherten Daten usw. gespeichert. Diese Partition wird normalerweise nicht vom Over-the-air-Update-Prozess berührt.
im Cache speichern
Temporer Speicherbereich, der von einigen Anwendungen verwendet wird (der Zugriff auf diese Partition erfordert spezielle App-Berechtigungen) und zum Speichern heruntergeladener OTA-Update-Pakete. Andere Programme nutzen diesen Speicherplatz in der Annahme, dass Dateien jederzeit verschwinden können. Einige OTA-Paketinstallationen können dazu führen, dass diese Partition vollständig gelöscht wird. Der Cache enthält auch die Update-Protokolle eines Over-the-air-Updates.
erholung
Enthält ein zweites vollständiges Linux-System, einschließlich eines Kernels und des speziellen Wiederherstellungs-Binärprogramms, das ein Paket liest und dessen Inhalt verwendet, um die anderen Partitionen zu aktualisieren.
Sonstiges
Kleine Partition, die von der Wiederherstellung verwendet wird, um Informationen zu speichern, was gerade passiert, falls das Gerät neu gestartet wird, während das OTA-Paket angewendet wird.

Lebensdauer eines Over-the-air-Updates

Ein typisches OTA-Update umfasst die folgenden Schritte:

  1. Das Gerät führt regelmäßig einen Check-in bei OTA-Servern durch und wird über die Verfügbarkeit eines Updates informiert, einschließlich der URL des Update-Pakets und eines Beschreibungsstrings, der dem Nutzer angezeigt wird.
  2. Downloads werden in einer Cache- oder Datenpartition aktualisiert und die kryptografische Signatur wird anhand der Zertifikate in /system/etc/security/otacerts.zip überprüft. Der Nutzer wird aufgefordert, das Update zu installieren.
  3. Das Gerät wird im Wiederherstellungsmodus neu gestartet, in dem der Kernel und das System in der Wiederherstellungspartition anstelle des Kernels in der Bootpartition gestartet werden.
  4. Das Wiederherstellungs-Binärprogramm wird von init gestartet. Es sucht in /cache/recovery/command nach Befehlszeilenargumenten, die auf das heruntergeladene Paket verweisen.
  5. Bei der Wiederherstellung wird die kryptografische Signatur des Pakets anhand der öffentlichen Schlüssel in /res/keys (Teil des RAM-Laufwerks in der Wiederherstellungspartition) überprüft.
  6. Daten werden aus dem Paket abgerufen und verwendet, um die Boot-, System- und/oder Anbieterpartitionen nach Bedarf zu aktualisieren. Eine der neuen Dateien, die auf der Systempartition verbleiben, enthält den Inhalt der neuen Wiederherstellungspartition.
  7. Das Gerät wird normal neu gestartet.
    1. Die neu aktualisierte Bootpartition wird geladen und bereitgestellt. Anschließend werden Binärdateien in der neu aktualisierten Systempartition ausgeführt.
    2. Im Rahmen des normalen Starts vergleicht das System den Inhalt der Wiederherstellungspartition mit dem gewünschten Inhalt, der zuvor als Datei in /system gespeichert wurde. Wenn sie sich unterscheiden, wird die Wiederherstellungspartition mit dem gewünschten Inhalt neu geflasht. Bei nachfolgenden Starts enthält die Wiederherstellungspartition bereits die neuen Inhalte, sodass kein erneutes Flashen erforderlich ist.

Das Systemupdate ist abgeschlossen. Die Update-Protokolle finden Sie unter /cache/recovery/last_log.#.

Pakete aktualisieren

Ein Update-Paket ist eine .zip-Datei, die die ausführbare Binärdatei META-INF/com/google/android/update-binary enthält. Nachdem die Signatur des Pakets überprüft wurde, extrahiert recovery diese Binärdatei in /tmp und führt sie mit den folgenden Argumenten aus:

  • Aktualisieren Sie die Versionsnummer der Binär-API. Wenn sich die an update binary übergebenen Argumente ändern, wird diese Zahl erhöht.
  • Dateideskriptor der Befehlspipe. Das Updateprogramm kann über diese Pipe Befehle an das Recovery-Binary zurücksenden, hauptsächlich für Änderungen an der Benutzeroberfläche, z. B. um den Fortschritt dem Nutzer anzuzeigen.
  • Dateiname der .zip-Datei des Updatepakets.

Ein Update-Paket kann jedes statisch verknüpfte Binärprogramm als Update-Binärprogramm verwenden. Die Tools zum Erstellen von OTA-Paketen verwenden das Updateprogramm (bootable/recovery/updater), das eine einfache Scripting-Sprache bietet, mit der viele Installationsaufgaben ausgeführt werden können. Sie können jedes andere Binärprogramm ersetzen, das auf dem Gerät ausgeführt wird.

Weitere Informationen zum Updater-Binärprogramm, zur edify-Syntax und zu integrierten Funktionen finden Sie unter Inside OTA Packages.

Von früheren Releases migrieren

Bei der Migration von Android 2.3/3.0/4.0 besteht die Hauptänderung darin, dass alle gerätespezifischen Funktionen von einer Reihe von C-Funktionen mit vordefinierten Namen in C++-Objekte umgewandelt werden. In der folgenden Tabelle sind die alten Funktionen und die neuen Methoden aufgeführt, die in etwa denselben Zweck erfüllen:

C-Funktion C++-Methode
device_recovery_start() Device::RecoveryStart()
device_toggle_display()
device_reboot_now()
 RecoveryUI::CheckKey()
(auch RecoveryUI::IsKeyPressed())
device_handle_key() Device::HandleMenuKey()
device_perform_action() Device::InvokeMenuItem()
device_wipe_data() Device::WipeData()
device_ui_init() ScreenRecoveryUI::Init()

Die Umstellung alter Funktionen auf neue Methoden sollte relativ einfach sein. Vergessen Sie nicht, die neue Funktion make_device() hinzuzufügen, um eine Instanz Ihrer neuen Device-Unterklasse zu erstellen und zurückzugeben.