Diese Seite wurde von der Cloud Translation API übersetzt.

ODM-Partitionen

Android 10 unterstützt die Entwicklung von odm-Partitionen mithilfe des Android-Build-Systems.

ODM-Partitionen

Original-Design-Hersteller (ODMs), System-on-Chip-Anbieter (SoC) Board-Support-Pakete (BSPs) mit ihren spezifischen Geräten (ihren Boards) verknüpfen. Dieses ermöglicht es ihnen, Kernelmodule für boardspezifische Komponenten zu implementieren, boardspezifische Daemons oder ihre eigenen Merkmale auf Hardwareabstraktionsschichten (HALs). Vielleicht möchten sie auch SoC-Komponenten ersetzen oder anpassen.

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

Produkt- und ODM-Partitionen verwenden

Android 9 unterstützt jetzt product Partitionen und ermöglichen die Verwendung eines einzelnen System-Images für mehrere Softwareprogramme. Artikelnummern, die von verschiedenen product.img-Bildern bereitgestellt werden. Während die Die Partition product ist für Software-SKUs vorgesehen, Die Partition odm ist für Hardware-SKUs vorgesehen.

Mit dedizierten Produkt- und ODM-Partitionen können Sie die system verwenden Partition für das Hosten von generischem Code für die gemeinsame Nutzung zwischen vielen Software-SKUs und der Partition vendor zum Hosten des SoC-spezifischen BSP-Codes für die gemeinsame Nutzung SoCs mehrere Geräte nutzen.

Die Verwendung separater Partitionen hat Nachteile, beispielsweise die Schwierigkeit, die Verwaltung Festplattenspeicher (z. B. müssen Sie eine begrenzte Menge an Speicherplatz für zukünftige Wachstum). Die Unterstützung von Android 10 dynamische Partitionen behebt das Laufwerksproblem und partitioniert ein Gerät während einer Over-the-Air-Update (OTA) möglich.

ODM-Komponenten

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

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

Keine benutzerdefinierten Images

Nicht verwenden benutzerdefiniert Bilder enthalten, da sie Folgendes nicht unterstützen:

Installation eines Moduls in einem bestimmten Ziel. Benutzerdefinierte Images unterstützen das Kopieren von Artefakten in ein Bild, können aber nicht ein Modul in einer bestimmten Partition installieren, indem Sie die Zielpartition angeben als Teil einer Build-Regel.
Song. custom_images kann nicht erstellt werden mit das Soong-Build-System.
OTA-Update: Benutzerdefinierte Images werden als Factory-ROM-Images, die nicht OTA-codiert werden können.

ABIs zwischen Partitionen verwalten

Die Partition odm ist eine Erweiterung von vendor. -Partition an. Wenn Sie die Stabilität der Binärschnittstelle (Application Binary Interface, ABI) prüfen, Architektur berücksichtigen.

Abbildung 1: ABI zwischen Partitionen beibehalten.

Es gibt keine ABI-Stabilität zwischen odm und vendor Partitionen. Beide Partitionen müssen gleichzeitig aktualisiert werden .
Die Partitionen odm und vendor können von sich gegenseitig, aber die Partition vendor muss funktionieren. ohne odm-Partition.
Der ABI zwischen odm und system ist gleich das ABI zwischen vendor und system.

Direkte Interaktion zwischen der Partition product und dem Partition vendor oder odm ist nicht zulässig. Dies wird durch SEpolicy erzwungen.

ODM-Partitionen implementieren

Bevor Sie eine neue Partition implementieren, prüfen Sie die zugehöriger AOSP Änderungen.

ODM-Partitionen einrichten

Fügen Sie zum Einrichten von odm-Partitionen die folgenden 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 dynamische Partition Größe [size]
BOARD_ODMIMAGE_FILE_SYSTEM_TYPE-Dateisystemtyp für den ODM-Bild
PRODUCT_ODM_PROPERTIES für /odm/build.prop für in $(call inherit-product path/to/device.mk) verwenden, wie in PRODUCT_ODM_PROPERTIES += product.abc=ok

Modul auf einer ODM-Partition installieren

Mit den folgenden Build-Flags können Sie ein Modul in einer odm-Partition installieren:

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

Verifizierten Bootmodus aktivieren

So verhindern Sie, dass schädliche Software odm-Partitionen manipuliert: Aktivieren Sie „Verifizierter Bootmodus von Android“. (AVB) für diese Partitionen (genau wie für vendor und system Partitionen).

Fügen Sie das Build-Flag ein, um AVB zu aktivieren. BOARD_AVB_ODM_ADD_HASHTREE_FOOTER_ARGS Weitere Informationen zur Konfiguration AVB für dynamische Partitionen, siehe AVB-Konfiguration Änderungen.

/odm als andere /vendor-Partition behandeln

Damit das System die Partition odm als Partition vendor, ersetzen Sie alle hartcodierten vendor-Dateien Referenzen mit einer Reihe von hardwareorientierten Partitionen (derzeit odm und vendor). Interessantes vendor Referenzstellen auf der Plattform sind u. a. dynamisch Verknüpfung Paket Manager und shell/libc.