Ogólne obrazy systemu

Ogólny obraz systemu (GSI) to obraz systemu z dostosowanymi konfiguracjami dla urządzeń z systemem Android. Uważa się, że jest to czysta implementacja systemu Android z niezmodyfikowanym kodem projektu Android Open Source Project (AOSP), na którym może pomyślnie działać każde urządzenie z systemem Android z systemem Android 9 lub nowszym.

GSI służą do przeprowadzania testów VTS i CTS-on-GSI. Obraz systemu urządzenia z Androidem zostaje zastąpiony GSI, a następnie przetestowany za pomocą pakietu Vendor Test Suite (VTS) i pakietu Compatibility Test Suite (CTS) , aby upewnić się, że urządzenie poprawnie implementuje interfejsy dostawcy w najnowszej wersji Androida.

Aby rozpocząć korzystanie z GSI, przejrzyj poniższe sekcje, aby uzyskać szczegółowe informacje na temat konfiguracji GSI (i dozwolonych odchyleń) i typów . Gdy wszystko będzie gotowe do użycia GSI, pobierz i skompiluj GSI dla swojego urządzenia docelowego, a następnie prześlij GSI na urządzenie z systemem Android.

Konfiguracja i odchylenia GSI

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

Obecny system 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 zależy od wersji Androida, z którą uruchamia się urządzenie.

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 Androida 12, a każda architektura procesora ma odpowiedni plik binarny GSI (zobacz listę celów kompilacji w Budowanie GSI ).

Zmiany w Androidzie 12 GSI

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 docelowa. Nazwa docelowa GSI dla testów zgodności została zmieniona na gsi_$arch . GSI o nazwie docelowej aosp_$arch jest przechowywany dla twórców aplikacji na Androida. Plan testów CTS-on-GSI jest również ograniczony w celu testowania interfejsu dostawcy.
  • Starsza wersja GSI jest wycofywana. 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 pliku vendor_boot-debug.img lub boot-debug.img , /system/bin/init załaduje userdebug_plat_sepolicy.cil z GSI system.img . Aby poznać szczegóły, odwołaj się do Testowania VTS z dyskiem debugującym .

Zmiany w Androidzie 11 GSI

Urządzenia uruchamiane z systemem Android 11 lub aktualizowane do niego muszą używać identyfikatoró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 APEX. To, którego użyć, określa właściwość systemowa ro.apex.updatable na partycji dostawcy w czasie wykonywania. Aby uzyskać szczegółowe informacje, zobacz Konfigurowanie systemu do obsługi aktualizacji APEX .

Zmiany w Androidzie 10 GSI

Urządzenia uruchamiane z systemem Android 10 lub aktualizowane do niego 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:

  • Budowa użytkownika. GSI ma wersję użytkownika z systemu Android 10. W systemie Android 10 kompilację użytkownika GSI można używać w testach zgodności CTS-on-GSI/VTS. Aby uzyskać szczegółowe informacje, zobacz Testowanie VTS z dyskiem debugującym .
  • Nieparzysty format. GSI z celami aosp_$arch są zbudowane w formacie niesparsowanym. Jeśli to konieczne, możesz użyć img2simg , aby przekonwertować niesparsowany GSI na format rozrzedzony.
  • System jako root. Starsza wersja docelowa kompilacji GSI o nazwie aosp_$arch_a została wycofana. W przypadku urządzeń zaktualizowanych z Androida 8 lub 8.1 do Androida 10 z ramdyskiem i systemem innym niż root, użyj starszego GSI aosp_$arch_ab . Uaktualniony plik init w ramdysku obsługuje plik OEM system.img z układem system-as-root.
  • Sprawdź rozruch. Korzystając z GSI wystarczy jedynie odblokować urządzenie. Wyłączanie weryfikacji rozruchu nie jest konieczne.

