Überblick

Android-Geräte verfügen über mehrere Partitionen, die beim Bootvorgang unterschiedliche Funktionen erfüllen.

Standardpartitionen

  • boot . Diese Partition enthält ein Kernel-Image und wird mit mkbootimg erstellt. Sie können eine virtuelle Partition verwenden, um eines der Images direkt zu flashen, ohne eine neue Boot-Partition zu flashen. Diese Partition enthält auch die generische Ramdisk in Geräten, die vor Android 13 gestartet wurden.

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

    • Ramdisk. Die virtuelle ramdisk Partition überschreibt die Ramdisk, indem sie das neue Ramdisk-Image über das alte Ramdisk-Image schreibt.

    Der Überschreibvorgang ermittelt den Startort des vorhandenen Bildes in eMMC und kopiert das neue Bild an diesen Ort. Das neue Image (Kernel oder Ramdisk) ist möglicherweise größer als das vorhandene; Um Platz zu schaffen, kann der Bootloader Daten nach dem Image verschieben oder den Vorgang mit einem Fehler abbrechen.

  • init_boot Partition. Diese Partition enthält die generische Ramdisk für Geräte, die mit Android 13 und höher starten.

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

  • odm Partition. Diese Partition enthält Original-Design-Manufacturer-Anpassungen (ODM) an System-on-Chip-(SoC)-Anbieter-Board-Support-Packages (BSPs). Solche Anpassungen ermöglichen es ODMs, SoC-Komponenten zu ersetzen oder anzupassen und Kernelmodule für platinenspezifische Komponenten, Daemons und ODM-spezifische Funktionen auf Hardware-Abstraktionsschichten (HALs) zu implementieren. Diese Partition ist optional; In der Regel werden darin Anpassungen enthalten, sodass Geräte ein einziges Anbieter-Image für mehrere Hardware-SKUs verwenden können. Einzelheiten finden Sie unter ODM-Partitionen .

  • odm_dlkm -Partition. Diese Partition ist für die Speicherung von ODM-Kernelmodulen vorgesehen. Durch das Speichern von ODM-Kernelmodulen in der odm_dlkm Partition (im Gegensatz zur odm Partition) ist es möglich, ODM-Kernelmodule zu aktualisieren, ohne die odm Partition zu aktualisieren.

  • recovery . Diese Partition speichert das Wiederherstellungsimage, das während des OTA-Prozesses gebootet wird. Geräte, die nahtlose Updates unterstützen, können die Wiederherstellungsimages als Ramdisk speichern, die im boot oder init_boot Image enthalten ist (statt als separates Image).

  • cache Partition. Diese Partition speichert temporäre Daten und ist optional, wenn ein Gerät nahtlose Updates verwendet. Die Cache-Partition muss vom Bootloader aus nicht beschreibbar, aber löschbar sein. Die Partitionsgröße hängt vom Gerätetyp und der Verfügbarkeit von Speicherplatz auf userdata ab; Normalerweise sind 50 MB–100 MB ausreichend.

  • misc Partition. Diese Partition wird von der Wiederherstellungspartition verwendet und ist 4 KB oder größer.

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

  • metadata . Diese Partition wird zum Speichern des Metadaten-Verschlüsselungsschlüssels verwendet, wenn das Gerät Metadaten-Verschlüsselung verwendet. Die Größe beträgt 16 MB oder mehr. Es ist nicht verschlüsselt und seine Daten werden nicht als Snapshot erstellt. Sie wird gelöscht, wenn das Gerät auf die Werkseinstellungen zurückgesetzt wird. Die Nutzung dieser Partition ist streng begrenzt.

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

  • vendor_dlkm Partition. Diese Partition dient der Speicherung von Kernelmodulen des Herstellers. Durch das Speichern von Vendor-Kernel-Modulen in der vendor_dlkm Partition (im Gegensatz zur vendor Partition) ist es möglich, Kernel-Module zu aktualisieren, ohne die vendor Partition zu aktualisieren.

  • radio . Diese Partition enthält das Radio-Image und wird nur für Geräte benötigt, die ein Radio mit radiospezifischer Software in einer dedizierten Partition enthalten.

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

  • pvmfw Partition. Diese Partition speichert die Protected Virtual Machine Firmware (pvmfw), den ersten Code, der in geschützten VMs ausgeführt wird. Weitere Einzelheiten finden Sie unter Firmware für geschützte virtuelle Maschinen .

