CTS 개발

Repo 클라이언트 초기화

소스 다운로드에 따라 Android 소스 코드를 가져와 빌드합니다. 단 repo init 명령어를 실행할 때 특정 CTS 브랜치 이름(예: -b android-5.0_r2)을 지정합니다. 이렇게 하면 CTS 변경사항이 이후 CTS 버전에 포함됩니다.

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' 주석이 달린 클래스, 메서드, 필드는 사용하지 마세요.
  • 뷰 레이아웃을 사용하지 말고 일부 기기에 없을 수도 있는 애셋 크기에 의존하지 마세요.
  • 루트 권한에 의존하지 않습니다.

테스트 이름 지정 및 위치

대부분의 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 1을 사용 중인지 또는 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를 사용합니다. 자세한 내용은 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.mkCTS_COVERAGE_TEST_CASE_LIST에 추가해야 합니다. 이 makefile은 build/core/tasks/cts.mk에서 모든 테스트를 결합하여 최종 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 수준에 적용되는 변경사항의 경우 CL은 먼저 aosp/master로 개발한 후 선별하여 최고의 업스트림 테스트 브랜치를 선택해야 합니다. 자동 병합 기능으로 AOSP 테스트 브랜치의 다운스트림 변경사항을 병합하도록 허용하세요. 브랜치 목록 및 경로 정보 자동 병합에 관해서는 출시 일정 및 브랜치 정보를 참조하세요.
  • 특정 API 수준에만 해당하는 변경사항의 경우 커밋 메시지에서 병합하지 않음 또는 자동 병합 제한을 선택하여 변경사항을 해당하는 테스트 브랜치로 개발하거나 CP하세요.

패치 제출 워크플로에 따라 CTS에 변경사항을 적용합니다. 검토자가 변경사항에 할당되어 곧 그 내용을 검토합니다.

출시 일정 및 브랜치 정보

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

버전 브랜치 빈도
10 android10-tests-dev 매분기
9 pie-cts-dev 매분기
8.1 oreo-mr1-cts-dev 매분기
8.0 oreo-cts-dev 매분기
7.1 nougat-mr1-cts-dev 매분기
7.0 nougat-cts-dev 매분기
6.0, 5.1, 5.0, 4.4, 4.3, 4.2는 출시 계획이 없습니다.

출시 중 중요 날짜

  • 첫 번째 주말: 코드 동결. 코드 동결 시점까지 브랜치에 제출된 코드는 곧 출시될 CTS 버전에서 고려됩니다. 코드 동결 후 또는 출시 후보가 선택된 후 브랜치에 제출된 코드는 후속 출시에서 고려됩니다.
  • 두 번째 또는 세 번째 주: CTS가 Android 오픈소스 프로젝트(AOSP)에 게시됩니다.

자동 병합 워크플로

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

향후 출시될 Android 버전의 변경사항에 사용될 자동 병합 경로는 다음과 같습니다.
aosp/master > <private-development-branch for Android R>

AOSP 브랜치의 직접 변경사항에 사용될 자동 병합 경로는 다음과 같습니다.
nougat-cts-dev > nougat-mr1-cts-dev > oreo-cts-dev > oreo-mr1-cts-dev > pie-cts-dev > android10-tests-dev

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

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