Android 9 und höher bietet Unterstützung für die Erstellung product
mithilfe des Android-Build-Systems. Zuvor erzwang Android 8.x die Trennung SoC-spezifischer Komponenten von der system
zur vendor
, ohne Platz für OEM-spezifische Komponenten bereitzustellen, die auf dem Android-Build-System erstellt wurden. Android 9 und höher bietet zusätzliche Berechtigungen und Whitelisting-Funktionen , die für private Apps auf verschiedenen Partitionen gelten.
Über Produktpartitionen
Viele OEMs passen das AOSP-System-Image an, um ihre eigenen Funktionen sowie die Anforderungen der Netzbetreiber zu implementieren. Solche Anpassungen machen es jedoch unmöglich, ein einzelnes Systemabbild für mehrere Software-SKUs zu verwenden. Jedes Bild muss unterschiedlich sein, um die Anpassungen zu unterstützen, z. B. mit unterschiedlichen Gebietsschemas oder Netzbetreibern. Durch die Verwendung einer separaten product
zur Aufnahme von Anpassungen ist es möglich, ein einziges Systemabbild für mehrere Software-SKUs zu verwenden. (Die system
hostet generischen Code, der von vielen Software-SKUs gemeinsam genutzt werden kann.) Die vendor
hostet weiterhin SoC-spezifischen BSP-Code, der basierend auf dem jeweiligen SoC von mehreren Geräten gemeinsam genutzt werden kann.
Die Verwendung separater Partitionen hat einige Nachteile, wie z. B. die Verwaltung des Festplattenspeichers (ein begrenzter Speicherplatz muss für zukünftiges Wachstum reserviert bleiben) und die Aufrechterhaltung einer stabilen Anwendungsbinärschnittstelle (ABI) zwischen den Partitionen. Bevor Sie sich für die Verwendung product
entscheiden, sollten Sie sich die Zeit nehmen, über Ihre individuelle AOSP-Implementierung und mögliche Gegenmaßnahmen nachzudenken (z. B. die Neupartitionierung eines Geräts während eines Over-the-Air-Updates (OTA) , was nicht von Google, aber von einigen OEMs durchgeführt wird). ). Eine dynamische Partitionierung wäre hierfür eine gute Lösung.
Produktpartitionen und Berechtigungen
In Android 9 und höher wirkt sich eine Änderung im Berechtigungs- und Whitelisting-Prozess darauf aus, wie Sie priv-apps-Berechtigungen für Ihre „Produkt“-Partitionen erteilen. Die Datei permissions.xml
muss sich in derselben Partition wie die priv-apps befinden. Durch das Platzieren einer permissions.xml
-Datei in der system
für „Priv-Apps“ werden diese Berechtigungen nicht auf „Priv-Apps“ in der product
ausgeweitet, auch wenn Ersteres eine Erweiterung von Letzterem ist. Einzelheiten zu den Berechtigungen und Whitelisting-Prozessen finden Sie unter Privileged Permission Allowlisting .
Legacy /oem vs. /product
Wir haben zwei Arten von Attributen der product
, abhängig von der Durchsetzung der Produktschnittstelle . Außerdem unterscheidet sich die product
von der alten oem
Partition:
Partition | Attribute |
---|---|
oem |
|
product |
|
product (erzwungene Schnittstellen) |
|
Aus diesen Gründen unterstützt Android 9 die product
und behält gleichzeitig die Unterstützung für die alte oem
Partition für Geräte bei, die davon abhängig sind. Um die product
von der system
zu entkoppeln, unterstützt Android 11 die Durchsetzung product
.
/Produktkomponenten
Die product
enthält die folgenden Komponenten:
- Produktspezifische Systemeigenschaften (
/product/build.prop
) - Produktspezifische RROs (
/product/overlay/*.apk
) - Produktspezifische Apps (
/product/app/*.apk
) - Produktspezifische Privat-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
Keine benutzerdefinierten_Bilder
Sie können custom_images
nicht verwenden. Ihnen fehlt die Unterstützung für Folgendes:
- Installieren von Modulen in einem bestimmten Ziel .
custom_images
unterstützt das Kopieren von Artefakten in ein Image, kann jedoch kein Modul in einer bestimmten Partition installieren, indem seine Zielpartition als Teil einer Build-Regel angegeben wird. - Baldige Unterstützung .
custom_images
können nicht mit dem Soong-Build-System erstellt werden. - OTA-Update-Unterstützung .
custom_images
werden als werkseitige ROM-Images verwendet, die keine OTA-Updates empfangen können.
ABIs zwischen Partitionen verwalten
Die product
in Android 9 ist eine Erweiterung der system
. Es gibt eine schwache ABI zwischen product
und system
, daher müssen beide gleichzeitig aktualisiert werden, und die ABI sollte auf dem System-SDK basieren. Wenn das System-SDK nicht alle API-Oberflächen zwischen product
und system
abdeckt, müssen OEMs ihre eigenen ABIs zwischen den beiden Partitionen verwalten.
Die product
und system
können voneinander abhängig sein. Allerdings müssen Tests mit dem Generic System Image (GSI) auch ohne die product
einwandfrei funktionieren.
Wenn die product
erzwungen werden, wird die product
von der system
entkoppelt. Die product
verwendet nur die zulässigen Schnittstellen der system
.
Die product
darf keine Abhängigkeit durch instabile Schnittstellen von vendor
haben. Eine direkte Interaktion zwischen den product
und vendor
ist verboten. (Dies wird durch SEpolicy erzwungen.)
Produktpartitionen implementieren
Bevor Sie eine neue Produktpartition implementieren, überprüfen Sie die zugehörigen Produktpartitionsänderungen in AOSP . Fügen Sie dann zum Einrichten von product
die folgenden Board- oder Product-Build-Flags ein:
-
BOARD_USES_PRODUCTIMAGE
-
BOARD_PRODUCTIMAGE_PARTITION_SIZE
-
BOARD_PRODUCTIMAGE_FILE_SYSTEM_TYPE
-
PRODUCT_PRODUCT_PROPERTIES
für/product/build.prop
. Diese müssen innerhalb eines$(call inherit-product path/to/device.mk)
liegen, wie inPRODUCT_PRODUCT_PROPERTIES += product.abc=ok
.
Installieren eines Moduls in der Produktpartition
Verwenden Sie die folgenden Build-Flags, um ein Modul auf der product
zu installieren.
-
product_specific: true
inAndroid.bp
-
LOCAL_PRODUCT_MODULE := true
inAndroid.mk
Aktivieren des verifizierten Startvorgangs
Um zu verhindern, dass die product
durch Schadsoftware manipuliert wird, aktivieren Sie Android Verified Boot (AVB) für diese Partition (genau wie Sie es für die vendor
und system
tun). Um AVB zu aktivieren, schließen Sie die folgenden Build-Flags ein: BOARD_AVB_PRODUCT_ADD_HASHTREE_FOOTER_ARGS
.