דף זה תורגם על ידי Cloud Translation API.

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 של גרסאות זמינות (לא ניתנות לניפוי באגים), הדגל מופעל כברירת מחדל.

Kotlin

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

Groovy

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

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

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

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

בדיקת ממשק המשתמש של Compose

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

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

לוחצים על הלחצן 'מצב בדיקה של ממשק המשתמש לכתיבה' כדי להפעיל את הבדיקה.

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

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

מצב בדיקה של ממשק המשתמש של Compose מופעל עם פרטים בחלונית הבעיות.

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

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

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

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

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

התבנית הזו מגדירה את הפרויקט כך שיוכל לתמוך בפרופילים בסיסיים. הוא משתמש בפלאגין החדש של Baseline Profiles ל-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 Emulator מגרסה 33.1.10 ואילך
מכשיר וירטואלי של Android שפועל עם API ברמה 24 ואילך

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

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

כדי לאפשר לבדיקה להעביר פקודות למכשיר הבדיקה, מוסיפים את ההרשאות INTERNET ו-ACCESS_NETWORK_STATE לקובץ המניפסט בקבוצת המקור androidTest:
```
  <uses-permission android:name="android.permission.INTERNET" />
  <uses-permission android:name="android.permissions.ACCESS_NETWORK_STATE" />
```
מפעילים את הדגל הניסיוני enableEmulatorControl בקובץ gradle.properties:
```
  android.experimental.androidTest.enableEmulatorControl=true
```

מפעילים את האפשרות emulatorControl בסקריפט ה-build ברמת המודול:

Kotlin

  testOptions {
    emulatorControl {
      enable = true
    }
  }

Groovy

  testOptions {
    emulatorControl {
      enable = true
    }
  }

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

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 יש כמה מצבים של מסך ושל מכשיר מתקפל שאפשר להשתמש בהם כדי לדמות שינויים בהגדרות המכשיר.

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

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

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

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

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

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

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

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

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

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

קודם כול, צריך לבדוק את המכשיר במצב מקופל על ידי קריאה ל-onDevice().setClosedMode(). חשוב לוודא שהפריסה של האפליקציה מתאימה לרוחב המסך הקומפקטי:
```
  @Test
  fun myUnfoldedTest() {
    onDevice().setClosedMode()
    composeTestRule.onNodeWithTag("BottomBar").assetIsDisplayed()
    composeTestRule.onNodeWithTag("NavRail").assetDoesNotExist()
    ...
  }
```

כדי לעבור למצב פתוח לגמרי, צריך להפעיל את הפונקציה 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() {
  ...
}