Testowanie VTS za pomocą dysku ramdisk debugowania

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 z testowaniem VTS, ponieważ mechanizm VTS wymaga do działania adb root, ale narzędzie adb root nie jest dostępne na urządzeniu kompilacji użytkownika.

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 proces testowania, ponieważ do testów CTS na GSI i VTS na GSI można używać tej samej kompilacji użytkownika na GSI system.img. W przypadku konfiguracji STS nadal wymagane jest użycie innego OEM-u userdebugsystem.img.

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

Zestaw testów Testowanie 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 -> user GSI

release signed

STS System OEM userdebug N Y Nowości w Q
VTS GSI użytkownik Y Y

userdebug -> GSI użytkownika

release signed

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 na partycję boot urządzenia, wczytywane są wersja userdebug pliku systemowego sepolicy i dodatkowy plik właściwości adb_debug.prop. Dzięki temu adb root może korzystać z wersji 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 vendor_boot-debug.img należy przeflashować na partycji vendor_boot, aby ułatwić debugowanie dysku RAM.

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

Pamięć RAM do debugowania jest dostarczana przez producenta OEM, który przeprowadza testy zgodności. Nie może być podpisane 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:

  • BOARD_BUILD_SYSTEM_ROOT_IMAGE prawda
  • skip_initramfs w wierszu poleceń jądra

Android 12 GSI

Aby używać debugowania w ramce z Androidem 12 GSI, nie musisz wykonywać żadnych dodatkowych czynności.

Od 29 września 2021 r. nie trzeba już aktualizować debugowanych dysków RAM za pomocą narzędzia 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żesz też użyć narzędzia repack_bootimg, aby odtworzyć plik boot-debug.img lub vendor_boot-debug.img z aktualizowanymi zasadami zabezpieczeń GSI.

Przepakowywanie pamięci RAM dysku 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).

Aby to zrobić:

  1. Pobierz otatools.zip ze strony https://ci.android.com. Zalecamy pobranie z archiwów kompilacji aosp_arm64-userdebug na aosp-main.

  2. Skonfiguruj środowisko wykonania dla repack_bootimg:

    unzip otatools.zip -d otatools
    export PATH="${PWD}/otatools/bin:${PATH}"
    repack_bootimg --help
  3. 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.

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

    Z użyciem aplikacji 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 informacje znajdziesz w następnej sekcji.

Ścieżka zasady sekwencji debugowania użytkownika

Powyższy wiersz kodu repack_bootimg kopiuje plik userdebug_plat_sepolicy.cil z dysku RAM --src_bootimg na dysk RAM --dst_bootimg. Ścieżka na dysku RAM debugowania może jednak być inna w różnych wersjach 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.

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

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

Od Androida 12 ścieżka na karcie pamięci debugowania jest zawsze userdebug_plat_sepolicy.cil, niezależnie od istnienia 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 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 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 parametru androidboot.force_normal_boot=1, należy zmienić polecenie w taki sposób, jak pokazano 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

Jeśli obraz przekazany do --dst_bootimg jest skonfigurowany jako partycja połączona z AVB, po wykonaniu polecenia repack_bootimg należy dodać stopkę AVB.

Na przykład przed uruchomieniem repack_bootimg uruchom to polecenie, aby sprawdzić, czy vendor_boot-debug.img ma łańcuchowy nagłówek AVB.

avbtool info_image --image vendor_boot-debug.img

Jeśli zawiera ona łańcuchową stopkę AVB, musisz dodać stopkę AVB po wykonaniu polecenia repack_bootimg. Użycie dowolnego klucza testowego do podpisania vendor_boot-debug.img działa, ponieważ dysk RAM do debugowania może być używany tylko wtedy, gdy urządzenie jest odblokowane, co umożliwia używanie obrazów podpisanych kluczem nieprzeznaczonym do wydania 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