CTS geliştirme

Depo istemcinizi başlatma

Aşağıdaki adımları uygulayarak Kaynağı İndirme'ye giderek ve Android kaynak kodunu oluşturalım. repo init komutunu verirken belirli bir CTS dalını kullanma: -b. Bu, CTS değişikliklerinizin dahil edilmesini sağlar sonraki CTS sürümlerinde yer alacak.

Aşağıdaki örnek kodda repo init özelliğinin 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 oluşturma ve çalıştırma

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

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

CTS konsolunda şunları girin:

tf> run cts --plan CTS

CTS testlerini yazma

talimatları

CTS testleri, JUnit ve Android test API'lerini kullanır. Şu göz atın: Test etme uygulamanızı eğiticiyi ve cts/tests dizini altındaki mevcut testleri içerir. CTS testleri çoğunlukla diğer Android testlerinde kullanılan kuralları uygular.

CTS birçok üretim cihazında çalışır, bu nedenle testlerin şu kuralları kabul edin:

  • Çeşitli ekran boyutlarını, yönleri ve klavye düzenlerini dikkate alın.
  • Yalnızca herkese açık API yöntemlerini kullanın. Başka bir deyişle, hide ek açıklamasıyla gösterilir.
  • Görünüm düzenleri kullanmaktan veya öğelerin, bazı öğelerde bulunmayan boyutlarına güvenmekten kaçının. cihazlar.
  • Kök ayrıcalıklarına güvenmeyin.

Java ek açıklaması ekle

Testiniz bir API davranışını doğrularsa test kodunuza @ApiTest ile ek açıklama ekleyin ve apis alanında yer alan tüm API'ler. Aşağıdakiler arasından uygun biçimi kullanın: şu örneklere bakabilirsiniz:

API türü Ek açıklama biçimi Notlar
Yöntem android.example.ClassA#methodA En yaygın kullanım alanıdır.
Anahtar/değer çiftleri yöntemi android.example.ClassB#methodB(KeyA) Aşağıdaki gibi yalnızca testiniz bir alanı doğrulamak için API yöntemi kullandığında kullanın: inceleyin.
Alan android.örnek.SınıfC#AlanA Aşağıdaki gibi yalnızca testiniz bir API alanını doğrudan doğruladığında kullanın inceleyin.

Testiniz bir CDD gereksinimini doğruluyorsa gereksinim kimliğini (CDD bölümü dahil) ekleyin (Kimlik ve Gereksinim Kimliği) aşağıda gösterildiği şekilde, CTS test kodunda @CddTest örneği inceleyelim. Taahhüt mesajınızda, bağlı olduğunuz CDD'nin hangi CDD koşulunun karşılandığını belirtin test etmek için CDD şart kimliklerine bakarak test etmeyi unutmayın. CDD gereksinim kimlikleri, bölüm kimliğinin bir kombinasyonudur ve gereksinim kimliği (7.3.1/C-1-1'de olduğu gibi eğik çizgi (/) ile bağlanmıştı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 etiketinizdeki her Etkinlik için ilgili CDD kimliği. Değer alanlarına ilişkin biçimler, CTS Taahhüt mesajında, CDD'ye referans vererek hangi CDD koşulunun uygulandığını belirtin gereklilik kimliği. 


  <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 alakalı bağlantılar ekleyin. CTS-D için testlerinin bir parçası olarak Google Sorun İzleyici'de oluşturduğunuz test teklifinin bağlantısını CTS-D gönderim sürecini takip edin.

Alt plan oluşturun

Örneğin, panele bir SubPlan.xml dosyası ekleyebilirsiniz. android-cts/subplans şöyle:

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

Adlandırmayı ve konumu test edin

Çoğu CTS test durumu, Android API'deki belirli bir sınıfı hedefler. Bu testler cts son ekine sahip Java paketi adlarına ve Test son eki. Her test durumu birden çok testten oluşur. Testlerin her biri testi genellikle test edilen sınıfın belirli bir yöntemini uygular. Bu testler, testlerin gruplandığı bir dizin yapısı halinde düzenlenir. "widget'lar" gibi farklı kategorileri veya "görüntüleme sayısı" gibi.

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

  • Java paketi adı
    CTS testleri için Java paketi adı testin test ettiği sınıfın paket adıdır ve ardından .cts. Örneğimizde paket adı android.widget.cts
  • Sınıf adı
    CTS testlerinin sınıf adı "Test" ile test edilen sınıfın adı eklendi. Örneğin, Örneğin, bir test TextView hedefini hedefliyorsa, sınıf adı şöyle olmalıdır: TextViewTest.
  • 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 ( örnek, widget).

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

