במסמך הזה מוסבר על מכשירי 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 נתמכים
כדי להציג את המודלים והממשקי ה-API של AVD שנתמכים על ידי Test Lab, מריצים את הפקודה הבאה:
gcloud firebase test android models list --filter=virtual
שיטות מומלצות לבדיקת האפליקציה
מכשירים וירטואליים מרחיבים את מגוון האפשרויות כשבודקים את האפליקציה באמצעות Test Lab. מומלץ להשתמש בשיטות המומלצות הבאות כדי לבדוק את האפליקציה לאורך מחזור החיים של פיתוח האפליקציה:
שימוש באמולטור של Android Studio או במכשיר פיזי מחובר
במהלך פיתוח האפליקציה, כדאי להשתמש באמולטור של Android Studio או במכשיר פיזי מחובר כדי לבדוק כל גרסת build לצורך אימות ראשוני. אם יש לכם בדיקות אינסטרומנטציה, אתם יכולים להריץ אותן מ-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, ראו ממשקי ABI של Android.
הערה: אם בדיקה במטריצת הבדיקות מסומנת כלא תקפה, יכול להיות שהסיבה לכך היא שהאפליקציה תלויה בקוד מקורי שלא נתמך על ידי ה-ABI של המכשיר. |
| ביצועים גרפיים | מכשירים וירטואליים של Nexus ו-Pixel משתמשים ברינדור גרפי של תוכנה. יכול להיות שהביצועים של אפליקציות עם גרפיקה עשירה יהיו נמוכים יותר. אם האפליקציה שלכם עתירת גרפיקה, מומלץ להשתמש במקום זאת ב-SmallPhone.arm, ב-MediumPhone.arm או במכשירים פיזיים. |
| Graphics APIs | OpenGL ES 3.x לא נתמך במכשירים מתחת לרמת API 29. מכשירים חדשים יותר לא תמיד תואמים באופן מלא לממשקי API של OpenGL/Vulkan, ולכן יכול להיות שתבחינו בהבדלים קלים בגרפיקה. |
| אפליקציית חנות Google Play | אין תמיכה באפליקציית חנות Google Play במכשירים וירטואליים של Arm. |
| פונקציונליות של מציאות רבודה (AR) | אין תמיכה בבדיקת הפונקציונליות של מציאות רבודה (AR) במכשירים וירטואליים. |
| רמות API ישנות יותר | Test Lab מכשירים וירטואליים של Arm לא תומכים ברמות API נמוכות מ-26. |