自 2025 年 3 月 27 日起,我們建議您使用 android-latest-release
而非 aosp-main
建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
服務名稱感知 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 和多個執行個體。舉例來說,執行 VTS 測試來驗證 KeyMint (先前為 Keymaster) 和 Gatekeeper HAL 如何協同運作時,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 服務程序的涵蓋範圍)。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-07-27 (世界標準時間)。
[[["容易理解","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"]],["上次更新時間:2025-07-27 (世界標準時間)。"],[],[],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)."]]