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
に設定されたバージョンが 1 つだけの場合、たとえば 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
のマニフェストに優先します)。
/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 サービス(graphics.composer/vr
など)の場合、HAL は /system/manifest.xml
で宣言されています。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-03-06 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"]],["最終更新日 2025-03-06 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`.)"]]