הגדרת הבדיקה

חבילת בדיקות

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