Google jest zaangażowany w promowanie równości rasowej dla społeczności czarnych. Zobacz jak.
Ta strona została przetłumaczona przez Cloud Translation API.
Switch to English

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 Androida z niezmodyfikowanym kodem Android Open Source Project (AOSP), którą można pomyślnie uruchomić na każdym urządzeniu z Androidem 8.1 lub nowszym.

GSI są używane do przeprowadzania testów VTS i CTS-on-GSI. Obraz systemu urządzenia z Androidem jest zastępowany przez GSI, a następnie testowany za pomocą Vendor Test Suite (VTS) i Compatibility Test Suite (CTS), aby upewnić się, że urządzenie prawidłowo 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 dopuszczalnych odchyleń), typów (Android GSI i Legacy GSI) oraz plików binarnych dostawców i zależności VNDK . Kiedy będziesz gotowy do korzystania z GSI, pobierz i skompiluj GSI dla urządzenia docelowego, a następnie sflashuj GSI na urządzenie z Androidem.

Konfiguracja i wariancje GSI

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

  • Potroić. GSI obejmuje pełną obsługę zmian architektonicznych opartych na HIDL (znanych również jako Treble ) wprowadzonych w systemie Android 8.0, w tym obsługę interfejsów HIDL . Możesz używać GSI na dowolnym urządzeniu z Androidem, które korzysta z interfejsów dostawców HIDL. (Aby uzyskać więcej informacji, zobacz zasoby dotyczące architektury) .
  • Sprawdź rozruch. GSI nie zawiera rozwiązania do weryfikacji rozruchu (takiego jak vboot 1.0 lub AVB ). Aby sflashować GSI do urządzenia uruchamianego w systemie Android 9 lub starszym, urządzenie musi mieć metodę wyłączania weryfikacji rozruchu.
  • System plików. GSI korzysta z systemu plików ext4.
  • Układ partycji. GSI używa układu partycji system-as-root .

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-bitowy lub 64-bitowy).

Cele GSI dla testów zgodności Treble

Wskaźnik 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 10 aosp_$arch-user
Urządzenia uruchamiane z systemem Android 9 aosp_$arch-userdebug
Urządzenia uruchamiane z systemem Android 8.0 lub Android 8.1 aosp_$arch_ab-userdebug

Wszystkie GSI są zbudowane na podstawie kodu systemu Android 10, a każda architektura procesora ma odpowiedni plik binarny GSI (zobacz listę celów kompilacji w sekcji GSI budynku ).

Zmiany w Androidzie 10 GSI

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

  • Wersja użytkownika. GSI ma wersję użytkownika z Androidem 10. W systemie Android 10, kompilacja użytkownika GSI może być używana do testowania zgodności CTS-on-GSI / VTS. Aby uzyskać szczegółowe informacje, zapoznaj się z testowaniem VTS z Debug Ramdisk .
  • Niesparowany format. GSI z celami aosp_$arch są zbudowane w formacie nierozliczonym. W razie potrzeby możesz użyć img2simg aby przekonwertować nierozdzielony GSI na format rzadki.
  • System jako root. aosp_$arch_a wersja docelowa GSI o nazwie aosp_$arch_a została wycofana. W przypadku urządzeń zaktualizowanych z systemu Android 8 lub 8.1 do systemu Android 10 z ramdyskiem i bez systemu jako root użyj starszej wersji GSI aosp_$arch_ab . Zaktualizowany init w ramdysku obsługuje OEM system.img z układem system-as-root.

Aby przetestować urządzenia uruchamiane w systemie Android 9 lub 10 z CTS-on-GSI, użyj celów kompilacji Android GSI .

Starsza wersja GSI

Starsze GSI o nazwie z przyrostkiem _ab (na przykład aosp_arm64_ab ). Te GSI są zbudowane na podstawie drzewa źródłowego systemu Android 10, ale zawierają następujące wstecznie zgodne konfiguracje dla urządzeń zaktualizowanych z systemu Android 8 lub 8.1:

  • 32-bitowa przestrzeń użytkownika + 32-bitowy interfejs segregatora. 32-bitowe GSI mogą nadal korzystać z 32-bitowego interfejsu segregatora.
  • 8.1 VNDK. Urządzenia mogą korzystać z dołączonego VNDK 8.1.
  • Zamontuj katalogi. Niektóre starsze urządzenia używają katalogów jako wskaźników montowania (na przykład /bluetooth , /firmware/radio i /persist ).

