Generische Systembilder

Ein generisches Systemabbild (GSI) ist ein Systemabbild mit angepassten Konfigurationen für Android-Geräte. Es ist eine reine Android - Implementierung mit unmodifizierten Android Open Source Project (AOSP) Code ausgegangen , dass jedes Android - Gerät Android 9 oder höher läuft erfolgreich ausgeführt werden kann.

GSIs werden zum Ausführen von VTS- und CTS-on-GSI-Tests verwendet. Das System Bild eines Android - Gerät wird dann mit dem getestet mit einem GSI ersetzt Vendor Test Suite (VTS) und die Compatibility Test Suite (CTS) , dass die Gerätegeräte Anbieter Schnittstellen korrekt mit der neuesten Version von Android zu gewährleisten.

Die folgenden Abschnitte für Details zu Um mit GSIs, überprüfen GSI Konfigurationen (und erlaubten Abweichungen) und Typen . Wenn Sie bereit sind , eine GSI, verwenden Download und die GSI bauen für Ihr Gerät Ziel, dann blinken die GSI zu einem Android - Gerät.

GSI-Konfiguration und Abweichungen

Die aktuelle Android GSI hat folgende Konfiguration:

Die aktuelle Android GSI enthält 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-Compliance-Tests

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

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

Alle GSIs werden aus der Code - Basis 12 Android gebaut, und jede CPU - Architektur hat eine entsprechende GSI binary (die Liste der Build - Ziele in sehen Gebäude GSIs ).

Android 12 GSI-Änderungen

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

  • Zielname. Der GSI Zielname für Konformitätstests wird geändert gsi_$arch . Die GSI mit Zielnamen aosp_$arch ist für Android - App - Entwickler gehalten. Der Testplan CTS-on-GSI wird auch zum Testen Anbieter Schnittstelle reduziert.
  • Legacy-GSI wird auslaufen. GSI 12 entfernt die Problemumgehungen für Android 8.0- oder 8.1-Geräte, die nicht vollständig verdreifacht sind.
  • Userdebug SEPolicy. Die GSI gsi_$arch enthält userdebug_plat_sepolicy.cil . Wenn die OEM-spezifische blinkt vendor_boot-debug.img oder boot-debug.img , /system/bin/init lädt userdebug_plat_sepolicy.cil von der GSI system.img . Referenz VTS Testen mit Debug Ramdisk für das Detail.

Android 11 GSI-Änderungen

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

  • system_ext-Inhalt. Android 11 definiert eine neue Partition system_ext . GSI stellt die Systemerweiterung Inhalt unter dem Ordner system/system_ext .
  • APEX. GSI enthält sowohl abgeflachte als auch komprimierte APEXes. Welcher Gebrauch wird durch die Systemeigenschaft bestimmt ro.apex.updatable in der Kreditoren Partition zur Laufzeit. Referenz Konfigurieren System zur Unterstützung des APEX - Updates für das Detail.

Android 10 GSI-Änderungen

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

  • Benutzer-Build. GSI verfügt über einen Benutzer-Build von Android 10. In Android 10 kann der Benutzer-Build GSI in CTS-on-GSI/VTS-Konformitätstests verwendet werden. Referenz VTS Testing mit Debug Ramdisk für weitere Einzelheiten.
  • Ungespartes Format. GSI mit Zielen aosp_$arch mit unsparsed Format gebaut. Sie können mit img2simg eine unsparsed GSI zu spärlichem Format bei Bedarf zu konvertieren.
  • System-als-root. Das Erbe GSI Build - Ziel genannt aosp_$arch_a hatte auslaufen. Für die Geräte von Android 8 oder 8.1 bis Android 10 mit RAM - Disk und Nicht-System-as-Root - Upgrade, verwenden Sie das Vermächtnis GSI aosp_$arch_ab . Die aktualisierte init in RAM - Disk unterstützt OEM system.img mit System-as-root - Layout.
  • Boot überprüfen. Mit GSI müssen Sie das Gerät nur entsperren. Es ist nicht erforderlich, das Verifizieren des Bootvorgangs zu deaktivieren.

Android 9 GSI-Änderungen

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

  • Führt GSI und Emulator zusammen. GSIs werden aus den Systemabbilder von Emulator Produkte, zum Beispiel, gebaut aosp_arm64 und aosp_x86 .
  • System-als-root. In früheren Versionen von Android, Geräte , die nicht A unterstützt hat / B - Updates konnte das Systemabbild unter dem Mount /system - Verzeichnis. In Android 9 wird das Stammverzeichnis des Systemabbilds als Stammverzeichnis des Geräts bereitgestellt.
  • 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. Ausgehend von Android 9 ist VNDK verpflichtend, so BOARD_VNDK_VERSION eingestellt werden müssen.
  • Kompatible Systemeigenschaft. Android 9 ermöglicht die Zugangskontrolle für ein kompatibles Systemeigenschaft ( PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true ).

Android 9 Keymaster-Änderungen

In früheren Versionen von Android, Implementierung Geräten Keymaster 3 oder niedriger waren erforderlich , um sicherzustellen , dass die Version info ( ro.build.version.release und ro.build.version.security_patch ) durch das laufende System gemeldet abgestimmt die Versionsinformationen von Bootloader berichtet. Diese Informationen wurden normalerweise aus dem Boot-Image-Header abgerufen.

