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