Generische System-Images

Ein generisches Systemimage (GSI) ist ein Systemimage 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 ausgeführt werden kann.

GSIs werden zum Ausführen von VTS- und CTS-on-GSI-Tests verwendet. Das Systemimage 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 Anbieter-Schnittstellen korrekt mit der neuesten Version von Android implementiert.

Wenn Sie mit GSIs beginnen möchten, lesen Sie die folgenden Abschnitte, um Details zu GSI-Konfigurationen (und zulässigen Abweichungen) und Typen zu erhalten. Wenn Sie ein GSI verwenden möchten, laden Sie das GSI herunter und erstellen Sie es für Ihr Geräteziel. Flashen Sie das GSI dann auf ein Android-Gerät.

GSI-Konfiguration und ‑Abweichungen

Das aktuelle Android-GSI hat die folgende Konfiguration:

• Höhen 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 das GSI auf jedem Android-Gerät verwenden, das AIDL-/HIDL-Anbieterschnittstellen nutzt. Weitere Informationen finden Sie unter Architekturressourcen.
• Dateisystem: Das GSI verwendet das ext4-Dateisystem.

Das aktuelle Android-GSI weist die folgenden wichtigen Unterschiede auf:

• CPU-Architektur: Unterstützung verschiedener CPU-Befehle (ARM, x86 usw.) und CPU-Bitbreiten (32 Bit oder 64 Bit).

GSI-Ziele für Treble-Konformitätstests

Die für Konformitätstests verwendete GSI wird durch die Android-Version bestimmt, mit der das Gerät auf den Markt kommt.

Alle GSIs werden aus dem Android 12-Quellcode erstellt und für jede CPU-Architektur gibt es eine entsprechende GSI-Binärdatei (siehe die Liste der Build-Ziele unter GSIs erstellen).

Änderungen am GSI für Android 12

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

• Name des Ziels: Der GSI-Zielname für Konformitätstests wurde in gsi_$arch geändert. Das GSI mit dem Zielnamen aosp_$arch wird für Android-App-Entwickler beibehalten. Der Testplan CTS-on-GSI wird auch für das Testen der Anbieter-Schnittstelle reduziert.
• Die alte Version von GSI wird eingestellt. Mit GSI 12 werden die Workarounds für Geräte mit Android 8.0 oder 8.1 entfernt, die nicht vollständig Treble-kompatibel sind.
• Userdebug-SEPolicy: Das GSI gsi_$arch enthält userdebug_plat_sepolicy.cil. Beim Flashen des OEM-spezifischen vendor_boot-debug.img oder boot-debug.img wird /system/bin/init userdebug_plat_sepolicy.cil aus dem GSI system.img geladen. Weitere Informationen finden Sie unter VTS-Tests mit Debug-Ramdisk.

Änderungen bei Android 11-GSIs

Geräte, die mit Android 11 auf den Markt kommen oder auf Android 11 aktualisiert werden, müssen für Konformitätstests GSIs für Android 11 verwenden. Dazu gehören die folgenden wichtigen Änderungen gegenüber früheren GSIs:

• Inhalte von „system_ext“ In Android 11 wird eine neue Partition system_ext definiert. Bei GSI werden die Inhalte der Systemerweiterung in den Ordner system/system_ext eingefügt.
• APEX-Pakete: GSI enthält sowohl komprimierte als auch nicht komprimierte APEX-Dateien. Welche verwendet wird, wird durch die Systemeigenschaft ro.apex.updatable in der Anbieterpartition zur Laufzeit bestimmt. Weitere Informationen finden Sie unter System für APEX-Updates konfigurieren.

Änderungen bei GSIs für Android 10

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

• Nutzer-Build: Das GSI hat einen Nutzer-Build ab Android 10. In Android 10 kann der User-Build-GSI für CTS‑on‑GSI-/VTS-Konformitätstests verwendet werden. Weitere Informationen finden Sie unter VTS-Tests mit Debug-Ramdisk.
• Nicht komprimiertes Format. GSI mit Zielvorhaben aosp_$arch werden im nicht spärlichen Format erstellt. Mit img2simg können Sie bei Bedarf ein nicht sparses GSI in ein sparses Format konvertieren.
• System-as-root: Das alte GSI-Build-Ziel 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 ohne System-as-Root aktualisiert wurden, das alte GSI aosp_$arch_ab. Das aktualisierte init in ramdisk unterstützt OEM-System.img mit System-as-Root-Layout.
• Bootvorgang überprüfen: Bei Verwendung von GSI müssen Sie das Gerät nur entsperren. Es ist nicht erforderlich, den verifizierten Bootmodus zu deaktivieren.

Änderungen bei Android 9-GSIs

Geräte, die mit Android 9 auf den Markt kommen oder auf Android 9 aktualisiert werden, müssen für Compliance-Tests Android 9-GSIs verwenden. Dazu gehören die folgenden wichtigen Änderungen gegenüber früheren GSIs:

• Führt GSI und Emulator zusammen. GSIs werden aus den System-Images von Emulatorprodukten wie aosp_arm64 und aosp_x86 erstellt.
• System-as-root: In früheren Android-Versionen konnten Geräte, die keine A/B-Updates unterstützten, das System-Image im Verzeichnis /system einbinden. In Android 9 wird das Root-Verzeichnis des System-Images als Root-Verzeichnis des Geräts bereitgestellt.
• 64-Bit-Binder-Schnittstelle. In Android 8.x wurde für 32-Bit-GSIs die 32-Bit-Binder-Schnittstelle verwendet. 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-Erzwingung In Android 8.1 war VNDK optional. Ab Android 9 ist VNDK obligatorisch. Daher BOARD_VNDK_VERSION muss festgelegt werden.
• Kompatibles Systemattribut: Unter Android 9 wird die Zugriffsprüfung für eine kompatible Systemeigenschaft (PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true) aktiviert.

