Od 27 marca 2025 r. zalecamy używanie android-latest-release zamiast aosp-main do kompilowania i wspołtworzenia AOSP. Więcej informacji znajdziesz w artykule o zmianach w AOSP.

Ta strona została przetłumaczona przez Cloud Translation API.

Testowanie VTS za pomocą debugowanego dysku RAM
Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Od Androida 10 obraz systemu ogólnego (GSI) używany do przeprowadzania testów zgodności CTS-on-GSI/VTS zmienił się z typu userdebug na userbuild, aby można było go podpisać. Jest to problem w przypadku testowania VTS, ponieważ wymaga on uruchomienia adb root, a na urządzeniu z kompilacją użytkownika nie jest on dostępny.

Wprowadzono obraz rozruchowy do debugowania (lub obraz rozruchowy do debugowania), aby umożliwić adb root na urządzeniu z wersją użytkownika, którego program rozruchowy jest odblokowany. Upraszcza to testowanie używając tej samej kompilacji użytkownika GSI system.img dla CTS-on-GSI i VTS na GSI. W przypadku konfiguracji STS korzystanie z innego debugowania OEM (system.img) nadal jest używane

Poniższa tabela zawiera zmiany w typach obrazów i kompilacji w ramach testów zgodności w Androidzie 10.

Zestaw testów	Przetestuj za pomocą	Budowanie	Debugowanie dysku RAM	adb root?	Android 9 -> Android 10 – zmiana wariantu kompilacji
CTS	System OEM	użytkownik	N	N	Bez zmian
CTS-on-GSI	GSI	użytkownik	N	N	userdebug -> GSI użytkownika wersja podpisana
STS	System OEM	debugowanie użytkownika	N	Y	Nowości w Q
VTS	GSI	użytkownik	Y	Y	userdebug -> user GSI wersja podpisana

Omówienie

Te dodatkowe pliki obrazów są generowane w folderze kompilacji (${ANDROID_PRODUCT_OUT}):

boot-debug.img
vendor_boot-debug.img

Gdy na partycji boot urządzenia pojawi się błysk boot-debug.img, wersji userdebug pliku sepolicy systemowego i dodatkowego pliku właściwości, Wczytano adb_debug.prop. Dzięki temu adb root będzie można uruchamiać wersję użytkownika system.img (GSI lub OEM).

W przypadku ogólnego obrazu jądra (GKI) na urządzeniach z partycją vendor_boot nie można zapisać obrazu boot-debug.img, ponieważ partycja boot musi być zapisana za pomocą certyfikowanego obrazu GKI. Zamiast tego interfejs vendor_boot-debug.img powinien zostać przesłany do interfejsu vendor_boot partycji, aby ułatwić debugowanie dysku RAM.

Wymagania wstępne dotyczące korzystania z pamieci RAM na potrzeby debugowania

Dysk Ramdisk debugowania jest udostępniany przez OEM, który przeprowadza testy zgodności. Nie musi być podpisany przez wydawcę i można go używać tylko wtedy, gdy urządzenie jest odblokowane.

Ramdysk debugowania nie będzie generowany ani używany do uaktualniania urządzeń z:

Prawda: BOARD_BUILD_SYSTEM_ROOT_IMAGE
skip_initramfs w wierszu poleceń jądra

Android 12 GSI

Do używania dysku ramdisk na potrzeby debugowania w Androidzie 12 GSI nie są wymagane żadne dodatkowe instrukcje.

Od 29 września 2021 r. pliki pamięci RAM debugowania nie wymagają już aktualizacji za pomocą repack_bootimg. Wersja GSI Androida 12, która po SGR1.210929.001 (7777720) zawiera aktualny plik userdebug_plat_sepolicy.cil w katalogu system.img i ignoruje plik userdebug_plat_sepolicy.cil z trybusu debugowania. Więcej informacji znajdziesz w specyfikacji CL.

Android 11 GSI

