테스트 스위트
테스트가 VTS의 일부가 되려면 Android.bp 에 다음 설정이 있어야 합니다.
test_suites: ["vts"],
또한 general-tests 제품군에 테스트를 추가하면 사전 제출 확인에 사용되는 테스트 매핑 제품군의 일부가 될 수 있습니다.
테스트 구성
대부분의 경우 VTS 테스트를 실행하기 위해 Trade Federation에서 사용하는 XML 파일인 테스트 구성은 빌드 중에 자동으로 생성됩니다. 그러나 테스트 구성을 사용자 정의할 수 있습니다.
사용자 지정 테스트 구성 파일 만들기
처음부터 새 테스트 XML 파일을 만드는 것은 테스트 도구의 작동 방식과 각 테스트 실행기 간의 차이점을 이해하지 못하기 때문에 복잡할 수 있습니다. 자동 생성된 테스트 구성 파일은 이 프로세스를 더 쉽게 만들도록 설계되었습니다.
테스트 XML 파일을 사용자 지정해야 하는 경우 자동 생성된 파일을 시작점으로 사용할 수 있습니다.
자동 생성된 테스트 구성 파일을 찾으려면 먼저 아래와 같이 make 명령을 실행하여 구성을 빌드합니다.
$ m VtsHalUsbV1_1TargetTest
빌드 아웃 디렉터리에서 아래와 같이 모듈 이름을 기반으로 구성 파일을 검색할 수 있습니다.
$ find out/ -name VtsHalUsbV1_1TargetTest.config
파일 사본이 여러 개 있을 수 있으며 그 중 아무거나 사용할 수 있습니다. .config 파일을 Android.bp 파일이 있는 디렉터리에 복사합니다.
Android.bp 파일에 테스트 모듈이 하나만 있는 경우 XML 파일의 이름을 AndroidTest.xml 로 바꿀 수 있으며 빌드 시스템은 자동으로 이를 테스트 모듈의 구성 파일로 사용합니다. 그렇지 않으면 아래 예와 같이 모듈에 test_config 특성을 추가합니다.
test_config: "VtsHalUsbV1_1TargetTest.xml",
이제 작업하고 사용자 지정을 구현할 테스트 구성 파일이 있습니다.
테스트를 adb 루트로 강제 실행
대부분의 VTS 테스트를 실행하려면 루트 권한이 필요합니다. 테스트 구성 파일이 자동 생성되면 Android.bp 에 다음 속성을 추가할 수 있습니다.
require_root: true,
테스트 구성 파일이 사용자 정의된 경우 테스트 XML 파일에 다음을 추가하십시오.
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
테스트 중 프레임워크 중지
많은 VTS 테스트는 Android 프레임워크를 실행할 필요가 없으며 프레임워크를 중지한 상태에서 테스트를 실행하면 디바이스 플레이크의 영향을 받지 않고 안정적으로 테스트를 실행할 수 있습니다. 테스트 구성 파일이 자동 생성되면 Android.bp 에 다음 속성을 추가할 수 있습니다.
disable_framework: true,
테스트 구성 파일이 사용자 정의된 경우 테스트 XML 파일에 다음을 추가하십시오.
<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>
추가 테스트 인수 추가
일부 gtest 테스트는 실행하는 데 더 많은 시간이 필요할 수 있습니다. 이러한 경우 XML 파일에 테스트 실행기 옵션을 추가할 수 있습니다.
예를 들어 다음 항목의 native-test-timeout 설정을 사용하면 기본값인 1분이 아닌 3분의 제한 시간으로 테스트를 실행할 수 있습니다.
<test class="com.android.tradefed.testtype.GTest" >
<option name="native-test-device-path" value="/data/local/tmp" />
<option name="module-name" value="VtsHalNfcV1_0TargetTest" />
<option name="native-test-timeout" value="180000"/>
</test>
최소 API 레벨 필요
일부 VTS 테스트는 API 수준이 최소인 기기에서만 실행할 수 있습니다. 테스트 구성 파일이 자동 생성되면 Android.bp 에 다음 속성을 추가할 수 있습니다.
test_min_api_level: 29,
테스트 구성 파일이 사용자 정의된 경우 테스트 XML 파일에 다음 명령을 추가하십시오.
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.MinApiLevelModuleController">
<option name="min-api-level" value="29" />
</object>
Android 12는 ro.board.first_api_level 및 ro.board.api_level 속성을 정의하여 이러한 기기에서 공급업체 이미지의 API 수준을 표시합니다. 이러한 속성을 ro.product.first_api_level 과 결합하여 테스트 도구 모음은 장치에 적합한 테스트 사례를 선택합니다.
Android 13은 ro.product.first_api_level , ro.board.first_api_level 및 ro.board.api_level 속성을 사용하여 필요한 공급업체 API 수준을 계산하여 자동으로 설정되는 ro.vendor.api_level 을 정의합니다.
ro.board.first_api_level
ro.board.first_api_level 속성은 이 속성과 함께 SoC의 공급업체 이미지가 처음 출시될 때의 API 수준입니다. 이는 기기의 시작 API 수준에 의존하지 않고 이 값을 정의하는 SoC의 첫 번째 API 수준에만 의존합니다. 이 값은 SoC의 수명 동안 영구적입니다.
ro.board.first_api_level 설정하기 위해 장치 제조업체는 다음 예와 같이 device.mk 파일에서 BOARD_SHIPPING_API_LEVEL 정의할 수 있습니다.
# BOARD_SHIPPING_API_LEVEL sets ro.product.first_api_level to indicate
# the first api level that the device has been commercially launched on.
BOARD_SHIPPING_API_LEVEL := 23
기기의 vendor/build.prop 에 대한 ro.board.first_api_level 속성을 자동으로 정의합니다. 이 속성은 공급업체 init 프로세스에서 설정합니다.
ro.board.api_level
ro.board.api_level 속성은 SoC에 대한 공급업체 이미지의 현재 API 수준입니다. ro.board.first_api_level 이 있는 벤더 이미지의 API 레벨이 업데이트되면 SoC를 사용하는 기기는 ro.board.first_api_level을 업데이트 ro.board.first_api_level 대신 벤더 이미지의 현재 API 레벨로 ro.board.api_level 속성을 정의해야 합니다. . 이 속성을 설정하지 않으면 기본적으로 ro.board.first_api_level 사용됩니다.
ro.board.api_level 설정하려면 원하는 값으로 device.mk 파일에 BOARD_API_LEVEL 정의합니다.
ro.vendor.api_level
공급업체 이미지가 지원해야 하는 API 수준을 표시하기 위해 ro.vendor.api_level 속성이 Android 13에 도입되었습니다. 자동으로 최소값인 ro.board.api_level (또는 ro.board.first_api_level 정의되지 않은 경우 ro.board.api_level ) 및 ro.product.first_api_level 로 설정됩니다. 공급업체 이미지 업그레이드가 필요한 공급업체 구현 테스트는 이 속성을 참조하여 SoC에 대한 공급업체 요구 사항에서 제외될 수 있습니다.
VTS를 사용한 샤딩 프로세스
Android 버전 10 이상의 경우 아래 지침에 따라 VTS 및 CTS-on-GSI 계획으로 테스트하는 동안 여러 기기에서 샤딩 프로세스를 수행할 수 있습니다.
run vts --shard-count <number of devices> -s <device serial> ...
이 명령은 VTS 계획을 샤드로 분할하고 여러 장치에서 실행합니다.
run cts-on-gsi --shard-count <number of devices> -s <device serial> -s ...
이 명령어는 CTS-on-GSI 계획을 샤드로 분할하고 여러 기기에서 실행합니다.