Generische System-Images

Ein generisches System-Image (GSI) ist ein System-Image mit angepassten Konfigurationen für Android-Geräte. Sie gilt als reine Android-Implementierung. mit unverändertem AOSP-Code (Android Open Source Project), mit Android 9 oder höher funktioniert.

GSIs werden zum Ausführen von VTS- und CTS-on-GSI-Tests verwendet. Das System-Image eines Das Android-Gerät wird durch ein GSI-Gerät ersetzt und dann mit dem Vendor Test Suite (VTS) und die Compatibility Test Suite (CTS), um sicherzustellen, Ob auf dem Gerät Anbieterschnittstellen korrekt mit der neuesten Version implementiert sind von Android.

In den folgenden Abschnitten finden Sie Informationen zu den ersten Schritten mit GSI-Konfigurationen (und zulässig Varianzen) und Typen. Wenn Sie bereit sind, eine GSI zu nutzen, GSI für Ihr Gerät herunterladen und erstellen und anschließend das GSI auf ein Android-Gerät .

GSI-Konfiguration und -Abweichungen

Die aktuelle Android GSI-Konfiguration ist folgendermaßen konfiguriert:

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

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

GSI-Ziele für Treble-Compliance-Tests

Die für Compliance-Tests verwendete GSI-Nummer hängt von der Android-Version ab, die mit denen das Gerät gestartet wird.

Gerätetyp Ziel erstellen
Geräte, die mit Android 14 auf den Markt gebracht werden gsi_$arch-user (unterzeichnet)
Geräte, die mit Android 13 auf den Markt gebracht werden gsi_$arch-user (unterzeichnet)
Geräte, die mit Android 12L auf den Markt gebracht werden gsi_$arch-user (unterzeichnet)
Geräte, die mit Android 12 auf den Markt gebracht werden gsi_$arch-user (unterzeichnet)
Geräte, die mit Android 11 auf den Markt gebracht werden gsi_$arch-user (unterzeichnet)

Alle GSIs basieren auf der Android 12-Codebasis. jede CPU-Architektur hat eine entsprechende GSI-Binärdatei (siehe Build-Liste Ziele in Google-Sicherheitsinformationen erstellen).

GSI-Änderungen bei Android 12

Auf Geräten, die mit Android 12 auf den Markt gebracht oder darauf aktualisiert werden, muss Android verwendet werden 12 GSIs für Compliance-Tests. Dazu gehören die folgenden wichtigen Änderungen gegenüber früheren GSIs:

  • Zielname: Der Name des GSI-Ziels für die Compliance Tests wird in gsi_$arch geändert. Die GSI mit Zielname aosp_$arch wird für Entwickler von Android-Apps gespeichert. Testplan CTS-on-GSI wurde auch für das Testen der Benutzeroberfläche des Anbieters reduziert.
  • Die alte GSI-Version wird eingestellt. GSI 12 entfernt die Behelfslösungen für Geräte mit Android 8.0 oder 8.1, nicht vollständig verdreifacht wurden.
  • UserDebug-SEPolicy. Die GSI-gsi_$arch enthält userdebug_plat_sepolicy.cil. Beim Blinken die OEM-spezifische vendor_boot-debug.img oder boot-debug.img, /system/bin/init wird geladen userdebug_plat_sepolicy.cil vom GSI system.img Nachschlagewerke VTS-Tests mit Debuggen Sie Ramdisk, um Details zu erhalten.

GSI-Änderungen bei Android 11

Auf Geräten, die mit Android 11 auf den Markt gebracht oder darauf aktualisiert werden, muss Android verwendet werden 11 GSIs für Compliance-Tests. Dazu gehören die folgenden wichtigen Änderungen gegenüber früheren GSIs:

  • system_ext-Inhalte. Android 11 definiert die neue Partition system_ext. GSI legt den Inhalt der Systemerweiterung im Ordner ab system/system_ext
  • APEXes: GSI enthält sowohl vereinfachte als auch komprimierte APEXes. Welche Methode verwendet werden soll, hängt von der Systemeigenschaft ro.apex.updatable ab. in der Anbieterpartition. Nachschlagewerke Konfigurieren des Systems zur Unterstützung von APEX-Updates für die Details.

GSI-Änderungen bei Android 10

