Generische System-Images

Ein generisches System-Image (GSI) ist ein System-Image 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), der 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 System-Image 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 auf dem Gerät Anbieterschnittstellen korrekt mit der neuesten Android-Version implementiert werden.

In den folgenden Abschnitten finden Sie Informationen zu GSI-Konfigurationen (und zulässigen Abweichungen) und Typen. Wenn Sie eine GSI verwenden möchten, laden Sie die GSI für Ihr Zielgerät herunter und erstellen Sie sie. Brennen Sie die GSI dann auf ein Android-Gerät.

GSI-Konfiguration und Abweichungen

Die aktuelle Android-GSI hat die folgende Konfiguration:

• Höhen Die GSI bietet vollständige Unterstützung für die AIDL-/HIDL-basierten Architekturänderungen (auch als Treble bezeichnet), 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 Informationen finden Sie unter Architekturressourcen.
• Dateisystem Die GSI verwendet das ext4-Dateisystem.

Der aktuelle GSI für Android weist die folgenden Hauptabweichungen auf:

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

GSI-Ziele für Treble-Compliance-Tests

Die für Compliance-Tests verwendete GSI richtet sich nach der Android-Version, mit der das Gerät gestartet wird.

Alle GSIs werden aus der Android 12-Codebasis erstellt und jede CPU-Architektur hat eine entsprechende GSI-Binärdatei (siehe Liste der Buildziele unter GSIs erstellen).

GSI-Änderungen bei Android 12

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

• Zielname: Der GSI-Zielname für Compliance-Tests wurde in gsi_$arch geändert. Die 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 Anbieteroberfläche reduziert.
• Die alte GSI-Version wird eingestellt. In GSI 12 werden die Problemumgehungen für Geräte mit Android 8.0 oder 8.1 entfernt, die nicht vollständig verarbeitet sind.
• Userdebug SEPolicy Die GSI gsi_$arch enthält userdebug_plat_sepolicy.cil. Wenn Sie die OEM-spezifische vendor_boot-debug.img oder boot-debug.img flashen, lädt /system/bin/init userdebug_plat_sepolicy.cil aus der GSI-system.img. Weitere Informationen finden Sie unter VTS-Tests mit Debug-Ramdisk.

Änderungen bei der GSI von Android 11

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

• system_ext-Inhalt. Android 11 definiert eine neue Partition system_ext. GSI fügt den Inhalt der Systemerweiterung dem Ordner system/system_ext hinzu.
• APEXes GSI enthält sowohl vereinfachte als auch komprimierte APEXes. Welches verwendet wird, wird zur Laufzeit durch die Systemeigenschaft ro.apex.updatable in der Anbieterpartition bestimmt. Weitere Informationen finden Sie unter System für die Unterstützung von APEX-Updates konfigurieren.

Änderungen bei der GSI von Android 10

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

• Nutzer erstellen GSI hat eine Nutzerversion von Android 10. Unter Android 10 kann die GSI des Nutzerbuilds für CTS-on-GSI-/VTS-Compliance-Tests verwendet werden. Weitere Informationen finden Sie unter VTS-Tests mit Debug-Ramdisk.
• Ungespartes Format GSIs mit Zielen vom Typ aosp_$arch werden im unformatierten Format erstellt. Mit img2simg können Sie bei Bedarf eine nicht geparste GSI in ein sparses Format konvertieren.
• System-as-root Das alte GSI-Buildziel 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, die alte GSI-aosp_$arch_ab. Das aktualisierte init in ramdisk unterstützt den OEM system.img mit dem System-as-root-Layout.
• Startvorgang prüfen Bei der Verwendung von GSI müssen Sie nur das Gerät entsperren. Es ist nicht erforderlich, den verifizierten Bootmodus zu deaktivieren.

Änderungen bei der GSI von Android 9

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

• Fügt GSI und Emulator zusammen. 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 Verzeichnis /system bereitstellen. Unter Android 9 wird das Stammverzeichnis des System-Images als Root 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, sodass sowohl 32-Bit-GSIs als auch 64-Bit-GSIs die 64-Bit-Binder-Schnittstelle verwenden.
• VNDK-Durchsetzung In Android 8.1 war VNDK optional. Ab Android 9 ist VNDK obligatorisch. Daher muss BOARD_VNDK_VERSION festgelegt werden.
• Kompatible Systemeigenschaft Unter Android 9 ist die Zugriffsüberprüfung für eine kompatible Systemeigenschaft (PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true) möglich.

Änderungen bei Keymaster unter Android 9

