Android 10 unterstützt das Erstellen von odm-Partitionen mit dem Android-Build-System.
ODM-Partitionen
ODMs (Original Design Manufacturers) passen die Board-Support-Pakete (BSPs) von SoC-Anbietern (System-on-Chip) an ihre spezifischen Geräte (Boards) an. So können sie Kernelmodule für plattformspezifische Komponenten, plattformspezifische Daemons oder eigene Funktionen in Hardwareabstraktionsschichten (HALs) implementieren. Möglicherweise möchten sie auch SoC-Komponenten ersetzen oder anpassen.
Bei älteren Android-Releases verhinderten solche Anpassungen die Verwendung eines einzelnen Anbieter-Images für Geräte mit demselben SoC (oder mit unterschiedlichen SoCs, aber derselben Familie). Unter Android 10 und höher können Sie für Anpassungen eine separate odm-Partition verwenden. So können Sie ein einzelnes Anbieter-Image für mehrere Hardware-SKUs verwenden.
Produkt- und ODM-Partitionen verwenden
Unter Android 9 wurde die Unterstützung für das Erstellen von product-Partitionen hinzugefügt. So kann ein einzelnes System-Image für mehrere Software-SKUs verwendet werden, die von verschiedenen product.img-Images bereitgestellt werden. Die Partition product ist für Software-SKUs vorgesehen, die Partition odm für Hardware-SKUs.
Mit speziellen Produkt- und ODM-Partitionen können Sie die system-Partition zum Hosten generischen Codes verwenden, der für viele Software-SKUs freigegeben werden soll, und die vendor-Partition zum Hosten von SoC-spezifischem BSP-Code, der für mehrere Geräte auf Basis des jeweiligen SoC freigegeben werden soll.
Die Verwendung separater Partitionen hat Nachteile, z. B. die Schwierigkeit bei der Verwaltung des Speicherplatzes. Sie müssen beispielsweise eine begrenzte Menge an Speicherplatz für zukünftiges Wachstum reservieren. Durch die Unterstützung von dynamischen Partitionen in Android 10 wird das Laufwerkproblem jedoch behoben und die Neupartitionierung eines Geräts während eines Over-the-air-Updates (OTA) möglich.
ODM-Komponenten
Die Partition odm enthält die folgenden ODM-spezifischen Komponenten (ähnlich wie die Partition vendor), die in der folgenden Tabelle aufgeführt sind.
| ODM-spezifische Komponente | Standort |
|---|---|
| Ladebare 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 |
| Laufzeit-Ressourcen-Overlays (RROs) | /odm/overlay/*.apk |
| Apps | /odm/app/*.apk |
| Priv-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 sie Folgendes nicht unterstützen:
- Installation eines Moduls auf einem bestimmten Ziel. Bei benutzerdefinierten Images können Artefakte in ein Image kopiert werden, aber es ist nicht möglich, ein Modul in einer bestimmten Partition zu installieren, indem die Zielpartition als Teil einer Build-Regel angegeben wird.
- Soong
custom_imageskann nicht mit dem Soong-Buildsystem erstellt werden. - Over-the-air-Update Benutzerdefinierte Images werden als ROM-Images des Herstellers verwendet, die nicht per Over-the-air (OTA) installiert werden können.
ABIs zwischen Partitionen beibehalten
Die odm-Partition ist eine Erweiterung der vendor-Partition. Beachten Sie bei der Stabilität der Anwendungs-Binärschnittstelle (Application Binary Interface, ABI) die folgende Architektur.
Abbildung 1: ABI zwischen Partitionen beibehalten
- Es gibt keine ABI-Stabilität zwischen
odm- undvendor-Partitionen. Beide Partitionen müssen gleichzeitig aktualisiert werden. - Die
odm- undvendor-Partitionen können voneinander abhängig sein, aber dievendor-Partition muss auch ohneodm-Partition funktionieren. - Der ABI zwischen
odmundsystemist mit dem ABI zwischenvendorundsystemidentisch.
Eine direkte Interaktion zwischen der product-Partition und der vendor- oder odm-Partition ist nicht zulässig. (Dies wird von SEpolicy erzwungen.)
ODM-Partitionen implementieren
Lesen Sie sich die zugehörigen AOSP-Änderungen durch, bevor Sie eine neue Partition implementieren.
ODM-Partitionen einrichten
Wenn Sie odm-Partitionen einrichten möchten, fügen Sie die folgenden Build-Flags hinzu:
BOARD_ODMIMAGE_PARTITION_SIZEfür eine feste PartitionsgrößePRODUCT_USE_DYNAMIC_PARTITIONSundBOARD_ODMIMAGE_PARTITION_RESERVED_SIZEfür die Größe einer dynamischen PartitionBOARD_ODMIMAGE_FILE_SYSTEM_TYPEDateisystemtyp, der für das ODM-Image verwendet wirdPRODUCT_ODM_PROPERTIESfür/odm/build.propzur Verwendung in einer$(call inherit-product path/to/device.mk), wie inPRODUCT_ODM_PROPERTIES += product.abc=ok
Modul in einer ODM-Partition installieren
Verwenden Sie diese Build-Flags, um ein Modul auf einer odm-Partition zu installieren:
device_specific: trueinAndroid.bpLOCAL_ODM_MODULE := trueinAndroid.mk
Bootmodus mit Verifikation aktivieren
Um zu verhindern, dass schädliche Software odm-Partitionen manipuliert, aktivieren Sie für diese Partitionen Android Verified Boot (AVB), genau wie für vendor- und system-Partitionen.
Wenn Sie AVB aktivieren möchten, fügen Sie das Build-Flag BOARD_AVB_ODM_ADD_HASHTREE_FOOTER_ARGS hinzu. Weitere Informationen zum Konfigurieren von AVB auf dynamischen Partitionen finden Sie unter Änderungen an der AVB-Konfiguration.
/odm als weitere /vendor-Partition behandeln
Damit das System die odm-Partition als vendor-Partition behandelt, ersetzen Sie alle hartcodierten vendor-Verweise durch eine Reihe von hardwareorientierten Partitionen (derzeit odm und vendor). Zu den wichtigen Speicherorten für vendor-Verweise auf der Plattform gehören der dynamische Linker, der Paketmanager und shell/libc.