Gemeinsames Android-System-Image

Auf dieser Seite werden mehrere Mechanismen vorgestellt, die OEMs von Android-Geräten nutzen können, um produktlinienübergreifend über ein eigenes gemeinsames Systemabbild (SSI) zu verfügen. Außerdem wird ein Verfahren vorgeschlagen, um ein OEM-eigenes SSI auf einem von AOSP erstellten generischen System-Image (GSI) zu basieren.

Hintergrund

Mit Project Treble wurde monolithisches Android in zwei Teile geteilt: den hardwarespezifischen Teil (die Herstellerimplementierung) und den generischen Betriebssystemteil (das Android OS Framework). Die Software für jeden wird in einer separaten Partition installiert: der Herstellerpartition für die hardwarespezifische Software und der Systempartition für die generische Betriebssystemsoftware. Eine versionierte Schnittstelle, die sogenannte Vendor-Schnittstelle ( VINTF ), wird in den beiden Partitionen definiert und durchgesetzt. Durch die Verwendung dieses Partitionierungssystems können Sie die Systempartition ändern, ohne die Herstellerpartition zu ändern, und umgekehrt.

Motivation

Der in AOSP veröffentlichte Framework-Code ist mit der Treble-Architektur kompatibel und hat die Abwärtskompatibilität mit Implementierungen älterer Anbieter beibehalten. Beispielsweise kann ein generisches System-Image, das aus Android 10 AOSP-Quellen erstellt wurde, auf jedem Treble-kompatiblen Gerät ausgeführt werden, das unter Android 8 oder höher läuft. Die auf Verbrauchergeräten ausgelieferte Android-Version wird von SoC-Anbietern und OEMs geändert. (Siehe Lebensdauer einer Android-Version .) Diese am Framework vorgenommenen Änderungen und Erweiterungen wurden nicht zur Aufrechterhaltung der Abwärtskompatibilität geschrieben, was zu einer erhöhten Komplexität und höheren Kosten bei einem Betriebssystem-Upgrade führte. Gerätespezifische Änderungen und Modifikationen erhöhen die Kosten und die Komplexität des Upgrades einer Android-Betriebssystemversion.

Vor Android 11 gab es keine klare Architektur, die es Partnern ermöglichte, modulare Erweiterungen des Android OS-Frameworks zu erstellen. In diesem Dokument werden die Schritte beschrieben, die SoC-Anbieter und OEMs zum Erstellen eines SSI unternehmen können. Dies bedeutet ein Image, das aus den Android-OS-Framework-Quellen zur Wiederverwendung auf mehreren Geräten erstellt wird, um die Abwärtskompatibilität mit Anbieterimplementierungen aufrechtzuerhalten und eine erhebliche Reduzierung der Komplexität und Kosten von Android-OS-Upgrades zu ermöglichen. Informationen zu den spezifischen Schritten, die Sie zum Erstellen eines SSI benötigen, finden Sie im Abschnitt „Vorgeschlagene Schritte für GSI-basiertes SSI“ . Beachten Sie, dass Sie nicht alle vier Schritte ausführen müssen. Welche Schritte Sie wählen (z. B. nur Schritt 1), hängt von Ihrer Implementierung ab.

SSI-Übersicht

Mit SSI werden produktspezifische Softwarekomponenten und OEM-Erweiterungen in einer neuen /product Partition abgelegt. Die Komponenten in der /product Partition verwenden eine klar definierte, stabile Schnittstelle, um mit Komponenten in der /system Partition zu interagieren. OEMs können sich entweder dafür entscheiden, ein SSI zu erstellen oder eine kleine Anzahl von SSIs für die Verwendung in mehreren Geräte-SKUs bereitzustellen. Wenn eine neue Version des Android-Betriebssystems veröffentlicht wird, investieren OEMs nur einmal in die Aktualisierung ihrer SSIs auf die neueste Android-Version. Sie können die SSIs wiederverwenden, um mehrere Geräte zu aktualisieren , ohne die /product -Partition zu aktualisieren.

Beachten Sie, dass OEMs und SoC-Anbieter SSIs erstellen, die alle benutzerdefinierten Funktionen und Modifikationen enthalten, die ein OEM benötigt. Die auf dieser Seite bereitgestellten Mechanismen und Best Practices sind für OEMs gedacht, mit denen sie diese wichtigen Ziele erreichen können:

