בפרויקט Android Open Source Project (AOSP) יש כמה כלים וחבילות בדיקה לבדיקה של חלקים שונים בהטמעה. לפני השימוש בדפים עליך להכיר את המונחים הבאים:
- מכשיר תואם Android
- מכשיר שיכול להריץ כל אפליקציה של צד שלישי שנכתבה על ידי מפתחים של צד שלישי באמצעות Android SDK ו-NDK. מכשירים שתואמים ל-Android חייבים לפעול בהתאם בדרישות של מסמך הגדרת תאימות (CDD) ומעבירים את חבילה לבדיקת תאימות (CTS). מכשירי Android תואמים עומדים בדרישות להשתתפות בסביבה העסקית של Android, שכוללת רישוי פוטנציאלי של Google Play, רישוי פוטנציאלי של חבילת האפליקציות וממשקי ה-API של Google Mobile Services (GMS) ושימוש במותג Android. כל אחד יכול להשתמש בקוד המקור של Android, אבל כדי להיחשב כחלק מסביבת Android, המכשיר צריך להיות תואם ל-Android.
- ארטיפקט
- יומן שקשור ל-build שמאפשר לפתור בעיות באופן מקומי.
- מסמך הגדרת תאימות (CDD)
- מסמך שמפרט את הדרישות לתוכנה ולחומרה של מכשיר תואם ל-Android.
- חבילה לבדיקת תאימות (CTS)
חבילת בדיקות בחינם ברמה מסחרית, שזמינה להורדה כקובץ בינארי או כקוד מקור ב-AOSP. CTS הוא אוסף של בדיקות יחידה שמיועדות לשילוב בתהליך העבודה היומי שלכם. המטרה של CTS היא לחשוף חוסר תאימות להבטיח שהתוכנה תמשיך להיות תואמת לכל אורך תהליך הפיתוח.
בדיקות CTS ובדיקות פלטפורמה אינן בלעדיות. הנה כמה הנחיות כלליות:
- אם הבדיקה מאשרת את תקינות הפונקציות או ההתנהגויות של ממשק ה-API של המסגרת, וצריכים לאכוף את הבדיקה אצל שותפי OEM, היא צריכה להיכלל ב-CTS.
- אם הבדיקה מיועדת לזהות רגרסיות במהלך פיתוח הפלטפורמה, והם עשויים לדרוש הרשאה בעלת הרשאות כדי לבצע אותם, והם עשויים להיות תלויים בפרטים של ההטמעה (כפי שפורסם ב-AOSP), זו צריכה להיות פלטפורמה לבדיקה.
- Google Mobile Services (GMS)
אוסף של אפליקציות וממשקי API של Google שאפשר להתקין מראש במכשירים.
- GoogleTest (GTest)
מסגרת של C++ לבדיקה ולעג. בדרך כלל קבצים בינאריים של GTest גישה לשכבות הפשטה ברמה נמוכה יותר או ביצוע IPC גולמי מול מערכות שונות שירותים שונים. בדרך כלל, הגישה לבדיקות ב-GTest קשורה מאוד לשירות שנבדק. CTS מכיל את מסגרת GTest.
- בדיקת אינסטרומנטציה
סביבת מיוחדת להרצת בדיקות שמופעל על ידי הפקודה
am instrument, שבה תהליך האפליקציה המטורגט מופעל מחדש ומאותחם עם הקשר בסיסי של האפליקציה, וחווטת הטמעה מתחילה לפעול בתוך המכונה הווירטואלית של תהליך האפליקציה. CTS מכיל בדיקות של מכשירי מדידה.- Logcat
כלי שורת פקודה שיוצר יומן של הודעות מערכת, כולל מעקב סטאק של מקרים שבהם המכשיר גורם לשגיאה והודעות שכתבתם מהאפליקציה באמצעות הכיתה
Log.- logging
שימוש ביומן כדי לעקוב אחרי אירועי מערכת במחשב, כמו בתור שגיאות. ההתחברות ל-Android היא מורכבת בגלל השילוב של התקנים שבהם נעשה שימוש משולבות בכלי Logcat.
- בדיקה לאחר השליחה
בדיקה של Android שמתבצעת כשתיקון חדש מחויב להסתעפות ליבה משותפת. מזינים את
aosp_kernelכחלק משם ההסתעפות כדי לראות רשימה של הסתעפויות של הליבה עם תוצאות זמינות. לדוגמה, תוצאות עבורandroid-mainlineניתן למצוא את https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid.- בדיקה מראש
בדיקה שמשמשת למניעת כשלים במערכת ליבות נפוצות.
- איחוד הסחר
נקרא גם Tradefe, בדיקה רציפה (CD) שמיועד להרצת בדיקות במכשירי Android. לדוגמה, אפשר להשתמש ב-Tradefed כדי להריץ בדיקות של חבילה לבדיקות תאימות (CTS) ובדיקות של חבילה לבדיקות של ספקים.
- חבילת בדיקה של ספקים (VTS)
מערך של יכולות מקיפות עבור בדיקות ב-Android, קידום תהליך פיתוח מבוסס-בדיקות ואוטומציה בדיקת שכבת הפשטה של חומרה (HAL) ובדיקת ליבה של מערכת ההפעלה.
סוגי בדיקות הפלטפורמה
בדרך כלל, בדיקת פלטפורמה מתבצעת באינטראקציה עם אחד או יותר משירותי המערכת או משכבות ה-HAL של Android, מפעילה את הפונקציות של הנושא שנבדק ומאמתת את תקינות התוצאה של הבדיקה. בדיקת פלטפורמה יכולה:
- (סוג 1) הפעלת ממשקי API של framework באמצעות Android framework. ממשקי ה-API הספציפיים שבהם נעשה שימוש יכולים לכלול:
- ממשקי API ציבוריים המיועדים לאפליקציות של צד שלישי
- ממשקי API נסתרים שמיועדים לאפליקציות בעלות הרשאות, כלומר ממשקי API של המערכת או
ממשקי API פרטיים (
@hide, אוprotected,package private)
- (סוג 2) קריאה לשירותי מערכת Android באמצעות שרתי proxy של IPC או שרתי proxy גולמיים של binder ישירות.
- (סוג 3) אינטראקציה ישירה עם HALs באמצעות ממשקי API ברמה נמוכה או ממשקי IPC.
בדיקות מסוג 1 ו-2 הן בדרך כלל בדיקות של מכשירי מדידה, ובדיקות מסוג 3 הן בדרך כלל בדיקות GTest.
מה השלב הבא?
ריכזנו כאן רשימה של מסמכים שאפשר לקרוא כדי לקבל מידע מפורט יותר:
אם עדיין לא חקרת את הארכיטקטורה של Android, כדאי לך לעיין במאמר סקירה כללית של הארכיטקטורה.
אם אתם יוצרים מכשיר תואם ל-Android, כדאי לעיין בסקירה הכללית של תוכנית התאימות של Android.
כדי לשלב בדיקות אינסטרומנטציה, פונקציונליות, מדדים ובדיקות מארח JAR לתוך שירות בדיקה רציף של פלטפורמה, בדיקת תהליך הפיתוח.
במאמר בדיקות אבטחה מוסבר איך לזהות נקודות חולשה במכשירים ולחזק אותם מפניהן.
מידע נוסף על בדיקת הטמעות ה-HAL והליבה זמין במאמר חבילת בדיקה של ספקים (VTS) ותשתיות.
לבדיקה של אפליקציות, כדאי לקרוא את המאמר Fundamentals of testing Android apps ולבצע את Advanced Android in Kotlin 05.1:Testing Basics באמצעות הדוגמאות שסופקו.
מידע על הבדיקות הבסיסיות לפני שליחת בקשת תיקון שזמינות לכם באמצעות ה-hooks של המאגר. אפשר להשתמש בתגי הוּקים האלה כדי להריץ איתור שגיאות בקוד, לבדוק את הפורמט ולהריץ את היחידה בדיקות לפני שממשיכים, למשל העלאת התחייבות. הווקים האלה מושבתים כברירת מחדל. מידע נוסף זמין במאמר AOSP Preupload Hooks.
מידע נוסף על רישום ביומן זמין במאמר הסבר על רישום ביומן.
במאמר ניפוי באגים בקוד של פלטפורמת Android מקומית מוסבר איך לנפות באגים בקוד של Android.