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ę:
- Potroić. GSI obejmuje pełną obsługę zmian architektonicznych opartych na AIDL/HIDL (znanych również jako Treble ), w tym obsługę interfejsów AIDL i interfejsów HIDL . Z GSI można korzystać na dowolnym urządzeniu z systemem Android korzystającym z interfejsów dostawców AIDL/HIDL. (Aby uzyskać więcej informacji, zobacz Zasoby dotyczące architektury .)
- System plików. GSI korzysta z systemu plików ext4.
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 docelowejaosp_$arch
jest przechowywany dla twórców aplikacji na Androida. Plan testówCTS-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
zawierauserdebug_plat_sepolicy.cil
. Podczas flashowania specyficznego dla OEMvendor_boot-debug.img
lubboot-debug.img
,/system/bin/init
załadujeuserdebug_plat_sepolicy.cil
z GSIsystem.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 folderzesystem/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 GSIaosp_$arch_ab
. Uaktualnionyinit
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ą korzystać z interfejsów GSI systemu Android 9 w celu 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
iaosp_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. Takie informacje zwykle uzyskiwano z nagłówka obrazu rozruchowego.
W systemie Android 9 i nowszych wersjach wymagania te uległy 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). Aby uzyskać szczegółowe informacje na temat Keymastera, zobacz Magazyn kluczy wspierany sprzętowo .
Pobierz 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.
Buduj 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 zastosować na wszystkich urządzeniach. 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ę:
- 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).
- Usuń bieżącą partycję systemową, a następnie flashuj GSI na partycję systemową.
- Wyczyść dane użytkownika i usuń dane z innych niezbędnych partycji (na przykład danych użytkownika i partycji systemowych).
- Uruchom ponownie urządzenie.
Na przykład, aby sflashować GSI na dowolnym urządzeniu Pixel:
- Uruchom system w trybie
fastboot
i odblokuj bootloader . - Urządzenia obsługujące
fastbootd
również muszą uruchomić się wfastbootd
przez:$ fastboot reboot fastboot
- Usuń i wgraj GSI na partycję systemową:
$ fastboot erase system $ fastboot flash system system.img
- Wyczyść dane użytkownika i usuń dane z innych niezbędnych partycji (na przykład danych użytkownika i partycji systemowych):
$ fastboot -w
- Uruchom ponownie:
$ fastboot reboot
Resizing 'system_a' FAILED (remote: 'Not enough space to resize partition') fastboot: error: Command failedUż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_aPostfix
_a
powinien odpowiadać identyfikatorowi gniazda partycji systemowej, np. system_a
w tym przykładzie.Wnieś swój wkład do 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:- Prześlij łatkę do
main
gałęzi AOSP . - Cherrypick łatka do
DESSERT -gsi
. - Zgłoś błąd, aby umożliwić sprawdzenie wiśniówki.
- Prześlij łatkę do
- 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
Zmień tryb 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.