تنظیم تست

مجموعه تست

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

test_suites: ["vts"],

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

پیکربندی تست

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

یک فایل پیکربندی تست سفارشی ایجاد کنید

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

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

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

$ m VtsHalUsbV1_1TargetTest

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

$ 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.bp اضافه کنید.

disable_framework: true,

اگر فایل پیکربندی آزمایشی سفارشی شده است، موارد زیر را به فایل XML آزمایشی اضافه کنید.

<target_preparer class="com.android.tradefed.targetprep.StopServicesSetup"/>
آرگومان های آزمایشی اضافی را اضافه کنید

برخی از تست‌های gtest ممکن است به زمان بیشتری برای اجرا نیاز داشته باشند. در چنین مواردی می توانید گزینه های تست runner را در فایل XML اضافه کنید.

به عنوان مثال، تنظیمات native-test-timeout در ورودی زیر به آزمون اجازه می‌دهد تا به جای 1 دقیقه پیش‌فرض، با فاصله زمانی 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>
نیاز به حداقل سطح API

برخی از تست‌های 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>
ویژگی های سطح API

اندروید 12 ویژگی‌های ro.board.first_api_level و ro.board.api_level را برای نشان دادن سطح API تصاویر فروشنده در این دستگاه‌ها تعریف می‌کند. مجموعه‌های آزمایشی با ترکیب این ویژگی‌ها با ro.product.first_api_level ، موارد تست مناسبی را برای دستگاه‌ها انتخاب می‌کنند.

Android 13 ro.vendor.api_level تعریف می‌کند که به‌طور خودکار با محاسبه سطح API فروشنده مورد نیاز با استفاده از ویژگی‌های ro.product.first_api_level ، ro.board.first_api_level و ro.board.api_level تنظیم می‌شود.

برای جزئیات بیشتر، به سطح API Vendor مراجعه کنید.

ro.board.first_api_level

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

ro.vendor.api_level

ویژگی ro.vendor.api_level در Android 13 معرفی شد تا سطح API را که تصاویر فروشنده باید پشتیبانی کنند، نشان دهد. این به طور خودکار روی ro.product.first_api_level یا ro.board.api_level اگر ro.board.first_api_level وجود داشته باشد و ro.board.api_level روی سطح API زودتر از ro.product.first_api_level تنظیم شده است. اگر نسخه از ro.product.first_api_level که بزرگتر یا مساوی 35 باشد، نسخه با سطح API فروشنده مربوطه جایگزین خواهد شد. آزمایش‌هایی برای پیاده‌سازی فروشنده که به ارتقای تصویر فروشنده نیاز دارند، ممکن است با مراجعه به این ویژگی از الزامات فروشنده برای SoC مستثنی شوند.

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

برای اندروید نسخه 10 یا بالاتر، می‌توانید با دنبال کردن دستورالعمل‌های زیر، فرآیند اشتراک‌گذاری را در چندین دستگاه در حین آزمایش با طرح‌های 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 را به قطعات تقسیم می کند و آنها را روی چندین دستگاه اجرا می کند.