Aby przetestować urządzenia uruchamiane w systemie Android 8 lub 8.1 z CTS-on-GSI, użyj celów kompilacji Legacy GSI .

Zmiany GSI w Androidzie 9

GSI systemu Android 9 zawierają następujące główne zmiany w stosunku do wcześniejszych GSI:

  • Łączy GSI i emulator. GSI są zbudowane z obrazów systemu produktów emulatorów, 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 /system 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 segregatora. Android 9 nie obsługuje 32-bitowego interfejsu segregatora, więc zarówno 32-bitowe GSI, jak i 64-bitowe GSI używają 64-bitowego interfejsu segregatora.
  • Egzekwowanie VNDK. W systemie Android 8.1 VNDK był opcjonalny. Począwszy od Androida 9, VNDK jest obowiązkowe, więc należy ustawić 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 były wymagane do sprawdzenia, czy informacje o wersji ( ro.build.version.release i ro.build.version.security_patch ) zgłaszane przez działający 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 uległo zmianie, 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 odpowiadać informacjom o wersji zgłaszanym przez program ładujący producenta. W przypadku urządzeń wdrażających Keymaster 3 lub niższy, dostawcy muszą zmodyfikować implementację Keymaster, aby pominąć weryfikację (lub zaktualizować do Keymaster 4). Szczegółowe informacje na temat Keymaster można znaleźć w sekcji Magazyn kluczy wspierany sprzętowo .

Pliki binarne dostawców i zależności VNDK

Urządzenia aktualizujące do systemu Android 10 mają różne ścieżki aktualizacji w zależności od wersji plików binarnych dostawcy używanych na urządzeniu i konfiguracji związanych z VNDK użytych do zbudowania urządzenia. Poniższa tabela zawiera podsumowanie starszej obsługi GSI dla zmodernizowanych urządzeń.

Przypadek użycia Sprzedawca
pliki binarne
wersja
BOARD_VNDK_VERSION Starsza wersja GSI
wersja plików binarnych systemu
Obsługa starszych systemów GSI
0 8.0 (każdy) 10 Nie
1 8.1 (pusty) 10 Nie
2 8.1 current 10 tak
3 10 current 10 tak

Najczęstszym obsługiwanym przypadkiem użycia jest # 2, gdzie starsze GSI obsługują urządzenia z systemem Android 8.1, które zostały zbudowane z ustawieniem BOARD_VNDK_VERSION na current .

Przypadek nr 1 nie jest obsługiwany. W tym przypadku starsze GSI NIE obsługują urządzeń z systemem Android 8.1, w których BOARD_VNDK_VERSION jest pominięty w kompilacji. Te urządzenia nie mogą być obsługiwane, ponieważ ich pliki binarne dostawców zależą od udostępnionych bibliotek systemu Android 8.1 innych niż VNDK, które nie są uwzględnione w starszych GSI. Aby zapewnić zgodność tych urządzeń ze starszą wersją GSI, należy wykonać jedną z następujących czynności:

  • Włącz BOARD_VNDK_VERSION bez BOARD_VNDK_RUNTIME_DISABLE (przypadek użycia nr 2).

    LUB

  • Przenieś / zaktualizuj pliki binarne dostawcy, aby były zależne od bibliotek współdzielonych z systemu Android 10 (przypadek użycia nr 3).

Pobieranie GSI

