Android Studio Iguana | 2.1.2023 (פברואר 2024)

הרשימה הבאה כוללת תכונות חדשות ב-Android Studio Iguana.

גרסאות תיקון

בהמשך מפורטת רשימה של גרסאות התיקון ב-Android Studio Iguana ובפלאגין Android Gradle 8.3.

‫Android Studio Iguana | 2023.2.1 Patch 2 ו-AGP 8.3.2 (אפריל 2024)

העדכון הקטן הזה כולל תיקוני באגים.

‫Android Studio Iguana | 2023.2.1 Patch 1 ו-AGP 8.3.1 (מרץ 2024)

העדכון הקטן הזה כולל תיקוני באגים.

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

‫Android Studio Iguana כולל את העדכונים של IntelliJ IDEA 2023.2, שמשפרים את חוויית השימוש ב-IDE של Studio. פרטים על השינויים מופיעים בהערות הגרסה של IntelliJ IDEA 2023.2.

שילוב של מערכת לניהול גרסאות בכלי 'תובנות לגבי איכות האפליקציה'

App Quality Insights מאפשר עכשיו לנווט מדוח קריסה של Crashlytics אל הקוד הרלוונטי – בנקודת הזמן שבה הקריסה התרחשה. ‫AGP מצרף נתוני גיבוב של קומיטים ב-git לדוחות קריסה, מה שעוזר ל-Android Studio לנווט לקוד שלכם ולהראות איך הוא היה בגרסה שבה הבעיה התרחשה. כשמעיינים בדוח קריסה בתובנות לגבי איכות האפליקציה, אפשר לעבור לשורת הקוד בצ'ק-אאוט הנוכחי של git או להציג השוואה בין הצ'ק-אאוט הנוכחי לבין הגרסה של בסיס הקוד שיצרה את הקריסה.

כדי לשלב את מערכת בקרת הגרסאות עם App Quality Insights, צריך לעמוד בדרישות המינימום הבאות:

• הגרסה האחרונה של Canary של Android Studio Iguana
• גרסת האלפא האחרונה של Android Gradle Plugin 8.3
• ‫Crashlytics SDK v18.3.7 (או Firebase Android Bill of Materials v32.0.0)

כדי להשתמש בשילוב של בקרת גרסאות לסוג build שניתן לניפוי באגים, צריך להפעיל את הדגל vcsInfo בקובץ ה-build ברמת המודול. בגרסאות (שלא מיועדות לניפוי באגים), הדגל מופעל כברירת מחדל.

android {
  buildTypes {
    getByName("debug") {
      vcsInfo {
        include = true
      }
    }
  }
}

android {
  buildTypes {
    debug {
      vcsInfo {
        include true
      }
    }
  }
}

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

הצגת וריאציות של קריסות ב-Crashlytics בתובנות לגבי איכות האפליקציה

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

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

כדי לעזור למפתחים ליצור ממשקי משתמש נגישים יותר ובעלי יכולת הסתגלות גבוהה יותר ב-Jetpack Compose, הוספנו ל-Android Studio Iguana Canary 5 מצב חדש לבדיקת ממשק המשתמש בתצוגה המקדימה של Compose. התכונה הזו פועלת באופן דומה לבדיקת קוד חזותי ולשילובים של בדיקות נגישות לתצוגות. כשמפעילים את מצב הבדיקה של ממשק המשתמש של Compose, ‏ Android Studio מבצע אוטומטית ביקורת על ממשק המשתמש של Compose ובודק בעיות של התאמה ונגישות בגדלים שונים של מסכים, כמו טקסט שנמתח במסכים גדולים או ניגודיות צבעים נמוכה. במצב הזה מודגשות בעיות שנמצאו בהגדרות שונות של תצוגה מקדימה, והן מפורטות בחלונית הבעיות.

כדי לנסות את התכונה הזו, לוחצים על הלחצן 'בדיקת ממשק המשתמש' בתצוגה המקדימה של הטיוטה ושולחים לנו משוב:

בעיות מוכרות במצב בדיקת ממשק משתמש:

• יכול להיות שהמיקוד יוסר מהבעיה שנבחרה בחלונית הבעיות
• האפשרות 'השבתת כלל' לא פועלת

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

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

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

אשף מודול פרופילי Baseline

החל מ-Android Studio Iguana, אפשר ליצור פרופילים של בסיס לאפליקציה באמצעות תבנית Baseline Profile Generator באשף המודולים החדש (File > New > New Module).

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

התבנית גם יוצרת הגדרת הפעלה שמאפשרת ליצור פרופיל בסיסי בלחיצה אחת מהרשימה הנפתחת Select Run/Debug Configuration (בחירת הגדרת הפעלה/ניפוי באגים).

בדיקה של שינויים בהגדרות באמצעות Espresso Device API

