Testes VTS com ramdisk de depuração

Desde o Android 10, a imagem genérica do sistema (GSI) usada para executar o teste de conformidade CTS-on-GSI/VTS mudou do tipo de compilação userdebug para user para ser assinada para lançamento. Isso é um problema para os testes do VTS porque ele requer a execução de adb root, mas adb root não está disponível em um dispositivo de build de usuário.

O ramdisk de depuração (ou imagem de inicialização de depuração) é introduzido para ativar o adb root em um dispositivo de build do usuário cujo carregador de inicialização está desbloqueado. Isso simplifica o fluxo de testes usando a mesma GSI de build do usuário system.img para CTS-on-GSI e VTS-on-GSI. Para a configuração do STS, ainda é necessário usar outro system.img OEM userdebug.

A tabela a seguir mostra as mudanças no tipo de imagem e build para testes de conformidade no Android 10.

Pacote de testes Teste com Criar Ramdisk de depuração adb root? Mudança na variante de build do Android 9 para o 10
CTS Sistema do OEM user N N Sem alterações
CTS-on-GSI GSI user N N

userdebug -> GSI do usuário

versão assinada

STS Sistema do OEM userdebug N Y Novidade no Q
VTS GSI user Y Y

userdebug -> GSI do usuário

versão assinada

Visão geral

Esses arquivos de imagem adicionais são gerados na pasta de build (${ANDROID_PRODUCT_OUT}):

  • boot-debug.img
  • vendor_boot-debug.img

Quando o boot-debug.img é atualizado na partição boot do dispositivo, a versão userdebug do arquivo sepolicy do sistema e um arquivo de propriedade adicional, adb_debug.prop, são carregados. Isso permite adb root com a compilação de usuário system.img (GSI ou do OEM).

Para Imagem genérica do kernel (GKI) usando dispositivos com uma partição vendor_boot, não é necessário atualizar com flash boot-debug.img, já que a partição boot precisa ser atualizada com flash com uma imagem GKI certificada. Em vez disso, vendor_boot-debug.img precisa ser gravado na partição vendor_boot para facilitar o ramdisk de depuração.

Pré-requisitos para usar um ramdisk de depuração

O ramdisk de depuração é fornecido pelo OEM que executa os testes de conformidade. Ele não pode ser assinado para lançamento e só pode ser usado se o dispositivo estiver desbloqueado.

O ramdisk de depuração não será gerado nem usado para fazer upgrade de dispositivos com:

  • BOARD_BUILD_SYSTEM_ROOT_IMAGE true
  • skip_initramfs na linha de comando do kernel

GSI do Android 12

Nenhuma instrução adicional é necessária para usar o ramdisk de depuração com a GSI do Android 12.

A partir de 29/09/2021, os ramdisks de depuração não precisam mais ser atualizados com a ferramenta repack_bootimg. O build da GSI do Android 12 após SGR1.210929.001 (7777720) incorpora o arquivo userdebug_plat_sepolicy.cil atualizado no system.img e ignora userdebug_plat_sepolicy.cil do ramdisk de depuração. Consulte as CLs para mais detalhes.

GSI do Android 11

Quando o boot-debug.img ou o vendor_boot-debug.img é usado, a política de segurança do sistema é carregada do arquivo userdebug_plat_sepolicy.cil no ramdisk de depuração do boot-debug.img ou do vendor_boot-debug.img. Para inicializar imagens GSI, sempre incorpore mudanças atualizadas de sepolicy da ramificação android11-gsi para recriar seu boot-debug.img ou vendor_boot-debug.img.

Como alternativa, a ferramenta repack_bootimg pode ser usada para recriar um boot-debug.img ou vendor_boot-debug.img com a política do SELinux da GSI atualizada.

Recompactar um ramdisk de depuração

Em vez de incorporar mudanças na sepolicy para reconstruir boot-debug.img, os parceiros podem usar repack_bootimg para atualizar o arquivo sepolicy da GSI em boot-debug.img (ou vendor_boot-debug.img se o dispositivo usar o GKI).