Gdy używasz boot-debug.img lub vendor_boot-debug.img, system wczytuje plik sepolicy z pliku userdebug_plat_sepolicy.cil na karcie pamięci RAM urządzenia boot-debug.img lub vendor_boot-debug.img. Aby uruchomić obrazy GSI, zawsze uwzględniaj aktualne zmiany w pliku sepolicy z gałęzi android11-gsi, aby odbudować obraz boot-debug.img lub vendor_boot-debug.img.

Można też użyć narzędzia repack_bootimg do ponownego utworzenia boot-debug.img lub vendor_boot-debug.img ze zaktualizowanymi zasadami dotyczącymi GSI.

Ponowne skompresowanie pliku RAMDSK na potrzeby debugowania

Zamiast wdrażać zmiany w sepolicy, aby ponownie skompilować boot-debug.img, partnerzy mogą użyć repack_bootimg, aby zaktualizować plik sepolicy GSI na boot-debug.img (lub vendor_boot-debug.img, jeśli urządzenie korzysta z GKI).

Wykonaj te czynności:

Pobierz otatools.zip z https://ci.android.com Zalecamy pobranie pliku z artefaktów kompilacji aosp_arm64-userdebug aosp-main.

Skonfiguruj środowisko wykonawcze repack_bootimg:

unzip otatools.zip -d otatools
export PATH="${PWD}/otatools/bin:${PATH}"
repack_bootimg --help

Pobierz plik userdebug_plat_sepolicy.cil lub boot-with-debug-ramdisk-${KERNEL_VERSION}.img z wersji GSI, której używasz. Jeśli na przykład używasz GSI arm64 z RJR1.211020.001 (7840830), pobierz z https://ci.android.com/builds/submitted/7840830/aosp_arm64-user/latest.

Ważne: wartość ${KERNEL_VERSION} nie ma tu znaczenia. Możesz użyć dowolnej boot-with-debug-ramdisk-${KERNEL_VERSION}.img.
Uwaga: od 27 września 2021 r. boot-debug-${KERNEL_VERSION}.img w kompilacji GSI jest została zmieniona na boot-with-debug-ramdisk-${KERNEL_VERSION}.img.

Zaktualizuj urządzenie boot-debug.img lub vendor_boot-debug.img do wersji userdebug_plat_sepolicy.cil:

repack_bootimg --local --dst_bootimg boot-debug.img \
    --ramdisk_add userdebug_plat_sepolicy.cil:userdebug_plat_sepolicy.cil \
    --ramdisk_add userdebug_plat_sepolicy.cil:first_stage_ramdisk/userdebug_plat_sepolicy.cil
# If using GKI
repack_bootimg --local --dst_bootimg vendor_boot-debug.img \
    --ramdisk_add userdebug_plat_sepolicy.cil:userdebug_plat_sepolicy.cil \
    --ramdisk_add userdebug_plat_sepolicy.cil:first_stage_ramdisk/userdebug_plat_sepolicy.cil

boot-with-debug-ramdisk-${KERNEL_VERSION}.img:

repack_bootimg --src_bootimg boot-with-debug-ramdisk-5.4.img \
    --dst_bootimg boot-debug.img \
    --ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:userdebug_plat_sepolicy.cil \
    --ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:first_stage_ramdisk/userdebug_plat_sepolicy.cil
# If using GKI
repack_bootimg --src_bootimg boot-with-debug-ramdisk-5.4.img \
    --dst_bootimg vendor_boot-debug.img \
    --ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:userdebug_plat_sepolicy.cil \
    --ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:first_stage_ramdisk/userdebug_plat_sepolicy.cil

Argumenty funkcji --ramdisk_add można dostosować w zależności od urządzenia. konfiguracji. Szczegółowe informacje znajdziesz w następnej sekcji.

Ścieżka do pliku userdebug sepolicy