In früheren Android-Versionen mussten Geräte, auf denen Keymaster 3 oder niedriger implementiert ist, prüfen, ob die vom laufenden System gemeldeten Versionsinformationen (ro.build.version.release und ro.build.version.security_patch) mit den vom Bootloader gemeldeten Versionsinformationen übereinstimmen. Diese Informationen wurden in der Regel aus dem Boot-Image-Header abgerufen.

Unter Android 9 und höher wurde diese Anforderung geändert, damit Anbieter eine GSI starten 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, auf denen Keymaster 3 oder niedriger implementiert ist, müssen Anbieter die Keymaster-Implementierung ändern, um die Überprüfung zu überspringen (oder auf Keymaster 4 umstellen). Weitere Informationen zum Keymaster finden Sie unter Hardwaregestützter Schlüsselspeicher.

GSIs herunterladen

Sie können vorkonfigurierte 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 Download verfügbar ist, finden Sie im folgenden Abschnitt Informationen zum Erstellen von GSIs für bestimmte Ziele.

GSIs entwickeln

Ab Android 9 hat jede Android-Version einen GSI-Branch namens DESSERT-gsi in AOSP. android12-gsi ist beispielsweise der GSI-Branch von Android 12. GSI-Zweige umfassen den Inhalt von Android mit allen angewendeten Sicherheitspatches und GSI-Patches.

Wenn Sie eine GSI erstellen möchten, richten Sie den Android-Quellbaum ein, indem Sie ihn aus einem GSI-Branch herunterladen und ein GSI-Buildziel auswählen. Anhand der folgenden Tabellen für Buildziele können Sie die richtige GSI-Version für Ihr Gerät ermitteln. Nach Abschluss des Builds ist die GSI das System-Image (system.img) und wird im Ausgabeordner out/target/product/generic_arm64 angezeigt.

Wenn Sie beispielsweise das GSI-Buildziel 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-Buildziele

Die folgenden GSI-Buildziele sind für Geräte gedacht, die mit Android 9 oder höher auf den Markt kommen.

Voraussetzungen für das Flashen von GSIs

Da Android-Geräte unterschiedliche Designs haben können, gibt es keinen generischen Befehl oder eine Reihe von Anweisungen zum Flashen einer GSI-Datei, die auf alle Geräte angewendet werden kann. Eine ausführliche Anleitung zum Flashen erhalten Sie vom Hersteller des Android-Geräts. Die folgenden Schritte dienen als allgemeiner Leitfaden:

1. Das Gerät muss folgende Voraussetzungen erfüllen:
   • Verdreifacht
   • Eine Methode zum Entsperren von Geräten, damit sie mit fastboot geflasht werden können
   • Entsperren, damit es über fastboot geflasht werden kann (Um sicherzugehen, dass Sie die neueste Version von fastboot haben, bauen Sie sie aus dem Android-Quellcodebaum.)
2. Löschen Sie die aktuelle Systempartition und flashen Sie die GSI dann 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 eine GSI auf ein Pixel-Gerät:

1. Starten Sie im fastboot-Modus und entsperren Sie den Bootloader.
2. Die Geräte, die fastbootd unterstützen, müssen außerdem in fastbootd starten. Gehen Sie dazu so vor:

   $ fastboot reboot fastboot

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

   $ fastboot erase system
   $ fastboot flash system system.img

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

   $ fastboot -w

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

   $ fastboot reboot-bootloader

6. Deaktivieren Sie die Überprüfung des abgesicherten Startmodus, während Sie die bereitgestellte vbmeta-Datei flashen:

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

7. Reboot:

   $ fastboot reboot

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

$ fastboot delete-logical-partition product_a

Zu GSIs beitragen

Wir freuen uns über Ihre Beiträge zur Entwicklung von GSI. Sie können sich beteiligen und zur Verbesserung der globalen Suchanfrage beitragen, indem Sie:

• GSI-Patch erstellen DESSERT-gsi ist kein Entwicklungszweig und akzeptiert nur Cherrypicks aus dem AOSP-Hauptzweig. Wenn du einen GSI-Patch einreichen möchtest, musst du:
  1. Reichen Sie den Patch für den main-Zweig von AOSP ein.
  2. Klicke auf das Pflaster, um DESSERT-gsi.
  3. Melden Sie einen Fehler, damit die Cherry-Pick-Datei überprüft wird.
• GSI-Fehler melden oder andere Vorschläge machen Lesen Sie die Anleitung unter Fehler melden und suchen Sie dann nach GSI-Fehlern.

Tipps

Modus der Navigationsleiste mit adb ändern

Beim Starten mit GSI wird der Navigationsleistenmodus durch den Anbieter überschrieben. Sie können den Navigationsleistenmodus ändern, indem Sie den folgenden ADB-Befehl in der Laufzeit ausführen.

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

Dabei steht mode für threebutton, twobutton, gestural usw.