• Verwenden Sie die SSI für mehrere Geräte-SKUs wieder.
• Aktualisieren Sie das Android-System mit den modularen Erweiterungen, um Betriebssystem-Upgrades zu vereinfachen.

Die Kernidee, produktspezifische Komponenten in die Produktpartition zu unterteilen, ähnelt der Treble-Idee, SoC-spezifische Komponenten in die Herstellerpartition zu unterteilen. Eine Produktschnittstelle (ähnlich VINTF ) ermöglicht die Kommunikation zwischen SSI und der Produktpartition. Beachten Sie, dass in Bezug auf SSI der Begriff „Komponenten“ alle Ressourcen, Binärdateien, Texte, Bibliotheken usw. beschreibt, die auf Images installiert werden, die im Wesentlichen zu Partitionen werden.

Partitionen um SSI

Abbildung 1 zeigt Partitionen rund um SSI sowie die versionierten Schnittstellen über die Partitionen und Richtlinien auf den Schnittstellen. In diesem Abschnitt werden die einzelnen Partitionen und Schnittstellen ausführlich erläutert.

Abbildung 1. Partitionen und Schnittstellen rund um SSI

Bilder und Partitionen

In den Informationen in diesem Abschnitt wird zwischen den Begriffen „Image“ und „Partition“ unterschieden.

• Ein Bild ist eine konzeptionelle Software, die unabhängig aktualisiert werden kann.
• Eine Partition ist ein physischer Speicherort, der unabhängig aktualisiert werden kann.

Die Abschnitte in Abbildung 1 sind wie folgt definiert:

• SSI: Das SSI ist das gemeinsame Image eines OEM und kann auf mehreren Geräten vorhanden sein. Es enthält keine hardwarespezifischen oder produktspezifischen Komponenten. Alles in einer bestimmten SSI wird per Definition von allen Geräten gemeinsam genutzt, die diese SSI verwenden. Das SSI besteht entweder aus einem einzelnen /system Image oder einer /system und der /system_ext Partition, wie in Abbildung 1 dargestellt.

  • Die /system Partition enthält AOSP-basierte Komponenten, während /system_ext bei Implementierung OEM- und SoC-Anbietererweiterungen und -Komponenten enthält, die eng mit AOSP-Komponenten gekoppelt sind. Beispielsweise passt eine OEM-Java-Framework-Bibliothek, die benutzerdefinierte APIs für die eigenen Apps des OEM bereitstellt, besser in die /system_ext Partition als in die /system Partition. Der Inhalt der Partitionen /system und /system_ext wird aus OEM-modifizierten Android-Quellen erstellt.

  • Die Partition /system_ext ist optional, es ist jedoch vorteilhaft, sie für alle benutzerdefinierten Funktionen und Erweiterungen zu verwenden, die eng mit AOSP-basierten Komponenten verknüpft sind. Diese Unterscheidung hilft Ihnen, Änderungen zu identifizieren, die Sie vornehmen müssen, um solche Komponenten über einen bestimmten Zeitraum von der Partition /system_ext in die Partition /product zu verschieben.

• Produkt: Eine Sammlung produkt- oder gerätespezifischer Komponenten, die OEM-Anpassungen und Erweiterungen des Android-Betriebssystems darstellen. Platzieren Sie SoC-spezifische Komponenten in der /vendor Partition. SoC-Anbieter können die /product Partition auch für entsprechende Komponenten verwenden, beispielsweise SoC-unabhängige. Wenn beispielsweise ein SoC-Anbieter seinen OEM-Kunden eine SoC-unabhängige Komponente bereitstellt (die optional mit dem Produkt geliefert werden kann), kann der SoC-Anbieter diese Komponente im Produktbild platzieren. Der Standort einer Komponente wird nicht durch ihren Besitz bestimmt, sondern durch ihren Zweck .

• Anbieter : Eine Sammlung SoC-spezifischer Komponenten.

• ODM: Eine Sammlung platinenspezifischer Komponenten, die nicht vom SoC bereitgestellt werden. Typischerweise ist der SoC-Anbieter Eigentümer des Anbieter-Images, während der Gerätehersteller Eigentümer des ODM-Images ist. Wenn keine separate /odm Partition vorhanden ist, werden sowohl die SoC-Anbieter- als auch die ODM-Images in der /vendor Partition zusammengeführt.

