O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Configuração de construção simples

Cada novo módulo de teste deve ter um arquivo de configuração para direcionar o sistema de construção com metadados do módulo, dependências de tempo de compilação e instruções de empacotamento. O Android agora usa o sistema de construção Soong para uma configuração de teste mais simples.

Soong usa arquivos Blueprint ou .bp , que são descrições declarativas simples semelhantes a JSON dos módulos a serem construídos. Este formato substitui o sistema baseado em Make usado em versões anteriores. Consulte os arquivos de referência do Soong no Painel de integração contínua para obter todos os detalhes.

Para acomodar testes personalizados ou usar o Android Compatibility Test Suite (CTS), siga a Complex Test Configuration .

Exemplo

As entradas abaixo vêm deste exemplo de arquivo de configuração do Blueprint: /platform_testing/tests/example/instrumentation/Android.bp

Um instantâneo está incluído aqui para sua conveniência:

android_test {
    name: "HelloWorldTests",
    srcs: ["src/**/*.java"],
    sdk_version: "current",
    static_libs: ["android-support-test"],
    certificate: "platform",
    test_suites: ["device-tests"],
}

Observe que a declaração android_test no início indica que este é um teste. Incluir android_app indicaria inversamente que este é um pacote de construção.

Configurações

As seguintes configurações obtêm explicações:

    name: "HelloWorldTests",

A configuração do name é necessária quando o tipo de módulo android_test é especificado (no início do bloco). Ele dá um nome ao seu módulo, e o APK resultante terá o mesmo nome e um sufixo .apk , por exemplo, neste caso, o apk de teste resultante é nomeado HelloWorldTests.apk . Além disso, isso também define um nome de destino do make para seu módulo, de forma que você possa usar make [options] <HelloWorldTests> para construir seu módulo de teste e todas as suas dependências.

    static_libs: ["android-support-test"],

A configuração static_libs instrui o sistema de construção a incorporar o conteúdo dos módulos nomeados no apk resultante do módulo atual. Isso significa que espera-se que cada módulo nomeado produza um arquivo .jar e seu conteúdo será usado para resolver referências de caminho de classe durante o tempo de compilação, bem como incorporado no apk resultante.

Neste exemplo, coisas que geralmente podem ser úteis para testes:

O android-support-test é o pré-construído para a Android Test Support Library, que inclui o novo AndroidJUnitRunner teste AndroidJUnitRunner : um substituto para o InstrumentationTestRunner integrado agora obsoleto, com suporte para a estrutura de teste JUnit4. Leia mais em Testar aplicativos no Android .

Se você estiver criando um novo módulo de instrumentação, deve sempre começar com a biblioteca android-support-test como executor de teste. A árvore de origem da plataforma também inclui outras estruturas de teste úteis, como ub-uiautomator , mockito-target , easymock e muito mais.

    certificate: "platform",

A configuração do certificate instrui o sistema de compilação a assinar o apk com o mesmo certificado da plataforma principal. Isso é necessário se o seu teste usar uma permissão protegida por assinatura ou API. Observe que isso é adequado para teste contínuo da plataforma, mas não deve ser usado em módulos de teste CTS. Observe que este exemplo usa esta configuração de certificado apenas para fins de ilustração: o código de teste do exemplo não precisa realmente que o apk de teste seja assinado com o certificado de plataforma especial.

Se você está escrevendo uma instrumentação para o seu componente que vive fora do servidor do sistema, ou seja, é empacotado mais ou menos como um apk de aplicativo regular, exceto que é integrado à imagem do sistema e pode ser um aplicativo privilegiado, é provável que sua instrumentação ter como alvo o pacote do aplicativo (consulte a seção abaixo sobre o manifesto) do seu componente. Nesse caso, o makefile do seu aplicativo pode ter sua própria configuração de certificate e seu módulo de instrumentação deve manter a mesma configuração. Isso ocorre porque para direcionar sua instrumentação no aplicativo em teste, o apk de teste e o apk do aplicativo devem ser assinados com o mesmo certificado.

Em outros casos, você não precisa ter essa configuração: o sistema de compilação simplesmente o assinará com um certificado integrado padrão, com base na variante de compilação, e normalmente é chamado de dev-keys .

    test_suites: ["device-tests"],

A configuração test_suites torna o teste facilmente detectável pelo equipamento de teste da Trade Federation. Outros conjuntos podem ser adicionados aqui, como CTS para que este teste possa ser compartilhado.

${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk

Configurações opcionais

As seguintes configurações opcionais obtêm explicações:

    test_config: "path/to/hello_world_test.xml"

A configuração test_config instrui o sistema de compilação de que seu destino de teste precisa de uma configuração específica. Por padrão, um AndroidTest.xml próximo ao Android.bp está associado ao config.

    auto_gen_config: true

A configuração auto_gen_config indica se deve ou não criar a configuração de teste automaticamente. Se AndroidTest.xml não existir próximo ao Android.bp , este atributo não precisa ser definido como true explicitamente.

    require_root: true

A configuração require_root instrui o sistema de compilação a adicionar RootTargetPreparer à configuração do teste gerado automaticamente. Isso garante que o teste seja executado com permissões de root.

    test_min_api_level: 29

A configuração test_min_api_level instrui o sistema de compilação a adicionar MinApiLevelModuleController à configuração de teste gerada automaticamente. Quando o Trade Federation executa a configuração do teste, o teste será ignorado se a propriedade do dispositivo de ro.product.first_api_level < test_min_api_level .