Mô-đun đa thiết bị

Tài liệu này cung cấp hướng dẫn từng bước về cách tạo mô-đun đa thiết bị và chỉ ra các giới hạn hiện tại khi biết.

Mẫu

Một mô-đun đa thiết bị nhận biết wifi CTS được cung cấp. Nó gửi tin nhắn từ một thiết bị qua wifi và xác minh thiết bị kia nhận được tin nhắn đó.

Nguồn của mô-đun nằm ở packages/modules/Wifi/tests/hostsidetests/multidevices/test/aware/ .

Chúng tôi đã chú thích ví dụ với nhiều nhận xét mà chúng tôi cảm thấy hữu ích.

Bước 1: Tạo thư mục mô-đun

Bạn nên tạo một thư mục cho mô-đun đa thiết bị của mình trong dự án bộ sản phẩm chứa nó. Ví dụ: cts/hostsidetests/multidevices/ . Chúng tôi khuyến nghị điều này để ít nhất lúc đầu tất cả các mô-đun đa thiết bị vẫn được sắp xếp cùng nhau, điều này sẽ giúp khám phá các ví dụ dễ dàng hơn.

Tất cả các tập tin cho mô-đun này phải được đặt trong thư mục mô-đun riêng của chúng. Ví dụ: wifi_aware .

Bước 2: Tạo bài kiểm tra

Đây là nơi bạn triển khai logic thử nghiệm của mình. Nó phụ thuộc nhiều vào những gì đang được thử nghiệm.

Tạo nguồn kiểm tra Mobly, như: wifi_aware_test.py .

Bước 3: Tạo file build: Android.bp

Thêm tệp Android.bp như packages/modules/Wifi/tests/hostsidetests/multidevices/test/Android.bp . Xác định mô-đun python_test_host, tương tự như:

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

Chỉ định các đoạn mã cho thử nghiệm bằng trường dữ liệu, trường này sẽ được đóng gói bằng tệp nhị phân và có thể được định vị và cài đặt trong thử nghiệm bằng ATest hoặc trong Thực thi liên tục.

Đoạn mã được đóng gói trên Mobly có sẵn trong Android tại external/mobly-bundled-snippets/ .

Tùy chọn: Tạo đoạn mã tùy chỉnh

Một số mô-đun đa thiết bị có thể yêu cầu đoạn mã Mobly tùy chỉnh. Thử nghiệm mẫu bao gồm một đoạn mã nhận biết wifi tại packages/modules/Wifi/tests/hostsidetests/multidevices/com.google.snippet.wifi/aware/WifiAwareSnippet.java , được xây dựng bằng Mobly Snippet Lib, có sẵn trong Android tại: external /mobly-snippet-lib/ .

Đoạn mã phải được xác định bằng quy tắc android_test trong Android.bp giống như công cụ đo lường tiêu chuẩn:

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

Bước 4: Tạo cấu hình mô-đun: AndroidTest.xml

Thêm tệp AndroidTest.xml như packages/modules/Wifi/tests/hostsidetests/multidevices/test/aware/AndroidTest.xml . Trong cấu hình thử nghiệm này, bạn cần chỉ định hai thiết bị để thử nghiệm, tương tự như:

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

Chú ý rằng:

  • Thử nghiệm mẫu này phụ thuộc vào Mobly. Mọi phần phụ thuộc đều có thể được chỉ định cho PythonVirtualenvPreparer và sẽ được cài đặt bằng pip.
  • mobly-par-file-name cho MoblyBinaryHostTest phải khớp với tên mô-đun như trong Android.bp.
  • Hãy chỉ định mobly-test-timeout cho bài kiểm tra. Nó tính bằng mili giây và áp dụng cho việc thực thi nhị phân python hoàn chỉnh (tất cả các trường hợp thử nghiệm cùng nhau). Điều này là cần thiết để tránh trường hợp thử nghiệm bị treo vĩnh viễn trong trường hợp có một số vấn đề.
  • Mỗi thẻ device có thể chứa một thiết lập riêng biệt trên mỗi thiết bị, Cấu hình Mobly sẽ nhận chúng theo thứ tự như được chỉ định trong XML.

Liên quan đến cài đặt apk đoạn trích:

  • POC ban đầu đã được cập nhật để cài đặt các đoạn mã thông qua target_preparer do cuộc trò chuyện với nhóm Bảo hiểm: Để đảm bảo các phép đo mức độ phù hợp không bị xóa quá sớm, việc gỡ cài đặt bằng Harness thay vì bằng mã kiểm tra trong mã nhị phân Python mang lại sự đảm bảo tốt hơn về mặt thời gian.

Bước 5: Chạy thử nghiệm cục bộ: atest

Hiện tại, thử nghiệm đa thiết bị chỉ chạy trên các thiết bị vật lý. Trước khi chạy thử nghiệm, hãy xác minh rằng thiết bị thử nghiệm của bạn ở trạng thái thích hợp. Lệnh adb devices sẽ báo cáo danh sách các thiết bị được kết nối của bạn. Nếu danh sách chứa các thiết bị không dành cho thử nghiệm, hãy chỉ định các thiết bị để thử nghiệm bằng cờ -s.

Để kiểm tra wifi, hãy đảm bảo bật wifi cho thiết bị (sau khi khôi phục cài đặt gốc).

Bạn có thể chạy thử nghiệm cục bộ với atest:

$ atest CtsWifiAwareTestCases

Bạn sẽ thấy số lượng thiết bị được sử dụng trong tiêu đề tóm tắt ở đầu ra chứng thực, chẳng hạn như Test executed with 2 device(s) .

Xử lý sự cố

Nếu kiểm tra không thành công khi chạy cục bộ do:

Lỗi ảo

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

Hãy đảm bảo virtualenv có trong PATH của bạn. Việc thêm "~/.local/bin" vào PATH sẽ khắc phục được. nếu virtualenv chưa được cài đặt, hãy làm theo: https://virtualenv.pypa.io/en/latest/installation.html

Dự kiến ​​sẽ nhận được ít nhất 2 đối tượng điều khiển, có 1

Các mô-đun thử nghiệm là nhiều thiết bị hoặc một thiết bị, không có mô-đun hỗn hợp. Nếu bạn cố chạy mô-đun nhiều thiết bị mà không có nhiều thiết bị, bạn sẽ thấy lỗi này:

Expected to get at least 2 controller objects, got 1

Việc thực thi mô-đun ở chế độ đa thiết bị sẽ giải quyết được vấn đề.

Đối với CTS: Bạn có thể sử dụng sharding để kích hoạt nó (Ví dụ: --shard-count 2) hoặc run cts-multidevces .