Kể từ ngày 27 tháng 3 năm 2025, bạn nên sử dụng android-latest-release thay vì aosp-main để xây dựng và đóng góp cho AOSP. Để biết thêm thông tin, hãy xem phần Thay đổi đối với AOSP.

Trang này được dịch bởi Cloud Translation API.

Cấu trúc AndroidTest.xml
Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.

Cấu trúc tổng thể của cấu hình mô-đun tuân theo mẫu tương tự như cấu hình XML Tradefed thông thường, nhưng có một số hạn chế do các cấu hình này chạy trong một bộ.

Danh sách thẻ được phép

AndroidTest.xml hoặc cấu hình mô-đun rộng hơn chỉ có thể chứa các thẻ XML sau: target_preparer, multi_target_preparer, test và metrics_collector.

Mặc dù danh sách đó có vẻ hạn chế, nhưng nó cho phép bạn xác định chính xác nhu cầu thiết lập mô-đun kiểm thử và bài kiểm thử để chạy.

LƯU Ý: Hãy xem phần Cấu hình XML được trao đổi nếu bạn cần xem lại các thẻ khác nhau.

Các đối tượng như build_provider hoặc result_reporter sẽ tạo ra một ConfigurationException nếu bạn cố gắng chạy từ bên trong cấu hình mô-đun. Điều này nhằm tránh kỳ vọng rằng các đối tượng thực sự thực hiện tác vụ nào đó từ bên trong một mô-đun.

Cấu hình mô-đun mẫu

<configuration description="Config for CTS Gesture test cases">
    <option name="test-suite-tag" value="cts" />
    <target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
        <option name="cleanup-apks" value="true" />
        <option name="test-file-name" value="CtsGestureTestCases.apk" />
    </target_preparer>
    <test class="com.android.tradefed.testtype.AndroidJUnitTest" >
        <option name="package" value="android.gesture.cts" />
        <option name="runtime-hint" value="10m50s" />
    </test>
</configuration>

Cấu hình này mô tả một chương trình kiểm thử yêu cầu CtsGestureTestCases.apk sẽ được cài đặt và chạy đo lường dựa trên android.gesture.cts .

Thẻ bao gồm `<include>` và `<template-include>`

Việc sử dụng <include> và <template-include> trong cấu hình mô-đun là không khuyến khích. Chúng tôi không đảm bảo rằng các tính năng này sẽ hoạt động như mong đợi.

Trường hợp đặc biệt cho thẻ metrics_collector

metrics_collector được cho phép nhưng chỉ giới hạn ở lớp FilePullerLogCollector để chỉ định một tệp hoặc thư mục nhất định cần được lấy và ghi nhật ký cho mô-đun. Cách này rất hữu ích nếu bạn để nhật ký ở một vị trí cụ thể và muốn khôi phục chúng một cách tự động.

Cấu hình mẫu:

<configuration description="Config for CTS UI Rendering test cases">
    <target_preparer class="com.android.tradefed.targetprep.suite.SuiteApkInstaller">
        <option name="cleanup-apks" value="true" />
        <option name="test-file-name" value="CtsUiRenderingTestCases.apk" />
    </target_preparer>
    <test class="com.android.tradefed.testtype.AndroidJUnitTest" >
        <option name="package" value="android.uirendering.cts" />
        <option name="runtime-hint" value="11m55s" />
        <option name="runner" value="android.uirendering.cts.runner.UiRenderingRunner" />
        <option name="isolated-storage" value="false" />
    </test>

    <!-- Collect the files in the dump directory for debugging -->
    <metrics_collector class="com.android.tradefed.device.metric.FilePullerLogCollector">
        <option name="directory-keys" value="/sdcard/UiRenderingCaptures" />
        <option name="collect-on-run-ended-only" value="true" />
    </metrics_collector>
</configuration>

Còn thông tin bản dựng hoặc nội dung tải xuống thì sao?

Định nghĩa về các thẻ được phép có thể gây ra ấn tượng không chính xác rằng một mô-đun sẽ không nhận được bất kỳ thông tin bản dựng nào. Điều này không đúng.

Thông tin bản dựng được cung cấp từ chế độ thiết lập cấp bộ và sẽ được tất cả mô-đun của bộ chia sẻ. Điều này cho phép bạn thiết lập một cấp cao nhất cho bộ ứng dụng để chạy tất cả các phần mô-đun của bộ ứng dụng.

Ví dụ: thay vì mỗi Bộ kiểm tra tính tương thích (CTS) truy vấn riêng thông tin, loại thiết bị, v.v. CTS chế độ thiết lập cấp phòng (cts.xml) thực hiện việc này một lần và mỗi mô-đun sẽ nhận được mã đó nếu họ yêu cầu.

