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 czysty Android realizacja z niemodyfikowanej Android Open Source Project (AOSP) Kod że każde urządzenie z Androidem 8.1 lub wyższy może działać skutecznie.

GSI są używane do przeprowadzania testów VTS i CTS-on-GSI. Obraz systemu z urządzenia z systemem Android jest zastąpiony przez GSI następnie testowane z Vendor Test Suite (VTS) i Compatibility Test Suite (CTS) , aby upewnić się, że urządzenie implementuje interfejsy sprzedawca poprawnie z najnowszą wersją Androida.

Aby rozpocząć korzystanie z GSIS, przejrzyj następujące sekcje Szczegółowe informacje na temat konfiguracji GSI (i dozwolonych odchyleń), typy (Android GSI i Legacy GSI) i pliki binarne i sprzedawca Zależności VNDK . Gdy jesteś gotowy do korzystania z GSI, pobrać i zbudować GSI do docelowego urządzenia, a następnie migać GSI na urządzeniu z Androidem.

Konfiguracja i wariancje GSI

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

  • Potroić. GSI pełną obsługę dla zmiany HIDL oparte na architekturze (znane również jako góry) wprowadzonych w Android 8.0 oraz wsparciem dla interfejsów HIDL . Możesz użyć GSI na dowolnym urządzeniu z Androidem, które korzysta z interfejsów dostawcy HIDL. (Aby uzyskać więcej informacji, zobacz zasobów architektury ).
  • Sprawdź rozruch. GSI nie obejmuje sprawdzenie rozruchu roztworu (np vboot 1,0 lub AVB ). Aby flashować GSI na urządzeniu uruchamianym w systemie Android 9 lub starszym, urządzenie musi mieć metodę wyłączania weryfikacji rozruchu.
  • System plików. GSI używa systemu plików ext4.
  • Układ partycji. GSI używa systemu jako korzeń układ partycji.

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 uruchamiające się 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

Wszystko GSIS są zbudowane z Androidem 10 kodzie, a każda architektura CPU posiada odpowiedni plik binarny GSI (zobacz listę celów budować w Budynku GSIS ).

Zmiany w Androidzie 10 GSI

Urządzenia uruchamiane z Androidem 10 muszą używać Android 10 GSI 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. Odnośnik VTS Testowanie z Debug Ramdisk na szczegółach.
  • Nierozdrobniony format. GSI z celami aosp_$arch zbudowane są z formatem unsparsed. Można użyć img2simg przekonwertować do formatu unsparsed GSI nielicznych, jeśli to konieczne.
  • System jako root. Spuścizna GSI cel build nazwie aosp_$arch_a zostały wycofane. Na urządzeniach z Androidem zmodernizowanych 8 lub 8,1 do Androida 10 z ramdysku niesystemowym-as-root, użyj spuściznę GSI aosp_$arch_ab . Unowocześniona init w ramdysku obsługuje system.img OEM z układu systemu jako root.

Do urządzeń testowych do wodowania na Androida 9 lub 10 z CTS-on-GSI, użyj kompilacji cele Android GSI .

Starsze GSI

Legacy GSIS podany 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 konfiguracje wstecznie zgodne dla urządzeń uaktualnionych z systemu Android 8 lub 8.1:

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

Do urządzeń testowych do wodowania na Androidzie 8.1 z 8 lub CTS-on-GSI, użyj kompilacji cele Legacy GSI .

Zmiany w Androidzie 9 GSI

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

  • Łączy GSI i emulator. GSIS zbudowane są z obrazów systemowych produktów emulatora np aosp_arm64 i aosp_x86 .
  • System jako root. W poprzednich wersjach systemu Android, urządzeniach, które nie obsługują / aktualizacje B może zamontować obraz systemu w ramach /system katalogu. 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 BOARD_VNDK_VERSION musi być ustawiony.
  • Zgodna właściwość systemu. Android 9 umożliwia kontrolę dostępu dla kompatybilny własności systemu ( PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true ).

Zmiany w systemie Android 9 Keymaster

We wcześniejszych wersjach systemu Android, urządzenia wykonawcze Keymaster 3 lub niższy musieli upewnić się, że informacje o wersji ( ro.build.version.release i ro.build.version.security_patch ) zgłaszane przez system uruchomiony dopasowane info wersji podanej przez bootloader. Takie informacje były zazwyczaj 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). Szczegółowe informacje na temat Keymaster patrz Hardware-backed Keystore .

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

Urządzenia uaktualniające do systemu Android 10 mają różne ścieżki uaktualniania w zależności od wersji plików binarnych dostawcy używanych na urządzeniu oraz konfiguracji związanych z VNDK użytych do skompilowania urządzenia. Poniższa tabela podsumowuje obsługę starszych GSI dla zaktualizowanych urządzeń.

Przypadek użycia Sprzedawca
pliki binarne
wersja
BOARD_VNDK_VERSION Starsze GSI
wersja systemu binarnego
Obsługa starszych 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 przypadkiem jest stosowanie obsługiwane nr 2, gdzie starsze urządzenia wspierające GSIS systemem Android 8.1, które zostały zbudowane z BOARD_VNDK_VERSION zestawu do current .

