במסגרת פרויקט הקוד הפתוח של Android (AOSP) יש כמה כלים וחבילות בדיקה לבדיקת חלקים שונים בהטמעה. לפני שמשתמשים בדפים שבקטע הזה, כדאי להכיר את המונחים הבאים:
- מכשיר שתואם ל-Android
- מכשיר שיכול להריץ כל אפליקציה של צד שלישי שנכתבה על ידי מפתחים של צד שלישי באמצעות Android SDK ו-NDK. מכשירים שתואמים ל-Android צריכים לעמוד בדרישות של מסמך ההגדרה של תאימות (CDD) ולעבור את חבילת הבדיקות לתאימות (CTS). מכשירים שתואמים ל-Android עומדים בדרישות להשתתפות במערכת האקולוגית של Android, שכוללת רישיון פוטנציאלי לשימוש ב-Google Play, רישיון פוטנציאלי לשימוש בחבילת האפליקציות וממשקי ה-API של שירותי Google לנייד (GMS) ושימוש בסימן המסחרי של Android. כל אחד יכול להשתמש בקוד המקור של Android, אבל כדי שמכשיר ייחשב כחלק ממערכת Android, הוא צריך להיות תואם ל-Android.
- artifact
- יומן שקשור לבנייה ומאפשר פתרון בעיות מקומי.
- מסמך הגדרת התאימות (CDD)
- מסמך שמפרט את דרישות התוכנה והחומרה למכשיר שתואם ל-Android.
- חבילה לבדיקות תאימות (CTS)
חבילת בדיקות חינמית באיכות מסחרית, שזמינה להורדה כקובץ בינארי או כמקור ב-AOSP. CTS הוא אוסף של בדיקות יחידה שנועדו להשתלב בתהליך העבודה היומיומי שלכם. מטרת CTS היא לחשוף חוסר תאימות, ולוודא שהתוכנה תישאר תואמת לאורך תהליך הפיתוח.
בדיקות CTS ובדיקות פלטפורמה לא סותרות זו את זו. הנה כמה הנחיות כלליות:
- אם בדיקה מאמתת את התקינות של פונקציות או התנהגויות של ממשקי API של מסגרת, והבדיקה צריכה להיות מחייבת אצל שותפי OEM, היא צריכה להיות ב-CTS.
- אם המטרה של הבדיקה היא לזהות רגרסיות במהלך פיתוח הפלטפורמה, יכול להיות שיידרשו הרשאות מיוחדות כדי לבצע אותה, ויכול להיות שהיא תהיה תלויה בפרטי ההטמעה (כפי שפורסמו ב-AOSP), אז היא צריכה להיות בדיקת פלטפורמה.
- שירותי Google לנייד (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.- בדיקה לפני שליחה
בדיקה שמשמשת למניעת כשלים בקרנלים הנפוצים.
- Trade Federation
נקרא גם Tradefed, מסגרת לבדיקות רציפות שנועדה להרצת בדיקות במכשירי Android. לדוגמה, Tradefed משמש להרצת בדיקות של חבילת בדיקות התאימות (CTS) וחבילת בדיקות הספק (VTS).
- חבילת בדיקות לספקים (VTS)
סט של יכולות נרחבות לבדיקות ב-Android, לקידום תהליך פיתוח מבוסס-בדיקות ולאוטומציה של בדיקות בשכבת הפשטת החומרה (HAL) ובליבת מערכת ההפעלה.
סוגי בדיקות בפלטפורמה
בדיקת פלטפורמה בדרך כלל מקיימת אינטראקציה עם שירות אחד או יותר של מערכת Android או עם שכבות HAL, מפעילה את הפונקציות של הנושא שנבדק ומאמתת את התוצאה של הבדיקה. בדיקה בפלטפורמה יכולה:
- (Type 1) שימוש בממשקי API של framework באמצעות Android framework. ממשקי API ספציפיים שנעשה בהם שימוש יכולים לכלול:
- ממשקי API ציבוריים שמיועדים לאפליקציות של צד שלישי
- ממשקי API מוסתרים שמיועדים לאפליקציות עם הרשאות, כלומר ממשקי API של המערכת או ממשקי API פרטיים (
@hideאוprotectedאוpackage private)
- (Type 2) הפעלה של שירותי מערכת Android באמצעות binder גולמי או שרתי proxy של IPC באופן ישיר.
- (Type 3) אינטראקציה ישירה עם HAL באמצעות ממשקי API ברמה נמוכה או ממשקי IPC.
בדרך כלל בדיקות מסוג 1 ו-2 הן בדיקות מכשור, ובדיקות מסוג 3 הן בדרך כלל GTests.
מה השלב הבא?
למידע מפורט יותר, אפשר לקרוא את המסמכים הבאים:
אם לא למדתם על ארכיטקטורת Android, כדאי לעיין במאמר סקירה כללית על ארכיטקטורה.
אם אתם יוצרים מכשיר שתואם ל-Android, כדאי לעיין בסקירה הכללית של תוכנית התאימות של Android.
כדי לשלב בדיקות אינסטרומנטציה, בדיקות פונקציונליות, בדיקות מדדים ובדיקות של מארח JAR בשירות בדיקות רציף של פלטפורמה, אפשר לעיין במאמר בנושא תהליך העבודה של פיתוח בדיקות.
כדי לזהות נקודות חולשה במכשירים ולחזק אותם מפני פגיעות, אפשר לעיין במאמר בנושא בדיקות אבטחה.
מידע על בדיקת ההטמעות של HAL ושל ליבת המערכת זמין במאמר בנושא חבילת בדיקות הספקים (VTS) והתשתית.
לצורך בדיקת אפליקציות, כדאי לקרוא את המאמר Fundamentals of testing Android apps (יסודות הבדיקה של אפליקציות ל-Android) ולעבור על Advanced Android in Kotlin 05.1: Testing Basics (Android מתקדם ב-Kotlin 05.1: יסודות הבדיקה) באמצעות הדוגמאות שמופיעות בו.
מידע על בדיקות בסיסיות לפני שליחה שזמינות לכם דרך repo hooks. אפשר להשתמש ב-hooks האלה כדי להריץ כלי לינט, לבדוק עיצוב ולהפעיל בדיקות יחידה לפני שממשיכים, למשל לפני העלאת קומיט. ה-hooks האלה מושבתים כברירת מחדל. מידע נוסף מפורט במאמר בנושא AOSP Preupload Hooks.
מידע נוסף על רישום ביומן זמין במאמר הסבר על רישום ביומן.
כדי להבין איך לנפות באגים בקוד Android, אפשר לעיין במאמר בנושא ניפוי באגים בקוד של פלטפורמת Android Native.