Testes VTS com ramdisk de depuração

Desde o Android 10, Imagem genérica do sistema (GSI) usada para execução. O teste de compliance CTS-on-GSI/VTS mudou do tipo de build "userdebug" para o tipo de build "user" para ter assinatura de lançamento. Esta é uma problema para o teste do VTS porque ele exige adb root para ser executado, mas O adb root não está disponível em dispositivos 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 é desbloqueado. Isso simplifica os testes usando a mesma GSI de build do usuário system.img para CTS-on-GSI e VTS na GSI. Para a configuração do STS, ainda é necessário usar outro OEM system.img de userdebug obrigatórios.

A tabela a seguir mostra as mudanças de imagem e tipo de build para testes de compliance em Android 10

Pacote de testes Testar com Criar Depurar o ramdisk raiz do adb? Android 9 -> Mudança de 10 variantes de build
CTS Sistema do OEM user N N Sem mudanças
CTS-on-GSI (link em inglês) GSI user N N

userdebug -> GSI do usuário

versão assinada

STS Sistema do OEM userdebug N Y Novidades no trimestre
VTS (em inglês) GSI user Y Y

userdebug -> GSI do usuário

versão assinada

Visão geral

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

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

Quando a boot-debug.img é atualizada na partição boot do dispositivo, a a versão userdebug do arquivo sepolicy do sistema e um arquivo de propriedade adicional, adb_debug.prop foram carregadas. Isso permite que adb root com o build do usuário system.img (GSIs ou OEMs).

Para Imagem genérica do kernel (GKI) usar dispositivos que tenham uma partição vendor_boot, boot-debug.img não podem ser atualizada, já que a partição boot precisa ser atualizada com uma imagem GKI certificada. Em vez disso, a vendor_boot-debug.img precisa ser transferida por flash para o vendor_boot. para facilitar a depuração do ramdisk.

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

O ramdisk de depuração é fornecido pelo OEM que executa os testes de conformidade. Ela não pode ser assinado por 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 verdadeiro
  • skip_initramfs na linha de comando do kernel
.

GSI do Android 12

Nenhuma outra instrução é 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 precisarão mais ser atualizados com a Ferramenta repack_bootimg. GSI do Android 12 build após SGR1.210929.001 (7777720) incorporar a versão userdebug_plat_sepolicy.cil no system.img e ignora userdebug_plat_sepolicy.cil no ramdisk de depuração. Consulte a CLs para detalhes.

GSI do Android 11

Quando boot-debug.img ou vendor_boot-debug.img são usados, o sistema sepolicy é carregado do arquivo userdebug_plat_sepolicy.cil na depuração ramdisk da boot-debug.img ou do vendor_boot-debug.img. Para inicializar a GSI imagens, incorpore sempre mudanças atualizadas de sepolicy do android11-gsi para recriar a boot-debug.img ou o 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 sepolicy da GSI atualizada.

Recompactar um ramdisk de depuração

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

As etapas são as seguintes:

  1. Baixar o otatools.zip de https://ci.android.com (link em inglês). Recomendamos fazer o download dos artefatos de build de aosp_arm64-userdebug em aosp-main.

  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 do build da GSI que você está usando. Por exemplo, se você estiver usando uma GSI arm64 da RJR1.211020.001 (7840830), depois faça o download pelo https://ci.android.com/builds/submitted/7840830/aosp_arm64-user/latest (link em inglês).

  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 o dispositivo personalizadas. Consulte a próxima seção para mais detalhes. explicação.

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 podem ser diferentes em versões distintas do Android. Em 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 o caminho é 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

No Android 12 e versões mais recentes, o caminho em uma depuração o ramdisk é sempre userdebug_plat_sepolicy.cil, independentemente da existência de androidboot.force_normal_boot=1 na linha de comando do kernel. O seguinte mostra os caminhos em um ramdisk de depuração em diferentes versões do Android.

Depurar imagem 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
Atributo específico do dispositivo fornecedor_boot-debug.img N/A Depende de force_normal_boot userdebug_plat_sepolicy.cil

Você pode especificar --ramdisk_add para copiar arquivos de e para caminhos diferentes com um lista de pares src_path:dst_path. Por exemplo, o comando a seguir copia o arquivo first_stage_ramdisk/userdebug_plat_sepolicy.cil de uma boot-with-debug-ramdisk-5.4.img do Android 11 para first_stage_ramdisk/userdebug_plat_sepolicy.cil em uma 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 deve ser ajustado conforme abaixo para alterar 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 um Encadeamento AVB partição, um rodapé AVB precisa ser adicionado depois de executar a repack_bootimg kubectl.

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

avbtool info_image --image vendor_boot-debug.img

Se ele originalmente tiver um rodapé AVB encadeado, será necessário adicionar um rodapé da AVB. 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 de chave de não liberação no 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