2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main 대신 android-latest-release를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
서비스 이름 인식 HAL 테스트
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
Android 9에는 VTS(공급업체 테스트 모음) 테스트가 실행되는 기기에 따라 지정된 HAL 인스턴스의 서비스 이름을 가져올 수 있는 지원 기능이 포함되어 있습니다. 서비스 이름을 인식하는 VTS HAL 테스트를 실행하면 개발자는 타겟과 호스트 측 VTS 테스트 실행 모두에서 공급업체 확장과 다중 HAL, 다중 HAL 인스턴스에 관한 테스트를 자동화할 수 있습니다.
서비스 이름 정보
실행 중인 HAL 서비스의 각 인스턴스는 자신을 서비스 이름으로 등록합니다.
이전 버전의 Android에서는 VTS HAL 테스트를 실행하는 개발자가 테스트 클라이언트의 올바른 서비스 이름을 getService()에 설정하거나 이름을 비워두고 기본 서비스 이름으로 대체해야 했습니다. 이러한 접근 방식의 단점은 다음과 같습니다.
- 올바른 서비스 이름을 설정할 때 테스트 개발자의 지식에 의존함
- 기본적으로 단일 서비스 인스턴스에 관한 테스트로 제한됨
- 서비스 이름을 수동으로 관리함(즉, 이름이 하드 코딩되므로 서비스 이름이 변경되면 이름을 수동 업데이트해야 함)
Android 9에서는 개발자가 테스트 중인 기기에 따라 지정된 HAL 인스턴스의 서비스 이름을 자동으로 가져올 수 있습니다.
이 접근 방식의 장점에는 다음 항목의 테스트가 지원된다는 점이 포함됩니다.
- 공급업체 HAL 확장. 예를 들어, 공급업체가 맞춤설정된 서비스 이름으로 공급업체 기기에서 실행되는 camera.provider HAL을 구현한 경우 VTS는 공급업체 인스턴스를 식별하고 이 인스턴스를 대상으로 테스트를 실행할 수 있습니다.
- 다중 HAL 인스턴스. 예를 들어,
graphics.composer HAL에 두 개의 인스턴스(하나는 서비스 이름이 'default'이고 다른 하나는 서비스 이름이 'vr'임)가 있는 경우 VTS는 두 인스턴스를 모두 식별하고 각각에 테스트를 실행할 수 있습니다.
- 다중 HAL 테스트. 여러 개의 인스턴스가 있는 다중 HAL을 테스트할 때 사용됩니다. 예를 들어, keymaster와 gatekeeper HAL이 연동되는 방식을 확인하는 VTS 테스트를 실행할 경우 VTS는 이러한 HAL의 모든 서비스 인스턴스 조합을 테스트할 수 있습니다.
타겟 측 테스트
타겟 측 테스트에 서비스 이름 인식을 사용 설정하기 위해 Android 9에는 맞춤설정이 가능한 테스트 환경(VtsHalHidlTargetTestEnvBase)이 포함되어 있습니다. 이 테스트 환경에서는 다음과 같은 기능의 인터페이스를 제공합니다.
- 테스트에 타겟 HAL 등록
- 등록된 모든 HAL 나열
- VTS 프레임워크에서 제공하는 등록된 HAL의 서비스 이름 가져오기
또한 VTS 프레임워크는 다음 항목에 관한 런타임 지원을 제공합니다.
- 등록된 모든 테스트 HAL을 가져오도록 테스트 바이너리 사전 처리
- 실행 중인 모든 서비스 인스턴스 식별 및 각 인스턴스의 서비스 이름 가져오기(
vendor/manifest.xml에 기반하여 가져옴)
- 모든 인스턴스 조합 계산(다중 HAL 테스트 지원 목적)
- 각 서비스 인스턴스(조합)에 관한 새로운 테스트 생성
예:
그림 1. 타겟 측 테스트를 위한 VTS 프레임워크 런타임 지원
서비스 이름을 인식하는 타겟 측 테스트 설정
서비스 이름을 인식하는 타겟 측 테스트의 테스트 환경을 설정하려면 다음 단계를 따릅니다.
VtsHalHidlTargetTestEnvBase에 따라 testEnvironment를 정의하고 테스트 HAL을 등록합니다.
#include <VtsHalHidlTargetTestEnvBase.h>
class testEnvironment : public::testing::VtsHalHidlTargetTestEnvBase {
virtual void registerTestServices() override {
registerTestService<IFoo>();
}
};
- 테스트 환경에서 제공된
getServiceName()을 사용하여 서비스 이름을 전달합니다.
::testing::VtsHalHidlTargetTestBase::getService<IFoo>(testEnv->getServiceName<IFoo>("default"));
// "default" is the default service name you want to use.
main() 및 initTest에서 테스트 환경을 등록합니다.
int main(int argc, char** argv) {
testEnv = new testEnvironment();
::testing::AddGlobalTestEnvironment(testEnv);
::testing::InitGoogleTest(&argc, argv);
testEnv->init(argc, argv);
return RUN_ALL_TESTS();
}
추가 예는 VtsHalCameraProviderV2_4TargetTest.cpp를 참고하세요.
VTS 호스트 측 테스트
VTS 호스트 측 테스트는 대상 기기에서 테스트 바이너리를 실행하는 대신 호스트 측에서 테스트 스크립트를 실행합니다. 이러한 테스트에 서비스 이름 인식을 사용 설정하려면 호스트 측 템플릿을 사용하여 서로 다른 매개변수를 대상으로 동일한 테스트 스크립트를 여러 번 실행하면 됩니다(gtest 매개변수화된 테스트와 유사함).
그림 2. 호스트 측 테스트를 위한 VTS 프레임워크 런타임 지원
- hal test 스크립트는 테스트에 타겟 HAL 서비스를 지정합니다.
hal_hidl_host_test(param_test의 서브클래스)에서는 테스트 스크립트에서 등록된 테스트 HAL을 가져와서 테스트 HAL의 서비스 이름을 식별한 다음 테스트 매개변수 형태로 서비스 이름 조합(다중 HAL 테스트용)을 생성합니다. 또한, 현재 테스트 사례에 전달된 매개변수에 따라 이에 대응하는 서비스 이름을 반환하는 getHalServiceName() 메서드도 제공합니다.- param_test 템플릿은 매개변수 목록을 허용하고 각 매개변수에 지정된 모든 테스트 사례를 실행하는 논리를 지원합니다. 즉, 이 템플릿은 테스트 사례마다 N개(N=매개변수 크기임)의 매개변수화된 새로운 테스트 사례를 생성합니다. 이때 각 테스트 사례에는 지정된 매개변수가 있습니다.
서비스 이름을 인식하는 호스트 측 테스트 설정
서비스 이름을 인식하는 호스트 측 테스트의 테스트 환경을 설정하려면 다음 단계를 따릅니다.
- 테스트 스크립트에서 타겟 HAL 서비스를 지정합니다.
TEST_HAL_SERVICES = { "android.hardware.foo@1.0::IFoo" }
getHalServiceName()을 호출하고 이름을 init hal에 전달합니다.
self.dut.hal.InitHidlHal(
target_type='foo',
target_basepaths=self.dut.libPaths,
target_version=1.0,
target_package='android.hardware.foo',
target_component_name='IFoo',
hw_binder_service_name
=self.getHalServiceName("android.hardware.foo@1.0::IFoo"),
bits=int(self.abi_bitness))
추가 예는 VtsHalMediaOmxStoreV1_0HostTest.py를 참고하세요.
테스트 HAL 등록
이전 버전의 Android에서 VTS는 AndroidTest.xml에 구성된 <precondition-lshal> 옵션을 사용하여 테스트 HAL을 식별했습니다. 이 접근 방식은 개발자가 테스트를 올바르게 구성하고 그에 따라 구성을 업데이트하는 데 의존했기 때문에 관리가 어렵고, 인터페이스 정보가 아닌 패키지와 버전 정보만 포함되어서 부정확했습니다.
Android 9에서 VTS는 서비스 이름 인식을 사용하여 테스트 HAL을 식별합니다. 등록된 테스트 HAL은 다음 경우에도 유용합니다.
- 전제 조건 확인. HAL 테스트를 실행하기 전에 VTS는 대상 기기에서 테스트 HAL을 사용할 수 있는지 확인하고 사용할 수 없는 경우 테스트를 건너뛸 수 있습니다(VTS 테스트 가능성 확인 참고).
- 적용 범위 측정. VTS에서는 측정하려는 테스트 HAL 서비스의 정보를 통해 프로세스 간 코드 적용 범위를 측정할 수 있습니다(즉, HAL 서비스 프로세스의 적용 범위를 플러시함).
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 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,["# Service name aware HAL testing\n\nAndroid 9 includes support for obtaining the service\nname of a given HAL instance based on the device on which Vendor Test Suite\n(VTS) tests are running. Running VTS HAL tests that are service name aware\nenables developers to automate testing vendor extensions, multiple HALs, and\nmultiple HAL instances on both target- and host-side VTS test runs.\n\n### About service names\n\n\nEach instance of the running HAL service registers itself with a service name.\n\n\nIn previous versions of Android, developers running VTS HAL tests were\nrequired to set the correct service name for the test client in\n`getService()` or leave the name empty and fallback to the default\nservice name. Disadvantages to this approach included:\n\n- Reliance on the test developer's knowledge to set the correct service name.\n- Limited to testing against a single service instance by default.\n- Manual maintenance of service names (i.e. because names are hard-coded, they must be manually updated if the service name changes.\n\n\nIn Android 9, developers can automatically get the\nservice name for a given HAL instance based on the device under test.\nAdvantages to this approach include support for testing:\n\n- **Vendor HAL extensions**. For example, when a vendor has an implementation of camera.provider HAL that runs on vendor devices with a customized service name, VTS can identify the vendor instance and run the test against it.\n- **Multiple HAL instances** . For example, when the `graphics.composer` HAL has two instances (one with service name \"default\" and one with service name \"vr\"), VTS can identify both instances and run the test against each of them.\n- **Multi-HAL testing**. Used when testing multiple HALs with multiple instances For example, when running the VTS test that verifies how the KeyMint (previously Keymaster) and Gatekeeper HALs work together, VTS can test all combinations of service instances for those HALs.\n\nTarget-side tests\n-----------------\n\n\nTo enable service name awareness for target-side testing, Android\n9 includes a customizable test environment\n([VtsHalHidlTargetTestEnvBase](https://android.googlesource.com/platform/test/vts/+/android16-release/runners/target/vts_hal_hidl_target/VtsHalHidlTargetTestEnvBase.h))\nthat provides interfaces to:\n\n- Register targeting HAL(s) in the test.\n- List all the registered HAL(s).\n- Get service name(s) for registered HAL(s) provided by VTS framework.\n\n\nIn addition, the VTS framework provides runtime support for:\n\n- Pre-processing the test binary to get all registered test HAL(s).\n- Identifying all running service instances and getting the service name for each instance (retrieved based on `vendor/manifest.xml`).\n- Calculating all instance combinations (to support multiple HAL testing).\n- Generating a new test for each service instance (combination).\n\n\nExample:\n\n\n**Figure 1.** VTS framework runtime support for target-side testing\n\n### Set up service name aware target-side tests\n\n\nTo setup your test environment for target-side service name aware testing:\n\n1. Define a `testEnvironment` based on `VtsHalHidlTargetTestEnvBase` and register test HALs: \n\n ```verilog\n #include \u003cVtsHalHidlTargetTestEnvBase.h\u003e\n class testEnvironment : public::testing::VtsHalHidlTargetTestEnvBase {\n virtual void registerTestServices() override {\n registerTestService\u003cIFoo\u003e();\n }\n };\n ```\n2. Use `getServiceName()` provided by the test environment to pass service name: \n\n ```css+lasso\n ::testing::VtsHalHidlTargetTestBase::getService\u003cIFoo\u003e(testEnv-\u003egetServiceName\u003cIFoo\u003e(\"default\"));\n // \"default\" is the default service name you want to use.\n ```\n3. Register the test environment in `main()` and `initTest`: \n\n ```css+lasso\n int main(int argc, char** argv) {\n testEnv = new testEnvironment();\n ::testing::AddGlobalTestEnvironment(testEnv);\n ::testing::InitGoogleTest(&argc, argv);\n testEnv-\u003einit(argc, argv);\n return RUN_ALL_TESTS();\n }\n ```\n\n\nFor additional examples, refer to\n[VtsHalCameraProviderV2_4TargetTest.cpp](https://android.googlesource.com/platform/hardware/interfaces/+/android16-release/camera/provider/2.4/vts/functional/VtsHalCameraProviderV2_4TargetTest.cpp).\n\nVTS host-side tests\n-------------------\n\n\nVTS host-side tests run test scripts on host side instead of test binaries on\nthe target device. To enable service name awareness for these tests, you can\nuse host side templates to run the same test script multiple times against\ndifferent parameters (similar to the gtest parameterized test).\n\n\n**Figure 2.** VTS framework runtime support for host-side testing\n\n- The **hal test** script specifies the targeting HAL service(s) in the test.\n- The [hal_hidl_host_test](https://android.googlesource.com/platform/test/vts/+/android16-release/testcases/template/hal_hidl_host_test/hal_hidl_host_test.py) (subclass of `param_test`) takes the registered testing HAL(s) from test script, identifies the corresponding service name(s) for the testing HAL, then generates service name combinations (for multi-HAL testing) as test parameters. It also provides a method `getHalServiceName()` which returns the corresponding service name according to the parameter passed to the current test case.\n- The [param_test](https://android.googlesource.com/platform/test/vts/+/android16-release/testcases/template/param_test/param_test.py) template supports logic to accept a list of parameters and run all the given test cases against each parameter. I.e. for each test case it generates N new parameterized test case (N = size of parameters), each with a given parameter.\n\n### Set up service name aware host-side tests\n\n\nTo setup your test environment for host-side service name aware testing:\n\n1. Specify the target HAL service in the test script: \n\n ```objective-c\n TEST_HAL_SERVICES = { \"android.hardware.foo@1.0::IFoo\" }\n ```\n2. Call `getHalServiceName()` and pass the name to init hal: \n\n ```objective-c\n self.dut.hal.InitHidlHal(\n target_type='foo',\n target_basepaths=self.dut.libPaths,\n target_version=1.0,\n target_package='android.hardware.foo',\n target_component_name='IFoo',\n hw_binder_service_name\n =self.getHalServiceName(\"android.hardware.foo@1.0::IFoo\"),\n bits=int(self.abi_bitness))\n ```\n\n\nFor additional examples, refer to\n[VtsHalMediaOmxStoreV1_0HostTest.py](https://android.googlesource.com/platform/test/vts-testcase/hal/+/android16-release/media/omx/V1_0/host_omxstore/VtsHalMediaOmxStoreV1_0HostTest.py).\n\nRegister test HALs\n------------------\n\n\nIn previous versions of Android, VTS identified the testing HAL using the\n`\u003cprecondition-lshal\u003e` option configured in\n`AndroidTest.xml`. This approach was difficult to maintain (as it\nrelied on developers to configure the test properly and update the\nconfiguration accordingly) and inaccurate (as it contained only the package\nand version info and not the interface info).\n\n\nIn Android 9, VTS identifies the testing HAL using\nservice name awareness. The registered testing HALs are also useful for:\n\n- **Precondition checks** . Before running a HAL test, VTS can confirm the testing HAL is available on the target device and skip the tests if it is not (refer to [VTS\n testability check](/docs/core/tests/vts/hal-testability)).\n- **Coverage measurement**. VTS supports cross-process code coverage measurement via the knowledge about the testing HAL services it wants to measure (i.e. to flush the coverage for the hal service process)."]]
