Google setzt sich dafür ein, die Rassengerechtigkeit für schwarze Gemeinschaften zu fördern. Siehe wie.
Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Generische Systemabbilder

Ein generisches Systemabbild (GSI) ist ein Systemabbild 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 8.1 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 anschließend mit der Vendor Test Suite (VTS) und der Compatibility Test Suite (CTS) getestet, um sicherzustellen, dass das Gerät die Herstellerschnittstellen korrekt mit der neuesten Version von Android implementiert.

Um mit GSIs zu beginnen, lesen Sie die folgenden Abschnitte, um Details zu GSI-Konfigurationen (und zulässigen Abweichungen), Typen (Android GSI und Legacy GSI) sowie Hersteller-Binärdateien und VNDK-Abhängigkeiten zu erhalten . Wenn Sie bereit sind, eine GSI zu verwenden, laden Sie die GSI für Ihr Geräteziel herunter und erstellen Sie sie. Flashen Sie dann die GSI auf ein Android-Gerät.

GSI-Konfiguration und Abweichungen

Die aktuelle Android GSI hat folgende Konfiguration:

  • Verdreifachen. Die GSI bietet vollständige Unterstützung für die in Android 8.0 eingeführten HIDL-basierten Architekturänderungen (auch als Treble bezeichnet ), einschließlich der Unterstützung für die HIDL-Schnittstellen . Sie können die GSI auf jedem Android-Gerät verwenden, das HIDL-Herstellerschnittstellen verwendet. (Weitere Informationen finden Sie unter Architekturressourcen .)
  • Überprüfen Sie den Start. Die GSI enthält keine Verify- Boot-Lösung (z. B. vboot 1.0 oder AVB ). Um die GSI auf ein Gerät zu flashen, das unter Android 9 oder früher gestartet wird, muss das Gerät über eine Methode zum Deaktivieren des Überprüfungsstarts verfügen.
  • Dateisystem. Die GSI verwendet das ext4-Dateisystem.
  • Partitionslayout. Die GSI verwendet das System-als-Root- Partitionslayout.

Die aktuelle Android-GSI enthält die folgenden Hauptabweichungen:

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

GSI-Ziele für Treble-Compliance-Tests

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

Gerätetyp Ziel erstellen
Geräte, die mit Android 10 gestartet werden aosp_$arch-user
Geräte, die mit Android 9 gestartet werden aosp_$arch-userdebug
Geräte, die mit Android 8.0 oder Android 8.1 gestartet werden aosp_$arch_ab-userdebug

Alle GSIs werden aus der Android 10-Codebasis erstellt, und jede CPU-Architektur verfügt über eine entsprechende GSI-Binärdatei (siehe Liste der Build-Ziele unter Erstellen von GSIs ).

Änderungen an Android 10 GSI

Geräte, die mit Android 10 gestartet werden, müssen Android 10-GSIs für Konformitätstests verwenden. Dies beinhaltet die folgenden wesentlichen Änderungen gegenüber früheren GSI:

  • User Build. GSI hat User Build von 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 gespartes Format. GSI mit Zielen aosp_$arch werden im nicht analysierten Format erstellt. Sie können img2simg , um eine nicht analysierte GSI bei Bedarf in ein Sparse-Format zu konvertieren.
  • System als Wurzel. Das ältere 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 Nicht-System als Root aosp_$arch_ab , die ältere GSI aosp_$arch_ab . Der aktualisierte init in Ramdisk unterstützt OEM system.img mit System-as-Root-Layout.

Verwenden Sie die Android GSI-Build-Ziele, um Geräte zu testen, die unter Android 9 oder 10 mit CTS-on-GSI gestartet werden.

Legacy GSI

Legacy-GSIs mit dem Suffix _ab (z. B. aosp_arm64_ab ). Diese GSIs basieren auf dem Android 10-Quellbaum, enthalten jedoch die folgenden abwärtskompatiblen Konfigurationen für Geräte, die von Android 8 oder 8.1 aktualisiert wurden:

  • 32-Bit-Benutzerbereich + 32-Bit-Binder-Schnittstelle. 32-Bit-GSIs können weiterhin die 32-Bit-Binder-Schnittstelle verwenden.
  • 8.1 VNDK. Geräte können das mitgelieferte 8.1 VNDK verwenden.
  • Mounten Sie Verzeichnisse. Einige ältere Geräte verwenden Verzeichnisse als Mount-Zeiger (z. B. /bluetooth , /firmware/radio und /persist ).

