CTS geliştirme

Repo istemcinizi başlatın

Android kaynak kodunu almak ve oluşturmak için Kaynağı İndirme bölümündeki talimatları izleyin. repo init komutunu verirken -b kullanarak belirli bir CTS dalını belirtin. Bu, CTS değişikliklerinizin sonraki CTS sürümlerine dahil edilmesini sağlar.

Aşağıdaki örnek kod repo init nasıl kullanılacağını gösterir.

CTS'yi oluşturun ve çalıştırın

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

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

CTS konsoluna şunu girin:

tf> run cts --plan CTS

CTS testleri yaz

CTS testleri JUnit'i ve Android test API'lerini kullanır. cts/tests dizini altındaki Uygulamanızı test etme eğitimini ve mevcut testleri inceleyin. CTS testleri çoğunlukla diğer Android testlerinde kullanılan aynı kuralları takip eder.

CTS birçok üretim cihazında çalıştığından testlerin şu kurallara uyması gerekir:

• Değişen ekran boyutlarını, yönlerini ve klavye düzenlerini dikkate alın.
• Yalnızca genel API yöntemlerini kullanın. Başka bir deyişle, hide 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 bulunmayan varlıkların boyutlarına güvenmekten kaçının.
• Kök ayrıcalıklarına güvenmeyin.

Java ek açıklaması ekle

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

Testiniz bir CDD gereksinimini doğruluyorsa, aşağıdaki örnekte gösterildiği gibi CTS test kodundaki gereksinim kimliğini (CDD Bölüm Kimliği ve Gereksinim Kimliği dahil) @CddTest ile açıklayın. Taahhüt mesajınızda, CDD gereksinim kimliklerine başvurarak testiniz tarafından hangi CDD gereksiniminin test edildiğini belirtin. CDD gereksinim kimlikleri, 7.3.1/C-1-1'de olduğu gibi eğik çizgi (/) ile bağlanan bölüm kimliği ve gereksinim kimliğinin birleşimidir.

/**
* 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ğe ilgili CDD kimliğiyle açıklama ekleyin. Değer alanlarının formatları, CTS'deki Java ek açıklamalarının formatlarına benzer. Taahhüt mesajında, CDD gereksinim kimliğine başvurarak hangi CDD gereksiniminin 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>

Taahhüt 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.

Bir alt plan oluşturun

Örnek olarak, android-cts/subplans bir SubPlan.xml dosyasını aşağıdaki gibi 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ş formatı şö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" />

Adlandırmayı ve konumu test edin

Çoğu CTS test senaryosu, Android API'sinde belirli bir sınıfı hedefler. Bu testlerin cts son ekine sahip Java paket adları ve Test son ekine sahip sınıf adları vardır. Her test durumu, her testin tipik olarak test edilen sınıfın belirli bir yöntemini uyguladığı birden fazla testten oluşur. Bu testler, testlerin "widget'lar" veya "görünümler" gibi farklı kategoriler halinde gruplandırıldığı bir dizin yapısında düzenlenir.

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

• Java paketi adı
  CTS testleri için Java paket adı, testin test ettiği sınıfın paket adı ve ardından .cts gelir. Örneğimiz için paket adı android.widget.cts olacaktır.
• Sınıf adı
  CTS testleri için sınıf adı, "Test" eklenerek test edilen sınıfın 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 (örneğimizde widget ).

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

CTS v1

Android 6.0 veya daha düşük sürümler için CTS v1'i kullanın. CTS v1 için örnek kod cts/tests/tests/example konumundadır.

CTS v1 testlerindeki dizin yapısı şuna benzer:

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

CTS v2

Android 7.0 veya üzeri 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ı şuna benzer:

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 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ı Android.mk cts/CtsTestCaseList.mk içindeki CTS_COVERAGE_TEST_CASE_LIST eklediğinizden emin olun. build/core/tasks/cts.mk tüm testleri birleştirmek ve son CTS paketini oluşturmak için bu makefile dosyasını kullanır.

CTS v2

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

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 adresine gidin ve tüm "[Ss]ample" örneklerini yukarıda önerilen adlandırma kuralıyla değiştirin.
3. Test ettiğiniz özelliği kullanmak için SampleDeviceActivity güncelleyin.
4. Etkinliğin başarılı olduğundan emin olmak veya hatalarını günlüğe kaydettirmek için SampleDeviceTest güncelleyin.

Ek dizinler

assets , jni , libs ve res gibi diğer Android dizinleri de eklenebilir. JNI kodunu eklemek için projenin kökünde src yanında yerel kod ve içinde bir Android.mk makefile dosyası bulunan 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 ona bağlı olmak için projenin kökündeki Android.mk dosyasını aşağıda gösterildiği 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üzeltin veya kaldırın

Yeni testler eklemenin yanı sıra BrokenTest veya KnownFailure ile açıklamalı testleri düzeltebilir veya kaldırabilirsiniz.

Değişikliklerinizi gönderin

AOSP'de 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 çok API düzeyine uygulanan değişiklikler için, önce aosp/main bir yama geliştirin ve ardından en üstteki test dalına doğru seçim yapın. Otomatik birleştirmenin, AOSP test dallarındaki değişiklikleri aşağı yönde birleştirmesine izin verin. Şubelerin listesi ve otomatik birleştirme yolu bilgileri için Yayın planı ve şube bilgilerine bakın.
• Belirli bir API düzeyine özel değişiklikler için, taahhüt mesajında ​​DO NOT MERGE veya RESTRICT AUTOMERGE ile doğru test dalındaki değişiklikleri geliştirin veya isteğe göre seçin.

CTS'deki değişikliklere katkıda bulunmak için Yamaların Gönderilmesi iş akışını izleyin. Değişikliğinizi uygun şekilde incelemek üzere bir incelemeci atanacaktır.

Yayın takvimi ve şube bilgileri

CTS sürümleri bu takvimi takip eder.

Yayın sırasındaki önemli tarihler

• İlk haftanın sonu: Kodun dondurulması. CTS'nin gelecek sürümü için kodun dondurulması dikkate alınana kadar dalda birleştirilen değişiklikler. Kod dondurulduktan sonra veya sürüme aday belirlendikten sonra şubeye yapılan başvurular bir sonraki sürüm için değerlendirmeye alınır.
• İkinci veya üçüncü hafta: CTS, AOSP'de yayınlanır.

Otomatik birleştirme akışı

CTS geliştirme şubeleri, her şubeye iletilen değişikliklerin otomatik olarak bir üst şubelerle birleşmesi için yapılandırılmıştır.

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

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

Bir değişiklik listesi (CL) doğru bir şekilde birleştirilemezse, yamanın yazarına çakışmanın nasıl çözüleceğine ilişkin talimatların yer aldığı bir e-posta gönderilir. Çoğu durumda yamanın yazarı, çakışan CL'nin otomatik birleştirme işlemini atlamak için talimatları kullanabilir.

Daha eski bir dal değişikliği gerektiriyorsa yamanın yeni daldan isteğe göre seçilmesi gerekir.