Android Studio Iguana | 2023.2.1 (Feb. 2024)

Im Folgenden finden Sie eine Liste der neuen Funktionen in Android Studio Iguana.

Patch-Releases

Im Folgenden finden Sie eine Liste der Patch-Releases in Android Studio Iguana und dem Android Gradle-Plug-in 8.3.

Android Studio Iguana | Patch 2 2023.2.1 und AGP 8.3.2 (April 2024)

Dieses kleinere Update enthält diese Fehlerkorrekturen.

Android Studio Iguana | 2023.2.1 Patch 1 und AGP 8.3.1 (März 2024)

Dieses kleinere Update enthält diese Fehlerkorrekturen.

IntelliJ IDEA 2023.2-Plattformupdate

Android Studio Iguana enthält die IntelliJ IDEA 2023.2-Updates, die die Studio IDE verbessern. Weitere Informationen zu den Änderungen finden Sie in den Versionshinweisen zu IntelliJ IDEA 2023.2.

Integration des Versionskontrollsystems in App Quality Insights

In App Quality Insights können Sie jetzt von einem Crashlytics-Stack-Trace zum relevanten Code springen – und zwar genau zu dem Zeitpunkt, zu dem der Absturz aufgetreten ist. AGP fügt Absturzberichten Git-Commit-Hash-Daten hinzu. So kann Android Studio Ihren Code aufrufen und anzeigen, wie er in der Version war, in der das Problem aufgetreten ist. Wenn Sie einen Absturzbericht in App Quality Insights aufrufen, können Sie zur Codezeile im aktuellen Git-Bezahlvorgang wechseln oder einen Unterschied zwischen dem aktuellen Bezahlvorgang und der Version Ihrer Codebasis, die den Absturz generiert hat, ansehen.

Damit Sie Ihr Versionskontrollsystem in App Quality Insights einbinden können, müssen die folgenden Mindestanforderungen erfüllt sein:

Wenn Sie die Versionskontroll-Integration für einen debuggbaren Buildtyp verwenden möchten, aktivieren Sie das Flag vcsInfo in der Builddatei auf Modulebene. Für Release-Builds (nicht debuggbare Builds) ist das Flag standardmäßig aktiviert.

Kotlin

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

Groovy

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

Wenn Sie Ihre App jetzt erstellen und bei Google Play veröffentlichen, enthalten Absturzberichte die Daten, die die IDE benötigt, um über den Stack-Trace Verknüpfungen zu früheren Versionen Ihrer App herzustellen.

Crashlytics-Absturzvarianten in App Quality Insights ansehen

Damit Sie die Ursachen eines Absturzes leichter analysieren können, können Sie sich Ereignisse mit App Quality Insights nach Problemvarianten oder Gruppen von Ereignissen mit ähnlichen Stacktraces ansehen. Wenn Sie Ereignisse in jeder Variante eines Absturzberichts ansehen möchten, wählen Sie eine Variante aus dem Drop-down-Menü aus. Wenn Sie Informationen für alle Varianten aggregieren möchten, wählen Sie Alle aus.

UI-Prüfung erstellen

Damit Entwickler adaptivere und zugänglichere UIs in Jetpack Compose erstellen können, wurde für Android Studio Iguana Canary 5 in der Compose-Vorschau ein neuer UI Check-Modus eingeführt. Diese Funktion funktioniert ähnlich wie visuelles Linting und Integrationen für die Barrierefreiheit für Ansichten. Wenn Sie den Modus „Compose UI Check“ aktivieren, prüft Android Studio automatisch Ihre Editor-UI und prüft, ob es Probleme mit der Anpassung oder Barrierefreiheit bei verschiedenen Bildschirmgrößen gibt, z. B. auf großen Bildschirmen gestreckter Text oder niedrigen Farbkontrast. Der Modus hebt Probleme hervor, die in verschiedenen Vorschaukonfigurationen gefunden wurden, und listet sie im Problembereich auf.

Probieren Sie diese Funktion gleich aus. Klicken Sie dazu in der Vorschau der Mitteilung auf die Schaltfläche „UI-Prüfung“ und senden Sie uns Ihr Feedback:

Klicken Sie auf die Schaltfläche „Compose UI Check mode“ (Modus für die Überprüfung der Benutzeroberfläche), um die Überprüfung zu aktivieren.

Bekannte Probleme des UI Check-Modus:

  • Der Fokus wird möglicherweise nicht mehr auf das ausgewählte Problem im Bereich „Probleme“ gelegt.
  • „Regel unterdrücken“ funktioniert nicht
Der Modus „UI-Check erstellen“ ist aktiviert und im Bereich „Probleme“ sind Details zu sehen.

Progressives Rendering für die Compose-Vorschau

In Android Studio Iguana Canary 3 wird das progressive Rendering in der Compose-Vorschau eingeführt. Wir arbeiten kontinuierlich daran, die Leistung von Vorschaubildern zu verbessern. Deshalb wird die Renderqualität von Vorschaubildern, die nicht sichtbar sind, jetzt bewusst reduziert, um den Arbeitsspeicher zu schonen.

