FAQ CTS

Program Kompatibilitas Android adalah pendorong utama untuk mempertahankan masukan positif untuk ekosistem Android. CTS adalah alat utama untuk memastikan kualitas kompatibilitas dalam skala besar. Tim Android terus meningkatkan alat CTS dan cakupan pengujian. Penambahan kasus pengujian secara rutin memiliki peningkatan yang signifikan pada kualitas perangkat yang kompatibel.

Pertanyaan umum

Bagian ini menyediakan FAQ CTS umum.

Apa saja yang diuji oleh CTS?

CTS menguji bahwa semua API bertipe kuat Android yang didukung ada dan berperilaku dengan benar. CTS juga menguji perilaku sistem non-API lainnya seperti siklus proses dan performa aplikasi.

Bagaimana CTS dilisensikan?

CTS dilisensikan berdasarkan Apache Software License 2.0 yang sama dengan yang digunakan sebagian besar Android.

Apakah codec diverifikasi oleh CTS?

Ya. Semua codec wajib diverifikasi oleh CTS.

Pertanyaan khusus pengujian

Bagian ini menyediakan FAQ yang membantu menjalankan pengujian CTS dengan lebih efisien.

Apa perbedaan antara Sharding CTS dan Sharding TF?

CTS Sharding dan TF Sharding adalah rencana pengujian yang benar-benar berbeda yang didukung oleh codebase infrastruktur pengujian yang berbeda. Sementara perintah{i> run <i}adalah sama di berbagai versi, hasil sharding akan berperilaku berbeda. Sharding CTS menetapkan kasus pengujian secara statis ke Devices Under Test (DUT) sebagai berikut:

Pembagian TF secara dinamis menetapkan kasus pengujian ke DUT yang tersedia sebagai berikut:

Apa yang diharapkan dari perangkat yang mendukung beberapa ABI?

Perangkat harus lulus semua uji CTS dan CTS Verifier untuk setiap mode ABI klaim untuk didukung. Oleh karena itu, perlu mengeksekusi aplikasi untuk ABI tertentu. Panduan untuk beberapa ABI adalah sebagai berikut:

  • Untuk CTS dan CTS Verifier, ada rilis ARM dan x86 untuk setiap arsitektur. Masing-masing dapat mendukung mode 32-bit atau 64-bit.
  • Untuk pengujian CTS, jika perangkat mendukung ARM dan x86, perangkat harus menjalankan dan lulus pengujian CTS ARM dan x86.

Lihat CDD 3.3.1. Antarmuka Biner Aplikasi untuk persyaratan CDD pada ABI.

Apakah menjalankan pengujian hanya pada ABI primer (misalnya, 64 bit) sudah cukup untuk mengurangi waktu eksekusi uji?

Tidak. Aplikasi Android berjalan di runtime 32-bit atau 64-bit-nya sendiri. Kode mesin, jalur kode, dan status sebenarnya berbeda antara 32 dan 64 tahun. Jika Anda melewati satu mode, Anda hanya akan mencakup 50% ABI perangkat.

Mengapa ada begitu banyak kasus pengujian yang dilaporkan sebagai Tidak Dijalankan?

Anda harus memeriksa nomor Module Done, bukan nomor Not Executed.

Dalam versi sebelumnya, modul CTS juga dilaporkan sebagai Module Done secara agresif sebelum selesai. Oleh karena itu, jumlah Modules Done dilaporkan tanpa semua kasus pengujian selesai meskipun beberapa perangkat mengalami masalah. Tes yang baru lebih konservatif dan melaporkan jumlah pengujian Tidak Dieksekusi yang lebih tinggi saat terjadi masalah.

Modul berjalan hingga selesai melaporkan Modul Tidak Selesai paling sering pemanggilan terbaru (done="false") dalam laporan selama proses berikut:

  • Proses pengujian untuk modul terganggu oleh masalah koneksi perangkat.
  • Tidak semua pengujian yang diharapkan untuk modul dijalankan.

  • Dicoba lagi (menggunakan opsi -r/--retry) dengan opsi pemfilteran tambahan, seperti:

    • --sertakan-filter
    • --filter-kecualikan
    • -t/--test (Opsi belum didukung saat mencoba lagi)
    • --retry-type gagal
    • --subplan

Untuk mendapatkan status Module Done (done="true") untuk modul ini, coba lagi hal berikut untuk pemanggilan terbaru:

run retry --retry <session_id> for Android 9 and later versions
run cts --retry <session_id> for Android 8.1 and previous versions

Modul dieksekusi tanpa masalah yang disebutkan sebelumnya (bahkan dengan 0 pengujian yang tersisa) ditandai sebagai Module Done dalam laporan baru.

Pengecualian

  • CtsNNAPITestCases memiliki masalah umum karena batasan argumen linux/OS. Modul dapat dijalankan ulang secara terpisah melalui run cts -m CtsNNAPITestCases secara langsung.

Bagaimana cara menghindari kegagalan persiapan pengujian di balik firewall perusahaan?

Semua rangkaian pengujian otomatis mencoba mendownload file media CTS atau file logika bisnis selama runtime. Di banyak lingkungan perusahaan, {i>firewall<i} dan {i>proxy<i} adalah standar, yang membuat persiapan tes gagal. {i>Execute<i} baris berikut atau tambahkan ke .profile (di Ubuntu).

export JAVA_TOOL_OPTIONS='-Djava.net.useSystemProxies=true'

Apakah saya memerlukan kartu SIM untuk CTS untuk Elemen Pengaman?

Kartu SIM diperlukan untuk pengujian tergantung pada pemahaman jika fitur tersebut didukung di perangkat pengujian.

  • Jika perangkat Anda TIDAK perlu mendukung aplikasi Android yang mengakses keamanan—baik dalam UICC (misalnya, kartu SIM) yang didistribusikan oleh operator jaringan seluler (operator) atau yang tersemat di perangkat—Anda dapat mengonfigurasi HIDL manifes agar tidak menyertakan android.hardware.secure_element HAL . Dalam hal ini, android.se.omapi.SEService.getReaders() API melaporkan daftar kosong dan pengujian CTS secara otomatis lulus dan melaporkan kelulusan untuk CTS.
  • Jika perangkat Anda HARUS mendukung aplikasi Android yang mengakses elemen aman—baik di UICC (misalnya, kartu SIM) yang didistribusikan oleh operator jaringan seluler (operator) atau disematkan di perangkat—Anda harus menerapkan elemen aman dengan benar dan mengujinya secara internal. Pengujian CTS untuk Elemen Pengaman menguraikan cara mempersiapkan pengujian CTS yang memastikan paket API android.se.omapi yang ditambahkan di Android 9 berfungsi. Sebaiknya lakukan pengujian tambahan sendiri karena cakupan pengujian CTS minimal.

Di mana saya bisa mendapatkan kartu SIM untuk CTS untuk Elemen Pengaman?

Anda dapat menghubungi vendor SIM pilihan Anda.

Mengapa SIM Orange ada di layar kunci selama eksekusi CTS dengan sharding token?

Kasus pengujian tidak dimulai karena pengujian kartu SIM terkunci. Nonaktifkan Kunci kartu SIM di **setelan kunci kartu SIM sebelum mengeksekusi CTS dengan sharding token.