Generische System-Images

Ein generisches Systemimage (GSI) ist ein Systemimage mit angepassten Konfigurationen für Android-Geräte. Es gilt als reine Android-Implementierung mit unverändertem Open-Source-Projekt für Android (AOSP)-Code, die auf jedem Android-Gerät mit Android 9 oder höher ausgeführt werden kann.

GSIs werden für die Ausführung 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 Herstellerschnittstellen mit der neuesten Version von Android korrekt implementiert.

Weitere Informationen zu GSI-Konfigurationen (und zulässigen Abweichungen) und -Typen finden Sie in den folgenden Abschnitten. Wenn Sie ein GSI verwenden möchten, laden Sie es herunter und erstellen Sie es für Ihr Zielgerät, anschließend können Sie es auf ein Android Gerät flashen.

GSI-Konfiguration und -Abweichungen

Das aktuelle Android-GSI hat die folgende Konfiguration:

• Treble Das GSI bietet vollständige Unterstützung für die auf AIDL/HIDL basierenden architektonischen Ä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-Herstellerschnittstellen nutzt. Weitere Informationen finden Sie unter Architekturressourcen.
• Dateisystem Das GSI verwendet das ext4-Dateisystem.

Das aktuelle Android-GSI weist die folgenden Hauptabweichungen auf:

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

GSI-Ziele für Treble-Konformitätstests

Das 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 der Android 12-Codebasis erstellt und für jede CPU-Architektur gibt es eine entsprechende GSI-Binärdatei (siehe die Liste der Build-Ziele unter GSIs erstellen).

Änderungen bei Android 12-GSIs

Geräte, die bei Markteinführung Android 12 nutzen 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:

• Zielname 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 wurde ebenfalls reduziert, um die Herstellerschnittstelle zu testen.
• Das alte GSI wird eingestellt Mit GSI 12 werden die Workarounds für Android 8.0- oder 8.1-Geräte entfernt, die nicht vollständig Treble-kompatibel sind.
• Userdebug-SEPolicy Das GSI gsi_$arch enthält userdebug_plat_sepolicy.cil. Wenn Sie das OEM-spezifische vendor_boot-debug.img oder boot-debug.img flashen, lädt /system/bin/init userdebug_plat_sepolicy.cil aus dem GSI system.img. Weitere Informationen finden Sie unter VTS-Tests mit Debug-Ramdisk.

Änderungen bei Android 11-GSIs

Geräte, die bei Markteinführung Android 11 nutzen oder auf Android 11 aktualisiert werden, müssen für Konformitätstests Android 11-GSIs 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. Das GSI platziert die Inhalte der Systemerweiterung im Ordner system/system_ext.
• APEX-Dateien Das GSI enthält sowohl nicht komprimierte als auch komprimierte APEX-Dateien. Welche verwendet wird, wird zur Laufzeit durch die System-Property ro.apex.updatable in der Herstellerpartition bestimmt. Weitere Informationen finden Sie unter System für APEX-Updates konfigurieren.

Änderungen bei Android 10-GSIs

Geräte, die bei Markteinführung Android 10 nutzen 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 aus Android 10. In Android 10 kann das GSI des Nutzer-Builds in CTS‑on‑GSI-/VTS-Konformitätstests verwendet werden. Weitere Informationen finden Sie unter VTS-Tests mit Debug-Ramdisk.
• Nicht komprimiertes Format GSIs mit den Zielen aosp_$arch werden mit einem nicht komprimierten Format erstellt. Bei Bedarf können Sie img2simg verwenden, um ein nicht komprimiertes GSI in ein komprimiertes Format zu konvertieren, falls erforderlich.
• System-as-root Das alte GSI-Ziel-Build mit dem Namen aosp_$arch_a wurde eingestellt. Für Geräte, die von Android 8 oder 8.1 auf Android 10 aktualisiert wurden und eine Ramdisk und kein System-as-root verwenden, verwenden Sie das alte GSI aosp_$arch_ab. Das aktualisierte init in der Ramdisk unterstützt OEM-System.img mit dem System-as-root-Layout.
• Verifizierter Bootmodus Wenn Sie ein GSI verwenden, 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 bei Markteinführung Android 9 nutzen oder auf Android 9 aktualisiert werden, müssen für Konformitätstests Android 9-GSIs verwenden. Dazu gehören die folgenden wichtigen Änderungen gegenüber früheren GSIs:

• GSI und Emulator werden zusammengeführt GSIs werden aus den System images von Emulatorprodukten erstellt, z. B. aosp_arm64 und aosp_x86.
• System-as-root In früheren Android-Versionen konnten Geräte, die keine A/B-Updates unterstützten, das Systemimage im /system Verzeichnis einbinden. In Android 9 wird das Stammverzeichnis des Systemimages als Stammverzeichnis des Geräts eingebunden.
• 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- 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.
• Kompatible System-Property Android 9 aktiviert die Zugriffsprüfung für eine kompatible System-Property (PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true).

