במסמך הזה מתוארים מכשירי AVD ל-Test Lab, כולל יתרונות ומגבלות ידועות. אנחנו גם מספקים המלצות לבדיקת האפליקציה לאורך מחזור החיים של הפיתוח. Test Lab מכשירי AVD דומים למכשירי AVD ל-Android Studio, אבל הם מותאמים לביצועים עם בדיקות בענן, ולכן יש כמה הבדלים בין השניים.
Test Lab מכשירי AVD עם הסיומת .arm או (Arm) הם אמולטורים מתקדמים שמספקים את היתרונות הבאים:
זמן ביצוע בדיקה מהיר יותר
גדלים וצפיפויות של מסכים שתואמים למכשירי ה-AVD של Android Studio, כדי לשמור על עקביות
גרפיקה מואצת שנתמכת על ידי GPU
בטבלה הבאה מפורטים היתרונות של שימוש במכשירים וירטואליים:
| יתרונות | תיאור | תרחישי שימוש |
| זמינות גבוהה | כשמבצעים בדיקות במכשירים וירטואליים, אפשר להריץ את הבדיקות ולקבל את התוצאות מהר יותר. מכשירים וירטואליים נוצרים לפי דרישה, ולכן הבדיקות מתחילות כמעט מיד ומאפשרות לאמת את האפליקציה במהירות. | בדיקת עדכונים קטנים באפליקציה או בדיקת רגרסיה. |
| משך בדיקה ארוך יותר | במכשירים וירטואליים אפשר להריץ בדיקות באורך של עד 60 דקות. בדיקות במכשירים פיזיים מוגבלות למשך בדיקה של 45 דקות בכל מכשיר. | הרצת בדיקות ארוכות יותר |
| עלויות נמוכות יותר | המחיר של מכשירים וירטואליים הוא דולר אחד לשעה לכל מכשיר וירטואלי שמשמש לבדיקת האפליקציה. | בדיקות יומיות באמצעות מערכות אינטגרציה רציפה (CI), או לפני בדיקת הקוד. מידע נוסף זמין במאמר רמות שימוש, מכסות ותמחור של Test Lab. |
בדיקת האפליקציה באמצעות מכשירים וירטואליים
אתם יכולים לבדוק את האפליקציה במכשירים וירטואליים באותו אופן שבו אתם בודקים אותה במכשירים פיזיים. כשמגדירים מטריצת בדיקה, אפשר לבחור מכשירים וירטואליים לבדיקות. מידע נוסף על הרצת בדיקות באמצעות Test Lab זמין במאמר תחילת העבודה עם בדיקות ל-Android באמצעות Firebase Test Lab.
הצגת המודלים וממשקי ה-API הנתמכים
כדי לראות את המודלים של AVD וממשקי ה-API שנתמכים על ידי Test Lab, מריצים את הפקודה הבאה:
gcloud firebase test android models list --filter=virtual
שיטות מומלצות לבדיקת האפליקציה
מכשירים וירטואליים מגדילים את מגוון האפשרויות לבדיקת האפליקציה באמצעות Test Lab. מומלץ להשתמש בשיטות המומלצות הבאות כדי לבדוק את האפליקציה לאורך מחזור החיים של פיתוח האפליקציה:
שימוש באמולטור של Android Studio או במכשיר פיזי מחובר
כשמפתחים את האפליקציה, משתמשים באמולטור של Android Studio או במכשיר פיזי מחובר כדי לבדוק כל גרסה לצורך אימות ראשוני. אם יש לכם בדיקות אינסטרומנטציה, אתם יכולים להריץ אותן מ-Android Studio במכשירים פיזיים או וירטואליים שסופקו על ידי Test Lab.
כשעובדים על פרויקטים משותפים, כדאי להשתמש במערכות CI בכל שינוי בקוד
אם אתם עובדים על פרויקט גדול, או אם אתם תורמים לפרויקטים שמשותפים באמצעות GitHub או אתר דומה, מומלץ להשתמש במערכות שילוב רציף (CI). בודקים את האפליקציות במכשירים וירטואליים בכל פעם שמערכת ה-CI פועלת, או לפני כל בקשת משיכה. מידע נוסף על השימוש ב-Test Lab עם מערכות CI זמין במאמר שימוש ב-Test Lab ל-Android עם מערכות שילוב רציף.
לפני שמפרסמים עדכונים משמעותיים לאפליקציה, כדאי לבדוק אותה במכשירים פיזיים באמצעות Test Lab
לפני שאתם משיקים עדכונים לאפליקציה עם שינויים משמעותיים בממשק המשתמש ובפונקציונליות, מומלץ להשתמש ב-Test Lab כדי לבדוק את האפליקציה במכשירים פיזיים. כך תוכלו לוודא שהאפליקציה יציבה ופועלת היטב במגוון רחב של מכשירים פיזיים פופולריים. בדיקה במכשירים פיזיים גם מבטיחה כיסוי בדיקה עבור כל תכונות האפליקציה שמסתמכות על תכונות של מכשירים פיזיים שלא מדומים על ידי מכשירים וירטואליים. מידע נוסף על התכונות האלה מופיע בקטע מגבלות ידועות.
עדכונים למכשירים וירטואליים
מדי פעם, צוות Android מוסיף קובצי אימג' חדשים של מכשירים וירטואליים, מוציא משימוש קבצים ישנים ומעדכן קבצים קיימים. אנחנו מחילים את העדכונים האלה על קובצי האימג' של המכשירים הווירטואליים כדי לוודא שאתם בודקים את האפליקציה בגרסאות עדכניות של Android שמשקפות את חוויות המשתמשים.
במקרים נדירים, העדכונים האלה עלולים לגרום לבדיקות להיכשל באופן בלתי צפוי. אם יש עדכון ידוע שעלול לגרום לשיבושים, Test Lab יכלול מידע בנתוני הגרסה. מומלץ להשתמש במסגרות בדיקה – לדוגמה, Espresso – שעמידות לשינויים האלה ככל האפשר. אם זה לא אפשרי, מומלץ לטרגט מכשירים וירטואליים של Arm, שמתעדכנים בתדירות נמוכה יותר.
מגבלות ידועות
חלק מהתכונות של המכשיר הפיזי לא מדומות כרגע על ידי מכשירים וירטואליים, או שהן מדומות עם מגבלות מסוימות. בטבלה הבאה מפורטות התכונות שלא זמינות כרגע במכשירים וירטואליים, או שזמינות עם מגבלות מסוימות:
| Feature | לפרטים |
| ממשקי Application Binary Interface (ABI) | לא כל המכשירים תומכים בכל ממשקי ה-ABI. אם אתם מפתחים עם Android NDK, הקפידו ליצור קוד עבור ה-ABI הנתמכים על ידי המכשירים שאתם מכוונים אליהם (ראו מכשירים זמינים ב-Test Lab). למידע נוסף על ניהול ABI, ראו ABIs של Android.
הערה: אם בדיקה במטריצת הבדיקה מסומנת כלא חוקית, יכול להיות שהסיבה לכך היא שהאפליקציה תלויה בקוד Native שלא נתמך על ידי ה-ABI של המכשיר. |
| ביצועי הגרפיקה | מכשירים וירטואליים של Nexus ו-Pixel משתמשים ברינדור גרפיקה של תוכנה. אפליקציות שדורשות משאבים גרפיים רבים עלולות לפעול לאט יותר. אם האפליקציה שלך דורשת משאבים גרפיים רבים, כדאי להשתמש במקום זאת ב-SmallPhone.arm, ב-MediumPhone.arm או במכשירים פיזיים. |
| ממשקי API לגרפיקה | OpenGL ES 3.x לא נתמך במכשירים עם רמת API נמוכה מ-29. מכשירים חדשים יותר לא תואמים ב-100% לממשקי ה-API של OpenGL או Vulkan, ויכול להיות שיהיו הבדלים קלים בגרפיקה. |
| אפליקציית חנות Google Play | האפליקציה של חנות Google Play לא נתמכת במכשירים וירטואליים של Arm. |
| פונקציונליות של מציאות רבודה (AR) | אי אפשר לבדוק את הפונקציונליות של המציאות הרבודה (AR) במכשירים וירטואליים. |
| רמות API ישנות יותר | Test Lab מכשירים וירטואליים של Arm לא תומכים ברמות API נמוכות מ-26. |