ODM-Partitionen

Android 10 bietet Unterstützung für die Erstellung odm Partitionen mithilfe des Android-Build-Systems.

Über ODM-Partitionen

Original Design Manufacturers (ODMs) passen die Board-Support-Pakete (BSPs) von System-on-Chip (SoC)-Anbietern an ihre spezifischen Geräte (ihre Boards) an. Dies ermöglicht es ihnen, Kernel-Module für platinenspezifische Komponenten, platinenspezifische Daemons oder eigene Funktionen auf Hardware-Abstraktionsschichten (HALs) zu implementieren. Möglicherweise möchten sie auch SoC-Komponenten ersetzen oder anpassen.

In niedrigeren Android-Versionen verhinderten solche Anpassungen die Verwendung eines einzelnen Anbieter-Images für Geräte mit demselben SoC (oder mit unterschiedlichen SoCs, aber in derselben Familie). In Android 10 und höher können Sie eine separate odm Partition für Anpassungen verwenden, wodurch Sie ein einzelnes Anbieter-Image für mehrere Hardware-SKUs verwenden können.

Verwendung von Produkt- und ODM-Partitionen

Android 9 hat Unterstützung für die Erstellung product hinzugefügt und ermöglicht so die Verwendung eines einzelnen System-Images für mehrere Software-SKUs, die von verschiedenen product.img Images bereitgestellt werden. Während die product für Software-SKUs vorgesehen ist, ist die odm Partition für Hardware-SKUs vorgesehen.

Mit dedizierten Produkt- und ODM-Partitionen können Sie die system zum Hosten von generischem Code zur gemeinsamen Nutzung durch viele Software-SKUs und die vendor zum Hosten von SoC-spezifischem BSP-Code zur gemeinsamen Nutzung durch mehrere Geräte basierend auf dem jeweiligen SoC verwenden.

Die Verwendung separater Partitionen hat Nachteile, wie z. B. die Schwierigkeit, den Speicherplatz zu verwalten (Sie müssen beispielsweise eine begrenzte Menge an Speicherplatz für zukünftiges Wachstum reservieren). Die Android 10-Unterstützung für dynamische Partitionen beseitigt jedoch das Festplattenproblem und ermöglicht die Neupartitionierung eines Geräts während eines OTA-Updates (Over-the-Air) .

ODM-Komponenten

Die odm Partition enthält die folgenden ODM-spezifischen Komponenten (ähnlich der vendor Partition), die in der folgenden Tabelle aufgeführt sind.

ODM-spezifische Komponente Standort
Ladbare Kernelmodule (LKMs) /odm/lib/modules/*.ko
Native Bibliotheken /odm/lib[64]
HALs /odm/lib[64]/hw
SEPolicy /odm/etc/selinux
VINTF-Objektdaten /odm/etc/vintf
init.rc -Dateien /odm/etc/init
Systemeigenschaften /odm/build.prop
Laufzeitressourcen-Overlays (RROs) /odm/overlay/*.apk
Apps /odm/app/*.apk
Privat-Apps /odm/priv-app/*.apk
Java-Bibliotheken /odm/framework/*.jar
Android Framework-Systemkonfigurationen /odm/etc/sysconfig/* und /odm/etc/permissions/*

Keine benutzerdefinierten Bilder

Verwenden Sie keine benutzerdefinierten Bilder, da diese Folgendes nicht unterstützen:

  • Installation eines Moduls auf einem bestimmten Ziel. Benutzerdefinierte Images unterstützen das Kopieren von Artefakten in ein Image, können jedoch kein Modul in einer bestimmten Partition installieren, indem die Zielpartition als Teil einer Build-Regel angegeben wird.
  • Bald. custom_images können nicht mit dem Soong-Build-System erstellt werden.
  • OTA-Update. Benutzerdefinierte Images werden als werkseitige ROM-Images verwendet, die nicht über OTA übertragen werden können.

ABIs zwischen Partitionen verwalten

Die odm Partition ist eine Erweiterung der vendor Partition. Wenn Sie die Stabilität der Anwendungsbinärschnittstelle (ABI) berücksichtigen, sollten Sie die folgende Architektur berücksichtigen.

ABI zwischen Partitionen aufrechterhalten
Abbildung 1. ABI zwischen Partitionen aufrechterhalten
  • Es gibt keine ABI-Stabilität zwischen odm und vendor Partitionen. Beide Partitionen müssen gleichzeitig aktualisiert werden.
  • Die odm und vendor Partitionen können voneinander abhängen, die vendor Partition muss jedoch ohne eine odm Partition funktionieren.
  • Der ABI zwischen odm und system ist derselbe wie der ABI zwischen vendor und system .

Eine direkte Interaktion zwischen der product und der vendor oder odm Partition ist nicht zulässig . (Dies wird durch SEpolicy erzwungen.)

Implementierung von ODM-Partitionen

Überprüfen Sie vor der Implementierung einer neuen Partition die zugehörigen AOSP-Änderungen .

ODM-Partitionen einrichten

Um odm Partitionen einzurichten, schließen Sie diese Build-Flags ein:

  • BOARD_ODMIMAGE_PARTITION_SIZE für eine feste Partitionsgröße
  • PRODUCT_USE_DYNAMIC_PARTITIONS und BOARD_ODMIMAGE_PARTITION_RESERVED_SIZE für eine dynamische Partitionsgröße
  • BOARD_ODMIMAGE_FILE_SYSTEM_TYPE Dateisystemtyp, der für das ODM-Image verwendet wird
  • PRODUCT_ODM_PROPERTIES für /odm/build.prop zur Verwendung innerhalb eines $(call inherit-product path/to/device.mk) , wie in PRODUCT_ODM_PROPERTIES += product.abc=ok

Installieren eines Moduls auf einer ODM-Partition

Verwenden Sie diese Build-Flags, um ein Modul auf einer odm Partition zu installieren:

  • device_specific: true in Android.bp
  • LOCAL_ODM_MODULE := true in Android.mk

Verifizierten Start aktivieren

Um zu verhindern, dass bösartige Software odm Partitionen manipuliert, aktivieren Sie Android Verified Boot (AVB) für diese Partitionen (genau wie für vendor und system ).

Um AVB zu aktivieren, schließen Sie das Build-Flag BOARD_AVB_ODM_ADD_HASHTREE_FOOTER_ARGS ein. Einzelheiten zur Konfiguration von AVB auf dynamischen Partitionen finden Sie unter AVB-Konfigurationsänderungen .

Behandeln von /odm als eine weitere /vendor-Partition

Um sicherzustellen, dass das System die odm Partition als vendor behandelt, ersetzen Sie alle hartcodierten vendor durch eine Reihe hardwareorientierter Partitionen (derzeit odm und vendor ). Zu den bemerkenswerten Referenzstandorten vendor auf der Plattform gehören Dynamic Linker , Package Manager und shell/libc .