Produktpartitionen

Android 9 und höher unterstützen das Erstellen von product-Partitionen mit dem Android-Build-System. Bisher wurde unter Android 8.x die Trennung von SoC-spezifischen Komponenten von der system-Partition in die vendor-Partition erzwungen, ohne Speicherplatz für OEM-spezifische Komponenten bereitzustellen, die mit dem Android-Build-System erstellt wurden. Android 9 und höher bietet zusätzliche Berechtigungen und Funktionen für die Zulassungsliste, die für private Apps auf verschiedenen Partitionen gelten.

Produktaufteilungen

Viele OEMs passen das AOSP-System-Image an, um ihre eigenen Funktionen sowie die Anforderungen der Mobilfunkanbieter zu implementieren. Solche Anpassungen machen es jedoch unmöglich, ein einzelnes System-Image für mehrere Software-SKUs zu verwenden. Jedes Bild muss sich unterscheiden, um die Anpassungen zu unterstützen, z. B. für unterschiedliche Sprachen oder Mobilfunkanbieter. Wenn Sie eine separate product-Partition für Anpassungen verwenden, können Sie ein einzelnes System-Image für mehrere Software-SKUs verwenden. Die system-Partition beherbergt generischen Code, der für viele Software-SKUs gemeinsam verwendet werden kann. Die Partition vendor beherbergt weiterhin SoC-spezifischen BSP-Code, der je nach SoC von mehreren Geräten gemeinsam genutzt werden kann.

Die Verwendung separater Partitionen hat einige Nachteile, z. B. die Verwaltung des Speicherplatzes (eine begrenzte Menge an Speicherplatz muss für zukünftiges Wachstum reserviert bleiben) und die Aufrechterhaltung einer stabilen Application Binary Interface (ABI) zwischen Partitionen. Bevor Sie sich für die Verwendung von product-Partitionen entscheiden, sollten Sie sich Ihre individuelle AOSP-Implementierung und mögliche Abhilfemaßnahmen ansehen, z. B. die Neupartitionierung eines Geräts während eines Over-the-air-Updates (OTA-Update), was nicht von Google, sondern von einigen OEMs durchgeführt wird. Dynamische Partitionierung ist eine gute Lösung dafür.

Produktpartitionen und ‑berechtigungen

Unter Android 9 und höher wirkt sich eine Änderung der Berechtigungen und der Zulassungsliste auf die Art und Weise aus, wie Sie Berechtigungen für private Apps auf Ihren „product“-Partitionen gewähren. Die Datei permissions.xml muss sich in derselben Partition wie die privaten Apps befinden. Wenn Sie eine permissions.xml-Datei in der system-Partition für privilegierte Apps ablegen, werden diese Berechtigungen nicht auf privilegierte Apps in der product-Partition ausgeweitet, auch wenn die erste eine Erweiterung der zweiten ist. Weitere Informationen zu Berechtigungen und Zulassungslisten finden Sie unter Zulassungsliste für Berechtigungen mit erhöhten Befugnissen.

Legacy-/oem im Vergleich zu /product

Es gibt zwei Arten von Attributen der product-Partition, je nach Durchsetzung der Produktoberfläche. Außerdem unterscheidet sich die product-Partition von der bisherigen oem-Partition:

Partition Attribute
oem
  • Nicht aktualisierbar; wird in der Regel einmal im Werk geflasht.
  • Sie werden für kleine Abweichungen wie Branding und Farbe erstellt. Ein unterschiedlicher Inhalt der oem-Partition bedeutet nicht, dass die Produktsoftware unterschiedlich ist.
  • Die system-Partition hängt nicht von der oem-Partition ab. Die oem-Partition wird nur verwendet, wenn dort eine bestimmte Datei gefunden wird.
  • Es wird nur die öffentliche API in der Partition system verwendet.
product
  • Aktualisierbar
  • Mit dem System-Image verknüpft (wird zusammen aktualisiert)
  • Sie werden pro Produkt oder Produktfamilie erstellt.
  • Die Systempartition kann von der product-Partition abhängen.
  • Nicht öffentliche APIs können verwendet werden, da sie gleichzeitig aktualisiert werden.
product (erzwungene Schnittstellen)
  • Aktualisierbar
  • Sie sind vom System-Image getrennt.
  • Sie werden pro Produkt oder Produktfamilie erstellt.
  • Die system-Partition hängt nicht von der product-Partition ab.
  • Es können keine versteckten APIs verwendet werden, sondern nur öffentliche und System-APIs auf der system-Partition.

