Pengembangan CTS

Inisialisasi klien Repo Anda

Ikuti petunjuk dari Mengunduh Sumber untuk mendapatkan dan membuat kode sumber Android. Saat mengeluarkan perintah repo init , tentukan cabang CTS tertentu menggunakan -b . 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 bawah direktori cts/tests . Pengujian CTS sebagian besar mengikuti konvensi yang sama yang digunakan dalam pengujian Android lainnya.

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

  • Mempertimbangkan 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 menggunakan 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 kunci android.example.ClassB#methodB(KeyA) Gunakan hanya saat pengujian Anda menggunakan metode API untuk memvalidasi bidang, seperti dalam contoh ini.
Bidang android.example.ClassC#FieldA Gunakan hanya saat pengujian Anda memvalidasi bidang 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 komit 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 Pemverifikasi CTS, beri anotasi pada setiap Aktivitas di AndroidManifest.xml Anda dengan ID CDD yang relevan. Format untuk bidang nilai mirip dengan format anotasi Java di CTS. Dalam pesan komit, sebutkan persyaratan CDD mana yang diberlakukan dengan merujuk 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 subplan:

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" />

Penamaan dan lokasi tes

Sebagian besar kasus pengujian 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 tes, di mana setiap tes biasanya melatih metode tertentu dari kelas yang diuji. Tes ini diatur dalam struktur direktori di mana tes dikelompokkan ke dalam kategori yang berbeda 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 kelasnya sebagai TextViewTest .

  • Nama paket Java
    Nama paket Java untuk pengujian CTS adalah nama paket kelas yang diuji, diikuti oleh .cts . Untuk contoh kita, nama paketnya adalah android.widget.cts .
  • Nama kelas
    Nama kelas untuk tes CTS adalah nama kelas yang sedang diuji dengan "Test" ditambahkan. Misalnya, jika pengujian menargetkan TextView , nama kelas harus TextViewTest .
  • Nama modul (hanya 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 lebih rendah, gunakan CTS v1. Untuk CTS v1, kode sampel 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 pengujian sampel 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 yang ada 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. Juga, 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 tes dan membuat paket CTS akhir.

CTS v2

Gunakan sample test /cts/tests/sample/ untuk memulai cepat modul pengujian baru Anda dengan langkah-langkah berikut:

  1. Untuk membuat direktori pengujian dan menyalin file sampel, jalankan: 
    mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name
  2. Arahkan ke cts/tests/ module-name dan ganti semua instance "[Ss]ample" dengan konvensi penamaan yang disarankan dari atas.
  3. Perbarui SampleDeviceActivity untuk menjalankan fitur yang Anda uji.
  4. 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 file 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 membangun 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))

Memperbaiki atau menghapus tes

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

Mengirimkan perubahan Anda

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

  • Untuk perubahan yang berlaku untuk beberapa level API, pertama -tama kembangkan tambalan di aosp/master , lalu pilih cabang pengujian paling upstream . Izinkan automerger untuk menggabungkan perubahan hilir di cabang uji AOSP. Lihat Jadwal rilis dan informasi cabang untuk 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 JANGAN MENGGABUNGKAN atau MEMBATASI OTOMATIS dalam pesan komit.

Ikuti alur kerja Mengirim Patch untuk memberikan kontribusi perubahan pada CTS. Peninjau akan ditugaskan untuk meninjau perubahan Anda.

Jadwal rilis dan informasi cabang

Rilis CTS mengikuti jadwal ini.

Versi: kapan tingkat API Cabang Frekuensi
12L 32 android12L-tes-dev Triwulanan
12 31 android12-tes-dev Triwulanan
11 30 android11-tes-dev Triwulanan
10 29 android10-tes-dev Triwulanan
Tidak ada rilis lebih lanjut yang direncanakan untuk versi 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 perilisan

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

Aliran otomatis

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

Untuk perubahan langsung ke cabang AOSP, jalur automerge adalah:
pie-cts-dev > android10-tests-dev > android11-tests-dev > android12-tests-dev > android12L-tests-dev > aosp/master

Untuk perubahan pada versi Android yang akan datang, jalur automerge adalah:
aosp/master > <private-development-branch for Android T (AOSP experimental)> .

Jika daftar perubahan (CL) gagal digabungkan dengan benar, pembuat tambalan dikirimi email dengan instruksi tentang cara mengatasi konflik. Dalam sebagian besar kasus, pembuat tambalan dapat menggunakan instruksi untuk melewati penggabungan otomatis CL yang berkonflik.

Jika cabang yang lebih lama memerlukan perubahan, maka tambalan harus diambil dari cabang yang lebih baru.