Ogólne obrazy systemu

Ogólny obraz systemu (GSI) to obraz systemu ze dostosowanymi konfiguracjami urządzeń z Androidem. Jest to czysty Android z niezmienionym kodem z Projektu Android Open Source (AOSP), który może działać na dowolnym urządzeniu z Androidem 9 lub nowszym.

GSI służą do przeprowadzania testów VTS i CTS-on-GSI. Obraz systemu urządzenia z Androidem jest zastąpiony obrazem GSI, a następnie testowany za pomocą pakietu Vendor Test Suite (VTS) i Compatibility Test Suite (CTS), aby sprawdzić, czy urządzenie prawidłowo implementuje interfejsy dostawcy w najnowszej wersji Androida.

Aby rozpocząć korzystanie z usług GSI, zapoznaj się z sekcjami poniżej, które zawierają szczegółowe informacje o konfiguracjach GSI (i dozwolonych odstępstwach) oraz typach. Gdy będziesz gotowy do użycia obrazu systemu, pobierz i skompiluj go na urządzenie docelowe, a następnie przeflashuj obraz systemu na urządzeniu z Androidem.

Konfiguracja i odstępstwa GSI

Obecna usługa GSI na Androida ma następującą konfigurację:

  • Tony wysokie. GSI obejmuje pełną obsługę zmian w architekturze opartej na AIDL/HIDL (zwanych też Treble), w tym obsługę interfejsów AIDL i HIDL. Możesz używać GSI na dowolnym urządzeniu z Androidem, które korzysta z interfejsów AIDL/HIDL. Więcej informacji znajdziesz w artykule o zasobach architektury.
  • System plików. GSI używa systemu plików ext4.

Obecna wersja GSI Androida obejmuje te główne różnice:

  • Architektura procesora. Obsługa różnych instrukcji procesora (ARM, x86 itp.) oraz liczby bitów procesora (32- lub 64-bitowy).

Docelowe wartości GSI w przypadku testów zgodności Treble

GSI używany do testów zgodności jest określany przez wersję Androida, z którą uruchamiane jest urządzenie.

Typ urządzenia Cel kompilacji
Urządzenia z Androidem 15 gsi_$arch-user (podpisano)
Urządzenia wprowadzone na rynek z Androidem 14 gsi_$arch-user (podpisano)
Urządzenia z Androidem 13 gsi_$arch-user (podpisano)
Urządzenia z Androidem 12L gsi_$arch-user (podpisano)
Urządzenia z Androidem 12 gsi_$arch-user (podpisano)
Urządzenia z Androidem 11 gsi_$arch-user (podpisano)

Wszystkie GSI są tworzone na podstawie kodu źródłowego Androida 12, a każda architektura procesora ma odpowiadający sobie plik binarny GSI (patrz lista celów kompilacji w sekcji Tworzenie GSI).

Zmiany w Androidzie 12 GSI

Urządzenia uruchamiane z Androidem 12 lub zaktualizowane do tej wersji muszą używać GSI Androida 12 do testów zgodności. Obejmuje to te ważne zmiany w stosunku do wcześniejszych wersji GSI:

  • Nazwa celu. Nazwa celu GSI testów zgodności została zmieniona na gsi_$arch. GSI o nazwie docelowej aosp_$arch jest zachowana dla deweloperów aplikacji na Androida. Plan testówCTS-on-GSI jest też ograniczony do testowania interfejsu dostawcy.
  • Starsza wersja GSI została wycofana. GSI 12 usuwa obejścia dla urządzeń z Androidem 8.0 lub 8.1, które nie są w pełni zgodne z Treble.
  • Userdebug SEPolicy. GSI gsi_$arch zawiera userdebug_plat_sepolicy.cil. Podczas flashowania vendor_boot-debug.img lub boot-debug.img firmy OEM /system/bin/init zostanie załadowany z GSI system.img.userdebug_plat_sepolicy.cil Szczegółowe informacje znajdziesz w artykule Testowanie VTS za pomocą debugowania Ramdisk.

Zmiany w Androidzie 11 GSI

Urządzenia uruchamiane z Androidem 11 lub zaktualizowane do Androida 11 muszą używać GSI Androida 11 do testów zgodności. Obejmuje to te ważne zmiany w stosunku do wcześniejszych wersji GSI:

  • treść_systemu_ext. Android 11 definiuje nowy podział system_ext. GSI umieszcza zawartość rozszerzenia systemu w folderze system/system_ext.
  • APEXes GSI zawiera zarówno spłaszczone, jak i skompresowane APEX-y. Który z nich należy użyć, zależy od właściwości systemowej ro.apex.updatablew partycji dostawcy w czasie wykonywania. Szczegółowe informacje znajdziesz w artykule Konfigurowanie systemu na potrzeby obsługi aktualizacji APEX.

