לכל מודול בדיקה חדש חייב להיות קובץ תצורה כדי לכוון את מערכת ה-build עם מטא-נתונים של המודול, יחסי תלות בזמן הידור והוראות אריזה. עכשיו Android משתמש במערכת ה-build של Soong, להגדרות האישיות לבדיקה.
ב-Songg משתמשים ב-Bluprint או בקובצי .bp
, שהם הצהרות פשוטות דמויי JSON
תיאורים של מודולים לבנייה. הפורמט הזה מחליף את המודל שמבוסס על יצרן
שהיו בשימוש בגרסאות קודמות. לקובצי העזר של Soong
בלוח הבקרה של אינטגרציה רציפה (CI) תוכלו למצוא פרטים מלאים.
כדי לאפשר בדיקה מותאמת אישית, או להשתמש חבילת בדיקת התאימות של Android (CTS), מעקב הגדרות אישיות של בדיקה מורכבת במקום זאת.
דוגמה
הערכים שבהמשך מגיעים מקובץ התצורה לדוגמה של תוכנית העיצוב: /platform_testing/tests/example/instrumentation/Android.bp
צירפנו כאן קובץ snapshot לנוחותכם:
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
חשוב לשים לב שההצהרה android_test
שמופיעה בהתחלה מציינת שמדובר בבדיקה.
לעומת זאת, הוספה של android_app
תציין שמדובר ב-build
חבילה.
הגדרות
ההגדרות הבאות מספקות הסבר:
name: "HelloWorldTests",
ההגדרה name
נדרשת כשמציינים את סוג המודול android_test
(בתחילת החסימה). הוא נותן שם למודול,
שם ה-APK יהיה זהה עם סיומת .apk
, למשל במקרה הזה,
כתוצאה מכך, ה-APK של הבדיקה נקרא HelloWorldTests.apk
. בנוסף,
מגדיר שם יעד למודול, כדי שתוכלו להשתמש ב-make [options]
<HelloWorldTests>
כדי לבנות את מודול הבדיקה ואת כל יחסי התלות שלו.
static_libs: ["androidx.test.runner"],
ההגדרה static_libs
מורה למערכת ה-build לשלב את התוכן
של המודולים בעלי השם לתוך ה-APK שמתקבל של המודול הנוכחי. המשמעות היא
כל מודול בעל שם צפוי להפיק קובץ .jar
, והתוכן שלו
משמשות לפתרון הפניות classpath במהלך זמן הידור (compile), וגם
משולב ב-APK שמתקבל.
המודול androidx.test.runner
הוא ה-build מראש של ספריית AndroidX Test Runner, שכוללת את מפעיל הבדיקות AndroidJUnitRunner
.
AndroidJUnitRunner
תומך במסגרת הבדיקה JUnit4 והחליף את InstrumentationTestRunner
ב-Android 10. עוד פרטים
מידע על בדיקת אפליקציות ל-Android במאמר בדיקת אפליקציות ב-Android.
אם אתם בונים מודול מדידה חדש, תמיד צריך להתחיל ב-
את הספרייה androidx.test.runner
בתור הרצת הבדיקה. עץ המקור של הפלטפורמה
כולל גם מסגרות בדיקה שימושיות אחרות, כמו ub-uiautomator
,
mockito-target
, easymock
ועוד.
certificate: "platform",
ההגדרה certificate
מורה למערכת ה-build לחתום על ה-APK באמצעות אותה
כפלטפורמה המרכזית. הפעולה הזו נדרשת אם הבדיקה שלך משתמשת בחתימה
בהרשאה מוגנת או ב-API. חשוב לשים לב: ההגדרה הזו מתאימה לרציפות בפלטפורמה.
אבל לא להיות בשימוש במודולים של בדיקות CTS. שימו לב שהדוגמה הזו
משתמש בהגדרת האישור הזו רק לצורך ההמחשה: קוד הבדיקה.
מהדוגמה לא נדרשת חתימה על ה-APK של הבדיקה
אישור מיוחד לפלטפורמה.
אם אתם כותבים כלי נגינה עבור הרכיב שלכם שנמצא מחוץ ל-
שרת מערכת, כלומר, הוא ארוז פחות או יותר כמו APK רגיל של אפליקציה,
מלבד העובדה שהיא מובנית בתמונת המערכת ועשויה להיות אפליקציה בעלת הרשאות, סביר להניח
הם שההגדרות שלכם יטרגטו את חבילת האפליקציה (פרטים בהמשך)
של הרכיב שלך. במקרה הזה, הבקשה
ל-makefile יש הגדרת certificate
משלו, והאינסטרומנטציה שלך
של המודול צריך להישאר ללא שינוי. הסיבה לכך היא שטירגוט
התיוג באפליקציה בבדיקה, ה-APK וה-APK של האפליקציה חייבים להיות חתומים
בעלי אותו אישור.
במקרים אחרים, אתם לא צריכים את ההגדרה הזו בכלל: מערכת ה-build
תחתום עליו באמצעות אישור מובנה בברירת מחדל, בהתבסס על
ובדרך כלל נקרא dev-keys
.
test_suites: ["device-tests"],
בעזרת ההגדרה test_suites
, העסק יכול למצוא את הבדיקה בקלות
רתמות הבדיקה של Federation. אפשר להוסיף כאן סוויטות אחרות, כמו CTS, כדי
עשויה לשתף את הבדיקה.
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
הגדרות אופציונליות
הסבר על ההגדרות האופציונליות הבאות:
test_config: "path/to/hello_world_test.xml"
ההגדרה test_config
מנחה את מערכת ה-build שיעד הבדיקה שלך צריך
. כברירת מחדל, AndroidTest.xml
ליד Android.bp
הוא
שמשויך להגדרה.
auto_gen_config: true
ההגדרה auto_gen_config
מציינת אם ליצור את הגדרת הבדיקה או לא
באופן אוטומטי. אם השדה AndroidTest.xml
לא קיים ליד Android.bp
,
אין צורך להגדיר את המאפיין כ-TRUE באופן מפורש.
require_root: true
ההגדרה require_root
מנחה את מערכת ה-build להוסיף את RootTargetPreparer
להגדרת הבדיקה שנוצרה אוטומטית. כך מובטח שהבדיקה תפעל עם הרשאות root.
test_min_api_level: 29
ההגדרה test_min_api_level
מורה למערכת ה-build להוסיף
MinApiLevelModuleController להגדרת הבדיקה שנוצרה באופן אוטומטי. בזמן עסקה
האיחוד מריץ את הגדרת הבדיקה, המערכת תדלג על הבדיקה אם מאפיין המכשיר
מתוך ro.product.first_api_level
< test_min_api_level
.