Ogólne obrazy systemu

Ogólny obraz systemu (GSI) to obraz systemu z dostosowanymi konfiguracjami dla urządzeń z systemem Android. Jest uważany za czystą implementację Androida z niezmodyfikowanym kodem Android Open Source Project (AOSP), którą może pomyślnie uruchomić każde urządzenie z Androidem 9 lub nowszym.

GSI są używane do uruchamiania testów VTS i CTS-on-GSI. Obraz systemu urządzenia z systemem Android jest zastępowany przez GSI, a następnie testowany za pomocą pakietu Vendor Test Suite (VTS) i Compatibility Test Suite (CTS) , aby upewnić się, że urządzenie poprawnie implementuje interfejsy dostawcy z najnowszą wersją Androida.

Aby rozpocząć korzystanie z GSI, przejrzyj poniższe sekcje, aby uzyskać szczegółowe informacje na temat konfiguracji GSI (i dozwolonych odchyleń) oraz typów . Gdy będziesz gotowy do użycia GSI, pobierz i zbuduj GSI dla swojego urządzenia docelowego, a następnie sflashuj GSI na urządzenie z Androidem.

Konfiguracja i wariancje GSI

Bieżący system Android GSI ma następującą konfigurację:

Bieżący Android GSI zawiera następujące główne różnice:

  • Architektura procesora. Obsługa różnych instrukcji procesora (ARM, x86 itp.) i bitowości procesora (32-bitowy lub 64-bitowy).

Cele GSI dla testów zgodności Treble

GSI używany do testowania zgodności jest określany na podstawie wersji Androida, z którą urządzenie jest uruchamiane.

Rodzaj urządzenia Zbuduj cel
Urządzenia uruchamiane z systemem Android 12 gsi_$arch-user (podpisany)
Urządzenia uruchamiane z systemem Android 11 gsi_$arch-user (podpisany)
Urządzenia uruchamiane z systemem Android 10 gsi_$arch-user (podpisany)
Urządzenia uruchamiane z systemem Android 9 gsi_$arch-userdebug

Wszystkie GSI są zbudowane z bazy kodu systemu Android 12, a każda architektura procesora ma odpowiedni plik binarny GSI (zobacz listę celów kompilacji w Budowanie GSI ).

Zmiany GSI w Androidzie 12

Urządzenia uruchamiane z systemem Android 12 lub aktualizowane do niego muszą używać interfejsów GSI systemu Android 12 do testowania zgodności. Obejmuje to następujące główne zmiany w stosunku do wcześniejszych GSI:

  • Nazwa celu. Nazwa docelowa GSI dla testów zgodności została zmieniona na gsi_$arch . GSI o nazwie docelowej aosp_$arch jest przeznaczony dla programistów aplikacji na Androida. Plan testów CTS-on-GSI jest również zredukowany do testowania interfejsu dostawcy.
  • Starsze GSI jest wycofywane. GSI 12 usuwa obejścia obsługujące urządzenia z Androidem 8.0 lub 8.1, które nie są w pełni Treblizowane.
  • Userdebug SEPolicy. GSI gsi_$arch zawiera userdebug_plat_sepolicy.cil . Podczas flashowania specyficznego dla OEM vendor_boot-debug.img lub boot-debug.img , /system/bin/init załaduje userdebug_plat_sepolicy.cil z GSI system.img . Aby uzyskać szczegółowe informacje, zapoznaj się z testowaniem VTS z ramdyskiem debugowania .

Zmiany GSI w Androidzie 11

Urządzenia uruchamiane z systemem Android 11 lub aktualizowane do niego muszą używać interfejsów GSI systemu Android 11 do testowania zgodności. Obejmuje to następujące główne zmiany w stosunku do wcześniejszych GSI:

  • zawartość system_ext. Android 11 definiuje nową partycję system_ext . GSI umieszcza zawartość rozszerzenia systemowego w folderze system/system_ext .
  • APEXy. GSI zawiera zarówno spłaszczone, jak i skompresowane wierzchołki. Którego użyć, określa właściwość systemowa ro.apex.updatable w partycji dostawcy w czasie wykonywania. Odniesienie Konfigurowanie systemu do obsługi aktualizacji APEX, aby uzyskać szczegółowe informacje.

Zmiany GSI w Androidzie 10

