קיפוד Android Studio | 1.1.2023 (נובמבר 2023)

בהמשך מפורטות תכונות חדשות ב-Android Studio Hdgehog.

עדכון לפלטפורמה של IntelliJ IDEA 2023.1

מכשירי Android Studio Hdgehog כוללים את עדכוני IntelliJ IDEA 2023.1, שמשפרים את הביצועים של Studio IDE. כדי לקבל פרטים על השינויים, אפשר לעיין במאמר בנושא נתוני הגרסה של IntelliJ IDEA 2023.1.

ניתוח תפקוד האפליקציה ב'תובנות לגבי איכות האפליקציה'

תובנות לגבי איכות האפליקציות כוללות עכשיו נתוני תפקוד האפליקציה, כדי שאפשר יהיה לגשת אליהם בקלות רבה יותר מדדים עיקריים שנאספים על ידי Google Play ומשפרים את חוויית המשתמש. כדאי להשתמש תפקוד האפליקציה לטיפול בבעיות שקשורות ליציבות האפליקציה כדי לעזור לשפר את של איכות האפליקציה ב-Google Play.

אפשר לראות את הבעיות בתפקוד האפליקציה, לסנן אותן ולעבור מדוח הקריסות אל הכול מהחלון של הכלי תובנות לגבי איכות האפליקציה. כדי להתחיל, צריך לפעול לפי את השלבים הבאים:

  1. נכנסים לחשבון הפיתוח ב-Android Studio באמצעות סמל הפרופיל זהה בסוף סרגל הכלים.
  2. לפתוח את תובנות לגבי איכות האפליקציה על ידי לחיצה על חלון הכלי Android Studio או לחיצה על תצוגה > Windows בכלי > תובנות לגבי איכות האפליקציה.
  3. לוחצים על הכרטיסייה תפקוד האפליקציה בתוך תובנות לגבי איכות האפליקציה.

מספרים שונים בין תפקוד האפליקציה ל-Crashlytics

לתשומת ליבכם: המדדים 'תפקוד האפליקציה' ו-Crashlytics עשויים לדווח על ערכים שונים עבור מספר המשתמשים והאירועים שמשויכים לאותה קריסה. פערים בנתונים קורה כי Play ו-Crashlytics יכולות לאתר קריסות בזמנים שונים, משתמשים שונים. יש כמה סיבות לכך ש-Play ו-Crashlytics המספרים עשויים להיות שונים:

  • משחקים ב-Play משיגים קריסות החל מזמן האתחול, ו-Crashlytics תופס קריסות קריסות שמתרחשות אחרי הפעלה של Crashlytics SDK.
  • אם משתמש מבטל את הסכמתו לדיווח על קריסות כשהוא מקבל טלפון חדש, הקריסות האלה לא ידווחו ל-Play. עם זאת, Crashlytics מזהה קריסות על סמך מדיניות פרטיות משלו.

כלי חדש לניתוח עוצמתי

החל מגרסת Android Studio Hdgehog, ה-Power Profiler מציג את צריכת החשמל במכשירים. אפשר לצפות בנתונים החדשים האלה ב-On Device Power Rails Monitor (ODPM). ה-ODPM מפלח את הנתונים לפי מערכות משנה שנקראות Power Rails. למידע נוסף על מסילות כוח שניתן ליצור פרופיל לרשימה של מערכות משנה נתמכות.

מעקב המערכת מתעדת ומציגה נתוני צריכת חשמל. הוא חלק מכלי לניתוח ביצועי ה-CPU. הנתונים האלה עוזרים לכם לבצע קורלציה חזותית של הכוח צריכה של המכשיר עם הפעולות המתרחשות בתוך האפליקציה שלך. הכלי לניתוח ביצועים מאפשר להציג את הנתונים האלה באופן חזותי.

הכלי החדש ל-Power Profiler

כדי להציג את הנתונים מהכלי החדש ל-Power Profiler, יש לעקוב אחר נתוני המערכת במכשיר Pixel 6 ואילך המכשיר:

  1. בוחרים באפשרות תצוגה > Windows בכלי > הכלי לניתוח ביצועים.
  2. לוחצים במקום כלשהו בציר הזמן של ה-CPU כדי לפתוח את הכלי לניתוח ביצועי ה-CPU. להתחיל מעקב מערכת.

