Pengembangan CTS

Melakukan inisialisasi klien Repo

Ikuti petunjuk dari Mendownload Sumber untuk mendapatkan dan membangun 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 membuat CTS dan memulai konsol CTS interaktif:

Catatan: Anda dapat menggunakan aosp_x86_64 sebagai alternatif untuk aosp_arm64.

Bangun CTS (AOSP 14 atau yang lebih lama)

cd /path/to/android/root
source build/envsetup.sh
make cts -j32 TARGET_PRODUCT=aosp_arm64
cts-tradefed

Build CTS (AOSP 15)

cd /path/to/android/root
source build/envsetup.sh
make cts -j32 TARGET_PRODUCT=aosp_arm64 TARGET_RELEASE=target-release
cts-tradefed

Lihat tabel berikut untuk memilih nilai target-release:

Cabang	Rilis Target
android15-tests-dev	ap3a

Menjalankan CTS

Di konsol CTS, masukkan:

tf> run cts --plan CTS

Menulis pengujian CTS

Untuk menulis pengujian CTS yang didukung Developer (CTS-D), Anda harus mengirimkan proposal pengujian terlebih dahulu dengan mengikuti petunjuk dalam proses pengiriman CTS.

Pengujian CTS menggunakan JUnit dan Android Testing API. Tinjau tutorial Menguji aplikasi Anda dan pengujian yang ada di direktori cts/tests. Sebagian besar pengujian CTS mengikuti konvensi yang sama yang digunakan dalam pengujian Android lainnya.

CTS berjalan di banyak perangkat produksi, sehingga pengujian harus mengikuti aturan berikut:

• Perhitungkan berbagai ukuran layar, orientasi, dan tata letak keyboard.
• Hanya gunakan metode API publik. Dengan kata lain, hindari semua class, metode, dan kolom dengan anotasi hide.
• Hindari penggunaan tata letak tampilan atau mengandalkan dimensi aset yang mungkin tidak ada di beberapa perangkat.
• Jangan mengandalkan hak istimewa root.

Menambahkan anotasi Java

Jika pengujian Anda memverifikasi perilaku API, anotasikan kode pengujian Anda dengan @ApiTest dan cantumkan semua API yang terlibat dalam kolom apis. Gunakan format yang sesuai dari contoh berikut:

API type	Format anotasi	Catatan
Metode	android.example.ClassA#methodA	Kasus penggunaan yang paling umum.
Metode dengan nilai kunci	android.example.ClassB#methodB(KeyA)	Gunakan hanya jika pengujian Anda menggunakan metode API untuk memvalidasi kolom, seperti dalam contoh ini.
Kolom	android.example.ClassC#FieldA	Gunakan hanya saat 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 commit Anda, sebutkan persyaratan CDD mana yang diuji oleh pengujian Anda dengan merujuk ke ID persyaratan CDD. ID persyaratan CDD adalah kombinasi ID bagian dan ID persyaratan, yang 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 untuk kolom nilai mirip dengan format anotasi Java di CTS. Dalam pesan commit, sebutkan persyaratan CDD 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 commit

Sebutkan dengan jelas alasan pengujian Anda perlu ditambahkan, dan tambahkan link yang relevan untuk mendapatkan dukungan. Untuk pengujian CTS-D, sertakan link ke proposal pengujian yang Anda buat di Google Issue Tracker sebagai bagian dari proses pengiriman CTS-D.

Membuat subrencana

Misalnya, 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 sub-paket:

run cts --subplan aSubPlan

Format entri subpaket 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" />

Penamaan dan lokasi pengujian

Sebagian besar kasus pengujian CTS menargetkan class tertentu di Android API. Pengujian ini memiliki nama paket Java dengan akhiran cts dan nama class dengan akhiran Test. Setiap kasus pengujian terdiri dari beberapa pengujian, yang masing-masing pengujian biasanya melatih metode tertentu dari class yang sedang diuji. Pengujian ini disusun dalam struktur direktori tempat pengujian dikelompokkan ke dalam berbagai kategori 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 class-nya sebagai TextViewTest.

• Nama paket Java
  Nama paket Java untuk pengujian CTS adalah nama paket class yang sedang diuji, diikuti dengan .cts. Untuk contoh kita, nama paketnya adalah android.widget.cts.
• Nama class
  Nama class untuk pengujian CTS adalah nama class yang sedang diuji dengan "Test" ditambahkan. Misalnya, jika pengujian menargetkan TextView, nama class harus TextViewTest.