Zmiany w GSI w Androidzie 10

Urządzenia uruchamiane z Androidem 10 lub zaktualizowane do tej wersji muszą używać GSI Androida 10 do testów zgodności. Obejmuje to te ważne zmiany w stosunku do wcześniejszych wersji GSI:

  • Kompilacja użytkownika. GSI ma wersję użytkownika z Androida 10. W Androidzie 10 użytkownicy mogą używać GSI w ramach testów zgodności CTS-on-GSI/VTS. Więcej informacji znajdziesz w artykule Testowanie VTS za pomocą debugowania na dysku RAM.
  • Nieprzetworzony format. GSI z docelami aosp_$arch są tworzone w nieprzetworzonym formacie. W razie potrzeby możesz użyć funkcji img2simg, aby przekonwertować nieprzetworzony plik GSI na rzadki format.
  • System jako root. Starsza wersja celu 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 ramdiskiem i opcją non-system-as-root należy użyć starszej wersji GSI aosp_$arch_ab. Uaktualniona wersja init w ramdisku obsługuje plik system.img OEM z układem system-as-root.
  • Weryfikacja podczas uruchamiania. Korzystając z GSI, wystarczy odblokować urządzenie. Nie musisz wyłączać weryfikacji podczas uruchamiania.

Zmiany w Androidzie 9 GSI

Urządzenia wprowadzane na rynek z Androidem 9 lub zaktualizowane do tej wersji muszą korzystać z GSI Androida 9 do testowania zgodności. Obejmują one te istotne zmiany w stosunku do wcześniejszych GSI:

  • Scala GSI i emulator. GSI są tworzone na podstawie obrazów systemowych produktów emulatora, 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 podłączyć obraz systemu do katalogu /system. W Androidzie 9 katalog główny obrazu systemu jest montowany jako katalog główny urządzenia.
  • 64-bitowy interfejs bindera. W Androidzie 8.x 32-bitowe GSI korzystały z 32-bitowego interfejsu bindera. Android 9 nie obsługuje 32-bitowego interfejsu bindera, więc zarówno 32-bitowe, jak i 64-bitowe GSI używają 64-bitowego interfejsu bindera.
  • Egzekwowanie zasad VNDK. W Androidzie 8.1 VNDK było opcjonalne. Od Androida 9 VNDK jest wymagany, więc musisz ustawić opcję BOARD_VNDK_VERSION.
  • Zgodna właściwość systemowa. Android 9 umożliwia sprawdzanie dostępu w przypadku zgodnej właściwości systemowej (PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true).

Android 9 Zmiany w Keymasterach

W starszych wersjach Androida urządzenia z Keymaster 3 lub niższym musiały weryfikować informacje o wersji (ro.build.version.release i ro.build.version.security_patch) zgłaszane przez uruchomiony system, aby dopasować je do informacji o wersji zgłaszanych przez program rozruchowy. Takie informacje były zwykle uzyskiwane z nagłówka obrazu rozruchowego.

W Androidzie 9 i nowszych ten wymóg został zmieniony, aby umożliwić dostawcom uruchamianie GSI. W szczególności Keymaster nie powinien przeprowadzać weryfikacji, ponieważ informacje o wersji z GSI mogą nie być zgodne z informacjami o wersji z bootloadera dostawcy. W przypadku urządzeń z Keymaster 3 lub niższą wersją sprzedawcy muszą zmodyfikować implementację Keymaster, aby pominąć weryfikację (lub uaktualnić Keymaster do wersji 4). Szczegółowe informacje o Keymaster znajdziesz w artykule Kluczowe informacje o Keymaster.

Pobierz GSI

Gotowe GSI możesz pobrać na stronie integracji ciągłej (CI) AOSP pod adresem ci.android.com. Jeśli typu GSI dla Twojej platformy sprzętowej nie można pobrać, w sekcji poniżej znajdziesz szczegółowe informacje o tworzeniu GSI dla określonych celów.

Utwórz 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ą treść Androida ze wszystkimi poprawkami zabezpieczeń i poprawkami GSI.

Aby skompilować GSI, skonfiguruj drzewo źródłowe Androida, pobierając z gałęzi GSI i wybierając docel kompilacji GSI. Aby określić odpowiednią wersję GSI dla swojego urządzenia, skorzystaj z tabel poniżej. Po zakończeniu kompilacji GSI staje się obrazem systemu (czyli system.img) i pojawia się w folderze wyjściowym out/target/product/generic_arm64.

