Produktpartitionen

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
  • Nicht aktualisierbar; Normalerweise wurde im Werk einmal geflasht.
  • Basierend auf kleinen Variationen wie Branding und Farbe. Unterschiedliche oem Partitionsinhalte bedeuten nicht, dass die Produktsoftware unterschiedlich ist.
  • Die system ist nicht von der oem Partition abhängig. (Die oem Partition wird nur verwendet, wenn dort eine bestimmte Datei gefunden wird.)
  • Verwendet nur die öffentliche API auf der system .
product
  • Aktualisierbar
  • Gekoppelt mit dem Systemabbild (sie werden gemeinsam aktualisiert)
  • Pro Produkt oder Produktfamilie erstellt.
  • Die Systempartition kann von der product abhängen.
  • Kann nicht öffentliche APIs verwenden, da diese gleichzeitig aktualisiert werden.
product (erzwungene Schnittstellen)
  • Aktualisierbar
  • Entkoppelt vom System-Image.
  • Pro Produkt oder Produktfamilie erstellt.
  • Die system ist nicht von der product abhängig.
  • Es können keine versteckten APIs verwendet werden, sondern nur öffentliche und System-APIs auf der system .

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 in PRODUCT_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 in Android.bp
  • LOCAL_PRODUCT_MODULE := true in Android.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 .