Để các đối tượng trong mô-đun nhận được thông tin bản dựng, các đối tượng đó cần làm như trong cấu hình Tradefed thông thường: triển khai giao diện IBuildReceiver để nhận IBuildInfo. Xem kiểm thử bằng thiết bị để biết thêm chi tiết.

Trường siêu dữ liệu

Một số lượng lớn mô-đun kiểm thử có chứa một số thông số kỹ thuật metadata, mỗi loại lại có một mục tiêu riêng.

Ví dụ:

  <option name="config-descriptor:metadata" key="component" value="framework" />
  <option name="config-descriptor:metadata" key="parameter" value="instant_app" />
  <option name="config-descriptor:metadata" key="parameter" value="multi_abi" />
  <option name="config-descriptor:metadata" key="parameter" value="secondary_user" />

Thành phần

Siêu dữ liệu component mô tả thành phần Android chung cho mô-đun dự định thử nghiệm. Không ảnh hưởng trực tiếp đến quá trình chạy kiểm thử; đó là chủ yếu được sử dụng cho mục đích tổ chức.

Danh sách mới nhất về các thành phần được phép cho CTS có trong CtsConfigLoadingTest. Kiểm thử này không thành công trong phần gửi trước nếu một thành phần không tồn tại được thêm vào mô-đun CTS.

Bạn có thể lọc một loạt chương trình chạy dựa trên các thành phần bằng cách sử dụng module-metadata-include-filter và module-metadata-exclude-filter.

Ví dụ:

  --module-metadata-include-filter component framework

Ví dụ này chỉ chạy mô-đun kiểm thử được chú giải bằng framework thành phần.

Thông số

Siêu dữ liệu parameter là thông tin và ảnh hưởng đến quá trình thực thi kiểm thử. Tệp này chỉ định chế độ Android mà mô-đun kiểm thử áp dụng. Trong trường hợp này, chế độ bị giới hạn ở các chế độ Android cấp cao, chẳng hạn như instant apps, secondary users hoặc different abis.

Trong quá trình chạy bộ kiểm thử, nếu chế độ áp dụng cho kiểm thử, thì một số biến thể của mô-đun kiểm thử sẽ được tạo dựa trên chế độ đó. Mỗi biến thể chạy các thử nghiệm tương tự nhưng ở các chế độ khác nhau.

instant_app: Tạo một biến thể của các kiểm thử cài đặt tệp APK dưới dạng ứng dụng tức thì.
multi_abi: Tạo biến thể bài kiểm thử cho từng ABI mà thiết bị.
secondary_user: Tạo biến thể của các bài kiểm thử cài đặt APK và chạy kiểm thử với tư cách là người dùng phụ.

Thu thập và xử lý sau chỉ số cho các mô-đun kiểm thử hiệu suất

Đối với các mô-đun kiểm thử hiệu suất, metrics_collector cấp mô-đun và Bạn có thể dùng metric_post_processor vì đây là thành phần cần thiết trong các chương trình kiểm thử hiệu suất. Bộ thu thập chỉ số và bộ xử lý bài đăng ở cấp mô-đun có thể cụ thể theo từng mô-đun. Bạn không nên chỉ định trình xử lý hậu kỳ ở cả cấp cao nhất và cấp mô-đun.

Cấu hình mô-đun kiểm thử hiệu suất phải bao gồm siêu dữ liệu test-type với giá trị performance, chẳng hạn như: xml <option name="config-descriptor:metadata" key="test-type" value="performance" /> Nếu không, nếu cấu hình kiểm thử bao gồm metric_collector khác với FilePullerLogCollector hoặc bất kỳ metric_post_processor nào, thì quá trình kiểm thử sẽ không thành công trong quá trình gửi trước.

Ví dụ về cấu hình mô-đun kiểm thử hiệu suất:

<configuration description="Runs sample performance test.">
    <!-- Declare as a performance test module -->
    <option name="config-descriptor:metadata" key="test-type" value="performance" />
    <option name="test-tag" value="hello-world-performance-test" />
    <test class="com.android.tradefed.testtype.HostTest" >
        <option name="class" value="android.test.example.helloworldperformance.HelloWorldPerformanceTest" />
    </test>
    <!-- Add module-level post processor MetricFilePostProcessor -->
    <metric_post_processor class="com.android.tradefed.postprocessor.MetricFilePostProcessor">
        <option name="aggregate-similar-tests" value="true" />
        <option name="enable-per-test-log" value="false" />
    </metric_post_processor>
</configuration>

Cấu trúc AndroidTest.xml Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.