Freigegebenes Android-System-Image

Auf dieser Seite werden verschiedene Mechanismen vorgestellt, mit denen OEMs von Android-Geräten ein eigenes freigegebenes System-Image (SSI) für alle Produktlinien haben können. Außerdem wird ein Verfahren vorgeschlagen, mit dem ein SSI eines OEM auf einem von AOSP erstellten generischen System-Image (GSI) basieren kann.

Hintergrund

Bei Project Treble wurde das monolithische Android-Betriebssystem in zwei Teile unterteilt: in den hardwarespezifischen Teil (die Anbieterimplementierung) und den generischen Teil des Betriebssystems (das Framework des Android-Betriebssystems). Die Software für beide wird 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, wird für die beiden Partitionen definiert und erzwungen. Mit diesem Partitionssystem 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 Implementierungen von Anbietern. Ein generisches System-Image, das aus AOSP-Quellen von Android 10 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 installiert ist, wird von SoC-Anbietern und OEMs geändert. (Siehe Lebensdauer eines Android-Release.) Diese Änderungen und Erweiterungen, die am Framework vorgenommen wurden, wurden nicht zur Gewährleistung der Abwärtskompatibilität geschrieben, was zu erhöhter Komplexität und höheren Kosten bei einem Betriebssystemupgrade führte. Gerätespezifische Änderungen und Modifikationen erhöhen die Kosten und Komplexität des Upgrades auf eine neue 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 eine SSI zu erstellen. Das bedeutet, dass ein Image aus den Android-Betriebssystem-Framework-Quellen erstellt wird, um es auf mehreren Geräten wiederzuverwenden, die Abwärtskompatibilität mit Anbieterimplementierungen aufrechtzuerhalten und die Komplexität und Kosten von Android-Betriebssystem-Upgrades erheblich zu senken. Die konkreten Schritte zum Erstellen einer SSI finden Sie im Abschnitt Empfohlene Schritte für GSI-basiertes SSI. Beachten Sie, dass Sie nicht alle vier Schritte ausführen müssen. Welche Schritte Sie auswählen (z. B. nur Schritt 1), hängt von Ihrer Implementierung ab.

SSI – Übersicht

Bei der SSI werden produktspezifische Softwarekomponenten und OEM-Erweiterungen in einer neuen /product-Partition platziert. Die Komponenten in der /product-Partition verwenden eine klar definierte, stabile Schnittstelle, um mit Komponenten in der /system-Partition zu interagieren. OEMs können entweder eine SSI erstellen oder eine kleine Anzahl von SSIs zur Verwendung in mehreren Geräte-SKUs einsetzen. 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 Partition /product zu aktualisieren.

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, die folgenden wichtigen Ziele zu erreichen:

• Die SSI kann für mehrere Geräte-SKUs wiederverwendet werden.
• Aktualisieren Sie das Android-System mit den modularen Erweiterungen, um Betriebssystem-Upgrades zu vereinfachen.

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

Partitionen um SSI

Abbildung 1 zeigt Partitionen um SSI herum und 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 für SSI

Images und Partitionen

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

• Ein Image ist eine 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 so definiert:

• SSI:Das SSI ist das Image, das für einen OEM üblich ist und auf mehreren Geräten vorhanden sein kann. Es hat keine hardware- oder produktspezifischen Komponenten. Alles in einer bestimmten SSI wird per Definition von allen Geräten geteilt, die diesen SSI verwenden. Das SSI besteht entweder aus einem einzelnen /system-Image oder aus einer /system- und einer /system_ext-Partition, wie in Abbildung 1 dargestellt.

  • Die Partition /system enthält AOSP-basierte Komponenten. Wenn /system_ext implementiert ist, enthält sie Erweiterungen des OEM- und SoC-Anbieters sowie Komponenten, die eng mit AOSP-Komponenten gekoppelt sind. Eine OEM-Java-Framework-Bibliothek, die benutzerdefinierte APIs für die eigenen Apps des OEMs bereitstellt, passt beispielsweise besser in die Partition /system_ext als in die Partition /system. Der Inhalt der Partitionen /system und /system_ext wird aus vom OEM geänderten Android-Quellen erstellt.

  • Die Partition /system_ext ist optional. Es ist aber vorteilhaft, sie für alle benutzerdefinierten Features und Erweiterungen zu verwenden, die eng mit AOSP-basierten Komponenten gekoppelt sind. Anhand dieser Unterscheidung können Sie die erforderlichen Änderungen ermitteln, um solche Komponenten im Laufe der Zeit von der Partition /system_ext in die Partition /product zu verschieben.