Auf Geräten, die mit Android 10 auf den Markt gebracht oder darauf aktualisiert werden, muss Android verwendet werden 10 GSIs für Compliance-Tests Dazu gehören die folgenden wichtigen Änderungen gegenüber früheren GSIs:

  • Nutzer-Build: GSI hat Nutzer-Build aus Android 10. In Android 10 Die von Nutzern erstellte GSI kann für CTS-on-GSI/VTS-Compliance-Tests verwendet werden. Nachschlagewerke VTS-Tests mit Debug Ramdisk .
  • Kein dünn besetztes Format. GSI mit Zielen aosp_$arch werden mit einem nicht geparsten Format erstellt. Sie können img2simg zum Konvertieren einer nicht geparsten GSI in ein dünnbesetztes Format, wenn notwendig ist.
  • System-as-root: Das alte GSI-Build-Ziel aosp_$arch_a wurde eingestellt. Für die Geräte mit Upgrade von Android 8 oder 8.1 auf Android 10 mit ramdisk und nicht vom System als Root, verwenden Sie das alte GSI-aosp_$arch_ab. Das aktualisierte init in ramdisk unterstützt die Datei OEM system.img. mit dem System-as-root-Layout.
  • Starten prüfen: Bei Verwendung von GSI müssen Sie nur das Gerät entsperren. Die Option „Verify Boot“ muss nicht deaktiviert werden.

GSI-Änderungen bei Android 9

Auf Geräten, die mit Android 9 auf den Markt gebracht oder darauf aktualisiert werden, muss Android verwendet werden 9 GSIs für Compliance-Tests. Dazu gehören die folgenden wichtigen Änderungen gegenüber früheren GSIs:

  • Kombiniert GSI und Emulator. GSIs werden aus dem System erstellt Bilder von Emulatorprodukten, z. B. aosp_arm64 und aosp_x86.
  • System-as-root: In früheren Android-Versionen die keine A/B-Updates unterstützt haben, könnten Sie das System-Image unter dem /system-Verzeichnis. In Android 9 Stamm des System-Images wird als Root des Geräts bereitgestellt.
  • 64-Bit-Binder-Schnittstelle. In Android 8.x, 32-Bit-GSIs die 32-Bit-Binder-Schnittstelle verwendet hat. Android 9 unterstützt die 32-Bit-Binder-Schnittstelle nicht, sodass sowohl 32-Bit-GSIs als auch 64-Bit-GSIs verwenden die 64-Bit-Binder-Schnittstelle.
  • Durchsetzung der VNDK-Richtlinie. In Android 8.1 war VNDK optional. Ab Android 9 ist VNDK obligatorisch. BOARD_VNDK_VERSION muss festgelegt werden.
  • Kompatible Systemeigenschaft: Android-Geräte 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 wurden auf Geräten mit Keymaster 3 oder niedriger um zu prüfen, ob die Versionsinformationen (ro.build.version.release und ro.build.version.security_patch) vom laufenden System gemeldet mit den vom Bootloader gemeldeten Versionsinformationen übereinstimmten. Diese Informationen wurden normalerweise aus dem Boot-Image-Header.

Ab Android 9 wurde diese Anforderung geändert: GSI zu starten. Insbesondere sollte Keymaster keine Überprüfungen da die von der GSI gemeldeten Versionsinformationen möglicherweise nicht mit den Versionsinformationen übereinstimmen. die vom Bootloader des Anbieters gemeldet wurden. Bei Geräten mit Keymaster 3 oder müssen Anbieter die Keymaster-Implementierung ändern, um die Überprüfung zu überspringen. oder ein Upgrade auf Keymaster 4 durchführen. Weitere Informationen zu Keymaster finden Sie unter Hardwaregestützter Schlüsselspeicher

GSIs herunterladen

Sie können vordefinierte GSIs aus der Continuous Integration (CI) von AOSP herunterladen Website unter ci.android.com zur Verfügung stehen. Wenn der GSI-Typ für Ihre Hardware nicht zum Download verfügbar ist, finden Sie im folgenden Abschnitt wie Sie GSIs für bestimmte Ziele erstellen.

GSIs entwickeln

Ab Android 9 hat jede Android-Version ein GSI-Zweig namens DESSERT-gsi bei AOSP (z. B. android12-gsi ist der GSI-Zweig unter Android. 12). Zu den GSI-Zweigen gehören Android-Inhalte mit alle Sicherheits-Patches und Es wurden GSI-Patches angewendet.

