En este documento, se proporcionan instrucciones paso a paso para crear módulos multidispositivo y se indican las limitaciones actuales cuando se conocen.
La muestra
Se proporciona un módulo multidispositivo compatible con Wi-Fi de CTS. Envía un mensaje desde un dispositivo a través de Wi-Fi y verifica que el otro dispositivo lo reciba.
La fuente del módulo se encuentra en packages/modules/Wifi/tests/hostsidetests/multidevices/test/aware/.
Anotamos el ejemplo con todos los comentarios que consideramos útiles.
Paso 1: Crea la carpeta del módulo
Se recomienda crear una carpeta para tu módulo multidispositivo en el proyecto del paquete al que pertenece. Por ejemplo: cts/hostsidetests/multidevices/. Te recomendamos que lo hagas para que todos los módulos multidispositivos permanezcan colocalizados, 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.
Crea la fuente de prueba de Mobly, como wifi_aware_test.py.
Paso 3: Crea el archivo de compilación: Android.bp
Agrega un archivo Android.bp, como packages/modules/Wifi/tests/hostsidetests/multidevices/test/Android.bp. Define un módulo python_test_host, similar al siguiente:
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",
],
}
Especifica los fragmentos para la prueba con el campo de datos, que se empaquetará con el objeto binario y que ATest o la ejecución continua pueden ubicar e instalar en la prueba.
Los fragmentos agrupados de Mobly están disponibles en Android en external/mobly-bundled-snippets/.
Opcional: Crea fragmentos personalizados
Es posible que algunos módulos multidispositivo requieran fragmentos de Mobly personalizados. La prueba de muestra incluye un fragmento adaptado al Wi-Fi en packages/modules/Wifi/tests/hostsidetests/multidevices/com.google.snippet.wifi/aware/WifiAwaresnippet.java, que se compila con la biblioteca de fragmentos de Mobly, disponible en Android en: external/mobly-snippet-lib/.
El fragmento debe definirse con la regla android_test en Android.bp como la 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: Crea la configuración del módulo: AndroidTest.xml
Agrega un archivo AndroidTest.xml, como packages/modules/Wifi/tests/hostsidetests/multidevices/test/aware/AndroidTest.xml. En esta configuración de prueba, debes especificar dos dispositivos para la prueba, similar a lo siguiente:
<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>
Ten en cuenta lo siguiente:
- Esta prueba de muestra tiene dependencia de Mobly. Se puede especificar cualquier dependencia para
PythonVirtualenvPreparery se instalará con pip. - El
mobly-par-file-namedeMoblyBinaryHostTestdebe coincidir con el nombre del módulo como en Android.bp. - Especifica un
mobly-test-timeoutpara la prueba. Se mide 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 haya algún problema. - Cada etiqueta
devicepuede contener una configuración distinta en cada dispositivo. La configuración de Mobly las recibirá en el mismo orden que se especifica en el archivo XML.
Relacionado con la instalación del APK del fragmento:
- Se actualizó la POC inicial para instalar apks 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 borren demasiado pronto, la desinstalación a través de Harness en lugar de código de prueba en objetos binarios de Python ofrece mejores garantías en términos de tiempo.
Paso 5: Ejecuta la prueba de forma local: atest
Actualmente, las pruebas multidispositivo solo se ejecutan en dispositivos físicos. Antes de ejecutar la
prueba, verifica que los dispositivos de prueba estén en el estado correcto. El comando adb
devices debería mostrar la lista de tus dispositivos conectados. Si la lista contiene dispositivos que no están destinados a pruebas, especifica los dispositivos para la prueba con la marca -s.
Para las pruebas de Wi-Fi, asegúrate de que la conexión esté habilitada en los dispositivos (después del restablecimiento de la configuración de fábrica).
Puedes ejecutar la prueba de manera local con atest:
$ atest CtsWifiAwareTestCases
Deberías ver la cantidad de dispositivos utilizados en el encabezado de resumen en el resultado de atest, algo como Test executed with 2 device(s).
Solución de problemas
Si la prueba falla cuando se ejecuta de forma local debido a lo siguiente:
Error de Virtualenv
java.io.IOException: Cannot run program
"virtualenv": error=2, No such file or directory
Asegúrate de que virtualenv esté en tu RUTA DE ACCESO. Si agregas “~/.local/bin” a PATH, debería solucionarse. Si virtualenv no está instalado, sigue las instrucciones que se indican en https://virtualenv.pypa.io/en/latest/installation.html.
Se esperaba obtener al menos 2 objetos de controlador, pero se obtuvo 1
Los módulos de prueba son de varios dispositivos o de un solo dispositivo, no hay módulos mezclados. Si intentas ejecutar un módulo multidispositivo sin varios dispositivos, verás este error:
Expected to get at least 2 controller objects, got 1
Ejecutar el módulo en el modo multidispositivo resolverá el problema.
Para CTS: Puedes usar el fragmentación para activarlo (por ejemplo, --shard-count 2)
o run cts-multidevces.