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 | 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.

Plattformupdate für IntelliJ IDEA 2023.2

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 sich einen Absturzbericht in App Quality Insights ansehen, können Sie zur Codezeile in Ihrer aktuellen Git-Checkout-Version wechseln oder sich einen Vergleich zwischen der aktuellen Checkout-Version und der Version Ihrer Codebasis ansehen, die den Absturz verursacht hat.

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.

android {
  buildTypes {
    getByName("debug") {
      vcsInfo {
        include = true
      }
    }
  }
}
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.

Crashvarianten aus Crashlytics in App Quality Insights ansehen

Um die Ursachen von Abstürzen zu analysieren, können Sie jetzt mithilfe von App-Qualitätsdaten Statistiken zu Ereignissen nach Problemvarianten oder Ereignisgruppen mit ähnlichen Stack-Traces aufrufen. Wenn Sie sich die 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.

UI-Prüfung erstellen

Um Entwicklern dabei zu helfen, in Jetpack Compose adaptivere und barrierefreiere Benutzeroberflächen zu erstellen, wurde in Android Studio Iguana Canary 5 ein neuer UI-Prüfmodus in der Compose-Vorabversion eingeführt. Diese Funktion funktioniert ähnlich wie visuelles Linting und Integrationen für die Prüfung der Barrierefreiheit für Ansichten. Wenn Sie den Modus „Compose UI Check“ aktivieren, prüft Android Studio automatisch Ihre Compose-Benutzeroberfläche auf Probleme mit Anpassung und Barrierefreiheit bei verschiedenen Bildschirmgrößen, z. B. auf Text, der auf großen Bildschirmen gedehnt wird, oder auf einen geringen Farbkontrast. In diesem Modus werden Probleme in verschiedenen Vorschaukonfigurationen hervorgehoben und im Bereich „Probleme“ aufgeführt.

Probieren Sie diese Funktion gleich aus. Klicken Sie dazu in der Vorschau für die Nachrichtenerstellung 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 mit dem UI-Prüfmodus:

  • 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 Vorschaubildern weiter verbessert werden, indem in einer Datei gleichzeitig mehr Vorschaubilder 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 mit der Vorlage Baseline Profile Generator im Assistenten für neue Module (File > New > New Module) Baseline-Profile für Ihre App generieren.

Mit dieser Vorlage wird Ihr Projekt so eingerichtet, dass es Baseline-Profile unterstützen kann. 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.

Konfigurationsänderungen mit der Espresso Device API 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 sind folgende Voraussetzungen erforderlich:

  • Android Studio Iguana oder höher
  • Android Gradle-Plug-in 8.3 oder höher
  • Android-Emulator 33.1.10 oder höher
  • Ein 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 der Test Befehle an das Testgerät weitergeben kann, fügen Sie der Manifestdatei im androidTest-Quellsatz 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-Script auf Modulebene:

      testOptions {
        emulatorControl {
          enable = true
        }
      }
      testOptions {
        emulatorControl {
          enable = true
        }
      }
  4. Importieren Sie die Espresso Device-Bibliothek in das Build-Script auf Modulebene in Ihr Projekt:

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

Gängige Konfigurationsänderungen testen

Die Espresso Device API bietet mehrere Bildschirmausrichtungen und Zustände für faltbare Geräte, mit denen Sie Änderungen an der Gerätekonfiguration simulieren können.

Test auf Bildschirmdrehung

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

  1. Stellen Sie zuerst den Modus des Geräts auf Hochformat ein, damit es immer im selben Startstatus ist:

      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. Testen Sie zuerst das 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. Wenn Sie das Gerät vollständig aufklappen möchten, rufen Sie onDevice().setFlatMode() auf. 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 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() {
  ...
}