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órą można uruchomić na każdym urządzeniu z Androidem 9 lub nowszym.

Obrazy GSI służą 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 tymi 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

Obecna konfiguracja GSI Androida jest następująca:

• Tony wysokie GSI w pełni obsługuje zmiany architektury oparte na AIDL/HIDL (znane też jako Treble), w tym interfejsy AIDL i interfejsy HIDL. Możesz używać GSI 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 do testów zgodności z Treble

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

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

Zmiany w GSI w Androidzie 12

Urządzenia, które są wprowadzane na rynek z Androidem 12 lub są 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 wersji 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.
• SEPolicy w wersji userdebug GSI gsi_$arch zawiera userdebug_plat_sepolicy.cil. Podczas flashowania vendor_boot-debug.img lub boot-debug.img/system/bin/inituserdebug_plat_sepolicy.cilsystem.img. Szczegółowe informacje znajdziesz w artykule Testowanie VTS z użyciem debugowania dysku RAM.

Zmiany w GSI Androida 11

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

• zawartość system_ext. Android 11 definiuje nową partycję system_ext. GSI umieszcza zawartość rozszerzenia systemowego w folderze system/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, które są wprowadzane na rynek z Androidem 10 lub są 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 wersji GSI:

• Wersja użytkownika GSI ma kompilację użytkownika z Androida 10. W Androidzie 10 obraz GSI w wersji użytkownika może być używany w testach zgodności CTS-on-GSI/VTS. Szczegółowe informacje znajdziesz w artykule Testowanie VTS za pomocą debugowania dysku RAM.
• Format bez rzadkich danych GSI z celami 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 element docelowy 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, które są wprowadzane na rynek z Androidem 9 lub zaktualizowane do tej wersji, muszą używać obrazów GSI Androida 9 do testów zgodności. Obejmuje to następujące główne zmiany w stosunku do wcześniejszych wersji GSI:

• Łączy GSI i emulator. Obrazy GSI są tworzone na podstawie obrazów systemu 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 musisz ustawić 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 uzyskiwane 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). Więcej informacji o Keymasterze znajdziesz w artykule Sprzętowy magazyn kluczy.

Pobieranie GSI

Gotowe obrazy GSI możesz pobrać ze strony internetowej 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 dowiesz się, która wersja GSI jest odpowiednia dla Twojego 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 utworzyć docelowy pakiet 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 wersje 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 urządzenie w fastboot 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. Uruchom ponownie w trybie bootloadera:

   $ fastboot reboot-bootloader

7. Wyłącz weryfikację podczas uruchamiania podczas flashowania dostarczonego 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 rozwijaniu 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 (android16-qpr2-release), więc aby przesłać poprawkę GSI, musisz:
  1. Prześlij poprawkę do gałęzi AOSP android16-qpr2-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

mode może być threebutton, twobutton, gestural itd.