Android 9 Keymaster-Änderungen

In früheren Android-Versionen mussten Geräte, die Keymaster 3 oder niedriger implementieren, überprüfen, ob die vom ausgeführten System gemeldeten Versionsinformationen (ro.build.version.release und ro.build.version.security_patch) mit den vom Bootloader gemeldeten Versionsinformationen übereinstimmten. Diese Informationen wurden in der Regel aus dem Boot-Image-Header abgerufen.

In Android 9 und höher wurde diese Anforderung geändert, damit Anbieter ein GSI booten können. 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 mit Keymaster 3 oder niedriger müssen Anbieter die Keymaster-Implementierung so ändern, dass die Bestätigung übersprungen wird, oder ein Upgrade auf Keymaster 4 durchführen. Weitere Informationen zu Keymaster finden Sie unter Hardware-backed Keystore.

GSIs herunterladen

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

GSIs erstellen

Seit Android 9 hat jede Android-Version einen GSI-Branch mit dem Namen DESSERT-gsi im AOSP (z. B. ist android12-gsi der GSI-Branch in Android 12). GSI-Branches enthalten 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 aus einem GSI-Branch herunterladen und ein GSI-Build-Ziel auswählen. Anhand der folgenden Tabellen mit Build-Zielen können Sie die richtige GSI-Version für Ihr Gerät ermitteln. Nach Abschluss des Builds ist das GSI das System-Image (system.img) und wird im Ausgabeverzeichnis out/target/product/generic_arm64 angezeigt.

Wenn Sie beispielsweise das GSI-Build-Ziel gsi_arm64-userdebug im GSI-Branch android12-gsi erstellen möchten, 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 sind für Geräte, die mit Android 9 oder höher auf den Markt kommen.

Anforderungen für das Flashen von GSIs

Android-Geräte können unterschiedliche Designs haben. Daher gibt es keinen generischen Befehl oder eine Reihe von Anleitungen zum Flashen einer GSI, die für alle Geräte gelten. Eine genaue Anleitung dazu erhalten Sie vom Hersteller des Android-Geräts. Gehen Sie dazu so vor:

1. Das Gerät muss Folgendes haben:
   • Höhen angehoben
   • Eine Methode zum Entsperren von Geräten (damit sie mit fastboot geflasht werden können)
   • Ein entsperrter Status, damit es über fastboot geflasht werden kann (damit Sie die aktuelle Version von fastboot haben, erstellen Sie sie 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 Nutzerdaten und die Daten aus anderen erforderlichen Partitionen (z. B. Nutzerdaten- und Systempartitionen).
4. Starten Sie das Gerät neu.

So flashen Sie beispielsweise ein GSI auf ein beliebiges Pixel-Gerät:

1. Im fastboot-Modus booten und Bootloader entsperren.
2. Die Geräte, die fastbootd unterstützen, müssen auch in fastbootd gebootet werden. Dazu muss Folgendes erfüllt sein:

   $ fastboot reboot fastboot

3. Löschen Sie die Systempartition und flashen Sie die GSI darauf:

   $ fastboot erase system
   $ fastboot flash system system.img

4. Wenn Ihr Gerät das Android Virtual Framework unterstützt, flashen Sie die Firmware der geschützten virtuellen Maschine:

   $ fastboot flash pvmfw pvmfw.img
   

5. Löschen Sie die Nutzerdaten und die Daten aus anderen erforderlichen Partitionen (z. B. Nutzerdaten- und Systempartitionen):

   $ fastboot -w

6. Starten Sie das Gerät wieder im Bootloader-Menü neu:

   $ fastboot reboot-bootloader

7. Deaktivieren Sie die Überprüfung des verifizierten Bootmodus, während Sie die bereitgestellte vbmeta flashen:

   $ fastboot --disable-verification flash vbmeta vbmeta.img

8. Reboot:

   $ fastboot reboot

    Resizing 'system_a'    FAILED (remote: 'Not enough space to resize partition')
    fastboot: error: Command failed

$ fastboot delete-logical-partition product_a

Beiträge zu GSIs

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

• GSI-Patch erstellen DESSERT-gsi ist kein Entwicklungszweig und akzeptiert nur Cherrypicks aus dem AOSP-Zweig der neuesten Version (android16-release). Wenn Sie also einen GSI-Patch einreichen möchten, müssen Sie Folgendes tun:
  1. Reichen Sie den Patch für den AOSP-Zweig android16-release ein.
  2. Cherrypicken Sie den Patch für DESSERT-gsi.
  3. Melden Sie einen Fehler, um den Cherry-Pick überprüfen zu lassen.
• GSI-Bugs melden oder andere Vorschläge machen. Lesen Sie die Anleitung unter Fehler melden und suchen oder melden Sie dann GSI-Fehler.

Tipps

Navigationsleistenmodus mit ADB ändern

Beim Booten mit GSI wird der Navigationsleistenmodus durch die Überschreibung 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

Dabei kann mode für threebutton, twobutton, gestural usw. stehen.