Powyższe repack_bootimg kopiuje plik userdebug_plat_sepolicy.cil z ramdysk --src_bootimg do dysku RAM --dst_bootimg. Jednak ścieżka mogą się różnić w zależności od wersji Androida. W Androidzie 10 i 11 ścieżka to first_stage_ramdisk/userdebug_plat_sepolicy.cil na urządzeniach z androidboot.force_normal_boot=1 w wierszu poleceń jądra. W przeciwnym razie ścieżka to userdebug_plat_sepolicy.cil.

Uruchom to polecenie, aby sprawdzić, czy w maszynie androidboot.force_normal_boot w wierszu poleceń jądra:

adb root
adb shell cat /proc/cmdline | grep force_normal_boot

Od Androida 12 ścieżka w debugowaniu dysk ramdisk ma zawsze wartość userdebug_plat_sepolicy.cil, niezależnie od tego, czy istnieje androidboot.force_normal_boot=1 w wierszu poleceń jądra. Poniższa tabela zawiera ścieżki w pamięci RAM na potrzeby debugowania w różnych wersjach Androida.

Debugowanie obrazu	Android 10	Android 11	Android 12
GKI boot-with-debug-ramdisk-${KERNEL_VERSION}.img	Nie dotyczy	`first_stage_ramdisk/userdebug_plat_sepolicy.cil`	`userdebug_plat_sepolicy.cil`
boot-debug.img dla konkretnego urządzenia	Zależy od force_normal_boot	Zależy od force_normal_boot	`userdebug_plat_sepolicy.cil`
vendor_boot-debug.img dotyczący konkretnego urządzenia	Nie dotyczy	Zależy od parametru force_normal_boot	`userdebug_plat_sepolicy.cil`

Możesz użyć parametru --ramdisk_add, aby kopiować pliki z różnych ścieżek do innych ścieżek za pomocą listy par src_path:dst_path. Na przykład to polecenie skopiuje plik first_stage_ramdisk/userdebug_plat_sepolicy.cil z Androida 11 boot-with-debug-ramdisk-5.4.img do first_stage_ramdisk/userdebug_plat_sepolicy.cil w Androidzie 11 vendor_boot-debug.img.

repack_bootimg \
    --src_bootimg boot-with-debug-ramdisk-5.4.img \
    --dst_bootimg vendor_boot-debug.img \
    --ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:first_stage_ramdisk/userdebug_plat_sepolicy.cil

Jeśli w wierszu poleceń jądra nie ma parametru androidboot.force_normal_boot=1, należy zmienić polecenie w sposób pokazany poniżej, aby zmienić ścieżkę docelową na userdebug_plat_sepolicy.cil.

repack_bootimg \
    --src_bootimg boot-with-debug-ramdisk-5.4.img \
    --dst_bootimg vendor_boot-debug.img \
    --ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:userdebug_plat_sepolicy.cil

Dodawanie stopki AVB

Jeśli obraz przekazywany do --dst_bootimg jest skonfigurowany jako w łańcuchu AVB, partycji, po uruchomieniu repack_bootimg należy dodać stopkę AVB .

Na przykład przed uruchomieniem usługi repack_bootimg uruchom następujące polecenie, aby sprawdź, czy vendor_boot-debug.img ma łańcuchową stopkę AVB.

avbtool info_image --image vendor_boot-debug.img

Jeśli zawiera ona łańcuchową stopkę AVB, należy dodać stopkę AVB po wykonaniu polecenia repack_bootimg. Podpisywanie kluczami testowymi vendor_boot-debug.img działa, ponieważ Ramdysk debugowania może być używany tylko wtedy, gdy urządzenie jest odblokowane, co umożliwia używanie niezwalniających obrazów podpisanych kluczem na boot lub vendor_boot partycja.

avbtool add_hash_footer --partition_name vendor_boot \
    --partition_size 100663296 \
    --algorithm SHA256_RSA4096 \
    --key otatools/external/avb/test/data/testkey_rsa4096.pem \
    --image vendor_boot-debug.img