إعداد الاختبار

تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

مجموعة الاختبار

لكي يكون الاختبار جزءًا من VTS، يجب أن يتضمن الإعداد التالي في Android.bp.

test_suites: ["vts"],

بالإضافة إلى ذلك، تسمح إضافة الاختبار إلى المجموعة general-tests بأن يكون جزءًا من مجموعة "ربط الاختبارات" المستخدَمة في عمليات التحقّق من التقديم المُسبَق.

إعدادات الاختبار

في معظم الحالات، يتم تلقائيًا توليد ملف إعداد الاختبار، وهو ملف XML يستخدمه TradeFederation لإجراء اختبار VTS، أثناء عملية الإنشاء. ومع ذلك، يمكنك تخصيص إعدادات الاختبار.

إنشاء ملف إعداد اختبار مخصّص

قد يكون إنشاء ملف XML تجريبي جديد من البداية أمرًا معقدًا، إذ يتطلب بغض النظر عن كيفية عمل حزام الاختبار، وكذلك الفرق بين لكل عداء اختبار. صُمم ملف الإعداد للاختبار الذي تم إنشاؤه تلقائيًا لجعل هذه العملية أسهل.

إذا كان عليك تخصيص ملف XML التجريبي، يمكنك استخدام ملف تم إنشاؤه تلقائيًا كنقطة بداية.

لتحديد موقع ملف إعداد الاختبار الذي تم إنشاؤه تلقائيًا، عليك أولاً تنفيذ الأمر make لإنشاء ملف الإعداد، كما هو موضّح أدناه.

$ m VtsHalUsbV1_1TargetTest

في دليل الإخراج الخاص بالإنشاء، يمكنك البحث عن ملف config استنادًا إلى اسم الوحدة، كما هو موضّح أدناه.

$ find out/ -name VtsHalUsbV1_1TargetTest.config

ويمكن أن يكون هناك نسخ متعددة من الملف، ويمكنك استخدام أي منها. انسخ ملف .config إلى الدليل الذي يقع فيه ملف Android.bp.

إذا كانت هناك وحدة اختبار واحدة فقط في ملف Android.bp، يمكنك إعادة تسمية ملف XML إلى AndroidTest.xml، ويستخدم نظام الإنشاء هذا الملف تلقائيًا كملف إعدادات وحدة الاختبار. وإلا، إضافة السمة test_config إلى الوحدة، كما هو موضح في المثال أدناه.

test_config: "VtsHalUsbV1_1TargetTest.xml",

لديك الآن ملف إعداد تجريبي للعمل عليه وتنفيذه التخصيص.

فرض تشغيل الاختبار باستخدام إذن الوصول إلى الجذر من adb

يتطلب تشغيل معظم اختبارات VTS الحصول على امتياز جذر. إذا لم تسمح إعدادات الاختبار يتم إنشاؤه تلقائيًا، يمكنك إضافة السمة التالية إلى Android.bp.

require_root: true,

في حال تخصيص ملف الإعداد التجريبي، أضِف العنصر التالي إلى ملف XML التجريبي:

<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>

إيقاف إطار العمل أثناء الاختبار

لا يتطلب العديد من اختبارات VTS تشغيل إطار عمل Android، يسمح الاختبار مع إيقاف إطار العمل بإجراء الاختبار بثبات بدون التأثر برقائق الجهاز. إذا تم إنشاء ملف الإعدادات التجريبية تلقائيًا، يمكنك إضافة السمة التالية إلى Android.bp.

disable_framework: true,

إذا تم تخصيص ملف الإعداد التجريبي، أضِف العنصر التالي إلى ملف XML التجريبي:

<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>

إضافة وسيطات اختبار إضافية

قد يتطلب تشغيل بعض اختبارات gtest وقتًا أطول. في هذه الحالات، يمكنك إضافة خيارات مُشغّل الاختبار في ملف XML.

على سبيل المثال، يسمح الإعداد native-test-timeout في القيمة التالية للاختبار بتنفيذه مع مهلة 3 دقائق بدلاً من القيمة التلقائية التي تبلغ دقيقة واحدة.

   <test class="com.android.tradefed.testtype.GTest" >
       <option name="native-test-device-path" value="/data/local/tmp" />
       <option name="module-name" value="VtsHalNfcV1_0TargetTest" />
       <option name="native-test-timeout" value="180000"/>
   </test>

طلب الحد الأدنى لمستوى واجهة برمجة التطبيقات

لا يمكن تشغيل بعض اختبارات VTS إلا على الأجهزة التي تتضمن الحد الأدنى من مستوى واجهة برمجة التطبيقات. إذا كان ملف إعداد الاختبار يتم إنشاؤه تلقائيًا، يمكنك إضافة الصفة التالية إلى Android.bp.

min_shipping_api_level: 29,

