Este documento proporciona instrucciones paso a paso sobre cómo crear módulos multidispositivo y menciona las limitaciones actuales cuando se conocen.
La muestra
Se proporciona un módulo multidispositivo compatible con wifi CTS. Envía un mensaje desde un dispositivo a través de wifi y verifica que el otro dispositivo lo reciba.
La fuente del módulo está en packages/modules/Wifi/tests/hostsidetests/multidevices/test/aware/ .
Hemos anotado el ejemplo con tantos comentarios como consideramos útiles.
Paso 1: crea la carpeta del módulo
Se recomienda crear una carpeta para su módulo multidispositivo en el proyecto de suite al que pertenece. Por ejemplo: cts/hostsidetests/multidevices/ . Recomendamos esto para que todos los módulos multidispositivos permanezcan colocados al menos al principio, lo que facilitará el descubrimiento de ejemplos.
Todos los archivos de este módulo deben colocarse en su propia carpeta de módulo. Por ejemplo: wifi_aware .
Paso 2: crea la prueba
Aquí es donde implementas tu lógica de prueba. Depende en gran medida de lo que se esté probando.
Cree la fuente de prueba de Mobly, como: wifi_aware_test.py .
Paso 3: cree el archivo de compilación: Android.bp
Agregue un archivo Android.bp como packages/modules/Wifi/tests/hostsidetests/multidevices/test/Android.bp . Defina un módulo python_test_host, similar 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 los fragmentos para la prueba con el campo de datos, que se empaquetarán con el binario y se pueden ubicar e instalar en la prueba mediante ATest o en ejecución continua.
Los fragmentos empaquetados de Mobly están disponibles en Android en external/mobly-bundled-snippets/ .
Opcional: cree fragmentos personalizados
Algunos módulos multidispositivo pueden requerir fragmentos de Mobly personalizados. La prueba de muestra incluye un fragmento compatible con wifi en packages/modules/Wifi/tests/hostsidetests/multidevices/com.google.snippet.wifi/aware/WifiAwareSnippet.java , que está creado con Mobly Snippet Lib, disponible en Android en: externo /mobly-snippet-lib/ .
El fragmento debe definirse con la regla android_test en Android.bp como instrumentación estándar:
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",
],
}
Paso 4: cree la configuración del módulo: AndroidTest.xml
Agregue un archivo AndroidTest.xml como paquetes/modules/Wifi/tests/hostsidetests/multidevices/test/aware/AndroidTest.xml . En esta configuración de prueba, debe especificar dos dispositivos para la prueba, similar 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>
Note que:
- Esta prueba de muestra depende de Mobly. Se puede especificar cualquier dependencia para
PythonVirtualenvPreparery se instalará con pip. - El
mobly-par-file-nameparaMoblyBinaryHostTestdebe coincidir con el nombre del módulo como en Android.bp. - Especifique un
mobly-test-timeoutpara la prueba. Está en milisegundos y se aplica a la ejecución binaria completa de Python (todos los casos de prueba juntos). Esto es necesario para evitar que los casos de prueba se bloqueen para siempre en caso de que surjan algunos problemas. - Cada etiqueta
devicepuede contener una configuración distinta en cada dispositivo. La configuración de Mobly las recibirá en el mismo orden especificado en el XML.
Relacionado con la instalación de apk de fragmento:
- La POC inicial se actualizó para instalar aplicaciones de fragmentos a través de target_preparer debido a una conversación con el equipo de Cobertura: para garantizar que las mediciones de cobertura no se eliminen demasiado pronto, la desinstalación mediante Harness en lugar de mediante código de prueba en binarios de Python ofrece mejores garantías en términos de tiempo.
Paso 5: Ejecute la prueba localmente: atest
Actualmente, las pruebas multidispositivo solo se ejecutan en dispositivos físicos. Antes de ejecutar la prueba, verifique que sus dispositivos de prueba estén en buen estado. El comando adb devices debería informar la lista de sus dispositivos conectados. Si la lista contiene dispositivos que no están destinados a la prueba, especifique los dispositivos para la prueba usando el indicador -s.
Para las pruebas de wifi, asegúrese de que el wifi esté habilitado para los dispositivos (después del restablecimiento de fábrica).
Puedes ejecutar la prueba localmente con atest:
$ atest CtsWifiAwareTestCases
Debería ver la cantidad de dispositivos utilizados en el encabezado de resumen en una salida de prueba, algo así como Test executed with 2 device(s) .
Solución de problemas
Si la prueba falla cuando se ejecuta localmente debido a:
Error de entorno virtual
java.io.IOException: Cannot run program
"virtualenv": error=2, No such file or directory
Asegúrese de que virtualenv esté en su RUTA. Agregar "~/.local/bin" a PATH debería solucionarlo. Si virtualenv no está instalado, siga: https://virtualenv.pypa.io/en/latest/installation.html
Se esperaba obtener al menos 2 objetos de controlador, obtuve 1
Los módulos de prueba son multidispositivos o monodispositivos, no hay módulos mixtos. Si intenta ejecutar un módulo multidispositivo sin varios dispositivos, verá este error:
Expected to get at least 2 controller objects, got 1
Ejecutar el módulo en modo multidispositivo resolverá el problema.
Para CTS: puede usar fragmentación para activarlo (por ejemplo: --shard-count 2) o run cts-multidevces .