Diese Seite wurde von der Cloud Translation API übersetzt.

Generische System-Images

Ein generisches Systemabbild (GSI) ist ein Systemabbild mit angepassten Konfigurationen für Android-Geräte. Es gilt als reine Android -Implementierung mit unverändertem Code des Android Open Source Project (AOSP), der 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 eine GSI ersetzt und dann mit der Vendor Test Suite (VTS) und der Compatibility Test Suite (CTS) getestet, um sicherzustellen, dass das Gerät Anbieterschnittstellen korrekt mit der neuesten Version von Android implementiert.

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

GSI-Konfiguration und Abweichungen

Die aktuelle Android GSI hat folgende Konfiguration:

Verdreifachen. Die GSI umfasst 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 die GSI auf jedem Android-Gerät verwenden, das AIDL/HIDL-Anbieterschnittstellen verwendet. (Weitere Einzelheiten finden Sie unter Architekturressourcen .)
Dateisystem. Die GSI verwendet das ext4-Dateisystem.

Die aktuelle Android GSI enthält die folgenden Hauptabweichungen:

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

GSI-Ziele für Treble-Compliance-Tests

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

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

Alle GSIs werden aus der Codebasis von Android 12 erstellt, und jede CPU-Architektur verfügt über eine entsprechende GSI-Binärdatei (siehe die Liste der Build-Ziele in Erstellen von 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 Konformitätstests verwenden. Dazu gehören die folgenden wesentlichen Änderungen gegenüber früheren GSIs:

Zielname. Der GSI-Zielname für Konformitätstests wird in gsi_$arch geändert. Die GSI mit aosp_$arch wird für Entwickler von Android-Apps aufbewahrt. Der Testplan CTS-on-GSI ist auch für das Testen der Herstellerschnittstelle reduziert.
Legacy-GSI wird auslaufen. GSI 12 entfernt die Problemumgehungen für Android 8.0- oder 8.1-Geräte, die nicht vollständig mit Treblized ausgestattet sind.
Userdebug SEPolicy. Die GSI gsi_$arch enthält userdebug_plat_sepolicy.cil . Beim Flashen der OEM-spezifischen vendor_boot-debug.img oder boot-debug.img /system/bin/init userdebug_plat_sepolicy.cil aus der GSI system.img . Siehe VTS Testing with Debug Ramdisk für Details.

Android 11 GSI-Änderungen

Geräte, die mit Android 11 gestartet oder auf Android 11 aktualisiert werden, müssen Android 11-GSIs für Konformitätstests verwenden. Dazu gehören 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 .
Spitzen. GSI enthält sowohl abgeflachte als auch komprimierte APEXs. Welche verwendet werden soll, wird zur Laufzeit durch die Systemeigenschaft ro.apex.updatable in der Herstellerpartition bestimmt. Siehe Konfigurieren des Systems zur Unterstützung von APEX-Aktualisierungen für Details.

Android 10 GSI-Änderungen

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

Benutzeraufbau. GSI verfügt über einen Benutzer-Build von Android 10. In Android 10 kann der Benutzer-Build von GSI in CTS-on-GSI/VTS-Compliance-Tests verwendet werden. Einzelheiten finden Sie unter VTS-Tests mit Debug-Ramdisk .
Unsparsed-Format. GSI mit Zielen aosp_$arch werden im unsparsed-Format erstellt. Sie können img2simg verwenden, um eine nicht gesparte GSI bei Bedarf in ein Sparse-Format zu konvertieren.
System als Root. Das alte GSI-Build-Target mit dem Namen aosp_$arch_a wurde eingestellt. Verwenden Sie für Geräte, die von Android 8 oder 8.1 auf Android 10 mit Ramdisk und Nicht-System-als-Root aktualisiert wurden, die Legacy-GSI aosp_$arch_ab . Die aktualisierte init -Datei in der Ramdisk unterstützt OEM system.img mit System-als-Root-Layout.
Start überprüfen. Mit GSI müssen Sie das Gerät nur entsperren. Es ist nicht erforderlich, die Überprüfung des Bootvorgangs zu deaktivieren.

Android 9 GSI-Änderungen

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

Verbindet GSI und Emulator. GSIs werden aus den Systemabbildern von Emulatorprodukten erstellt, z. B. aosp_arm64 und aosp_x86 .
System als Root. In früheren Versionen von Android konnten Geräte, die A/B-Updates nicht unterstützten, das Systemabbild im Verzeichnis /system . In Android 9 wird das Stammverzeichnis des Systemabbilds als Stammverzeichnis des Geräts bereitgestellt.
64-Bit-Binderschnittstelle. 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 aktiviert die Zugriffsprüfung für eine kompatible Systemeigenschaft ( PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true ).

Android 9 Keymaster-Änderungen

In früheren Versionen von Android 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 wurden normalerweise aus dem Boot-Image-Header erhalten.

In Android 9 und höher hat sich diese Anforderung geändert, damit Anbieter eine GSI booten können. Insbesondere sollte Keymaster keine Überprüfung durchführen, da die von der 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 finden Sie unter Hardwaregestützter Keystore .

Herunterladen von GSIs

Sie können vorgefertigte GSIs von der AOSP Continuous Integration (CI)-Website 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

Beginnend mit Android 9 hat jede Android-Version einen GSI-Zweig namens DESSERT -gsi auf AOSP (z. B. android12-gsi ist der GSI-Zweig auf Android 12). GSI-Zweige umfassen den Inhalt von Android mit allen angewendeten Sicherheitspatches und GSI-Patches .

Um eine 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 Build-Zieltabellen unten, um die richtige GSI-Version für Ihr Gerät zu ermitteln. Nach Abschluss des Builds ist die 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 im 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 gestartet werden.

GSI-Name	CPU-Bogen	Bitness der Binder-Schnittstelle	System als Root	Ziel bauen
`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`

Voraussetzungen 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 einer GSI, die auf alle Geräte angewendet werden können. 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 die neueste Version von fastboot haben, erstellen Sie es aus dem Android-Quellbaum.)
Löschen Sie die aktuelle Systempartition und flashen Sie dann die 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 in den fastboot Modus und entsperren Sie den Bootloader .
Die Geräte, die fastbootd unterstützen, müssen auch in fastbootd booten durch:
```
$ fastboot reboot fastboot
```

Löschen und flashen Sie die GSI 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
```

Auf Android 10 oder neueren Geräten mit kleineren Systempartitionen wird beim Flashen der 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. Dies bietet zusätzlichen Platz zum Flashen der GSI:

$ fastboot delete-logical-partition product_a

Das Postfix _a sollte mit der Steckplatz-ID der Systempartition übereinstimmen, wie in diesem Beispiel system_a .

Beitrag zu GSIs

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

Erstellen eines GSI-Patches. DESSERT -gsi ist kein Entwicklungszweig und akzeptiert nur Cherrypicks aus dem AOSP-Master-Zweig. Um also einen GSI-Patch einzureichen, müssen Sie:
1. Senden Sie den Patch an den AOSP- master Zweig.
2. Picken Sie den Patch für DESSERT -gsi .
3. Melden Sie einen Fehler, um den Cherrypick überprüfen zu lassen.
GSI-Fehler melden oder andere Vorschläge machen. Lesen Sie die Anweisungen in Melden von Fehlern und durchsuchen oder melden Sie dann GSI-Fehler .

Tipps

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

Dabei kann der mode threebutton , twobutton , gestural und so weiter sein.