Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.
Nicht A/B-Systemupdates
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
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:
-
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.
-
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.
-
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.
-
Das Wiederherstellungs-Binärprogramm wird von init gestartet. Es sucht in
/cache/recovery/command nach Befehlszeilenargumenten, die auf das heruntergeladene Paket verweisen.
-
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.
-
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.
-
Das Gerät wird normal neu gestartet.
-
Die neu aktualisierte Bootpartition wird geladen und bereitgestellt. Anschließend werden Binärdateien in der neu aktualisierten Systempartition ausgeführt.
-
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.
Alle Inhalte und Codebeispiele auf dieser Seite unterliegen den Lizenzen wie im Abschnitt Inhaltslizenz beschrieben. Java und OpenJDK sind Marken oder eingetragene Marken von Oracle und/oder seinen Tochtergesellschaften.
Zuletzt aktualisiert: 2025-07-27 (UTC).
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Benötigte Informationen nicht gefunden","missingTheInformationINeed","thumb-down"],["Zu umständlich/zu viele Schritte","tooComplicatedTooManySteps","thumb-down"],["Nicht mehr aktuell","outOfDate","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Problem mit Beispielen/Code","samplesCodeIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-07-27 (UTC)."],[],[],null,["# Non-A/B system updates\n\nNon AB updates are a deprecated OTA methodology used by older Android Devices (Android 6 and\nearlier). These devices have a dedicated recovery partition containing the software needed to\nunpack a downloaded update package and apply the update to the other partitions.\n\n\nOn older Android devices without A/B partitions, the flash space typically contains the\nfollowing partitions:\n\nboot\n:\n Contains the Linux kernel and a minimal root filesystem (loaded into a RAM disk). It mounts\n system and other partitions and starts the runtime located on the system partition.\n\nsystem\n:\n Contains system applications and libraries that have source code available on Android Open\n Source Project (AOSP). During normal operation, this partition is mounted read-only; its\n contents change only during an OTA update.\n\nvendor\n:\n Contains system applications and libraries that do *not* have source code available\n on Android Open Source Project (AOSP). During normal operation, this partition is mounted\n read-only; its contents change only during an OTA update.\n\nuserdata\n:\n Stores the data saved by applications installed by the user, etc. This partition is not\n normally touched by the OTA update process.\n\ncache\n:\n Temporary holding area used by a few applications (accessing this partition requires special\n app permissions) and for storage of downloaded OTA update packages. Other programs use this\n space with the expectation that files can disappear at any time. Some OTA package\n installations may result in this partition being wiped completely. The cache also contains\n the update logs from an OTA update.\n\nrecovery\n:\n Contains a second complete Linux system, including a kernel and the special recovery binary\n that reads a package and uses its contents to update the other partitions.\n\nmisc\n:\n Tiny partition used by recovery to stash some information away about what it is doing in\n case the device is restarted while the OTA package is being applied.\n\nLife of an OTA update\n---------------------\n\nA typical OTA update contains the following steps:\n\n1. Device performs regular check in with OTA servers and is notified of the availability of an update, including the URL of the update package and a description string to show the user.\n2. Update downloads to a cache or data partition, and its cryptographic signature is verified against the certificates in `/system/etc/security/otacerts.zip`. User is prompted to install the update.\n3. Device reboots into recovery mode, in which the kernel and system in the recovery partition are booted instead of the kernel in the boot partition.\n4. Recovery binary is started by init. It finds command-line arguments in `/cache/recovery/command` that point it to the downloaded package.\n5. Recovery verifies the cryptographic signature of the package against the public keys in `/res/keys` (part of the RAM disk contained in the recovery partition).\n6. Data is pulled from the package and used to update the boot, system, and/or vendor partitions as necessary. One of the new files left on the system partition contains the contents of the new recovery partition.\n7. Device reboots normally.\n 1. The newly updated boot partition is loaded, and it mounts and starts executing binaries in the newly updated system partition.\n 2. As part of normal startup, the system checks the contents of the recovery partition against the desired contents (which were previously stored as a file in `/system`). They are different, so the recovery partition is reflashed with the desired contents. (On subsequent boots, the recovery partition already contains the new contents, so no reflash is necessary.)\n\n\nThe system update is complete! The update logs can be found in\n`/cache/recovery/last_log.`\u003cvar translate=\"no\"\u003e#\u003c/var\u003e.\n\nUpdate packages\n---------------\n\n\nAn update package is a `.zip` file that contains the executable binary\n`META-INF/com/google/android/update-binary`. After verifying the signature on the\npackage, `recovery` extracts this binary to `/tmp` and runs the binary,\npassing the following arguments:\n\n- **Update binary API version number**. If the arguments passed to the update binary change, this number increments.\n- **File descriptor of the *command pipe***. The update program can use this pipe to send commands back to the recovery binary, mostly for UI changes, such as indicating progress to the user.\n- **Filename of the update package `.zip` file**.\n\n\nAn update package can use any statically linked binary as the update binary. The OTA package\nconstruction tools use the updater program (`bootable/recovery/updater`), which\nprovides a simple scripting language that can do many installation tasks. You can substitute\nany other binary running on the device.\n\n\nFor details on the updater binary, edify syntax, and builtin functions, see\n[Inside OTA Packages](/docs/core/ota/nonab/inside_packages).\n\nMigrate from previous releases\n------------------------------\n\n\nWhen migrating from Android 2.3/3.0/4.0 release, the major change is the conversion of all the\ndevice-specific functionality from a set of C functions with predefined names to C++ objects.\nThe following table lists the old functions and the new methods that serve a roughly\nequivalent purpose:\n\n| C function | C++ method |\n|---------------------------------------------|----------------------------------------------------------|\n| device_recovery_start() | Device::RecoveryStart() |\n| device_toggle_display() device_reboot_now() | RecoveryUI::CheckKey() (also RecoveryUI::IsKeyPressed()) |\n| device_handle_key() | Device::HandleMenuKey() |\n| device_perform_action() | Device::InvokeMenuItem() |\n| device_wipe_data() | Device::WipeData() |\n| device_ui_init() | ScreenRecoveryUI::Init() |\n\n\nConversion of old functions to new methods should be reasonably straightforward. Don't forget\nto add the new `make_device()`\nfunction to create and return an instance of your new Device subclass."]]