Verwenden Sie die Legacy-GSI-Build-Ziele, um Geräte zu testen, die unter Android 8 oder 8.1 mit CTS-on-GSI gestartet werden.

Android 9 GSI ändert sich

Android 9-GSIs enthalten die folgenden wesentlichen Änderungen gegenüber früheren GSIs:

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

Änderungen an Android 9 Keymaster

In früheren Android-Versionen mussten Geräte, die Keymaster 3 oder niedriger implementieren, ü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 übereinstimmen. Solche Informationen wurden typischerweise aus dem Boot-Image-Header erhalten.

In 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 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 ein Upgrade auf Keymaster 4 durchzuführen). Ausführliche Informationen zu Keymaster finden Sie unter Hardware-gestützter Keystore .

Hersteller-Binärdateien und VNDK-Abhängigkeiten

Geräte, die auf Android 10 aktualisiert werden, haben unterschiedliche Aktualisierungspfade, abhängig von der Version der auf dem Gerät verwendeten Hersteller-Binärdateien und den VNDK-bezogenen Konfigurationen, die zum Erstellen des Geräts verwendet werden. In der folgenden Tabelle ist die ältere GSI-Unterstützung für aktualisierte Geräte zusammengefasst.

Anwendungsfall Verkäufer
Binärdateien
Ausführung
BOARD_VNDK_VERSION Legacy GSI
Version der Systembinärdateien
Legacy-GSI-Unterstützung
0 8.0 (irgendein) 10 Nein
1 8.1 (leer) 10 Nein
2 8.1 current 10 Ja
3 10 current 10 Ja

Der am häufigsten unterstützte Anwendungsfall ist # 2, bei dem die älteren GSIs Geräte unterstützen, auf denen Android 8.1 ausgeführt wird und bei denen BOARD_VNDK_VERSION auf current .

Der Fall Nr. 1 wird nicht unterstützt. In diesem Fall unterstützen die älteren GSIs KEINE Geräte mit Android 8.1, bei denen BOARD_VNDK_VERSION im Build weggelassen wird. Diese Geräte können nicht unterstützt werden, da ihre Hersteller-Binärdateien von gemeinsam genutzten Android 8.1-Nicht-VNDK-Bibliotheken abhängen, die nicht in älteren GSIs enthalten sind. Um diese Geräte mit einer älteren GSI kompatibel zu machen, müssen Sie einen der folgenden Schritte ausführen:

  • BOARD_VNDK_VERSION BOARD_VNDK_RUNTIME_DISABLE BOARD_VNDK_VERSION ohne BOARD_VNDK_RUNTIME_DISABLE (Anwendungsfall 2).

    ODER

  • Portieren / aktualisieren Sie die Hersteller-Binärdateien, um von den gemeinsam genutzten Bibliotheken von Android 10 abhängig zu sein (Anwendungsfall 3).

GSIs herunterladen

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 Herunterladen verfügbar ist, finden Sie im folgenden Abschnitt Einzelheiten zum Erstellen von GSIs für bestimmte Ziele.

Aufbau von GSIs

Ab Android 9 verfügt jede Android-Version über einen GSI-Zweig mit dem Namen DESSERT -gsi unter AOSP (beispielsweise ist android10-gsi der GSI-Zweig unter Android 10). GSI-Zweige enthalten den Inhalt von Android, wobei alle Sicherheitspatches und GSI-Patches angewendet werden.

Um eine GSI zu erstellen, richten Sie den Android-Quellbaum ein, indem Sie ihn von einem GSI-Zweig herunterladen und ein GSI-Erstellungsziel auswählen . Verwenden Sie die folgenden Build-Zieltabellen, um die richtige GSI-Version für Ihr Gerät zu ermitteln. Nach Abschluss des system.img ist die GSI das Systemabbild ( system.img ) und wird im Ausgabeordner out/target/product/ generic_arm64 . Der Build gibt auch vbmeta.img , mit dem Sie den Überprüfungsstart auf den Geräten mit Android Verified Boot deaktivieren können.

Führen Sie beispielsweise die folgenden Befehle aus, um das GSI-Build-Ziel aosp_arm64-userdebug im GSI-Zweig android10-gsi .

$ repo init -u https://android.googlesource.com/platform/manifest -b android10-gsi
$ repo sync -cq
$ source build/envsetup.sh
$ lunch aosp_arm64-userdebug
$ make -j4

Android GSI Build-Ziele