הכלי החדש לקישורי אפליקציות מספק סקירה כללית מקיפה של קישורי העומק שהוגדר באפליקציה. ה-Assistant מציג את כל קישורי העומק הקיימים AndroidManifest.xml, מוודא שההגדרות של ההגדרות העמוקות האלה נכון, ומספק דרך מהירה לתקן ותצורה שגויה.

כדי לפתוח את ה-Assistant עם קישורים לאפליקציות, עוברים אל כלים > App Links ל-Assistant ב- ב-Android Studio. למידע נוסף על קישורים לאפליקציות: הוספת קישורים לאפליקציות ל-Android.

קיצור דרך מעודכן למצב הידני עם התכונה 'עריכה בזמן אמת'

עריכה בזמן אמת ב-Android Studio Hdgehog כולל קיצור דרך חדש למצב ידני (דחיפה ידנית): Control+\ (Command+\ ב-macOS). מצב ידני מועיל במצבים שבהם רוצים לשלוט בצורה מדויקת על זמני העדכונים נפרסה באפליקציה שפועלת. לדוגמה, אם אתם יוצרים כמות גדולה מסוימים בקובץ ואתם לא רוצים שמצב הביניים ישתקף במכשיר. אפשר לבחור בין דחיפה ידנית או דחיפה ידנית בשמירה. בהגדרות של 'עריכה בזמן אמת' או באמצעות האינדיקטור של ממשק המשתמש של 'עריכה בזמן אמת'. לקבלת מידע נוסף מידע נוסף, זמין בקליפ בעריכה בזמן אמת ב-Jetpack פיתוח נייטיב.

יצירת תבניות של כמה תצוגות מקדימות

androidx.compose.ui:ui-tooling-preview מגרסה 1.6.0-alpha01 ואילך משיקה Multipreview API תבניות: @PreviewScreenSizes, @PreviewFontScales, @PreviewLightDark, ו-@PreviewDynamicColors, כך שבעזרת הערה אחת אפשר לצפות בתצוגה מקדימה של ממשק הכתיבה בתרחישים נפוצים.

ב-Android Studio Hdgehog, הושק מצב 'גלריה' חדש תצוגה מקדימה של הכתיבה, שמאפשרת להתמקד בתצוגה מקדימה אחת בכל פעם לחסוך במשאבים בעיבוד. מומלץ להשתמש במצב גלריה כשצריך לבצע איטרציה בממשק המשתמש של האפליקציה ולעבור למצבים אחרים, לדוגמה 'רשת' או 'רשימה', כשצריך לראות וריאנטים של ממשק המשתמש.

כתיבת מידע על המצב בכלי לניפוי באגים

כשחלקים בממשק המשתמש של 'כתיבה' נוצרים מחדש באופן בלתי צפוי, לפעמים קשה כדי להבין למה. עכשיו, כשמגדירים נקודת עצירה בפונקציה קומפוזבילית, debugger מפרט את הפרמטרים של התוכן הקומפוזבילי כך שתוכל לזהות בקלות רבה יותר אילו שינויים גרמו חיבור מחדש. לדוגמה, כשאתם משהים תוכן קומפוזבילי, הכלי לניפוי באגים יכול להראות לכם בדיוק אילו פרמטרים השתנו או נשארו 'ללא שינוי', כדי שתוכלו לחקור ביעילות רבה יותר את הגורם להרכבת מחדש.

שיקוף מסך

עכשיו ניתן לשקף את המכשיר הפיזי שלך בחלון מכשירים פועלים בתוך ב-Android Studio. מבצעים סטרימינג של תצוגת המכשיר ישירות אל Android Studio, אפשר לבצע פעולות נפוצות כמו הפעלת אפליקציות ואינטראקציה איתן, סיבוב המסך, קיפול ופתיחה של הטלפון, שינוי עוצמת הקול ישירות מתוך סביבת הפיתוח המשולבת (IDE) של Studio.

