自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 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
还会显示具有透传实现(即在设备上具有相应的 -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 依赖供应商清单和 lshal
输出来确定(和测试)未在 manifest.xml
文件中声明的实验性 HAL。决策流程如下所示:
图 2. VTS 非合规性测试的可测试性检查
查找供应商清单
VTS 按以下顺序在以下位置查找供应商 manifest.xml
文件
:
/vendor/etc/vintf/manifest.xml
+ ODM 清单(如果这两个位置定义了同一 HAL,则 ODM 清单将替换 /vendor/etc/vintf/manifest.xml
中的 HAL)
/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 打包在一起的二进制程序,VTS 测试框架会在运行时使用该工具来确定指定的 HAL 测试是否可行。该工具基于 libvintf
来加载和解析供应商清单文件,并实现上一部分中所述的决策流程。
如需使用 vts_testability_check
,请执行以下操作:
- 对于合规性测试:
vts_testability_check -c -b <bitness> <hal@version>
- 对于非合规性测试:
vts_testability_check -b <bitness> <hal@version>
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
],/system/manifest.xml
中会声明 HAL)。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-03-09。
[[["易于理解","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"]],["最后更新时间 (UTC):2025-03-09。"],[],[],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`.)"]]