FAQ CTS

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

Artikel ini menyediakan FAQ untuk menjalankan tes CTS dengan lebih efisien.

Apa perbedaan antara CTS Sharding dan TF Sharding?

CTS Sharding dan TF Sharding adalah rencana pengujian yang sama sekali berbeda yang didukung oleh basis kode infrastruktur pengujian yang berbeda. Sementara perintah run sama di berbagai versi, hasil sharding berperilaku berbeda. CTS Sharding secara statis menetapkan kasus uji ke Devices Under Test (DUT) sebagai berikut:

TF Sharding secara dinamis menetapkan kasus uji ke DUT yang tersedia sebagai berikut:

Apa yang diharapkan dari perangkat yang mendukung banyak ABI?

Perangkat harus melewati semua CTS/Verifier untuk setiap mode ABI yang diklaim didukungnya. Oleh karena itu, perlu untuk menjalankan aplikasi untuk ABI tertentu. Pedoman untuk beberapa ABI adalah sebagai berikut:

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

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

Apakah cukup menjalankan tes hanya pada ABI primer (misalnya 64 bit) untuk mengurangi waktu eksekusi tes?

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

Mengapa ada begitu banyak kasus uji yang dilaporkan sebagai Tidak Dieksekusi?

Anda harus memeriksa nomor Modul Selesai alih-alih nomor Tidak Dieksekusi .

Dalam versi yang lebih lama, modul CTS dilaporkan sebagai Modul Selesai terlalu agresif sebelum diselesaikan. Oleh karena itu, nomor Modul Selesai dilaporkan tanpa semua kasus uji selesai bahkan ketika beberapa perangkat mengalami masalah. Harness tes baru lebih konservatif dan melaporkan jumlah tes Not Executed yang lebih tinggi saat terjadi masalah.

Sebuah modul dijalankan hingga laporan penyelesaian Modul Tidak Selesai dalam doa terbaru (done="false") dalam laporan selama berikut ini:

  • Uji coba modul terganggu oleh masalah koneksi perangkat.
  • Tidak semua uji coba yang diharapkan untuk modul dilakukan.
  • Dicoba lagi (menggunakan opsi -r/--retry ) dengan opsi pemfilteran tambahan, seperti:

    • --termasuk-filter
    • --kecuali-filter
    • -t/--test (Opsi belum didukung saat coba lagi)
    • --retry-type gagal
    • --subplan

Untuk mendapatkan status Modul Selesai (done="true") untuk modul ini, coba lagi berikut ini untuk permintaan 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 yang dijalankan tanpa masalah yang disebutkan di atas (bahkan dengan 0 tes tersisa) ditandai Modul Selesai dalam laporan baru.

Pengecualian

  • CtsNNAPITestCases memiliki masalah yang diketahui karena batasan linux/OS dari args. Modul dapat dijalankan kembali secara terpisah melalui run cts -m CtsNNAPITestCases secara langsung.

Bagaimana saya bisa menghindari kegagalan persiapan ujian di balik firewall perusahaan?

Semua rangkaian pengujian otomatis mencoba mengunduh file media CTS atau file logika bisnis selama waktu proses. Di banyak lingkungan perusahaan, firewall/proxy adalah tipikal, yang membuat persiapan tes gagal. Jalankan 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 Aman?

Apakah kartu SIM diperlukan untuk pengujian tergantung pada pemahaman apakah fitur tersebut didukung di perangkat pengujian.

  • Jika perangkat Anda TIDAK perlu mendukung aplikasi Android yang mengakses elemen aman—baik di UICC (misalnya, kartu SIM) yang didistribusikan oleh operator jaringan seluler (operator) atau tertanam di perangkat—Anda dapat mengonfigurasi manifes HIDL untuk tidak menyertakan elemen HAL android.hardware.secure_element . Dalam hal ini, API android.se.omapi.SEService.getReaders() akan melaporkan daftar kosong dan pengujian CTS akan secara otomatis lulus dan melaporkan kelulusan untuk CTS.
  • Jika perangkat Anda TIDAK perlu mendukung aplikasi Android untuk mengakses elemen aman—baik di UICC (misalnya, kartu SIM) yang didistribusikan oleh operator jaringan seluler (operator) atau tertanam di perangkat—Anda perlu menerapkan elemen aman dengan benar dan mengujinya di rumah. Pengujian CTS untuk Elemen Aman menguraikan cara mempersiapkan diri untuk menjalankan pengujian CTS yang memastikan paket API android.se.omapi yang ditambahkan di Android 9 berfungsi. Kami juga merekomendasikan melakukan pengujian tambahan sendiri karena cakupan pengujian CTS minimal.

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

Anda dapat menghubungi vendor SIM pilihan Anda.

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

Kasus pengujian tidak dimulai karena pengujian kartu SIM terkunci. Nonaktifkan opsi "Kunci kartu SIM" di "pengaturan kunci kartu SIM" sebelum menjalankan CTS dengan token sharding.