הגדרת build פשוטה

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

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

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

דוגמה

הערכים שבהמשך מגיעים מקובץ התצורה של תוכנית ה-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 למודול, כדי שתוכלו להשתמש ב-make [options] <HelloWorldTests> כדי ליצור את מודול הבדיקה ואת כל התלות שלו.

    static_libs: ["androidx.test.runner"],

ההגדרה static_libs מורה למערכת הבנייה לשלב את התוכן של המודולים שצוינו בחבילת ה-APK שמתקבלת של המודול הנוכחי. המשמעות היא שכל מודול בעל שם אמור ליצור קובץ .jar, והתוכן שלו ישמש לפתרון הפניות לנתיב המחלקה בזמן ההידור, וגם ישולב בקובץ ה-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 מורה למערכת הבנייה לחתום על ה-APK עם אותו אישור כמו פלטפורמת הליבה. ההרשאה הזו נדרשת אם הבדיקה משתמשת בהרשאה או בממשק API שמוגנים בחתימה. הערה: הפתרון הזה מתאים לבדיקות רציפות של פלטפורמות, אבל לא לשימוש במודולים של בדיקות CTS. שימו לב שההגדרה הזו של האישור משמשת בדוגמה רק לצורך המחשה: קוד הבדיקה בדוגמה לא צריך בעצם שקובץ ה-APK של הבדיקה ייחתם באמצעות אישור הפלטפורמה המיוחד.

אם אתם כותבים כלי למדידת ביצועים עבור רכיב שנמצא מחוץ לשרת המערכת, כלומר, הוא ארוז בערך כמו קובץ APK של אפליקציה רגילה, אבל הוא מוטמע בתמונת המערכת ויכול להיות שהוא אפליקציה עם הרשאות מיוחדות, סביר להניח שהכלי למדידת הביצועים יכוון לחבילת האפליקציה (ראו את הקטע בהמשך על מניפסט) של הרכיב. במקרה כזה, יכול להיות שלקובץ ה-makefile של האפליקציה יש הגדרה משלו של certificate, ומודול המדידה צריך לשמור על אותה הגדרה. הסיבה לכך היא שכדי לטרגט את המכשור באפליקציה שנבדקת, קובץ ה-APK של הבדיקה וקובץ ה-APK של האפליקציה צריכים להיות חתומים באותו אישור.

במקרים אחרים, אין צורך בהגדרה הזו בכלל: מערכת ה-build פשוט תחתום על האפליקציה באמצעות אישור מובנה שמוגדר כברירת מחדל, על סמך וריאציית ה-build, והוא נקרא בדרך כלל dev-keys.

    test_suites: ["device-tests"],

ההגדרה test_suites מאפשרת למערכת Trade Federation test harness לגלות את הבדיקה בקלות. אפשר להוסיף כאן חבילות אחרות כמו 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 מורה למערכת הבנייה להוסיף את RootTargetPreparer להגדרת הבדיקה שנוצרת באופן אוטומטי. כך מובטח שהבדיקה תפעל עם הרשאות root.

    test_min_api_level: 29

ההגדרה test_min_api_level מורה למערכת ה-build להוסיף את MinApiLevelModuleController להגדרת הבדיקה שנוצרת אוטומטית. כש-Trade Federation מריץ את הגדרת הבדיקה, הבדיקה תדלג אם מאפיין המכשיר של ro.product.first_api_level < test_min_api_level.