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

Od Androida 10 ogólny obraz systemu (GSI) używany do przeprowadzania testów zgodności CTS-on-GSI/VTS zmienił typ kompilacji z userdebug na user, aby można było go podpisać przed wydaniem. Jest to problem w przypadku testów VTS, ponieważ wymagają one uruchomienia adb root, ale adb root nie jest dostępny na urządzeniu z wersją użytkownika.

Dysk RAM w trybie debugowania (lub obraz rozruchowy w trybie debugowania) został wprowadzony, aby włączyć adb root na urządzeniu z wersją użytkownika, którego program rozruchowy jest odblokowany. Upraszcza to proces testowania, ponieważ w przypadku testów CTS-on-GSI i VTS-on-GSI używana jest ta sama kompilacja użytkownika GSI system.img. W przypadku konfiguracji STS nadal wymagane jest użycie innego OEM system.img w wersji debugowania użytkownika.

W tabeli poniżej przedstawiono zmiany w obrazach i typach kompilacji na potrzeby testów zgodności w Androidzie 10.

Zestaw testów	Przetestuj za pomocą:	Build	Debugowanie dysku RAM	adb root?	Zmiana wariantu kompilacji z Androida 9 na 10
CTS	system OEM,	użytkownik	N	N	Bez zmian
CTS-on-GSI	GSI	użytkownik	N	N	userdebug -> user GSI wersja podpisana
STS	system OEM,	userdebug	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 boot-debug.img zostanie wgrany do partycji boot urządzenia, załadowana zostanie wersja userdebug pliku sepolicy systemu i dodatkowy plik właściwości adb_debug.prop. Umożliwia to adb root z kompilacją użytkownikasystem.img (GSI lub OEM).

W przypadku ogólnego obrazu jądra (GKI) na urządzeniach z partycją vendor_boot nie można flashować boot-debug.img, ponieważ partycja boot musi być flashowana za pomocą certyfikowanego obrazu GKI. Zamiast tego należy wgrać vendor_boot-debug.img do partycji vendor_boot, aby ułatwić debugowanie dysku RAM.

Wymagania wstępne dotyczące korzystania z dysku RAM do debugowania

Dysk RAM do debugowania jest dostarczany przez producenta OEM, który przeprowadza testy zgodności. Nie może być podpisana do wersji i może być używana tylko wtedy, gdy urządzenie jest odblokowane.

Dysk RAM do debugowania nie będzie generowany ani używany do uaktualniania urządzeń z tymi cechami:

BOARD_BUILD_SYSTEM_ROOT_IMAGE prawda
skip_initramfs w wierszu poleceń jądra

Obraz GSI Androida 12

Aby używać debug ramdisku z obrazem GSI Androida 12, nie musisz wykonywać żadnych dodatkowych czynności.

Od 29 września 2021 r. dyski RAM do debugowania nie wymagają już aktualizacji za pomocą narzędzia repack_bootimg. Kompilacja GSI Androida 12 po SGR1.210929.001 (7777720) zawiera aktualny plik userdebug_plat_sepolicy.cil w system.img i ignoruje userdebug_plat_sepolicy.cil z debug ramdisku. Szczegółowe informacje znajdziesz w sekcji CL.

Obraz GSI Androida 11

Gdy używana jest partycja boot-debug.img lub vendor_boot-debug.img, zasady SELinux są wczytywane z pliku userdebug_plat_sepolicy.cil w ramdysku debugowania partycji boot-debug.img lub vendor_boot-debug.img. Aby uruchomić obrazy GSI, zawsze uwzględniaj aktualne zmiany w zasadach SELinux z gałęzi android11-gsi, aby ponownie skompilować boot-debug.img lub vendor_boot-debug.img.

Możesz też użyć repack_bootimg narzędzia do ponownego tworzenia boot-debug.img lub vendor_boot-debug.img z aktualną polityką SELinux w GSI.

Ponowne pakowanie dysku RAM debugowania

