Ogólne obrazy systemu

Ogólny obraz systemu (GSI) to obraz systemu ze dostosowanymi konfiguracjami na urządzenia z Androidem. Uznaje się, że jest to implementacja czystego Androida. z niezmodyfikowanym kodem Android Open Source Project (AOSP) używanym przez na urządzeniach z Androidem 9 lub nowszym.

GSI służy do uruchamiania testów VTS i CTS-on-GSI. Obraz systemu urządzenie z Androidem zostało zastąpione elementem GSI, a następnie przetestowanym z Vendor Test Suite (VTS) oraz Compatibility Test Suite (CTS) pozwala sprawdzić, urządzenie prawidłowo zaimplementuje interfejsy dostawcy w najnowszej wersji, Androida.

Aby rozpocząć korzystanie z GSI, zapoznaj się ze szczegółowymi informacjami w sekcjach poniżej: Konfiguracje GSI (i dozwolone wariancje) i typy. Jeśli chcesz zacząć korzystać z GSI, pobierz i utwórz GSI na swoje urządzenie. i prześlij GSI do Androida urządzenia.

Konfiguracja i warianty GSI

Obecna konfiguracja GSI Androida ma taką konfigurację:

• Tony wysokie. GSI obejmuje pełną obsługę Zmiany architektoniczne oparte na AIDL/HIDL (nazywany również wysokim), w tym obsługę Interfejsy AIDL oraz Interfejsy HIDL. Możesz korzystać z GSI na dowolne urządzenie z Androidem korzystające z interfejsów dostawcy AIDL/HIDL. (Aby dowiedzieć się więcej, zapoznaj się z artykułem Zasoby dotyczące architektury).
• System plików. GSI korzysta z systemu plików ext4.

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

• Architektura procesora. Obsługa różnych instrukcji dotyczących procesora (ARM, x86 itp.) i szybkość bity procesora (32- lub 64-bitowa).

Cele GSI do testów zgodności Treble

Wskaźnik GSI używany do testowania zgodności jest określany na podstawie wersji Androida, z którym urządzenie ma zostać uruchomione.

Wszystkie GSI są oparte na bazie kodu Androida 12. każda architektura procesora ma odpowiedni plik binarny GSI (zobacz listę kompilacji celów w artykule Tworzenie GSI).

Zmiany w Androidzie 12 GSI

Urządzenia wprowadzane na rynek z Androidem 12 lub zaktualizowane do tej wersji muszą obsługiwać Androida 12 GSI do testowania zgodności. Obejmuje to m.in.: następujące istotne zmiany w stosunku do wcześniejszych GSI:

• Nazwa celu. Nazwa celu GSI zgodności – stan testów został zmieniony na gsi_$arch. GSI z nazwą celu Aplikacja aosp_$arch jest przechowywana dla deweloperów aplikacji na Androida. Plan testów W przypadku testowania interfejsu dostawcy usługa CTS-on-GSI jest ograniczona.
• Starsza wersja GSI została wycofana. GSI 12 usuwa obejścia na urządzeniach z Androidem 8.0 lub 8.1, nie są w pełni treblowane.
• Userdebug SEPolicy. gsi_$archGSI zawiera userdebug_plat_sepolicy.cil. Podczas migania vendor_boot-debug.img producenta OEM lub boot-debug.img, załaduje się /system/bin/init userdebug_plat_sepolicy.cil z GSI system.img. Źródła wiedzy Testowanie VTS przy użyciu Debuguj Ramdisk, aby uzyskać szczegółowe informacje.

Zmiany w Androidzie 11 GSI

Urządzenia wprowadzane na rynek z Androidem 11 lub zaktualizowane do tej wersji muszą obsługiwać Androida 11 GSI do testowania zgodności. Obejmuje to m.in.: następujące istotne zmiany w stosunku do wcześniejszych GSI:

• treść_systemu_ext. Android 11 definiuje nową partycję system_ext. GSI umieszcza treść rozszerzenia systemu w folderze system/system_ext
• APEX. GSI zawiera zarówno spłaszczone, jak i skompresowane punkty APEX. Wybór metody zależy od właściwości systemowej ro.apex.updatable na partycji dostawcy w czasie działania. Źródła wiedzy Skonfiguruj system do obsługi aktualizacji APEX.

