از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
آزمایش HAL از نام سرویس آگاه است
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
Android 9 شامل پشتیبانی برای به دست آوردن نام سرویس یک نمونه HAL معین بر اساس دستگاهی است که تست‌های مجموعه تست فروشنده (VTS) روی آن اجرا می‌شود. اجرای آزمایش‌های VTS HAL که از نام سرویس آگاه هستند، توسعه‌دهندگان را قادر می‌سازد تا برنامه‌های افزودنی فروشنده، HALهای متعدد و نمونه‌های HAL متعدد را در هر دو اجرای آزمایشی VTS سمت مقصد و میزبان، خودکار کنند.
درباره نام خدمات
هر نمونه از سرویس HAL در حال اجرا خود را با نام سرویس ثبت می کند.
در نسخه‌های قبلی اندروید، توسعه‌دهندگانی که آزمایش‌های VTS HAL را اجرا می‌کردند، باید نام سرویس صحیح را برای سرویس گیرنده آزمایشی در getService() تنظیم می‌کردند یا نام را خالی می‌گذاشتند و به نام سرویس پیش‌فرض برگردانیدند. معایب این روش عبارتند از:
- برای تنظیم نام صحیح سرویس، به دانش توسعه دهنده آزمون تکیه کنید.
- به طور پیش فرض محدود به آزمایش در برابر یک نمونه سرویس واحد است.
- نگهداری دستی نام‌های سرویس (یعنی چون نام‌ها سخت‌کد هستند، در صورت تغییر نام سرویس، باید به‌صورت دستی به‌روزرسانی شوند.
در اندروید 9، توسعه دهندگان می توانند به طور خودکار نام سرویس را برای یک نمونه HAL بر اساس دستگاه تحت آزمایش دریافت کنند. از مزایای این روش می توان به پشتیبانی از آزمایش اشاره کرد:
- پسوند HAL فروشنده . به عنوان مثال، هنگامی که یک فروشنده یک پیاده سازی از camera.provider HAL دارد که بر روی دستگاه های فروشنده با نام سرویس سفارشی اجرا می شود، VTS می تواند نمونه فروشنده را شناسایی کرده و آزمایش را در برابر آن اجرا کند.
- چند نمونه HAL . به عنوان مثال، زمانی که
graphics.composer HAL دو نمونه دارد (یکی با نام سرویس "default" و دیگری با نام سرویس "vr")، VTS می تواند هر دو نمونه را شناسایی کرده و آزمایش را بر روی هر یک از آنها اجرا کند. - تست Multi-HAL . برای آزمایش چندین HAL با چندین نمونه استفاده می‌شود، به‌عنوان مثال، هنگام اجرای آزمایش VTS که بررسی می‌کند چگونه KeyMint (قبلاً Keymaster) و HALهای 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 سرویس(های) هدف 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 های آزمایشی را ثبت کنید
در نسخه های قبلی اندروید، VTS با استفاده از گزینه <precondition-lshal> پیکربندی شده در AndroidTest.xml ، HAL آزمایشی را شناسایی کرد. حفظ این رویکرد دشوار بود (زیرا به توسعه دهندگان متکی بود تا آزمایش را به درستی پیکربندی کنند و پیکربندی را متناسب با آن به روز کنند) و نادرست بود (زیرا فقط اطلاعات بسته و نسخه را شامل می شد و نه اطلاعات رابط).
در اندروید 9، VTS با استفاده از آگاهی از نام سرویس، HAL آزمایشی را شناسایی می‌کند. HAL های تست ثبت شده نیز برای موارد زیر مفید هستند:
- بررسی های پیش شرط قبل از اجرای آزمایش HAL، VTS می‌تواند تأیید کند که HAL آزمایشی در دستگاه مورد نظر در دسترس است و در صورت عدم وجود آن، از آزمایش‌ها صرفنظر کند (به بررسی آزمایش‌پذیری VTS مراجعه کنید).
- اندازه گیری پوشش . VTS از اندازه‌گیری پوشش کد متقابل فرآیند از طریق دانش در مورد سرویس‌های آزمایشی HAL که می‌خواهد اندازه‌گیری کند، پشتیبانی می‌کند (یعنی برای شستشوی پوشش فرآیند خدمات hal).
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین به‌روزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-29 بهوقت ساعت هماهنگ جهانی."],[],[],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)."]]