Zamiast wprowadzać zmiany w zasadach SELinux w celu ponownego skompilowania boot-debug.img, partnerzy mogą użyć repack_bootimg, aby zaktualizować plik zasad SELinux GSI do boot-debug.img (lub vendor_boot-debug.img, jeśli urządzenie korzysta z GKI).

Aby to zrobić:

Pobierz otatools.zip ze strony https://ci.android.com. Zalecamy pobieranie z artefaktów kompilacji aosp_cf_arm64_only_phone-userdebug w gałęzi aosp-android-latest-release.

Skonfiguruj środowisko wykonawcze dla repack_bootimg:

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

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

Ważne: symbol ${KERNEL_VERSION} nie ma tu znaczenia. Możesz użyć dowolnego z tych plików:boot-with-debug-ramdisk-${KERNEL_VERSION}.img.
Uwaga: od 27 września 2021 r. w kompilacji GSI plik boot-debug-${KERNEL_VERSION}.img został zmieniony na boot-with-debug-ramdisk-${KERNEL_VERSION}.img.

Zaktualizuj urządzenie boot-debug.img lub vendor_boot-debug.img za pomocą 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

Z 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ć do konfiguracji urządzenia. Szczegółowe wyjaśnienie znajdziesz w następnej sekcji.

Ścieżka do pliku sepolicy w wersji userdebug

Powyższe polecenie repack_bootimg kopiuje plik userdebug_plat_sepolicy.cil z dysku RAM --src_bootimg na dysk RAM --dst_bootimg. Ścieżka w ramdysku debugowania może się jednak różnić w zależności od wersji Androida. W Androidzie 10 i 11 ścieżka to first_stage_ramdisk/userdebug_plat_sepolicy.cil w przypadku urządzeń z androidboot.force_normal_boot=1 w wierszu poleceń jądra. W przeciwnym razie ścieżka to userdebug_plat_sepolicy.cil.

Aby sprawdzić, czy w wierszu poleceń jądra znajduje się androidboot.force_normal_boot, uruchom to polecenie:

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

Od Androida 12 ścieżka w ramdysku debugowania jest zawsze userdebug_plat_sepolicy.cil, niezależnie od tego, czy w wierszu poleceń jądra istnieje androidboot.force_normal_boot=1. Poniższa tabela zawiera ścieżki w ramdysku debugowania w różnych wersjach Androida.

Obraz debugowania	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`
Plik boot-debug.img dla konkretnego urządzenia	Zależy od ustawienia force_normal_boot	Zależy od ustawienia force_normal_boot	`userdebug_plat_sepolicy.cil`
Plik vendor_boot-debug.img dla konkretnego urządzenia	Nie dotyczy	Zależy od ustawienia force_normal_boot	`userdebug_plat_sepolicy.cil`

Możesz określić --ramdisk_add, aby kopiować pliki z różnych ścieżek i do różnych ścieżek za pomocą listy par src_path:dst_path. Na przykład to polecenie kopiuje 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 znaku androidboot.force_normal_boot=1, dostosuj polecenie w sposób podany 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 przekazany do --dst_bootimg jest skonfigurowany jako partycja AVB-chained, po uruchomieniu polecenia repack_bootimg należy dodać stopkę AVB.

Na przykład przed uruchomieniem polecenia repack_bootimg uruchom to polecenie, aby sprawdzić, czy vendor_boot-debug.img ma połączony stopkę AVB:

avbtool info_image --image vendor_boot-debug.img

Jeśli pierwotnie zawiera stopkę AVB połączoną w łańcuch, po uruchomieniu polecenia repack_bootimg należy dodać stopkę AVB po. Użycie dowolnego klucza testowego do podpisania vendor_boot-debug.img działa, ponieważ dysk RAM do debugowania można używać tylko wtedy, gdy urządzenie jest odblokowane, co umożliwia używanie obrazów podpisanych kluczem innym niż klucz wersji na partycji boot lub vendor_boot.

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