תצורת build פשוטה

לכל מודול בדיקה חדש חייב להיות קובץ תצורה כדי לכוון את מערכת ה-build עם מטא-נתונים של המודול, יחסי תלות בזמן הידור והוראות אריזה. עכשיו Android משתמש במערכת ה-build של Soong, להגדרות האישיות לבדיקה.

ב-Songg משתמשים ב-Bluprint או בקובצי .bp, שהם הצהרות פשוטות דמויי JSON תיאורים של מודולים לבנייה. הפורמט הזה מחליף את המודל שמבוסס על יצרן שהיו בשימוש בגרסאות קודמות. לקובצי העזר של Soong בלוח הבקרה של אינטגרציה רציפה (CI) תוכלו למצוא פרטים מלאים.

כדי לאפשר בדיקה מותאמת אישית, או להשתמש חבילת בדיקת התאימות של Android (CTS), מעקב הגדרות אישיות של בדיקה מורכבת במקום זאת.

דוגמה

הערכים שבהמשך מגיעים מקובץ התצורה לדוגמה של תוכנית העיצוב: /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 תציין שמדובר ב-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 בנוי מראש ל-AndroidX Test Runner ספרייה, שכוללת את סשן הבדיקה AndroidJUnitRunner. פלטפורמת AndroidJUnitRunner תומכת ב-framework של בדיקת 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.