Schnittstellen zwischen Bildern

Rund um SSI gibt es zwei Hauptschnittstellen für Anbieter- und Produktbilder:

• Vendor Interface (VINTF) : VINTF ist die Schnittstelle zu den Komponenten, die sich im Vendor und den ODM-Images befinden. Komponenten in den Produkt- und System-Images können nur über diese Schnittstelle mit den Anbieter- und ODM-Images interagieren. Beispielsweise kann ein Anbieter-Image nicht von einem privaten Teil des System-Images abhängen und umgekehrt. Dies ist ursprünglich in Project Treble definiert, das die Images in System- und Herstellerpartitionen aufteilt. Die Schnittstelle wird über folgende Mechanismen beschrieben:

  • HIDL (Passthrough HAL ist nur für system und system_ext Module verfügbar)
  • Stabiles AIDL
  • Konfigurationen
    • Systemeigenschaften-API
    • Konfigurationsdateischema-API
  • VNDK
  • Android SDK-APIs
  • Java SDK-Bibliothek

• Produktschnittstellen : Die Produktschnittstelle ist die Schnittstelle zwischen SSI und dem Produktbild. Durch die Definition einer stabilen Schnittstelle werden die Produktkomponenten von den Systemkomponenten in einem SSI entkoppelt. Die Produktschnittstelle erfordert die gleichen stabilen Schnittstellen wie VINTF. Für Geräte, die mit Android 11 (und höher) starten, werden jedoch nur die VNDK- und Android SDK-APIs erzwungen.

SSI in Android 11 aktivieren

In diesem Abschnitt wird erläutert, wie Sie die neuen Funktionen zur Unterstützung von SSI in Android 11 nutzen.

Die /system_ext-Partition

Die /system_ext Partition wurde in Android 11 als optionale Partition eingeführt. (Hier finden Nicht-AOSP-Komponenten statt, die eine enge Verbindung mit den AOSP-definierten Komponenten in der /system Partition haben.) Es wird davon ausgegangen, dass die /system_ext Partition die OEM-spezifische Erweiterung der /system Partition ist, ohne dass eine Schnittstelle darüber definiert ist die beiden Partitionen. Komponenten in der Partition /system_ext können private API-Aufrufe in die Partition /system ausführen, und Komponenten in der Partition /system können private API-Aufrufe in die Partition /system_ext ausführen.

Da die beiden Partitionen eng miteinander verbunden sind, werden beide Partitionen gemeinsam aktualisiert, wenn eine neue Android-Version veröffentlicht wird. Eine /system_ext Partition, die für die vorherige Android-Version erstellt wurde, muss nicht mit der /system Partition in der nächsten Android-Version kompatibel sein.

Um ein Modul auf der Partition /system_ext zu installieren, fügen Sie system_ext_specific: true zur Datei Android.bp hinzu. Bei Geräten, die keine /system_ext Partition haben, installieren Sie solche Module im Unterverzeichnis ./system_ext in der /system Partition.

Geschichte

Hier ist etwas Geschichte über die /system_ext -Partition. Das Designziel bestand darin, alle OEM-spezifischen Komponenten, unabhängig davon, ob sie gemeinsam sind, in der /product Partition zu platzieren. Allerdings war es nicht möglich, sie alle auf einmal zu verschieben, insbesondere wenn einige Komponenten eng mit der /system Partition verbunden waren. Um eine eng gekoppelte Komponente in die /product Partition zu verschieben, muss die Produktschnittstelle erweitert werden. Dies erforderte oft ein umfangreiches Refactoring der Komponente selbst, was viel Zeit und Aufwand kostete. Die Partition /system_ext diente zunächst als Ort zum vorübergehenden Hosten der Komponenten, die nicht zum Verschieben in die Partition /product bereit sind. Das Ziel des SSI bestand darin, die /system_ext -Partition schließlich zu entfernen.

Die Partition /system_ext ist jedoch nützlich, um die Partition /system so nah wie möglich an AOSP zu halten. Bei SSI wird der größte Teil des Upgrade-Aufwands für die Komponenten in den Partitionen /system und /system_ext aufgewendet. Wenn das System-Image aus Quellen erstellt wird, die denen in AOSP möglichst ähnlich sind, können Sie den Upgrade-Aufwand auf das system_ext Image konzentrieren.