Aus diesen Gründen unterstützt Android 9 die product-Partition und behält die Unterstützung für die alte oem-Partition für Geräte bei, die darauf angewiesen sind. Um die product-Partition von der system-Partition zu entkoppeln, unterstützt Android 11 die Erzwigung von product-Schnittstellen.

/product components

Die product-Partition enthält die folgenden Komponenten:

  • Produktspezifische Systemeigenschaften (/product/build.prop)
  • Produktspezifische Rücknahmebedingungen (/product/overlay/*.apk)
  • Produktspezifische Apps (/product/app/*.apk)
  • Produktspezifische private Apps (/product/priv-app/*.apk)
  • Produktspezifische Bibliotheken (/product/lib/*)
  • Produktspezifische Java-Bibliotheken (/product/framework/*.jar)
  • Produktspezifische Android-Framework-Systemkonfigurationen (/product/etc/sysconfig/* und /product/etc/permissions/*)
  • Produktspezifische Mediendateien (/product/media/audio/*)
  • Produktspezifische bootanimation-Dateien

Keine „custom_images“

Sie können custom_images nicht verwenden. Folgende Funktionen werden nicht unterstützt:

  • Module in einem bestimmten Ziel installieren custom_images unterstützt das Kopieren von Artefakten in ein Image, kann aber kein Modul in einer bestimmten Partition installieren, indem die Zielpartition als Teil einer Build-Regel angegeben wird.
  • Soong-Support custom_images kann nicht mit dem Soong-Buildsystem erstellt werden.
  • Unterstützung für OTA-Updates custom_images werden als ROM-Images des Herstellers verwendet, die keine OTA-Updates erhalten können.

ABIs zwischen Partitionen beibehalten

Die product-Partition in Android 9 ist eine Erweiterung der system-Partition. Zwischen den Partitionen product und system gibt es eine schwache ABI. Daher müssen beide gleichzeitig aktualisiert werden und die ABI sollte system-SDK-basiert sein. Wenn das System-SDK nicht alle API-Oberflächen zwischen product und system abdeckt, müssen OEMs zwischen den beiden Partitionen eigene ABIs verwalten.

Die Partitionen product und system können voneinander abhängig sein. Tests mit dem generischen System-Image (GSI) müssen jedoch ohne die product-Partition ordnungsgemäß funktionieren.

Wenn die product-Schnittstellen erzwungen werden, wird die product-Partition von der system-Partition getrennt. In der product-Partition werden nur die zulässigen Schnittstellen aus der system-Partition verwendet.

Die product-Partition darf keine Abhängigkeiten über instabile Schnittstellen von der vendor-Partition haben. Eine direkte Interaktion zwischen den Partitionen product und vendor ist nicht zulässig. (Dies wird von SEpolicy erzwungen.)

Produktaufteilungen implementieren

Lesen Sie sich vor der Implementierung einer neuen Produktpartition die zugehörigen Änderungen an der Produktpartition in AOSP durch. Fügen Sie zum Einrichten von product dann die folgenden Flags für das Board oder die Produktversion ein:

  • BOARD_USES_PRODUCTIMAGE
  • BOARD_PRODUCTIMAGE_PARTITION_SIZE
  • BOARD_PRODUCTIMAGE_FILE_SYSTEM_TYPE
  • PRODUCT_PRODUCT_PROPERTIES für /product/build.prop. Sie müssen in einem $(call inherit-product path/to/device.mk) stehen, wie in PRODUCT_PRODUCT_PROPERTIES += product.abc=ok.

Modul in der Produktpartition installieren

Verwenden Sie die folgenden Build-Flags, um ein Modul auf der Partition product zu installieren.

  • product_specific: true in Android.bp
  • LOCAL_PRODUCT_MODULE := true in Android.mk

Bootmodus mit Verifikation aktivieren

Um zu verhindern, dass die Partition product von schädlicher Software manipuliert wird, aktivieren Sie für diese Partition den Android-verifizierten Boot (AVB), genau wie für die Partitionen vendor und system. Wenn Sie AVB aktivieren möchten, fügen Sie die folgenden Build-Flags hinzu: BOARD_AVB_PRODUCT_ADD_HASHTREE_FOOTER_ARGS.