תמיד אפשר לסנכרן בענן ובמחשב מכשירים שמחוברים אל מחשב שמופעל בו ניפוי באגים ב-USB או אלחוטי. אפשר להתחיל ולהפסיק שיקוף באמצעות החלון מכשירים שפועלים או מנהל המכשירים (תצוגה > Windows בכלי > מנהל המכשירים). אפשר גם להתאים אישית את ההפעלה של שיקוף המסך במכשיר (הגדרות > כלים > שיקוף מכשיר).

ממשק המשתמש של המכשירים שפועלים

בעיות מוכרות

ייתכן שבמכשירים מסוימים אין אפשרות לקודד בקצב העברת נתונים שמספיק כדי לתמוך שיקוף מסך. במצבים אלה, ייתכן שתופיע שגיאה בשדה ריצה חלון מכשירים וכן יומנים שדומים לאלה שמוצגים בהמשך.

2023-06-01 15:32:22,675 [  56094]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - Too many video encoder errors:
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - encoder: c2.android.vp8.encoder
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - mime type: video/x-vnd.on2.vp8
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - max resolution: 640x640
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - min resolution: 2x2
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - alignment: 2x2
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - max frame rate: 960
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - max frame rate for 288x640: 960
2023-06-01 15:32:22,870 [  56289]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - max bitrate: 20000000
2023-06-01 15:32:22,871 [  56290]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - terminated with code 1

הודעת פרטיות

בהתאם להגדרות של סנכרון בענן ובמחשב במכשיר, Android Studio יכול להתחיל אוטומטית שיקוף מסך של כל מכשיר מחובר ומותאם. כתוצאה מכך, גילוי נאות לגבי מכשירים שמחוברים לפקודה adb tcpip כי המידע והפקודות המשקפים מועברים דרך . כמו כן, מערכת Android Studio משתמשת בערוץ לא מוצפן כדי לתקשר עם שרת ה-adb, כך שמשתמשים אחרים יוכלו ליירט מידע שתומך בענן ובמחשב במכונה המארחת שלכם.

העברת קלט באמצעות חומרה

עכשיו אפשר להפעיל העברה שקופה של מקורות הקלט של החומרה בתחנות העבודה, כמו העכבר והמקלדת, למכשיר פיזי ווירטואלי שמחובר. שפת תרגום כדי להפעיל העברה שקופה, לוחצים על קלט חומרה. עבור מכשיר היעד בחלון מכשירים פועלים.

ניהול מכשירים ישירות מהחלון 'מכשירים פועלים'

עכשיו אפשר להפעיל מכשיר וירטואלי של Android (AVD) או להתחיל לסנכרן בענן ובמחשב מהמכשיר הפיזי, ישירות מהחלון מכשירים פועלים על ידי לחיצה על הסמל + ובחירת מכשיר. כדי להפסיק את ה-AVD או את השיקוף של נכס פיזי במכשיר, סוגרים את כרטיסיית המכשיר.

תפריט נפתח של המכשיר 'מכשירים פועלים'

הכלי לבדיקת פריסות מוטמעות

החל מגרסת Android Studio Hdgehog Canary 2, אפשר להריץ בודק הפריסה ישירות חלון הכלי מכשירים פעילים. התכונה הניסיונית הזו שומרת על שלמות המסך וגם עוזר לארגן את תהליך העבודה של ניפוי הבאגים בממשק המשתמש בחלון כלי יחיד. לחשבון במצב מוטמע, אפשר להציג היררכיית תצוגה, לבדוק את המאפיינים של כל ולגשת לתכונות נפוצות אחרות של 'בודק הפריסה'. כדי לגשת לקבוצה המלאה עדיין צריך להריץ את 'מפקח הפריסה' בחלון נפרד (קובץ > הגדרות > ניסיוני > מפקח פריסה ב-Windows או Android Studio > הגדרות > ניסיוני > הכלי לבדיקת פריסות ב-macOS).

מגבלה של מפקח הפריסה המוטמע היא מצב תלת-ממד זמין רק קובצי snapshot.

כדי לעזור לנו לשפר את 'בודק הפריסה' המוטמע, יש לשלוח אלינו משוב.

שיפורים חדשים בממשק המשתמש

