En este documento, se proporcionan instrucciones paso a paso para crear módulos de varios dispositivos y se indican las limitaciones actuales cuando se conocen.
La muestra
Se proporciona un módulo de varios dispositivos con reconocimiento de Wi-Fi del 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 tantos comentarios como consideramos útiles.
Paso 1: Crea la carpeta del módulo
Se recomienda crear una carpeta para el módulo de varios dispositivos en el proyecto de la suite al que pertenece. Por ejemplo: cts/hostsidetests/multidevices/. Recomendamos esto para que todos los módulos de varios dispositivos permanezcan ubicados en el mismo lugar, 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 la 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 a lo 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 de la prueba con el campo de datos, que se empaquetará con el objeto binario y ATest o la ejecución continua podrán ubicarlo e instalarlo en la prueba.
Los fragmentos agrupados de Mobly están disponibles en Android en external/mobly-bundled-snippets/.
Crea fragmentos personalizados (opcional)
Es posible que algunos módulos multidispositivo requieran fragmentos de Mobly personalizados. La prueba de muestra incluye un fragmento con reconocimiento de Wi-Fi en packages/modules/Wifi/tests/hostsidetests/multidevices/com.google.snippet.wifi/aware/WifiAwareSnippet.java, que se compila con Mobly Snippet Lib, 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, de manera 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-nameparaMoblyBinaryHostTestdebe coincidir con el nombre del módulo como en Android.bp. - Especifica 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 problemas. - Cada etiqueta
devicepuede contener una configuración distinta en cada dispositivo. La configuración de Mobly los recibirá en el mismo orden en que se especifican en el XML.
Relacionado con la instalación de APK de fragmentos:
- Se actualizó el POC inicial para instalar APK de fragmentos a través de target_preparer debido a la conversación con el equipo de cobertura: Para garantizar que las mediciones de cobertura no se borren demasiado pronto, la desinstalación por Harness en lugar de por 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 tus dispositivos de prueba estén en el estado correcto. El comando adb
devices debe informar la lista de tus dispositivos conectados. Si la lista contiene dispositivos que no están destinados a las pruebas, especifica los dispositivos para la prueba con la marca -s.
Para las pruebas de Wi-Fi, asegúrate de que Wi-Fi esté habilitado para los dispositivos (después del restablecimiento de la configuración de fábrica).
Puedes ejecutar la prueba de forma local con atest:
$ atest CtsWifiAwareTestCases
Deberías ver la cantidad de dispositivos que se usan en el encabezado del 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. Agregar "~/.local/bin" a la RUTA DE ACCESO debería solucionarlo. Si virtualenv no está instalado, sigue estos pasos: 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 mixtos. Si intentas ejecutar un módulo de varios dispositivos sin varios dispositivos, verás este error:
Expected to get at least 2 controller objects, got 1
Ejecutar el módulo en el modo de varios dispositivos resolverá el problema.
Para CTS: Puedes usar la fragmentación para activarlo (por ejemplo, --shard-count 2) o run cts-multidevces.