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