Inisialisasi klien Repo Anda
Ikuti instruksi dari Mengunduh Sumber untuk mendapatkan dan membuat kode sumber Android. Saat mengeluarkan perintah repo init
, tentukan cabang CTS tertentu menggunakan -b
. Hal ini memastikan bahwa perubahan CTS Anda disertakan dalam rilis CTS berikutnya.
Contoh kode berikut menunjukkan cara menggunakan repo init
.
mkdir android11-tests-dev && cd android11-tests-dev && repo init -c -u https://android.googlesource.com/platform/manifest -b android11-tests-dev --use-superproject --partial-clone --partial-clone-exclude=platform/frameworks/base --clone-filter=blob:limit=10M && repo sync -c -j8
Membangun dan menjalankan CTS
Jalankan perintah berikut untuk membangun CTS dan memulai konsol CTS interaktif:
cd /path/to/android/root
make cts -j32 TARGET_PRODUCT=aosp_arm64
cts-tradefed
Di konsol CTS, masukkan:
tf> run cts --plan CTS
Tulis tes CTS
Pengujian CTS menggunakan JUnit dan API pengujian Android. Tinjau tutorial Uji aplikasi Anda dan pengujian yang ada di direktori cts/tests
. Pengujian CTS sebagian besar mengikuti konvensi yang sama dengan yang digunakan dalam pengujian Android lainnya.
CTS berjalan di banyak perangkat produksi, sehingga pengujian harus mengikuti aturan berikut:
- Pertimbangkan berbagai ukuran layar, orientasi, dan tata letak keyboard.
- Gunakan hanya metode API publik. Dengan kata lain, hindari semua kelas, metode, dan bidang dengan anotasi
hide
. - Hindari penggunaan tata letak tampilan atau mengandalkan dimensi aset yang mungkin tidak ada di beberapa perangkat.
- Jangan mengandalkan hak akses root.
Tambahkan anotasi Java
Jika pengujian Anda memverifikasi perilaku API, beri anotasi pada kode pengujian Anda dengan @ApiTest
dan cantumkan semua API yang terlibat dalam bidang apis
. Gunakan format yang sesuai dari contoh berikut:
Jenis API | Format anotasi | Catatan |
---|---|---|
metode | android.example.ClassA#methodA | Kasus penggunaan yang paling umum. |
Metode dengan nilai-nilai kunci | android.example.ClassB#methodB(KeyA) | Gunakan hanya ketika pengujian Anda menggunakan metode API untuk memvalidasi suatu bidang, seperti dalam contoh ini. |
Bidang | android.example.ClassC#FieldA | Gunakan hanya ketika pengujian Anda memvalidasi kolom API secara langsung, seperti dalam contoh ini. |
Jika pengujian Anda memverifikasi persyaratan CDD, beri anotasi pada ID persyaratan (termasuk ID Bagian CDD dan ID Persyaratan) dengan @CddTest
dalam kode pengujian CTS seperti yang ditunjukkan dalam contoh berikut. Dalam pesan penerapan Anda, sebutkan persyaratan CDD mana yang diuji oleh pengujian Anda dengan mengacu pada ID persyaratan CDD. ID persyaratan CDD adalah kombinasi ID bagian dan ID persyaratan, dihubungkan dengan garis miring (/) seperti pada 7.3.1/C-1-1.
/**
* Verify Passpoint configuration management APIs for a Passpoint
* @throws Exception
*/
@CddTest(requirement="7.4.2.3/C-1-1,C-2-1")
public void testAddPasspointConfigWithUserCredential() throws Exception {
if (!WifiFeature.isWifiSupported(getContext())) {
// skip the test if WiFi is not supported
return;
} testAddPasspointConfig(generatePasspointConfig(generateUserCredential()));
}
Untuk CTS Verifier, beri anotasi pada setiap Aktivitas di AndroidManifest.xml
Anda dengan ID CDD yang relevan. Format bidang nilai mirip dengan format anotasi Java di CTS. Dalam pesan penerapan, sebutkan persyaratan CDD mana yang diterapkan dengan merujuk pada ID persyaratan CDD.
<activity>
......
<!-- OPTIONAL: Add a meta data attribute to indicate CDD requirements. -->
<meta-data android:name="cdd_test" android:value="7.4.1/C-4-1" />
<!-- OPTIONAL: Add a meta data attribute to indicate APIs being tested. -->
<meta-data android:name="api_test"
android:value="com.example.MyClass#myMethod" />
<!-- OPTIONAL: Add a metadata attribute to indicate the reason why the test doesn't enforce any CDD requirement but still useful in CTS-V. -->
<meta-data android:name="non_compliance_test"
android:value="detailed reasons" />
</activity>
Dalam pesan komit
Sebutkan dengan jelas mengapa pengujian Anda perlu ditambahkan, dan tambahkan tautan yang relevan untuk dukungan. Untuk pengujian CTS-D, sertakan tautan ke proposal pengujian yang Anda buat di Google Issue Tracker sebagai bagian dari proses pengiriman CTS-D .
Buat subrencana
Sebagai contoh, Anda dapat menambahkan file SubPlan.xml di android-cts/subplans
sebagai berikut:
<?xml version="1.0" encoding="utf-8" standalone="no"?> <SubPlan version="2.0"> <Entry include="CtsSystemIntentTestCases" /> <Entry include="CtsSystemUiHostTestCases" /> <Entry include="CtsSecurityHostTestCases android.security.cts.SELinuxHostTest#testAospFileContexts" /> <Entry include="CtsSecurityHostTestCases android.security.cts.SELinuxHostTest#testAospServiceContexts" /> </SubPlan>
Untuk menjalankan subrencana:
run cts --subplan aSubPlan
Format entri subplan adalah:
Include a module name as follows: <Entry include="MODULE_NAME" /> Include a package: <Entry include="MODULE_NAME PACKAGE_NAME" /> Include a class: <Entry include="MODULE_NAME PACKAGE_NAME.CLASS_NAME" /> Include an individual test: <Entry include="MODULE_NAME PACKAGE_NAME.CLASS_NAME#TEST_NAME" />
Uji penamaan dan lokasi
Kebanyakan kasus uji CTS menargetkan kelas tertentu di Android API. Tes ini memiliki nama paket Java dengan akhiran cts
dan nama kelas dengan akhiran Test
. Setiap kasus uji terdiri dari beberapa pengujian, di mana setiap pengujian biasanya menggunakan metode tertentu dari kelas yang diuji. Pengujian ini disusun dalam struktur direktori tempat pengujian dikelompokkan ke dalam kategori berbeda seperti "widget" atau "tampilan".
Misalnya, pengujian CTS untuk paket Java android.widget.TextView
adalah android.widget.cts.TextViewTest
dengan nama paket Java-nya sebagai android.widget.cts
dan nama kelasnya sebagai TextViewTest
.
- Nama paket Java
Nama paket Java untuk pengujian CTS adalah nama paket kelas yang diuji, diikuti dengan.cts
. Sebagai contoh, nama paketnya adalahandroid.widget.cts
. - Nama kelas
Nama kelas untuk tes CTS adalah nama kelas yang diuji dengan tambahan "Tes". Misalnya, jika pengujian menargetkanTextView
, nama kelasnya harusTextViewTest
. - Nama modul (hanya CTS v2)
CTS v2 mengatur tes berdasarkan modul. Nama modul biasanya merupakan string kedua dari nama paket Java (dalam contoh kita,widget
).
Struktur direktori dan kode contoh bergantung pada apakah Anda menggunakan CTS v1 atau CTS v2.
CTS v1
Untuk Android 6.0 atau lebih rendah, gunakan CTS v1. Untuk CTS v1, kode contohnya ada di cts/tests/tests/example
.
Struktur direktori dalam pengujian CTS v1 terlihat seperti ini:
cts/ tests/ tests/ package-name/ Android.mk AndroidManifest.xml src/ android/ package-name/ SampleDeviceActivity.java cts/ SampleDeviceTest.java
CTS v2
Untuk Android 7.0 atau lebih tinggi, gunakan CTS v2. Untuk detailnya, lihat contoh pengujian di Android Open Source Project (AOSP) .
Struktur direktori CTS v2 terlihat seperti ini:
cts/ tests/ module-name/ Android.mk AndroidManifest.xml src/ android/ package-name/ SampleDeviceActivity.java cts/ SampleDeviceTest.java
Paket sampel baru
Saat menambahkan pengujian baru, mungkin tidak ada direktori untuk melakukan pengujian Anda. Dalam kasus tersebut, Anda perlu membuat direktori dan menyalin file sampel yang sesuai.
CTS v1
Jika Anda menggunakan CTS v1, lihat contoh di bawah cts/tests/tests/example
dan buat direktori baru. Selain itu, pastikan untuk menambahkan nama modul paket baru Anda dari Android.mk
ke CTS_COVERAGE_TEST_CASE_LIST
di cts/CtsTestCaseList.mk
. build/core/tasks/cts.mk
menggunakan makefile ini untuk menggabungkan semua pengujian dan membuat paket CTS akhir.
CTS v2
Gunakan tes sampel /cts/tests/sample/
untuk memulai modul pengujian baru Anda dengan cepat dengan langkah-langkah berikut:
- Untuk membuat direktori pengujian dan menyalin file sampel, jalankan:
mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name
- Navigasikan ke
cts/tests/ module-name
dan gantikan semua instance "[Ss]ample" dengan konvensi penamaan yang direkomendasikan dari atas. - Perbarui
SampleDeviceActivity
untuk menjalankan fitur yang Anda uji. - Perbarui
SampleDeviceTest
untuk memastikan bahwa aktivitas berhasil atau mencatat kesalahannya.
Direktori tambahan
Direktori Android lainnya seperti assets
, jni
, libs
, dan res
juga dapat ditambahkan. Untuk menambahkan kode JNI, buat direktori di root proyek di sebelah src
dengan kode asli dan makefile Android.mk
di dalamnya.
Makefile biasanya berisi pengaturan berikut:
LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE := libCtsSample_jni # don't include this package in any target LOCAL_MODULE_TAGS := optional LOCAL_SRC_FILES := list of source code files LOCAL_C_INCLUDES := $(JNI_H_INCLUDE) # Tag this module as a cts test artifact LOCAL_COMPATIBILITY_SUITE := cts LOCAL_SHARED_LIBRARIES := libnativehelper LOCAL_SDK_VERSION := current include $(BUILD_SHARED_LIBRARY)
File Android.mk
Terakhir, modifikasi file Android.mk
di root proyek untuk membuat kode asli dan bergantung padanya, seperti yang ditunjukkan di bawah ini:
# All tests should include android.test.runner. LOCAL_JAVA_LIBRARIES := android.test.runner # Includes the jni code as a shared library LOCAL_JNI_SHARED_LIBRARIES := libCtsSample_jni # Include for InstrumentationCtsTestRunner LOCAL_STATIC_JAVA_LIBRARIES := ctstestrunner... LOCAL_SDK_VERSION := currentinclude $(BUILD_CTS_PACKAGE) #Tells make to look in subdirectories for more make files to include include $(call all-makefiles-under,$(LOCAL_PATH))
Perbaiki atau hapus tes
Selain menambahkan pengujian baru, Anda dapat memperbaiki atau menghapus pengujian yang dianotasi dengan BrokenTest
atau KnownFailure
.
Kirimkan perubahan Anda
Saat mengirimkan patch CTS atau VTS di AOSP, pilih cabang pengembangan Anda berdasarkan level API tempat patch tersebut diterapkan.
- Untuk perubahan yang berlaku pada beberapa level API, pertama-tama kembangkan patch di
aosp/main
lalu pilih cabang pengujian paling hulu . Izinkan penggabungan otomatis untuk menggabungkan perubahan hilir di cabang pengujian AOSP. Lihat Jadwal rilis dan informasi cabang untuk daftar cabang dan informasi jalur penggabungan otomatis. - Untuk perubahan yang spesifik pada level API tertentu, kembangkan atau pilih perubahan pada cabang pengujian yang benar dengan JANGAN MERGE atau RESTRICT AUTOMERGE dalam pesan penerapan.
Ikuti alur kerja Mengirimkan patch untuk menyumbangkan perubahan pada CTS. Seorang peninjau akan ditugaskan untuk meninjau perubahan Anda.
Jadwal rilis dan informasi cabang
Rilis CTS mengikuti jadwal ini.
Versi: kapan | tingkat API | Cabang | Frekuensi |
---|---|---|---|
14 | 34 | android14-tes-dev | Triwulanan |
13 | 33 | android13-tes-dev | Triwulanan |
12L | 32 | android12L-tes-dev | Triwulanan |
12 | 31 | android12-tes-dev | Triwulanan |
11 | 30 | android11-tes-dev | Triwulanan |
Tidak ada rilis lebih lanjut yang direncanakan untuk versi 10.0, 9.0, 8.1, 8.0, 7.1, 7.0, 6.0, 5.1, 5.0, 4.4, 4.3, dan 4.2. |
Tanggal-tanggal penting selama rilis
- Akhir minggu pertama: Pembekuan kode. Perubahan yang digabungkan di cabang hingga pembekuan kode dipertimbangkan untuk versi CTS yang akan datang. Pengiriman ke cabang setelah kode dibekukan, atau setelah kandidat rilis dipilih, dipertimbangkan untuk rilis berikutnya.
- Minggu kedua atau ketiga: CTS diterbitkan di AOSP .
Aliran penggabungan otomatis
Cabang pengembangan CTS telah diatur sehingga perubahan yang dikirimkan ke setiap cabang secara otomatis digabungkan ke cabang yang lebih tinggi.
Untuk perubahan langsung ke cabang pengembang pengujian AOSP, jalur penggabungan otomatisnya adalah:
android11-tests-dev
> android12-tests-dev
dev > android12L-tests-dev
> android13-tests-dev
> android14-tests-dev
> aosp/main
Untuk perubahan hanya pada versi Android berikutnya, jalur penggabungan otomatisnya adalah:
aosp/main
> <Internal git/main>
.
Jika daftar perubahan (CL) gagal digabungkan dengan benar, pembuat tambalan akan dikirimi email berisi instruksi tentang cara menyelesaikan konflik. Dalam sebagian besar kasus, pembuat tambalan dapat menggunakan instruksi untuk melewati penggabungan otomatis CL yang bertentangan.
Jika cabang yang lebih tua memerlukan perubahan, maka tambalan tersebut harus dipilih dari cabang yang lebih baru.