Entbündelung von Komponenten aus den Partitionen /system und /system_ext in die Partition /product

Mit Android 9 wurde eine /product Partition eingeführt, die mit der /system -Partition gekoppelt ist. Die Module in der /product Partition nutzen die Systemressourcen uneingeschränkt und umgekehrt. Um SSI in Android 10 zu ermöglichen, werden die Produktkomponenten in die Partitionen /system_ext und /product aufgeteilt. Die /system_ext Partition muss sich nicht an die Einschränkungen für die Verwendung von Systemkomponenten halten, die für die /product Partition in Android 9 galten. Ab Android 10 muss die /product Partition von der /system Partition entbündelt werden und stabile Schnittstellen von verwenden die Partitionen /system und /system_ext .

Der Hauptzweck der /system_ext Partition besteht darin, Systemfunktionen zu erweitern, und nicht darin, gebündelte Produktmodule zu installieren, wie im Abschnitt /system_ext partition beschrieben. Entbündeln Sie dazu die produktspezifischen Module und verschieben Sie sie in die /product Partition. Durch die Entbündelung der produktspezifischen Module wird /system_ext für alle Geräte gemeinsam. (Weitere Einzelheiten finden Sie unter „Die /system_ext-Partition gemeinsam machen “.)

Um die /product Partition von den Systemkomponenten zu entbündeln, muss die /product Partition über dieselbe Durchsetzungsrichtlinie verfügen wie die /vendor Partition, die bereits mit Project Treble entbündelt wurde.

Ab Android 11 werden native und Java-Schnittstellen für die /product Partition wie unten beschrieben erzwungen. Weitere Informationen finden Sie unter Erzwingen von Produktpartitionsschnittstellen .

• Native Schnittstellen : Die nativen Module in der /product Partition müssen von den anderen Partitionen entbündelt werden. Die einzigen zulässigen Abhängigkeiten von den Produktmodulen sind einige VNDK-Bibliotheken (einschließlich LLNDK) von der /system -Partition. JNI-Bibliotheken, von denen die Produkt-Apps abhängen, müssen NDK-Bibliotheken sein.
• Java-Schnittstellen : Die Java-(App-)Module in der /product Partition können keine versteckten APIs verwenden, da sie instabil sind. Diese Module dürfen nur öffentliche APIs und System-APIs aus der Partition /system sowie Java SDK-Bibliotheken in der Partition /system oder /system_ext verwenden. Sie können Java SDK-Bibliotheken für benutzerdefinierte APIs definieren.

Vorgeschlagene Schritte für GSI-basiertes SSI

Abbildung 2. Empfohlene Partitionen für GSI-basiertes SSI

Ein generisches System-Image (GSI) ist das System-Image, das direkt aus AOSP erstellt wird. Es wird für Treble-Konformitätstests (z. B. CTS-on-GSI) und als Referenzplattform verwendet, mit der App-Entwickler die Kompatibilität ihrer Apps testen können, wenn sie kein echtes Gerät haben, auf dem die erforderliche Android-Version ausgeführt wird.

OEMs können GSI auch zur Herstellung ihrer SSI verwenden. Wie unter „Images und Partitionen“ erläutert, besteht SSI aus dem System-Image für die AOSP-definierten Komponenten und dem system_ext Image für die OEM-definierten Komponenten. Wenn GSI als system Image verwendet wird, kann sich der OEM für das Upgrade auf das system_ext Image konzentrieren.

Dieser Abschnitt bietet eine Anleitung für OEMs, die ihre Anpassungen in den /system_ext und /product Partitionen modularisieren möchten, während sie ein AOSP- oder Near-AOSP-System-Image verwenden. Wenn OEMs das Systemabbild aus AOSP-Quellen erstellen, können sie das von ihnen erstellte Systemabbild durch das von AOSP bereitgestellte GSI ersetzen. Allerdings müssen OEMs den letzten Schritt (unter Verwendung von GSI in seiner jetzigen Form) nicht auf einmal erreichen.

Schritt 1. Generic_system.mk für das OEM-System-Image (OEM GSI) erben

