חבילת בדיקות
כדי שמבחן יהיה חלק מ-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
, ומערכת הבנייה משתמשת בזה באופן אוטומטי כקובץ התצורה של מודול הבדיקה. אחרת, הוסף תכונה test_config
למודול, כפי שמוצג בדוגמה למטה.
test_config: "VtsHalUsbV1_1TargetTest.xml",
כעת יש לך קובץ תצורת בדיקה לעבוד איתו וליישם את ההתאמה האישית.
הכריח את הבדיקה לפעול עם שורש adb
רוב בדיקות ה-VTS דורשות הרשאת שורש להפעלה. אם קובץ תצורת הבדיקה נוצר אוטומטית, תוכל להוסיף את התכונה הבאה ל- Android.bp
.
require_root: true,
אם קובץ תצורת הבדיקה מותאם אישית, הוסף את הבאים לקובץ ה-XML הבדיקה.
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
עצור את המסגרת במהלך המבחן
בדיקות VTS רבות אינן דורשות הפעלה של מסגרת אנדרואיד, והפעלת הבדיקה עם מסגרת עצורה מאפשרת לבדיקה לפעול ביציבות מבלי להיות מושפעת מקרעים במכשיר. אם קובץ תצורת הבדיקה נוצר אוטומטית, תוכל להוסיף את התכונה הבאה ל- 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
.
test_min_api_level: 29,
אם קובץ תצורת הבדיקה מותאם אישית, הוסף את הפקודה הבאה לקובץ ה-XML המבחן.
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.MinApiLevelModuleController">
<option name="min-api-level" value="29" />
</object>
אנדרואיד 12 מגדירה מאפייני ro.board.first_api_level
ו- ro.board.api_level
כדי להציג את רמת ה-API של תמונות הספק במכשירים אלה. בשילוב מאפיינים אלה עם ro.product.first_api_level
, חבילות בדיקה בוחרות מקרי בדיקה מתאימים עבור המכשירים.
אנדרואיד 13 מגדיר את ro.vendor.api_level
שמוגדר אוטומטית על ידי חישוב רמת ה-API של הספק באמצעות המאפיינים ro.product.first_api_level
, ro.board.first_api_level
ו- ro.board.api_level
.
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 הנוכחית של תמונות הספק עבור SoC. כאשר רמת ה-API של תמונת הספק בעלת ה- ro.board.first_api_level
מתעדכנת, המכשיר המשתמש ב-SoC חייב להגדיר את המאפיין ro.board.api_level
עם רמת ה-API הנוכחית של תמונת הספק במקום לעדכן את ה- ro.board.first_api_level
. אם מאפיין זה אינו מוגדר, ro.board.first_api_level
ישמש כברירת מחדל.
כדי להגדיר את ro.board.api_level
, הגדר BOARD_API_LEVEL
בקובץ device.mk
עם הערך הרצוי.
ro.vendor.api_level
המאפיין ro.vendor.api_level
הוצג באנדרואיד 13 כדי להציג את רמת ה-API שתמונות הספק נדרשות לתמוך בה. זה מוגדר אוטומטית למינימום של ro.board.api_level
(או ro.board.first_api_level
אם ro.board.api_level
לא מוגדר) ו- ro.product.first_api_level
. בדיקות להטמעת ספק הדורשות שדרוג תמונת ספק עשויות להיות חריגות מדרישות הספק עבור ה-SoC על ידי הפניה למאפיין זה.
תהליך פיצול באמצעות VTS
עבור אנדרואיד גרסה 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 לרסיסים ומפעילה אותם במספר מכשירים.
,חבילת בדיקות
כדי שמבחן יהיה חלק מ-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
, ומערכת הבנייה משתמשת בזה באופן אוטומטי כקובץ התצורה של מודול הבדיקה. אחרת, הוסף תכונה test_config
למודול, כפי שמוצג בדוגמה למטה.
test_config: "VtsHalUsbV1_1TargetTest.xml",
כעת יש לך קובץ תצורת בדיקה לעבוד איתו וליישם את ההתאמה האישית.
הכריח את הבדיקה לפעול עם שורש adb
רוב בדיקות ה-VTS דורשות הרשאת שורש להפעלה. אם קובץ תצורת הבדיקה נוצר אוטומטית, תוכל להוסיף את התכונה הבאה ל- Android.bp
.
require_root: true,
אם קובץ תצורת הבדיקה מותאם אישית, הוסף את הבאים לקובץ ה-XML הבדיקה.
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
עצור את המסגרת במהלך המבחן
בדיקות VTS רבות אינן דורשות הפעלה של מסגרת אנדרואיד, והפעלת הבדיקה עם מסגרת עצורה מאפשרת לבדיקה לפעול ביציבות מבלי להיות מושפעת מקרעים במכשיר. אם קובץ תצורת הבדיקה נוצר אוטומטית, תוכל להוסיף את התכונה הבאה ל- 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
.
test_min_api_level: 29,
אם קובץ תצורת הבדיקה מותאם אישית, הוסף את הפקודה הבאה לקובץ ה-XML המבחן.
<object type="module_controller" class="com.android.tradefed.testtype.suite.module.MinApiLevelModuleController">
<option name="min-api-level" value="29" />
</object>
אנדרואיד 12 מגדירה מאפייני ro.board.first_api_level
ו- ro.board.api_level
כדי להציג את רמת ה-API של תמונות הספק במכשירים אלה. בשילוב מאפיינים אלה עם ro.product.first_api_level
, חבילות בדיקה בוחרות מקרי בדיקה מתאימים עבור המכשירים.
אנדרואיד 13 מגדיר את ro.vendor.api_level
שמוגדר אוטומטית על ידי חישוב רמת ה-API של הספק באמצעות המאפיינים ro.product.first_api_level
, ro.board.first_api_level
ו- ro.board.api_level
.
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 הנוכחית של תמונות הספק עבור SoC. כאשר רמת ה-API של תמונת הספק בעלת ה- ro.board.first_api_level
מתעדכנת, המכשיר המשתמש ב-SoC חייב להגדיר את המאפיין ro.board.api_level
עם רמת ה-API הנוכחית של תמונת הספק במקום לעדכן את ה- ro.board.first_api_level
. אם מאפיין זה אינו מוגדר, ro.board.first_api_level
ישמש כברירת מחדל.
כדי להגדיר את ro.board.api_level
, הגדר BOARD_API_LEVEL
בקובץ device.mk
עם הערך הרצוי.
ro.vendor.api_level
המאפיין ro.vendor.api_level
הוצג באנדרואיד 13 כדי להציג את רמת ה-API שתמונות הספק נדרשות לתמוך בה. זה מוגדר אוטומטית למינימום של ro.board.api_level
(או ro.board.first_api_level
אם ro.board.api_level
לא מוגדר) ו- ro.product.first_api_level
. בדיקות להטמעת ספק הדורשות שדרוג תמונת ספק עשויות להיות חריגות מדרישות הספק עבור ה-SoC על ידי הפניה למאפיין זה.
תהליך פיצול באמצעות VTS
עבור אנדרואיד גרסה 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 לרסיסים ומפעילה אותם במספר מכשירים.