Die folgenden GSI-Build-Ziele gelten für Geräte, die unter Android 9 oder höher gestartet werden. Aufgrund der geringeren Abweichungen zwischen den Architekturen enthält Android 10 nur vier GSI-Produkte.

GSI-Name CPU-Bogen Binder-Schnittstellen-Bit System als Wurzel Ziel erstellen
aosp_arm ARM 64 Y. aosp_arm-user
aosp_arm-userdebug
aosp_arm64 ARM64 64 Y. aosp_arm64-user
aosp_arm64-userdebug
aosp_x86 x86 64 Y. aosp_x86-user
aosp_x86-userdebug
aosp_x86_64 x86-64 64 Y. aosp_x86_64-user
aosp_x86_64-userdebug

Legacy-GSI-Build-Ziele

Die folgenden älteren GSI-Build-Ziele gelten für Geräte, die von Android 8.0 oder 8.1 auf Android 10 _ab . Legacy-GSI-Namen enthalten das Suffix _ab , um sie von Android 10-GSI-Namen zu unterscheiden.

GSI-Name CPU-Bogen Binder-Schnittstellen-Bitness System als Wurzel Ziel erstellen
aosp_arm_ab ARM 32 Y. aosp_arm_ab-userdebug
aosp_arm_64b_ab ARM 64 Y. aosp_arm_64b_ab-userdebug
aosp_arm64_ab ARM64 64 Y. aosp_arm64_ab-userdebug
aosp_x86_ab x86 32 Y. aosp_x86_ab-userdebug
aosp_x86_64_ab x86-64 64 Y. aosp_x86_64_ab-userdebug

Anforderungen für das Flashen von GSIs

Android-Geräte können unterschiedliche Designs haben, daher gibt es keinen allgemeinen Befehl oder eine Anleitung zum Flashen einer GSI, die auf alle Geräte angewendet werden kann. Wenden Sie sich an den Hersteller des Android-Geräts, um explizite Anweisungen zum Flashen zu erhalten. Verwenden Sie die folgenden Schritte als allgemeine Richtlinie:

  1. Stellen Sie sicher, dass das Gerät über Folgendes verfügt:
    • Treblized
    • Eine Methode zum Entsperren von Geräten (damit sie mit fastboot geflasht werden fastboot )
    • Eine Methode zum Deaktivieren des Überprüfungsstarts (z. B. vboot 1.0 oder AVB )
    • Ein entsperrter Status, der das fastboot über fastboot (Um sicherzustellen, dass Sie über die neueste Version von fastboot , erstellen Sie diese aus dem Android- fastboot .)
  2. Deaktivieren Sie den Überprüfungsstart.
  3. Löschen Sie die aktuelle Systempartition und flashen Sie die GSI auf die Systempartition.
  4. Löschen Sie die Benutzerdaten und löschen Sie die Daten von anderen erforderlichen Partitionen (z. B. Benutzerdaten und Systempartitionen).
  5. Starte das Gerät neu.

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

  1. fastboot im fastboot Modus und entsperren Sie den Bootloader . Die Geräte, die fastbootd unterstützen, fastbootd außerdem fastbootd durch:
    $ fastboot reboot fastboot
  2. Deaktivieren Sie den Überprüfungsstart (AVB) durch vbmeta.img von vbmeta.img :
    $ fastboot --disable-verification flash vbmeta vbmeta.img
  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 Benutzerdaten und löschen Sie die Daten von anderen erforderlichen Partitionen (z. B. Benutzerdaten und Systempartitionen):
    $ fastboot -w
  5. Neustart:
    $ fastboot reboot
Auf Android 10-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 system_a , z. B. system_a in diesem Beispiel.

Beitrag zu GSIs

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

  • Erstellen eines GSI-Patches. DESSERT -gsi ist kein Entwicklungszweig und akzeptiert nur Cherrypicks aus dem AOSP-Hauptzweig. Um einen GSI-Patch einzureichen, müssen Sie:
    1. Die Patch zum AOSP master - Zweig.
    2. Wählen Sie den Patch für DESSERT -gsi .
    3. Melde einen Fehler an, um den Cherrypick überprüfen zu lassen.
  • GSI-Fehler melden oder andere Vorschläge machen. Lesen Sie die Anweisungen in Fehler melden , dann durchsuchen oder Datei GSI Bugs .

Tipps

Ändern des Navigationsleistenmodus mit adb

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

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

Der mode kann threebutton , zwei twobutton , gestural usw. sein.