Możesz pobrać wstępnie skompilowane GSI z witryny ciągłej integracji AOSP (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 na AOSP (na przykład android10-gsi to gałąź GSI w systemie Android 10). Oddziały GSI obejmują zawartość systemu Android ze wszystkimi zastosowanymi poprawkami zabezpieczeń i łatkami 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 celów kompilacji, aby określić właściwą wersję GSI dla swojego urządzenia. Po zakończeniu kompilacji GSI jest obrazem systemu (to jest system.img ) i pojawia się w folderze wyjściowym out/target/product/ generic_arm64 . vbmeta.img wyświetla również vbmeta.img , którego można użyć do wyłączenia weryfikacji rozruchu na urządzeniach z systemem Android Verified Boot .

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

$ repo init -u https://android.googlesource.com/platform/manifest -b android10-gsi
$ repo sync -cq
$ source build/envsetup.sh
$ lunch aosp_arm64-userdebug
$ make -j4

Cele kompilacji Android GSI

Poniższe cele kompilacji GSI dotyczą urządzeń uruchamianych w systemie Android 9 lub nowszym. Ze względu na zmniejszenie rozbieżności między architekturami system Android 10 zawiera tylko cztery produkty GSI.

Nazwa GSI Łuk procesora Bitowość interfejsu Binder System jako root Zbuduj cel
aosp_arm RAMIĘ 64 Y aosp_arm-user
aosp_arm-userdebug
aosp_arm64 ARM64 64 Y aosp_arm64-user
aosp_arm64-userdebug
aosp_x86 x86 64 Y aosp_x86-user
aosp_x86-userdebug
aosp_x86_64 x86-64 64 Y aosp_x86_64-user
aosp_x86_64-userdebug

Starsze cele kompilacji GSI

Następujące starsze cele kompilacji GSI są przeznaczone dla urządzeń aktualizowanych z systemu Android 8.0 lub 8.1 do systemu Android 10. Starsze nazwy GSI zawierają przyrostek _ab aby odróżnić je od nazw GSI systemu Android 10.

Nazwa GSI Łuk procesora Bitowość interfejsu Binder System jako root Zbuduj cel
aosp_arm_ab RAMIĘ 32 Y aosp_arm_ab-userdebug
aosp_arm_64b_ab RAMIĘ 64 Y aosp_arm_64b_ab-userdebug
aosp_arm64_ab ARM64 64 Y aosp_arm64_ab-userdebug
aosp_x86_ab x86 32 Y aosp_x86_ab-userdebug
aosp_x86_64_ab x86-64 64 Y aosp_x86_64_ab-userdebug

Wymagania dotyczące flashowania GSI

Urządzenia z systemem Android mogą mieć różne konstrukcje, więc nie ma ogólnego polecenia ani zestawu instrukcji dotyczących flashowania GSI do zastosowania na wszystkich urządzeniach. Skontaktuj się z producentem urządzenia z systemem Android, aby uzyskać wyraźne instrukcje dotyczące flashowania. Postępuj zgodnie z następującymi krokami jako ogólną wskazówką:

  1. Upewnij się, że urządzenie ma:
    • Treblized
    • Metoda odblokowywania urządzeń (aby można je było flashować za pomocą fastboot )
    • Metoda wyłączania weryfikacji rozruchu (na przykład vboot 1.0 lub AVB )
    • Odblokowany stan umożliwiający flashowanie przez fastboot (aby upewnić się, że masz najnowszą wersję fastboot , fastboot ją z drzewa źródłowego Androida).
  2. Wyłącz weryfikację rozruchu.
  3. Usuń bieżącą partycję systemową, a następnie flashuj GSI na partycję systemową.
  4. Wyczyść dane użytkownika i usuń dane z innych niezbędnych partycji (na przykład dane użytkownika i partycje systemowe).
  5. Uruchom ponownie urządzenie.

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

  1. Uruchom w trybie fastboot i odblokuj bootloader . Urządzenia obsługujące fastbootd również muszą zostać uruchomione w fastbootd przez:
    $ fastboot reboot fastboot
  2. Wyłącz weryfikację rozruchu (AVB), vbmeta.img :
    $ fastboot --disable-verification flash vbmeta vbmeta.img
  3. Wymaż i zapisz 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. Restart:
    $ fastboot reboot
Na urządzeniach z systemem Android 10, 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 dodatkową przestrzeń do flashowania GSI:
$ fastboot delete-logical-partition product_a
Postfix _a powinien być zgodny z identyfikatorem gniazda partycji systemowej, takim jak 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ą programistyczną i akceptuje tylko cherrypicks z głównej gałęzi AOSP, więc aby przesłać łatkę GSI, musisz:
    1. Prześlij poprawkę do master gałęzi AOSP .
    2. Cherrypick poprawkę do DESSERT -gsi .
    3. Zgłoś błąd, aby przejrzeć cherrypick.
  • Zgłaszanie błędów GSI lub przedstawianie innych sugestii. Zapoznaj się z instrukcjami zawartymi w części Zgłaszanie błędów , a następnie przeglądaj lub archiwizuj 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.