Este documento proporciona instrucciones paso a paso sobre cómo crear módulos de dispositivos múltiples 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 cts/hostsidetests/multidevices/wifi_aware .
Hemos anotado el ejemplo con todos los comentarios que consideramos útiles.
Paso 1: crea la carpeta del módulo
Se recomienda crear una carpeta para su módulo multidispositivo en el proyecto de la suite al que pertenece. Por ejemplo: cts/hostsidetests/multidevices/ . Recomendamos esto para que todos los módulos de dispositivos múltiples 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 .
Por lo general, se requiere un archivo OWNERS para el módulo y se debe especificar el componente de error en él. Consulte cts/hostsidetests/multidevices/wifi_aware/OWNERS para ver un ejemplo.
Paso 2: Crear la prueba
Aquí es donde implementa su 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 cts/hostsidetests/multidevices/wifi_aware/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 pueden ser ubicados e instalados en la prueba por ATest o en ejecución continua.
Mobly Bundled Snippets están disponibles en Android en external/mobly-bundled-snippets/ .
Opcional: crea fragmentos personalizados
Algunos módulos multidispositivo pueden requerir fragmentos personalizados de Mobly. La prueba de muestra incluye un fragmento compatible con wifi en cts/hostsidetests/multidevices/wifi_aware/snippet/ , que está construido 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 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
Agregue un archivo AndroidTest.xml como cts/hostsidetests/multidevices/wifi_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 cuelguen para siempre en caso de que surjan algunos problemas. - Cada etiqueta de
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 XML.
Relacionado con la instalación del fragmento de apk:
- El POC inicial se actualizó 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 eliminen demasiado pronto, la desinstalación por Harness en lugar de por el código de prueba en los 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 debe 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 wifi, asegúrese de que wifi esté habilitado para los dispositivos (después del restablecimiento de fábrica).
Puede 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 de un solo dispositivo, no hay módulos mixtos. Si intenta ejecutar un módulo de dispositivos múltiples sin dispositivos múltiples, 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 .