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ę systemu Android z niezmodyfikowanym kodem projektu Android Open Source Project (AOSP), który można pomyślnie uruchomić na dowolnym urządzeniu z systemem Android 9 lub nowszym.

GSI są używane do przeprowadzania 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ą systemu Android.

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

Konfiguracja i wariancje GSI

Obecny Android GSI ma następującą konfigurację:

Obecny Android GSI obejmuje następujące główne warianty:

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

Cele GSI dla testów zgodności Treble

GSI używany do testowania zgodności zależy od 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ą budowane na podstawie kodu Android 12, a każda architektura procesora ma odpowiedni plik binarny GSI (zobacz listę celów kompilacji w Building GSI ).

Zmiany w Androidzie 12 GSI

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

  • Nazwa docelowa. Nazwa docelowa GSI dla testów zgodności została zmieniona na gsi_$arch . GSI o nazwie docelowej aosp_$arch jest zachowywany dla programistów aplikacji na Androida. Plan testów CTS-on-GSI jest również ograniczony do testowania interfejsu dostawcy.
  • Starsze GSI jest wycofywane. GSI 12 usuwa obejścia dotyczące urządzeń z Androidem 8.0 lub 8.1, które nie są w pełni potreblizowane.
  • Polityka SEPolityka debugowania użytkownika. 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 debugowaniem Ramdisk .

Zmiany w Androidzie 11 GSI

Urządzenia uruchamiane z systemem Android 11 lub aktualizowane do tego systemu muszą używać 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 .
  • APEX. GSI zawiera zarówno spłaszczone, jak i skompresowane pliki APEX. To, którego użyć, zależy od właściwości systemowej ro.apex.updatable w partycji dostawcy w czasie wykonywania. Szczegółowe informacje można znaleźć w sekcji Konfiguracja systemu do obsługi aktualizacji APEX .

Zmiany w Androidzie 10 GSI

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

  • Kompilacja użytkownika. GSI ma kompilację użytkownika z Androida 10. W Androidzie 10, kompilacja użytkownika GSI może być używana w testach zgodności CTS-on-GSI/VTS. Aby uzyskać szczegółowe informacje, zapoznaj się z testowaniem VTS z debugowaniem Ramdisk .
  • Niesparowany format. GSI z celami aosp_$arch są budowane w niesparsowanym formacie. Możesz użyć img2simg , aby przekonwertować niesparsowany GSI na format sparse, jeśli to konieczne.
  • 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 bez systemu jako root użyj starszego GSI aosp_$arch_ab . Ulepszony init w ramdysku obsługuje OEM system.img z układem system-as-root.
  • Sprawdź rozruch. Korzystając z GSI wystarczy tylko odblokować urządzenie. Nie ma potrzeby wyłączania weryfikacji rozruchu.

Zmiany w Androidzie 9 GSI

Urządzenia uruchamiane z systemem Android 9 lub aktualizowane do niego muszą używać 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ą budowane na podstawie obrazów systemu produktów emulujących, na przykład aosp_arm64 i aosp_x86 .
  • System jako root. W poprzednich wersjach systemu Android 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ł opcjonalny. Począwszy od Androida 9, VNDK jest obowiązkowe, więc musi być ustawione BOARD_VNDK_VERSION .
  • Zgodna właściwość systemu. Android 9 umożliwia sprawdzenie dostępu dla zgodnej właściwości systemowej ( PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true ).

Zmiany w systemie Android 9 Keymaster

We wcześniejszych wersjach Androida urządzenia implementujące Keymaster 3 lub starsze musiały sprawdzić, czy informacje o wersji ( ro.build.version.release i ro.build.version.security_patch ) zgłoszone przez działający system są zgodne z informacjami o wersji zgłoszonymi przez bootloader. 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 bootloader dostawcy. W przypadku urządzeń z implementacją Keymaster 3 lub starszej dostawcy muszą zmodyfikować implementację Keymaster, aby pominąć weryfikację (lub uaktualnić do Keymaster 4). Aby uzyskać szczegółowe informacje na temat Keymaster, zobacz Magazyn kluczy wspierany sprzętowo .

Pobieranie GSI

Gotowe dane GSI można pobrać ze strony internetowej 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 poniższą sekcją, aby uzyskać szczegółowe informacje na temat tworzenia GSI dla określonych celów.

Budynek GSI

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

Aby zbudować GSI, skonfiguruj drzewo źródłowe Androida, pobierając 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ć obiekt GSI build target 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ń uruchamianych z systemem Android 9 lub nowszym.

Nazwa GSI Łuk procesora Bitowość interfejsu 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 systemem Android mogą mieć różne konstrukcje, więc nie ma ogólnych poleceń ani zestawu instrukcji dotyczących flashowania GSI, które można by zastosować do wszystkich urządzeń. Skontaktuj się z producentem urządzenia z systemem Android, aby uzyskać wyraźne instrukcje dotyczące flashowania. Użyj następujących kroków jako ogólnych wskazówek:

  1. Upewnij się, że urządzenie posiada:
    • Potrójny
    • Metoda odblokowywania urządzeń (aby można je było sflashować za pomocą fastboot )
    • Stan odblokowany, aby można go było flashować za pomocą fastboot (Aby upewnić się, że masz najnowszą wersję fastboot , skompiluj ją z drzewa źródłowego Androida).
  2. Usuń bieżącą partycję systemową, a następnie sflashuj GSI na partycję systemową.
  3. Wyczyść dane użytkownika i usuń dane z innych niezbędnych partycji (na przykład danych użytkownika i partycji systemowych).
  4. Uruchom ponownie urządzenie.

Na przykład, aby sflashować GSI do dowolnego urządzenia Pixel:

  1. Uruchom w trybie fastboot i odblokuj bootloader .
  2. Urządzenia obsługujące fastbootd również muszą zostać uruchomione w 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 usuń dane z innych niezbędnych partycji (na przykład danych użytkownika i partycji systemowych):
    $ fastboot -w
  5. Uruchom ponownie:
    $ fastboot reboot
Na urządzeniach z systemem Android 10 lub nowszych, 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 odpowiadać identyfikatorowi gniazda partycji systemowej, na przykład system_a w tym przykładzie.

Wkład w GSI

Android wita 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ą programistyczną i akceptuje tylko cherrypicki z gałęzi master AOSP, więc aby przesłać łatkę GSI, należy:
    1. Prześlij poprawkę do master gałęzi AOSP .
    2. Cherrywybierz łatkę do DESSERT -gsi .
    3. Zgłoś błąd, aby zrecenzować 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 przeglądaj lub zgłaszaj błędy GSI .

Porady

Zmiana trybu paska nawigacji za pomocą adb

Podczas uruchamiania z GSI tryb paska nawigacji jest konfigurowany przez nadpisanie dostawcy. Tryb paska nawigacji można zmienić, 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 być threebutton , twobutton , gestural i tak dalej.