ממשק משתמש חדש ל-Android Studio משפרים את המראה והסגנון של Studio סביבת פיתוח משולבת (IDE). קיבלנו את המשוב שלך עד עכשיו ופתרנו את הבעיות שקשורות אל את התכונות הבאות ב-Android Studio Hdgehog:

  • מצב קומפקטי
  • תמיכה בפיצול אנכי או אופקי
  • כרטיסיות פרויקט ב-macOS
  • תיקונים למצב 'ללא הסחות דעת'
  • הגדרות מתקדמות כך שתמיד יוצגו פעולות בחלון הכלים

עדכונים בכלי לשדרוג SDK

הכלי לשדרוג SDK מספק של האשף, שלב אחר שלב, שיעזור לך targetSdkVersion שדרוגים. אלו העדכונים ל'עוזר הדיגיטלי לשדרוג SDK' ב-Android Studio קיפוד:

  • הצגת שינויי תוכנה שעלולים לגרום לכשל בשדרוג ל-Android 14
  • הוספנו מסנני רלוונטיות כדי להסיר כמה שלבים מיותרים
  • לגבי שינויים מסוימים, עליך לציין את המיקום המדויק בקוד שבו צריך להופיע נוצרה

השבתת האופטימיזציה של ה-build לרמת ה-API לטירגוט בלבד

עכשיו אפשר להשבית אופטימיזציה של סביבת פיתוח משולבת (IDE) ברמת ה-API של מכשיר היעד. על ידי כברירת מחדל, מערכת Android Studio מקצרת את זמן ה-build הכולל על ידי התאמה של הקוד ברמת ה-API של מכשיר היעד שבו מבצעים את הפריסה. כדי להפעיל את ההגדרה את התכונה מושבתת, עוברים אל File > הגדרות > ניסיוני (Android Studio > הגדרות > ניסיוני ב-macOS) ומבטלים את הסימון של האפשרות Optimize build for target (אופטימיזציה של build ליעד) ברמת ה-API של המכשיר בלבד. חשוב לזכור שהשבתת האופטימיזציה של ה-build הזו עשויה לגרום להאריך את זמן ה-build.

[Windows בלבד] צמצום ההשפעה של תוכנת אנטי-וירוס על מהירות ה-build

Build Analyzer מאפשר לך לדעת אם תוכנת אנטי-וירוס משפיעה על ה-build שלך או של ביצועים. דבר זה עלול לקרות אם תוכנת אנטי-וירוס, כמו Windows Defender, מבצעת סריקה בזמן אמת של הספריות שמשמשות את Gradle. כלי לניתוח נתונים ממליץ על רשימה של ספריות שלא ייכללו בסריקה הפעילה וגם אם אפשר, הוא מציע קישור להוספתם ל-Windows Defender רשימת ההחרגות של תיקיות.

אין יותר תמיכה בפרויקטים של Eclipse Android Development Tool

מכשיר Android Studio Hdgehog ואילך לא תומך בייבוא של Eclipse ADT פרויקטים. עדיין יש לך אפשרות לפתוח את הפרויקטים האלה, אבל הם כבר לא זוהו כפרויקטים של Android. אם צריך לייבא פרויקט מהסוג הזה אתם יכולים להשתמש בגרסה קודמת של Android Studio. אם גרסת Android מסוימת ל-Studio אין אפשרות לייבא את הפרויקט שלך, אפשר לנסות באמצעות את הגרסה הקודמת. אחרי שהפרויקט מומר לפרויקט Android באמצעות בגרסה הקודמת של Android Studio, אפשר להשתמש בכלי השדרוג ל-AGP כדי לעבוד בפרויקט הזה באמצעות הגרסה האחרונה של Android Studio.

שימוש במכשירי Firebase Test Lab עם מכשירים שמנוהלים על ידי Gradle

כשמשתמשים ב-AGP 8.2.0-alpha03 ואילך, ניתן להפעיל את המכשירים האוטומטיים בדיקות בקנה מידה נרחב מכשירי Firebase Test Lab מתי באמצעות מכשירים שמנוהלים על ידי Gradle. מעבדת בדיקה מאפשר להריץ בדיקות בו-זמנית במגוון רחב של מכשירי Android, פיזי ווירטואלי. הבדיקות האלה פועלות במרכזי נתונים מרוחקים של Google. ב- תמיכה ממכשירים שמנוהלים על ידי Gradle (GMD), עכשיו מערכת ה-build יכולה לנהל באופן מלא הרצת בדיקות במכשירים האלה של Test Lab על סמך ההגדרות בקובצי Gradle של הפרויקט.

