Pengembangan CTS

Melakukan inisialisasi klien Repo

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

Kode contoh 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:

cd /path/to/android/root
make cts -j32 TARGET_PRODUCT=aosp_arm64
cts-tradefed

Di konsol CTS, masukkan:

tf> run cts --plan CTS

Menulis pengujian CTS

Pengujian CTS menggunakan JUnit dan API pengujian Android. Ulas Uji coba aplikasi Anda tutorial dan pengujian yang sudah ada pada direktori cts/tests. Pengujian CTS sebagian besar mengikuti konvensi yang sama dengan yang digunakan pada pengujian Android lainnya.

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

  • Pertimbangkan berbagai ukuran layar, orientasi, dan tata letak {i>keyboard<i}.
  • Hanya gunakan metode API publik. Dengan kata lain, hindari semua class, metode, dan kolom dengan anotasi hide.
  • Hindari menggunakan 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 di antara 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 pada contoh ini.
Kolom android.example.ClassC#FieldA Gunakan hanya jika pengujian Anda memvalidasi kolom API secara langsung, seperti pada contoh ini.

Jika pengujian Anda memverifikasi persyaratan CDD, anotasikan ID persyaratan (termasuk Bagian CDD ID dan ID Persyaratan) dengan @CddTest dalam kode uji CTS seperti yang ditampilkan pada contoh berikut. Dalam pesan commit, sebutkan persyaratan CDD mana yang diuji oleh tes dengan merujuk pada ID persyaratan CDD. ID persyaratan CDD adalah kombinasi dari 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, anotasikan setiap Aktivitas di AndroidManifest.xml Anda dengan ID CDD yang relevan. Format untuk isian nilai mirip dengan format anotasi Java dalam CTS. Dalam pesan commit, sebutkan persyaratan CDD mana yang diberlakukan dengan mereferensikan CDD ID persyaratan. 


  <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 dukungan. Untuk CTS-D pengujian, sertakan link ke proposal pengujian yang Anda buat di Issue Tracker Google sebagai bagian dari 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 subpaket:

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, di mana setiap biasanya melatih metode kelas tertentu yang diuji. Pengujian ini diatur dalam struktur direktori tempat pengujian dikelompokkan ke dalam berbagai kategori, seperti "widget" atau "tampilan".

Misalnya, uji CTS untuk paket Java android.widget.TextView sama dengan 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 kelas
    Nama kelas untuk pengujian CTS adalah nama class yang akan diuji dengan "Test" ditambahkan. Sebagai 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 (di contoh, widget).

Struktur direktori dan kode sampel bergantung pada apakah Anda menggunakan CTS v1 atau tidak atau CTS v2.

CTS v1

Untuk Android 6.0 atau yang lebih rendah, 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 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 sudah ada untuk menempatkan uji coba. Dalam kasus tersebut, Anda perlu membuat direktori dan menyalin contoh file yang sesuai.

CTS v1

Jika Anda menggunakan CTS v1, lihat contoh pada cts/tests/tests/example dan buat direktori baru. Selain itu, pastikan untuk menambahkan nama modul paket baru dari Android.mk menjadi CTS_COVERAGE_TEST_CASE_LIST inci cts/CtsTestCaseList.mk. build/core/tasks/cts.mk menggunakan makefile ini untuk menggabungkan semua tes dan membuat paket CTS akhir.

CTS v2

Menggunakan pengujian contoh /cts/tests/sample/ untuk memulai cepat modul pengujian baru Anda 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 "[S]cukup" dengan konvensi penamaan yang direkomendasikan dari penjelasan di atas.
  3. Update SampleDeviceActivity untuk menerapkan fitur yang Anda uji.
  4. Update SampleDeviceTest untuk memastikan aktivitas berhasil atau dicatat dalam log {i>error <i}tersebut.

Direktori tambahan

Direktori Android lain seperti assets, jni, libs, dan res juga dapat ditambahkan. Untuk menambahkan kode JNI, buat direktori di root project di samping src dengan native kode 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, ubah file Android.mk di root project untuk membangun kode native 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))

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 Anda berdasarkan level API yang menerapkan patch.

  • Untuk perubahan yang berlaku di beberapa level API, pertama kembangkan patch di aosp/main lalu pilih patch ke cabang pengujian upstream. Mengizinkan automerger untuk menggabungkan perubahan downstream 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 terbaik perubahan pada cabang pengujian yang benar dengan JANGAN MENGGABUNGKAN atau BATASI OTOMERGE dalam pesan commit.

Ikuti Alur kerja pengiriman patch berkontribusi terhadap perubahan CTS. 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 digabungkan di cabang hingga {i>code freeze<i} dipertimbangkan untuk versi CTS yang akan datang. Pengiriman ke cabang setelah penghentian kode, atau setelah kandidat untuk dipilih, dipertimbangkan untuk rilis berikutnya.
  • Minggu kedua atau ketiga: CTS dipublikasikan di AOSP.

Alur penggabungan otomatis

Cabang pengembangan CTS telah dibentuk sehingga perubahan yang dikirimkan ke setiap secara otomatis bergabung ke cabang yang lebih tinggi.

Untuk perubahan langsung ke cabang dev 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 changelist (CL) gagal digabungkan dengan benar, penulis patch akan dikirim email yang berisi petunjuk tentang cara menyelesaikan konflik tersebut. Di sebagian besar ini, penulis {i>patch<i} dapat menggunakan petunjuk untuk melewati penggabungan otomatis CL yang berkonflik.

Jika cabang yang lebih lama memerlukan perubahan, maka {i>patch<i} tersebut harus yang dipetik dari cabang yang lebih baru.