CTS geliştirme

Repo istemcinizi başlatma

Android kaynak kodunu indirip derlemek için Kaynak kodunu indirme bölümündeki talimatları uygulayın. repo init komutunu verirken -b kullanarak belirli bir CTS şubesini belirtin. Bu sayede CTS değişiklikleriniz sonraki CTS sürümlerine dahil edilir.

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

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

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

CTS'yi derlemek ve etkileşimli CTS konsolunu başlatmak için aşağıdaki komutları yürütün:

CTS derlemesi (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 derlemesi (AOSP 15 veya sonraki sürümler)

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:

Şube Hedef Sürüm
android15-tests-dev ap3a

CTS konsoluna şunu girin:

tf> run cts --plan CTS

CTS testleri yazma

talimatları uygulayarak bir test önerisi göndermeniz gerekir.

CTS testleri JUnit ve Android test API'lerini kullanır. cts/tests dizininde bulunan Uygulamanızı test edin eğitimini ve mevcut testleri inceleyin. CTS testleri çoğunlukla diğer Android testlerinde kullanılan aynı kurallara uyar.

CTS birçok üretim cihazında çalışır. Bu nedenle, testler aşağıdaki kurallara uymalıdır:

  • Farklı ekran boyutlarını, yönleri ve klavye düzenlerini göz önünde bulundurun.
  • Yalnızca herkese açık API yöntemlerini kullanın. Diğer bir deyişle, hide ek açıklamalı tüm sınıflardan, yöntemlerden ve alanlardan kaçının.
  • Görüntüleme düzenleri 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ğrularsa test kodunuzu @ApiTest ile ek açıklamayla belirtin ve apis alanındaki tüm API'leri listeleyin. Aşağıdaki örnekler arasından uygun biçimi kullanın:

API türü Ek açıklama biçimi Notlar
Yöntem android.example.ClassA#methodA En yaygın kullanım alanı.
Anahtar/değer çiftleri içeren yöntem android.example.ClassB#methodB(KeyA) Yalnızca testiniz bir alanı doğrulamak için API yöntemi kullandığında (bu örnekte olduğu gibi) kullanın.
Alan android.example.ClassC#FieldA Yalnızca testiniz bir API alanını doğrudan doğrularken kullanın (bu örnekte olduğu gibi).

Testiniz bir CDD koşulunu doğruluyorsa CTS test kodunda koşul kimliğini (CDD bölüm kimliği ve koşul kimliği dahil) aşağıdaki örnekte gösterildiği gibi @CddTest ile ek açıklama ekleyin. CDD şartı kimliklerini referans göstererek hangi CDD şartının testiniz tarafından test edildiğini belirtmek için commit mesajınızdan yararlanın. CDD şart kimlikleri, bölüm kimliği ve şart kimliğinin bir kombinasyonudur ve 7.3.1/C-1-1'de olduğu gibi eğik çizgiyle (/) birbirine 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 Doğrulayıcı için AndroidManifest.xml dosyanızdaki her etkinliği ilgili CDD kimliğiyle ek açıklamalı hale getirin. Değer alanlarının biçimleri, CTS'deki Java ek açıklamalarının biçimlerine benzer. Taahhüt mesajında, CDD şartı kimliğine atıfta bulunarak 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 açıkça belirtin ve destek için ilgili bağlantıları ekleyin. CTS-D testleri için CTS-D gönderim sürecinin bir parçası olarak Google Issue Tracker'da oluşturduğunuz test teklifinin bağlantısını ekleyin.

Alt plan oluşturma

Örneğin, android-cts/subplans içine 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ş biçimi şu şekildedir:

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ırma ve konumu

Çoğu CTS test senaryosu, Android API'deki belirli bir sınıfı hedefler. Bu testlerde cts son eki içeren Java paket adları ve Test son eki içeren sınıf adları bulunur. Her test senaryosu, genellikle test edilen sınıfın belirli bir yöntemini çalıştıran birden fazla testten oluşur. Bu testler, testlerin "widget'lar" veya "görüntüler" gibi farklı kategorilerde gruplandırıldığı bir dizin yapısında düzenlenir.

Örneğin, android.widget.TextView Java paketi için CTS testi, android.widget.cts Java paketi adıyla ve TextViewTest sınıf adıyla android.widget.cts.TextViewTest şeklindedir.

  • Java paket adı
    CTS testlerinin Java paket adı, testin test ettiği sınıfın paket adının 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 "Test" eklenmiş adıdır. Ö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 (örnekimizde widget).

Dizin yapısı ve örnek kod, CTS v1 mi yoksa CTS v2 mi kullandığınıza bağlıdır.

CTS v1

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

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ümler için CTS v2'yi kullanın. Ayrıntılar için Android Açık Kaynak Projesi'ndeki (AOSP) örnek teste bakın.

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 altındaki örneğe bakın ve yeni bir dizin oluşturun. Ayrıca, yeni paketinizin modül adını cts/CtsTestCaseList.mk'deki Android.mk bölümünden CTS_COVERAGE_TEST_CASE_LIST bölümüne eklediğinizden emin olun. build/core/tasks/cts.mk, tüm testleri birleştirmek ve nihai CTS paketini oluşturmak için bu makefile'i kullanır.

CTS v2

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

  1. Test dizinini oluşturmak ve örnek dosyaları kopyalamak için şunları çalıştırın: 
    mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name
  2. cts/tests/module-name adresine gidin ve "[Örnek]" ifadesinin tüm örneklerini yukarıdaki önerilen adlandırma kuralıyla değiştirin.
  3. Test ettiğiniz özelliği çalıştırmak için SampleDeviceActivity öğesini güncelleyin.
  4. Etkinliğin başarılı olmasını veya hatalarını kaydetmesini sağlamak için SampleDeviceTest değerini güncelleyin.

Ek dizinler

assets, jni, libs ve res gibi diğer Android dizinleri de eklenebilir. JNI kodu eklemek için projenin kökünde, src'nin yanında yerel kodu ve bir 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 derlemek ve ona bağımlı olmak 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 ek açıklama eklenmiş testleri düzeltebilir ya da kaldırabilirsiniz.

Değişikliklerinizi gönderin

AOSP'te CTS veya VTS yamalarını gönderirken, yamanın geçerli olduğu API düzeylerine göre geliştirme dalınızı seçin.

  • Birden fazla API düzeyi için geçerli olan değişikliklerde önce aosp/main'de bir yama geliştirin ve ardından en üst test dalına seçkin değişiklikleri ekleyin. Otomatik birleştirme aracının, AOSP test dallarındaki değişiklikleri alt akışta birleştirmesine izin verin. Şubelerin listesi ve otomatik birleştirme yolu bilgileri için Sürüm planı ve şube bilgileri başlıklı makaleyi inceleyin.
  • Belirli bir API düzeyine özgü değişiklikler için, kaydetme mesajında DO NOT MERGE (Birleştirmeyin) veya RESTRICT AUTOMERGE (Otomatik birleştirmeyi kısıtlayın) seçeneğini belirleyerek değişiklikleri doğru test dalında geliştirin ya da seçin.

CTS'ye katkıda bulunmak için Yama gönderme iş akışını uygulayın. Değişikliklerinizi incelemesi için bir inceleme uzmanı atanır.

Sürüm planı ve şube bilgileri

CTS sürümleri bu programa uyar.

Sürüm API seviyesi Şube Sıklık
15 35 android15-tests-dev Üç Aylık
14 34 android14-tests-dev Üç Aylık
13 33 android13-tests-dev Üç Aylık
12L 32 android12L-tests-dev Üç Aylık
12 31 android12-tests-dev Üç Aylık

Sürüm sırasındaki önemli tarihler

  • İlk haftanın sonu: Kod dondurulur. Kod dondurulana kadar dallara birleştirilen değişiklikler, CTS'nin gelecekteki sürümü için değerlendirilir. Kod dondurulduktan veya sürüm için bir aday seçildikten sonra şubeye gönderilen gönderimler sonraki sürüm için değerlendirilir.
  • İkinci veya üçüncü hafta: CTS, AOSP'de yayınlanır.

Otomatik birleştirme akışı

CTS geliştirme dalları, her bir dala gönderilen değişikliklerin üst dallara otomatik olarak birleştirilmesi için ayarlanmıştır.

Doğrudan bir AOSP test geliştirici dalında yapılan değişiklikler için otomatik birleştirme yolu şudur:
android11-tests-dev > android12-tests-dev > android12L-tests-dev > android13-tests-dev > android14-tests-dev > android15-tests-dev > aosp-main

Yalnızca bir sonraki Android sürümünde yapılan değişiklikler için otomatik birleştirme yolu:
aosp-main > <Internal git_main>.

Bir değişiklik listesi (CL) doğru şekilde birleştirilemezse yamayı yazan kullanıcıya, çakışmanın nasıl çözüleceğine dair talimatlar içeren bir e-posta gönderilir. Çoğu durumda, yamanın yazarı, çakışan CL'nin otomatik birleştirme işlemini atlama talimatlarını kullanabilir.

Değişiklik için daha eski bir dal gerekiyorsa yamanın yeni daldan seçilmesi gerekir.