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.

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.

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

    Resizing 'system_a'    FAILED (remote: 'Not enough space to resize partition')
    fastboot: error: Command failed

$ fastboot delete-logical-partition product_a

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.