Nicht-A/B-Systemaktualisierungen

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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 (geladen in eine RAM-Disk). Es mountet System- und andere Partitionen und startet die Runtime, die sich auf der Systempartition befindet.
System
Enthält Systemanwendungen und Bibliotheken, deren Quellcode im Android Open Source Project (AOSP) verfügbar ist. Während des normalen Betriebs ist diese Partition schreibgeschützt eingehängt; sein Inhalt ändert sich nur während eines OTA-Updates.
Verkäufer
Enthält Systemanwendungen und Bibliotheken, für die kein Quellcode im Android Open Source Project (AOSP) verfügbar ist. Während des normalen Betriebs ist diese Partition schreibgeschützt eingehängt; sein Inhalt ändert sich nur während eines OTA-Updates.
Benutzerdaten
Speichert die Daten, die von Anwendungen gespeichert wurden, die vom Benutzer installiert wurden usw. Diese Partition wird normalerweise nicht vom OTA-Aktualisierungsprozess berührt.
Zwischenspeicher
Temporärer Haltebereich, der von einigen Anwendungen verwendet wird (der Zugriff auf diese Partition erfordert spezielle App-Berechtigungen) und zum Speichern heruntergeladener OTA-Aktualisierungspakete. Andere Programme verwenden diesen Speicherplatz mit 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.
Wiederherstellung
Enthält ein zweites vollständiges Linux-System, einschließlich eines Kernels und der speziellen Wiederherstellungs-Binärdatei, die ein Paket liest und seinen Inhalt verwendet, um die anderen Partitionen zu aktualisieren.
versch
Winzige Partition, die von der Wiederherstellung verwendet wird, um einige Informationen darüber zu speichern, was sie tut, falls das Gerät neu gestartet wird, während das OTA-Paket angewendet wird.

Lebensdauer 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. Aktualisieren Sie Downloads in einen Cache oder eine Datenpartition, und ihre kryptografische Signatur wird anhand der Zertifikate in /system/etc/security/otacerts.zip . 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 gestartet werden.
  4. Die Wiederherstellungs-Binärdatei wird von init gestartet. Es findet Befehlszeilenargumente in /cache/recovery/command , die auf das heruntergeladene Paket verweisen.
  5. Die Wiederherstellung verifiziert 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 gezogen und verwendet, um die Start-, System- und/oder Herstellerpartitionen nach Bedarf zu aktualisieren. Eine der neuen Dateien, die auf der Systempartition verbleiben, enthält den Inhalt der neuen Wiederherstellungspartition.
  7. Das Gerät startet normal neu.
    1. Die neu aktualisierte Boot-Partition wird geladen und sie mountet und beginnt mit der Ausführung von Binärdateien in der neu aktualisierten Systempartition.
    2. Als Teil des normalen Starts vergleicht das System den Inhalt der Wiederherstellungspartition mit den gewünschten Inhalten (die zuvor als Datei in /system gespeichert waren). Sie sind unterschiedlich, daher wird die Wiederherstellungspartition mit den gewünschten Inhalten neu geflasht. (Bei nachfolgenden Starts enthält die Wiederherstellungspartition bereits den neuen Inhalt, sodass kein erneutes Flashen erforderlich ist.)

Das Systemupdate ist abgeschlossen! Die Aktualisierungsprotokolle 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 Ü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ären API . Wenn sich die an die Update-Binärdatei übergebenen Argumente ändern, erhöht sich diese Zahl.
  • Dateideskriptor der Befehlspipe . Das Aktualisierungsprogramm kann diese Pipe verwenden, um Befehle zurück an die Wiederherstellungsbinärdatei zu senden, hauptsächlich für Änderungen der Benutzeroberfläche, z. B. um dem Benutzer den Fortschritt anzuzeigen.
  • Dateiname der .zip -Datei des Aktualisierungspakets .

Ein Aktualisierungspaket kann jede statisch verknüpfte Binärdatei als Aktualisierungsbinärdatei verwenden. Die Tools zum Erstellen von OTA-Paketen verwenden das Updater-Programm ( bootable 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, Edify-Syntax und integrierten Funktionen finden Sie unter Inside OTA Packages .

Migration von früheren Versionen

Bei der Migration von Android 2.3/3.0/4.0 ist die wichtigste Änderung die Konvertierung aller gerätespezifischen Funktionen von einer Reihe von C-Funktionen mit vordefinierten Namen in C++-Objekte. Die folgende Tabelle listet die alten Funktionen und die neuen Methoden auf, die einem ungefähr gleichwertigen Zweck dienen:

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

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.