En este documento, encontrarás instrucciones paso a paso sobre cómo crear apps multidispositivo módulos y menciona las limitaciones actuales cuando se conocen.
La muestra
Se proporciona un módulo multidispositivo con reconocimiento de Wi-Fi de CTS. Envía un mensaje desde una dispositivo a través de Wi-Fi y verifica que el otro 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 el módulo multidispositivos del paquete el proyecto al que pertenece. Por ejemplo: cts/hostsidetests/multidevices/. Recomendamos esta opción para que todos los módulos multidispositivo permanezcan ubicados al menos al menos lo que facilitará el descubrimiento de ejemplos.
Todos los archivos de este módulo deben colocarse en su propia carpeta de módulo. Para
ejemplo: wifi_aware.
Paso 2: Crea la prueba
Aquí es donde implementas la lógica de prueba. Depende mucho de lo que se que se está probando.
Crea la fuente de prueba de Mobly, como en el siguiente ejemplo: 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:
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 ATest puede ubicarse e instalarse en la prueba Ejecución continua.
Los fragmentos agrupados para Mobly 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 de reconocimiento de Wi-Fi en packages/modules/Wifi/tests/hostsidetests/multidevices/com.google.snippet.wifi/aware/WifiAwaresnippet.java, que se compiló 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 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. similares 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>
Ten en cuenta lo siguiente:
- Esta prueba de ejemplo depende de Mobly. Cualquier dependencia se puede especificar
para
PythonVirtualenvPreparery se instalará con pip. - El elemento
mobly-par-file-nameparaMoblyBinaryHostTestdebe coincidir con el módulo como en Android.bp. - Especifica un
mobly-test-timeoutpara la prueba. Es en milisegundos y Se aplica a la ejecución completa del objeto binario de Python (todos los casos de prueba juntos). Esto es necesario para evitar que los casos de prueba se detengan para siempre en caso de que surjan algunos problemas. - Cada etiqueta
devicepuede contener una configuración distinta en cada dispositivo, The Mobly. config los recibirá en el mismo orden que se especifica en el XML.
Relacionado con el fragmento de APK instalación:
- Se actualizó el POC inicial para instalar el APK de fragmentos a través de target_preparer debido a la conversación con el equipo de cobertura: Para garantizar Las mediciones de cobertura no se borran demasiado pronto, por lo que Harness las desinstala. en lugar de hacerlo por código de prueba en los binarios de Python ofrecen mejores garantías en términos del tiempo.
Paso 5: Ejecuta la prueba de manera local: atest
Actualmente, las pruebas multidispositivo solo se ejecutan en dispositivos físicos. Antes de ejecutar
verifica que los dispositivos de prueba
estén en el estado correcto. El comando adb
devices debería informar la lista de dispositivos conectados. Si la lista contiene
dispositivos que no están destinados a la prueba, especifica los dispositivos para la prueba mediante -s
marca.
Para realizar pruebas de Wi-Fi, asegúrate de que la red Wi-Fi esté habilitada para los dispositivos (después de restablecer la configuración de fábrica).
Puedes ejecutar la prueba de forma local con atest:
$ atest CtsWifiAwareTestCases
Deberías ver la cantidad de dispositivos usados en el encabezado de resumen de una prueba.
de salida, 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. Agregando "~/.local/bin" a PATH debe
y solucionar el problema.
Si virtualenv no está instalado, sigue estos pasos: https://virtualenv.pypa.io/en/latest/instructions.html
Se espera que obtengas al menos 2 objetos de control, pero hay 1
Los módulos de prueba pueden ser multidispositivos o de un solo dispositivo, módulos mixtos. 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 solucionará el problema.
Para CTS: Puedes usar la fragmentación para activarlo (por ejemplo: --shard-count 2)
o run cts-multidevces.