Mit dieser Funktion soll die Nutzerfreundlichkeit von Vorschauen weiter verbessert werden, da in einer Datei mehr Vorschauen gleichzeitig verarbeitet werden können. Probieren Sie es noch heute aus und senden Sie uns Ihr Feedback.

Assistent für das Modul „Baseline-Profile“

Ab Android Studio Iguana können Sie Baseline-Profile für Ihre App mit der Vorlage Baseline Profile Generator im Assistenten für neue Module erstellen (File > New > New Module).

Mit dieser Vorlage wird Ihr Projekt so eingerichtet, dass es Baseline-Profile unterstützt. Dabei wird das neue Gradle-Plug-in für Baseline-Profile verwendet, das die Einrichtung Ihres Projekts mit einer einzigen Gradle-Aufgabe automatisiert.

Mit der Vorlage wird auch eine Ausführungskonfiguration erstellt, mit der Sie über die Drop-down-Liste Ausführungs-/Debug-Konfiguration auswählen mit nur einem Klick ein Baseline-Profil generieren können.

Mit der Espresso Device API auf Konfigurationsänderungen testen

Verwenden Sie die Espresso Device API, um Ihre App zu testen, wenn das Gerät häufige Konfigurationsänderungen durchläuft, z. B. Drehung und Entfalten des Displays. Mit der Espresso Device API können Sie diese Konfigurationsänderungen auf einem virtuellen Gerät simulieren und Ihre Tests synchron ausführen. So wird immer nur eine UI-Aktion oder -Bestätigung ausgeführt und Ihre Testergebnisse sind zuverlässiger. Weitere Informationen zum Erstellen von UI-Tests mit Espresso

Für die Verwendung der Espresso Device API benötigen Sie Folgendes:

  • Android Studio Iguana oder höher
  • Android Gradle-Plug-in 8.3 oder höher
  • Android-Emulator 33.1.10 oder höher
  • Virtuelles Android-Gerät mit API-Level 24 oder höher

Projekt für die Espresso Device API einrichten

So richten Sie Ihr Projekt so ein, dass es die Espresso Device API unterstützt:

  1. Damit die Testbefehle auf dem Testgerät übergeben werden, musst du der Manifestdatei im androidTest-Quellsatz die Berechtigungen INTERNET und ACCESS_NETWORK_STATE hinzufügen:

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

  2. Aktivieren Sie das experimentelle Flag enableEmulatorControl in der Datei gradle.properties:

      android.experimental.androidTest.enableEmulatorControl=true

  3. Aktivieren Sie die Option emulatorControl im Build-Script auf Modulebene:

    Kotlin

      testOptions {
    emulatorControl {
      enable = true
    }
  }

    Groovy

      testOptions {
    emulatorControl {
      enable = true
    }
  }

  4. Importieren Sie die Espresso Device-Bibliothek in das Build-Script auf Modulebene in Ihr Projekt:

    Kotlin

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

    Groovy

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

Häufige Konfigurationsänderungen testen

Die Espresso Device API hat mehrere Bildschirmausrichtungen und faltbare Statuswerte, mit denen Sie Änderungen an der Gerätekonfiguration simulieren können.

Test auf Bildschirmdrehung

Hier ist ein Beispiel, wie du testen kannst, was mit deiner App geschieht, wenn sich der Bildschirm des Geräts dreht:

  1. Setzen Sie das Gerät zuerst auf Hochformat, um einen einheitlichen Startzustand zu erreichen:

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

  2. Erstellen Sie einen Test, bei dem das Gerät während der Testausführung ins Querformat wechselt:

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

  3. Prüfen Sie nach der Bildschirmdrehung, ob sich die Benutzeroberfläche wie erwartet an das neue Layout anpasst:

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

Test auf Displayentfaltung

Hier ist ein Beispiel dafür, wie Sie testen können, was mit Ihrer App passiert, wenn sie auf einem faltbaren Gerät ausgeführt wird und das Display aufgeklappt wird:

  1. Teste zuerst, ob das Gerät zugeklappt ist. Dazu rufst du onDevice().setClosedMode() auf. Achten Sie darauf, dass sich das Layout Ihrer App an die kompakte Bildschirmbreite anpasst:

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

  2. Wenn Sie das Gerät vollständig aufklappen möchten, drücken Sie onDevice().setFlatMode(). Prüfe, ob sich das Layout der App an die erweiterte Größenklasse anpasst:

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

Angeben, welche Geräte für Ihre Tests erforderlich sind

Wenn Sie einen Test ausführen, bei dem Faltaktionen auf einem Gerät ausgeführt werden, das nicht faltbar ist, schlägt der Test in der Regel fehl. Wenn Sie nur die Tests ausführen möchten, die für das laufende Gerät relevant sind, verwenden Sie die Anmerkung @RequiresDeviceMode. Der Test-Runner überspringt automatisch die Ausführung von Tests auf Geräten, die die getestete Konfiguration nicht unterstützen. Sie können die Regel für die Geräteanforderungen jedem Test oder einer ganzen Testklasse hinzufügen.

Wenn Sie beispielsweise angeben möchten, dass ein Test nur auf Geräten ausgeführt werden soll, die das Entfalten in eine flache Konfiguration unterstützen, fügen Sie dem Test den folgenden @RequiresDeviceMode-Code hinzu:

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