Änderungen bei Android 9-Keymaster

In früheren Android-Versionen mussten Geräte, die Keymaster 3 oder niedriger implementierten, ü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 Angaben übereinstimmten. Diese Informationen wurden in der Regel aus dem Bootimage-Header abgerufen.

In Android 9 und höher wurde diese Anforderung geändert, damit Anbieter ein GSI starten können. Insbesondere sollte Keymaster keine Überprüfung durchführen da die vom GSI gemeldeten Versionsinformationen möglicherweise nicht mit den vom Anbieter gemeldeten Versionsinformationen des Bootloaders übereinstimmen. Für Geräte, die Keymaster 3 oder niedriger implementieren, müssen Anbieter die Keymaster-Implementierung ändern, um die Überprüfung zu überspringen (oder auf Keymaster 4 zu aktualisieren). Weitere Informationen zu Keymaster finden Sie unter Hardwaregestützter Keystore.

GSIs herunterladen

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

GSIs erstellen

Ab Android 9 hat jede Android-Version einen GSI-Branch mit dem Namen DESSERT-gsi in AOSP. android12-gsi ist beispielsweise der GSI-Branch in Android 12. GSI-Branches enthalten die Inhalte von Android mit allen Sicherheitspatches und GSI-Patches angewendet.

Um ein GSI zu erstellen, richten Sie die Android-Quellstruktur ein, indem Sie sie aus einem GSI-Branch herunterladen und ein GSI-Ziel-Build auswählen. Anhand der Tabellen mit den Ziel-Builds unten können Sie die richtige GSI Version für Ihr Gerät ermitteln. Nach Abschluss des Builds ist das GSI das System image (that is, system.img) und wird im Ausgabeverzeichnis out/target/product/generic_arm64.

Führen Sie beispielsweise die folgenden Befehle aus, um das GSI-Ziel-Build gsi_arm64-userdebug im GSI-Branch android12-gsi, zu erstellen.

$ 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-Ziel-Builds

Die folgenden GSI-Ziel-Builds sind für Geräte, die bei Markteinführung Android 9 oder höher nutzen.

Anforderungen für das Flashen von GSIs

Android-Geräte können unterschiedliche Designs haben. Daher gibt es keinen generischen Befehl oder keine generische Anleitung zum Flashen eines GSIs, die für alle Geräte gilt. Wenden Sie sich an den Hersteller des Android-Geräts, um eine genaue Anleitung zum Flashen zu erhalten. Verwenden Sie die folgenden Schritte als allgemeine Richtlinie:

1. Das Gerät muss Folgendes haben:
   • Treble-kompatibel
   • Eine Methode zum Entsperren von Geräten, damit sie mit fastboot geflasht werden können
   • Ein entsperrter Zustand, damit es über fastboot geflasht werden kann. Um sicherzustellen, dass Sie die neueste Version von fastboot haben, erstellen Sie sie aus der Android-Quellstruktur.
2. Löschen Sie die aktuelle Systempartition und flashen Sie dann das GSI auf die System partition.
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. Starten Sie im fastboot Modus und entsperren Sie den Bootloader.
2. Geräte, die fastbootd unterstützen, müssen auch in fastbootd gestartet werden. Gehen Sie dazu so vor:

   $ 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. Wenn Ihr Gerät 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 den Bootloader neu:

   $ fastboot reboot-bootloader

7. Deaktivieren Sie die Überprüfung des Bootmodus mit Verifikation, 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 leisten

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

• Einen GSI-Patch erstellen DESSERT-gsi ist kein Entwicklungs-Branch und akzeptiert nur Cherrypicks aus dem neuesten AOSP-Release-Branch (android17-release). Wenn Sie also einen GSI Patch einreichen möchten, müssen Sie so vorgehen:
  1. Reichen Sie den Patch im AOSP android17-release Branch ein.
  2. Cherrypicken Sie den Patch zu DESSERT-gsi.
  3. Melden Sie einen Fehler, damit der Cherrypick überprüft werden kann.
• GSI-Fehler melden oder andere Vorschläge machen. Folgen Sie der Anleitung unter Fehler melden und suchen Sie nach GSI Fehlern oder melden Sie sie.

Tipps

Navigationsleistenmodus mit adb ändern

Beim Starten mit GSI wird der Navigationsleistenmodus durch die Überschreibung des Herstellers konfiguriert. Sie können den Navigationsleistenmodus ändern, indem Sie zur Laufzeit den folgenden adb-Befehl ausführen.

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

Dabei kann mode threebutton, twobutton, gestural usw. sein.