Ü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 entweder das Image 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 ramdisk-Partition überschreibt das RAM-Disk, indem das neue RAM-Disk-Image über das alte RAM-Disk-Image geschrieben wird.

    Beim Überschreiben wird der Startspeicherort des vorhandenen Images im eMMC ermittelt und das neue Image an diesen Speicherort kopiert. Das neue Image (Kernel oder RAM-Disk) ist möglicherweise größer als das vorhandene. Um Platz zu schaffen, 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). Durch solche Anpassungen können ODMs SoC-Komponenten ersetzen oder anpassen und Kernelmodule für plattformspezifische Komponenten, Daemons und ODM-spezifische Funktionen auf Hardwareabstraktionsschichten (HALs) implementieren. Diese Partition ist optional. Normalerweise enthält sie Anpassungen, 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. Auf Geräten, die nahtlose Updates unterstützen, können die Wiederherstellungs-Images als RAM-Disk im boot- oder init_boot-Image gespeichert werden (nicht als separates 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 reichen 50 MB bis 100 MB.

  • misc-Partition. Diese Partition wird von der Wiederherstellungspartition verwendet und hat eine Größe von mindestens 4 KB.

  • 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. Sie werden gelöscht, wenn das Gerät auf die Werkseinstellungen zurückgesetzt wird. Die Nutzung dieser Partition ist streng eingeschränkt.

  • 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. Wenn Anbieterkernelmodule in der Partition vendor_dlkm gespeichert werden (im Gegensatz zur Partition vendor), können Kernelmodule aktualisiert werden, ohne dass die Partition vendor aktualisiert werden muss.

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

  • tos-Partition. Auf dieser Partition wird das Binärimage des Trusty-Betriebssystems gespeichert. Sie wird nur verwendet, wenn das Gerät Trusty enthält. Weitere Informationen finden Sie unter TOS-Partitionen.

  • pvmfw-Partition. Auf dieser Partition wird die Firmware der geschützten virtuellen Maschine (Protected Virtual Machine Firmware, pvmfw) gespeichert. 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 unterstützen dynamische Partitionen. Das ist ein Partitionssystem für den Nutzerbereich unter Android, mit dem Partitionen während Over-the-air-Updates (OTA) erstellt, in der Größe geändert oder gelöscht werden können. Weitere Informationen finden Sie unter Dynamische Partitionen.

Wichtige 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 in 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 das 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 die 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, das für OEM-Produkte verwendet wird. 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) ist eine 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.

  • Unter Android 11 und höher können die Partitionen product und vendor auf VNDK-Bibliotheken in der Partition system verweisen, aber nicht auf andere Bibliotheken in der Partition system.

Soong-Produktvarianten

Das Soong-Build-System verwendet Bildvarianten, um Build-Abhä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. Es kann auch Anbietervarianten erstellen, indem vendor_available: true in den Android.bp-Dateien definiert wird. So können Anbietermodule mit Systemmodulen verknüpft werden. VNDK-Bibliotheken, die Anbietervarianten von system-Bibliotheken sind, können auch Anbietervarianten für Anbietermodule erstellen, indem vendor_available: true in den Android.bp-Dateien definiert wird (siehe Beispiel).

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

  • 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.