ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release แทน aosp-main เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP
การทดสอบ HAL ที่รับรู้ชื่อบริการ
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
Android 9 รองรับการรับชื่อบริการของอินสแตนซ์ HAL ที่ระบุตามอุปกรณ์ที่ชุดทดสอบของผู้ให้บริการ (VTS) ทำงานอยู่ การเรียกใช้การทดสอบ VTS HAL ที่รับรู้ชื่อบริการ
ช่วยให้นักพัฒนาซอฟต์แวร์สามารถทำการทดสอบส่วนขยายของผู้ให้บริการ, HAL หลายรายการ และ
อินสแตนซ์ HAL หลายรายการโดยอัตโนมัติในการทดสอบ VTS ทั้งฝั่งเป้าหมายและฝั่งโฮสต์
เกี่ยวกับชื่อบริการ
อินสแตนซ์แต่ละรายการของบริการ HAL ที่ทำงานจะลงทะเบียนตัวเองด้วยชื่อบริการ
ใน Android เวอร์ชันก่อนหน้านี้ นักพัฒนาแอปที่เรียกใช้การทดสอบ VTS HAL จะต้องตั้งชื่อบริการที่ถูกต้องสำหรับไคลเอ็นต์ทดสอบใน
getService() หรือปล่อยให้ชื่อว่างไว้และกลับไปใช้ชื่อบริการเริ่มต้น
ข้อเสียของแนวทางนี้ ได้แก่
- การพึ่งพาความรู้ของนักพัฒนาซอฟต์แวร์ทดสอบในการตั้งชื่อบริการที่ถูกต้อง
- โดยค่าเริ่มต้นจะจำกัดการทดสอบกับอินสแตนซ์บริการเดียว
- การบำรุงรักษาชื่อบริการด้วยตนเอง (กล่าวคือ เนื่องจากชื่อมีการฮาร์ดโค้ด
จึงต้องอัปเดตด้วยตนเองหากชื่อบริการมีการเปลี่ยนแปลง
ใน Android 9 นักพัฒนาแอปจะรับชื่อบริการสำหรับอินสแตนซ์ HAL ที่กำหนดโดยอัตโนมัติตามอุปกรณ์ที่อยู่ระหว่างการทดสอบได้
ข้อดีของแนวทางนี้รวมถึงการรองรับการทดสอบมีดังนี้
- ส่วนขยาย HAL ของผู้จำหน่าย ตัวอย่างเช่น เมื่อผู้ให้บริการมีการ
ติดตั้งใช้งาน HAL ของ camera.provider ที่ทำงานบนอุปกรณ์ของผู้ให้บริการที่มี
ชื่อบริการที่กำหนดเอง VTS จะระบุอินสแตนซ์ของผู้ให้บริการและเรียกใช้การทดสอบ
กับอินสแตนซ์นั้นได้
- HAL หลายอินสแตนซ์ ตัวอย่างเช่น เมื่อ
graphics.composer HAL มี 2 อินสแตนซ์ (อินสแตนซ์หนึ่งมีชื่อบริการ "default" และอีกอินสแตนซ์หนึ่งมีชื่อบริการ "vr") VTS จะระบุทั้ง 2 อินสแตนซ์และเรียกใช้การทดสอบกับแต่ละอินสแตนซ์ได้
- การทดสอบ HAL หลายรายการ ใช้เมื่อทดสอบ HAL หลายรายการที่มีอินสแตนซ์หลายรายการ เช่น เมื่อเรียกใช้การทดสอบ VTS ที่ตรวจสอบว่า HAL ของ KeyMint (เดิมคือ Keymaster) และ Gatekeeper ทำงานร่วมกันอย่างไร VTS จะทดสอบชุดค่าผสมทั้งหมดของอินสแตนซ์บริการสำหรับ HAL เหล่านั้นได้
การทดสอบฝั่งเป้าหมาย
Android 9 มีสภาพแวดล้อมการทดสอบที่ปรับแต่งได้ (VtsHalHidlTargetTestEnvBase) เพื่อให้มีอินเทอร์เฟซสำหรับทำสิ่งต่อไปนี้ เพื่อเปิดใช้การรับรู้ชื่อบริการสำหรับการทดสอบฝั่งเป้าหมาย
- ลงทะเบียน HAL ของการกำหนดเป้าหมายในการทดสอบ
- แสดงรายการ HAL ที่ลงทะเบียนทั้งหมด
- รับชื่อบริการสำหรับ HAL ที่ลงทะเบียนซึ่งเฟรมเวิร์ก VTS จัดเตรียมไว้ให้
นอกจากนี้ เฟรมเวิร์ก VTS ยังรองรับรันไทม์สำหรับรายการต่อไปนี้
- ประมวลผลไบนารีของทดสอบล่วงหน้าเพื่อรับ HAL ของการทดสอบที่ลงทะเบียนทั้งหมด
- ระบุอินสแตนซ์บริการที่ทำงานทั้งหมดและรับชื่อบริการสำหรับ
แต่ละอินสแตนซ์ (ดึงข้อมูลตาม
vendor/manifest.xml)
- การคำนวณการผสมผสานอินสแตนซ์ทั้งหมด (เพื่อรองรับการทดสอบ HAL หลายรายการ
)
- สร้างการทดสอบใหม่สำหรับอินสแตนซ์บริการ (ชุดค่าผสม) แต่ละรายการ
ตัวอย่าง
รูปที่ 1 การรองรับรันไทม์ของเฟรมเวิร์ก VTS สำหรับการทดสอบฝั่งเป้าหมาย
ตั้งค่าการทดสอบฝั่งเป้าหมายที่รับรู้ชื่อบริการ
วิธีตั้งค่าสภาพแวดล้อมการทดสอบสำหรับการทดสอบที่รับรู้ชื่อบริการฝั่งเป้าหมาย
- กำหนด
testEnvironment ตาม
VtsHalHidlTargetTestEnvBase และลงทะเบียน 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 จะระบุ HAL การทดสอบโดยใช้ตัวเลือก <precondition-lshal> ที่กำหนดค่าไว้ใน AndroidTest.xml วิธีนี้ดูแลรักษายาก (เนื่องจากต้องอาศัยนักพัฒนาซอฟต์แวร์ในการกำหนดค่าการทดสอบอย่างถูกต้องและอัปเดตการกำหนดค่าตามนั้น) และไม่ถูกต้อง (เนื่องจากมีเฉพาะข้อมูลแพ็กเกจและเวอร์ชัน ไม่ใช่ข้อมูลอินเทอร์เฟซ)
ใน Android 9 VTS จะระบุ HAL ที่ใช้ทดสอบโดยใช้
การรับรู้ชื่อบริการ นอกจากนี้ HAL การทดสอบที่ลงทะเบียนแล้วยังมีประโยชน์สำหรับสิ่งต่อไปนี้ด้วย
- การตรวจสอบข้อกำหนดเบื้องต้น ก่อนที่จะเรียกใช้การทดสอบ HAL นั้น VTS สามารถ
ยืนยันว่า HAL ที่ทดสอบพร้อมใช้งานในอุปกรณ์เป้าหมายและข้ามการทดสอบ
หากไม่พร้อมใช้งาน (ดูการตรวจสอบความสามารถในการทดสอบของ VTS)
- การวัดการครอบคลุม VTS รองรับการวัดความครอบคลุมของโค้ดข้ามกระบวนการ
ผ่านความรู้เกี่ยวกับบริการ HAL ของการทดสอบที่ต้องการ
วัด (เช่น เพื่อล้างความครอบคลุมสำหรับกระบวนการบริการ HAL)
ตัวอย่างเนื้อหาและโค้ดในหน้าเว็บนี้ขึ้นอยู่กับใบอนุญาตที่อธิบายไว้ในใบอนุญาตการใช้เนื้อหา Java และ OpenJDK เป็นเครื่องหมายการค้าหรือเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2025-07-27 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-07-27 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)."]]
