Questo documento fornisce istruzioni passo passo su come creare moduli multischermo e indica le limitazioni attuali, se note.
Il campione
Viene fornito un modulo multi-dispositivo CTS wifi-aware. Invia un messaggio da un dispositivo tramite Wi-Fi e verifica che l'altro dispositivo lo riceva.
L'origine del modulo si trova in packages/modules/Wifi/tests/hostsidetests/multidevices/test/aware/.
Abbiamo annotato l'esempio con tutti i commenti che riteniamo utili.
Passaggio 1: crea la cartella del modulo
Ti consigliamo di creare una cartella per il modulo multi-dispositivo nel progetto della suite a cui appartiene. Ad esempio: cts/hostsidetests/multidevices/. Consigliamo questa soluzione in modo che tutti i moduli multischermo rimangano raggruppati almeno all'inizio, il che semplificherà la scoperta degli esempi.
Tutti i file per questo modulo devono essere inseriti nella propria cartella del modulo. Ad
esempio: wifi_aware.
Passaggio 2: crea il test
È qui che implementi la logica di test. Dipende molto da cosa viene testato.
Crea l'origine di test Mobly, ad esempio: wifi_aware_test.py.
Passaggio 3: crea il file di build: Android.bp
Aggiungi un file Android.bp come packages/modules/Wifi/tests/hostsidetests/multidevices/test/Android.bp. Definisci un modulo python_test_host, simile 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",
],
}
Specifica gli snippet per il test con il campo dati, che verrà compresso con il file binario e può essere individuato e installato nel test da ATest o in esecuzione continua.
Gli snippet in bundle di Mobly sono disponibili in Android all'indirizzo external/mobly-bundled-snippets/.
(Facoltativo) Crea snippet personalizzati
Alcuni moduli multidevice potrebbero richiedere snippet Mobly personalizzati. Il test di esempio include uno snippet wifi-aware in packages/modules/Wifi/tests/hostsidetests/multidevices/com.google.snippet.wifi/aware/WifiAwareSnippet.java, che è creato con Mobly Snippet Lib, disponibile in Android all'indirizzo: external/mobly-snippet-lib/.
Lo snippet deve essere definito con la regola android_test in Android.bp come strumentazione standard:
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",
],
}
Passaggio 4: crea la configurazione del modulo: AndroidTest.xml
Aggiungi un file AndroidTest.xml come packages/modules/Wifi/tests/hostsidetests/multidevices/test/aware/AndroidTest.xml. In questa configurazione di test, devi specificare due dispositivi per il test, in modo simile 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>
Tieni presente che:
- Questo test di esempio ha una dipendenza da Mobly. È possibile specificare qualsiasi dipendenza
per
PythonVirtualenvPreparer, che verrà installata con pip. - Il
mobly-par-file-nameperMoblyBinaryHostTestdeve corrispondere al nome del modulo in Android.bp. - Specifica un
mobly-test-timeoutper il test. È espresso in millisecondi e si applica all'esecuzione completa del binario Python (tutti gli scenari di test insieme). Questo è necessario per evitare che gli scenari di test rimangano bloccati per sempre in caso di problemi. - Ogni tag
devicepuò contenere una configurazione distinta su ogni dispositivo. La configurazione di Mobly li riceverà nello stesso ordine specificato nel file XML.
Correlato all'installazione dell'apk dello snippet:
- Il POC iniziale è stato aggiornato per installare gli APK degli snippet tramite target_preparer a seguito di una conversazione con il team di copertura: per garantire che le misurazioni della copertura non vengano eliminate troppo presto, la disinstallazione da parte di Harness anziché dal codice di test nei binari Python offre garanzie migliori in termini di tempistiche.
Passaggio 5: esegui il test in locale: atest
Al momento, i test su più dispositivi vengono eseguiti solo su dispositivi fisici. Prima di eseguire il test, verifica che i dispositivi di test siano nello stato corretto. Il comando adb
devices dovrebbe restituire l'elenco dei dispositivi connessi. Se l'elenco contiene
dispositivi non destinati ai test, specifica i dispositivi per il test utilizzando il flag -s.
Per i test Wi-Fi, assicurati che il Wi-Fi sia attivo per i dispositivi (dopo il ripristino dei dati di fabbrica).
Puoi eseguire il test localmente con atest:
$ atest CtsWifiAwareTestCases
Nell'intestazione del riepilogo di un output di test dovresti vedere il numero di dispositivi utilizzati, ad esempio Test executed with 2 device(s).
Risoluzione dei problemi
Se il test non va a buon fine durante l'esecuzione in locale a causa di:
Errore virtualenv
java.io.IOException: Cannot run program
"virtualenv": error=2, No such file or directory
Assicurati che virtualenv si trovi nel tuo PATH. L'aggiunta di"~/.local/bin" a PATH dovrebbe
risolvere il problema.
Se virtualenv non è installato, segui la procedura descritta in https://virtualenv.pypa.io/en/latest/installation.html
Previsti almeno due oggetti controller, ma ne è stato ricevuto uno
I moduli di test sono multi-dispositivo o a dispositivo singolo, non esistono moduli misti. Se tenti di eseguire un modulo multi-dispositivo senza più dispositivi, verrà visualizzato questo errore:
Expected to get at least 2 controller objects, got 1
L'esecuzione del modulo in modalità multi-dispositivo risolverà il problema.
Per CTS: puoi utilizzare lo sharding per attivarlo (ad esempio: --shard-count 2)
o run cts-multidevces.