Module für mehrere Geräte

In diesem Dokument finden Sie eine detaillierte Anleitung zum Erstellen von Modulen für mehrere Geräte. Außerdem werden aktuelle Einschränkungen genannt, sofern bekannt.

Die Stichprobe

Es wird ein CTS-WLAN-fähiges Multi-Device-Modul bereitgestellt. Es sendet eine Nachricht von einem Gerät über WLAN und überprüft, ob das andere Gerät sie empfängt.

Die Quelle für das Modul befindet sich unter packages/modules/Wifi/tests/hostsidetests/multidevices/test/aware/.

Wir haben das Beispiel mit so vielen Kommentaren versehen, wie wir für sinnvoll halten.

Schritt 1: Modulordner erstellen

Es wird empfohlen, im zugehörigen Suite-Projekt einen Ordner für das Modul für mehrere Geräte zu erstellen. Beispiel: cts/hostsidetests/multidevices/. Wir empfehlen dies, damit alle Module für mehrere Geräte zumindest anfangs zusammenbleiben, was es einfacher macht, Beispiele zu finden.

Alle Dateien für dieses Modul sollten sich in einem eigenen Modulordner befinden. Beispiel: wifi_aware.

Schritt 2: Test erstellen

Hier implementieren Sie Ihre Testlogik. Das hängt stark davon ab, was getestet wird.

Erstellen Sie die Mobly-Testquelle, z. B. wifi_aware_test.py.

Schritt 3: Build-Datei erstellen: Android.bp

Fügen Sie eine Android.bp-Datei wie packages/modules/Wifi/tests/hostsidetests/multidevices/test/Android.bp hinzu. Definieren Sie ein python_test_host-Modul, ähnlich wie hier:

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",
    ],
}

Geben Sie die Snippets für den Test mit dem Datenfeld an. Sie werden mit dem Binärcode verpackt und können von ATest oder in der kontinuierlichen Ausführung im Test gefunden und installiert werden.

Mobly-Bundled-Snippets sind unter external/mobly-bundled-snippets/ auf Android-Geräten verfügbar.

Optional: Benutzerdefinierte Snippets erstellen

Für einige Mehrgeräte-Module sind möglicherweise benutzerdefinierte Mobly-Snippets erforderlich. Der Beispieltest enthält ein WLAN-fähiges Snippet unter packages/modules/Wifi/tests/hostsidetests/multidevices/com.google.snippet.wifi/aware/WifiAwareSnippet.java, das mit der Mobly-Snippet-Lib erstellt wurde. Diese ist unter Android unter external/mobly-snippet-lib/ verfügbar.

Das Snippet sollte in Android.bp mit der Regel „android_test“ wie bei der Standardinstrumentierung definiert werden:

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",
    ],
}

Schritt 4: Modulkonfiguration erstellen: AndroidTest.xml

Fügen Sie eine Datei „AndroidTest.xml“ wie packages/modules/Wifi/tests/hostsidetests/multidevices/test/aware/AndroidTest.xml hinzu. In dieser Testkonfiguration müssen Sie zwei Geräte für den Test angeben, z. B.:

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

Hinweis:

  • Dieser Beispieltest ist von Mobly abhängig. Für PythonVirtualenvPreparer können beliebige Abhängigkeiten angegeben werden, die dann mit pip installiert werden.
  • Die mobly-par-file-name für MoblyBinaryHostTest muss mit dem Modulnamen in Android.bp übereinstimmen.
  • Geben Sie für den Test eine mobly-test-timeout an. Sie wird in Millisekunden angegeben und bezieht sich auf die gesamte Ausführung der Python-Binärdatei (alle Testfälle zusammen). Dies ist erforderlich, um zu verhindern, dass Testfälle bei Problemen ewig hängen.
  • Jedes device-Tag kann auf jedem Gerät eine andere Einrichtung enthalten. Die Mobly-Konfiguration empfängt sie in der Reihenfolge, die in der XML-Datei angegeben ist.

Weitere Informationen zur Installation der Snippet-APK:

  • Der ursprüngliche POC wurde aufgrund einer Unterhaltung mit dem Coverage-Team aktualisiert, um Snippet-APKs über target_preparer zu installieren: Damit die Abdeckungsmessungen nicht zu früh gelöscht werden, bietet die Deinstallation über Harness anstelle von Testcode in Python-Binärdateien bessere Garantien in Bezug auf die Zeit.

Schritt 5: Test lokal ausführen: atest

Derzeit werden Multigerätetests nur auf physischen Geräten ausgeführt. Prüfen Sie vor dem Testen, ob sich Ihre Testgeräte im richtigen Zustand befinden. Der Befehl adb devices sollte eine Liste Ihrer verbundenen Geräte zurückgeben. Wenn die Liste Geräte enthält, die nicht für Tests vorgesehen sind, geben Sie die Geräte für den Test mit dem Flag „-s“ an.

Achten Sie bei WLAN-Tests darauf, dass das WLAN für die Geräte aktiviert ist (nach dem Zurücksetzen auf die Werkseinstellungen).

Sie können den Test lokal mit atest ausführen:

$ atest CtsWifiAwareTestCases

Die Anzahl der verwendeten Geräte sollte in der Zusammenfassung der Testausgabe angezeigt werden, z. B. Test executed with 2 device(s).

Fehlerbehebung

Wenn der Test bei der lokalen Ausführung aufgrund der folgenden Gründe fehlschlägt:

Virtualenv-Fehler

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

Prüfen Sie, ob virtualenv in Ihrem PATH enthalten ist. Wenn Sie „~/.local/bin“ zu PATH hinzufügen, sollte das Problem behoben werden. Wenn virtualenv nicht installiert ist, folgen Sie diesem Leitfaden: https://virtualenv.pypa.io/en/latest/installation.html

Es wurden mindestens 2 Controllerobjekte erwartet, aber nur 1 ermittelt

Testmodule sind entweder für mehrere Geräte oder für ein einzelnes Gerät gedacht. Es gibt keine gemischten Module. Wenn Sie versuchen, ein Modul für mehrere Geräte ohne mehrere Geräte auszuführen, wird dieser Fehler angezeigt:

Expected to get at least 2 controller objects, got 1

Wenn Sie das Modul im Modus für mehrere Geräte ausführen, wird das Problem behoben.

Für CTS: Sie können das Sharding verwenden, um ihn auszulösen (z. B. „–shard-count 2“) oder run cts-multidevces.