Freigegebenes Android-Systemimage

Auf dieser Seite werden verschiedene Mechanismen vorgestellt, mit denen Android-Geräte-OEMs ein eigenes gemeinsames System-Image (Shared System Image, SSI) für verschiedene Produktlinien verwenden können. Außerdem wird ein Verfahren vorgeschlagen, mit dem ein SSI des OEM auf einem generischen Systemimage (GSI) basiert, das auf AOSP basiert.

Hintergrund

Mit Project Treble wurde das monolithische Android in zwei Teile aufgeteilt: den hardwarespezifischen Teil (die Anbieterimplementierung) und den generischen Betriebssystemteil (das Android-Betriebssystem-Framework). Die Software für die einzelnen Komponenten ist in einer separaten Partition installiert: die Anbieterpartition für die hardwarespezifische Software und die Systempartition für die generische Betriebssystemsoftware. Eine versionierte Schnittstelle, die als Anbieterschnittstelle (VINTF) bezeichnet wird, ist definiert und wird über die beiden Partitionen hinweg erzwungen. Mit diesem Partitionierungssystem können Sie die Systempartition ändern, ohne die Anbieterpartition zu ändern, und umgekehrt.

Ziel

Der in AOSP veröffentlichte Framework-Code entspricht der Treble-Architektur und ist abwärtskompatibel mit älteren Anbieterimplementierungen. Ein generisches System-Image, das aus Android 10 AOSP-Quellen erstellt wurde, kann beispielsweise auf jedem Treble-kompatiblen Gerät mit Android 8 oder höher ausgeführt werden. Die Android-Version, die auf Verbrauchergeräten ausgeliefert wird, wird von SoC-Anbietern und OEMs modifiziert. Weitere Informationen finden Sie unter Life of an Android Release. Diese Änderungen und Erweiterungen des Frameworks wurden nicht im Hinblick auf die Abwärtskompatibilität vorgenommen, 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 Komplexität der Aktualisierung einer Android-Betriebssystemversion.

Vor Android 11 gab es keine klare Architektur, die es Partnern ermöglichte, modulare Erweiterungen für das Android-Betriebssystem zu entwickeln. In diesem Dokument werden die Schritte beschrieben, die SoC-Anbieter und OEMs ausführen können, um ein SSI zu erstellen. Das bedeutet, dass ein Image, das aus den Android-Betriebssystem-Framework-Quellen erstellt wird, auf mehreren Geräten wiederverwendet werden kann, um die Abwärtskompatibilität mit Anbieterimplementierungen aufrechtzuerhalten und die Komplexität und Kosten von Android-Betriebssystem-Upgrades erheblich zu reduzieren. Die genauen Schritte zum Erstellen eines SSI finden Sie im Abschnitt Empfohlene Schritte für GSI-basiertes SSI. Sie müssen nicht alle vier Schritte ausführen. Welche Schritte Sie auswählen (z. B. nur Schritt 1), hängt von Ihrer Implementierung ab.

SSI – Übersicht

Bei SSI werden produktspezifische Softwarekomponenten und OEM-Erweiterungen in einer neuen /product-Partition platziert. Die Komponenten in der Partition /product verwenden eine genau definierte, stabile Schnittstelle für die Interaktion mit Komponenten in der Partition /system. OEMs können entweder ein SSI erstellen oder eine kleine Anzahl von SSIs für die Verwendung in mehreren Geräte-SKUs haben. 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.

Hinweis: OEMs und SoC-Anbieter erstellen SSIs, die alle benutzerdefinierten Funktionen und Änderungen enthalten, die ein OEM benötigt. Die auf dieser Seite beschriebenen Mechanismen und Best Practices sollen OEMs dabei helfen, folgende wichtige Ziele zu erreichen:

• Die SSI für mehrere Geräte-SKUs wiederverwenden.
• Das Android-System wird mit den modularen Erweiterungen aktualisiert, um Betriebssystem-Upgrades zu vereinfachen.

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

Partitionen rund um SSI

