Generische Systembilder

Ein generisches Systemabbild (GSI) ist ein Systemabbild mit angepassten Konfigurationen für Android-Geräte. Es handelt sich um eine reine Android- Implementierung mit unverändertem AOSP-Code (Android Open Source Project), die auf jedem Android-Gerät mit Android 9 oder höher erfolgreich ausgeführt werden kann.

GSIs werden zum Ausführen von VTS- und CTS-on-GSI-Tests verwendet. Das Systemabbild eines Android-Geräts wird durch ein GSI ersetzt und dann mit der Vendor Test Suite (VTS) und der Compatibility Test Suite (CTS) getestet, um sicherzustellen, dass das Gerät die Herstellerschnittstellen korrekt mit der neuesten Android-Version implementiert.

Um mit GSIs zu beginnen, lesen Sie die folgenden Abschnitte mit Einzelheiten zu GSI-Konfigurationen (und zulässigen Abweichungen) und Typen . Wenn Sie bereit sind, ein GSI zu verwenden, laden Sie das GSI für Ihr Geräteziel herunter, erstellen es und flashen das GSI dann auf ein Android-Gerät.

GSI-Konfiguration und -Varianzen

Das aktuelle Android GSI hat die folgende Konfiguration:

Das aktuelle Android GSI umfasst die folgenden wesentlichen Abweichungen:

  • CPU-Architektur. Unterstützung für verschiedene CPU-Anweisungen (ARM, x86 usw.) und CPU-Bitness (32 Bit oder 64 Bit).

GSI-Ziele für Treble-Konformitätstests

Der für Konformitätstests verwendete GSI wird durch die Android-Version bestimmt, mit der das Gerät gestartet wird.

Gerätetyp Ziel aufbauen
Geräte, die mit Android 12 starten gsi_$arch-user (signiert)
Geräte, die mit Android 11 starten gsi_$arch-user (signiert)
Geräte, die mit Android 10 starten gsi_$arch-user (signiert)
Geräte, die mit Android 9 starten gsi_$arch-userdebug

Alle GSIs werden auf der Codebasis von Android 12 erstellt und jede CPU-Architektur verfügt über eine entsprechende GSI-Binärdatei (siehe Liste der Build-Ziele unter Erstellen von GSIs ).

Android 12 GSI-Änderungen

Geräte, die mit Android 12 gestartet oder darauf aktualisiert werden, müssen für Konformitätstests Android 12-GSIs verwenden. Dies beinhaltet die folgenden wesentlichen Änderungen gegenüber früheren GSIs:

  • Zielname. Der GSI-Zielname für Konformitätstests wird in gsi_$arch geändert. Der GSI mit dem Zielnamen aosp_$arch wird für Android-App-Entwickler aufbewahrt. Der Testplan CTS-on-GSI ist auch für das Testen der Anbieterschnittstelle reduziert.
  • Das alte GSI wird eingestellt. GSI 12 entfernt die Problemumgehungen für Android 8.0- oder 8.1-Geräte, die nicht vollständig verdreifacht sind.
  • Userdebug SEPolicy. Der GSI gsi_$arch enthält userdebug_plat_sepolicy.cil . Beim Flashen der OEM-spezifischen vendor_boot-debug.img oder boot-debug.img lädt /system/bin/init userdebug_plat_sepolicy.cil aus der GSI system.img . Weitere Informationen finden Sie unter „VTS-Testen mit Debug Ramdisk“ .

Android 11 GSI-Änderungen

Geräte, die mit Android 11 gestartet oder darauf aktualisiert werden, müssen für Konformitätstests Android 11-GSIs verwenden. Dies beinhaltet die folgenden wesentlichen Änderungen gegenüber früheren GSIs:

  • system_ext-Inhalt. Android 11 definiert eine neue Partition system_ext . GSI legt den Inhalt der Systemerweiterung im Ordner system/system_ext ab.
  • APEXes. GSI enthält sowohl abgeflachte als auch komprimierte APEXes. Welche verwendet werden soll, wird durch die Systemeigenschaft ro.apex.updatable in der Herstellerpartition zur Laufzeit bestimmt. Weitere Informationen finden Sie unter Konfigurieren des Systems zur Unterstützung von APEX-Updates .

Android 10 GSI-Änderungen

