Módulos multidispositivo

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

A amostra

Um módulo CTS de vários dispositivos compatíveis com Wi-Fi é fornecido. Ele envia uma mensagem de um dispositivo por Wi-Fi e verifica se o outro dispositivo a recebe.

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

Anotamos o exemplo com o máximo de comentários que consideramos úteis.

Etapa 1: criar a pasta do módulo

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

Todos os arquivos desse módulo precisam ser colocados na pasta dele. Por exemplo: wifi_aware.

Etapa 2: criar o teste

É aqui que você implementa a lógica de teste. Isso depende muito do que está sendo testado.

Crie a origem de teste do Mobly, como: wifi_aware_test.py.

Etapa 3: criar o arquivo de build: 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 este:

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 snippets para o teste com o campo de dados, que será empacotado com o binário e poderá ser localizado e instalado no teste pelo ATest ou na execução contínua.

Os snippets agrupados do Mobly estão disponíveis no Android em external/mobly-bundled-snippets/.

Opcional: criar snippets personalizados

Alguns módulos de vários dispositivos podem exigir snippets personalizados do Mobly. O teste de exemplo inclui um snippet compatível com Wi-Fi em packages/modules/Wifi/tests/hostsidetests/multidevices/com.google.snippet.wifi/aware/WifiAwareSnippet.java, que é criado com a biblioteca de snippets do Mobly, disponível no Android em: external/mobly-snippet-lib/.

O snippet precisa 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: criar a configuração do módulo: AndroidTest.xml

Adicione um arquivo AndroidTest.xml como packages/modules/Wifi/tests/hostsidetests/multidevices/test/aware/AndroidTest.xml. Nessa configuração de teste, você precisa especificar dois dispositivos, semelhante 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>

Observação:

  • Esse teste de amostra tem dependência do Mobly. Qualquer dependência pode ser especificada para PythonVirtualenvPreparer e será instalada com o pip.
  • O mobly-par-file-namepara MoblyBinaryHostTest precisa corresponder ao nome do módulo, como em Android.bp.
  • Especifique um mobly-test-timeout para o teste. Ele está em milissegundos e se aplica à execução completa do binário Python (todos os casos de teste juntos). Isso é necessário para evitar que os casos de teste fiquem pendentes para sempre em caso de problemas.
  • Cada tag device pode conter uma configuração distinta em cada dispositivo. A configuração do Mobly vai recebê-las na mesma ordem especificada no XML.

Relacionado à instalação do APK do snippet:

  • A POC inicial foi atualizada 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 pelo Harness em vez de pelo código de teste em binários Python oferece melhores garantias em termos de tempo.

Etapa 5: executar o teste localmente: atest

No momento, os testes em vários dispositivos só são executados em dispositivos físicos. Antes de executar o teste, verifique se os dispositivos de teste estão no estado adequado. O comando adb devices vai mostrar a lista dos seus dispositivos conectados. Se a lista contiver dispositivos não destinados a testes, especifique os dispositivos para o teste usando a flag -s

Para testes de Wi-Fi, verifique se o Wi-Fi está ativado nos dispositivos (após a redefinição de fábrica).

É possível executar o teste localmente com o atest:

$ atest CtsWifiAwareTestCases

Você vai ver o número de dispositivos usados no cabeçalho do resumo na saída do atest, algo como Test executed with 2 device(s).

Solução de problemas

Se o teste falhar ao ser executado localmente devido a:

Erro do Virtualenv

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

Verifique se virtualenv está no seu PATH. Adicionar "~/.local/bin" ao PATH deve corrigir o problema. Se o virtualenv não estiver instalado, siga estas instruções: https://virtualenv.pypa.io/en/latest/installation.html

Era esperado receber pelo menos dois objetos controladores, mas só foi recebido um.

Os módulos de teste são para vários ou um único dispositivo. Não há módulos mistos. Se você tentar executar um módulo de vários dispositivos sem ter vários dispositivos, este erro vai aparecer:

Expected to get at least 2 controller objects, got 1

Executar o módulo no modo de vários dispositivos resolve o problema.

Para o CTS, use o sharding para acionar (por exemplo, --shard-count 2) ou run cts-multidevces.