Abbildung 1 zeigt Partitionen um SSI sowie die versionierten Schnittstellen zwischen den Partitionen und Richtlinien für die Schnittstellen. In diesem Abschnitt werden die einzelnen Partitionen und Schnittstellen im Detail beschrieben.

Abbildung 1: Partitionen und Schnittstellen rund um SSI

Bilder und Partitionen

In diesem Abschnitt wird zwischen den Begriffen Image und Partition unterschieden.

• Ein Image ist ein konzeptionelles Softwareelement, das unabhängig aktualisiert werden kann.
• Eine Partition ist ein physischer Speicherort, der unabhängig aktualisiert werden kann.

Die Abschnitte in Abbildung 1 sind so definiert:

• SSI:Das SSI ist das Image, das für einen OEM üblich ist und auf mehreren Geräten vorhanden sein kann. Es enthält keine hardwarespezifischen oder produktspezifischen Komponenten. Alle Inhalte in einem bestimmten SSI werden per Definition für alle Geräte freigegeben, die dieses SSI verwenden. Das SSI besteht entweder aus einem einzelnen /system-Bild oder aus den Partitionen /system und /system_ext, wie in Abbildung 1 dargestellt.

  • Die Partition /system enthält AOSP-basierte Komponenten, während /system_ext, sofern implementiert, OEM- und SoC-Anbietererweiterungen sowie Komponenten enthält, die eng mit AOSP-Komponenten verknüpft sind. Eine OEM-Java-Framework-Bibliothek, die benutzerdefinierte APIs für die eigenen Apps des OEM bereitstellt, passt beispielsweise besser in die Partition /system_ext als in die Partition /system. Inhalte für die Partitionen /system und /system_ext werden aus OEM-modifizierten Android-Quellen erstellt.

  • Die Partition /system_ext ist optional, es ist jedoch von Vorteil, 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 im Laufe der Zeit von der /system_ext-Partition in die /product-Partition zu verschieben.

• Produkt:Eine Sammlung von produkt- oder gerätespezifischen Komponenten, die OEM-Anpassungen und ‑Erweiterungen des Android-Betriebssystems darstellen. SoC-spezifische Komponenten in die Partition /vendor einfügen. SoC-Anbieter können die /product-Partition auch für geeignete Komponenten wie SoC-unabhängige Komponenten verwenden. Wenn ein SoC-Anbieter beispielsweise eine SoC-unabhängige Komponente für seine OEM-Kunden bereitstellt, die optional mit dem Produkt ausgeliefert werden kann, kann der SoC-Anbieter diese Komponente im Produktbild platzieren. Der Speicherort einer Komponente wird nicht durch ihre Inhaberschaft, sondern durch ihren Zweck bestimmt.

• Anbieter:Eine Sammlung von SoC-spezifischen Komponenten.

• ODM:Eine Sammlung von boardspezifischen Komponenten, die nicht vom SoC bereitgestellt werden. In der Regel gehört das Anbieter-Image dem SoC-Anbieter, während das ODM-Image dem Gerätehersteller gehört. Wenn keine separate /odm-Partition vorhanden ist, werden die Bilder des SoC-Anbieters und des ODM in der /vendor-Partition zusammengeführt.

Schnittstellen zwischen Bildern

Es gibt zwei Hauptschnittstellen für Anbieter- und Produktbilder im Zusammenhang mit SSI:

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

  • HIDL (Passthrough-HAL ist nur für die Module system und system_ext verfügbar)
  • Stabile AIDL
  • Konfigurationen
    • System Properties API
    • API für Konfigurationsdateischema
  • 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 dieselben stabilen Schnittstellen wie VINTF. Allerdings werden nur die VNDK- und Android SDK-APIs für Geräte mit Android 11 (und höher) 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 verwenden.

Die Partition „/system_ext“

Die Partition /system_ext wurde in Android 11 als optionale Partition eingeführt. Hier werden Nicht-AOSP-Komponenten gespeichert, die eng mit den AOSP-definierten Komponenten in der /system-Partition verknüpft sind. Die Partition /system_ext wird als OEM-spezifische Erweiterung der Partition /system betrachtet, ohne dass eine Schnittstelle zwischen den beiden Partitionen definiert ist. 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 zusammen aktualisiert, wenn eine neue Android-Version veröffentlicht wird. Eine /system_ext-Partition, die für das vorherige Android-Release erstellt wurde, muss nicht mit der /system-Partition im nächsten Android-Release kompatibel sein.

