בפרויקט 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.
- פריט מידע אחד (artifact) שנוצר בתהליך פיתוח
- יומן שקשור ל-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.
- postsubmit test
בדיקה של Android שמתבצעת כשתיקון חדש מחויב להסתעפות ליבה משותפת. מזינים את
aosp_kernel
כחלק משם ההסתעפות כדי לראות רשימה של הסתעפויות של הליבה עם תוצאות זמינות. לדוגמה, התוצאות שלandroid-mainline
זמינות בכתובת https://ci.android.com/builds/branches/aosp_kernel-common-android-mainline/grid.- בדיקה לפני שליחת בקשה
בדיקה שמטרתה למנוע כניסה של כשלים לליבת הליבה המשותפת.
- Trade Federation
נקרא גם Tradefed, מסגרת בדיקה רציפה שמיועדת להרצת בדיקות במכשירי Android. לדוגמה, אפשר להשתמש ב-Tradefed כדי להריץ בדיקות של חבילה לבדיקות תאימות (CTS) ובדיקות של חבילה לבדיקות של ספקים.
- חבילת בדיקות של ספקים (VTS)
קבוצה של יכולות נרחבות לבדיקת Android, שמקדמות תהליך פיתוח מבוסס-בדיקה (TDD) ומאפשרות אוטומציה של בדיקות שכבת ההפשטה של החומרה (HAL) ובדיקות הליבה של מערכת ההפעלה.
סוגי בדיקות הפלטפורמה
בבדיקה של פלטפורמה מתבצעת בדרך כלל אינטראקציה עם אחד או יותר משירותי המערכת או משכבות ה-HAL של Android, מתבצעת בדיקה של הפונקציונליות של הנושא שנבדק ומוודאת התקינות של תוצאת הבדיקה. בדיקת פלטפורמה יכולה:
- (סוג 1) אימון ממשקי API של מסגרת באמצעות מסגרת Android. ממשקי ה-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, קראו את המאמר התשתית ו-Vendor Test Suite (VTS).
לבדיקה של אפליקציות, כדאי לקרוא את המאמר Fundamentals of testing Android apps ולבצע את Advanced Android in Kotlin 05.1:Testing Basics באמצעות הדוגמאות שסופקו.
מידע על הבדיקות הבסיסיות לפני שליחת בקשת תיקון שזמינות לכם באמצעות ה-hooks של המאגר. אפשר להשתמש בהוקים האלה כדי להריץ כלי איתור שגיאות בקוד, לבדוק את הפורמט ולהפעיל בדיקות יחידה לפני שממשיכים, למשל העלאת השמירה. הווקים האלה מושבתים כברירת מחדל. מידע נוסף זמין במאמר AOSP Preupload Hooks.
מידע נוסף על רישום ביומן זמין במאמר הסבר על רישום ביומן.
במאמר ניפוי באגים בקוד של פלטפורמת Android מקומית מוסבר איך לנפות באגים בקוד של Android.