• Nama modul (khusus CTS v2)
  CTS v2 mengatur pengujian 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 yang lebih lama, 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 yang lebih tinggi, gunakan CTS v2. Untuk mengetahui detailnya, lihat contoh pengujian di Proyek Open Source Android (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 yang ada untuk menempatkan pengujian Anda. Dalam kasus tersebut, Anda perlu membuat direktori dan menyalin file contoh yang sesuai.

CTS v1

Jika Anda menggunakan CTS v1, lihat contoh di bagian cts/tests/tests/example dan buat direktori baru. Selain itu, pastikan untuk menambahkan nama modul paket baru dari Android.mk-nya 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 pengujian contoh /cts/tests/sample/ untuk memulai modul pengujian baru dengan cepat menggunakan langkah-langkah berikut:

1. Untuk membuat direktori pengujian dan menyalin file contoh, jalankan:

   mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name

2. Buka cts/tests/module-name dan ganti semua instance "[Ss]ample" dengan konvensi penamaan yang direkomendasikan di atas.
3. Perbarui SampleDeviceActivity untuk menggunakan fitur yang Anda uji.
4. Perbarui SampleDeviceTest untuk memastikan 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 project di samping src dengan kode native dan makefile Android.mk di dalamnya.

Makefile biasanya berisi setelan 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, ubah file Android.mk di root project untuk membuat kode native dan bergantung padanya, seperti yang ditunjukkan di bawah:

# 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))

Memperbaiki atau menghapus pengujian

Selain menambahkan pengujian baru, Anda dapat memperbaiki atau menghapus pengujian yang dianotasi dengan BrokenTest atau KnownFailure.

Kirim perubahan Anda

Ikuti alur kerja Mengirimkan perubahan kode saat memberikan kontribusi perubahan pada CTS.

• Pilih cabang pengembangan berdasarkan level API yang diterapkan patch.
• Kembangkan atau pilih perubahan ke cabang pengujian yang benar dengan DO NOT MERGE atau RESTRICT AUTOMERGE dalam pesan commit.

Peninjau akan ditugaskan untuk meninjau perubahan Anda dan memilih perubahan ke Gerrit internal yang sesuai.

Jadwal rilis dan informasi cabang

Rilis CTS mengikuti jadwal ini.

Catatan: Jadwal ini bersifat tentatif dan akan diperbarui seiring dengan kematangan CTS untuk versi Android tertentu.

Versi	Level API	Cabang pengembangan	Frekuensi rilis
16+	36+	Gerrit internal	Per kuartal
15	35	android15-tests-dev	Per kuartal
14	34	android14-tests-dev	Per kuartal
13	33	android13-tests-dev	Per kuartal

Catatan: Tidak ada rilis lebih lanjut yang direncanakan untuk versi 4.2 hingga 12.1.

Tanggal penting selama rilis

• Akhir minggu pertama: Penghentian perubahan kode. Perubahan yang digabungkan di cabang hingga penghentian kode akan dipertimbangkan untuk CTS versi mendatang. Pengiriman ke cabang setelah pembekuan kode, atau setelah kandidat untuk rilis dipilih, akan dipertimbangkan untuk rilis berikutnya.
• Minggu kedua atau ketiga: CTS dipublikasikan di halaman Download Compatibility Test Suite.

Alur penggabungan otomatis

Cabang pengembangan CTS telah disiapkan sehingga perubahan yang dikirimkan ke setiap cabang akan otomatis digabungkan ke cabang yang lebih tinggi.

Untuk perubahan langsung ke cabang pengembangan pengujian AOSP, jalur penggabungan otomatis adalah:
android13-tests-dev > android14-tests-dev > android15-tests-dev

• Untuk versi CTS 16+, peninjau akan memilih perubahan ke Gerrit internal yang sesuai.

Jika daftar perubahan (CL) gagal digabungkan dengan benar, penulis patch akan dikirimi email berisi petunjuk tentang cara menyelesaikan konflik. Dalam sebagian besar kasus, penulis patch dapat menggunakan petunjuk untuk melewati penggabungan otomatis CL yang bertentangan.

Jika cabang yang lebih lama memerlukan perubahan, patch harus dipilih dari cabang yang lebih baru.

Untuk perubahan pengujian yang berlaku untuk versi Android berikutnya, setelah Anda mengupload perubahan yang diusulkan, Google akan meninjaunya dan, jika diterima, akan memilihnya ke Gerrit internal.