אפשר להשתמש ב-Espresso Device API כדי לבדוק את האפליקציה כשמתבצעים במכשיר שינויים נפוצים בהגדרות, כמו סיבוב ופתיחת המסך. ‫Espresso Device API מאפשר לכם לדמות את השינויים בהגדרות במכשיר וירטואלי, ומבצע את הבדיקות באופן סינכרוני, כך שרק פעולת UI אחת או טענה אחת מתבצעות בכל פעם, ותוצאות הבדיקה מהימנות יותר. מידע נוסף על כתיבת בדיקות של ממשק משתמש באמצעות Espresso

כדי להשתמש ב-Espresso Device API, אתם צריכים:

• ‫Android Studio Iguana או גרסה מתקדמת יותר
• פלאגין Android Gradle מגרסה 8.3 ואילך
• Android Emulator מגרסה 33.1.10 ואילך
• מכשיר וירטואלי של Android עם API ברמה 24 ומעלה

הגדרת הפרויקט ל-Espresso Device API

כדי להגדיר את הפרויקט כך שיתמוך ב-Espresso Device API, מבצעים את הפעולות הבאות:

1. כדי לאפשר לבדיקה להעביר פקודות למכשיר הבדיקה, מוסיפים את ההרשאות INTERNET ו-ACCESS_NETWORK_STATE לקובץ המניפסט בערכת המקור androidTest:

     <uses-permission android:name="android.permission.INTERNET" />
     <uses-permission android:name="android.permissions.ACCESS_NETWORK_STATE" />

2. מפעילים את הדגל הניסיוני enableEmulatorControl בקובץ gradle.properties:

     android.experimental.androidTest.enableEmulatorControl=true

3. מפעילים את האפשרות emulatorControl בסקריפט הבנייה ברמת המודול:

   Kotlin

     testOptions {
       emulatorControl {
         enable = true
       }
     }

   מגניב

     testOptions {
       emulatorControl {
         enable = true
       }
     }

4. בסקריפט הבנייה ברמת המודול, מייבאים את ספריית Espresso Device לפרויקט:

   Kotlin

     dependencies {
       androidTestImplementation("androidx.test.espresso:espresso-device:3.6.1")
     }

   מגניב

     dependencies {
       androidTestImplementation 'androidx.test.espresso:espresso-device:3.6.1'
     }

בדיקה של שינויים נפוצים בהגדרות

ל-Espresso Device API יש כמה מצבים של כיוון המסך ומצבים של מכשירים מתקפלים שבהם אפשר להשתמש כדי לדמות שינויים בהגדרות המכשיר.

בדיקה של סיבוב המסך

דוגמה לבדיקה של מה שקורה לאפליקציה כשמסובבים את מסך המכשיר:

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

     import androidx.test.espresso.device.action.ScreenOrientation
     import androidx.test.espresso.device.rules.ScreenOrientationRule
     ...
     @get:Rule
     val screenOrientationRule: ScreenOrientationRule = ScreenOrientationRule(ScreenOrientation.PORTRAIT)

2. יוצרים בדיקה שמגדירה את המכשיר לתצוגה לרוחב במהלך ההרצה של הבדיקה:

     @Test
     fun myRotationTest() {
       ...
       // Sets the device to landscape orientation during test execution.
       onDevice().setScreenOrientation(ScreenOrientation.LANDSCAPE)
       ...
     }

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

     @Test
     fun myRotationTest() {
       ...
       // Sets the device to landscape orientation during test execution.
       onDevice().setScreenOrientation(ScreenOrientation.LANDSCAPE)
       composeTestRule.onNodeWithTag("NavRail").assertIsDisplayed()
       composeTestRule.onNodeWithTag("BottomBar").assertDoesNotExist()
     }

בדיקה של פתיחת המסך

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

1. קודם כול, צריך לבדוק את המכשיר כשהוא מקופל על ידי התקשרות אל onDevice().setClosedMode(). חשוב לוודא שהפריסה של האפליקציה מותאמת לרוחב המסך הקומפקטי:

     @Test
     fun myUnfoldedTest() {
       onDevice().setClosedMode()
       composeTestRule.onNodeWithTag("BottomBar").assetIsDisplayed()
       composeTestRule.onNodeWithTag("NavRail").assetDoesNotExist()
       ...
     }

2. כדי לעבור למצב פתוח לגמרי, קוראים ל-onDevice().setFlatMode(). בודקים שפריסת האפליקציה מותאמת לגודל המורחב:

     @Test
     fun myUnfoldedTest() {
       onDevice().setClosedMode()
       ...
       onDevice().setFlatMode()
       composeTestRule.onNodeWithTag("NavRail").assertIsDisplayed()
       composeTestRule.onNodeWithTag("BottomBar").assetDoesNotExist()
     }

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

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

לדוגמה, כדי לציין שבדיקה תופעל רק במכשירים שתומכים בפתיחה לתצורה שטוחה, מוסיפים את @RequiresDeviceModeהקוד הבא לבדיקה:

@Test
@RequiresDeviceMode(mode = FLAT)
fun myUnfoldedTest() {
  ...
}