Urządzenia uruchamiane z systemem Android 10 lub aktualizowane do niego muszą używać GSI systemu Android 10 do testowania zgodności. Obejmuje to następujące główne zmiany w stosunku do wcześniejszych GSI:

  • Budowa użytkownika. GSI ma kompilację użytkownika z systemu Android 10. W systemie Android 10 kompilacja GSI użytkownika może być używana w testach zgodności CTS-on-GSI/VTS. Aby uzyskać szczegółowe informacje, zapoznaj się z testowaniem VTS z ramdyskiem debugowania .
  • Niesparowany format. GSI z celami aosp_$arch są zbudowane w formacie unsparsed. Możesz użyć img2simg , aby w razie potrzeby przekonwertować niesparowany GSI na format rzadki.
  • System jako root. Starszy cel kompilacji GSI o nazwie aosp_$arch_a został wycofany. W przypadku urządzeń uaktualnionych z Androida 8 lub 8.1 do Androida 10 z ramdyskiem i nie-system-as-root użyj starszego GSI aosp_$arch_ab . Zaktualizowany init w ramdysku obsługuje OEM system.img z układem system-as-root.
  • Sprawdź rozruch. Korzystając z GSI wystarczy odblokować urządzenie. Nie trzeba wyłączać weryfikacji rozruchu.

Zmiany GSI w Androidzie 9

Urządzenia uruchamiane z systemem Android 9 lub aktualizowane do niego muszą używać interfejsów GSI systemu Android 9 do testowania zgodności. Obejmuje to następujące główne zmiany w stosunku do wcześniejszych GSI:

  • Łączy GSI i emulator. GSI są zbudowane z obrazów systemowych produktów emulujących, na przykład aosp_arm64 i aosp_x86 .
  • System jako root. W poprzednich wersjach Androida urządzenia, które nie obsługiwały aktualizacji A/B, mogły montować obraz systemu w katalogu /system . W systemie Android 9 katalog główny obrazu systemu jest montowany jako katalog główny urządzenia.
  • 64-bitowy interfejs bindera. W systemie Android 8.x 32-bitowe GSI używały 32-bitowego interfejsu bindera. Android 9 nie obsługuje 32-bitowego interfejsu bindera, więc zarówno 32-bitowe GSI, jak i 64-bitowe GSI używają 64-bitowego interfejsu bindera.
  • Egzekwowanie VNDK. W Androidzie 8.1 VNDK było opcjonalne. Począwszy od Androida 9, VNDK jest obowiązkowe, więc należy ustawić BOARD_VNDK_VERSION .
  • Kompatybilna właściwość systemu. Android 9 umożliwia sprawdzenie dostępu pod kątem zgodnej właściwości systemowej ( PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true ).

Zmiany w kluczu Androida 9

We wcześniejszych wersjach Androida urządzenia z wdrożoną wersją Keymaster 3 lub starszą musiały sprawdzać, czy informacje o wersji ( ro.build.version.release i ro.build.version.security_patch ) zgłaszane przez uruchomiony system są zgodne z informacjami o wersji zgłaszanymi przez program ładujący. Takie informacje były zwykle uzyskiwane z nagłówka obrazu rozruchowego.

W systemie Android 9 i nowszych wymaganie to zostało zmienione, aby umożliwić dostawcom uruchamianie GSI. W szczególności Keymaster nie powinien przeprowadzać weryfikacji, ponieważ informacje o wersji zgłaszane przez GSI mogą nie zgadzać się z informacjami o wersji zgłaszanymi przez program ładujący dostawcy. W przypadku urządzeń z wdrożoną wersją Keymaster 3 lub starszą dostawcy muszą zmodyfikować implementację Keymaster, aby pominąć weryfikację (lub dokonać aktualizacji do wersji Keymaster 4). Aby uzyskać szczegółowe informacje na temat modułu Keymaster, zapoznaj się ze sprzętowym magazynem kluczy .

Pobieranie GSI

Gotowe GSI można pobrać z witryny AOSP Continuous Integration (CI) pod adresem ci.android.com . Jeśli typ GSI dla Twojej platformy sprzętowej jest niedostępny do pobrania, zapoznaj się z następną sekcją, aby uzyskać szczegółowe informacje na temat tworzenia GSI dla określonych celów.

Budowa GSI

Począwszy od systemu Android 9, każda wersja systemu Android ma gałąź GSI o nazwie DESSERT -gsi w AOSP (na przykład android12-gsi to gałąź GSI w systemie Android 12). Gałęzie GSI obejmują zawartość Androida ze wszystkimi zastosowanymi poprawkami bezpieczeństwa i poprawkami GSI .

Aby zbudować GSI, skonfiguruj drzewo źródłowe Androida, pobierając je z gałęzi GSI i wybierając cel kompilacji GSI . Skorzystaj z poniższych tabel docelowych kompilacji, aby określić poprawną wersję GSI dla swojego urządzenia. Po zakończeniu kompilacji GSI jest obrazem systemu (czyli system.img ) i pojawia się w folderze wyjściowym out/target/product/ generic_arm64 .

