הגדרת הבדיקה

חבילת בדיקות

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

disable_framework: true,

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

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

הוספת ארגומנטים נוספים לבדיקה

יכול להיות שיידרש יותר זמן להרצת חלק מהבדיקות של gtest. במקרים כאלה, אפשר להוסיף אפשרויות של test runner לקובץ ה-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 שמגדירה את הערך הזה. הערך קבוע למשך חיי המערכת על שבב.

כדי להגדיר את 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. הגרסה תוחלף ברמת ה-API המתאימה של הספק אם היא מוגדרת לגרסה מ-ro.product.first_api_level שגדולה מ-35 או שווה לה. אפשר להשתמש במאפיין הזה כדי להחריג מהדרישות של הספק לגבי ה-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-on-GSI לרסיסים ומריצה אותם בכמה מכשירים.