Mulai 27 Maret 2025, sebaiknya gunakan android-latest-release, bukan aosp-main, untuk mem-build dan berkontribusi pada AOSP. Untuk mengetahui informasi selengkapnya, lihat Perubahan pada AOSP.

Halaman ini diterjemahkan oleh Cloud Translation API.

Struktur AndroidTest.xml
Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Struktur keseluruhan konfigurasi modul mengikuti pola yang mirip dengan konfigurasi XML Tradefed reguler, tetapi dengan beberapa batasan karena fakta bahwa konfigurasi tersebut berjalan sebagai bagian dari suite.

Daftar tag yang diizinkan

AndroidTest.xml atau konfigurasi modul secara lebih luas hanya dapat berisi tag XML berikut: target_preparer, multi_target_preparer, test, dan metrics_collector.

Meskipun daftar tersebut terlihat membatasi, daftar tersebut memungkinkan Anda menentukan dengan tepat kebutuhan penyiapan modul pengujian dan pengujian yang akan dijalankan.

CATATAN: Lihat Konfigurasi XML Tradefed jika Anda perlu mengulang materi tentang berbagai tag.

Objek seperti build_provider atau result_reporter akan memunculkan ConfigurationException jika dicoba untuk dijalankan dari dalam modul konfigurasi Anda. Hal ini dimaksudkan untuk menghindari objek yang sebenarnya melakukan tugas dari dalam modul.

Contoh konfigurasi modul

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

Konfigurasi ini menjelaskan pengujian yang memerlukan CtsGestureTestCases.apk untuk diinstal dan akan menjalankan instrumentasi terhadap android.gesture.cts paket.

Tag penyertaan `<include>` dan `<template-include>`

Penggunaan <include> dan <template-include> dalam konfigurasi modul adalah tidak disarankan. Tidak dijamin akan berfungsi seperti yang diharapkan.

Kasus khusus untuk tag metrics_collector

metrics_collector diizinkan tetapi terbatas pada FilePullerLogCollector untuk menentukan file atau direktori tertentu yang akan ditarik dan dicatat dalam log modul ini. Hal ini berguna jika Anda menyimpan log di lokasi tertentu dan ingin memulihkannya secara otomatis.

Contoh konfigurasi:

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

Bagaimana dengan info build atau download?

Definisi tag yang diizinkan mungkin memberikan tayangan iklan yang salah bahwa tidak akan mendapatkan informasi build. Hal ini tidak benar.

Informasi build disediakan dari penyiapan tingkat suite dan akan dibagikan oleh semua modul suite. Hal ini memungkinkan satu penyiapan tingkat teratas untuk suite guna menjalankan semua modul yang merupakan bagian dari suite.

Misalnya, setiap modul Compatibility Test Suite (CTS) tidak perlu mengkueri informasi, jenis, dll. perangkat satu per satu. Penyiapan tingkat suite CTS (cts.xml) melakukannya sekali dan setiap modul akan menerima informasi tersebut jika memintanya.

Agar objek dalam modul dapat menerima informasi build, mereka perlu untuk melakukan hal yang sama seperti dalam konfigurasi Tradefed reguler: Antarmuka IBuildReceiver untuk menerima IBuildInfo. Lihat menguji dengan perangkat untuk mengetahui detail selengkapnya.

Kolom metadata

Sejumlah besar modul pengujian menyertakan beberapa spesifikasi metadata, yang masing-masing memiliki tujuan unik.

Contoh:

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

Komponen

Metadata component menjelaskan komponen Android umum yang ingin diuji modul. Hal ini tidak memiliki dampak langsung pada eksekusi pengujian; hal ini secara khusus digunakan untuk tujuan organisasi.

Daftar terbaru komponen yang diizinkan untuk CTS tersedia di CtsConfigLoadingTest. Pengujian ini gagal dalam pra-pengiriman jika komponen yang tidak ada ditambahkan ke modul CTS.

Anda dapat memfilter suite yang dijalankan berdasarkan komponen menggunakan module-metadata-include-filter dan module-metadata-exclude-filter.

Contoh:

  --module-metadata-include-filter component framework

Contoh ini hanya menjalankan modul pengujian yang dianotasi dengan komponen framework.

Parameter

Metadata parameter bersifat informatif dan berdampak pada pengujian dalam proses eksekusi. Ini menentukan mode Android tempat modul pengujian diterapkan. Dalam hal ini, mode dibatasi untuk mode Android tingkat tinggi, seperti instant apps, secondary users, atau different abis.

Selama suite berjalan, jika mode diterapkan untuk pengujian, beberapa variasi modul pengujian dibuat berdasarkan mode. Setiap variasi berjalan pengujian serupa tetapi dengan mode yang berbeda.

instant_app: Membuat variasi pengujian yang menginstal APK sebagai aplikasi instan.
multi_abi: Membuat variasi pengujian untuk setiap ABI yang didukung oleh perangkat seluler.
secondary_user: Membuat variasi pengujian yang menginstal APK dan menjalankan pengujian sebagai pengguna sekunder.

Pengumpulan metrik dan pascapemrosesan untuk modul pengujian performa

Untuk modul pengujian performa, metrics_collector dan tingkat modul metric_post_processor diizinkan karena penting untuk pengujian performa. Kolektor metrik dan pasca-prosesor tingkat modul dapat bersifat khusus modul. Sebaiknya jangan tentukan post-processor di tingkat teratas dan modul.

Konfigurasi modul pengujian performa harus menyertakan metadata test-type dengan nilai performance, seperti: xml <option name="config-descriptor:metadata" key="test-type" value="performance" /> Tanpa ini, jika konfigurasi pengujian menyertakan metric_collector selain FilePullerLogCollector atau metric_post_processor apa pun, pengujian akan gagal dalam pra-pengiriman.

Contoh konfigurasi modul pengujian performa:

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

Struktur AndroidTest.xml Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.