הגדרת הבדיקה

קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

חבילת בדיקות

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

test_suites: ["vts"],

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

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

ברוב המקרים, הגדרת הבדיקה, שהיא קובץ 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",

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

אילוץ הרצה של הבדיקה עם Root של adb

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