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