• Produkt:Eine Sammlung von produkt- oder gerätespezifischen Komponenten, die OEM-Anpassungen und ‑Erweiterungen des Android-Betriebssystems darstellen. Fügen Sie SoC-spezifische Komponenten in die Partition /vendor ein. SoC-Anbieter können die /product-Partition auch für geeignete Komponenten wie SoC-unabhängige Komponenten verwenden. Wenn ein SoC-Anbieter seinen OEM-Kunden beispielsweise eine SoC-unabhängige Komponente zur Verfügung stellt, die optional mit dem Produkt geliefert wird, kann der SoC-Anbieter diese Komponente in das Produktbild einfügen. Der Standort einer Komponente wird nicht durch ihre Eigentümerschaft, sondern durch ihren Zweck bestimmt.

• Anbieter: Eine Sammlung von SoC-spezifischen Komponenten.

• ODM:Eine Sammlung boardspezifischer Komponenten, die nicht vom SoC bereitgestellt werden. In der Regel ist der SoC-Anbieter Inhaber des Anbieter-Images, während der Gerätehersteller das ODM-Image besitzt. Wenn es keine separate /odm-Partition gibt, werden sowohl die SoC-Anbieter- als auch die ODM-Images in der /vendor-Partition zusammengeführt.

Übergänge zwischen Bildern

Um SSI herum gibt es zwei Hauptoberflächen für Anbieter- und Produkt-Images:

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

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

• Produktoberflächen: Die Produktoberfläche ist die Schnittstelle zwischen SSI und dem Produktbild. Durch die Definition einer stabilen Schnittstelle werden die Produktkomponenten von den Systemkomponenten in einer SSI getrennt. Die Produktoberfläche erfordert dieselben stabilen Schnittstellen wie VINTF. Für Geräte, die mit Android 11 (und höher) auf den Markt kommen, 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 verwenden.

Die Partition „/system_ext“

Die /system_ext-Partition wurde in Android 11 als optionale Partition eingeführt. (Dies ist der Ort für nicht AOSP-Komponenten, die eng mit den AOSP-definierten Komponenten in der /system-Partition gekoppelt sind.) Die /system_ext-Partition wird als OEM-spezifische Erweiterung der /system-Partition angesehen, ohne dass eine Schnittstelle für die beiden Partitionen definiert ist. Komponenten in der Partition /system_ext können private API-Aufrufe an die Partition /system senden und Komponenten in der Partition /system können private API-Aufrufe an die Partition /system_ext senden.

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 die vorherige Android-Version erstellt wurde, muss nicht mit der /system-Partition in der nächsten Android-Version kompatibel sein.

Fügen Sie der Datei Android.bp system_ext_specific: true hinzu, um ein Modul in der Partition /system_ext zu installieren. Bei Geräten ohne /system_ext-Partition installieren Sie solche Module im Unterverzeichnis ./system_ext der Partition /system.

Verlauf

Hier finden Sie einige Informationen zur /system_ext-Partition. Das Designziel bestand darin, alle OEM-spezifischen Komponenten, unabhängig davon, ob sie häufig vorkommen, in der Partition /product zu platzieren. Es war jedoch nicht möglich, alle gleichzeitig zu verschieben, insbesondere da einige Komponenten eng mit der /system-Partition gekoppelt waren. Wenn Sie eine eng verbundene Komponente in die /product-Partition verschieben möchten, muss die Produktoberfläche erweitert werden. Das erforderte oft eine umfangreiche Refaktorisierung der Komponente selbst, was viel Zeit und Mühe 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 können. Ziel der SSI-Datei war es, die Partition /system_ext letztendlich zu entfernen.

Die Partition /system_ext ist jedoch nützlich, um die Partition /system so nahe wie möglich bei AOSP zu halten. Bei SSI wird der Großteil des Upgradeaufwands für die Komponenten in den Partitionen /system und /system_ext ausgegeben. Wenn das System-Image aus Quellen erstellt wird, die denen in AOSP möglichst ähnlich sind, können Sie sich beim Upgrade auf das system_ext-Image konzentrieren.