תחילת העבודה עם מכשירי Firebase Test Lab שמנוהלים על ידי Gradle

השלבים הבאים מתארים איך להתחיל להשתמש במכשירים של Firebase Test Lab עם GMD. שימו לב שהשלבים האלה משתמשים ב-CLI של gcloud כדי לספק את פרטי הכניסה של משתמשים, ייתכן שלא יחולו על כל סביבות הפיתוח. כדי לקבל מידע נוסף על לתהליך האימות המתאים לצרכים שלכם, הסבר על Application Default Credentials

  1. כדי ליצור פרויקט Firebase, נכנסים אל מסוף Firebase. לוחצים על מוסיפים פרויקט ופועלים לפי ההוראות במסך כדי ליצור פרויקט. חשוב לזכור את מזהה הפרויקט.

  2. כדי להתקין את Google Cloud CLI, פועלים לפי השלבים הבאים: להתקין את ה-CLI של gcloud.
  3. מגדירים את הסביבה המקומית.
    1. קישור לפרויקט Firebase ב-gcloud: 
        gcloud config set project FIREBASE_PROJECT_ID

    2. אישור השימוש בפרטי הכניסה של המשתמש לצורך גישה ל-API. ההמלצות שלנו באמצעות העברה קובץ JSON של חשבון שירות ב-Gradle באמצעות DSL בסקריפט ה-build ברמת המודול:

      Kotlin

        firebaseTestLab {
    ...
    serviceAccountCredentials.set(file(SERVICE_ACCOUNT_JSON_FILE))
  }

      מגניב

        firebaseTestLab {
    ...
    serviceAccountCredentials = file(SERVICE_ACCOUNT_JSON_FILE)
  }

      לחלופין, אפשר לאשר ידנית באמצעות המסוף הבא הפקודה:

        gcloud auth application-default login

    3. אופציונלי: מוסיפים את פרויקט Firebase כפרויקט למכסה. השלב הזה הוא נדרש רק אם חורגים מכסה ללא עלות ל-Test Lab. 

        gcloud auth application-default set-quota-project FIREBASE_PROJECT_ID

  4. הפעלת ממשקי ה-API הנדרשים.

    ב בדף ספריית ה-API של Google Developers Console, להפעיל את Cloud Testing API וגם ממשק Cloud Tool Results API על ידי הקלדת שמות ממשקי ה-API בתיבת החיפוש שבחלק העליון של המסוף, ואז לוחצים על Enable API בדף הסקירה הכללית של כל API.

  5. מגדירים את פרויקט Android.

    1. מוסיפים את הפלאגין של Firebase Test Lab לסקריפט ה-build ברמה העליונה:

      Kotlin

        plugins {
    ...
    id("com.google.firebase.testlab") version "0.0.1-alpha05" apply false
  }

      מגניב

        plugins {
    ...
    id 'com.google.firebase.testlab' version '0.0.1-alpha05' apply false
  }

    2. מפעילים סוגי מכשירים מותאמים אישית בקובץ gradle.properties:

        android.experimental.testOptions.managedDevices.customDevice=true

    3. מוסיפים את הפלאגין של Firebase Test Lab לסקריפט ה-build ברמת המודול:

      Kotlin

        plugins {
    ...
    id "com.google.firebase.testlab"
  }

      מגניב

        plugins {
    ...
    id 'com.google.firebase.testlab'
  }

    יצירה והרצה של בדיקות במכשיר Firebase Test Lab שמנוהל על ידי Gradle

    אפשר להגדיר ל-Gradle מכשיר ב-Firebase Test Lab שישמש לבדיקה בסקריפט ה-build ברמת המודול. דוגמת הקוד הבאה יוצרת מכשיר Pixel 3 עם רמת API 30 המנוהל על ידי Gradle, שנקרא מכשיר Test Lab בניהול Gradle ftlDevice החסימה של firebaseTestLab {} זמינה כשמחילים את com.google.firebase.testlab למודול שלך. המינימום הנתמך גרסת הפלאגין של Android Gradle היא 8.2.0-alpha01.

    Kotlin

    firebaseTestLab {
  managedDevices {
    create("ftlDevice") {
      device = "Pixel3"
      apiLevel = 30
    }
  }
  ...
}

    מגניב

    firebaseTestLab {
  managedDevices {
    ftlDevice {
      device = "Pixel3"
      apiLevel = 30
    }
  }
  ...
}

    כדי להריץ את הבדיקות באמצעות מכשירי Test Lab שמנוהלים על ידי Gradle, צריך להשתמש את הפקודה הבאה. device-name הוא שם המכשיר שהגדרת בו סקריפט ה-build של Gradle, כמו ftlDevice ו-BuildVariant הוא ה-build של האפליקציה שרוצים לבדוק. שימו לב ש-Gradle לא מריץ בדיקות מקבילות או תומכות בהגדרות אישיות אחרות של Google Cloud CLI למכשירי Test Lab.

    ב-Windows:

    gradlew device-nameBuildVariantAndroidTest

    ב-Linux או ב-macOS:

    ./gradlew device-nameBuildVariantAndroidTest

    פלט הבדיקה כולל נתיב לקובץ HTML שמכיל את דוח הבדיקה. שלך יכול גם לייבא תוצאות בדיקה ל-Android Studio לניתוח נוסף על ידי לחיצה על הפעלה > היסטוריית בדיקות בסביבת הפיתוח המשולבת (IDE).

    יצירה והרצה של בדיקות בקבוצת מכשירים

    כדי לבצע בדיקות בקנה מידה נרחב, צריך להוסיף מספר מכשירים של Firebase Test Lab שמנוהלים על ידי Gradle קבוצת מכשירים ואז להריץ בדיקות על כולם בפקודה אחת. להגיד מספר מכשירים שמוגדרים כך:

    firebaseTestLab {
  managedDevices {
    create("GalaxyS23Ultra") { ... }
    create("GalaxyZFlip3") { ... }
    create("GalaxyZFold3") { ... }
    create("GalaxyTabS2") { ... }
  }
}

    כדי להוסיף אותם לקבוצת מכשירים בשם samsungGalaxy, צריך להשתמש בבלוק groups {}:

    firebaseTestLab {
  managedDevices {...}
}

