Nicht-A/B-Systemaktualisierungen

Auf älteren Android-Geräten ohne A/B-Partitionen enthält der Flash-Speicher typischerweise die folgenden Partitionen:

Stiefel

Enthält den Linux-Kernel und ein minimales Root-Dateisystem (auf eine RAM-Disk geladen). Es mountet System- und andere Partitionen und startet die Laufzeit, die sich auf der Systempartition befindet.

System

Enthält Systemanwendungen und Bibliotheken, deren Quellcode im Android Open Source Project (AOSP) verfügbar ist. Im Normalbetrieb ist diese Partition schreibgeschützt gemountet; Der Inhalt ändert sich nur während eines OTA-Updates.

Verkäufer

Enthält Systemanwendungen und Bibliotheken, für die im Android Open Source Project (AOSP) kein Quellcode verfügbar ist. Im Normalbetrieb ist diese Partition schreibgeschützt gemountet; Der Inhalt ändert sich nur während eines OTA-Updates.

Benutzerdaten

Speichert die Daten, die von vom Benutzer installierten Anwendungen usw. gespeichert werden. Diese Partition wird normalerweise vom OTA-Aktualisierungsprozess nicht berührt.

Zwischenspeicher

Temporärer Speicherbereich, der von einigen Anwendungen (für den Zugriff auf diese Partition sind spezielle App-Berechtigungen erforderlich) und zum Speichern heruntergeladener OTA-Update-Pakete verwendet wird. Andere Programme nutzen diesen Speicherplatz in der Erwartung, 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 OTA-Updates.

Erholung

Enthält ein zweites vollständiges Linux-System, einschließlich eines Kernels und der speziellen Wiederherstellungsbinärdatei, die ein Paket liest und seinen Inhalt zum Aktualisieren der anderen Partitionen verwendet.

Sonstiges

Winzige Partition, die von der Wiederherstellung verwendet wird, um einige Informationen darüber zu speichern, was sie tut, für den Fall, dass das Gerät neu gestartet wird, während das OTA-Paket angewendet wird.

Leben eines OTA-Updates

Ein typisches OTA-Update umfasst die folgenden Schritte:

1. Das Gerät führt einen regelmäßigen Check-in bei OTA-Servern durch und wird über die Verfügbarkeit eines Updates benachrichtigt, einschließlich der URL des Update-Pakets und einer Beschreibungszeichenfolge, die dem Benutzer angezeigt wird.
2. Das Update wird in einen Cache oder eine Datenpartition heruntergeladen und seine kryptografische Signatur wird anhand der Zertifikate in /system/etc/security/otacerts.zip überprüft. Der Benutzer wird aufgefordert, das Update zu installieren.
3. Das Gerät startet im Wiederherstellungsmodus neu, in dem der Kernel und das System in der Wiederherstellungspartition anstelle des Kernels in der Startpartition gebootet werden.
4. Die Wiederherstellungsbinärdatei wird von init gestartet. Es findet Befehlszeilenargumente in /cache/recovery/command , die auf das heruntergeladene Paket verweisen.
5. Die Wiederherstellung überprüft die kryptografische Signatur des Pakets anhand der öffentlichen Schlüssel in /res/keys (Teil der RAM-Disk, die in der Wiederherstellungspartition enthalten ist).
6. Daten werden aus dem Paket abgerufen und bei Bedarf zur Aktualisierung der Boot-, System- und/oder Herstellerpartitionen verwendet. Eine der neuen Dateien auf der Systempartition enthält den Inhalt der neuen Wiederherstellungspartition.
7. Das Gerät startet normal neu.
   1. Die neu aktualisierte Boot-Partition wird geladen und stellt Binärdateien in der neu aktualisierten Systempartition bereit und beginnt mit deren Ausführung.
   2. Im Rahmen des normalen Startvorgangs vergleicht das System den Inhalt der Wiederherstellungspartition mit dem gewünschten Inhalt (der zuvor als Datei in /system gespeichert wurde). Da sie unterschiedlich sind, wird die Wiederherstellungspartition mit den gewünschten Inhalten neu geflasht. (Bei nachfolgenden Startvorgängen enthält die Wiederherstellungspartition bereits den neuen Inhalt, sodass kein erneutes Flashen erforderlich ist.)

Das Systemupdate ist abgeschlossen! Die Update-Protokolle finden Sie in /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. Nach der Überprüfung der Signatur des Pakets extrahiert recovery diese Binärdatei nach /tmp und führt die Binärdatei aus, wobei die folgenden Argumente übergeben werden:

• Aktualisieren Sie die Versionsnummer der Binär-API . Wenn sich die an die Update-Binärdatei übergebenen Argumente ändern, erhöht sich diese Zahl.
• Dateideskriptor der Befehlspipe . Das Update-Programm kann diese Pipe verwenden, um Befehle an die Wiederherstellungsbinärdatei zurückzusenden, hauptsächlich für Änderungen an der Benutzeroberfläche, z. B. um dem Benutzer den Fortschritt anzuzeigen.
• Dateiname der .zip Datei des Updatepakets .

Ein Update-Paket kann jede statisch verknüpfte Binärdatei als Update-Binärdatei verwenden. Die OTA-Paketerstellungstools verwenden das Updater-Programm ( bootable/recovery/updater ), das eine einfache Skriptsprache bereitstellt, die viele Installationsaufgaben erledigen kann. Sie können jede andere auf dem Gerät ausgeführte Binärdatei ersetzen.

Einzelheiten zur Updater-Binärdatei, der Edify-Syntax und den integrierten Funktionen finden Sie unter Inside OTA Packages .

Von früheren Versionen migrieren

Bei der Migration von der Android-Version 2.3/3.0/4.0 besteht die wichtigste Änderung in der Konvertierung aller gerätespezifischen Funktionen aus einem Satz von C-Funktionen mit vordefinierten Namen in C++-Objekte. Die folgende Tabelle listet die alten Funktionen und die neuen Methoden auf, die einen ungefähr gleichwertigen Zweck erfüllen:

Die Konvertierung alter Funktionen in 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.