Obrazy systemu ogólnego

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Ogólny obraz systemu (GSI) to obraz systemu z dopasowanymi konfiguracjami na potrzeby 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 materiałach dotyczących 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.) i 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 Tworzenie GSI).

Zmiany w GSI w Androidzie 12

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 miejsca docelowego. Nazwa docelowego obiektu GSI w testach 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 jest wycofywana. GSI 12 usuwa obejścia, które umożliwiały działanie na urządzeniach 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 GSI w Androidzie 11

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ści system_ext. Android 11 definiuje nowy podział system_ext. GSI umieszcza zawartość rozszerzenia systemowego 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. Aby uzyskać szczegółowe informacje, zapoznaj się z artykułem Konfigurowanie systemu na potrzeby obsługi aktualizacji APEX.

Zmiany w GSI w Androidzie 10

Urządzenia uruchamiane z Androidem 10 lub zaktualizowane do Androida 10 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 nierozpoznanym formacie. W razie potrzeby możesz użyć funkcji img2simg, aby przekonwertować nieprzetworzony plik GSI na rzadki format.
• System jako root. Stary docelowo obiekt 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 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, musisz tylko odblokować urządzenie. Nie musisz wyłączać weryfikacji podczas uruchamiania.

Zmiany w GSI w Androidzie 9

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

• Łączy 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 zamontować obraz systemu w 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 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 systemowej (PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true).

Android 9 Zmiany w Keymaster

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 są zazwyczaj 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 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ć ją do Keymaster 4). Szczegółowe informacje o Keymaster znajdziesz w artykule Kluczowe informacje o Keymaster.

Pobieranie 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.

Tworzenie 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 zawierają zawartość Androida z włączonymi wszystkimi poprawkami bezpieczeństwa 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 jest obrazem systemu (czyli system.img) i pojawia się w folderze wyjściowym out/target/product/generic_arm64.

Aby na przykład utworzyć docelowe wydanie GSI gsi_arm64-userdebug na 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

Docelowe kompilacje GSI Androida

Te docelowe wersje GSI są przeznaczone do urządzeń z Androidem 9 lub nowszym.

Wymagania dotyczące flashowania GSI

Urządzenia z Androidem mogą mieć różne konstrukcje, więc nie ma uniwersalnego polecenia ani zestawu instrukcji dotyczących flashowania obrazu GSI, które można by zastosować na wszystkich urządzeniach. Aby uzyskać instrukcje dotyczące instalowania oprogramowania na urządzeniu z Androidem, skontaktuj się z producentem. Poniżej znajdziesz ogólne wskazówki:

1. Upewnij się, że urządzenie ma:
   • Treblizacja
   • Metoda odblokowywania urządzeń (aby można było je przeprogramować za pomocą fastboot)
   • Odblokowany stan, aby można było go zainstalować 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 zainstaluj GSI na partycji systemowej.
3. Wymaż dane użytkownika i dane z innych niezbędnych partycji (np. partycji danych użytkownika i partycji systemowej).
4. Zrestartuj urządzenie.

Aby na przykład zainstalować obraz 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 inne niezbędne partycje (np. partycje danych użytkownika i partycje systemowe):

   $ 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ą rozwojową 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 błędy 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ć threebutton, twobutton, gestural itd.