راه‌اندازی آزمایش

مجموعه آزمون

برای اینکه آزمایشی بخشی از VTS باشد، باید تنظیم زیر را در Android.bp داشته باشد.

test_suites: ["vts"],

علاوه‌براین، افزودن آزمایش به مجموعه general-tests به آن امکان می‌دهد بخشی از مجموعه «نگاشت آزمایش» باشد که در بررسی‌های پیش‌ارسال استفاده می‌شود.

پیکربندی آزمایش

در بیشتر موارد، پیکربندی آزمایش، که فایل XML مورداستفاده Trade Federation برای اجرای آزمایش VTS است، به‌طور خودکار درطول ساخت تولید می‌شود. بااین‌حال، می‌توانید پیکربندی آزمون را سفارشی‌سازی کنید.

ایجاد فایل پیکربندی آزمایش سفارشی

ایجاد یک فایل XML آزمایشی جدید از ابتدا می‌تواند پیچیده باشد، زیرا شامل درک نحوه عملکرد مجموعه داده‌های تست و همچنین تفاوت بین هر اجراکننده تست است. فایل پیکربندی آزمایش تولیدشده به‌طور خودکار برای آسان‌تر کردن این فرایند طراحی شده است.

اگر باید فایل XML آزمایش را سفارشی‌سازی کنید، می‌توانید از فایل تولیدشده به‌صورت خودکار به‌عنوان نقطه شروع استفاده کنید.

برای پیدا کردن فایل پیکربندی آزمایشی خودکار تولیدشده، ابتدا همان‌طور که در زیر نشان داده شده است، فرمان make را برای ساختن پیکربندی اجرا کنید.

$ m VtsHalUsbV1_1TargetTest

در فهرست ساختار خود، می‌توانید فایل پیکربندی را براساس نام واحد، همان‌طور که در زیر نشان داده شده است، جستجو کنید.

$ find out/ -name VtsHalUsbV1_1TargetTest.config

ممکن است چندین نسخه از فایل وجود داشته باشد و می‌توانید از هرکدام از آن‌ها استفاده کنید. فایل .config را در دایرکتوری‌ای که فایل Android.bp در آن قرار دارد کپی کنید.

اگر فقط یک واحد آزمایش در فایل Android.bp وجود داشته باشد، می‌توانید فایل XML را به AndroidTest.xml تغییر نام دهید، و سیستم ساخت به‌طور خودکار از آن به‌عنوان فایل پیکربندی واحد آزمایش استفاده می‌کند. درغیراین‌صورت، مشخصه test_config را به ماژول اضافه کنید، همان‌طور که در مثال زیر نشان داده شده است.

test_config: "VtsHalUsbV1_1TargetTest.xml",

اکنون فایل پیکربندی آزمایشی برای کار کردن و پیاده‌سازی سفارشی‌سازی دارید.

اجبار کردن آزمایش برای اجرا با adb root

اکثر آزمایش‌های 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 در ورودی زیر به آزمایش اجازه می‌دهد با زمان اتمام ۳ دقیقه اجرا شود، به‌جای زمان اتمام پیش‌فرض ۱ دقیقه.

   <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 فقط در دستگاه‌هایی با حداقل سطح API اجرا می‌شوند. اگر فایل پیکربندی آزمایش به‌طور خودکار تولید می‌شود، می‌توانید ویژگی زیر را به 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 را برای نمایش سطح API تصاویر فروشنده در این دستگاه‌ها تعریف می‌کند. ترکیب این خصوصیات با ro.product.first_api_level، مجموعه‌های آزمایش موارد آزمایشی مناسب را برای دستگاه‌ها انتخاب می‌کند.

‫Android 13 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 دائمی است.

برای تنظیم 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.first_api_level وجود داشته باشد و ro.board.api_level روی سطح میانای برنامه‌سازی کاربردی قدیمی‌تری نسبت‌به ro.product.first_api_level تنظیم شده باشد، روی ro.board.api_level تنظیم می‌شود. اگر نسخه روی نسخه ro.product.first_api_level تنظیم شده باشد که بزرگ‌تر یا مساوی 35 است، نسخه با سطح میانای برنامه‌سازی کاربردی فروشنده مربوطه جایگزین خواهد شد. آزمایش‌های پیاده‌سازی فروشنده که نیاز به ارتقای تصویر فروشنده دارند ممکن است با ارجاع به این دارایی از الزامات فروشنده برای SoC مستثنا شوند.

فرایند شاردینگ بااستفاده از VTS

برای 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 را به چند بخش تقسیم می‌کند و آن‌ها را در چند دستگاه اجرا می‌کند.