pengembangan CTS

Inisialisasi klien Repo Anda

Ikuti instruksi dari Mengunduh Sumber untuk mendapatkan dan membuat 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 .

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 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.
• Gunakan hanya metode API publik. Dengan kata lain, hindari semua kelas, metode, dan bidang dengan anotasi hide .
• Hindari penggunaan 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:

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 penerapan 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 CTS Verifier, beri anotasi pada setiap Aktivitas di AndroidManifest.xml Anda dengan ID CDD yang relevan. Format bidang nilai mirip dengan format anotasi Java di CTS. Dalam pesan penerapan, sebutkan persyaratan CDD mana 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 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 subrencana:

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

Uji penamaan dan lokasi

Kebanyakan kasus uji 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 pengujian, di mana setiap pengujian biasanya menggunakan metode tertentu dari kelas yang diuji. Pengujian ini disusun dalam struktur direktori tempat pengujian dikelompokkan ke dalam kategori berbeda 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 kelasnya sebagai TextViewTest .

• Nama paket Java
  Nama paket Java untuk pengujian CTS adalah nama paket kelas yang diuji, diikuti dengan .cts . Sebagai contoh, nama paketnya adalah android.widget.cts .
• Nama kelas
  Nama kelas untuk tes CTS adalah nama kelas yang diuji dengan tambahan "Tes". Misalnya, jika pengujian menargetkan TextView , nama kelasnya harus TextViewTest .
• Nama modul (hanya CTS v2)
  CTS v2 mengatur tes 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 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 lebih tinggi, gunakan CTS v2. Untuk 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 sampel baru

Saat menambahkan pengujian baru, mungkin tidak ada direktori 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. Selain itu, 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 pengujian dan membuat paket CTS akhir.

CTS v2

Gunakan tes sampel /cts/tests/sample/ untuk memulai modul pengujian baru Anda dengan cepat 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. Navigasikan ke cts/tests/ module-name dan gantikan 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 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 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, modifikasi file Android.mk di root proyek untuk membuat 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))

Perbaiki atau hapus tes

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

Kirimkan perubahan Anda

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

• Untuk perubahan yang berlaku pada beberapa level API, pertama-tama kembangkan patch di aosp/main lalu pilih cabang pengujian paling hulu . Izinkan penggabungan otomatis untuk menggabungkan perubahan hilir 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 perubahan pada cabang pengujian yang benar dengan JANGAN MERGE atau RESTRICT AUTOMERGE dalam pesan penerapan.

Ikuti alur kerja Mengirimkan patch untuk menyumbangkan perubahan pada CTS. Seorang peninjau akan ditugaskan untuk meninjau perubahan Anda.

Jadwal rilis dan informasi cabang

Rilis CTS mengikuti jadwal ini.

Tanggal-tanggal penting selama rilis

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

Aliran penggabungan otomatis

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

Untuk perubahan langsung ke cabang pengembang pengujian AOSP, jalur penggabungan otomatisnya adalah:
android11-tests-dev > android12-tests-dev dev > android12L-tests-dev > android13-tests-dev > android14-tests-dev > aosp/main

Untuk perubahan hanya pada versi Android berikutnya, jalur penggabungan otomatisnya adalah:
aosp/main > <Internal git/main> .

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

Jika cabang yang lebih tua memerlukan perubahan, maka tambalan tersebut harus dipilih dari cabang yang lebih baru.