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:
- Verdreifachen. Das GSI bietet volle Unterstützung für die AIDL/HIDL-basierten Architekturänderungen (auch bekannt als Treble ), einschließlich Unterstützung für die AIDL-Schnittstellen und HIDL-Schnittstellen . Sie können GSI auf jedem Android-Gerät verwenden, das AIDL/HIDL-Herstellerschnittstellen verwendet. (Weitere Einzelheiten finden Sie unter Architekturressourcen .)
- Dateisystem. Das GSI verwendet das ext4-Dateisystem.
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 Zielnamenaosp_$arch
wird für Android-App-Entwickler aufbewahrt. Der TestplanCTS-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ältuserdebug_plat_sepolicy.cil
. Beim Flashen der OEM-spezifischenvendor_boot-debug.img
oderboot-debug.img
lädt/system/bin/init
userdebug_plat_sepolicy.cil
aus der GSIsystem.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 Ordnersystem/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önnenimg2simg
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 GSIaosp_$arch_ab
. Das aktualisierteinit
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
undaosp_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.
Erstellen Sie GSIs
Ab Android 9 verfügt jede Android-Version über einen GSI-Zweig namens DESSERT -gsi
auf AOSP (beispielsweise ist android12-gsi
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:
- 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 vonfastboot
verfügen, erstellen Sie es aus dem Android-Quellbaum.)
- Löschen Sie die aktuelle Systempartition und flashen Sie dann das GSI auf die Systempartition.
- Löschen Sie die Benutzerdaten und löschen Sie die Daten von anderen erforderlichen Partitionen (z. B. Benutzerdaten und Systempartitionen).
- Starte das Gerät neu.
Um beispielsweise ein GSI auf ein beliebiges Pixel-Gerät zu flashen:
- Booten Sie im
fastboot
Modus und entsperren Sie den Bootloader . - Die Geräte, die
fastbootd
unterstützen, müssen auchfastbootd
starten über:$ fastboot reboot fastboot
- Löschen Sie das GSI und flashen Sie es auf die Systempartition:
$ fastboot erase system $ fastboot flash system system.img
- Löschen Sie die Benutzerdaten und löschen Sie die Daten von anderen erforderlichen Partitionen (z. B. Benutzerdaten und Systempartitionen):
$ fastboot -w
- Neustart:
$ fastboot reboot
Resizing 'system_a' FAILED (remote: 'Not enough space to resize partition') fastboot: error: Command failedVerwenden Sie den folgenden Befehl, um die Produktpartition zu löschen und Speicherplatz für die Systempartition freizugeben. Dies bietet zusätzlichen Platz zum Flashen des GSI:
$ fastboot delete-logical-partition product_aDas Postfix
_a
sollte mit der Steckplatz-ID der Systempartition übereinstimmen, wie in diesem Beispiel system_a
.Tragen Sie zu GSIs bei
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:- Senden Sie den Patch an den AOSP-
main
. - Wählen Sie den Patch für
DESSERT -gsi
aus. - Melden Sie einen Fehler, um den Cherrypick überprüfen zu lassen.
- Senden Sie den Patch an den AOSP-
- 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 Sie den 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.