Aby na przykład utworzyć cel kompilacji GSI gsi_arm64-userdebug w gałęzi android12-gsi GSI, uruchom te 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

Docelowe kompilacje GSI Androida

Poniższe cele kompilacji GSI dotyczą urządzeń z Androidem 9 lub nowszym.

Nazwa GSI architektura procesora, Interfejs Bindera – liczba bitów System jako root Tworzenie elementu docelowego
gsi_arm WŁĄCZ WYKRYWANIE 32 Y gsi_arm-user
gsi_arm-userdebug
gsi_arm64 ARM64 64 Y gsi_arm64-user
gsi_arm64-userdebug
gsi_x86 x86 32 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 instalowania GSI

Urządzenia z Androidem mogą mieć różne projekty, dlatego nie ma ogólnego polecenia ani zestawu instrukcji dotyczących aktualizowania GSI, które można zastosować na wszystkich urządzeniach. Aby uzyskać instrukcje dotyczące instalowania oprogramowania na urządzeniu z Androidem, skontaktuj się z producentem. Skorzystaj z tych ogólnych wskazówek:

  1. Upewnij się, że urządzenie ma:
    • Treblizacja
    • Metoda odblokowywania urządzeń (aby można było je przeflashować za pomocą fastboot)
    • Stan odblokowany, dzięki czemu można ją flashować za pomocą fastboot (aby mieć pewność, że masz najnowszą wersję fastboot, skompiluj ją z drzewa źródłowego Androida).
  2. Wymaż bieżący partycji systemowej, a następnie prześlij GSI na partycję systemową.
  3. Wyczyść dane użytkownika i inne niezbędne partycje (np. partycje danych użytkownika i partycje systemowe).
  4. Zrestartuj urządzenie.

Aby na przykład zainstalować GSI na dowolnym urządzeniu Pixel:

  1. Uruchom urządzenie w trybiefastboot i odblokuj program rozruchowy.
  2. Urządzenia obsługujące fastbootd muszą też uruchamiać fastbootd: 
    $ fastboot reboot fastboot
  3. Wymaż i zapisz GSI na partycji systemowej: 
    $ fastboot erase system
$ fastboot flash system system.img
  4. Wymaż dane użytkownika i dane z innych niezbędnych partycji (np. partycji danych użytkownika i partycji systemowej): 
    $ fastboot -w
  5. Ponownie uruchom bootloader: 
    $ fastboot reboot-bootloader
  6. Wyłącz weryfikację podczas uruchamiania podczas instalowania dostarczonego pliku vbmeta: 
    $ fastboot --disable-verification flash vbmeta vbmeta.img
  7. Reboot: 
    $ fastboot reboot
Na urządzeniach z Androidem 10 lub nowszym, które mają mniejsze partycje systemowe, podczas aktualizacji GSI może pojawić się ten komunikat o błędzie: 
    Resizing 'system_a'    FAILED (remote: 'Not enough space to resize partition')
    fastboot: error: Command failed
 Użyj tego polecenia, aby usunąć partycję produktu i zwolnić miejsce na partycji systemowej. To dodatkowe miejsce na aktualizację GSI: 
$ fastboot delete-logical-partition product_a
 Postfix _a powinien być zgodny z identyfikatorem przedziału partycji systemowej, np. system_a w tym przykładzie.

Współtworzenie usług GSI

Zespół Androida zaprasza do udziału w rozwijaniu GSI. Możesz wziąć udział w ulepszaniu GSI, wykonując te czynności:

  • Tworzenie poprawki GSI. DESSERT-gsi nie jest gałęzią programowania i akceptuje tylko cherrypicks z gałęzi głównej AOSP, więc aby przesłać poprawkę GSI, musisz:
    1. Prześlij poprawkę do gałęzi AOSP main.
    2. Wybierz poprawkę do zaimplementowania w DESSERT-gsi.
    3. Zgłoś błąd, aby sprawdzić, czy wybrane dane zostały sprawdzone.
  • Zgłaszanie błędów GSI lub przedstawianie innych sugestii. Zapoznaj się z instrukcjami w artykule Zgłaszanie błędów, a następnie przejrzyj lub prześlij zgłoszenia błędów GSI.

Wskazówki

Zmiana trybu paska nawigacyjnego za pomocą adb

Podczas uruchamiania z GSI tryb paska nawigacyjnego jest konfigurowany przez dostawcę. Tryb paska nawigacyjnego możesz zmienić, uruchamiając to polecenie adb w czasie działania. 

adb exec-out cmd overlay enable-exclusive com.android.internal.systemui.navbar.mode

Gdzie mode może być wartością threebutton, twobutton, gestural itd.