Pengembangan CTS

Menginisialisasi klien Repo

Ikuti petunjuk dari Mendownload Kode Sumber untuk mendapatkan dan mem-build kode sumber Android. Saat mengeluarkan perintah repo init, tentukan cabang CTS tertentu menggunakan -b. Hal ini memastikan perubahan CTS Anda disertakan dalam rilis CTS berikutnya.

Contoh kode berikut menunjukkan cara menggunakan repo init.

Mem-build dan menjalankan CTS

Jalankan perintah berikut untuk mem-build CTS dan memulai konsol CTS interaktif:

Mem-build 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

Mem-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:

Menjalankan CTS

Di konsol CTS, masukkan:

tf> run cts --plan CTS

Menulis pengujian CTS

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

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

• Perhatikan 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, beri anotasi pada kode pengujian Anda dengan @ApiTest dan cantumkan semua API yang terlibat di kolom apis. Gunakan format yang sesuai dari contoh berikut:

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, 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 terhubung dengan garis miring (/) seperti dalam 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 mana yang diterapkan dengan merujuk ke 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 tests, sertakan link ke proposal pengujian yang Anda buat di Google Issue Tracker sebagai bagian dari the proses pengiriman CTS-D.

Membuat 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 subrencana 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, dengan setiap pengujian biasanya menjalankan 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 sebagai android.widget.cts dan nama class sebagai TextViewTest.

• Nama paket Java
  Nama paket Java untuk pengujian CTS adalah nama paket class yang 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 menambahkan "Test". Misalnya, jika pengujian menargetkan TextView, nama class harus TextViewTest.
• Nama modul (khusus CTS v2)
  CTS v2 mengatur pengujian berdasarkan modul. Nama modul biasanya adalah 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 baru, gunakan CTS v2. Untuk mengetahui 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 contoh baru

Saat menambahkan pengujian baru, mungkin tidak ada direktori yang ada untuk menempatkan pengujian Anda. Dalam kasus tersebut, Anda harus 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 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 dari atas.
3. Perbarui SampleDeviceActivity untuk menjalankan fitur yang Anda uji.
4. Perbarui SampleDeviceTest untuk memastikan aktivitas berhasil atau mencatat error-nya.

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 mem-build 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 diberi anotasi dengan BrokenTest atau KnownFailure.

Mengirim perubahan Anda

Ikuti alur kerja Mengirim perubahan kode saat berkontribusi perubahan ke CTS.

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

Peninjau akan ditugaskan untuk meninjau perubahan Anda dan melakukan cherrypick perubahan ke Gerrit internal sesuai.

Jadwal rilis dan informasi cabang

Rilis CTS mengikuti jadwal ini.

Tanggal penting selama rilis

• Akhir minggu pertama: Pembekuan kode. Perubahan yang digabungkan di cabang hingga pembekuan kode akan dipertimbangkan untuk versi CTS 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 CTS versi 16+, peninjau akan melakukan cherrypick perubahan ke Gerrit internal sesuai.

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

Jika cabang yang lebih lama memerlukan perubahan, patch harus di- cherrypick 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 melakukan cherrypick ke Gerrit internal.