Wenn Sie ein Modul in der Partition /system_ext installieren möchten, fügen Sie der Datei Android.bpsystem_ext_specific: true hinzu. Auf Geräten ohne /system_ext-Partition werden solche Module im Unterverzeichnis ./system_ext der /system-Partition installiert.

Verlauf

Hier finden Sie einige Informationen zum Verlauf der Partition /system_ext. Das Designziel war, alle OEM-spezifischen Komponenten, unabhängig davon, ob sie häufig verwendet werden, in der Partition /product zu platzieren. Es war jedoch nicht möglich, alle Komponenten gleichzeitig zu verschieben, insbesondere da einige Komponenten eng mit der /system-Partition verknüpft waren. Wenn Sie eine eng gekoppelte Komponente in die Partition /product verschieben möchten, muss die Produktschnittstelle erweitert werden. Dazu musste die Komponente selbst oft umfassend umgestaltet werden, was viel Zeit und Aufwand kostete. Die Partition /system_ext wurde ursprünglich als temporärer Speicherort für Komponenten eingerichtet, die noch nicht in die Partition /product verschoben werden konnten. Ziel der SSI war es, die /system_ext-Partition zu eliminieren.

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 Aufwands für die Aktualisierung auf die Komponenten in den Partitionen /system und /system_ext verwendet. Wenn das System-Image aus Quellen erstellt wird, die denen in AOSP so ähnlich wie möglich sind, können Sie sich bei der Aktualisierung auf das system_ext-Image konzentrieren.

Komponenten aus den Partitionen „/system“ und „/system_ext“ in die Partition „/product“ entbündeln

Mit Android 9 wurde eine /product-Partition eingeführt, die mit der /system-Partition gekoppelt ist. Die Module in der Partition /product verwenden die Systemressourcen ohne Einschränkung und umgekehrt. Damit SSI in Android 10 möglich ist, werden die Produktkomponenten in die Partitionen /system_ext und /product aufgeteilt. Die /system_ext-Partition muss nicht den Einschränkungen für die Verwendung von Systemkomponenten entsprechen, die für die /product-Partition in Android 9 galten. Ab Android 10 muss die /product-Partition von der /system-Partition entkoppelt werden und stabile Schnittstellen aus den /system- und /system_ext-Partitionen verwenden.

Der primäre Zweck der /system_ext-Partition besteht darin, Systemfunktionen zu erweitern und nicht darin, gebündelte Produktmodule zu installieren, wie im Abschnitt /system_ext partition beschrieben. Entfernen Sie dazu die produktspezifischen Module aus dem Bundle und verschieben Sie sie in die /product-Partition. Durch die Entkopplung der produktspezifischen Module ist /system_ext auf allen Geräten verfügbar. Weitere Informationen finden Sie unter /system_ext-Partition gemeinsam nutzen.

Damit die Partition /product von den Systemkomponenten entkoppelt werden kann, muss sie dieselbe Erzwingungsrichtlinie wie die Partition /vendor haben, die bereits mit Project Treble entkoppelt wurde./product

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

• Native Schnittstellen:Die nativen Module in der /product-Partition müssen von den anderen Partitionen entkoppelt werden. Die einzigen zulässigen Abhängigkeiten von den Produktmodulen sind einige VNDK-Bibliotheken (einschließlich LLNDK) aus der /system-Partition. JNI-Bibliotheken, von denen die Produkt-Apps abhängen, müssen NDK-Bibliotheken sein.
• Java-Schnittstellen:Die Java-Module (Apps) in der Partition /product können keine verborgenen APIs verwenden, da diese 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: Vorgeschlagene Partitionen für GSI-basiertes SSI