Durch die Vererbung von generic_system.mk (das in Android 11 mainline_system.mk hieß und in AOSP in generic_system.mk umbenannt wurde) enthält das Systemabbild (OEM GSI) alle Dateien, über die das AOSP GSI verfügt. Diese Dateien können von OEMs geändert werden, sodass die OEM-GSI zusätzlich zu den AOSP-GSI-Dateien auch die proprietären OEM-Dateien enthalten kann. Allerdings ist es OEMs nicht gestattet, die Datei generic_system.mk selbst zu ändern.

Abbildung 3. Vererbung von generic_system.mk für das System-Image des OEM

Schritt 2: Stellen Sie sicher, dass die OEM-GSI dieselbe Dateiliste wie die AOSP-GSI hat

Die OEM-GSI kann derzeit keine zusätzlichen Dateien haben. Die proprietären Dateien des OEM müssen in die system_ext oder product verschoben werden.

Abbildung 4. Verschieben hinzugefügter Dateien aus dem OEM-GSI

Schritt 3: Definieren einer Zulassungsliste, um die geänderten Dateien im OEM-GSI einzuschränken

Um die geänderten Dateien zu überprüfen, können OEMs das Tool compare_images verwenden und die AOSP-GSI mit der OEM-GSI vergleichen. Rufen Sie den AOSP-GSI vom AOSP-Lunch-Ziel generic_system_* ab.

Indem Sie das Tool compare_images regelmäßig mit dem Parameter allowlist ausführen, können Sie die Unterschiede außerhalb der zulässigen Liste überwachen. Dies verhindert, dass zusätzliche Änderungen am OEM-GSI erforderlich sind.

Abbildung 5. Definieren Sie eine Zulassungsliste, um die Liste der geänderten Dateien im OEM-GSI zu reduzieren

Schritt 4: Stellen Sie sicher, dass die OEM-GSI dieselben Binärdateien wie die AOSP-GSI hat

Durch das Bereinigen der Zulassungsliste können OEMs das AOSP GSI als System-Image für ihre eigenen Produkte verwenden. Um die Zulassungsliste zu bereinigen, können OEMs entweder ihre Änderungen im OEM-GSI verwerfen oder ihre Änderungen an AOSP hochladen, damit das AOSP-GSI ihre Änderungen enthält.

Abbildung 6. Das OEM-GSI muss dieselben Binärdateien haben wie das AOSP-GSI

SSI für OEMs definieren

Schützen Sie die /system-Partition zur Erstellungszeit

Um produktspezifische Änderungen in der /system Partition zu vermeiden und die OEM-GSI zu definieren, können OEMs ein Makefile-Makro namens require-artifacts-in-path verwenden, um jegliche Deklaration von Systemmodulen nach dem Aufruf des Makros zu verhindern. Sehen Sie sich das Beispiel „Makefile erstellen und Artefaktpfadprüfung aktivieren“ an.

OEMs können eine Liste definieren, um die vorübergehende Installation produktspezifischer Module in der /system Partition zu ermöglichen. Die Liste muss jedoch leer sein, damit die OEM-GSI allen OEM-Produkten gemeinsam ist. Dieser Prozess dient der Definition des OEM-GSI und kann unabhängig von den Schritten für den AOSP-GSI sein.

Produktschnittstellen durchsetzen

Um sicherzustellen, dass die /product Partition entbündelt ist, können OEMs sicherstellen, dass ihre Geräte die Produktschnittstellen erzwingen, indem sie PRODUCT_PRODUCT_VNDK_VERSION:= current für native Module und PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE:= true für Java-Module festlegen. Diese Variablen werden automatisch gesetzt, wenn der PRODUCT_SHIPPING_API_LEVEL des Geräts größer oder gleich 30 ist. Ausführliche Informationen finden Sie unter Erzwingen von Produktpartitionsschnittstellen .

Die /system_ext -Partition gemeinsam machen

Die Partition /system_ext kann je nach Gerät unterschiedlich sein, da sie gerätespezifische, systemgebündelte Module enthalten kann. Da die SSI aus den Partitionen /system und /system_ext besteht, hindern die Unterschiede in der Partition /system_ext OEMs daran, eine SSI zu definieren. OEMs können ihre eigene SSI haben und diese SSI auf mehreren Geräten gemeinsam nutzen, indem sie alle Unterschiede beseitigen und die /system_ext Partition gemeinsam machen.

In diesem Abschnitt werden Empfehlungen zur gemeinsamen Gestaltung der /system_ext Partition gegeben.

Machen Sie versteckte APIs in der Systempartition verfügbar