Przypadek nr 1 nie jest obsługiwany. W tym przypadku, dziedzictwo GSIS nie obsługują urządzeń z systemem Android 8.1, gdzie BOARD_VNDK_VERSION jest pominięte w kompilacji. Te urządzenia nie mogą być obsługiwane, ponieważ pliki binarne ich dostawców zależą od udostępnionych bibliotek systemu Android 8.1 innych niż VNDK, które nie są zawarte w starszych plikach GSI. Aby te urządzenia były zgodne ze starszym GSI, musisz wykonać jedną z następujących czynności:

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

    LUB

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

Pobieranie GSI

Można pobrać prekompilowany GSIS z AOSP ciągłej integracji (CI) stronie internetowej 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 GSI oddział nazwany DESSERT -gsi na AOSP (np android10-gsi jest oddział GSI na Androidzie 10). Gałęzie GSI zawierać treść Androida z wszystkich poprawek zabezpieczeń i poprawek GSI stosowane.

Aby zbudować GSI, ustawić drzewa źródłowego Androida przez pobranie z gałęzi GSI i wyborze gromadzeniu cel GSI . Skorzystaj z poniższych tabel docelowych kompilacji, aby określić poprawną wersję GSI dla swojego urządzenia. Po uzupełnia budować, GSI jest obraz systemu (czyli system.img ) i pojawia się w folderze wyjście out/target/product/ generic_arm64 . Kompilacja także wyjścia vbmeta.img , których można użyć, aby wyłączyć sprawdzić bagażnik na urządzeniach wykorzystujących Android Verified Boot .

Na przykład, aby zbudować GSI docelową build aosp_arm64-userdebug na GSI oddziału 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 Androida GSI

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

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

Starsze cele kompilacji GSI

Następujące kompilacji celem Legacy GSI są do urządzeń podnoszących Androidzie 8,0 lub 8,1 do nazw Android 10. Zapis GSI obejmują sufiks _ab aby odróżnić je od Androida 10 nazw GSI.

Nazwa GSI Łuk procesora Bitowość interfejsu Binder System jako root Zbuduj cel
aosp_arm_ab RAMIĘ 32 Tak aosp_arm_ab-userdebug
aosp_arm_64b_ab RAMIĘ 64 Tak aosp_arm_64b_ab-userdebug
aosp_arm64_ab ARM64 64 Tak aosp_arm64_ab-userdebug
aosp_x86_ab x86 32 Tak aosp_x86_ab-userdebug
aosp_x86_64_ab x86-64 64 Tak 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ólnych poleceń ani zestawu instrukcji dotyczących flashowania GSI, które można zastosować do wszystkich urządzeń. Skontaktuj się z producentem urządzenia z Androidem, 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
    • Sposób urządzenia odblokowujące (więc mogą być powleczone przy użyciu fastboot )
    • Sposób wyłączania sprawdzenia rozruchu (na przykład vboot 1,0 lub AVB )
    • Stanie odblokowanym aby flashable poprzez fastboot (Aby upewnić się, że masz najnowszą wersję fastboot , zbudować go z drzewa źródłowego Androida).
  2. Wyłącz weryfikację rozruchu.
  3. Usuń bieżącą partycję systemową, a następnie sflashuj GSI na partycję systemową.
  4. Wyczyść dane użytkownika i usuń dane z innych niezbędnych partycji (na przykład danych użytkownika i partycji systemowych).
  5. Uruchom ponownie urządzenie.

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

  1. Boot do fastboot trybie i odblokować bootloader . Wyłącz zweryfikować rozruchowym (AVB) miganiem vbmeta.img :
    $ fastboot --disable-verification flash vbmeta vbmeta.img
  2. Urządzenia wspierające fastbootd również muszą buta do fastbootd przez:
    $ fastboot reboot fastboot
  3. Erase i migać GSI do partycji systemowej:
    $ fastboot erase system
    $ fastboot flash system system.img
    
  4. Wycierania dane użytkownika i kasowanie danych z innych partycji, (na przykład, dane użytkownika i partycji systemu):
    $ fastboot -w
  5. Reboot:
    $ fastboot reboot
Na Androidzie 10 urządzeń, które mają mniejsze partycje systemowe, może pojawić się następujący komunikat o błędzie, gdy miga GSI:
    Resizing 'system_a'    FAILED (remote: 'Not enough space to resize partition')
    fastboot: error: Command failed
użyć następującego polecenia, aby usunąć partycję produktów i zwolnić miejsce dla partycji systemowej. Zapewnia to dodatkową przestrzeń do flash GSI:
$ fastboot delete-logical-partition product_a
przyrostek _a powinna odpowiadać identyfikator gniazda partycji systemu, 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ą rozwoju i akceptuje tylko cherrypicks z głównego oddziału AOSP, tak aby przedstawić poprawkę GSI, należy:
    1. Złożyć poprawkę do AOSP master gałęzi.
    2. Cherrypick poprawkę na DESSERT -gsi .
    3. Zgłoś błąd, aby zrecenzować Cherrypick.
  • Raportowanie błędów GSI lub dokonywanie innych sugestii. Zapoznaj się z instrukcjami w Zgłaszanie błędów , a następnie przeglądać lub plików GSI błędy .

Porady

Zmiana trybu paska nawigacji za pomocą adb

Podczas uruchamiania z GSI tryb paska nawigacyjnego 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.