Ce document fournit des instructions étape par étape sur la façon de créer des modules multi-périphériques et signale les limitations actuelles lorsqu'elles sont connues.
L'échantillon
Un module multi-périphériques compatible Wi-Fi CTS est fourni. Il envoie un message depuis un appareil via Wi-Fi et vérifie que l'autre appareil le reçoit.
La source du module se trouve dans packages/modules/Wifi/tests/hostsidetests/multidevices/test/aware/ .
Nous avons annoté l'exemple avec autant de commentaires que nous jugeons utiles.
Étape 1 : Créer le dossier du module
Il est recommandé de créer un dossier pour votre module multi-appareils dans le projet de suite auquel il appartient. Par exemple : cts/hostsidetests/multidevices/ . Nous le recommandons afin que tous les modules multi-appareils restent colocalisés au moins au début, ce qui facilitera la découverte d'exemples.
Tous les fichiers de ce module doivent être placés dans leur propre dossier de module. Par exemple : wifi_aware .
Étape 2 : Créer le test
C'est ici que vous implémentez votre logique de test. Cela dépend fortement de ce qui est testé.
Créez la source de test Mobly, comme : wifi_aware_test.py .
Étape 3 : Créez le fichier de build : Android.bp
Ajoutez un fichier Android.bp comme packages/modules/Wifi/tests/hostsidetests/multidevices/test/Android.bp . Définissez un module python_test_host, similaire à :
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",
],
}
Spécifiez les extraits du test avec le champ de données, qui seront emballés avec le binaire et pourront être localisés et installés dans le test par ATest ou en exécution continue.
Les extraits de code Mobly Bundled sont disponibles sur Android à l' adresse external/mobly-bundled-snippets/ .
Facultatif : Créez des extraits personnalisés
Certains modules multi-appareils peuvent nécessiter des extraits Mobly personnalisés. L'exemple de test inclut un extrait compatible Wi-Fi dans packages/modules/Wifi/tests/hostsidetests/multidevices/com.google.snippet.wifi/aware/WifiAwareSnippet.java , qui est construit avec Mobly Snippet Lib, disponible sur Android à l'adresse : externe /mobly-snippet-lib/ .
L'extrait doit être défini avec la règle android_test dans Android.bp comme l'instrumentation 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",
],
}
Étape 4 : Créez la configuration du module : AndroidTest.xml
Ajoutez un fichier AndroidTest.xml comme packages/modules/Wifi/tests/hostsidetests/multidevices/test/aware/AndroidTest.xml . Dans cette configuration de test, vous devez spécifier deux appareils pour le test, semblables à :
<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>
Notez que :
- Cet exemple de test dépend de Mobly. Toute dépendance peut être spécifiée pour
PythonVirtualenvPrepareret sera installée avec pip. - Le
mobly-par-file-namepourMoblyBinaryHostTestdoit correspondre au nom du module comme dans Android.bp. - Spécifiez un
mobly-test-timeoutpour le test. Il est en millisecondes et s'applique à l'exécution binaire complète de Python (tous les cas de test ensemble). Ceci est nécessaire pour éviter que les cas de test ne soient suspendus pour toujours en cas de problèmes. - Chaque balise
devicepeut contenir une configuration distincte sur chaque appareil. La configuration Mobly les recevra dans le même ordre que celui spécifié dans le XML.
Lié à l'installation de l'extrait d'apk :
- Le POC initial a été mis à jour pour installer des apks d'extraits via target_preparer en raison d'une conversation avec l'équipe Coverage : afin de garantir que les mesures de couverture ne sont pas supprimées trop tôt, la désinstallation par Harness plutôt que par le code de test dans les binaires Python offre de meilleures garanties en termes de timing.
Étape 5 : Exécuter le test localement : atest
Actuellement, les tests multi-appareils ne s’exécutent que sur des appareils physiques. Avant d'exécuter le test, vérifiez que vos appareils de test sont en bon état. La commande adb devices doit signaler la liste de vos appareils connectés. Si la liste contient des appareils non destinés au test, spécifiez les appareils à tester à l'aide de l'indicateur -s.
Pour les tests Wi-Fi, assurez-vous que le Wi-Fi est activé pour les appareils (après la réinitialisation d'usine).
Vous pouvez exécuter le test localement avec atest :
$ atest CtsWifiAwareTestCases
Vous devriez voir le nombre de périphériques utilisés dans l'en-tête récapitulatif de la sortie du test, quelque chose comme Test executed with 2 device(s) .
Dépannage
Si le test échoue lors de son exécution locale en raison de :
Erreur d'environnement virtuel
java.io.IOException: Cannot run program
"virtualenv": error=2, No such file or directory
Veuillez vous assurer que virtualenv est dans votre PATH. L'ajout de "~/.local/bin" à PATH devrait résoudre le problème. si virtualenv n'est pas installé, suivez : https://virtualenv.pypa.io/en/latest/installation.html
Je m'attendais à obtenir au moins 2 objets contrôleur, j'en ai obtenu 1
Les modules de test sont soit multi-appareils, soit mono-appareil, il n'y a pas de modules mixtes. Si vous essayez d'exécuter un module multi-appareils sans plusieurs appareils, vous verrez cette erreur :
Expected to get at least 2 controller objects, got 1
L'exécution du module en mode multi-appareils résoudra le problème.
Pour CTS : vous pouvez utiliser le partitionnement pour le déclencher (par exemple : --shard-count 2) ou run cts-multidevces .