Modules multi-appareils

Ce document fournit des instructions détaillées sur la création de modules multi-appareils et indique les limites actuelles, le cas échéant.

L'échantillon

Un module CTS multi-appareils Wi-Fi Aware est fourni. Il envoie un message d'un appareil via le Wi-Fi et vérifie que l'autre appareil le reçoit.

La source du module se trouve à l'adresse packages/modules/Wifi/tests/hostsidetests/multidevices/test/aware/.

Nous avons annoté l'exemple avec autant de commentaires que nous le jugions utile.

Étape 1 : Créez le dossier du module

Nous vous recommandons de créer un dossier pour votre module multidétecteur dans le projet de suite auquel il appartient. Par exemple : cts/hostsidetests/multidevices/. Nous vous recommandons de le faire pour 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éez le test

C'est ici que vous implémentez la logique de votre test. Cela dépend fortement de ce qui est testé.

Créez la source de test Mobly, par exemple wifi_aware_test.py.

Étape 3 : Créez le fichier de compilation : Android.bp

Ajoutez un fichier Android.bp comme packages/modules/Wifi/tests/hostsidetests/multidevices/test/Android.bp. Définissez un module python_test_host, comme suit :

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 pour le test avec le champ de données, qui seront inclus dans le fichier binaire et pourront être localisés et installés dans le test par ATest ou dans l'exécution continue.

Les extraits groupés Mobly sont disponibles dans Android à l'adresse external/mobly-bundled-snippets/.

Facultatif : Créer des extraits personnalisés

Certains modules multi-appareils peuvent nécessiter des extraits Mobly personnalisés. L'exemple de test inclut un extrait Wifi-Aware à l'adresse packages/modules/Wifi/tests/hostsidetests/multidevices/com.google.snippet.wifi/aware/WifiAwareSnippet.java, qui est conçu avec la bibliothèque Mobly Snippet, disponible dans Android à l'adresse external/mobly-snippet-lib/.

L'extrait doit être défini avec la règle android_test dans Android.bp comme 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 tel que packages/modules/Wifi/tests/hostsidetests/multidevices/test/aware/AndroidTest.xml. Dans cette configuration de test, vous devez spécifier deux appareils pour le test, comme suit :

<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>

Remarque :

  • Cet exemple de test dépend de Mobly. Toute dépendance peut être spécifiée pour PythonVirtualenvPreparer et sera installée avec pip.
  • Le mobly-par-file-name de MoblyBinaryHostTest doit correspondre au nom du module dans Android.bp.
  • Spécifiez un mobly-test-timeout pour le test. Elle est exprimée en millisecondes et s'applique à l'exécution complète du binaire Python (tous les scénarios de test ensemble). Cela permet d'éviter que les scénarios de test ne restent bloqués indéfiniment en cas de problème.
  • Chaque balise device peut contenir une configuration distincte sur chaque appareil. La configuration Mobly les recevra dans le même ordre que celui spécifié dans le fichier XML.

Concernant l'installation de l'APK de l'extrait :

  • La première preuve de concept a été mise à jour pour installer les APK de snippets via target_preparer suite à une conversation avec l'équipe Coverage : afin de s'assurer 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écutez le test en local : 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 dans l'état approprié. La commande adb devices doit afficher la liste de vos appareils connectés. Si la liste contient des appareils qui ne sont pas destinés aux tests, spécifiez les appareils pour le test à l'aide de l'indicateur -s.

Pour les tests Wi-Fi, assurez-vous que le Wi-Fi est activé sur les appareils (après le rétablissement de la configuration d'usine).

Vous pouvez exécuter le test en local avec atest :

$ atest CtsWifiAwareTestCases

Vous devriez voir le nombre d'appareils utilisés dans l'en-tête du récapitulatif de la sortie atest, par exemple Test executed with 2 device(s).

Dépannage

Si le test échoue lors de l'exécution en local pour les raisons suivantes :

Erreur Virtualenv

java.io.IOException: Cannot run program
"virtualenv": error=2, No such file or directory

Veuillez vous assurer que virtualenv se trouve dans votre PATH. L'ajout de "~/.local/bin" à PATH devrait résoudre le problème. Si virtualenv n'est pas installé, suivez les instructions sur https://virtualenv.pypa.io/en/latest/installation.html.

Au moins deux objets de contrôleur étaient attendus, mais un seul a été reçu.

Les modules de test sont soit multi-appareils, soit mono-appareil. Il n'existe pas de modules mixtes. Si vous essayez d'exécuter un module multi-appareils sans plusieurs appareils, l'erreur suivante s'affiche :

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 le CTS : vous pouvez utiliser le partitionnement pour le déclencher (par exemple, --shard-count 2) ou run cts-multidevces.