In Android 9 und höher hat sich diese Anforderung geändert, um es Anbietern zu ermöglichen, eine GSI zu booten. 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 auf Keymaster 4 aktualisieren). Einzelheiten zu Keymaster siehe Hardware-unterstützte Schlüsselspeicher .

Herunterladen von GSIs

Sie können vorkompilierte GSIs vom AOSP Continuous Integration (CI) Website herunterladen ci.android.com . 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.

GSIs erstellen

Beginnend mit Android 9, jede Android - Version hat ein GSI Zweig namens DESSERT -gsi auf AOSP (zB android12-gsi ist der GSI Zweig auf Android 12). GSI Filialen umfassen den Inhalt von Android mit allen Sicherheits - Patches und GSI - Patches angewendet.

Um eine GSI zu bauen, die Android - Source - Tree durch einrichten Download von einem GSI - Zweig und die Wahl eines GSI Build - Ziel . Verwenden Sie die folgenden Build-Zieltabellen, um die richtige GSI-Version für Ihr Gerät zu ermitteln. Nach dem Build abgeschlossen ist , wird die GSI das Systemabbild (das heißt, system.img ) und erscheinen im Ausgabeordner out/target/product/ generic_arm64 .

Um zum Beispiel des GSI Erstellungsziel aufzubauen gsi_arm64-userdebug auf dem GSI Zweig android12-gsi , die folgenden Befehle.

$ 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 gestartet werden.

GSI-Name CPU-Bogen Bitness der Binderschnittstelle System-als-root Ziel erstellen
gsi_arm ARM 64 Ja gsi_arm-user
gsi_arm-userdebug
gsi_arm64 ARM64 64 Ja gsi_arm64-user
gsi_arm64-userdebug
gsi_x86 x86 64 Ja gsi_x86-user
gsi_x86-userdebug
gsi_x86_64 x86-64 64 Ja gsi_x86_64-user
gsi_x86_64-userdebug

Voraussetzungen für das Flashen von GSIs

Android-Geräte können unterschiedliche Designs haben, daher gibt es keinen generischen Befehl oder eine Reihe von Anweisungen zum Flashen einer GSI, die auf alle Geräte angewendet werden kann. Erkundigen Sie sich beim Hersteller des Android-Geräts nach expliziten Flash-Anweisungen. Verwenden Sie die folgenden Schritte als allgemeine Richtlinie:

  1. Stellen Sie sicher, dass das Gerät über Folgendes verfügt:
    • verdreifacht
    • Verfahren zum Entriegeln Geräte (so können sie geflasht werden unter Verwendung von fastboot )
    • Ein unverriegelten Zustand, um es flashbar über fastboot (Um sicherzustellen , dass Sie die neueste Version von haben fastboot , baut es aus der Android - Source - Tree.)
  2. Löschen Sie die aktuelle Systempartition und flashen Sie dann die 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 eine GSI auf ein beliebiges Pixel-Gerät zu flashen:

  1. Boot to fastboot - Modus und Entsperren des Bootloader .
  2. Die Geräte unterstützen fastbootd müssen auch Boot in fastbootd von:
    $ fastboot reboot fastboot
  3. Lösch- und blinken die GSI auf die Systempartition:
    $ fastboot erase system
    $ fastboot flash system system.img
    
  4. Wischen Sie die Benutzerdaten und löschen Sie die Daten aus anderen notwendigen Partitionen (zB Benutzerdaten und Systempartitionen):
    $ fastboot -w
  5. Reboot:
    $ fastboot reboot
Auf Android - 10 oder neuere Geräte , die kleinere Systempartitionen haben könnte, wird die folgende Fehlermeldung angezeigt , wenn der GSI blinkt:
    Resizing 'system_a'    FAILED (remote: 'Not enough space to resize partition')
    fastboot: error: Command failed
Verwenden Sie den folgenden Befehl , um die Produktaufteilung und Speicherplatz freizugeben für die Systempartition zu löschen. Dies bietet zusätzlichen Raum , um die GSI zu blinken:
$ fastboot delete-logical-partition product_a
Der Postfix _a sollte die Slot - ID der Systempartition, wie paßt system_a in diesem Beispiel.

Beitrag zu GSIs

Android freut sich über Ihre Beiträge zur GSI-Entwicklung. Sie können sich einbringen und zur Verbesserung der GSI beitragen, indem Sie:

  • Erstellen eines GSI-Patches. DESSERT -gsi kein Entwicklungszweig ist und akzeptiert nur cherrypicks vom AOSP Master Zweig, so ein GSI - Patch einreichen, müssen Sie:
    1. Die Patch zum AOSP master - Zweig.
    2. Cherrypick den Patch DESSERT -gsi .
    3. Melden Sie einen Fehler, um die Rosinenauswahl überprüfen zu lassen.
  • Berichterstattung GSI Bugs oder andere Vorschläge. Lesen Sie die Anweisungen in Fehler melden , dann durchsuchen oder Datei GSI Bugs .

Tipps

Ändern des Navigationsleistenmodus mit adb

Beim Booten mit GSI wird der Navigationsleistenmodus durch das Überschreiben des Anbieters 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

Wo mode sein kann threebutton , twobutton , gestural , und so weiter.