Übersicht

Android-Geräte enthalten mehrere Partitionen, die während des Startvorgangs unterschiedliche Funktionen erfüllen.

Standardpartitionen

  • boot Partition. Diese Partition enthält ein Kernel-Image und wird mit mkbootimg erstellt. Sie können eine virtuelle Partition verwenden, um jedes Image 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 das neue Kernel-Image über das alte Kernel-Image geschrieben wird. Wenn der bereitgestellte Entwicklungskernel nicht kompatibel ist, müssen Sie möglicherweise die vendor , system oder dtb Partition (falls vorhanden) mit zugehörigen Kernelmodulen aktualisieren.

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

    Die Überschreiboperation bestimmt den Startort des vorhandenen Abbilds in eMMC und kopiert das neue Abbild 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 gestartet werden.

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

  • odm Partition. Diese Partition enthält Original Design Manufacturer (ODM)-Anpassungen 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 Board-spezifische Komponenten, Daemons und ODM-spezifische Funktionen auf Hardware-Abstraktionsschichten (HALs) zu implementieren. Diese Partition ist optional; In der Regel wird es verwendet, um Anpassungen zu enthalten, damit Geräte ein einzelnes Anbieterimage für mehrere Hardware-SKUs verwenden können. Einzelheiten finden Sie unter ODM-Partitionen .

  • odm_dlkm Partition. Diese Partition dient zum Speichern von ODM-Kernel-Modulen. Das Speichern von ODM-Kernel-Modulen in der odm_dlkm Partition (im Gegensatz zur odm Partition) ermöglicht es, ODM-Kernel-Module zu aktualisieren, ohne die odm Partition zu aktualisieren.

  • recovery . Diese Partition speichert das Wiederherstellungsabbild, das während des OTA-Prozesses gebootet wird. Geräte, die nahtlose Updates unterstützen, können die Wiederherstellungs-Images 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 nicht vom Bootloader beschreibbar sein, muss aber löschbar sein. Die Partitionsgröße hängt vom Gerätetyp und der Verfügbarkeit von Speicherplatz für userdata ; normalerweise sind 50 MB bis 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 die Metadatenverschlüsselung verwendet . Die Größe beträgt 16 MB oder mehr. Es ist nicht verschlüsselt und seine Daten werden nicht gespeichert. Es 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 zum Speichern von Hersteller-Kernel-Modulen. Das Speichern von Anbieter-Kernel-Modulen in der vendor_dlkm Partition (im Gegensatz zur vendor -Partition) ermöglicht es, Kernel-Module zu aktualisieren, ohne die vendor -Partition zu aktualisieren.

  • radio Partition. 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ärabbild des Trusty-Betriebssystems und wird nur verwendet, wenn das Gerät Trusty enthält. Einzelheiten finden Sie unter TOS-Partitionen .

Dynamische Partitionen

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

Festlegen kritischer Partitionen

Wenn das Gerät zum Ausführen bestimmte Partitionen oder Daten benötigt, müssen Sie diese Partitionen/Daten entweder als vollständig geschützt oder als re- fastboot oem , d. Dazu gehören Daten wie werksspezifische Einstellungen pro Gerät, Seriennummern, Kalibrierungsdaten und mehr.

Änderungen in Android 11

Android 11 enthält 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

  • Single-System-Image (SSI). Ein neues, konzeptionelles Image, das die Images system und system_ext enthält. Wenn diese Partitionen für eine Reihe von Zielgeräten gleich 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 verwenden und Systemmodule enthalten kann, die:

    • Erweitern Sie AOSP-Systemmodule in der system . Wir empfehlen, solche Module zu AOSP hochzuladen, 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 . Allgemeines Systemabbild, 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 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 , aber nicht mit anderen Bibliotheken in der system verknüpft werden. 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, aber nicht mit anderen Bibliotheken in der system .

Baldige 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 Core-Varianten. Es kann auch Anbietervarianten erstellen, indem es in seinen Android.bp Dateien „ vendor_available: true “ definiert; Dadurch können Herstellermodule mit Systemmodulen verknüpft werden. VNDK-Bibliotheken, die Anbietervarianten von system sind, können auch Anbietervarianten für Anbietermodule erstellen, indem sie in ihren Android.bp Dateien „ vendor_available: true “ definieren (siehe Beispiel ).

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

  • In Android 12 oder höher erstellt ein Systemmodul mit vendor_available: true zusätzlich zur Core-Variante 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.