Módulos de vários dispositivos

Este documento fornece instruções passo a passo sobre como criar módulos para vários dispositivos e destaca as limitações atuais quando conhecidas.

A amostra

É fornecido um módulo multidispositivo CTS com reconhecimento de wifi. Ele envia uma mensagem de um dispositivo por wi-fi e verifica se o outro dispositivo a recebe.

A fonte do módulo está em packages/modules/Wifi/tests/hostsidetests/multidevices/test/aware/ .

Anotamos o exemplo com tantos comentários quanto consideramos úteis.

Etapa 1: crie a pasta do módulo

Recomenda-se criar uma pasta para o seu módulo multidispositivos no projeto da suíte ao qual ele pertence. Por exemplo: cts/hostsidetests/multidevices/ . Recomendamos isso para que todos os módulos multi-dispositivos permaneçam colocados pelo menos no início, o que facilitará a descoberta de exemplos.

Todos os arquivos deste módulo devem ser colocados em sua própria pasta de módulo. Por exemplo: wifi_aware .

Etapa 2: crie o teste

É aqui que você implementa sua lógica de teste. É altamente dependente do que está sendo testado.

Crie a fonte de teste Mobly, como: wifi_aware_test.py .

Etapa 3: Crie o arquivo de compilação: Android.bp

Adicione um arquivo Android.bp como packages/modules/Wifi/tests/hostsidetests/multidevices/test/Android.bp . Defina um módulo python_test_host, semelhante a:

python_test_host {
    name: "CtsWifiAwareTestCases",
    main: "wifi_aware_test.py",
    srcs: ["wifi_aware_test.py"],
    test_suites: [
        "cts",
        "general-tests",
    ],
    test_options: {
        unit_test: false,
    },
    data: [
          // Package the snippet with the mobly test
        ":wifi_aware_snippet",
    ],
}

Especifique os trechos para o teste com o campo data, que será empacotado com o binário e poderá ser localizado e instalado no teste pelo ATest ou em execução contínua.

Mobly Bundled Snippets estão disponíveis no Android em external/mobly-bundled-snippets/ .

Opcional: crie snippets personalizados

Alguns módulos para vários dispositivos podem exigir trechos personalizados do Mobly. O teste de amostra inclui um snippet com reconhecimento de wifi em packages/modules/Wifi/tests/hostsidetests/multidevices/com.google.snippet.wifi/aware/WifiAwareSnippet.java , que é construído com Mobly Snippet Lib, disponível no Android em: external /mobly-snippet-lib/ .

O snippet deve ser definido com a regra android_test em Android.bp como instrumentação padrão:

android_test {
    name: "wifi_aware_snippet",
    sdk_version: "current",
    srcs: [
        "CallbackUtils.java",
        "WifiAwareSnippet.java",
    ],
    manifest: "AndroidManifest.xml",
    static_libs: [
        "androidx.test.runner",
        "guava",
        "mobly-snippet-lib",
    ],
}

Etapa 4: crie a configuração do módulo: AndroidTest.xml

Adicione um arquivo AndroidTest.xml como packages/modules/Wifi/tests/hostsidetests/multidevices/test/aware/AndroidTest.xml . Nesta configuração de teste, você precisa especificar dois dispositivos para o teste, semelhantes a:

