במסמך הזה מתוארים מכשירי AVD ל-Test Lab, כולל יתרונות ומגבלות ידועות. אנחנו גם מספקים המלצות לבדיקת האפליקציה לאורך מחזור החיים של הפיתוח. מכשירי ה-AVD ב-Test Lab דומים ל-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 או במכשיר פיזי מחובר כדי לבדוק כל גרסת build לצורך אימות ראשוני. אם יש לכם בדיקות אינסטרומנטציה, אתם יכולים להריץ אותן מ-Android Studio במכשירים פיזיים או וירטואליים שסופקו על ידי Test Lab.
כשעובדים על פרויקטים משותפים, כדאי להשתמש במערכות CI בכל שינוי בקוד
אם אתם עובדים על פרויקט גדול, או אם אתם תורמים לפרויקטים שמשותפים באמצעות GitHub או אתר דומה, מומלץ להשתמש במערכות של שילוב רציף (CI). בודקים את האפליקציות במכשירים וירטואליים בכל פעם שמערכת ה-CI פועלת, או לפני כל בקשת משיכה. מידע נוסף על השימוש ב-Test Lab עם מערכות CI זמין במאמר שימוש ב-Test Lab ל-Android עם מערכות אינטגרציה רציפה.
לפני שמפרסמים עדכונים משמעותיים לאפליקציה, כדאי לבדוק אותה במכשירים פיזיים באמצעות Test Lab
לפני שאתם משיקים עדכונים לאפליקציה עם שינויים משמעותיים בממשק המשתמש ובפונקציונליות, מומלץ להשתמש ב-Test Lab כדי לבדוק את האפליקציה במכשירים פיזיים. כך תוכלו לוודא שהאפליקציה יציבה ופועלת היטב במגוון רחב של מכשירים פיזיים פופולריים. בדיקה במכשירים פיזיים גם מבטיחה כיסוי של בדיקות לכל תכונות האפליקציה שמסתמכת על תכונות של מכשירים פיזיים שלא מדומים על ידי מכשירים וירטואליים. מידע נוסף על התכונות האלה מופיע בקטע מגבלות ידועות.
עדכונים של מכשירים וירטואליים
מדי פעם, צוות Android מוסיף קובצי אימג' חדשים של מכשירים וירטואליים, מוציא משימוש קבצים ישנים ומעדכן קבצים קיימים. אנחנו מיישמים את העדכונים האלה בתמונות של המכשירים הווירטואליים כדי לוודא שאתם בודקים את האפליקציה בגרסאות עדכניות של Android שמשקפות את חוויית המשתמשים.
במקרים נדירים, העדכונים האלה עלולים לגרום לבדיקות להיכשל באופן בלתי צפוי. כשיש עדכון ידוע שעלול לגרום לבעיות, Test Lab יכלול מידע בנתוני הגרסה. מומלץ להשתמש ב-frameworks לבדיקות, כמו Espresso, שמתאימות לשינויים האלה כשאפשר. אם זה לא אפשרי, מומלץ לטרגט מכשירים וירטואליים של Arm, שמתעדכנים בתדירות נמוכה יותר.
מגבלות ידועות
חלק מהתכונות של המכשיר הפיזי לא מדומות כרגע על ידי מכשירים וירטואליים, או שהן מדומות עם מגבלות מסוימות. בטבלה הבאה מפורטות התכונות שלא זמינות כרגע במכשירים וירטואליים, או שזמינות עם מגבלות מסוימות:
| Feature | לפרטים |
| ממשקי Application Binary Interface (ABI) | לא כל המכשירים תומכים בכל ממשקי ה-ABI. אם אתם מפתחים באמצעות Android NDK, הקפידו ליצור קוד לממשקי ה-ABI שנתמכים במכשירים שאתם מטרגטים (ראו מכשירים זמינים ב-Test Lab). למידע נוסף על ניהול ממשקי ABI, ראו ממשקי ABI של 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. |