Testowanie VTS za pomocą debugowanego dysku RAM

W Androidzie 10 i nowszych wersjach podstawowy obraz systemu (GSI) używany do przeprowadzania testów zgodności CTS-on-GSI/VTS został zmieniony z rodzaju kompilacji userdebug na rodzaj kompilacji user, aby można było go podpisać do wydania. Jest to problem w przypadku testów VTS, ponieważ wymagają one uruchomienia adb root, które adb root nie jest dostępne na urządzeniu z wersją user.

Aby włączyć adb root na urządzeniu z wersją user, którego program rozruchowy jest odblokowany, wprowadzono dysk RAM do debugowania (lub obraz rozruchowy do debugowania). Upraszcza to proces testowania, ponieważ w przypadku CTS-on-GSI i VTS-on-GSI używany jest ten sam obraz system.img w wersji user. W przypadku konfiguracji STS nadal wymagane jest użycie innego obrazu system.img w wersji userdebug od producenta.

W tabeli poniżej przedstawiamy zmiany obrazu i rodzaju kompilacji na potrzeby testów zgodności w Androidzie 10.

Przegląd

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, wczytana zostanie wersja userdebug pliku sepolicy systemu oraz dodatkowy plik właściwości, adb_debug.prop. Umożliwia to używanie polecenia adb root z obrazem system.img w wersji user (GSI lub producenta).

W przypadku urządzeń korzystających z ogólnego obrazu jądra (GKI) , które mają partycję vendor_boot, nie można wgrać pliku boot-debug.img, ponieważ na partycji boot musi być wgrany certyfikowany obraz GKI. Zamiast tego na partycję vendor_boot należy wgrać plik vendor_boot-debug.img, 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 przeprowadzającego testy zgodności. Nie może być podpisany do wydania i można go używać tylko wtedy, gdy urządzenie jest odblokowane.

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

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

GSI Androida 12

Aby używać dysku RAM do debugowania z GSI Androida 12, nie trzeba wykonywać żadnych dodatkowych instrukcji.

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 obrazie system.img i ignoruje plik userdebug_plat_sepolicy.cil z dysku RAM do debugowania. Szczegółowe informacje znajdziesz w CL.

GSI Androida 11

Gdy używany jest plik boot-debug.img lub vendor_boot-debug.img, sepolicy systemu jest wczytywana z pliku userdebug_plat_sepolicy.cil na dysku RAM do debugowania w pliku boot-debug.img lub vendor_boot-debug.img. Aby uruchomić obrazy GSI , zawsze uwzględniaj aktualne zmiany sepolicy z android11-gsi gałęzi, aby ponownie skompilować plik boot-debug.img lub vendor_boot-debug.img.

Możesz też użyć narzędzia repack_bootimg, aby ponownie skompilować plik boot-debug.img lub vendor_boot-debug.img z zaktualizowanym sepolicy GSI.

Ponowne pakowanie dysku RAM do debugowania

Zamiast uwzględniać zmiany sepolicy w celu ponownego skompilowania pliku boot-debug.img, partnerzy mogą użyć repack_bootimg, aby zaktualizować plik sepolicy GSI w pliku boot-debug.img (lub vendor_boot-debug.img, jeśli urządzenie korzysta z GKI).

Wykonaj te czynności:

1. Pobierz plik 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.

2. Skonfiguruj środowisko wykonawcze dla narzędzia 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 używanej kompilacji GSI. Jeśli na przykład używasz GSI arm64 z RJR1.211020.001 (7840830), pobierz go ze strony 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

   W przypadku pliku 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 --ramdisk_add można dostosować do konfiguracji urządzenia. Szczegółowe wyjaśnienie znajdziesz w następnej sekcji.

Ścieżka do sepolicy 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 dysku RAM do 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 parametrem 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ę parametr androidboot.force_normal_boot, uruchom to polecenie:

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

W Androidzie 12 i nowszych wersjach ścieżka w dysku RAM do debugowania jest zawsze userdebug_plat_sepolicy.cil, niezależnie od tego, czy w wierszu poleceń jądra znajduje się parametr androidboot.force_normal_boot=1. W tabeli poniżej przedstawiamy ścieżki w dysku RAM do debugowania w różnych wersjach Androida.

Możesz określić parametr --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 pliku boot-with-debug-ramdisk-5.4.img Androida 11 do pliku first_stage_ramdisk/userdebug_plat_sepolicy.cil w pliku vendor_boot-debug.img Androida 11.

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 dostosować polecenie w sposób opisany 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 połączona z AVB, po uruchomieniu polecenia repack_bootimg należy dodać stopkę AVB.

Aby na przykład przed uruchomieniem polecenia repack_bootimg sprawdzić, czy plik vendor_boot-debug.img ma połączoną stopkę AVB, uruchom to polecenie:

avbtool info_image --image vendor_boot-debug.img

Jeśli pierwotnie ma połączoną stopkę AVB, należy ją dodać po uruchomieniu polecenia repack_bootimg. Użycie dowolnego klucza testowego do podpisania pliku 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 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