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ę:
- 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 . Możesz używać GSI na dowolnym urządzeniu z Androidem, które korzysta z interfejsów dostawców AIDL/HIDL. (Aby uzyskać więcej informacji, zobacz Zasoby dotyczące architektury .)
- System plików. GSI używa systemu plików ext4.
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 docelowejaosp_$arch
jest przeznaczony dla programistów aplikacji na Androida. Plan testówCTS-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
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 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 folderzesystem/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 GSIaosp_$arch_ab
. Zaktualizowanyinit
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
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 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:
- 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).
- Wymaż bieżącą partycję systemową, a następnie sflashuj GSI na partycję systemową.
- Wyczyść dane użytkownika i wyczyść dane z innych niezbędnych partycji (na przykład dane użytkownika i partycje systemowe).
- Uruchom ponownie urządzenie.
Na przykład, aby sflashować GSI na dowolne urządzenie Pixel:
- Uruchom w trybie
fastboot
i odblokuj bootloader . - Urządzenia obsługujące
fastbootd
również wymagają uruchomieniafastbootd
przez:$ fastboot reboot fastboot
- Wymaż i sflashuj GSI na partycję systemową:
$ fastboot erase system $ fastboot flash system system.img
- Wyczyść dane użytkownika i wyczyść dane z innych niezbędnych partycji (na przykład dane użytkownika i partycje systemowe):
$ 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 na partycję systemową. Zapewnia to dodatkowe miejsce na flashowanie GSI:
$ fastboot delete-logical-partition product_aPostfiks
_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:- Prześlij poprawkę do
main
gałęzi AOSP . - Cherrypick poprawkę do
DESSERT -gsi
. - Zgłoś błąd, aby uzyskać przegląd Cherrypick.
- Prześlij poprawkę do
- 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.