Zmiany w Androidzie 9 GSI

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 segregatora. W systemie Android 8.x 32-bitowe GSI korzystały z 32-bitowego interfejsu spoiwa. Android 9 nie obsługuje 32-bitowego interfejsu segregatora, więc zarówno 32-bitowe, jak i 64-bitowe GSI korzystają z 64-bitowego interfejsu segregatora.
  • Egzekucja VNDK. W Androidzie 8.1 VNDK był opcjonalny. Począwszy od Androida 9, VNDK jest obowiązkowe, dlatego należy ustawić BOARD_VNDK_VERSION .
  • Zgodna właściwość systemu. Android 9 umożliwia sprawdzenie dostępu do kompatybilnej właściwości systemu ( PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true ).

Zmiany w Keymasterze Androida 9

We wcześniejszych wersjach Androida urządzenia z implementacją Keymaster 3 lub niższą 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 program ładujący. Informacje takie zwykle uzyskiwano z nagłówka obrazu rozruchowego.

W Androidzie 9 i nowszych wymaganie to uległo zmianie, aby umożliwić dostawcom uruchamianie GSI. W szczególności Keymaster nie powinien przeprowadzać weryfikacji, ponieważ informacje o wersji zgłoszone przez GSI mogą nie zgadzać się z informacjami o wersji zgłoszonymi przez program ładujący dostawcy. W przypadku urządzeń z implementacją Keymaster 3 lub niższą, dostawcy muszą zmodyfikować implementację Keymaster, aby pominąć weryfikację (lub uaktualnić do Keymaster 4). Szczegółowe informacje na temat Keymastera można znaleźć w artykule Magazyn kluczy wspierany sprzętowo .

Pobieranie GSI

Gotowe moduły GSI można pobrać z witryny 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.

Budowanie 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 Androidzie 12). Gałęzie GSI obejmują zawartość Androida ze wszystkimi zastosowanymi poprawkami bezpieczeństwa i poprawkami GSI .

Aby zbudować GSI, skonfiguruj drzewo źródeł 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 (tzn. system.img ) i pojawia się w folderze wyjściowym out/target/product/ generic_arm64 .

Na przykład, aby zbudować obiekt docelowy 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 Bitowość interfejsu Bindera 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 konstrukcje, więc nie ma ogólnego polecenia ani zestawu instrukcji dotyczących flashowania GSI, które można byłoby zastosować do wszystkich urządzeń. Skontaktuj się z producentem urządzenia z systemem Android, aby uzyskać szczegółowe instrukcje dotyczące flashowania. Poniższe kroki stanowią ogólną wskazówkę:

  1. Upewnij się, że urządzenie posiada następujące elementy:
    • Potrojony
    • Metoda odblokowywania urządzeń (aby można było je flashować za pomocą fastboot )
    • Stan odblokowania umożliwiający flashowanie przez fastboot (aby mieć pewność, że masz najnowszą wersję fastboot , zbuduj ją z drzewa źródłowego Androida).
  2. Usuń bieżącą partycję systemową, a następnie flashuj 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 na dowolnym urządzeniu Pixel:

  1. Uruchom system w trybie fastboot i odblokuj bootloader .
  2. Urządzenia obsługujące fastbootd również muszą uruchomić się w fastbootd przez:
    $ fastboot reboot fastboot
  3. Usuń i wgraj 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 Androidem 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 dla partycji systemowej. Zapewnia to dodatkową przestrzeń do flashowania GSI:
$ fastboot delete-logical-partition product_a
Postfix _a powinien odpowiadać identyfikatorowi gniazda partycji systemowej, np. system_a w tym przykładzie.

Wkład w GSI

Android z radością przyjmie Twój wkład w rozwój GSI. Możesz zaangażować się i pomóc ulepszyć GSI poprzez:

  • Tworzenie łatki GSI. DESSERT -gsi nie jest gałęzią rozwojową i akceptuje tylko wiśniówki z głównej gałęzi AOSP, więc aby przesłać łatkę GSI, musisz:
    1. Prześlij łatkę do main gałęzi AOSP .
    2. Cherrypick łatka do DESSERT -gsi .
    3. Zgłoś błąd, aby umożliwić sprawdzenie wiśniówki.
  • Zgłaszanie błędów GSI lub zgłaszanie innych sugestii. Przejrzyj instrukcje w części 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 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 być threebutton , twobutton , gestural i tak dalej.