Produktpartitionen

Android 9 und höher unterstützt die Entwicklung product-Partitionen mithilfe des Android-Build-Systems. Bisher Unter Android 8.x wurde die Trennung von SoC-spezifischen Komponenten erzwungen. von der Partition system in den vendor ohne Platz für OEM-spezifische Komponenten aus dem Android-Build-System Android 9 und höher bietet zusätzliche Berechtigungen und weiße Listen, die für private Apps in verschiedenen Partitionen gelten.

Produktpartitionen

Viele OEMs passen das AOSP-System-Image an, um ihre eigenen Funktionen zu implementieren. sowie die Anforderungen der Mobilfunkanbieter. Solche Anpassungen machen es jedoch ein einziges System-Image nicht für mehrere Software-SKUs verwendet werden kann. Jedes muss sich für die Anpassungen unterscheiden, z. B. in verschiedenen Regionen oder von unterschiedlichen Mobilfunkanbietern. Mit einem separate product-Partition für Anpassungen ein einziges System-Image für mehrere Software-SKUs verwenden. Der Parameter system-Partitionshosts generischen Code, der gemeinsam genutzt werden kann Software-SKUs). Die Partition vendor wird weiterhin gehostet. SoC-spezifischer BSP-Code, der von mehreren basierend auf dem jeweiligen SoC.

Die Verwendung separater Partitionen hat einige Nachteile, z. B. Speicherplatzverwaltung (ein begrenzter Speicherplatz muss für die Zukunft reserviert bleiben) Wachstum) und die Aufrechterhaltung eine Stable Application Binärschnittstelle (ABI) zwischen Partitionen. Vorher wenn Sie sich für product-Partitionen entscheiden, sollten Sie sich die Zeit nehmen, einzigartige AOSP-Implementierung und mögliche Minderungstaktiken (z. B. die Neupartitionierung eines Geräts over-the-air (OTA-Update), das nicht von Google, sondern von einigen OEMs durchgeführt wird. Dynamische Partitionierung ist eine gute Lösung hierfür.

Produktpartitionen und Berechtigungen

Unter Android 9 und höher wurde eine Änderung der Berechtigungen wie Sie Berechtigungen für private Apps Ihre „product“-Partitionen. Die Datei permissions.xml muss sich in derselben Partition wie die privaten Anwendungen befinden. Das Platzieren eines Datei permissions.xml in der Partition system Für private Apps werden diese Berechtigungen nicht auf private Apps in der product erweitert obwohl die erste eine Erweiterung der zweiten ist. Weitere Informationen zu Berechtigungen und Prozessen für die weiße Liste finden Sie unter Zulassungsliste privilegierter Berechtigungen.

Legacy /oem im Vergleich zu /product

Für die Partition product gibt es zwei Arten von Attributen auf dem Produkt Erzwingung der Benutzeroberfläche. Außerdem ist die Partition product als bei der Legacy-Partition oem:

Partition Attribute
oem
  • Nicht aktualisierbar. in der Regel einmal in der Fabrik geflasht.
  • Erstellt für kleine Variationen wie Branding und Farbe. Wenn Sie unterschiedliche oem-Partitionsinhalte bedeutet nicht, dass das Produkt Software ist anders.
  • Die Partition system hängt nicht von die Partition oem. (Hierfür werden die oem wenn dort eine bestimmte Datei gefunden wird.)
  • Verwendet nur die öffentliche API für die Partition system.
product
  • Aktualisierbar
  • Mit dem System-Image verbunden (gemeinsame Aktualisierung)
  • Erstellt pro Produkt oder Produktfamilie
  • Die Systempartition kann von der Partition product abhängen.
  • Kann nicht öffentliche APIs verwenden, da sie gleichzeitig aktualisiert werden.
product (erzwungene Schnittstellen)
  • Aktualisierbar
  • Mit dem System-Image entkoppelt.
  • Erstellt pro Produkt oder Produktfamilie
  • Die Partition system hängt nicht von product ab. -Partition an.
  • Ausgeblendete APIs können nicht verwendet werden, sondern es werden nur öffentliche APIs und System-APIs auf der Partition system.

Aus diesen Gründen unterstützt Android 9 die Partition product, die Unterstützung für die alte Partition oem bei Geräten, . Um die Partition product von system zu entkoppeln Partition, Android 11 unterstützt erzwingen product Benutzeroberflächen.

/product Components

Die Partition product enthält die folgenden Komponenten:

  • Produktspezifische Systemeigenschaften (/product/build.prop)
  • Produktspezifische RROs (/product/overlay/*.apk)
  • Produktspezifische Apps (/product/app/*.apk)
  • Produktspezifische private 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-Dateien

Keine benutzerdefinierten Bilder

Sie können custom_images nicht verwenden. Es mangelt an Unterstützung für die Folgendes:

  • Module in einem bestimmten Ziel installieren custom_images unterstützen das Kopieren von Artefakten in ein Bild, aber Können ein Modul nicht durch Angabe des Ziels in einer bestimmten Partition installieren -Partition als Teil einer Build-Regel.
  • Unterstützung von Soongs. custom_images darf nicht sein mit dem Soong-Build-System erstellt.
  • Unterstützung von OTA-Updates. custom_images werden als Factory-ROM verwendet Images, die keine OTA-Updates empfangen können.

ABIs zwischen Partitionen verwalten

Die Partition product in Android 9 ist eine Erweiterung der Partition system. Es gibt ein schwaches ABI zwischen product- und system-Partitionen, daher müssen beide sein aktualisiert werden und das ABI sollte system-SDK-basiert sein. Wenn die System SDK deckt nicht alle API-Oberflächen zwischen product und system haben OEMs ihre eigenen ABIs zwischen die beiden Partitionen.

Die Partitionen product und system können voneinander abhängig sind. Tests mit der Generic System Image (GSI) ohne die Partition product ordnungsgemäß funktionieren.

Wenn die product-Schnittstellen erzwungen werden, gilt: product Partition mit der Partition system entkoppelt ist. Das product Partition verwendet nur die zulässigen Schnittstellen aus der Partition system.

Die Partition product darf keine Abhängigkeit über instabile Schnittstellen haben auf Partition vendor. Die direkte Interaktion zwischen den product- und vendor-Partitionen sind unzulässig. Dies wird durch SEpolicy erzwungen.

Produktaufteilungen implementieren

Bevor Sie eine neue Produktaufteilung implementieren, prüfen Sie die zugehörig Änderungen der Produktaufteilung in AOSP. Zum Einrichten von product Die folgenden Board- oder Produkt-Build-Flags enthalten:

  • BOARD_USES_PRODUCTIMAGE
  • BOARD_PRODUCTIMAGE_PARTITION_SIZE
  • BOARD_PRODUCTIMAGE_FILE_SYSTEM_TYPE
  • PRODUCT_PRODUCT_PROPERTIES für /product/build.prop. Diese müssen in einem $(call inherit-product path/to/device.mk), wie in PRODUCT_PRODUCT_PROPERTIES += product.abc=ok.

Modul in der Produktaufteilung installieren

Mit den folgenden Build-Flags können Sie ein Modul in der Partition product installieren.

  • product_specific: true in Android.bp
  • LOCAL_PRODUCT_MODULE := true in Android.mk

Verifizierten Bootmodus aktivieren

Um zu verhindern, dass die Partition product manipuliert wird, Malware, aktivieren Sie Android Verified Boot (AVB) für diese Partition (genau wie für das vendor und system). Um AVB zu aktivieren, die folgenden Build-Flags enthalten: BOARD_AVB_PRODUCT_ADD_HASHTREE_FOOTER_ARGS