CTS 개발

Repo 클라이언트 초기화

소스 다운로드의 안내에 따라 Android 소스 코드를 가져온 후 빌드합니다. repo init 명령어를 실행할 때 -b를 사용하여 특정 CTS 브랜치를 지정합니다. 이렇게 하면 CTS 변경사항이 CTS 후속 버전에 포함됩니다.

다음 코드 예에서는 repo init를 사용하는 방법을 보여줍니다.

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 빌드 및 실행

다음 명령어를 실행하여 CTS를 빌드하고 양방향 CTS 콘솔을 시작합니다.

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

CTS 콘솔에서 다음을 입력합니다.

tf> run cts --plan CTS

CTS 테스트 작성

CTS 테스트는 JUnit 및 Android 테스트 API를 사용합니다. cts/tests 디렉터리에서 앱 테스트 튜토리얼 및 기존 테스트를 검토합니다. CTS 테스트 규칙은 다른 Android 테스트에서 따르는 규칙과 대체로 동일합니다.

CTS는 여러 프로덕션 기기에서 실행되므로 테스트 시 다음 규칙을 따라야 합니다.

  • 다양한 화면 크기, 방향 및 키보드 레이아웃을 고려해야 합니다.
  • 공개 API 메서드만 사용합니다. 즉, hide 주석이 달린 클래스, 메서드, 필드는 모두 사용하지 않습니다.
  • 뷰 레이아웃을 사용하지 말고 일부 기기에 없을 수도 있는 애셋 크기에 의존하지 않습니다.
  • 루트 권한에 의존하지 않습니다.

자바 주석 추가

테스트에서 API 동작이 확인되면 테스트 코드에 @ApiTest 주석을 추가하고 apis 필드와 관련된 모든 API를 나열합니다. 다음 예 중에서 적절한 형식을 사용하세요.

API 유형 주석 형식 메모
메서드 android.example.ClassA#methodA 가장 일반적인 사용 사례입니다.
키 값이 있는 메서드 android.example.ClassB#methodB(KeyA) 이 예와 같이 테스트에서 API 메서드를 사용하여 필드를 검증할 때만 사용합니다.
필드 android.example.ClassC#FieldA 이 예와 같이 테스트에서 API 필드를 직접 검증하는 경우에만 사용합니다.

테스트에서 CDD 요구사항이 확인되면 다음 예와 같이 CTS 테스트 코드의 @CddTest 주석을 요구사항 ID(CDD 섹션 ID 및 요구사항 ID 포함)에 추가합니다. 커밋 메시지에서 CDD 요구사항 ID를 참조하여 테스트에서 어떤 CDD 요구사항을 테스트하는지 언급합니다. CDD 요구사항 ID는 섹션 ID와 요구사항 ID의 조합이며 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()));
    }

CTS 인증 도구의 경우 AndroidManifest.xml의 각 활동에 관련 CDD ID를 주석으로 추가합니다. 값 필드의 형식은 CTS의 자바 주석 형식과 유사합니다. 커밋 메시지에서 CDD 요구사항 ID를 참조하여 어떤 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>

커밋 메시지에서

테스트를 추가해야 하는 이유를 명확하게 설명하고 지원을 위한 관련 링크를 추가합니다. CTS-D 테스트의 경우 CTS-D 제출 프로세스의 일환으로 Google Issue Tracker에서 만든 테스트 제안서 링크를 포함하세요.

하위 계획 만들기

예를 들어 다음과 같이 android-cts/subplans에 SubPlan.xml 파일을 추가할 수 있습니다.

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

하위 계획을 실행하려면 다음 안내를 따르세요.

run cts --subplan aSubPlan

하위 계획 항목 형식은 다음과 같습니다.

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

테스트 이름 지정 및 위치

대부분의 CTS 테스트 사례는 Android API의 특정 클래스를 타겟팅합니다. 이러한 테스트는 접미사가 cts인 자바 패키지 이름과 접미사가 Test인 클래스 이름을 가집니다. 각 테스트 사례는 여러 테스트로 구성되며 각 테스트는 일반적으로 테스트 중인 클래스의 특정 메서드를 실행합니다. 이러한 테스트는 테스트가 여러 카테고리(예: '위젯' 또는 '뷰')로 구분되는 디렉터리 구조로 배열됩니다.

예를 들어 자바 패키지 android.widget.TextView의 CTS 테스트는 android.widget.cts.TextViewTest이고 테스트의 자바 패키지 이름은 android.widget.cts이며 클래스 이름은 TextViewTest입니다.

  • 자바 패키지 이름
    CTS 테스트의 자바 패키지 이름은 테스트하는 클래스의 패키지 이름이고 그 뒤에 .cts가 추가됩니다. 이 예에서 패키지 이름은 android.widget.cts입니다.
  • 클래스 이름
    CTS 테스트의 클래스 이름은 테스트하는 클래스의 이름에 'Test'를 붙입니다. 예를 들어 테스트가 TextView를 타겟팅하는 경우 클래스 이름은 TextViewTest입니다.
  • 모듈 이름(CTS v2만)
    CTS v2는 모듈별로 테스트를 구성합니다. 모듈 이름은 일반적으로 자바 패키지 이름의 두 번째 문자열(이 예에서는 widget)입니다.

디렉터리 구조와 샘플 코드는 CTS v1을 사용 중인지 또는 CTS v2를 사용 중인지에 따라 달라집니다.

CTS v1

Android 6.0 이하에서는 CTS v1을 사용합니다. CTS v1의 경우 샘플 코드는 cts/tests/tests/example에 있습니다.

CTS v1 테스트의 디렉터리 구조는 다음과 같습니다. 

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