Zmiany w Androidzie 10 GSI

Urządzenia wprowadzane na rynek z Androidem 10 lub zaktualizowane do tej wersji muszą obsługiwać Androida 10 GSI do testowania zgodności. Obejmuje to m.in.: następujące istotne zmiany w stosunku do wcześniejszych GSI:

• Tworzenie użytkownika. GSI ma kompilację użytkownika utworzoną na podstawie Androida 10. W Androidzie 10 GSI kompilacji użytkownika można używać do testowania zgodności CTS na GSI/VTS. Źródła wiedzy Testowanie VTS z użyciem debugowania Ramdisk .
• Nierozdzielony format. GSI z wartościami docelowymi aosp_$arch są tworzone w formacie nierozproszonym. Za pomocą img2simg, aby przekonwertować nierozproszony plik GSI na format rozproszony, jeśli niezbędną.
• System jako root. Starszy cel kompilacji GSI o nazwie Usługa aosp_$arch_a została wycofana. Urządzenia, które przeszły na wyższą wersję z Androida 8 lub 8.1 do Androida 10 z zainstalowanym systemem pamięci RAM inny niż system jako root, użyj starszej wersji GSI aosp_$arch_ab. Uaktualniony init w ramach dysku ramdisk obsługuje system OEM.img z układem systemowym jako głównym.
• Sprawdź rozruch. Jeśli korzystasz z GSI, wystarczy, że odblokujesz urządzenie. Wyłączenie weryfikacji podczas uruchamiania nie jest konieczne.

Zmiany w Androidzie 9 GSI

Urządzenia wprowadzane na rynek z Androidem 9 lub zaktualizowane do tej wersji muszą obsługiwać Androida 9 GSI do testowania zgodności. Obejmuje to m.in.: następujące istotne zmiany w stosunku do wcześniejszych GSI:

• Scala GSI i emulator. Główne cele wyszukiwania są tworzone na podstawie systemu obrazy usług emulatorów, np. aosp_arm64 i aosp_x86
• System jako root. W poprzednich wersjach Androida który nie obsługiwał aktualizacji A/B, mógł podłączyć obraz systemu pod Katalog /system. W Androidzie 9 główny obraz systemu jest podłączony jako katalog główny urządzenia.
• 64-bitowy interfejs Binder. W Androidzie 8.x 32-bitowy plik GSI użyliśmy 32-bitowego interfejsu Binder. Android 9 nie obsługuje 32-bitowego interfejsu Binder, więc zarówno 32-bitowy GSI, jak i 64-bitowe komponenty GSI używają 64-bitowego interfejsu binder.
• Egzekwowanie zasad VNDK. W Androidzie 8.1 użycie VNDK było opcjonalne. Począwszy od Androida 9 obsługa VNDK jest obowiązkowa, więc Wartość BOARD_VNDK_VERSION musi być ustawiona.
• Zgodna właściwość systemowa. Android, 9 włącza sprawdzanie dostępu w przypadku zgodnego właściwość systemowa (PRODUCT_COMPATIBLE_PROPERTY_OVERRIDE := true).

Android 9 Zmiany w Keymasterze

We wcześniejszych wersjach Androida urządzenia z implementacją Keymaster 3 lub starszym wymagane do zweryfikowania, czy informacje o wersji (ro.build.version.release i ro.build.version.security_patch) zgłoszone przez uruchomiony system zgodne z informacjami o wersji zgłoszonymi przez program rozruchowy. Takie informacje były zazwyczaj pochodzi z nagłówka obrazu rozruchowego.

W Androidzie 9 i nowszych to wymaganie zostało zmienione i dostępne dostawców usług GSI. W szczególności Keymaster nie powinien przeprowadzać weryfikacji. bo informacje o wersji zgłoszone przez GSI mogą nie odpowiadać danym o wersji. zgłoszone przez program rozruchowy dostawcy. Na urządzeniach z implementacją Keymaster 3 lub niższych wartości, dostawcy muszą zmodyfikować implementację Keymaster, aby pominąć weryfikację. (albo uaktualnij do Keymaster 4). Informacje o Keymasterze znajdziesz tutaj: Obsługiwany sprzętowo magazyn kluczy.