Geräte, die mit Android 10 gestartet oder darauf aktualisiert werden, müssen für Konformitätstests Android 10-GSIs verwenden. Dies beinhaltet die folgenden wesentlichen Änderungen gegenüber früheren GSIs:

  • Benutzeraufbau. GSI verfügt über einen Benutzer-Build ab Android 10. In Android 10 kann der Benutzer-Build GSI für CTS-on-GSI/VTS-Konformitätstests verwendet werden. Weitere Informationen finden Sie unter „VTS-Testen mit Debug Ramdisk“ .
  • Ungespartes Format. GSI mit Zielen aosp_$arch werden im ungesparten Format erstellt. Sie können img2simg verwenden, um bei Bedarf ein nicht gespartes GSI in ein Sparse-Format zu konvertieren.
  • System-als-Root. Das alte GSI-Build-Ziel namens aosp_$arch_a wurde eingestellt. Für Geräte, die von Android 8 oder 8.1 auf Android 10 mit Ramdisk und ohne System-as-Root aktualisiert wurden, verwenden Sie das alte GSI aosp_$arch_ab . Das aktualisierte init in der Ramdisk unterstützt OEM system.img mit System-als-Root-Layout.
  • Überprüfen Sie den Start. Mit GSI müssen Sie lediglich das Gerät entsperren. Es ist nicht erforderlich, die Startbestätigung zu deaktivieren.

Android 9 GSI-Änderungen

Geräte, die mit Android 9 gestartet oder darauf aktualisiert werden, müssen für Konformitätstests Android 9-GSIs verwenden. Dies beinhaltet die folgenden wesentlichen Änderungen gegenüber früheren GSIs:

  • Führt GSI und Emulator zusammen. GSIs werden aus den Systemabbildern von Emulatorprodukten erstellt, zum Beispiel aosp_arm64 und aosp_x86 .
  • System-als-Root. In früheren Android-Versionen konnten Geräte, die A/B-Updates nicht unterstützten, das Systemabbild im Verzeichnis /system bereitstellen. In Android 9 wird das Stammverzeichnis des Systemabbilds als Stammverzeichnis des Geräts gemountet.
  • 64-Bit-Binder-Schnittstelle. In Android 8.x verwendeten 32-Bit-GSIs die 32-Bit-Binder-Schnittstelle. Android 9 unterstützt die 32-Bit-Binder-Schnittstelle nicht, daher verwenden sowohl 32-Bit-GSIs als auch 64-Bit-GSIs die 64-Bit-Binder-Schnittstelle.
  • VNDK-Durchsetzung. In Android 8.1 war VNDK optional. Ab Android 9 ist VNDK obligatorisch, daher muss BOARD_VNDK_VERSION festgelegt werden.
  • Kompatible Systemeigenschaft. Android 9 ermöglicht die Zugriffsprüfung für eine kompatible Systemeigenschaft ( PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true ).

Android 9 Keymaster-Änderungen

In früheren Android-Versionen mussten Geräte, die Keymaster 3 oder niedriger implementierten, überprüfen, ob die vom laufenden System gemeldeten Versionsinformationen ( ro.build.version.release und ro.build.version.security_patch ) mit den vom Bootloader gemeldeten Versionsinformationen übereinstimmten. Solche Informationen werden normalerweise aus dem Boot-Image-Header abgerufen.

In Android 9 und höher hat sich diese Anforderung geändert, um Anbietern das Booten eines GSI zu ermöglichen. Insbesondere sollte Keymaster keine Überprüfung durchführen, da die vom GSI gemeldeten Versionsinformationen möglicherweise nicht mit den vom Bootloader des Anbieters gemeldeten Versionsinformationen übereinstimmen. Bei Geräten, die Keymaster 3 oder niedriger implementieren, müssen Anbieter die Keymaster-Implementierung ändern, um die Überprüfung zu überspringen (oder ein Upgrade auf Keymaster 4 durchführen). Einzelheiten zu Keymaster finden Sie unter Hardware-gestützter Keystore .

GSIs herunterladen

Sie können vorgefertigte GSIs von der AOSP-Website für kontinuierliche Integration (CI) unter ci.android.com herunterladen. Wenn der GSI-Typ für Ihre Hardwareplattform nicht zum Download verfügbar ist, finden Sie im folgenden Abschnitt Einzelheiten zum Erstellen von GSIs für bestimmte Ziele.

Aufbau von GSIs

Ab Android 9 verfügt jede Android-Version über einen GSI-Zweig namens DESSERT -gsi auf AOSP ( android12-gsi ist beispielsweise der GSI-Zweig auf Android 12). GSI-Zweige umfassen den Inhalt von Android mit allen angewendeten Sicherheitspatches und GSI-Patches .

Um ein GSI zu erstellen, richten Sie den Android-Quellbaum ein, indem Sie ihn von einem GSI-Zweig herunterladen und ein GSI-Build-Ziel auswählen . Verwenden Sie die folgenden Build-Zieltabellen, um die richtige GSI-Version für Ihr Gerät zu ermitteln. Nach Abschluss des Builds ist das GSI das Systemabbild (d. h. system.img ) und erscheint im Ausgabeordner out/target/product/ generic_arm64 .

Um beispielsweise das GSI-Build-Ziel gsi_arm64-userdebug auf dem GSI-Zweig android12-gsi zu erstellen, führen Sie die folgenden Befehle aus.