Um eine GSI-Datei zu erstellen, richten Sie die Android-Quellstruktur ein, indem Sie das Herunterladen aus einem GSI-Zweig und GSI-Build auswählen Ziel haben. Verwenden Sie die unten stehenden Build-Zieltabellen, um die richtige GSI-Version zu bestimmen. Version für Ihr Gerät. Nach Abschluss des Builds ist die GSI das System, (system.img) und wird im Ausgabeordner angezeigt out/target/product/generic_arm64.

Um beispielsweise das GSI-Build-Ziel zu erstellen, gsi_arm64-userdebug für den GSI-Zweig android12-gsi, 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 herausgebracht werden 9 oder höher.

GSI-Name CPU-Architektur Bitgröße der Binder-Schnittstelle System-as-root Ziel erstellen
gsi_arm SCHARF SCHALTEN 32 J gsi_arm-user
gsi_arm-userdebug
gsi_arm64 ARM64 64 J gsi_arm64-user
gsi_arm64-userdebug
gsi_x86 x86 32 J gsi_x86-user
gsi_x86-userdebug
gsi_x86_64 x86–64 64 J gsi_x86_64-user
gsi_x86_64-userdebug

Anforderungen für das Flashen von GSIs

Da Android-Geräte unterschiedliche Designs haben können, gibt es keine generischen Befehle oder Anleitung zum Flashen einer GSI-Datei für alle Geräte Prüfen bei den Hersteller des Android-Geräts, um explizite Anweisungen zum Blinken zu erhalten. Orientieren Sie sich an den folgenden Schritten:

  1. Das Gerät muss folgende Voraussetzungen erfüllen:
    • Treblized
    • Eine Methode zum Entsperren von Geräten, damit sie mit fastboot)
    • Ein entsperrter Zustand, der das Flash-Format über fastboot ermöglicht (Um sicherzustellen, dass Sie über die neueste Version von fastboot verfügen, erstellen Sie aus der Android-Quellstruktur.
  2. Löscht die aktuelle Systempartition und flasht dann das GSI auf das System. -Partition an.
  3. Löschen Sie die Nutzerdaten und die Daten aus anderen erforderlichen Partitionen (für z. B. Nutzerdaten und Systempartitionen).
  4. Starten Sie das Gerät neu.

So können Sie beispielsweise eine GSI-Datei auf einem beliebigen Pixel-Gerät flashen:

  1. Booten bis fastboot-Modus und entsperren Sie Bootloader.
  2. Geräte, die die fastbootd müssen außerdem fastbootd starten: 
    $ fastboot reboot fastboot
  3. Löschen Sie die GSI-Datei und speichern Sie sie auf der Systempartition: 
    $ fastboot erase system
$ fastboot flash system system.img
  4. Löschen Sie die Nutzerdaten und die Daten aus anderen erforderlichen Partitionen (für z. B. Nutzerdaten und Systempartitionen): 
    $ fastboot -w
  5. Neu starten: 
    $ fastboot reboot
Auf Geräten mit Android 10 oder höher mit kleineren Systempartitionen: kann die folgende Fehlermeldung angezeigt werden, wenn das GSI geflasht wird: 
    Resizing 'system_a'    FAILED (remote: 'Not enough space to resize partition')
    fastboot: error: Command failed
Verwenden Sie den folgenden Befehl, um die Produktaufteilung zu löschen und Speicherplatz für die Systempartition. Dies bietet zusätzlichen Platz zum Flashen der GSI-Datei: 
$ fastboot delete-logical-partition product_a
Das Postfix _a sollte mit der Slot-ID der Systempartition übereinstimmen. wie system_a in diesem Beispiel.

Zu GSIs beitragen

Wir freuen uns über Ihren Beitrag zur GSI-Entwicklung. Du kannst mitmachen und zur Verbesserung des GSI beitragen, indem Sie:

  • GSI-Patch erstellen: DESSERT-gsi ist keine Entwicklungsabteilung und akzeptiert nur Cherrypicks von dem AOSP-Hauptzweig. Um einen GSI-Patch zu senden, müssen Sie also:
    1. Sende den Patch an den AOSP Zweig main.
    2. Klicke auf das Pflaster, um DESSERT-gsi.
    3. Melde einen Fehler, um den Cherypick zu überprüfen.
  • GSI-Fehler melden oder andere Vorschläge machen Überprüfen die Anweisungen in Fehler melden, dann Durchsuchen oder Datei GSI Bugs

Tipps

Navigationsleistenmodus mit ADB ändern

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

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

Wobei mode threebutton, twobutton, gestural usw.