Pobierz GSI

Możesz pobrać gotowe interfejsy GSI z poziomu ciągłej integracji AOSP (CI) witrynie pod adresem ci.android.com Jeśli typ GSI sprzętu platformy jest niedostępna do pobrania, zapoznaj się z sekcją poniżej, na temat tworzenia GSI dla konkretnych celów.

Utwórz GSI

Począwszy od Androida 9, każda wersja Androida ma Oddział GSI o nazwie DESSERT-gsi w AOSP (np. android12-gsi to oddział GSI na Androidzie 12) Oddziały GSI obejmują zawartość Androida wszystkich poprawek zabezpieczeń oraz Zastosowano poprawki GSI.

Aby utworzyć GSI, skonfiguruj drzewo źródłowe Androida przez pobieranie z oddziału GSI Wybór kompilacji GSI . Korzystając z poniższych tabel celów kompilacji, określ prawidłową GSI wersję systemu. Po zakończeniu kompilacji, system GSI jest obrazu (czyli system.img) i pojawi się w folderze wyjściowym out/target/product/generic_arm64

Na przykład, aby utworzyć cel kompilacji GSI gsi_arm64-userdebug w oddziale GSI android12-gsi, uruchom następujące 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

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

Wymagania dotyczące migania GSI

Urządzenia z Androidem mogą mieć różne projekty, więc nie jest potrzebne ogólne polecenie zestawu instrukcji dotyczących aktualizowania GSI, które mają zastosowanie na wszystkich urządzeniach. Skontaktuj się z producenta urządzenia z Androidem, aby uzyskać wyraźne instrukcje dotyczące flashowania. Kieruj się tymi ogólnymi wskazówkami:

1. Upewnij się, że urządzenie ma:
   • Z trebli
   • Metoda odblokowywania urządzeń (np. za pomocą fastboot).
   • Stan: odblokowany, aby można było go wyświetlić na urządzeniu fastboot (Aby mieć pewność, że masz najnowszą wersję fastboot, kompiluj z drzewa źródłowego Androida).
2. Usuń bieżącą partycję systemową, a następnie zainstaluj w systemie GSI partycji danych.
3. Wyczyść dane użytkownika i usuń dane z innych niezbędnych partycji (na np. dane użytkownika i partycje systemu).
4. Zrestartuj urządzenie.

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

1. Uruchom fastboot i odblokuj programu rozruchowego.
2. Urządzenia obsługujące fastbootd konieczne jest też uruchomienie systemu fastbootd przez:

   $ fastboot reboot fastboot

3. Usuń plik GSI i uruchom go na partycji systemowej:

   $ fastboot erase system
   $ fastboot flash system system.img
   

4. Wyczyść dane użytkownika i usuń dane z innych niezbędnych partycji (na np. dane użytkownika i partycje systemowe):

   $ fastboot -w

5. Restart:

   $ fastboot reboot

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

$ fastboot delete-logical-partition product_a

Wspieraj GSI

Dziękujemy za wkład w rozwój GSI. Możesz się zaangażować i pomóc w ulepszaniu GSI przez:

• Tworzenie poprawki GSI. DESSERT-gsi nie jest działem programowania i akceptuje tylko cherrypicks do głównej gałęzi AOSP, więc aby przesłać poprawkę GSI, musisz:
  .
  1. Prześlij poprawkę do AOSP, Gałąź: main.
  2. Wybierz teren na trasie DESSERT-gsi.
  3. Zgłoś błąd, aby uzyskać ocenę cherrypick.
• Zgłaszanie błędów GSI i przesyłanie innych sugestii. Sprawdź instrukcje w artykule Zgłaszanie błędów, przejrzyj lub zapisz GSI

Wskazówki

Zmienianie trybu paska nawigacyjnego za pomocą narzędzia adb

Podczas uruchamiania przy użyciu GSI tryb paska nawigacyjnego jest konfigurowany przez zastąpienie dostawcy. Dostępne opcje zmień tryb paska nawigacyjnego, uruchamiając w czasie działania podane niżej polecenie adb.

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

Gdzie mode może mieć wartość threebutton, twobutton, gestural itd.