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

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

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

גרסאות של תיקונים

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

Android Studio Iguana | 2023.2.1 תיקון 2 ו-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.

שילוב של מערכת בקרת גרסאות ב-App Quality Insights

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

כדי לשלב את המערכת לניהול גרסאות עם 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
      }
    }
  }
}

מגניב

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אשף המודול של פרופילים בסיסיים

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

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

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

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

אפשר להשתמש ב-Espresso Device API כדי לבדוק את האפליקציה כשהמכשיר עובר בעיות נפוצות שינויים בתצורה, כגון סיבוב ופריסת מסך. האספרסו Device API מאפשר לדמות את שינויי ההגדרות האלה במכשיר וירטואלי מפעיל את הבדיקות באופן סינכרוני, כך שרק פעולה אחת בממשק המשתמש או טענת נכוֹנוּת (assertion) מתרחשת זמן מסוים, ותוצאות הבדיקה מהימנות יותר. מידע נוסף על כתיבה בדיקות ממשק משתמש עם Espresso.

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

Android Studio Iguana ואילך
פלאגין Android Gradle מגרסה 8.3 ואילך
אמולטור Android 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
    }
  }

מגניב

  testOptions {
    emulatorControl {
      enable = true
    }
  }

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

Kotlin

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

מגניב

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