Obrazy systemu ogólnego

Podstawowy obraz systemu (GSI) to obraz systemu z dostosowanymi konfiguracjami na urządzenia z Androidem. Jest to implementacja czystego Androida z niezmodyfikowanym kodem Projektu Android Open Source (AOSP), który można uruchomić na każdym urządzeniu z Androidem 9 lub nowszym.

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

Aby rozpocząć korzystanie z GSI, zapoznaj się z poniższymi sekcjami, w których znajdziesz szczegółowe informacje o konfiguracjach GSI (i dopuszczalnych odchyleniach) oraz typach. Gdy będziesz gotowy(-a) do użycia GSI, pobierz i skompiluj GSI dla urządzenia docelowego, a następnie wgraj GSI na urządzenie z Androidem.

Konfiguracja i różnice w GSI

Obecny obraz GSI Androida ma taką konfigurację:

• Sopran GSI w pełni obsługuje zmiany architektury oparte na AIDL/HIDL (znane też jako Treble), w tym interfejsy AIDL i interfejsy HIDL. Interfejsu GSI możesz używać na dowolnym urządzeniu z Androidem, które korzysta z interfejsów dostawcy AIDL/HIDL. (Więcej informacji znajdziesz w materiałach o architekturze).
• System plików GSI korzysta z systemu plików ext4.

Obecny obraz GSI Androida zawiera te główne różnice:

• Architektura procesora. Obsługa różnych instrukcji procesora (ARM, x86 itp.) i bitowości procesora (32-bitowy lub 64-bitowy).

Obrazy GSI na potrzeby testów zgodności z Treble

Wersja GSI używana do testów zgodności jest określana przez wersję Androida, z którą urządzenie jest wprowadzane na rynek.

Wszystkie obrazy GSI są tworzone na podstawie bazy kodu Androida 12, a każda architektura procesora ma odpowiadający jej plik binarny GSI (listę docelowych kompilacji znajdziesz w sekcji Tworzenie obrazów GSI).

Zmiany w obrazie GSI w Androidzie 12

Urządzenia, które są wprowadzane na rynek z Androidem 12 lub aktualizowane do tej wersji, muszą używać obrazów GSI Androida 12 do testów zgodności. Obejmuje to następujące główne zmiany w stosunku do wcześniejszych GSI:

• Nazwa miejsca docelowego. Nazwa docelowa GSI w przypadku testów zgodności została zmieniona na gsi_$arch. Interfejs GSI o nazwie docelowejaosp_$arch jest zachowywany dla deweloperów aplikacji na Androida. Plan testówCTS-on-GSI jest też ograniczony w przypadku interfejsu dostawcy testów.
• Starsza wersja GSI jest wycofywana. 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 specyficznych dla producenta OEM /system/bin/init załaduje userdebug_plat_sepolicy.cil z interfejsu GSI system.img. Szczegółowe informacje znajdziesz w artykule Testowanie VTS za pomocą debugowania dysku RAM.

Zmiany w GSI Androida 11

Urządzenia wprowadzane na rynek z Androidem 11 lub aktualizowane do tej wersji muszą używać GSI w Androidzie 11 do testów 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.
• APEXes GSI zawiera zarówno spłaszczone, jak i skompresowane pakiety APEX. To, który z nich zostanie użyty, jest określane przez właściwość systemu ro.apex.updatable w partycji dostawcy w czasie działania. Szczegółowe informacje znajdziesz w artykule Konfigurowanie systemu pod kątem obsługi aktualizacji APEX.

Zmiany w GSI Androida 10

Urządzenia wprowadzane na rynek z Androidem 10 lub aktualizowane do tej wersji muszą używać obrazów GSI Androida 10 do testów 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 GSI użytkownika może być używana w testach zgodności CTS-on-GSI/VTS. Szczegółowe informacje znajdziesz w artykule Testowanie VTS za pomocą debugowania ramdysku.
• Format bez rozrzedzenia GSI z elementami docelowymi aosp_$arch są tworzone w formacie bez rozrzedzania. W razie potrzeby możesz użyć polecenia img2simg, aby przekonwertować nieprzetworzony GSI na format rzadki.
• System-as-root Starszy cel kompilacji GSI o nazwie aosp_$arch_a został wycofany. W przypadku urządzeń zaktualizowanych z Androida 8 lub 8.1 do Androida 10 z ramdiskiem i bez systemu jako roota użyj starszego obrazu GSI aosp_$arch_ab. Ulepszony init w ramdysku obsługuje system OEM.img z układem system-as-root.
• Weryfikacja podczas uruchamiania. W przypadku GSI wystarczy odblokować urządzenie. Nie musisz wyłączać weryfikacji podczas uruchamiania.

Zmiany w GSI Androida 9

Urządzenia wprowadzane na rynek z Androidem 9 lub aktualizowane do tej wersji muszą używać GSI Androida 9 do testów zgodności. Obejmuje to następujące główne zmiany w stosunku do wcześniejszych GSI:

• Łączy GSI i emulator. Obrazy GSI są tworzone na podstawie obrazów systemowych produktów emulatora, np. aosp_arm64 i aosp_x86.
• System-as-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 Androidzie 9 katalog główny obrazu systemu jest montowany jako katalog główny urządzenia.
• Interfejs 64-bitowy. W Androidzie 8.x 32-bitowe obrazy 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 obrazy GSI korzystają z 64-bitowego interfejsu bindera.
• Egzekwowanie VNDK W Androidzie 8.1 VNDK było opcjonalne. Od Androida 9 VNDK jest obowiązkowy, więc musi być ustawiony.BOARD_VNDK_VERSION
• Zgodna właściwość systemu. Android 9 umożliwia sprawdzanie dostępu do zgodnej właściwości systemu (PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true).

