תצורת בנייה פשוטה

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