Übersicht

Android-Geräte haben mehrere Partitionen, die verschiedene Funktionen beim Booten haben.

Standardpartitionen

  • boot-Partition. Diese Partition enthält ein Kernel-Image und wird mit mkbootimg erstellt. Sie können eine virtuelle Partition verwenden, um die Images direkt zu flashen, ohne eine neue Bootpartition zu flashen. Diese Partition enthält auch das generische RAM-Disk auf Geräten, die vor Android 13 auf den Markt gebracht wurden.

    • kernel. Die virtuelle kernel-Partition überschreibt den Kernel (zImage, zImage-dtb, Image.gz-dtb), indem das neue Kernel-Image über das alte Kernel-Image geschrieben wird. Wenn der bereitgestellte Entwicklungskernel nicht kompatibel ist, müssen Sie möglicherweise die Partition vendor, system oder dtb (falls vorhanden) mit den zugehörigen Kernelmodulen aktualisieren.

    • ramdisk. Die virtuelle Partition ramdisk überschreibt Ramdisk, indem das neue RAM-Disk-Image das alte RAM-Disk-Image überschreibt.

    Beim Überschreiben wird der Startort des vorhandenen Images in eMMC bestimmt und das neue Image dorthin kopiert. Das neue Image (Kernel oder RAM-Disk) ist möglicherweise größer als das vorhandene. Um Speicherplatz freizugeben, kann der Bootloader Daten nach dem Image verschieben oder den Vorgang mit einer Fehlermeldung abbrechen.

  • init_boot-Partition. Diese Partition enthält das generische RAM-Disk für Geräte, die mit Android 13 oder höher gestartet werden.

  • system-Partition. Diese Partition enthält das Android-Framework.

  • odm-Partition. Diese Partition enthält Anpassungen von ODMs (Original Design Manufacturers) an die Board-Support-Pakete (BSPs) von SoC-Anbietern (System-on-Chip). Solche Anpassungen ermöglichen es ODMs, SoC-Komponenten zu ersetzen oder anzupassen und Kernelmodule für boardspezifische Komponenten, Daemons und ODM-spezifische Funktionen auf Hardwareabstraktionsebenen (HALs) zu implementieren. Diese Partition ist optional. Sie wird in der Regel verwendet, um Anpassungen zu enthalten, damit Geräte ein einzelnes Anbieter-Image für mehrere Hardware-SKUs verwenden können. Weitere Informationen finden Sie unter ODM-Partitionen.

  • odm_dlkm-Partition. Diese Partition ist zum Speichern von ODM-Kernelmodulen vorgesehen. Wenn ODM-Kernelmodule in der odm_dlkm-Partition gespeichert werden (im Gegensatz zur odm-Partition), können ODM-Kernelmodule aktualisiert werden, ohne dass die odm-Partition aktualisiert werden muss.

  • recovery-Partition. Auf dieser Partition wird das Wiederherstellungs-Image gespeichert, das während des Over-the-air-Prozesses gestartet wird. Geräte, die nahtlose Updates unterstützen, können die Wiederherstellungs-Images als RAM-Disk im boot- oder init_boot-Image speichern (anstatt in einem separaten Image).

  • cache-Partition. In dieser Partition werden temporäre Daten gespeichert. Sie ist optional, wenn auf einem Gerät nahtlose Updates verwendet werden. Die Cache-Partition muss nicht über den Bootloader beschreibbar sein, aber sie muss löschbar sein. Die Größe der Partition hängt vom Gerätetyp und vom verfügbaren Speicherplatz auf userdata ab. Normalerweise sind 50 MB bis 100 MB ausreichend.

  • misc-Partition. Diese Partition wird von der Wiederherstellungspartition verwendet und ist mindestens 4 KB groß.

  • userdata-Partition. Diese Partition enthält vom Nutzer installierte Apps und Daten, einschließlich Anpassungsdaten.

  • metadata-Partition. Auf dieser Partition wird der Metadatenverschlüsselungsschlüssel gespeichert, wenn auf dem Gerät die Metadatenverschlüsselung verwendet wird. Die Größe ist 16 MB oder mehr. Sie ist nicht verschlüsselt und es werden keine Snapshots ihrer Daten erstellt. Die Daten werden beim Zurücksetzen des Geräts auf die Werkseinstellungen gelöscht. Die Nutzung dieser Partition ist streng begrenzt.

  • vendor-Partition. Diese Partition enthält alle Binärdateien, die nicht für AOSP freigegeben werden können. Wenn das Gerät keine proprietären Informationen enthält, können Sie diese Partition weglassen.

  • vendor_dlkm-Partition. Diese Partition ist für das Speichern von Kernelmodulen von Anbietern vorgesehen. Durch das Speichern der Kernelmodule des Anbieters in der Partition vendor_dlkm (im Gegensatz zur Partition vendor) können Kernelmodule aktualisiert werden, ohne die Partition vendor zu aktualisieren.

  • radio-Partition. Diese Partition enthält das Radio-Image und ist nur für Geräte erforderlich, die ein Radio mit radiospezifischer Software in einer speziellen Partition enthalten.

  • tos-Partition. Diese Partition speichert das Binär-Image des Trusty-Betriebssystems und wird nur verwendet, wenn das Gerät Trusty enthält. Weitere Informationen finden Sie unter TOS-Partitionen.

  • pvmfw-Partition. Diese Partition speichert die Firmware der Protected Virtual Machine (pvmfw). Dies ist der erste Code, der in geschützten VMs ausgeführt wird. Weitere Informationen finden Sie unter Geschützte Firmware virtueller Maschinen.