<configuration description="Config for CTS Wifi Aware test cases">
    <option name="test-suite-tag" value="cts" />
    <option name="config-descriptor:metadata" key="component" value="wifi" />
    <option name="config-descriptor:metadata" key="parameter" value="not_instant_app" />
    <option name="config-descriptor:metadata" key="parameter" value="not_multi_abi" />
    <option name="config-descriptor:metadata" key="parameter" value="not_secondary_user" />

    <device name="device1">
        <!-- For coverage to work, the APK should not be uninstalled until after coverage is pulled.
             So it's a lot easier to install APKs outside the python code.
        -->
        <target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
            <option name="test-file-name" value="wifi_aware_snippet.apk" />
        </target_preparer>
        <target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer">
            <option name="run-command" value="input keyevent KEYCODE_WAKEUP" />
            <option name="run-command" value="wm dismiss-keyguard" />
        </target_preparer>
        <target_preparer class="com.android.tradefed.targetprep.PythonVirtualenvPreparer">
          <!-- Any python dependencies can be specified and will be installed with pip -->
          <option name="dep-module" value="mobly" />
        </target_preparer>
    </device>
    <device name="device2">
        <target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
            <option name="test-file-name" value="wifi_aware_snippet.apk" />
        </target_preparer>
        <target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer">
            <option name="run-command" value="input keyevent KEYCODE_WAKEUP" />
            <option name="run-command" value="wm dismiss-keyguard" />
        </target_preparer>
    </device>

    <test class="com.android.tradefed.testtype.mobly.MoblyBinaryHostTest">
      <!-- The mobly-par-file-name should match the module name -->
      <option name="mobly-par-file-name" value="CtsWifiAwareTestCases" />
      <!-- Timeout limit in milliseconds for all test cases of the python binary -->
      <option name="mobly-test-timeout" value="60000" />
    </test>
</configuration>

Observe que:

  • Este teste de amostra depende do Mobly. Qualquer dependência pode ser especificada para PythonVirtualenvPreparer e será instalada com pip.
  • O mobly-par-file-name para MoblyBinaryHostTest deve corresponder ao nome do módulo como em Android.bp.
  • Especifique um mobly-test-timeout para o teste. Está em milissegundos e se aplica à execução binária completa do python (todos os casos de teste juntos). Isso é necessário para evitar que os casos de teste fiquem suspensos para sempre no caso de alguns problemas.
  • Cada tag device pode conter uma configuração distinta em cada dispositivo. A configuração do Mobly os receberá na mesma ordem especificada no XML.

Relacionado à instalação do snippet apk:

  • O POC inicial foi atualizado para instalar apks de snippet via target_preparer devido a uma conversa com a equipe de cobertura: Para garantir que as medições de cobertura não sejam excluídas muito cedo, a desinstalação por Harness em vez de por código de teste em binários Python oferece melhores garantias em termos de tempo.

Etapa 5: execute o teste localmente: atest

Atualmente, os testes de vários dispositivos são executados apenas em dispositivos físicos. Antes de executar o teste, verifique se os dispositivos de teste estão em bom estado. O comando adb devices deve relatar a lista de seus dispositivos conectados. Se a lista contiver dispositivos não destinados ao teste, especifique os dispositivos para teste usando o sinalizador -s.

Para testes de wi-fi, certifique-se de que o wi-fi esteja habilitado para os dispositivos (após a redefinição de fábrica).

Você pode executar o teste localmente com atest:

$ atest CtsWifiAwareTestCases

Você deverá ver o número de dispositivos usados ​​no cabeçalho de resumo em uma saída de teste, algo como Test executed with 2 device(s) .

Solução de problemas

Se o teste falhar ao ser executado localmente devido a:

Erro de ambiente virtual

java.io.IOException: Cannot run program
"virtualenv": error=2, No such file or directory

Certifique-se de virtualenv esteja em seu PATH. Adicionar "~/.local/bin" ao PATH deve corrigir o problema. se o virtualenv não estiver instalado, siga: https://virtualenv.pypa.io/en/latest/installation.html

Espera-se obter pelo menos 2 objetos de controlador, obteve 1

Os módulos de teste são multi-dispositivos ou de dispositivo único, não há módulos mistos. Se você tentar executar um módulo de vários dispositivos sem vários dispositivos, verá este erro:

Expected to get at least 2 controller objects, got 1

Executar o módulo no modo multidispositivos resolverá o problema.

Para CTS: você pode usar sharding para acioná-lo (por exemplo: --shard-count 2) ou run cts-multidevces .