Testowanie VTS za pomocą dysku ramdisk debugowania

Od wersji Androida 10 Ogólny obraz systemu (GSI) użyty do uruchomienia. Zmieniono testowanie zgodności CTS-on-GSI/VTS od debugowania użytkownika do typu kompilacji użytkownika. To jest w przypadku testowania VTS, ponieważ VTS wymaga adb root, aby uruchomić, ale Komponent adb root nie jest dostępny na urządzeniu kompilacji użytkownika.

Wprowadzono dysk Ramdisk debugowania (lub obraz rozruchowy debugowania) umożliwiający włączenie adb root w urządzenie kompilacji użytkownika, którego program rozruchowy to bez blokady. 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

W tabeli poniżej znajdziesz zmiany obrazu i typu kompilacji na potrzeby testowania zgodności w Android 10.

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. Zezwala to usłudze adb root z kompilacją użytkownika system.img (GSI lub OEM).

Dla: Ogólny obraz jądra (GKI) przy użyciu urządzeń z partycją vendor_boot, boot-debug.img nie może być ponieważ partycja boot musi zawierać certyfikowany obraz 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 do korzystania z dysku ramdysk do debugowania

Dysk Ramdisk debugowania jest udostępniany przez OEM, który przeprowadza testy zgodności. it nie może być podpisana 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. Android 12 GSI po wprowadzeniu SGR1.210929.001 (7777720) zaktualizowanej wersji userdebug_plat_sepolicy.cil plik w stanie system.img i ignoruje userdebug_plat_sepolicy.cil z dysktu debugowania. Zobacz Zmiany w przypadku: .

Android 11 GSI

Gdy używana jest funkcja boot-debug.img lub vendor_boot-debug.img, system sepolicy jest wczytywany z pliku userdebug_plat_sepolicy.cil w debugowaniu RAM dysku boot-debug.img lub vendor_boot-debug.img. Aby uruchomić GSI należy uwzględniać najnowsze zmiany zasad z android11-gsi odbudowywanie gałęzi 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.

Przepakowywanie pamięci RAM dysku debugowania

Zamiast wprowadzać zmiany zasad w celu odbudowy instancji boot-debug.img, partnerzy może użyć repack_bootimg, by zaktualizować plik sepolicy GSI do boot-debug.img (lub vendor_boot-debug.img, jeśli urządzenie korzysta z GKI).

Wykonaj te czynności:

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

2. Skonfiguruj środowisko wykonawcze repack_bootimg:

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

3. Pobierz aplikację userdebug_plat_sepolicy.cil lub boot-with-debug-ramdisk-${KERNEL_VERSION}.img z wersji GSI, w której jesteś . Na przykład: jeśli używasz grupy arm64 GSI z RJR1.211020.001 (7840830), a potem 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 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
   

   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 zasady sekwencji debugowania użytkownika

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 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żej Tabela pokazuje ścieżki w ramach dysku ramdy debugowania w różnych wersjach Androida.

Możesz określić --ramdisk_add, aby kopiować pliki z i do innych ścieżek za pomocą atrybutu lista 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 polecenia androidboot.force_normal_boot=1, polecenie należy dostosować jak 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

Dodaj stopkę 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 pierwotnie miała łańcuchową stopkę AVB, musisz ją dodać po uruchomieniu 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