自 2025 年 3 月 27 日起,我們建議您使用 android-latest-release
而非 aosp-main
建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
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
檔案)。範例如下:
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
中的資訊清單)
/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
),HAL 會在 /system/manifest.xml
中宣告)。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-08-23 (世界標準時間)。
[[["容易理解","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-08-23 (世界標準時間)。"],[],[],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`.)"]]