2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main 대신 android-latest-release를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
HAL 테스트 가능성 확인
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
Android 9 공급업체 테스트 모음(VTS)은 기기 설정을 사용하여 기기 타겟에서 건너뛰어야 하는 VTS 테스트를 식별하는 런타임 메서드를 지원합니다.
VTS 테스트 유연성
Android 8.0부터는 Android 8.0 이상으로 실행되는 모든 기기에 VTS 테스트가 필수입니다. 그러나 모든 VTS 테스트가 모든 기기 타겟에 적용되는 것은 아닙니다. 예:
- 특정 기기가 테스트 HAL(예: IR)을 지원하지 않는 경우 VTS는 기기 타겟에서 HAL 테스트를 위한 테스트를 실행할 필요가 없습니다.
- 몇몇 기기에서 동일한 SoC와 공급업체 이미지를 공유하지만 하드웨어 기능이 다른 경우, VTS는 특정 기기 타겟에서 테스트를 실행해야 하는지 아니면 건너뛰어야 하는지 결정해야 합니다.
VTS 테스트 유형
VTS에는 다음과 같은 테스트 유형이 있습니다.
- 규정 준수 테스트는 프레임워크와 공급업체 파티션 간의 호환성을 보장합니다. 이러한 테스트는 Android 8.0 이상을 실행하는 기기에서 실행(및 통과)해야 합니다.
- 비규정 준수 테스트는 공급업체가 제품 품질(성능/퍼징 등)을 개선하는 데 도움이 됩니다. 공급업체의 경우 이 테스트는 선택사항입니다.
테스트가 규정 준수 테스트인지 여부는 테스트가 속한 계획에 따라 다릅니다. VTS 계획으로 실행되는 테스트는 규정 준수 테스트로 간주됩니다.
지원되는 HAL 확인
VTS는 다음 파일을 사용하여 기기 타겟이 특정 HAL을 지원하는지 확인할 수 있습니다.
/system/compatibility_matrix.xml. 프레임워크에 필요한 HAL 인스턴스를 요청합니다. 예:
<hal format="hidl" optional="true">
<name>android.hardware.vibrator</name>
<version>1.0-1</version>
<interface>
<name>IVibrator</name>
<instance>default</instance>
</interface>
</hal>
optional 속성은 프레임워크에서 HAL을 엄격하게 요구하는지 나타냅니다.- 파일에는 이름은 같지만 버전과 인터페이스가 서로 다른 동일한 HAL에 관한 여러 개의 항목이 있을 수 있습니다.
- 파일에 동일한 항목의
version 구성이 여러 개 있을 수 있습니다. 이는 프레임워크가 여러 버전과 작동할 수 있음을 나타냅니다.
version1.0-1은 프레임워크가 가장 낮은 버전 1.0과 작동할 수 있으며 1.1보다 높은 버전이 필요하지 않음을 의미합니다.
- 기기
manifest.xml. 공급업체에서 제공한 HAL 인스턴스를 요청합니다. 예:
<hal format="hidl">
<name>android.hardware.vibrator</name>
<transport>hwbinder</transport>
<version>1.2</version>
<interface>
<name>IVibrator</name>
<instance>default</instance>
</interface>
</hal>
- 파일에는 이름은 같지만 버전과 인터페이스가 서로 다른 동일한 HAL에 관한 여러 개의 항목이 있을 수 있습니다.
- 파일에 항목의 단일
version 구성만 포함된 경우 version1.2는 공급업체에서 1.0~1.2의 모든 버전을 지원한다는 의미입니다.
- lshal. 기기상의 도구로,
hwservicemanager로 등록된 HAL 서비스의 런타임 정보를 표시합니다. 예:
android.hardware.vibrator@1.0::IVibrator/default
lshal은 또한 패스 스루 구현이 있는 모든 HAL을 표시합니다. 즉, 해당하는 -impl.so 파일이 기기에 있는 HAL입니다. 예:
android.hardware.nfc@1.0::I*/* (/vendor/lib/hw/)
android.hardware.nfc@1.0::I*/* (/vendor/lib64/hw/)
규정 준수 테스트
규정 준수 테스트의 경우 VTS는 기기에서 제공된 모든 HAL 인스턴스를 확인하고 테스트하는 데 공급업체 매니페스트를 사용합니다. 결정 흐름:
그림 1. VTS 규정 준수 테스트의 테스트 가능성 확인
비규정 준수 테스트
규정을 준수하지 않는 테스트의 경우 VTS는 manifest.xml 파일에서 요청하지 않은 실험용 HAL을 확인하고 테스트하는 데 공급업체 매니페스트와 lshal 출력을 사용합니다. 결정 흐름:
그림 2. VTS 비규정 준수 테스트의 테스트 가능성 확인
공급업체 매니페스트 찾기
VTS는 다음 위치에 있는 공급업체 manifest.xml 파일을 아래 순서대로 확인합니다.
/vendor/etc/vintf/manifest.xml + ODM 매니페스트(동일한 HAL이 두 위치에 모두 정의되어 있는 경우 ODM 매니페스트가 /vendor/etc/vintf/manifest.xml에 있는 매니페스트보다 우선함)/vendor/etc/vintf/manifest.xml- ODM
manifest.xml 파일(다음 파일에서 아래 순서대로 로드됨)/odm/etc/vintf/manifest_$(ro.boot.product.hardware.sku).xml
/odm/etc/vintf/manifest.xml/odm/etc/manifest_$(ro.boot.product.hardware.sku).xml/odm/etc/manifest.xml/vendor/manifest.xml
VTS 테스트 가능성 검사기
vts_testibility_checker는 VTS로 패키징된 바이너리로, 지정된 HAL 테스트가 테스트 가능 상태인지 확인하기 위해 런타임 시 VTS 테스트 프레임워크에서 사용합니다. 이 검사기는 libvintf에 기반하여 공급업체 매니페스트 파일을 로드하고 파싱하며, 이전 섹션에서 설명한 결정 흐름을 구현합니다.
vts_testability_check 앱을 사용하려면 다음 안내를 따르세요
vts_testability_check의 출력에는 다음과 같은 JSON 형식이 사용됩니다.
{testable: <True/False> Instances: <list of instance names of HAL service>}
액세스된 HAL 확인
VTS 테스트에서 액세스한 HAL을 확인하려면 각 HAL 테스트에서 VtsHalHidlTargetTestEnvBase 템플릿을 사용하여 테스트에서 액세스된 HAL을 등록해야 합니다. 그러면 VTS 테스트 프레임워크가 테스트를 사전 처리할 때 등록된 HAL을 추출할 수 있습니다.
규정 준수 테스트의 경우 /system/etc/vintf/manifest.xml을 확인해도 됩니다. 여기에 HAL이 정의되어 있으면 VTS는 HAL을 테스트해야 합니다. 시스템에서 제공된 HAL 서비스(예: graphics.composer/vr)의 경우 HAL은 /system/manifest.xml에 선언됩니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2024-05-07(UTC)
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2024-05-07(UTC)"],[],[],null,["# HAL testability check\n\nThe Android 9 Vendor Test Suite (VTS) supports a\nruntime method for using the device configuration to identify which VTS tests\nshould be skipped for that device target.\n\n### VTS test flexibility\n\n\nAs of Android 8.0, VTS tests are required for all devices launched with\nAndroid 8.0 and higher. However, not all VTS tests apply to all device\ntargets. For example:\n\n- If a specific device does not support a testing HAL (e.g. IR), VTS does not need to run tests for that HAL test against that device target.\n- If several devices share the same SoC and vendor image but have different hardware functionalities, VTS must determine whether a test should be run or be skipped for a specific device target.\n\n### VTS test types\n\n\nVTS includes the following test types:\n\n- **Compliance** tests ensure compatibility between framework and vendor partitions. These tests are required to be run (and pass) on devices launching with Android 8.0 or higher.\n- **Noncompliance** tests help vendors to improve product quality (performance/fuzzing etc.). These tests are optional for vendors.\n\n\nWhether a test is a compliance test or not depends on which plan it belongs\nto. Tests that run with\n[VTS plan](https://android.googlesource.com/platform/test/vts/+/android16-release/tools/vts-tradefed/res/config/vts.xml) are considered compliance tests.\n\nDetermine supported HALs\n------------------------\n\n\nVTS can use the following files to determine if the device target supports a\nspecific HAL:\n\n- `/system/compatibility_matrix.xml`. Claims the HAL instances required by the framework. Example: \n\n ```text\n \u003chal format=\"hidl\" optional=\"true\"\u003e\n \u003cname\u003eandroid.hardware.vibrator\u003c/name\u003e\n \u003cversion\u003e1.0-1\u003c/version\u003e\n \u003cinterface\u003e\n \u003cname\u003eIVibrator\u003c/name\u003e\n \u003cinstance\u003edefault\u003c/instance\u003e\n \u003c/interface\u003e\n \u003c/hal\u003e\n ```\n - The `optional` attribute indicates if the HAL is strictly required by the framework.\n - The file may contain multiple entries for the same HAL (with same name) but with different version and interfaces.\n - The file may contain multiple `version` configurations for the same entry, indicating the framework can work with different versions.\n - `version1.0-1` means the framework can work with the lowest version 1.0, and does not require a version higher than 1.1.\n- Device `manifest.xml`. Claims the HAL instances provided by the vendor. Example: \n\n ```text\n \u003chal format=\"hidl\"\u003e\n \u003cname\u003eandroid.hardware.vibrator\u003c/name\u003e\n \u003ctransport\u003ehwbinder\u003c/transport\u003e\n \u003cversion\u003e1.2\u003c/version\u003e\n \u003cinterface\u003e\n \u003cname\u003eIVibrator\u003c/name\u003e\n \u003cinstance\u003edefault\u003c/instance\u003e\n \u003c/interface\u003e\n \u003c/hal\u003e\n ```\n - The file may contain multiple entries for the same HAL (with same name) but with different version and interfaces.\n - If the file contains only a single `version` configuration for an entry, `version1.2` means the vendor supports all versions from 1.0\\~1.2.\n- **lshal** . A tool on device that shows runtime info about the HAL services registered with the `hwservicemanager`. Example: \n\n ```objective-c\n android.hardware.vibrator@1.0::IVibrator/default\n ```\n\n `lshal` also shows all the HALs that with passthrough implementations (i.e having the corresponding `-impl.so` file on the device). Example: \n\n ```objective-c\n android.hardware.nfc@1.0::I*/* (/vendor/lib/hw/)\n android.hardware.nfc@1.0::I*/* (/vendor/lib64/hw/)\n ```\n\nCompliance tests\n----------------\n\n\nFor compliance tests, VTS relies on the vendor manifest to determine (and\ntest) all HAL instances provided by the device. Decision flow:\n\n\n**Figure 1.** Testability check for VTS compliance tests\n\nNoncompliance tests\n-------------------\n\n\nFor noncompliance tests, VTS relies on the vendor manifest and\n`lshal` outputs to determine (and test) the experimental HALs not\nclaimed in the `manifest.xml` file. Decision flow:\n\n\n**Figure 2.** Testability check for VTS noncompliance tests\n\nLocate the vendor manifest\n--------------------------\n\n\nVTS checks for the vendor `manifest.xml` file in the following\nplaces in the following order:\n\n1. `/vendor/etc/vintf/manifest.xml` + ODM manifest (If same HAL is defined in both places, ODM manifest overrides the one in `/vendor/etc/vintf/manifest.xml`)\n2. `/vendor/etc/vintf/manifest.xml`\n3. ODM `manifest.xml` file, loaded from the following files in the following order:\n 1. `/odm/etc/vintf/manifest_$(ro.boot.product.hardware.sku).xml`\n 2. `/odm/etc/vintf/manifest.xml`\n 3. `/odm/etc/manifest_$(ro.boot.product.hardware.sku).xml`\n 4. `/odm/etc/manifest.xml`\n 5. `/vendor/manifest.xml`\n\nVTS testability checker\n-----------------------\n\n\nThe\n[vts_testibility_checker](https://android.googlesource.com/platform/test/vts/+/android16-release/utils/native/testability_checker/?q=vts_testability&g=0) is a binary packaged with VTS and used by\nVTS test framework at runtime to determine whether a given HAL test is\ntestable or not. It is based on\n[libvintf](https://android.googlesource.com/platform/system/libvintf/+/android16-release)\nto load and parse the vendor manifest file and implements the decision flow\ndescribed in the previous section.\n\n\nTo use `vts_testability_check`:\n\n- For a compliance test: \n\n ```transact-sql\n vts_testability_check -c -b \u003cbitness\u003e \u003chal@version\u003e\n ```\n- For a noncompliance test: \n\n ```transact-sql\n vts_testability_check -b \u003cbitness\u003e \u003chal@version\u003e\n ```\n\n\nThe output of `vts_testability_check` uses the following json\nformat: \n\n```text\n{testable: \u003cTrue/False\u003e Instances: \u003clist of instance names of HAL service\u003e}\n```\n\nDetermine accessed HALs\n-----------------------\n\n\nTo determine which HALs are accessed by VTS tests, ensure that each HAL test\nuses the\n[VtsHalHidlTargetTestEnvBase](https://android.googlesource.com/platform/test/vts/+/android16-release/runners/target/vts_hal_hidl_target/VtsHalHidlTargetTestEnvBase.h)\ntemplate to register the HAL(s) accessed in the test. The VTS testing\nframework can then extract the registered HALs when pre-processing the test.\n\n\nFor compliance tests, you can also check\n`/system/etc/vintf/manifest.xml`. If a HAL is defined here, VTS\nshould test it. (For the HAL services provided by the system (e.g.\n`graphics.composer/vr`), the HALs are declared in\n`/system/manifest.xml`.)"]]
