הגדרת הבדיקה

חבילת בדיקות

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

test_suites: ["vts"],

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

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

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

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

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

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

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

$ m VtsHalUsbV1_1TargetTest

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

$ 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 לא דורשות את Android framework כדי לפעול, והפעלת הבדיקה כשה-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

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