CTS v2

Android 7.0 이상에서는 CTS v2를 사용합니다. 자세한 내용은 Android 오픈소스 프로젝트(AOSP)의 샘플 테스트를 참고하세요.

CTS v2 디렉터리 구조는 다음과 같습니다. 

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

새 샘플 패키지

새 테스트를 추가할 때 테스트를 추가할 기존 디렉터리가 없을 수도 있습니다. 이러한 경우 디렉터리를 만들고 적절한 샘플 파일을 복사해야 합니다.

CTS v1

CTS v1을 사용 중이라면 cts/tests/tests/example 아래의 예를 참조하여 새 디렉터리를 만드세요. 또한 Android.mk의 새 패키지 모듈 이름을 cts/CtsTestCaseList.mk의 CTS_COVERAGE_TEST_CASE_LIST에 추가해야 합니다. build/core/tasks/cts.mk는 이 makefile을 사용하여 모든 테스트를 결합하고 최종 CTS 패키지를 생성합니다.

CTS v2

샘플 테스트 /cts/tests/sample/ 을 사용하여 다음 단계에 따라 새 테스트 모듈을 빠르게 시작하세요.

  1. 테스트 디렉터리를 만들고 샘플 파일을 복사하려면 다음을 실행합니다. 
    mkdir cts/tests/module-name && cp -r cts/tests/sample/* cts/tests/module-name
  2. cts/tests/module-name으로 이동하고 위에서 권장하는 이름 지정 규칙에 따라 '[Ss]ample'의 모든 인스턴스를 대체합니다.
  3. SampleDeviceActivity를 업데이트하여 테스트 중인 기능을 실행합니다.
  4. SampleDeviceTest를 업데이트하여 활동이 실행되거나 오류가 로깅되도록 합니다.

추가 디렉터리

다른 Android 디렉터리(assets, jni, libs, res)도 추가될 수 있습니다. JNI 코드를 추가하려면 네이티브 코드를 사용하여 src 옆의 프로젝트 루트에 디렉터리를 만들고 그 안에 Android.mk makefile을 만드세요.

makefile에는 일반적으로 다음 설정이 포함됩니다. 

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

마지막으로 프로젝트의 루트에 있는 Android.mk 파일을 다음과 같이 수정하여 네이티브 코드를 빌드하고 사용합니다.

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

테스트 수정 또는 삭제

새로운 테스트를 추가하는 것 외에 BrokenTest 또는 KnownFailure 주석이 달린 테스트를 수정하거나 삭제할 수 있습니다.

변경사항 제출

AOSP에 CTS나 VTS 패치를 제출할 때 패치가 적용되는 API 수준에 따라 개발 브랜치를 선택합니다.

  • 여러 API 수준에 적용되는 변경사항의 경우 먼저 aosp/main에 패치를 개발한 다음 가장 상위의 업스트림 테스트 브랜치를 선택합니다. 자동 병합 기능으로 AOSP 테스트 브랜치의 다운스트림 변경사항을 병합하도록 허용하세요. 브랜치 목록 및 경로 정보 자동 병합에 관해서는 출시 일정 및 브랜치 정보를 참고하세요.
  • 특정 API 수준에만 해당하는 변경사항의 경우 커밋 메시지에 DO NOT MERGE(병합하지 않음) 또는 RESTRICT AUTOMERGE(자동 병합 제한)를 사용하여 변경사항을 올바른 테스트 브랜치로 개발하거나 선택하세요.

패치 제출 워크플로에 따라 CTS에 변경사항을 적용합니다. 변경사항을 검토할 수 있도록 검토자가 할당됩니다.

출시 일정 및 브랜치 정보

CTS는 다음 일정에 따라 출시됩니다.

버전 API 수준 브랜치 주파수
14 34 android14-tests-dev 분기별
13 33 android13-tests-dev 분기별
12L 32 android12L-tests-dev 분기별
12 31 android12-tests-dev 분기별
11 30 android11-tests-dev 분기별
버전 10.0, 9.0, 8.1, 8.0, 7.1, 7.0, 6.0, 5.1, 5.0, 4.4, 4.3, 4.2는 더 이상 출시되지 않습니다.

출시 중 중요 날짜

  • 첫 번째 주말: 코드 동결. 코드 동결까지 브랜치에 병합된 변경사항은 다음 CTS 버전에서 고려됩니다. 코드 동결 후 또는 출시 후보가 선택된 후 브랜치에 제출된 코드는 후속 출시에서 고려됩니다.
  • 두 번째 또는 세 번째 주: CTS가 AOSP에 게시됩니다.

자동 병합 워크플로

각 브랜치에 제출된 변경사항이 자동으로 상위 브랜치와 병합되도록 CTS 개발 브랜치가 설정되었습니다.

AOSP 테스트 개발 브랜치의 직접적인 변경사항에 사용될 자동 병합 경로는 다음과 같습니다.
android11-tests-dev > android12-tests-dev > android12L-tests-dev > android13-tests-dev > android14-tests-dev > aosp/main

다음 Android 버전에만 적용되는 변경사항의 자동 병합 경로는 다음과 같습니다.
aosp/main > <Internal git/main>.

변경 목록(CL)이 제대로 병합되지 않으면 패치 작성자에게 충돌 해결 방법에 관한 안내가 포함된 이메일이 전송됩니다. 대부분의 경우 패치 작성자는 이 안내에 따라 충돌하는 CL의 자동 병합을 건너뛸 수 있습니다.

또한, 이전 브랜치를 변경해야 하는 경우 최신 브랜치에서 패치를 선별해야 합니다.