اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release
بدلاً من aosp-main
لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
اختبار HAL المدرك لاسم الخدمة
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
يتضمّن Android 9 إمكانية الحصول على اسم الخدمة لمثيل HAL معيّن استنادًا إلى الجهاز الذي يتم تشغيل اختبارات Vendor Test Suite (VTS) عليه. يؤدي تشغيل اختبارات VTS HAL التي تتوافق مع أسماء الخدمات إلى تمكين المطوّرين من تنفيذ الاختبارات تلقائيًا على إضافات المورّدين، وواجهات HAL المتعددة، ومثيلات HAL المتعددة في عمليات تشغيل اختبارات VTS على كل من الجهاز المستهدف والجهاز المضيف.
لمحة عن أسماء الخدمات
تسجّل كل نسخة من خدمة HAL قيد التشغيل نفسها باسم خدمة.
في الإصدارات السابقة من Android، كان على المطوّرين الذين ينفّذون اختبارات VTS HAL ضبط اسم الخدمة الصحيح لبرنامج الاختبار في getService()
أو ترك الاسم فارغًا والرجوع إلى اسم الخدمة التلقائي. تشمل عيوب هذا النهج ما يلي:
- الاعتماد على معرفة مطوّر الاختبار لضبط اسم الخدمة الصحيح
- يقتصر الاختبار تلقائيًا على مثيل خدمة واحد.
- الصيانة اليدوية لأسماء الخدمات (أي لأنّ الأسماء مبرمَجة بشكل ثابت، يجب تعديلها يدويًا في حال تغيّر اسم الخدمة)
في نظام التشغيل Android 9، يمكن للمطوّرين الحصول تلقائيًا على اسم الخدمة لمثيل HAL معيّن استنادًا إلى الجهاز قيد الاختبار.
تشمل مزايا هذا النهج إمكانية إجراء الاختبارات:
- إضافات Vendor HAL على سبيل المثال، عندما يكون لدى مورّد عملية تنفيذ لواجهة HAL الخاصة بـ camera.provider تعمل على أجهزة المورّدين مع اسم خدمة مخصّص، يمكن لأداة VTS تحديد مثيل المورّد وتشغيل الاختبار عليه.
- نُسخ متعددة من طبقة تجريد الأجهزة (HAL) على سبيل المثال، عندما يحتوي
graphics.composer
HAL على مثيلَين (أحدهما يحمل اسم الخدمة "default" والآخر يحمل اسم الخدمة "vr")، يمكن لأداة VTS تحديد كلا المثيلَين وتشغيل الاختبار على كل منهما.
- اختبار HAL المتعدّد يتم استخدامها عند اختبار عدة طبقات HAL مع عدة مثيلات، مثلاً عند تشغيل اختبار VTS الذي يتحقّق من كيفية عمل طبقتَي KeyMint (المعروفة سابقًا باسم Keymaster) وGatekeeper HAL معًا، يمكن أن يختبر VTS جميع مجموعات مثيلات الخدمة لهاتين الطبقتين.
اختبارات من جهة الاستهداف
لتفعيل ميزة التعرّف على اسم الخدمة لأغراض الاختبار على الجهاز المستهدف، يتضمّن الإصدار 9 من نظام التشغيل Android بيئة اختبار قابلة للتخصيص (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 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","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 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],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)."]]