Dynamische Partitionen

Geräte mit Android 11 und höher können dynamische Partitionen unterstützen. Sie sind ein Partitionierungssystem für den Nutzerbereich für Android, mit dem Partitionen während Over-the-Air-Aktualisierungen (OTA) erstellt, in der Größe angepasst oder gelöscht werden können. Weitere Informationen finden Sie unter Dynamische Partitionen.

Kritische Partitionen festlegen

Wenn für das Gerät bestimmte Partitionen oder Daten zum Ausführen erforderlich sind, müssen Sie diese Partitionen oder Daten entweder als vollständig geschützt oder als wiederaufladbar kennzeichnen. Das bedeutet, dass sie mit einem fastboot oem-Befehl neu erstellt, bereitgestellt oder extrahiert werden können. Dazu gehören unter anderem gerätespezifische werkseitige Einstellungen, Seriennummern und Kalibrierungsdaten.

Änderungen bei Android 11

Android 11 enthält zahlreiche Änderungen an Partitionen, einschließlich Einschränkungen bei der Verknüpfung mit Bibliotheken und neuen Soong-Imagevarianten.

Android-Partitionslayout

Abbildung 1. Partitionslayout in Android 11

  • Single System Image (SSI) Ein neues, konzeptionelles Bild, das die Bilder system und system_ext enthält. Wenn diese Partitionen für eine Reihe von Zielgeräten gemeinsam sind, können diese Geräte die SSI gemeinsam nutzen und das Erstellen der system- und system_ext-Images überspringen.

  • system_ext-Partition. Eine neue Partition, die system-Ressourcen verwenden und Systemmodule enthalten kann, die:

    • Erweitern Sie AOSP-Systemmodule in der Partition system. Wir empfehlen, solche Module an AOSP weiterzuleiten, damit sie später auf der system-Partition installiert werden können.

    • OEM- oder SoC-spezifische Module in Bundles zusammenfassen Wir empfehlen, solche Module zu entkoppeln, damit sie auf der Partition product oder vendor installiert werden können.

  • system-Partition. Gängiges System-Image für OEM-Produkte. Wir empfehlen, proprietäre Module aus der system-Partition zu verschieben, entweder indem Sie sie an AOSP weiterleiten oder in die system_ext-Partition verschieben.

  • product-Partition. Auf dieser Partition können jetzt zulässige Schnittstellen verwendet werden, um produktspezifische Module zu installieren, die nicht mit anderen Partitionen gebündelt sind.

VNDK-Änderungen

Das Vendor Native Development Kit (VNDK) besteht aus einer Reihe von Bibliotheken, die in der Partition system installiert sind und ausschließlich für Anbieter zur Implementierung ihrer HALs entwickelt wurden.

  • Unter Android 10 und niedriger kann die Partition vendor auf VNDK-Bibliotheken in der Partition system verweisen, aber nicht auf andere Bibliotheken in der Partition system. Native Module in der product-Partition können mit jeder Bibliothek in der system-Partition verknüpft werden.

  • Ab Android 11 können die Partitionen product und vendor mit VNDK-Bibliotheken in der Partition system verknüpft werden, jedoch nicht mit anderen Bibliotheken in der Partition system.

Soong-Produktvarianten

Das Soong-Buildsystem verwendet Bildvarianten, um Buildabhängigkeiten aufzuteilen. Native Module (/build/soong/cc) können Systemprozessmodule in die Kernvariante und Anbieterprozessmodule in die Anbietervariante umwandeln. Ein Modul in einer Bildvariante kann nicht mit anderen Modulen in einer anderen Bildvariante verknüpft werden.

  • Unter Android 10 oder niedriger werden Kernvarianten automatisch von einem Systemmodul erstellt. Außerdem können Anbietervarianten erstellt werden, indem vendor_available: true in den Android.bp-Dateien definiert wird. Dadurch können Anbietermodule mit Systemmodulen verknüpft werden. VNDK-Bibliotheken, bei denen es sich um Anbietervarianten von system-Bibliotheken handelt, können auch Anbietervarianten für Anbietermodule erstellen. Dazu definieren sie vendor_available: true in den zugehörigen Android.bp-Dateien (Beispiel).

  • In Android 11 kann ein Systemmodul zusätzlich zu Kern- und Anbietervarianten auch eine Produktvariante erstellen. Dazu wird vendor_available: true definiert.

  • Unter Android 12 oder höher wird durch ein Systemmodul mit vendor_available: true zusätzlich zur Kernvariante eine Anbietervariante erstellt. Damit eine Produktvariante erstellt werden kann, muss product_available: true definiert sein. Einige VNDK-Bibliotheken ohne product_available: true sind für Produktmodule nicht verfügbar.