Na przykład, aby zbudować cel kompilacji GSI gsi_arm64-userdebug w gałęzi GSI android12-gsi , uruchom następujące polecenia.

$ 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

Cele kompilacji Androida GSI

Poniższe cele kompilacji GSI dotyczą urządzeń z systemem Android 9 lub nowszym.

nazwa GSI łuk procesora Liczba bitów interfejsu programu Binder System jako root Zbuduj cel
gsi_arm RAMIĘ 64 Y gsi_arm-user
gsi_arm-userdebug
gsi_arm64 ARM64 64 Y gsi_arm64-user
gsi_arm64-userdebug
gsi_x86 x86 64 Y gsi_x86-user
gsi_x86-userdebug
gsi_x86_64 x86-64 64 Y gsi_x86_64-user
gsi_x86_64-userdebug

Wymagania dotyczące flashowania GSI

Urządzenia z Androidem mogą mieć różne projekty, więc nie ma ogólnego polecenia ani zestawu instrukcji dotyczących flashowania GSI, które można zastosować do wszystkich urządzeń. Skontaktuj się z producentem urządzenia z systemem Android, aby uzyskać szczegółowe instrukcje dotyczące flashowania. Użyj następujących kroków jako ogólnej wskazówki:

  1. Upewnij się, że urządzenie ma następujące elementy:
    • Treblizowany
    • Metoda odblokowywania urządzeń (aby można je było sflashować za pomocą fastboot )
    • Stan odblokowany, aby umożliwić flashowanie przez fastboot (Aby mieć pewność, że masz najnowszą wersję fastboot , zbuduj ją z drzewa źródeł Androida).
  2. Wymaż bieżącą partycję systemową, a następnie sflashuj GSI na partycję systemową.
  3. Wyczyść dane użytkownika i wyczyść dane z innych niezbędnych partycji (na przykład dane użytkownika i partycje systemowe).
  4. Uruchom ponownie urządzenie.

Na przykład, aby sflashować GSI na dowolne urządzenie Pixel:

  1. Uruchom w trybie fastboot i odblokuj bootloader .
  2. Urządzenia obsługujące fastbootd również wymagają uruchomienia fastbootd przez:
    $ fastboot reboot fastboot
  3. Wymaż i sflashuj GSI na partycję systemową:
    $ fastboot erase system
$ fastboot flash system system.img
  4. Wyczyść dane użytkownika i wyczyść dane z innych niezbędnych partycji (na przykład dane użytkownika i partycje systemowe):
    $ fastboot -w
  5. Uruchom ponownie:
    $ fastboot reboot
Na urządzeniach z systemem Android 10 lub nowszym, które mają mniejsze partycje systemowe, podczas flashowania GSI może pojawić się następujący komunikat o błędzie:
    Resizing 'system_a'    FAILED (remote: 'Not enough space to resize partition')
    fastboot: error: Command failed
Użyj następującego polecenia, aby usunąć partycję produktu i zwolnić miejsce na partycję systemową. Zapewnia to dodatkowe miejsce na flashowanie GSI:
$ fastboot delete-logical-partition product_a
Postfiks _a powinien pasować do identyfikatora gniazda partycji systemowej, na przykład system_a w tym przykładzie.

Wkład w GSI

Android z zadowoleniem przyjmuje Twój wkład w rozwój GSI. Możesz się zaangażować i pomóc ulepszyć GSI poprzez:

  • Tworzenie poprawki GSI. DESSERT -gsi nie jest gałęzią rozwojową i akceptuje tylko wykałaczki z głównej gałęzi AOSP, więc aby przesłać łatkę GSI, musisz:
    1. Prześlij poprawkę do main gałęzi AOSP .
    2. Cherrypick poprawkę do DESSERT -gsi .
    3. Zgłoś błąd, aby uzyskać przegląd Cherrypick.
  • Zgłaszanie błędów GSI lub zgłaszanie innych sugestii. Zapoznaj się z instrukcjami w sekcji Zgłaszanie błędów , a następnie przejrzyj lub zgłoś błędy GSI .

Porady

Zmiana trybu paska nawigacji za pomocą adb

Podczas uruchamiania z GSI tryb paska nawigacyjnego jest konfigurowany przez zastąpienie dostawcy. Możesz zmienić tryb paska nawigacji, uruchamiając następujące polecenie adb w czasie wykonywania.

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

Gdzie mode może mieć wartość threebutton , twobutton , gestural i tak dalej.