בדיקת הכינון.

חבילת בדיקות

כדי שבדיקה תהיה חלק מ-VTS, היא צריכה להיות מוגדרת באמצעות ההגדרה הבאה ב-Android.bp.

test_suites: ["vts"],

בנוסף, הוספת הבדיקה לחבילה general-tests מאפשרת לה להיכלל בחבילת Test Mapping שמשמשת לבדיקות לפני שליחה.

הגדרות אישיות לבדיקה

ברוב המקרים, הגדרת הבדיקה, שהיא קובץ XML שמשמש את Trade Federation להרצת בדיקת VTS, נוצרת באופן אוטומטי במהלך ה-build. עם זאת, אפשר להתאים אישית את הגדרות הבדיקה.

יצירת קובץ תצורה מותאם אישית לבדיקה

יצירת קובץ XML חדש לבדיקה מהתחלה יכולה להיות מורכבת, כי צריך להבין איך עובד ציוד הבדיקה, וגם את ההבדל בין כל מפעיל בדיקה. קובץ התצורה של הבדיקה שנוצר באופן אוטומטי נועד להקל על התהליך הזה.

אם אתם צריכים להתאים אישית את קובץ ה-XML לבדיקה, תוכלו להשתמש בקובץ שנוצר באופן אוטומטי כנקודת התחלה.

כדי לאתר את קובץ התצורה של הבדיקה שנוצר באופן אוטומטי, מריצים קודם את הפקודה make כדי ליצור את קובץ התצורה, כפי שמתואר בהמשך.

$ m VtsHalUsbV1_1TargetTest

בספריית ה-build שלכם תוכלו לחפש את קובץ התצורה לפי שם המודול, כפי שמוצג בהמשך.

$ find out/ -name VtsHalUsbV1_1TargetTest.config

יכולים להיות כמה עותקים של הקובץ, וניתן להשתמש בכל אחד מהם. מעתיקים את הקובץ .config לספרייה שבה נמצא הקובץ Android.bp.

אם יש רק מודול בדיקה אחד בקובץ Android.bp, אפשר לשנות את שם קובץ ה-XML ל-AndroidTest.xml, ומערכת ה-build תשתמש בו באופן אוטומטי כקובץ התצורה של מודול הבדיקה. אחרת, מוסיפים את המאפיין test_config למודול, כפי שמוצג בדוגמה הבאה.

test_config: "VtsHalUsbV1_1TargetTest.xml",

עכשיו יש לכם קובץ תצורה לבדיקה, שבו תוכלו לעבוד ולהטמיע את ההתאמה האישית.

איך מפעילים את הבדיקה באמצעות adb root

כדי להריץ את רוב הבדיקות של VTS נדרשת הרשאת root. אם קובץ ההגדרות של הבדיקה נוצר באופן אוטומטי, אפשר להוסיף את המאפיין הבא ל-Android.bp.

require_root: true,

אם קובץ התצורה של הבדיקה מותאם אישית, מוסיפים את הקטע הבא לקובץ ה-XML של הבדיקה.

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

הפסקת המסגרת במהלך הבדיקה

כדי לבצע בדיקות VTS רבות לא צריך להשתמש ב-framework של Android, והרצת הבדיקה עם framework נעצרת מאפשרת את הבדיקה לרוץ ביציבות בלי להשפיע על פריקים במכשיר. אם קובץ ההגדרות של הבדיקה נוצר באופן אוטומטי, אפשר להוסיף את המאפיין הבא ל-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>

דרישה לרמת 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

ב-Android 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 של הספק.

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 של הספק הוקפא. מערכת ה-build מגדירה אותו באופן אוטומטי.

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

ב-Android מגרסה 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 ב-GSI למקטעים ומריצה אותם במספר מכשירים.