$ repo init -u https://android.googlesource.com/platform/manifest -b android12-gsi
$ repo sync -cq
$ source build/envsetup.sh
$ lunch gsi_arm64-userdebug
$ make -j4

Android GSI-Build-Ziele

Die folgenden GSI-Build-Ziele gelten für Geräte, die mit Android 9 oder höher starten.

GSI-Name CPU-Bogen Bitness der Binderschnittstelle System-als-Root Ziel aufbauen
gsi_arm ARM 64 Y gsi_arm-user
gsi_arm-userdebug
gsi_arm64 ARM64 64 Y gsi_arm64-user
gsi_arm64-userdebug
gsi_x86 x86 64 Y gsi_x86-user
gsi_x86-userdebug
gsi_x86_64 x86-64 64 Y gsi_x86_64-user
gsi_x86_64-userdebug

Anforderungen für das Flashen von GSIs

Android-Geräte können unterschiedliche Designs haben, daher gibt es keinen allgemeinen Befehl oder eine Reihe von Anweisungen zum Flashen eines GSI, die für alle Geräte gelten. Erkundigen Sie sich beim Hersteller des Android-Geräts nach expliziten Anweisungen zum Flashen. Verwenden Sie die folgenden Schritte als allgemeine Richtlinie:

  1. Stellen Sie sicher, dass das Gerät über Folgendes verfügt:
    • Verdreifacht
    • Eine Methode zum Entsperren von Geräten (damit sie mit fastboot geflasht werden können)
    • Ein entsperrter Zustand, um es über fastboot flashbar zu machen (Um sicherzustellen, dass Sie über die neueste Version von fastboot verfügen, erstellen Sie es aus dem Android-Quellbaum.)
  2. Löschen Sie die aktuelle Systempartition und flashen Sie dann das GSI auf die Systempartition.
  3. Löschen Sie die Benutzerdaten und löschen Sie die Daten von anderen erforderlichen Partitionen (z. B. Benutzerdaten und Systempartitionen).
  4. Starte das Gerät neu.

Um beispielsweise ein GSI auf ein beliebiges Pixel-Gerät zu flashen:

  1. Booten Sie im fastboot Modus und entsperren Sie den Bootloader .
  2. Die Geräte, die fastbootd unterstützen, müssen auch fastbootd starten über:
    $ fastboot reboot fastboot
  3. Löschen Sie das GSI und flashen Sie es auf die Systempartition:
    $ fastboot erase system
    $ fastboot flash system system.img
    
  4. Löschen Sie die Benutzerdaten und löschen Sie die Daten von anderen erforderlichen Partitionen (z. B. Benutzerdaten und Systempartitionen):
    $ fastboot -w
  5. Neustart:
    $ fastboot reboot
Auf Geräten mit Android 10 oder neuer, die über kleinere Systempartitionen verfügen, wird beim Flashen des GSI möglicherweise die folgende Fehlermeldung angezeigt:
    Resizing 'system_a'    FAILED (remote: 'Not enough space to resize partition')
    fastboot: error: Command failed
Verwenden Sie den folgenden Befehl, um die Produktpartition zu löschen und Speicherplatz für die Systempartition freizugeben. Dadurch wird zusätzlicher Speicherplatz zum Flashen des GSI bereitgestellt:
$ fastboot delete-logical-partition product_a
Das Postfix _a sollte mit der Steckplatz-ID der Systempartition übereinstimmen, in diesem Beispiel beispielsweise system_a .

Beitrag zu GSIs

Android freut sich über Ihre Beiträge zur GSI-Entwicklung. Sie können sich engagieren und dabei helfen, die GSI zu verbessern, indem Sie:

  • Erstellen eines GSI-Patches. DESSERT -gsi ist kein Entwicklungszweig und akzeptiert nur Cherrypicks vom AOSP-Hauptzweig. Um also einen GSI-Patch einzureichen, müssen Sie:
    1. Senden Sie den Patch an den AOSP- main .
    2. Wählen Sie den Patch für DESSERT -gsi aus.
    3. Melden Sie einen Fehler, um den Cherrypick überprüfen zu lassen.
  • GSI-Fehler melden oder andere Vorschläge machen. Lesen Sie die Anweisungen unter Fehler melden und durchsuchen oder melden Sie dann GSI-Fehler .

Tipps

Ändern des Navigationsleistenmodus mit adb

Beim Booten mit GSI wird der Navigationsleistenmodus durch Herstellerüberschreibung konfiguriert. Sie können den Navigationsleistenmodus ändern, indem Sie den folgenden ADB-Befehl zur Laufzeit ausführen.

adb exec-out cmd overlay enable-exclusive com.android.internal.systemui.navbar.mode

Wobei mode threebutton , twobutton “, gestural “ usw. sein kann.