Pengembangan CTS

Melakukan inisialisasi klien Repo

Ikuti petunjuk dari Mendownload Sumber untuk mendapatkan dan mem-build kode sumber Android. Saat mengeluarkan perintah repo init, tentukan cabang CTS tertentu menggunakan -b. Tindakan 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

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 atau yang lebih baru)

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

Di konsol CTS, masukkan:

tf> run cts --plan CTS

Menulis pengujian CTS

Pengujian CTS menggunakan JUnit dan API pengujian Android. Tinjau tutorial Menguji 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.
  • 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 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 jika pengujian Anda memvalidasi kolom API secara langsung, seperti dalam contoh ini.

Jika pengujian Anda memverifikasi persyaratan CDD, anotasikan 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 dihubungkan 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, anotasikan setiap Aktivitas di AndroidManifest.xml 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 mereferensikan 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 Issue Tracker Google 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-rencana:

run cts --subplan aSubPlan

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

Pengujian penamaan dan lokasi

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 menggunakan 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 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 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 contoh 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 pengujian contoh di Project 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 contoh 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 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 contoh pengujian /cts/tests/sample/ untuk memulai modul pengujian baru dengan cepat dengan 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 errornya.

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.

File make 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 dianotasi dengan BrokenTest atau KnownFailure.

Kirim perubahan Anda

Saat mengirimkan patch CTS atau VTS di AOSP, pilih cabang pengembangan berdasarkan API level yang diterapkan patch.

  • Untuk perubahan yang berlaku untuk beberapa level API, pertama kembangkan patch di aosp/main, lalu pilih cabang pengujian upstream paling baru. Izinkan penggabungan otomatis untuk menggabungkan perubahan di downstream di cabang pengujian AOSP. Lihat Jadwal rilis dan informasi cabang untuk mengetahui daftar cabang dan informasi jalur penggabungan otomatis.
  • Untuk perubahan yang spesifik untuk level API tertentu, kembangkan atau pilih perubahan ke cabang pengujian yang benar dengan DO NOT MERGE atau RESTRICT AUTOMERGE dalam pesan commit.

Ikuti Alur kerja pengiriman patch untuk berkontribusi pada perubahan CTS. Seorang peninjau akan ditugaskan untuk meninjau perubahan Anda.

Jadwal rilis dan informasi cabang

Rilis CTS mengikuti jadwal ini.

Versi Level API Cabang Frekuensi
15 35 android15-tests-dev Per kuartal
14 34 android14-tests-dev Per kuartal
13 33 android13-tests-dev Per kuartal
12L 32 android12L-tests-dev Per kuartal
12 31 android12-tests-dev Per kuartal

Tanggal penting selama rilis

  • Akhir minggu pertama: Pembekuan kode. Perubahan yang digabungkan di cabang hingga pembekuan kode akan dipertimbangkan untuk versi CTS mendatang. Kiriman ke cabang setelah pembekuan kode, atau setelah kandidat untuk rilis dipilih, akan dipertimbangkan untuk rilis berikutnya.
  • Minggu kedua atau ketiga: CTS dipublikasikan di AOSP.

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 developer pengujian AOSP, jalur penggabungan otomatis adalah:
android11-tests-dev > android12-tests-dev > android12L-tests-dev > android13-tests-dev > android14-tests-dev > android15-tests-dev > aosp-main

Untuk perubahan hanya pada versi Android berikutnya, jalur penggabungan otomatis adalah:
aosp-main > <Internal git_main>.

Jika daftar perubahan (CL) gagal digabungkan dengan benar, penulis patch akan menerima email yang 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.