أو

vsr_min_shipping_api_level: 202404,

في حال تخصيص ملف إعداد الاختبار، أضِف العبارة التالية إلى ملف XML للاختبار.

   <object type="module_controller" class="com.android.tradefed.testtype.suite.module.ShippingApiLevelModuleController">
       <option name="min-api-level" value="29" />
   </object>

أو

   <object type="module_controller" class="com.android.tradefed.testtype.suite.module.ShippingApiLevelModuleController">
       <option name="vsr-min-api-level" value="202404" />
   </object>

خصائص مستوى واجهة برمجة التطبيقات

يحدِّد نظام التشغيل Android 12 السمتَين ro.board.first_api_level و ro.board.api_level لعرض مستوى واجهة برمجة التطبيقات لصور المورّدين على هذه الأجهزة. من خلال الجمع بين هذه السمات وro.product.first_api_level، تختار مجموعات الاختبار حالات الاختبار المناسبة للأجهزة.

يحدِّد الإصدار 13 من نظام التشغيل Android القيمة ro.vendor.api_level التي يتم ضبطها تلقائيًا من خلال احتساب المستوى المطلوب لواجهة برمجة التطبيقات الخاصة بالمورّد باستخدام السمات ro.product.first_api_level وro.board.first_api_level و ro.board.api_level.

لمزيد من التفاصيل، يُرجى الاطّلاع على مستوى واجهة برمجة التطبيقات الخاصة بالمورّد.

ro.board.first_api_level

السمة ro.board.first_api_level هي مستوى واجهة برمجة التطبيقات عندما يتم إصدار صور المصنّع لوحدة المعالجة المركزية (SoC) المؤهَّلة لإيقاف التصنيع لأول مرة باستخدام هذه السمة. لا يعتمد ذلك على مستوى واجهة برمجة التطبيقات لبدء تشغيل الجهاز، بل يعتمد فقط على مستوى واجهة برمجة التطبيقات الأول لوحدة المعالجة المركزية (SoC) الذي يحدّد هذه القيمة. تشير رسالة الأشكال البيانية تكون دائمة طوال عمر المنظومة على الرقاقة (SoC).

لضبط ro.board.first_api_level، يمكن للشركات المصنّعة للأجهزة تحديد BOARD_SHIPPING_API_LEVEL في ملف device.mk، كما هو موضح في ما يلي مثال:

  # BOARD_SHIPPING_API_LEVEL sets ro.product.first_api_level to indicate
  # the first api level that the device has been commercially launched on.
  BOARD_SHIPPING_API_LEVEL := 23

سيتم تلقائيًا تحديد السمة ro.board.first_api_level على القيمة vendor/build.prop على الجهاز. يتم ضبط السمة من خلال عملية init المورّد.

ro.board.api_level

الموقع ro.board.api_level هو مستوى واجهة برمجة التطبيقات للمورّد الحالي الصور التي تحتوي على التنسيق YYYYMM حيث تم تجميد واجهة برمجة تطبيقات البائع. من المهم التي يحددها نظام التصميم تلقائيًا

ro.vendor.api_level

تم تقديم السمة ro.vendor.api_level في Android 13 لإظهار مستوى واجهة برمجة التطبيقات الذي يعرضه المورّد مطلوبة لتقديم الدعم. يتم ضبط هذا الإعداد تلقائيًا على ro.product.first_api_level أو ro.board.api_level إذا كان ro.board.first_api_level متوفّرًا وتم ضبط ro.board.api_level على مستوى أقدم لواجهة برمجة التطبيقات من ro.product.first_api_level. سيتم استبدال الإصدار بمستوى واجهة برمجة التطبيقات المقابل الخاص بالمورّد إذا تم ضبطه على الإصدار من ro.product.first_api_level الذي يكون أكبر من أو يساوي 35. الاختبارات بالنسبة إلى عمليات التنفيذ التي يجريها المورّد والتي تتطلب ترقية صورة البائع عن متطلبات البائع لمنظومة المنظومة على الرقاقة (SoC) من خلال الإشارة إلى هذا الموقع.

عملية تقسيم البيانات باستخدام VTS

بالنسبة إلى الإصدار 10 من Android أو الإصدارات الأحدث، يمكنك تنفيذ عملية التقسيم على على أجهزة متعددة أثناء الاختبار باستخدام كل من خطتي VTS وCTS-on-GSI من خلال اتباع التعليمات أدناه.

run vts --shard-count <number of devices> -s <device serial> ...

يقسم هذا الأمر خطة VTS إلى أجزاء ويشغلها على أجهزة متعددة.

run cts-on-gsi --shard-count <number of devices> -s <device serial> -s ...

يقسم هذا الأمر خطة CTS-on-GSI إلى أجزاء ويشغلها على عدة الأجهزة.