Komponenten aus den Partitionen „/system“ und „/system_ext“ in die Partition „/product“ verschieben

In Android 9 wurde die /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 unter Android 10 möglich ist, werden die Produktkomponenten in die Partitionen /system_ext und /product unterteilt. Die /system_ext-Partition muss nicht den Einschränkungen bei der Verwendung von Systemkomponenten entsprechen, die für die /system_ext-Partition in Android 9 galten./product Ab Android 10 muss die /product-Partition von der /system-Partition getrennt werden und stabile Schnittstellen aus den /system- und /system_ext-Partitionen verwenden.

Der primäre Zweck der Partition /system_ext besteht darin, Systemfunktionen zu erweitern, anstatt 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 Partition /product. Wenn die produktspezifischen Module nicht mehr inbegriffen sind, ist /system_ext für alle Geräte verfügbar. Weitere Informationen finden Sie unter Partition „/system_ext“ gemeinsam nutzen.

Wenn Sie die /product-Partition von den Systemkomponenten entkoppeln möchten, muss die /product-Partition dieselbe Erzwingungsrichtlinie wie die /vendor-Partition haben, die bereits mit Project Treble entkoppelt wurde.

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

• Native Oberflächen: Die nativen Module in der /product-Partition müssen von den anderen Partitionen getrennt 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-(App-)Module in der Partition /product können keine ausgeblendeten APIs verwenden, da sie instabil sind. Diese Module dürfen nur öffentliche APIs und System-APIs aus der Partition /system und Java SDK-Bibliotheken in der Partition /system oder /system_ext verwenden. Sie können Java SDK-Bibliotheken für benutzerdefinierte APIs definieren.

Empfohlene Schritte für GSI-basierte SSI

Abbildung 2. Vorgeschlagene Partitionen für GSI-basierte SSI

Ein generisches System-Image (GSI) ist das System-Image, das direkt aus AOSP erstellt wird. Es 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 ihre SSI zu erstellen. 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 enthält eine Anleitung für OEMs, die ihre Anpassungen in den Partitionen /system_ext und /product modularisieren und dabei ein AOSP- oder Near-AOSP-System-Image verwenden möchten. 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 jedoch nicht den letzten Schritt (die Verwendung von GSI in der aktuellen Form) auf einmal erreichen.

Schritt 1: generic_system.mk für das System-Image des OEMs (OEM GSI) erben

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

Abbildung 3 Inheritance of generic_system.mk for OEM's system image

Schritt 2: Die OEM-GSI muss dieselbe Liste von Dateien wie die AOSP-GSI haben.

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

Abbildung 4 Verschieben hinzugefügter Dateien aus der OEM-GSI-Datei

Schritt 3: Zulassungsliste definieren, um die geänderten Dateien in der OEM-GSI-Datei einzuschränken

OEMs können die geänderten Dateien mit dem Tool compare_images prüfen und die AOSP-GSI mit der OEM-GSI vergleichen. Holen Sie sich die AOSP-GSI aus dem AOSP-Startziel generic_system_*.

Wenn Sie das compare_images-Tool regelmäßig mit dem Parameter allowlist ausführen, können Sie die Unterschiede außerhalb der zulässigen Liste überwachen. Dadurch sind keine zusätzlichen Änderungen an der OEM-GSI erforderlich.

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

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

Durch die Bereinigung der Zulassungsliste können OEMs die AOSP-GSI als System-Image für ihre eigenen Produkte verwenden. Um die Zulassungsliste zu bereinigen, können OEMs entweder ihre Änderungen in der OEM-GSI zurückziehen oder ihre Änderungen an AOSP senden, damit die AOSP-GSI ihre Änderungen enthält.

Abbildung 6 Die OEM-GSI muss dieselben Binärdateien wie die AOSP-GSI haben

SSI für OEMs definieren

Partition „/system“ bei der Buildzeit schützen

