Penyiapan pengujian

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

Rangkaian pengujian

Agar pengujian menjadi bagian dari VTS, pengujian harus memiliki setelan berikut di Android.bp.

test_suites: ["vts"],

Selain itu, menambahkan pengujian ke suite general-tests memungkinkan bagian dari paket Pemetaan Pengujian yang digunakan dalam pemeriksaan pra-pengiriman.

Konfigurasi pengujian

Dalam sebagian besar kasus, konfigurasi pengujian, yang merupakan file XML yang digunakan oleh Trade Federation untuk menjalankan pengujian VTS, akan otomatis dibuat selama build. Namun, Anda dapat menyesuaikan konfigurasi pengujian.

Membuat file konfigurasi pengujian yang disesuaikan

Membuat file XML pengujian baru dari awal bisa jadi rumit, karena melibatkan tidak memahami cara kerja {i>test harness<i}, serta perbedaan antara setiap runner pengujian. File konfigurasi pengujian yang dibuat secara otomatis dirancang untuk mempermudah proses ini.

Jika harus menyesuaikan file XML pengujian, Anda dapat menggunakan file yang dibuat otomatis sebagai titik awal.

Untuk menemukan file konfigurasi pengujian yang dibuat secara otomatis, jalankan perintah make terlebih dahulu untuk mem-build konfigurasi, seperti yang ditunjukkan di bawah.

$ m VtsHalUsbV1_1TargetTest

Di direktori {i>build out<i} Anda, Anda dapat mencari konfigurasi berdasarkan nama modul, seperti yang ditunjukkan di bawah ini.

$ find out/ -name VtsHalUsbV1_1TargetTest.config

Mungkin ada beberapa salinan file dan Anda dapat menggunakan salah satunya. Salin file .config ke direktori tempat file Android.bp berada.

Jika hanya ada satu modul pengujian dalam file Android.bp, Anda dapat mengganti nama file XML menjadi AndroidTest.xml, dan sistem build akan otomatis menggunakannya sebagai file konfigurasi modul pengujian. Jika tidak, tambahkan atribut test_config ke modul, seperti yang ditunjukkan dalam contoh di bawah ini.

test_config: "VtsHalUsbV1_1TargetTest.xml",

Sekarang Anda memiliki file konfigurasi pengujian untuk digunakan dan menerapkan penyesuaian.

Memaksa pengujian untuk dijalankan dengan root adb

Sebagian besar pengujian VTS memerlukan hak istimewa root agar dapat dijalankan. Jika konfigurasi pengujian otomatis dibuat, Anda dapat menambahkan atribut berikut ke Android.bp.

require_root: true,

Jika file konfigurasi pengujian disesuaikan, tambahkan berikut ini ke file XML pengujian.

<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>

Menghentikan framework selama pengujian

Banyak pengujian VTS tidak memerlukan framework Android untuk berjalan, dan menjalankan pengujian dengan framework dihentikan memungkinkan pengujian berjalan dengan stabilitas tanpa terpengaruh oleh flake perangkat. Jika file konfigurasi pengujian dibuat secara otomatis, Anda dapat menambahkan atribut berikut ke Android.bp.

disable_framework: true,

Jika file konfigurasi pengujian disesuaikan, tambahkan berikut ini ke file XML pengujian.

<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>

Menambahkan argumen pengujian tambahan

Beberapa pengujian gtest mungkin memerlukan lebih banyak waktu untuk dijalankan. Dalam kasus tersebut, Anda dapat menambahkan opsi runner pengujian dalam file XML.

Misalnya, setelan native-test-timeout dalam entri berikut memungkinkan pengujian berjalan dengan waktu tunggu 3 menit, bukan default 1 menit.

   <test class="com.android.tradefed.testtype.GTest" >
       <option name="native-test-device-path" value="/data/local/tmp" />
       <option name="module-name" value="VtsHalNfcV1_0TargetTest" />
       <option name="native-test-timeout" value="180000"/>
   </test>

Memerlukan level API minimum