CTS s1

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

CTS v1 testlerindeki dizin yapısı aşağıdaki gibi görünür: 

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 2 sürümünü kullanın. Ayrıntılar için bkz. Android Açık Kaynak Projesi'nde (AOSP) örnek test.

CTS v2 dizin yapısı aşağıdaki gibi görünür: 

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

Yeni örnek paketler

Yeni testler eklerken, testi. Bu tür durumlarda, dizini oluşturmanız ve örnek dosyalar oluşturun.

CTS s1

CTS v1 kullanıyorsanız cts/tests/tests/example sayfasına giderek yeni bir dizin oluşturun. Ayrıca, Android.mk bölümünden yeni paketinizin modül adını eklediğinizden emin olun - CTS_COVERAGE_TEST_CASE_LIST inç cts/CtsTestCaseList.mk. build/core/tasks/cts.mk bu oluşturma dosyasını kullanır tüm testleri birleştirmek ve son CTS paketini oluşturmaktır.

CTS v2

Örnek testi kullanma /cts/tests/sample/ yeni test modülünüzü aşağıdaki adımları uygulayarak hızlıca başlatın:

  1. Test dizinini oluşturmak ve örnek dosyaları kopyalamak için şu komutu ç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 örneklerini değiştirin "[Ss]bol" şununla: Yukarıdaki önerilen adlandırma kuralını inceleyin.
  3. Test ettiğiniz özelliği kullanmak için SampleDeviceActivity uygulamasını güncelleyin.
  4. Etkinliğin başarılı olduğundan veya günlüğe kaydedildiğinden emin olmak için SampleDeviceTest uygulamasını güncelleyin emin olun.

Ek dizinler

assets, jni, gibi diğer Android dizinleri libs ve res de eklenebilir. JNI kodu eklemek için yerel dizin içeren src öğesinin yanında, projenin kök dizininde bir dizin oluşturun bir Android.mk setfile'ı yer alır.

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, Android.mk dosyasını projesindeki adımları uygulayın:

# 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, test amaçlı veya BrokenTest veya KnownFailure ile açıklama eklenen testleri kaldırın.

Değişikliklerinizi gönderin

AOSP'de CTS veya VTS yamaları gönderirken geliştirme dalınızı seçin düzeylerine göre değiştirilir.

  • Birden fazla API düzeyinde geçerli olan değişiklikler için önce aosp/main içinde bir yama geliştirin ve en uygun yukarı akış test dalını kullanabilirsiniz. Otomatik birleştiricinin, aşağı akıştaki değişiklikleri birleştirmesine izin ver: AOSP test dalları. Ş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 seviyesine özgü değişiklikler için, kendiniz geliştirin veya seçiminizi yapın doğru test dalını değiştirmek için DO NOTBirleştir veya RESTRICT OTOMATİK'i belirten bir değer girin.

Yama gönderme iş akışını uygulayın destekleyici materyalleri inceleyeceksiniz. Değişikliğinizi incelemek üzere bir inceleme uzmanı atanır.

Yayın planı ve şube bilgileri

CTS yayınları bu programı takip eder.

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

Yayın sırasındaki önemli tarihler

  • İlk haftanın sonu: Kod donar. Değişiklikler dalda birleştirildi kullanıma sunulması planlanıyor. Kod dondurulduktan sonra veya bir program için aday olduktan sonra şubeye yapılan gönderimler sonraki yayın için dikkate alınır.
  • İkinci veya üçüncü hafta: CTS şurada yayınlanır: AOSP.

Otomatik birleştirme akışı

CTS geliştirme dalları oluşturuldu. Böylece, dal otomatik olarak daha yüksek dallara birleştirilir.

Doğrudan bir AOSP test geliştirme dalında yapılan değişiklikler için otomatik birleştirme yolu şu şekildedir:
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 şu şekildedir:
aosp-main <Internal git_main>.

Değişiklik listesi (CL) düzgün şekilde birleştirilemezse yamanın yazarı gönderilir çakışmanın nasıl çözüleceğine ilişkin talimatları içeren bir e-posta. Bölgenizin durumlarda, yamanın yazarı, çakışan CL.

Eski bir dal için değişiklik gerekiyorsa yamanın özenle seçilmiştir.