במסמך הזה מתוארים מכשירי AVD ל-Test Lab, כולל היתרונות והמגבלות הידועות. אנחנו גם מספקים המלצות לגבי בדיקת האפליקציה לאורך מחזור החיים של הפיתוח. מכשירי AVD ל-Test Lab דומים למכשירי AVD ל-Android Studio, אבל הם מותאמים לביצועים בבדיקות בענן, ולכן יש כמה הבדלים ביניהם.
Test Lab AVDs עם הסיומת .arm או (Arm) הם אמולטורים מתקדמים שמספקים את היתרונות הבאים:
זמן ביצוע בדיקה מהיר יותר
גדלים ודחיסויות של מסכים שתואמים למכשירי AVD ב-Android Studio, כדי לשמור על עקביות
גרפיקה מואצת נתמכת ב-GPU
בטבלה הבאה מתוארים היתרונות של שימוש במכשירים וירטואליים:
| הטבה | תיאור | תרחישים לדוגמה |
| זמינות גבוהה | כשבודקים באמצעות מכשירים וירטואליים, אפשר להריץ בדיקות ולקבל תוצאות בדיקה מהר יותר. מכיוון שמכשירים וירטואליים נוצרים לפי דרישה, הבדיקות מתחילות כמעט מיד, ומספקות אימות מהיר של האפליקציה. | בדיקת עדכונים קטנים באפליקציה או בדיקת רגרסיה. |
| משכי בדיקה ארוכים יותר | מכשירים וירטואליים תומכים במשך בדיקה של עד 60 דקות. בדיקות במכשירים פיזיים מוגבלות למשך בדיקה של 45 דקות בכל מכשיר. | הפעלת בדיקות ארוכות יותר |
| עלויות נמוכות יותר | התמחור של מכשירים וירטואליים הוא 1 $לשעה לכל מכשיר וירטואלי שמשמש לבדיקת האפליקציה. | בדיקות יומיות באמצעות מערכות אינטגרציה רציפה, או לפני ביצוע צ'ק-אין של קוד. מידע נוסף מופיע במאמר בנושא רמות שימוש, מכסות ומחירים של 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.
הערה: אם בדיקה במטריצת הבדיקות מסומנת כלא תקינה, יכול להיות שהסיבה לכך היא שהאפליקציה תלויה בקוד Native שלא נתמך על ידי ממשק ה-ABI של המכשיר. |
| ביצועים גרפיים | מכשירים וירטואליים של Nexus ו-Pixel משתמשים ברינדור גרפי של תוכנה. יכול להיות שהביצועים של אפליקציות עם גרפיקה עשירה יהיו נמוכים יותר. אם האפליקציה שלכם דורשת הרבה משאבים גרפיים, מומלץ להשתמש במקום זאת ב-SmallPhone.arm, ב-MediumPhone.arm או במכשירים פיזיים. |
| Graphics APIs | OpenGL ES 3.x לא נתמך במכשירים מתחת לרמת API 29. מכשירים חדשים יותר לא תואמים באופן מלא לממשקי OpenGL/Vulkan API, ויכול להיות שתבחינו בהבדלים קטנים בגרפיקה. |
| אפליקציית חנות Google Play | אין תמיכה באפליקציית חנות Google Play במכשירים וירטואליים של Arm. |
| פונקציונליות של מציאות רבודה (AR) | אין תמיכה בבדיקה של פונקציונליות המציאות הרבודה (AR) במכשירים וירטואליים. |
| רמות API ישנות יותר | Test Lab מכשירים וירטואליים של Arm לא תומכים ברמות API נמוכות מ-26. |