לכל מודול בדיקה חדש חייב להיות קובץ תצורה כדי לכוון את מערכת הבנייה עם מטא נתונים של מודול, תלות בזמן הידור והוראות אריזה. אנדרואיד משתמשת כעת במערכת ה-Soong build עבור תצורת בדיקה פשוטה יותר.
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: ["androidx.test.runner"],
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: ["androidx.test.runner"],
ההגדרה static_libs
מורה למערכת הבנייה לשלב את התוכן של המודולים בעלי השם ב-apk המתקבל של המודול הנוכחי. המשמעות היא שכל מודול בעל שם צפוי לייצר קובץ .jar
, והתוכן שלו ישמש לפתרון הפניות ל-classpath במהלך זמן הקומפילציה, כמו גם שילוב ב-apk שנוצר.
מודול androidx.test.runner
הוא המודול שנבנה מראש עבור ספריית ה-AndroidX Test Runner, הכוללת את רץ המבחן AndroidJUnitRunner
. AndroidJUnitRunner
תומך במסגרת הבדיקה JUnit4 והחליף את InstrumentationTestRunner
באנדרואיד 10. קרא עוד על בדיקת אפליקציות אנדרואיד ב- Test apps on Android .
אם אתה בונה מודול מכשור חדש, אתה תמיד צריך להתחיל עם ספריית androidx.test.runner
בתור רץ המבחן שלך. עץ המקור של הפלטפורמה כולל גם מסגרות בדיקה שימושיות אחרות כמו 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
.
לכל מודול בדיקה חדש חייב להיות קובץ תצורה כדי לכוון את מערכת הבנייה עם מטא נתונים של מודול, תלות בזמן הידור והוראות אריזה. אנדרואיד משתמשת כעת במערכת ה-Soong build עבור תצורת בדיקה פשוטה יותר.
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: ["androidx.test.runner"],
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: ["androidx.test.runner"],
ההגדרה static_libs
מורה למערכת הבנייה לשלב את התוכן של המודולים בעלי השם ב-apk המתקבל של המודול הנוכחי. המשמעות היא שכל מודול בעל שם צפוי לייצר קובץ .jar
, והתוכן שלו ישמש לפתרון הפניות ל-classpath במהלך זמן הקומפילציה, כמו גם שילוב ב-apk שנוצר.
מודול androidx.test.runner
הוא המודול שנבנה מראש עבור ספריית ה-AndroidX Test Runner, הכוללת את רץ המבחן AndroidJUnitRunner
. AndroidJUnitRunner
תומך במסגרת הבדיקה JUnit4 והחליף את InstrumentationTestRunner
באנדרואיד 10. קרא עוד על בדיקת אפליקציות אנדרואיד ב- Test apps on Android .
אם אתה בונה מודול מכשור חדש, אתה תמיד צריך להתחיל עם ספריית androidx.test.runner
בתור רץ המבחן שלך. עץ המקור של הפלטפורמה כולל גם מסגרות בדיקה שימושיות אחרות כמו 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
.
לכל מודול בדיקה חדש חייב להיות קובץ תצורה כדי לכוון את מערכת הבנייה עם מטא נתונים של מודול, תלות בזמן הידור והוראות אריזה. אנדרואיד משתמשת כעת במערכת ה-Soong build עבור תצורת בדיקה פשוטה יותר.
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: ["androidx.test.runner"],
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: ["androidx.test.runner"],
ההגדרה static_libs
מורה למערכת הבנייה לשלב את התוכן של המודולים בעלי השם ב-apk המתקבל של המודול הנוכחי. המשמעות היא שכל מודול בעל שם צפוי לייצר קובץ .jar
, והתוכן שלו ישמש לפתרון הפניות ל-classpath במהלך זמן הקומפילציה, כמו גם שילוב ב-apk שנוצר.
מודול androidx.test.runner
הוא המודול שנבנה מראש עבור ספריית ה-AndroidX Test Runner, הכוללת את רץ המבחן AndroidJUnitRunner
. AndroidJUnitRunner
תומך במסגרת הבדיקה JUnit4 והחליף את InstrumentationTestRunner
באנדרואיד 10. קרא עוד על בדיקת אפליקציות אנדרואיד ב- Test apps on Android .
אם אתה בונה מודול מכשור חדש, אתה תמיד צריך להתחיל עם ספריית androidx.test.runner
בתור רץ המבחן שלך. עץ המקור של הפלטפורמה כולל גם מסגרות בדיקה שימושיות אחרות כמו 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
.