Beberapa pengujian VTS hanya dapat berjalan pada perangkat dengan level API minimum. Jika file konfigurasi pengujian dibuat secara otomatis, Anda dapat menambahkan atribut berikut ke Android.bp.

min_shipping_api_level: 29,

atau

vsr_min_shipping_api_level: 202404,

Jika file konfigurasi pengujian disesuaikan, tambahkan perintah berikut ke file XML pengujian.

   <object type="module_controller" class="com.android.tradefed.testtype.suite.module.ShippingApiLevelModuleController">
       <option name="min-api-level" value="29" />
   </object>

atau

   <object type="module_controller" class="com.android.tradefed.testtype.suite.module.ShippingApiLevelModuleController">
       <option name="vsr-min-api-level" value="202404" />
   </object>

Properti level API

Android 12 menentukan properti ro.board.first_api_level dan ro.board.api_level untuk menampilkan API level image vendor di perangkat ini. Menggabungkan properti ini dengan ro.product.first_api_level, rangkaian pengujian memilih kasus pengujian yang tepat untuk perangkat tersebut.

Android 13 menentukan ro.vendor.api_level yang ditetapkan secara otomatis dengan menghitung level API vendor yang diperlukan menggunakan properti ro.product.first_api_level, ro.board.first_api_level, dan ro.board.api_level.

Untuk mengetahui detail selengkapnya, lihat API level vendor.

{i>ro.board.first_api_level<i}

Properti ro.board.first_api_level adalah API level saat image vendor untuk SoC yang memenuhi syarat untuk pembekuan vendor adalah langkah pertama yang dirilis dengan properti ini. Hal ini tidak bergantung pada API peluncuran perangkat tapi hanya bergantung pada API level pertama SoC yang menentukan nilai ini. Tujuan bersifat permanen selama masa pakai SoC.

Untuk menetapkan ro.board.first_api_level, produsen perangkat dapat menentukan BOARD_SHIPPING_API_LEVEL dalam file device.mk, seperti yang ditunjukkan dalam contoh berikut:

  # BOARD_SHIPPING_API_LEVEL sets ro.product.first_api_level to indicate
  # the first api level that the device has been commercially launched on.
  BOARD_SHIPPING_API_LEVEL := 23

Ini akan secara otomatis menentukan properti {i>ro.board.first_api_level<i} untuk vendor/build.prop di perangkat. Properti ditetapkan oleh proses init vendor.

level_ro.board.api

Properti ro.board.api_level adalah API level vendor saat ini dari image vendor yang memiliki format YYYYMM tempat API vendor dibekukan. Penting secara otomatis ditetapkan oleh sistem build.

ro.vendor.api_level

Properti ro.vendor.api_level diperkenalkan di Android 13 untuk menampilkan level API yang image vendor yang harus didukung. Fitur ini otomatis diatur ke ro.product.first_api_level, atau ro.board.api_level jika ro.board.first_api_level ada dan ro.board.api_level disetel ke level API yang lebih lama dari ro.product.first_api_level. Versi akan diganti dengan API level vendor yang sesuai jika ditetapkan ke versi dari ro.product.first_api_level yang lebih besar dari atau sama dengan 35. Pengujian untuk implementasi vendor yang memerlukan upgrade image vendor dapat dikecualikan dari persyaratan vendor untuk SoC dengan merujuk ke properti ini.

Proses sharding menggunakan VTS

Untuk Android versi 10 atau yang lebih tinggi, Anda dapat melakukan proses sharding di beberapa perangkat saat menguji dengan paket VTS dan CTS-on-GSI dengan mengikuti petunjuk di bawah.

run vts --shard-count <number of devices> -s <device serial> ...

Perintah ini akan membagi paket VTS menjadi beberapa bagian dan menjalankannya di beberapa perangkat.

run cts-on-gsi --shard-count <number of devices> -s <device serial> -s ...

Perintah ini membagi paket CTS-on-GSI menjadi shard dan menjalankannya di beberapa perangkat.