android {
  ...
  testOptions {
    managedDevices {
      groups {
        create("samsungGalaxy") {
          targetDevices.add(devices["GalaxyS23Ultra"])
          targetDevices.add(devices["GalaxyZFlip3"])
          targetDevices.add(devices["GalaxyZFold3"])
          targetDevices.add(devices["GalaxyTabS3"])
        }
      }
    }
  }
}

    כדי להריץ בדיקות בכל המכשירים בקבוצת המכשירים, משתמשים בפקודה הבאה:

    ב-Windows:

    gradlew group-nameGroupBuildVariantAndroidTest

    ב-Linux או ב-macOS:

    ./gradlew group-nameGroupBuildVariantAndroidTest

    אופטימיזציה של הרצת הבדיקות באמצעות חלוקה חכמה

    בדיקות במכשירי Test Lab שמנוהלים על ידי Gradle תומכות עכשיו בחלוקה חכמה. חכמה חלוקה לפיצולים, תפיץ באופן אוטומטי את הבדיקות בין פיצולים, כך שכל פיצול פועל למשך זמן זהה בערך, וכך מפחית את מאמצי ההקצאה הידנית משך הזמן הכולל של הרצת הבדיקה. פיצול חכם מתבסס על היסטוריית הבדיקות או על המידע שלכם כמה זמן נמשכה הרצת הבדיקות בעבר, כדי להפיץ את הבדיקות בדרך אופטימלית. לתשומת ליבכם: גרסה 0.0.1-alpha05 של הפלאגין Gradle כדי לאפשר שימוש בפיצול חכם ב-Firebase Test Lab.

    כדי להפעיל פיצול חכם, יש לציין את משך הזמן לבדיקות בכל פיצול מה צריך לקחת. צריך להגדיר את יעד הזמן המפוצל של היעד לחמישה לפחות דקות פחות מ-timeoutMinutes כדי למנוע את המצב של פיצולים הבדיקות יבוטלו לפני שהבדיקות יסתיימו.

    firebaseTestLab {
  ...
  testOptions {
    targetedShardDurationMinutes = 2
  }
}

    למידע נוסף, אפשר לקרוא על האפשרויות החדשות של DSL.

    DSL מעודכן למכשירי Firebase Test Lab בניהול Gradle

    יש עוד אפשרויות DSL שאפשר להגדיר כדי להתאים אישית את הרצת הבדיקות או לעבור מפתרונות אחרים שאולי אתם כבר משתמשים בהם. הצגת כמה מהאפשרויות האלה כפי שמתואר בקטע הקוד הבא.

    firebaseTestLab {
  ...

  /**
   * A path to a JSON file that contains service account credentials to access to
   * a Firebase Test Lab project.
   */
  serviceAccountCredentials.set(file("your_service_account_credentials.json"))


  testOptions {
    fixture {
      /**
       * Whether to grant permissions on the device before tests begin.
       * Available options are "all" or "none".
       *
       * Default value is "all".
       */
      grantedPermissions = "all"

      /**
       * Map of files to push to the device before starting the test.
       *
       * The key is the location on the device.
       * The value is the location of the file, either local or in Google Cloud.
       */
      extraDeviceFiles["/sdcard/dir1/file1.txt"] = "local/file.txt"
      extraDeviceFiles["/sdcard/dir2/file2.txt"] = "gs://bucket/file.jpg"

      /**
       * The name of the network traffic profile.
       *
       * Specifies network conditions to emulate when running tests.
       *
       * Default value is empty.
       */
      networkProfile = "LTE"
    }

    execution {
      /**
       * The maximum time to run the test execution before cancellation,
       * measured in minutes. Does not include the setup or teardown of device,
       * and is handled server-side.
       *
       * The maximum possible testing time is 45 minutes on physical devices
       * and 60 minutes on virtual devices.
       *
       * Defaults to 15 minutes.
       */
       timeoutMinutes = 30

      /**
       * Number of times the test should be rerun if tests fail.
       * The number of times a test execution should be retried if one
       * or more of its test cases fail.
       *
       * The max number of times is 10.
       *
       * The default number of times is 0.
       */
      maxTestReruns = 2

      /**
       * Ensures only a single attempt is made for each execution if
       * an infrastructure issue occurs. This doesn't affect `maxTestReruns`.
       * Normally, two or more attempts are made by Firebase Test Lab if a
       * potential infrastructure issue is detected. This is best enabled for
       * latency sensitive workloads. The number of execution failures might be
       * significantly greater with `failFast` enabled.
       *
       * Defaults to false.
       */
      failFast = false

      /**
       * The number of shards to split the tests across.
       * 
       * Default to 0 for no sharding.
       */
      numUniformShards = 20

      /**
      * For smart sharding, the target length of time each shard should takes in
      * minutes. Maxes out at 50 shards for physical devices and 100 shards for
      * virtual devices.
      *
      * Only one of numUniformShards or targetedShardDurationMinutes can be set.
      *
      * Defaults to 0 for no smart sharding.
      */
      targetedShardDurationMinutes = 15
    }

    results {
      /**
       * The name of the Google storage bucket to store the test results in.
       *
       * If left unspecified, the default bucket is used.
       *
       * Please refer to Firebase Test Lab permissions for required permissions
       * for using the bucket.
       */
      cloudStorageBucket = "bucketLocationName"

      /**
       * Name of test results for the Firebase console history list.
       * All tests results with the same history name are grouped
       * together in the Firebase console in a time-ordered test history list.
       *
       * Defaults to the application label in the APK manifest in Flank/Fladle.
       */
      resultsHistoryName = "application-history"

      /**
       * List of paths to copy from the test device's storage to the test
       * results folder. These must be absolute paths under /sdcard or
       * /data/local/tmp.
       */
      directoriesToPull.addAll(
        "/sdcard/path/to/something"
      )

      /**
       * Whether to enable video recording during the test.
       *
       * Disabled by default.
       */
      recordVideo = false

      /**
       * Whether to enable performance metrics. If enabled, monitors and records
       * performance metrics such as CPU, memory, and network usage.
       *
       * Defaults to false.
       */
      performanceMetrics = true
    }
  }
}