Dynamische Partitionen

Geräte mit Android 11 und höher können dynamische Partitionen unterstützen. Dabei handelt es sich um ein Userspace-Partitionierungssystem für Android, das das Erstellen, Ändern der Größe oder Zerstören von Partitionen während Over-the-Air-Updates (OTA) ermöglicht. Einzelheiten finden Sie unter Dynamische Partitionen .

Kritische Partitionen festlegen

Wenn für die Ausführung des Geräts bestimmte Partitionen oder Daten erforderlich sind, müssen Sie diese Partitionen/Daten entweder als vollständig geschützt oder als erneut flashbar kennzeichnen, was bedeutet, dass sie mit einem fastboot oem Befehl neu erstellt, bereitgestellt oder extrahiert werden können. Dazu gehören Daten wie werksspezifische Einstellungen pro Gerät, Seriennummern, Kalibrierungsdaten und mehr.

Änderungen in Android 11

Android 11 beinhaltet zahlreiche Änderungen an Partitionen, darunter Einschränkungen bei der Verknüpfung mit Bibliotheken und neue Soong-Image-Varianten.

Android-Partitionslayout

Abbildung 1. Partitionslayout in Android 11

  • Einzelsystem-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 die Erstellung der system und system_ext -Images überspringen.

  • system_ext Partition. Eine neue Partition, die system nutzen und Systemmodule enthalten kann, die:

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

    • Bündeln Sie OEM- oder SoC-spezifische Module. Wir empfehlen, solche Module zu entbündeln, damit sie auf der product oder vendor installiert werden können.

  • system . Gemeinsames System-Image, das für OEM-Produkte verwendet wird. Wir empfehlen, proprietäre Module aus der system zu verschieben, entweder durch Upstreaming zu AOSP oder durch Verschieben in die system_ext Partition.

  • product . Diese Partition kann jetzt zulässige Schnittstellen verwenden, 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 system installiert werden und ausschließlich für Anbieter zur Implementierung ihrer HALs entwickelt wurden.

  • In Android 10 und niedriger kann die vendor mit VNDK-Bibliotheken in der system verknüpft werden, jedoch nicht mit anderen Bibliotheken in der system . Native Module in der product können mit jeder Bibliothek in der system verknüpft werden.

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

Bald Produktvarianten

Das Soong- Build-System verwendet Image-Varianten, um Build-Abhängigkeiten aufzuteilen. Native Module ( /build/soong/cc ) können Systemprozessmodule zur Kernvariante und Anbieterprozessmodule zur Anbietervariante mutieren; Ein Modul in einer Bildvariante kann nicht mit anderen Modulen in einer anderen Bildvariante verknüpft werden.

  • In Android 10 oder niedriger erstellt ein Systemmodul automatisch Kernvarianten. Es kann auch Herstellervarianten erstellen, indem es vendor_available: true in seinen Android.bp Dateien definiert; Dadurch können Herstellermodule mit Systemmodulen verknüpft werden. VNDK-Bibliotheken, bei denen es sich um Anbietervarianten von system handelt, können auch Anbietervarianten für Anbietermodule erstellen, indem sie vendor_available: true in ihren Android.bp Dateien definieren (siehe Beispiel ).

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

  • In Android 12 oder höher erstellt ein Systemmodul mit vendor_available: true zusätzlich zur Kernvariante eine Vendor-Variante. Um eine Produktvariante zu erstellen, muss product_available: true definiert werden. Einige VNDK-Bibliotheken ohne product_available: true sind für Produktmodule nicht verfügbar.