CTS geliştirme

Repo istemcinizi başlatma

Android kaynak kodunu edinmek ve oluşturmak için Kaynak Kodu İndirme bölümündeki talimatları uygulayın. repo init komutunu verirken -b kullanarak belirli bir CTS dalı belirtin. Bu sayede, CTS değişikliklerinizin sonraki CTS sürümlerine dahil edilmesi sağlanır.

Aşağıdaki örnek kodda repo init simgesinin nasıl kullanılacağı gösterilmektedir.

CTS'yi derleme ve çalıştırma

CTS'yi oluşturmak ve etkileşimli CTS konsolunu başlatmak için aşağıdaki komutları çalıştırın:

CTS oluşturma (AOSP 14 veya önceki sürümler)

cd /path/to/android/root
source build/envsetup.sh
make cts -j32 TARGET_PRODUCT=aosp_arm64
cts-tradefed

CTS'yi oluşturma (AOSP 15)

cd /path/to/android/root
source build/envsetup.sh
make cts -j32 TARGET_PRODUCT=aosp_arm64 TARGET_RELEASE=target-release
cts-tradefed

target-release değerini seçmek için lütfen aşağıdaki tabloya bakın:

CTS'yi çalıştırma

CTS konsolunda şunu girin:

tf> run cts --plan CTS

CTS testleri yazma

CTS testlerinde JUnit ve Android test API'leri kullanılır. cts/tests dizinindeki Uygulamanızı test etme eğitimini ve mevcut testleri inceleyin. CTS testleri, diğer Android testlerinde kullanılan kuralların çoğuna uyar.

CTS birçok üretim cihazında çalışır. Bu nedenle testlerin aşağıdaki kurallara uyması gerekir:

• Farklı ekran boyutlarını, yönlerini ve klavye düzenlerini göz önünde bulundurun.
• Yalnızca herkese açık API yöntemlerini kullanın. Başka bir deyişle, hide ek açıklamasına sahip tüm sınıflardan, yöntemlerden ve alanlardan kaçının.
• Görünüm düzenlerini kullanmaktan veya bazı cihazlarda bulunmayabilecek öğelerin boyutlarına güvenmekten kaçının.
• Kök ayrıcalıklarına güvenmeyin.

Java notu ekleme

Testiniz bir API davranışını doğruluyorsa test kodunuza @ApiTest ekleyin ve apis alanında ilgili tüm API'leri listeleyin. Aşağıdaki örnekler arasından uygun biçimi kullanın:

Testiniz bir CDD şartını doğruluyorsa aşağıdaki örnekte gösterildiği gibi CTS test kodunda şart kimliğini (CDD bölüm kimliği ve şart kimliği dahil) @CddTest ile açıklama olarak ekleyin. Commit mesajınızda, CDD koşulu kimliklerine atıfta bulunarak testinizin hangi CDD koşulunu test ettiğini belirtin. CDD koşulu kimlikleri, bölüm kimliği ve koşul kimliğinin birleşimidir. 7.3.1/C-1-1 örneğinde olduğu gibi, eğik çizgiyle (/) bağlanır.