Viele produktspezifische Anwendungen können nicht in der Produktpartition installiert werden, da sie versteckte APIs verwenden, die in der Produktpartition verboten sind. Um gerätespezifische Anwendungen auf die Produktpartition zu verschieben, entfernen Sie die Verwendung versteckter APIs.

Der bevorzugte Weg, versteckte APIs aus den Anwendungen zu entfernen, besteht darin, die alternativen öffentlichen oder System-APIs zu finden, um sie zu ersetzen. Wenn es keine APIs gibt, die die versteckten APIs ersetzen, können OEMs zu AOSP beitragen, um die neuen System-APIs für ihre Geräte zu definieren.

Alternativ können OEMs benutzerdefinierte APIs definieren, indem sie ihre eigene Java SDK-Bibliothek in der /system_ext -Partition erstellen. Es kann versteckte APIs in der Systempartition verwenden und die APIs den Anwendungen in der Produkt- oder Anbieterpartition bereitstellen. OEMs müssen die produktbezogenen APIs aus Gründen der Abwärtskompatibilität einfrieren .

Schließen Sie die Obermenge aller APKs ein und überspringen Sie die Installation einiger Pakete für jedes Gerät

Bestimmte Pakete, die mit dem System gebündelt sind, sind auf allen Geräten nicht gleich. Es kann schwierig sein, diese APK-Module zu entbündeln, um sie auf die Produkt- oder Herstellerpartition zu verschieben. Als Übergangslösung können OEMs dafür sorgen, dass das SSI alle Module einschließt und dann mithilfe einer SKU-Eigenschaft ( ro.boot.hardware.sku ) unerwünschte herausfiltert. Um den Filter zu verwenden, überlagern OEMs die Framework-Ressourcen config_disableApkUnlessMatchedSku_skus_list und config_disableApksUnlessMatchedSku_apk_list .

Für genauere Einstellungen deklarieren Sie einen Broadcast-Receiver, der unnötige Pakete deaktiviert. Der Broadcast-Empfänger ruft setApplicationEnabledSetting auf, um das Paket zu deaktivieren, wenn er die Nachricht ACTION_BOOT_COMPLETED empfängt.

Definieren Sie RRO, anstatt ein statisches Ressourcen-Overlay zu verwenden

Ein statisches Ressourcen-Overlay manipuliert die überlagerten Pakete. Dies kann jedoch die Definition eines SSI behindern. Stellen Sie daher sicher, dass die Eigenschaften für RRO aktiviert und richtig eingestellt sind. Durch Festlegen der Eigenschaften wie folgt können OEMs alle automatisch generierten Overlays als RROs haben.

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

Wenn eine detaillierte Konfiguration erforderlich ist, definieren Sie eine RRO manuell, anstatt sich auf eine automatisch generierte zu verlassen. Ausführliche Informationen finden Sie unter Runtime Resource Overlays (RROs) . OEMs können auch bedingte RROs definieren, die von den Systemeigenschaften abhängen, indem sie die Attribute android:requiredSystemPropertyName und android:requiredSystemPropertyValue verwenden.

Häufig gestellte Fragen (FAQ)

Kann ich mehrere SSIs definieren?

Dies hängt von der Gemeinsamkeit und den Eigenschaften der Geräte (oder Gerätegruppen) ab. OEMs können versuchen, die system_ext Partition gemeinsam zu machen, wie unter „System_ext-Partition gemeinsam machen“ beschrieben. Wenn eine Gerätegruppe viele Unterschiede aufweist, ist es besser, mehrere SSIs zu definieren.

Kann ich generic_system.mk ( mainline_system.mk ) für ein OEM-GSI ändern?

Nein. OEMs können jedoch ein neues Makefile für ein OEM-GSI definieren, das die Datei generic_system.mk erbt, und stattdessen das neue Makefile verwenden. Ein Beispiel finden Sie unter Erzwingen von Produktpartitionsschnittstellen .

Kann ich Module aus generic_system.mk entfernen, die mit meiner Implementierung in Konflikt stehen?

Nein. GSI verfügt über einen Mindestsatz an bootfähigen und testbaren Modulen. Wenn Sie der Meinung sind, dass ein Modul nicht unbedingt erforderlich ist, melden Sie bitte einen Fehler, um die Datei generic_system.mk in AOSP zu aktualisieren.