Estas são as etapas:

  1. Baixe otatools.zip em https://ci.android.com. Recomendamos baixar dos artefatos de build de aosp_cf_arm64_only_phone-userdebug na ramificação aosp-android-latest-release.

  2. Configure o ambiente de execução para repack_bootimg:

    unzip otatools.zip -d otatools
    export PATH="${PWD}/otatools/bin:${PATH}"
    repack_bootimg --help
  3. Faça o download do userdebug_plat_sepolicy.cil ou boot-with-debug-ramdisk-${KERNEL_VERSION}.img da build da GSI que você está usando. Por exemplo, se você estiver usando uma GSI arm64 de RJR1.211020.001 (7840830), faça o download em https://ci.android.com/builds/submitted/7840830/aosp_arm64-user/latest.

  4. Atualize o dispositivo boot-debug.img ou vendor_boot-debug.img com 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

    Com 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

    Os argumentos de --ramdisk_add podem ser ajustados de acordo com as configurações do dispositivo. Consulte a próxima seção para uma explicação detalhada.

Caminho da sepolicy userdebug

O repack_bootimg acima copia o arquivo userdebug_plat_sepolicy.cil do ramdisk de --src_bootimg para o ramdisk de --dst_bootimg. No entanto, o caminho em um ramdisk de depuração pode ser diferente em versões diferentes do Android. No Android 10 e 11, o caminho é first_stage_ramdisk/userdebug_plat_sepolicy.cil para dispositivos com androidboot.force_normal_boot=1 na linha de comando do kernel. Caso contrário, o caminho será userdebug_plat_sepolicy.cil.

Execute o seguinte comando para verificar se há androidboot.force_normal_boot na linha de comando do kernel:

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

A partir do Android 12, o caminho em um ramdisk de depuração é sempre userdebug_plat_sepolicy.cil, independente da existência de androidboot.force_normal_boot=1 na linha de comando do kernel. A tabela a seguir mostra os caminhos em um ramdisk de depuração em diferentes versões do Android.

Imagem de depuração Android 10 Android 11 Android 12
GKI boot-with-debug-ramdisk-${KERNEL_VERSION}.img N/A first_stage_ramdisk/userdebug_plat_sepolicy.cil userdebug_plat_sepolicy.cil
boot-debug.img específico do dispositivo Depende de "force_normal_boot" Depende de "force_normal_boot" userdebug_plat_sepolicy.cil
vendor_boot-debug.img específico do dispositivo N/A Depende de "force_normal_boot" userdebug_plat_sepolicy.cil

É possível especificar --ramdisk_add para copiar arquivos de e para caminhos diferentes com uma lista de pares src_path:dst_path. Por exemplo, o comando a seguir copia o arquivo first_stage_ramdisk/userdebug_plat_sepolicy.cil de um boot-with-debug-ramdisk-5.4.img do Android 11 para first_stage_ramdisk/userdebug_plat_sepolicy.cil em um vendor_boot-debug.img do Android 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

Se não houver androidboot.force_normal_boot=1 na linha de comando do kernel, o comando precisará ser ajustado conforme abaixo para mudar o caminho de destino para 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

Se a imagem transmitida para --dst_bootimg estiver configurada como uma partição encadeada por AVB, um rodapé do AVB precisará ser adicionado após a execução do comando repack_bootimg.

Por exemplo, antes de executar repack_bootimg, execute o comando a seguir para verificar se um vendor_boot-debug.img tem um rodapé AVB encadeado.

avbtool info_image --image vendor_boot-debug.img

Se ele tiver um rodapé AVB encadeado, um rodapé AVB precisará ser adicionado depois de executar o comando repack_bootimg. Usar qualquer chave de teste para assinar o vendor_boot-debug.img funciona porque o ramdisk de depuração só pode ser usado quando um dispositivo está desbloqueado, o que permite imagens assinadas com chaves não de lançamento na partição boot ou 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