/**
* 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()));
    }

CTS Verifier için AndroidManifest.xml içindeki her bir Etkinliğe ilgili CDD kimliğini ekleyin. Değer alanlarının biçimleri, CTS'deki Java ek açıklamalarının biçimlerine benzer. Commit iletisinde, CDD şartı kimliğine referans vererek hangi CDD şartının zorunlu kılındığını belirtin.

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

Kaydetme mesajında

Testinizin neden eklenmesi gerektiğini net bir şekilde belirtin ve destek için ilgili bağlantıları ekleyin. CTS-D testleri için CTS-D gönderim süreci kapsamında Google Issue Tracker'da oluşturduğunuz test önerisine bir bağlantı ekleyin.

Alt plan oluşturma

Örneğin, android-cts/subplans klasörüne aşağıdaki gibi bir SubPlan.xml dosyası ekleyebilirsiniz:

<?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>

Alt planı çalıştırmak için:

run cts --subplan aSubPlan

Alt plan girişi biçimi şöyledir:

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

Test adlandırması ve konumu

Çoğu CTS test durumu, Android API'sindeki belirli bir sınıfı hedefler. Bu testlerde, cts sonekine sahip Java paketi adları ve Test sonekine sahip sınıf adları bulunur. Her test senaryosu birden fazla testten oluşur. Bu testlerin her biri genellikle test edilen sınıfın belirli bir yöntemini çalıştırır. Bu testler, testlerin "widget'lar" veya "görünümler" gibi farklı kategorilerde gruplandırıldığı bir dizin yapısında düzenlenir.

Örneğin, android.widget.TextView Java paketi için CTS testi, Java paket adı android.widget.cts ve sınıf adı TextViewTest olan android.widget.cts.TextViewTest'dir.

• Java paket adı
  CTS testlerinin Java paket adı, testin test ettiği sınıfın paket adıdır ve ardından .cts gelir. Örneğimizde paket adı android.widget.cts olur.
• Sınıf adı
  CTS testlerinin sınıf adı, test edilen sınıfın adının sonuna "Test" eklenerek oluşturulur. Örneğin, bir test TextView hedefliyorsa sınıf adı TextViewTest olmalıdır.
• Modül adı (yalnızca CTS v2)
  CTS v2, testleri modüle göre düzenler. Modül adı genellikle Java paket adının ikinci dizesidir (örneğimizde widget).

Dizin yapısı ve örnek kod, CTS v1 veya CTS v2 kullanıp kullanmadığınıza bağlıdır.

CTS v1

Android 6.0 veya önceki sürümlerde CTS v1'i kullanın. CTS v1 için örnek kod cts/tests/tests/example adresinde yer alır.

CTS v1 testlerindeki dizin yapısı şu şekildedir:

cts/
  tests/
    tests/
      package-name/
        Android.mk
        AndroidManifest.xml
        src/
          android/
            package-name/
              SampleDeviceActivity.java
              cts/
                SampleDeviceTest.java

CTS v2

Android 7.0 veya sonraki sürümlerde CTS v2'yi kullanın. Ayrıntılar için Android Açık Kaynak Projesi'ndeki (AOSP) örnek testi inceleyin.

CTS v2 dizin yapısı şu şekildedir:

cts/
  tests/
    module-name/
      Android.mk
      AndroidManifest.xml
      src/
        android/
          package-name/
            SampleDeviceActivity.java
            cts/
              SampleDeviceTest.java

Yeni örnek paketler

Yeni testler eklerken testinizi yerleştirebileceğiniz mevcut bir dizin olmayabilir. Bu gibi durumlarda dizini oluşturmanız ve uygun örnek dosyaları kopyalamanız gerekir.

CTS v1

CTS v1 kullanıyorsanız cts/tests/tests/example bölümündeki örneğe bakın ve yeni bir dizin oluşturun. Ayrıca, yeni paketinizin modül adını Android.mk bölümünden CTS_COVERAGE_TEST_CASE_LIST bölümüne cts/CtsTestCaseList.mk içinde eklediğinizden emin olun. build/core/tasks/cts.mk, tüm testleri birleştirmek ve nihai CTS paketini oluşturmak için bu makefile'ı kullanır.

CTS v2

Yeni test modülünüzü hızlı bir şekilde başlatmak için aşağıdaki adımları uygulayarak örnek testi kullanın: /cts/tests/sample/

1. Test dizinini oluşturmak ve örnek dosyaları kopyalamak için şunu çalıştırın:

   mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name

2. cts/tests/module-name konumuna gidin ve tüm "[Ss]ample" örneklerini yukarıdaki önerilen adlandırma kuralıyla değiştirin.
3. Test ettiğiniz özelliği kullanmak için SampleDeviceActivity öğesini güncelleyin.
4. Etkinliğin başarılı olmasını veya hatalarını günlüğe kaydetmesini sağlamak için SampleDeviceTest öğesini güncelleyin.

Ek dizinler

assets, jni, libs ve res gibi diğer Android dizinleri de eklenebilir. JNI kodu eklemek için projenin kök dizininde src ile aynı seviyede, yerel kodu ve Android.mk makefile'ı içeren bir dizin oluşturun.

Makefile genellikle aşağıdaki ayarları içerir:

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)

Android.mk dosyası

Son olarak, yerel kodu oluşturmak ve buna bağlı kalmak için projenin kökündeki Android.mk dosyasını aşağıdaki gibi değiştirin:

# 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))

Testleri düzeltme veya kaldırma

Yeni testler eklemenin yanı sıra BrokenTest veya KnownFailure ile açıklama eklenmiş testleri düzeltebilir ya da kaldırabilirsiniz.

Değişikliklerinizi gönderin

CTS'ye değişiklik gönderirken Kod değişikliklerini gönderme iş akışını izleyin.

• Yamanın uygulandığı API düzeylerine göre geliştirme dalını seçin.
• Değişiklikleri geliştirin veya doğru test dalına seçerek uygulayın. Commit mesajında DO NOT MERGE (Birleştirme) veya RESTRICT AUTOMERGE (Otomatik birleştirmeyi kısıtla) kullanın.

Değişikliğinizi incelemek ve dahili Gerrit'e aktarmak için bir incelemeci atanır.

Yayın planı ve şube bilgileri

CTS sürümleri bu programa göre yayınlanır.

Yayın sırasında önemli tarihler

• İlk haftanın sonu: Kod dondurma. Kod dondurma işlemine kadar dalda birleştirilen değişiklikler, CTS'nin gelecek sürümünde dikkate alınır. Kod dondurma işleminden sonra veya yayın adayı seçildikten sonra dala gönderilenler sonraki sürüm için değerlendirilir.
• İkinci veya üçüncü hafta: CTS, Compatibility Test Suite indirmeleri sayfasında yayınlanır.

Otomatik birleştirme akışı

CTS geliştirme dalları, her dala gönderilen değişikliklerin otomatik olarak daha yüksek dallarla birleştirileceği şekilde ayarlanmıştır.

Doğrudan bir AOSP test geliştirme dalında yapılan değişiklikler için otomatik birleştirme yolu şöyledir:
android13-tests-dev > android14-tests-dev > android15-tests-dev

• CTS 16 ve sonraki sürümlerde, incelemeyi yapacak kişi değişikliği dahili Gerrit'e göre seçerek uygular.

Bir değişiklik listesi (CL) doğru şekilde birleştirilemezse yama yazarına, çakışmayı çözmeyle ilgili talimatların yer aldığı bir e-posta gönderilir. Çoğu durumda, yamanın yazarı, çakışan CL'nin otomatik birleştirilmesini atlamak için talimatları kullanabilir.

Daha eski bir dalda değişiklik yapılması gerekiyorsa yamanın daha yeni daldan seçilmesi gerekir.

Bir sonraki Android sürümü için geçerli olan test değişikliklerinde, önerilen bir değişikliği yükledikten sonra Google bu değişikliği inceler ve kabul ederse dahili Gerrit'e seçerek ekler.