Ein generisches Systemimage (GSI) ist das Systemimage, das direkt aus AOSP erstellt wird. Sie wird für die Treble-Compliance-Tests (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 mit der erforderlichen Android-Version haben.

OEMs können auch GSI verwenden, um ihr SSI zu erstellen. Wie unter Images und Partitionen beschrieben, besteht SSI aus dem Systemimage 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 auf das system_ext-Image für das Upgrade konzentrieren.

Dieser Abschnitt enthält eine Anleitung für OEMs, die ihre Anpassungen in die Partitionen /system_ext und /product modularisieren möchten, während sie ein AOSP- oder AOSP-nahes System-Image verwenden. Wenn OEMs das System-Image aus AOSP-Quellen erstellen, können sie das von ihnen erstellte System-Image durch das von AOSP bereitgestellte GSI ersetzen. OEMs müssen den letzten Schritt (GSI unverändert verwenden) jedoch nicht sofort erreichen.

Schritt 1: generic_system.mk für das Systemimage des OEM (OEM‑GSI) übernehmen

Durch die Übernahme von generic_system.mk (das in Android 11 mainline_system.mk hieß und in AOSP in generic_system.mk umbenannt wurde) enthält das Systemimage (OEM-GSI) alle Dateien, die das AOSP-GSI hat. Diese Dateien können von OEMs geändert werden, sodass das OEM-GSI zusätzlich zu den AOSP-GSI-Dateien die proprietären Dateien des OEMs enthalten kann. OEMs dürfen die Datei generic_system.mk jedoch nicht selbst ändern.

Abbildung 3: generic_system.mk für das Systemimage des OEM übernehmen

Schritt 2: Sorgen Sie dafür, dass das OEM-GSI dieselbe Liste von Dateien wie das AOSP-GSI hat.

Das OEM-GSI darf in dieser Phase keine zusätzlichen Dateien enthalten. Die proprietären Dateien des OEM müssen in die Partitionen system_ext oder product verschoben werden.

Abbildung 4: Hinzugefügte Dateien aus dem OEM-GSI verschieben

Schritt 3: Erstellen Sie eine Zulassungsliste, um die geänderten Dateien im OEM-GSI zu begrenzen.

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

Wenn Sie das Tool compare_images regelmäßig mit dem Parameter allowlist ausführen, können Sie die Unterschiede außerhalb der Zulassungsliste im Blick behalten. Dadurch sind keine zusätzlichen Änderungen am OEM-GSI erforderlich.

Abbildung 5: Zulassungsliste definieren, um die Liste der geänderten Dateien im OEM-GSI zu reduzieren

Schritt 4: Die OEM-GSI muss dieselben Binärdateien wie die AOSP-GSI haben.

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 aufgeben oder ihre Änderungen in AOSP einbringen, damit das AOSP-GSI ihre Änderungen enthält.

Abbildung 6 OEM-GSI mit denselben Binärdateien wie AOSP-GSI

SSI für OEMs definieren

Die /system-Partition zur Build-Zeit schützen

Um produktspezifische Änderungen in der /system-Partition zu vermeiden und das OEM-GSI zu definieren, können OEMs ein Makefile-Makro namens require-artifacts-in-path verwenden, um zu verhindern, dass Systemmodule nach dem Aufrufen des Makros deklariert werden. Beispiel für das Erstellen einer Make-Datei und das Aktivieren der Prüfung des Artefaktpfads

OEMs können eine Liste definieren, damit produktspezifische Module vorübergehend in der Partition /system installiert werden können. Die Liste muss jedoch leer sein, damit das OEM-GSI für alle Produkte des OEM gilt. Dieser Prozess dient zum Definieren des OEM-GSI und kann unabhängig von den Schritten für das AOSP-GSI erfolgen.

Produktschnittstellen erzwingen

Damit die /product-Partition nicht gebündelt wird, können OEMs dafür sorgen, dass auf ihren Geräten die Produktschnittstellen erzwungen werden. Dazu müssen 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 festgelegt, wenn die PRODUCT_SHIPPING_API_LEVEL des Geräts größer oder gleich 30 ist. Weitere Informationen finden Sie unter Schnittstellen für Produktpartitionen erzwingen.

/system_ext-Partition gemeinsam nutzen

Die Partition /system_ext kann sich je nach Gerät unterscheiden, da sie gerätespezifische, systemgebundene Module enthalten kann. Da das SSI aus /system- und /system_ext-Partitionen besteht, können OEMs aufgrund der Unterschiede in der /system_ext-Partition kein SSI definieren. OEMs können ihr eigenes SSI haben und es auf mehreren Geräten teilen, indem sie alle Unterschiede entfernen und die /system_ext-Partition gemeinsam nutzen.

In diesem Abschnitt finden Sie Empfehlungen dazu, wie Sie die /system_ext-Partition gemeinsam nutzen können.

Ausgeblendete APIs in der Systempartition verfügbar machen

Viele produktspezifische Apps können nicht in der Produktpartition installiert werden, da sie verborgene APIs verwenden, die in der Produktpartition nicht zulässig sind. Wenn Sie gerätespezifische Apps in die Produktpartition verschieben möchten, müssen Sie die Verwendung verborgener APIs entfernen.

Die bevorzugte Methode zum Entfernen verborgener APIs aus den Apps besteht darin, alternative öffentliche oder System-APIs zu finden, um sie zu ersetzen. Wenn es keine APIs gibt, die die ausgeblendeten 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 Partition /system_ext erstellen. Sie kann verborgene APIs in der Systempartition verwenden und die APIs für die Apps in der Produkt- oder Anbieterpartition bereitstellen. OEMs müssen die produktbezogenen APIs aus Gründen der Abwärtskompatibilität einfrieren.

Das Superset aller APKs einbeziehen und einige Paketinstallationen für jedes Gerät überspringen

Bestimmte Pakete, die mit dem System gebündelt sind, sind nicht auf allen Geräten verfügbar. Das Entkoppeln dieser APK-Module, um sie in die Produkt- oder Anbieterpartition zu verschieben, kann schwierig sein. Als Zwischenlösung können OEMs das SSI so gestalten, dass es alle Module enthält, und dann unerwünschte Module mithilfe einer SKU-Eigenschaft (ro.boot.hardware.sku) herausfiltern. Dazu müssen sie die Framework-Ressourcen config_disableApkUnlessMatchedSku_skus_list und config_disableApksUnlessMatchedSku_apk_list überlagern.

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

RRO definieren, anstatt statisches Ressourcen-Overlay zu verwenden

Ein statisches Ressourcen-Overlay manipuliert die überlagerten Pakete. Dies kann jedoch die Definition eines SSI beeinträchtigen. Achten Sie daher darauf, dass die Eigenschaften für RRO aktiviert und richtig festgelegt sind. Wenn OEMs die Attribute wie unten beschrieben festlegen, können alle automatisch generierten Overlays als RROs verwendet werden.

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

Wenn eine detaillierte Konfiguration erforderlich ist, definieren Sie ein RRO manuell, anstatt sich auf ein automatisch generiertes zu verlassen. Ausführliche Informationen finden Sie unter Runtime Resource Overlays (RROs). Originalgerätehersteller 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 (FAQs)

Kann ich mehrere SSIs definieren?

Das hängt von der Häufigkeit und den Merkmalen der Geräte (oder Gerätegruppe) ab. OEMs können versuchen, die system_ext-Partition gemeinsam zu nutzen, wie unter system_ext-Partition gemeinsam nutzen beschrieben. Wenn sich eine Gerätegruppe in vielen Punkten unterscheidet, 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 Make-File für ein OEM-GSI definieren, das die generic_system.mk-Datei übernimmt, und stattdessen das neue Make-File verwenden. Ein Beispiel finden Sie unter Schnittstellen für Produktpartitionen erzwingen.

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

Nein. GSI hat eine Mindestanzahl von bootfähigen und testbaren Modulen. Wenn Sie der Meinung sind, dass ein Modul nicht unbedingt erforderlich ist, reichen Sie bitte einen Fehlerbericht ein, um die Datei generic_system.mk in AOSP zu aktualisieren.