Um produktspezifische Änderungen an der /system-Partition zu vermeiden und die OEM-GSI zu definieren, können OEMs ein Makefile-Makro namens require-artifacts-in-path verwenden, um die Deklaration von Systemmodulen nach dem Aufruf des Makros zu verhindern. Weitere Informationen finden Sie im Beispiel Makefile erstellen und Prüfung des Pfads zu Artefakten aktivieren.

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 die OEM-GSI für alle Produkte des OEMs gilt. Dieser Prozess dient zum Definieren der OEM-GSI und kann unabhängig von den Schritten für die AOSP-GSI erfolgen.

Produktoberflächen erzwingen

Um sicherzustellen, dass die /product-Partition nicht gebündelt ist, können OEMs dafür sorgen, 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 festgelegt, wenn die PRODUCT_SHIPPING_API_LEVEL des Geräts größer oder gleich 30 ist. Weitere Informationen finden Sie unter Produktpartitionsoberflächen erzwingen.

Gemeinsame /system_ext-Partition einrichten

Die /system_ext-Partition kann sich von Gerät zu Gerät unterscheiden, da sie gerätespezifische, im System enthaltene Module enthalten kann. Da die SSI aus /system- und /system_ext-Partitionen besteht, verhindern die Unterschiede in der /system_ext-Partition, dass OEMs eine SSI definieren können. OEMs können ihre eigene SSI-Datei haben und diese für mehrere Geräte freigeben, indem sie alle Unterschiede entfernen und die Partition /system_ext gemeinsam nutzen.

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

Ausgeblendete APIs in der Systempartition freigeben

Viele produktspezifische Apps können nicht in der Produktpartition installiert werden, da sie versteckte APIs verwenden, die in der Produktpartition verboten sind. Wenn Sie gerätespezifische Apps in die Produktpartition verschieben möchten, entfernen Sie die Verwendung versteckter APIs.

Die beste Methode zum Entfernen versteckter APIs aus Apps besteht darin, alternative öffentliche oder System-APIs zu finden, um sie zu ersetzen. Wenn es keine APIs gibt, mit denen die ausgeblendeten APIs ersetzt werden können, 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 in der Partition /system_ext eine eigene Java SDK-Bibliothek erstellen. Es kann versteckte APIs in der Systempartition verwenden und die APIs den Anwendungen in der Produkt- oder Anbieterpartition zur Verfügung stellen. OEMs müssen die Produkt-APIs für die Abwärtskompatibilität einfrieren.

Alle APKs einschließen und einige Paketinstallationen für jedes Gerät überspringen

Bestimmte Pakete, die im Lieferumfang des Systems enthalten sind, sind nicht auf allen Geräten verfügbar. Die Entbündelung dieser APK-Module, um sie zum Produkt oder zur Anbieterpartition zu verschieben, kann schwierig sein. Als Zwischenlösung können OEMs die SSI so konfigurieren, dass alle Module enthalten sind, und dann unerwünschte Module mithilfe einer SKU-Eigenschaft (ro.boot.hardware.sku) herausfiltern. 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-Empfänger, 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.

RRO definieren, anstatt statische Ressourcen-Overlays zu verwenden

Mit einem statischen Ressourcen-Overlay werden die überlagerten Pakete manipuliert. Dies kann jedoch die Definition einer SSI beeinträchtigen. Achten Sie daher darauf, dass die Properties für die RRO aktiviert und richtig festgelegt sind. Wenn OEMs die Eigenschaften so 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 einen RRO manuell, anstatt sich auf eine automatisch generierte RRO zu verlassen. Weitere Informationen finden Sie unter Laufzeitressourcen-Overlays (RROs). OEMs können auch nutzerabhängige RROs definieren, die von den Systemeigenschaften abhängen. Verwenden Sie dazu die Attribute android:requiredSystemPropertyName und android:requiredSystemPropertyValue.

Häufig gestellte Fragen

Kann ich mehrere SSIs definieren?

Das 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 verwenden, wie unter Die system_ext-Partition gemeinsam verwenden beschrieben. Wenn sich eine Gerätegruppe stark unterscheidet, ist es besser, mehrere SSIs zu definieren.

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

Nein. OEMs können jedoch ein neues Makefile für eine OEM-GSI-Datei definieren, die die Datei generic_system.mk übernimmt und stattdessen das neue Makefile verwenden. Ein Beispiel finden Sie unter Produktpartitionsoberflächen 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 erforderlich ist, melden Sie einen Fehler, um die Datei generic_system.mk in AOSP zu aktualisieren.