Android 9 Zmiany w Keymasterze

W starszych wersjach Androida urządzenia z Keymasterem 3 lub starszym musiały sprawdzać, 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 rozruchowy. Takie informacje były zwykle pobierane z nagłówka obrazu rozruchowego.

W Androidzie 9 i nowszych to wymaganie 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 być zgodne z informacjami o wersji zgłaszanymi przez program rozruchowy dostawcy. W przypadku urządzeń z Keymasterem 3 lub starszym dostawcy muszą zmodyfikować implementację Keymastera, aby pominąć weryfikację (lub uaktualnić ją do Keymastera 4). Szczegółowe informacje o Keymasterze znajdziesz w artykule Sprzętowy magazyn kluczy.

Pobieranie obrazów GSI

Gotowe obrazy GSI możesz pobrać ze strony internetowej trybu ciągłej integracji (CI) AOSP pod adresem ci.android.com. Jeśli typ obrazu GSI dla Twojej platformy sprzętowej jest niedostępny do pobrania, w następnej sekcji znajdziesz szczegółowe informacje o tworzeniu obrazów GSI dla konkretnych celów.

Tworzenie GSI

Od Androida 9 każda wersja Androida ma w AOSP gałąź GSI o nazwie DESSERT-gsi (np. android12-gsi to gałąź GSI w Androidzie 12). Gałęzie GSI zawierają treść Androida ze wszystkimi zastosowanymi łatkami zabezpieczeń i łatkami GSI.

Aby utworzyć GSI, skonfiguruj drzewo źródłowe Androida, pobierając je z gałęzi GSI i wybierając docelową kompilację GSI. Z tabel poniżej określ prawidłową wersję GSI dla swojego urządzenia. Po zakończeniu kompilacji obraz GSI będzie obrazem systemu (czyli system.img) i pojawi się w folderze wyjściowym out/target/product/generic_arm64.

Aby na przykład skompilować docelową kompilację GSI gsi_arm64-userdebug w gałęzi GSI android12-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

Cele kompilacji GSI Androida

Te docelowe kompilacje GSI są przeznaczone dla urządzeń wprowadzanych na rynek z Androidem 9 lub nowszym.

Wymagania dotyczące instalowania obrazów GSI

Urządzenia z Androidem mogą mieć różne konstrukcje, więc nie ma ogólnego polecenia ani zestawu instrukcji flashowania obrazu GSI, które można by zastosować do wszystkich urządzeń. Aby uzyskać szczegółowe instrukcje flashowania, skontaktuj się z producentem urządzenia z Androidem. Postępuj zgodnie z tymi ogólnymi wytycznymi:

1. Sprawdź, czy urządzenie ma:
   • Podbicie tonów wysokich
   • Metoda odblokowywania urządzeń (aby można było je flashować za pomocą narzędzia fastboot).
   • Odblokowany stan, aby można było wgrać oprogramowanie za pomocą fastboot. (Aby mieć pewność, że masz najnowszą wersję fastboot, skompiluj ją z drzewa źródłowego Androida).
2. Usuń bieżącą partycję systemową, a następnie wgraj GSI na partycję systemową.
3. Wymaż dane użytkownika i usuń dane z innych niezbędnych partycji (np. partycji danych użytkownika i partycji systemowych).
4. Zrestartuj urządzenie.

Aby na przykład wgrać GSI na dowolne urządzenie Pixel:

1. Uruchom w trybiefastboot i odblokuj program rozruchowy.
2. Urządzenia obsługujące fastbootd muszą też uruchamiać się w trybie fastbootd w jeden z tych sposobów:

   $ fastboot reboot fastboot

3. Wymaż i zainstaluj GSI w partycji systemowej:

   $ fastboot erase system
   $ fastboot flash system system.img

4. Jeśli urządzenie obsługuje Android Virtual Framework, wgraj oprogramowanie Protected Virtual Machine Firmware:

   $ fastboot flash pvmfw pvmfw.img
   

5. Wymaż dane użytkownika i usuń dane z innych niezbędnych partycji (np. partycji danych użytkownika i partycji systemowych):

   $ fastboot -w

6. Ponownie uruchom program rozruchowy:

   $ fastboot reboot-bootloader

7. Wyłącz weryfikację podczas uruchamiania podczas flashowania podanego pliku vbmeta:

   $ fastboot --disable-verification flash vbmeta vbmeta.img

8. 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 GSI

Android zachęca do udziału w tworzeniu GSI. Możesz się zaangażować i pomóc w ulepszaniu GSI, wykonując te czynności:

• Tworzenie poprawki GSI DESSERT-gsi nie jest gałęzią deweloperską i akceptuje tylko wybrane zmiany z najnowszej gałęzi AOSP (android17-release), więc aby przesłać poprawkę GSI, musisz:
  1. Prześlij poprawkę do gałęzi AOSP android17-release.
  2. Wybrać poprawkę do DESSERT-gsi.
  3. Zgłoś błąd, aby sprawdzić, czy można zastosować cherrypick.
• zgłaszanie błędów GSI lub przesyłanie innych sugestii. Zapoznaj się z instrukcjami w artykule Zgłaszanie błędów, a następnie przejrzyj lub zgłoś błędy GSI.

Wskazówki

Zmiana trybu paska nawigacyjnego za pomocą narzędzia adb

Podczas uruchamiania z GSI tryb paska nawigacyjnego jest konfigurowany przez zastąpienie dostawcy. 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ć threebutton, twobutton, gestural itd.