Android Studio Iguana | 2023.2.1 (Feb. 2024)

Im Folgenden finden Sie die neuen Funktionen in Android Studio Iguana.

Patch releases

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

Android Studio Iguana | 2023.2.1 Patch 2 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 Updates von IntelliJ IDEA 2023.2, die die Studio-IDE verbessern. Weitere Informationen zu den Änderungen finden Sie in den Versionshinweisen zu IntelliJ IDEA 2023.2.

Integration von Versionskontrollsystemen in App Quality Insights

In App Quality Insights können Sie jetzt von einem Crashlytics-Stacktrace zum relevanten Code navigieren – und zwar zu dem Zeitpunkt, zu dem der Absturz aufgetreten ist. AGP fügt Crash-Berichten Git-Commit-Hash-Daten hinzu. So kann Android Studio zu Ihrem Code navigieren und zeigen, 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 in Ihrem aktuellen Git-Checkout wechseln oder einen Unterschied zwischen dem aktuellen Checkout und der Version Ihrer Codebasis ansehen, die den Absturz verursacht hat.

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

Wenn Sie die Versionskontrollintegration für einen debugfähigen Build-Typ verwenden möchten, aktivieren Sie das Flag vcsInfo in der Build-Datei auf Modulebene. Bei Release-Builds (nicht debugfähig) 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 für die IDE erforderlich sind, um über den Stacktrace auf frühere Versionen Ihrer App zu verweisen.

Crashlytics-Crashvarianten in App Quality Insights ansehen

Um die Ursachen eines Absturzes besser analysieren zu können, können Sie jetzt in App Quality Insights Ereignisse nach Varianten aufrufen. Das sind Gruppen von Ereignissen mit ähnlichen Stacks. Wenn Sie Ereignisse in den einzelnen Varianten eines Absturzberichts ansehen möchten, wählen Sie eine Variante aus dem Drop-down-Menü aus. Wenn Sie Informationen für alle Varianten zusammenfassen möchten, wählen Sie Alle aus.

Compose-UI-Check

Damit Entwickler in Jetpack Compose anpassungsfähigere und barrierefreiere Benutzeroberflächen erstellen können, wurde in Android Studio Iguana Canary 5 ein neuer UI-Prüfmodus in der Compose-Vorschau eingeführt. Diese Funktion funktioniert ähnlich wie Visual Linting und Integrationen für Barrierefreiheitsprüfungen für Ansichten. Wenn Sie den Compose-UI-Prüfmodus aktivieren, prüft Android Studio Ihre Compose-UI automatisch auf Probleme mit Anpassungsfähigkeit und Barrierefreiheit auf verschiedenen Bildschirmgrößen, z. B. auf Text, der auf großen Bildschirmen gestreckt wird, oder auf geringen Farbkontrast. In diesem Modus werden Probleme hervorgehoben, die in verschiedenen Vorschaukonfigurationen gefunden wurden, und im Bereich „Probleme“ aufgeführt.

Klicken Sie in der Compose-Vorschau auf die Schaltfläche „UI-Check“ , um die Funktion auszuprobieren, und geben Sie uns Feedback:

Klicken Sie auf die Schaltfläche „Compose UI Check-Modus“, um die Prüfung zu aktivieren.

Bekannte Probleme mit dem UI-Prüfmodus:

  • Das ausgewählte Problem im Problembereich verliert möglicherweise den Fokus
  • „Regel unterdrücken“ funktioniert nicht
Compose-UI-Prüfmodus aktiviert mit Details im Bereich „Probleme“

Progressives Rendern für Compose-Vorschau

In Android Studio Iguana Canary 3 wird progressives Rendern in Compose-Vorschau eingeführt. Wir arbeiten kontinuierlich daran, die Leistung von Vorschauen zu verbessern. Deshalb verringern wir jetzt die Renderqualität von Vorschauen, die nicht im Blickfeld sind, um Arbeitsspeicher zu sparen.

Diese Funktion wurde entwickelt, um die Benutzerfreundlichkeit von Vorschauen weiter zu verbessern, indem mehr Vorschauen gleichzeitig in einer Datei verarbeitet werden können. Probieren Sie es noch heute aus und geben Sie uns Feedback.

Assistent für Baseline-Profile-Modul

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 (File > New > New Module) generieren.

Mit dieser Vorlage wird Ihr Projekt so eingerichtet, dass es Baseline Profiles unterstützt. Dazu wird das neue Gradle-Plug-in für Baseline Profiles verwendet, mit dem das Einrichten Ihres Projekts auf die erforderliche Weise mit einer Gradle-Aufgabe automatisiert wird.

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

Konfigurationsänderungen mit der Espresso Device API testen

Mit der Espresso Device API können Sie Ihre App testen, wenn das Gerät häufigen Konfigurationsänderungen unterzogen wird, z. B. Drehen und Aufklappen des Displays. Mit der Espresso Device API können Sie diese Konfigurationsänderungen auf einem virtuellen Gerät simulieren. Ihre Tests werden synchron ausgeführt, sodass jeweils nur eine UI-Aktion oder ‑Assertion erfolgt und Ihre Testergebnisse zuverlässiger sind. Weitere Informationen zum Schreiben 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 ab Version 8.3
  • 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 für die Unterstützung der Espresso Device API ein:

  1. Damit der Test Befehle an das Testgerät übergeben kann, fügen Sie der Manifestdatei im Quellsatz androidTest die Berechtigungen INTERNET und ACCESS_NETWORK_STATE hinzu:

      <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-Skript auf Modulebene:

    Kotlin

      testOptions {
    emulatorControl {
      enable = true
    }
  }

    Groovy

      testOptions {
    emulatorControl {
      enable = true
    }
  }

  4. Importieren Sie die Espresso Device-Bibliothek in das Build-Skript auf Modulebene:

    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 bietet mehrere Bildschirmorientierungen und faltbare Zustände, mit denen Sie Änderungen an der Gerätekonfiguration simulieren können.

Auf Bildschirmdrehung testen

Hier ist ein Beispiel dafür, wie Sie testen können, was mit Ihrer App passiert, wenn sich das Display des Geräts dreht:

  1. Stellen Sie zuerst sicher, dass sich das Gerät im Hochformat befindet, um einen einheitlichen Startzustand zu erhalten:

      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, der das Gerät während der Testausführung in das Querformat versetzt:

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

  3. Prüfen Sie nach dem Drehen des Displays, 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()
  }

Testen, wenn das Display aufgeklappt wird

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 der Bildschirm aufgeklappt wird:

  1. Testen Sie zuerst mit dem Gerät im zusammengeklappten Zustand, indem Sie onDevice().setClosedMode() aufrufen. 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. Rufen Sie onDevice().setFlatMode() auf, um in den vollständig aufgeklappten Zustand zu wechseln. Prüfen Sie, 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 Faltvorgänge auf einem nicht faltbaren Gerät ausgeführt werden, schlägt der Test in der Regel fehl. Wenn Sie nur die Tests ausführen möchten, die für das aktuelle Gerät relevant sind, verwenden Sie die Annotation @RequiresDeviceMode. Der Test-Runner überspringt automatisch Tests auf Geräten, die die getestete Konfiguration nicht unterstützen. Sie können die Regel für Geräteanforderungen jedem Test oder einer ganzen Testklasse hinzufügen.

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

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