Rangkaian tes
Agar pengujian menjadi bagian dari VTS, pengujian tersebut harus memiliki pengaturan berikut di Android.bp .
test_suites: ["vts"],
Selain itu, menambahkan tes ke rangkaian general-tests memungkinkannya menjadi bagian dari rangkaian Pemetaan Tes yang digunakan dalam pemeriksaan pra-pengiriman.
Konfigurasi pengujian
Dalam kebanyakan kasus, konfigurasi pengujian, yang merupakan file XML yang digunakan oleh Federasi Dagang untuk menjalankan pengujian VTS, dibuat secara otomatis selama pembuatan. Namun, Anda dapat menyesuaikan konfigurasi pengujian.
Buat file konfigurasi pengujian yang disesuaikan
Membuat file XML pengujian baru dari awal bisa jadi rumit, karena memerlukan pemahaman tentang cara kerja rangkaian pengujian, serta perbedaan antara setiap runner pengujian. File konfigurasi pengujian yang dibuat secara otomatis dirancang untuk membuat proses ini lebih mudah.
Jika Anda harus menyesuaikan file XML pengujian, Anda dapat menggunakan file yang dibuat secara otomatis sebagai titik awal.
Untuk menemukan file konfigurasi pengujian yang dibuat secara otomatis, pertama-tama jalankan perintah make untuk membuat konfigurasi, seperti yang ditunjukkan di bawah ini.
$ m VtsHalUsbV1_1TargetTest
Di direktori build out Anda, Anda dapat mencari file konfigurasi berdasarkan nama modul, seperti yang ditunjukkan di bawah ini.
$ find out/ -name VtsHalUsbV1_1TargetTest.config
Mungkin ada banyak salinan file dan Anda dapat menggunakan salah satunya. Copy file .config ke direktori tempat file Android.bp berada.
Jika hanya ada satu modul pengujian di file Android.bp , Anda dapat mengganti nama file XML menjadi AndroidTest.xml , dan sistem build secara otomatis menggunakannya sebagai file konfigurasi modul pengujian. Jika tidak, tambahkan atribut test_config ke modul, seperti yang ditunjukkan pada contoh di bawah.
test_config: "VtsHalUsbV1_1TargetTest.xml",
Sekarang Anda memiliki file konfigurasi pengujian untuk digunakan dan menerapkan penyesuaian.
Paksa pengujian untuk dijalankan dengan adb root
Sebagian besar tes VTS memerlukan hak akses root untuk dijalankan. Jika file konfigurasi pengujian dibuat secara otomatis, Anda dapat menambahkan atribut berikut ke Android.bp .
require_root: true,
Jika file konfigurasi pengujian dikustomisasi, tambahkan berikut ini ke file XML pengujian.
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
Hentikan kerangka kerja selama pengujian
Banyak pengujian VTS yang tidak memerlukan kerangka kerja Android untuk dijalankan, dan menjalankan pengujian dengan kerangka kerja dihentikan memungkinkan pengujian berjalan dengan stabil tanpa terpengaruh oleh kesalahan perangkat. Jika file konfigurasi pengujian dibuat secara otomatis, Anda dapat menambahkan atribut berikut ke Android.bp .
disable_framework: true,
Jika file konfigurasi pengujian dikustomisasi, tambahkan berikut ini ke file XML pengujian.
<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>
Tambahkan argumen pengujian tambahan
Beberapa pengujian gtest mungkin memerlukan lebih banyak waktu untuk dijalankan. Dalam kasus seperti itu, Anda dapat menambahkan opsi test runner di file XML.
Misalnya, pengaturan native-test-timeout di entri berikut memungkinkan pengujian dijalankan dengan batas waktu 3 menit, bukan 1 menit default.
<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 tingkat API minimum
Beberapa pengujian VTS hanya dapat dijalankan pada perangkat dengan level API minimum. Jika file konfigurasi pengujian dibuat secara otomatis, Anda dapat menambahkan atribut berikut ke Android.bp .
test_min_api_level: 29,
Jika file konfigurasi pengujian dikustomisasi, tambahkan perintah berikut ke file XML pengujian.
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.MinApiLevelModuleController">
<option name="min-api-level" value="29" />
</object>
Android 12 mendefinisikan properti ro.board.first_api_level dan ro.board.api_level untuk menampilkan API level gambar vendor pada perangkat ini. Menggabungkan properti ini dengan ro.product.first_api_level , rangkaian pengujian memilih kasus pengujian yang tepat untuk perangkat.
Android 13 mendefinisikan ro.vendor.api_level yang disetel 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 .
ro.board.first_api_level
Properti ro.board.first_api_level adalah level API ketika gambar vendor untuk SoC pertama kali dirilis dengan properti ini. Hal ini tidak bergantung pada API level peluncuran perangkat, namun hanya bergantung pada API level pertama SoC yang menentukan nilai ini. Nilainya permanen selama masa pakai SoC.
Untuk menyetel ro.board.first_api_level , produsen perangkat dapat menentukan BOARD_SHIPPING_API_LEVEL di file device.mk mereka, 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 mendefinisikan properti ro.board.first_api_level ke vendor/build.prop pada perangkat. Properti ini diatur oleh proses init vendor.
ro.board.api_level
Properti ro.board.api_level adalah level API gambar vendor saat ini untuk SoC. Ketika level API gambar vendor yang memiliki ro.board.first_api_level diperbarui, perangkat yang menggunakan SoC harus mendefinisikan properti ro.board.api_level dengan level API gambar vendor saat ini alih-alih memperbarui ro.board.first_api_level . Jika properti ini tidak disetel, ro.board.first_api_level akan digunakan secara default.
Untuk menyetel ro.board.api_level , tentukan BOARD_API_LEVEL di file device.mk dengan nilai yang diinginkan.
ro.vendor.api_level
Properti ro.vendor.api_level diperkenalkan di Android 13 untuk menunjukkan level API yang harus didukung oleh image vendor. Ini secara otomatis disetel ke minimum ro.board.api_level (atau ro.board.first_api_level jika ro.board.api_level tidak ditentukan) dan ro.product.first_api_level . Pengujian untuk implementasi vendor yang memerlukan peningkatan citra vendor mungkin dikecualikan dari persyaratan vendor untuk SoC dengan mengacu pada properti ini.
Proses sharding menggunakan VTS
Untuk Android versi 10 atau 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 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 beberapa bagian dan menjalankannya di beberapa perangkat.
,Rangkaian tes
Agar pengujian menjadi bagian dari VTS, pengujian tersebut harus memiliki pengaturan berikut di Android.bp .
test_suites: ["vts"],
Selain itu, menambahkan tes ke rangkaian general-tests memungkinkannya menjadi bagian dari rangkaian Pemetaan Tes yang digunakan dalam pemeriksaan pra-pengiriman.
Konfigurasi pengujian
Dalam kebanyakan kasus, konfigurasi pengujian, yang merupakan file XML yang digunakan oleh Federasi Dagang untuk menjalankan pengujian VTS, dibuat secara otomatis selama pembuatan. Namun, Anda dapat menyesuaikan konfigurasi pengujian.
Buat file konfigurasi pengujian yang disesuaikan
Membuat file XML pengujian baru dari awal bisa jadi rumit, karena memerlukan pemahaman tentang cara kerja rangkaian pengujian, serta perbedaan antara setiap runner pengujian. File konfigurasi pengujian yang dibuat secara otomatis dirancang untuk membuat proses ini lebih mudah.
Jika Anda harus menyesuaikan file XML pengujian, Anda dapat menggunakan file yang dibuat secara otomatis sebagai titik awal.
Untuk menemukan file konfigurasi pengujian yang dibuat secara otomatis, pertama-tama jalankan perintah make untuk membuat konfigurasi, seperti yang ditunjukkan di bawah ini.
$ m VtsHalUsbV1_1TargetTest
Di direktori build out Anda, Anda dapat mencari file konfigurasi berdasarkan nama modul, seperti yang ditunjukkan di bawah ini.
$ find out/ -name VtsHalUsbV1_1TargetTest.config
Mungkin ada banyak salinan file dan Anda dapat menggunakan salah satunya. Copy file .config ke direktori tempat file Android.bp berada.
Jika hanya ada satu modul pengujian di file Android.bp , Anda dapat mengganti nama file XML menjadi AndroidTest.xml , dan sistem build secara otomatis menggunakannya sebagai file konfigurasi modul pengujian. Jika tidak, tambahkan atribut test_config ke modul, seperti yang ditunjukkan pada contoh di bawah.
test_config: "VtsHalUsbV1_1TargetTest.xml",
Sekarang Anda memiliki file konfigurasi pengujian untuk digunakan dan menerapkan penyesuaian.
Paksa pengujian untuk dijalankan dengan adb root
Sebagian besar tes VTS memerlukan hak akses root untuk dijalankan. Jika file konfigurasi pengujian dibuat secara otomatis, Anda dapat menambahkan atribut berikut ke Android.bp .
require_root: true,
Jika file konfigurasi pengujian dikustomisasi, tambahkan berikut ini ke file XML pengujian.
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
Hentikan kerangka kerja selama pengujian
Banyak pengujian VTS yang tidak memerlukan kerangka kerja Android untuk dijalankan, dan menjalankan pengujian dengan kerangka kerja dihentikan memungkinkan pengujian berjalan dengan stabil tanpa terpengaruh oleh kesalahan perangkat. Jika file konfigurasi pengujian dibuat secara otomatis, Anda dapat menambahkan atribut berikut ke Android.bp .
disable_framework: true,
Jika file konfigurasi pengujian dikustomisasi, tambahkan berikut ini ke file XML pengujian.
<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>
Tambahkan argumen pengujian tambahan
Beberapa pengujian gtest mungkin memerlukan lebih banyak waktu untuk dijalankan. Dalam kasus seperti itu, Anda dapat menambahkan opsi test runner di file XML.
Misalnya, pengaturan native-test-timeout di entri berikut memungkinkan pengujian dijalankan dengan batas waktu 3 menit, bukan 1 menit default.
<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 tingkat API minimum
Beberapa pengujian VTS hanya dapat dijalankan pada perangkat dengan level API minimum. Jika file konfigurasi pengujian dibuat secara otomatis, Anda dapat menambahkan atribut berikut ke Android.bp .
test_min_api_level: 29,
Jika file konfigurasi pengujian dikustomisasi, tambahkan perintah berikut ke file XML pengujian.
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.MinApiLevelModuleController">
<option name="min-api-level" value="29" />
</object>
Android 12 mendefinisikan properti ro.board.first_api_level dan ro.board.api_level untuk menampilkan API level gambar vendor pada perangkat ini. Menggabungkan properti ini dengan ro.product.first_api_level , rangkaian pengujian memilih kasus pengujian yang tepat untuk perangkat.
Android 13 mendefinisikan ro.vendor.api_level yang disetel 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 .
ro.board.first_api_level
Properti ro.board.first_api_level adalah level API ketika gambar vendor untuk SoC pertama kali dirilis dengan properti ini. Hal ini tidak bergantung pada API level peluncuran perangkat, namun hanya bergantung pada API level pertama SoC yang menentukan nilai ini. Nilainya permanen selama masa pakai SoC.
Untuk menyetel ro.board.first_api_level , produsen perangkat dapat menentukan BOARD_SHIPPING_API_LEVEL di file device.mk mereka, 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 mendefinisikan properti ro.board.first_api_level ke vendor/build.prop pada perangkat. Properti ini diatur oleh proses init vendor.
ro.board.api_level
Properti ro.board.api_level adalah level API gambar vendor saat ini untuk SoC. Ketika level API gambar vendor yang memiliki ro.board.first_api_level diperbarui, perangkat yang menggunakan SoC harus mendefinisikan properti ro.board.api_level dengan level API gambar vendor saat ini alih-alih memperbarui ro.board.first_api_level . Jika properti ini tidak disetel, ro.board.first_api_level akan digunakan secara default.
Untuk menyetel ro.board.api_level , tentukan BOARD_API_LEVEL di file device.mk dengan nilai yang diinginkan.
ro.vendor.api_level
Properti ro.vendor.api_level diperkenalkan di Android 13 untuk menunjukkan level API yang harus didukung oleh image vendor. Ini secara otomatis disetel ke minimum ro.board.api_level (atau ro.board.first_api_level jika ro.board.api_level tidak ditentukan) dan ro.product.first_api_level . Pengujian untuk implementasi vendor yang memerlukan peningkatan citra vendor mungkin dikecualikan dari persyaratan vendor untuk SoC dengan mengacu pada properti ini.
Proses sharding menggunakan VTS
Untuk Android versi 10 atau 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 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 beberapa bagian dan menjalankannya di beberapa perangkat.