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

אלו תכונות חדשות ב-Android Studio Iguana.

גרסאות תיקון

בהמשך מופיעה רשימה של עדכוני התיקונים ב-Android Studio Iguana ובפלאגין של Android Gradle בגרסה 8.3.

Android Studio Iguana | תיקון 2 לגרסה 2023.2.1 ו-AGP 8.3.2 (אפריל 2024)

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

Android Studio Iguana | תיקון 1 לגרסה 2023.2.1 ו-AGP 8.3.1 (מרץ 2024)

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

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

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

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

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

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

• גרסת Canary האחרונה של Android Studio Iguana
• גרסת האלפא האחרונה של Android Gradle Plugin 8.3
• Crashlytics SDK v18.3.7 (או עץ המוצר (BoM) של Firebase ל-Android v32.0.0)

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

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

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

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

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

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

בדיקת ממשק המשתמש של כתיבת הודעה

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

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

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

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

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

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

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

האשף של מודול Baseline Profiles

החל מ-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 אפשר לדמות את השינויים האלה בהגדרות במכשיר וירטואלי, ולהריץ את הבדיקות באופן סינכרוני, כך שרק פעולה אחת או טענת נכוֹנוּת אחת בממשק המשתמש מתרחשות בכל פעם, ותוצאות הבדיקה אמינות יותר. מידע נוסף על כתיבת בדיקות ממשק משתמש באמצעות Espresso

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

• Android Studio Iguana ואילך
• פלאגין Android Gradle מגרסה 8.3 ואילך
• אמולטור Android 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 בסקריפט ה-build ברמת המודול:

   Kotlin

     testOptions {
       emulatorControl {
         enable = true
       }
     }

   Groovy

     testOptions {
       emulatorControl {
         enable = true
       }
     }

4. בסקריפט ה-build ברמת המודול, מייבאים את הספרייה של מכשירי Espresso לפרויקט:

   Kotlin

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

   Groovy

     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() {
  ...
}