Android Studio Iguana | 2023.2.1

Android Studio ist die offizielle IDE für die Android-Entwicklung und enthält alles, was Sie zum Erstellen von Android-Apps benötigen.

Auf dieser Seite werden die neuen Funktionen und Verbesserungen in der neuesten Version der stabilen Version Android Studio Iguana aufgeführt. Sie können sie hier herunterladen oder in Android Studio aktualisieren. Klicken Sie dazu auf Hilfe > Nach Updates suchen (Android Studio > Nach Updates suchen für macOS).

Informationen zu den Fehlerkorrekturen in dieser Version von Android Studio finden Sie unter Geschlossene Probleme.

Die Versionshinweise für ältere Versionen von Android Studio finden Sie unter Frühere Versionen.

Vorabzugriff auf neue Funktionen und Verbesserungen findest du unter Builds von Android Studio als Vorabversion.

Falls Probleme in Android Studio auftreten, lesen Sie die Informationen auf der Seite Bekannte Probleme oder Fehlerbehebung.

Android-Gradle-Plug-in und Kompatibilität mit Android Studio

Das Build-System von Android Studio basiert auf Gradle. Das Android Gradle-Plug-in (AGP) bietet verschiedene Funktionen, die speziell für das Erstellen von Android-Apps entwickelt wurden. In der folgenden Tabelle ist aufgeführt, welche AGP-Version für die jeweilige Version von Android Studio erforderlich ist.

Informationen zu den Neuerungen im Android-Gradle-Plug-in finden Sie in den Versionshinweisen zum Android-Gradle-Plug-in.

Mindestversionen von Tools für Android API-Level

Es gibt Mindestversionen von Android Studio und AGP, die eine bestimmte API-Ebene unterstützen. Die Verwendung niedrigerer Versionen von Android Studio oder AGP als für targetSdk oder compileSdk Ihres Projekts erforderlich, kann zu unerwarteten Problemen führen. Wir empfehlen, für Projekte, die auf Vorschauversionen des Android-Betriebssystems ausgerichtet sind, die neueste Vorschauversion von Android Studio und AGP zu verwenden. Sie können Vorschauversionen von Android Studio zusammen mit einer stabilen Version installieren.

Für Android Studio und AGP gelten folgende Mindestversionen:

Die folgenden neuen Funktionen sind in Android Studio Iguana verfügbar.

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 umfasst diese Fehlerkorrekturen.

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

Dieses kleinere Update umfasst diese Fehlerkorrekturen.

Integration des Versionsverwaltungssystems in App Quality Insights

Mit App Quality Insights können Sie jetzt von einem Crashlytics-Stacktrace zum entsprechenden Code zum Zeitpunkt des Absturzes wechseln. AGP hängt Hash-Daten mit Git Commit an Absturzberichte an. So kann Android Studio zu Ihrem Code navigieren und sehen, wie er sich in der Version befand, in der das Problem aufgetreten ist. Wenn Sie in App Quality Insights einen Absturzbericht aufrufen, können Sie zur Codezeile im aktuellen Git-Checkout gehen oder einen Unterschied zwischen dem aktuellen Bezahlvorgang und der Version Ihrer Codebasis anzeigen, die den Absturz generiert hat.

Für die Einbindung Ihres Versionsverwaltungssystems in App Quality Insights gelten die folgenden Mindestanforderungen:

• Neueste Canary-Version von Android Studio Iguana
• Neueste Alphaversion des Android-Gradle-Plug-ins 8.3
• Crashlytics SDK V18.3.7 (oder Firebase Android Bill of Materials, Version 32.0.0)

Wenn Sie die Integration der Versionsverwaltung 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 Debug-fähig) 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 die Absturzberichte die Daten, die erforderlich sind, damit die IDE eine Verknüpfung zu vorherigen Versionen Ihrer App aus dem Stacktrace herstellen kann.

Crashlytics-Absturzvarianten in App Quality Insights ansehen

Zur Analyse der Ursachen eines Absturzes können Sie jetzt mithilfe von App Quality Insights Ereignisse nach Problemvarianten oder Gruppen von Ereignissen mit ähnlichen Stacktraces ansehen. Wenn Sie Ereignisse in jeder Variante eines Absturzberichts aufrufen möchten, wählen Sie eine Variante aus dem Drop-down-Menü aus. Um Informationen für alle Varianten zu aggregieren, wählen Sie Alle aus.

Prüfung der Benutzeroberfläche für das Verfassen

Android Studio Iguana Canary 5 hat in der Vorschau „Compose“ einen neuen UI-Prüfmodus eingeführt, um Entwicklern dabei zu helfen, adaptive und barrierefreie Benutzeroberflächen in Jetpack Compose zu erstellen. Diese Funktion funktioniert ähnlich wie visuelle Linting und Integrationen für Bedienungshilfen prüfen für Ansichten. Wenn Sie den Prüfungsmodus für die Benutzeroberfläche zum Schreiben aktivieren, prüft Android Studio automatisch Ihre Benutzeroberfläche zum Schreiben und sucht nach adaptiven Problemen und Problemen mit der Barrierefreiheit bei verschiedenen Bildschirmgrößen, z. B. auf großen Bildschirmen gestreckter Text oder geringer Farbkontrast. Im Modus werden Probleme hervorgehoben, die in verschiedenen Vorschaukonfigurationen gefunden wurden, und im Bereich „Probleme“ aufgeführt.

Sie können diese Funktion gleich ausprobieren. Klicken Sie dazu unter „Vorschau erstellen“ auf die Schaltfläche „UI Check“ (UI-Prüfung) und senden Sie uns Ihr Feedback:

Bekannte Probleme des UI-Prüfmodus:

• Das ausgewählte Problem im Problembereich verliert möglicherweise den Fokus
• „Regel unterdrücken“ funktioniert nicht

Progressives Rendering für die Vorschau der Erstellung

In Android Studio Iguana Canary 3 wird das progressive Rendering in der Vorschau „Compose“ eingeführt. Im Rahmen unserer kontinuierlichen Bemühungen, die Leistung von Vorschauen zu verbessern, verringern wir nun für jede Vorschau, die nicht sichtbar ist, bewusst die Renderingqualität, um Speicherplatz zu sparen.

Diese Funktion wurde mit dem Ziel entwickelt, die Nutzerfreundlichkeit von Vorschauen weiter zu verbessern, da mehr Vorschauen gleichzeitig in einer Datei verarbeitet werden können. Probieren Sie sie noch heute aus und senden Sie uns Ihr Feedback.

Plattformupdate für IntelliJ IDEA 2023.2

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

Assistent für das Modul „Baseline-Profile“

Ab Android Studio Iguana können Sie Baseline-Profile für Ihre App mithilfe der Vorlage Baseline Profile Generator im neuen Modulassistenten (File > New > New Module) generieren.

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

Die Vorlage erstellt außerdem eine Ausführungskonfiguration, mit der Sie mit einem Klick aus der Drop-down-Liste Ausführung/Fehlerbehebungskonfiguration auswählen ein Referenzprofil generieren können.

Konfigurationsänderungen mit der Espresso Device API testen

Verwenden Sie die Espresso Device API, um Ihre Anwendung zu testen, wenn das Gerät allgemeine Konfigurationsänderungen wie die Drehung oder das Aufklappen des Bildschirms durchläuft. Mit der Espresso Device API können Sie diese Konfigurationsänderungen auf einem virtuellen Gerät simulieren und Ihre Tests synchron ausführen, sodass nur eine UI-Aktion oder Assertion gleichzeitig ausgeführt wird und Ihre Testergebnisse zuverlässiger sind. UI-Tests mit Espresso schreiben

Zur Verwendung der Espresso Device API ist Folgendes erforderlich:

• 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

Gehen Sie wie folgt vor, um Ihr Projekt so einzurichten, dass es die Espresso Device API unterstützt:

1. Damit die Befehle zur Testkarte für das Testgerät verwendet werden können, 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
       }
     }

   Groovig

     testOptions {
       emulatorControl {
         enable = true
       }
     }

4. Importieren Sie die Espresso-Gerätebibliothek im Build-Skript auf Modulebene in Ihr Projekt:

   Kotlin

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

   Groovig

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

Mit gängigen Konfigurationsänderungen testen

Die Espresso Device API bietet mehrere Bildschirmausrichtungen und faltbare Status, mit denen Sie Gerätekonfigurationsänderungen simulieren können.

Gegen Bildschirmdrehung testen

Hier ein Beispiel, wie du testen kannst, was mit deiner App passiert, wenn sich der Gerätebildschirm dreht:

1. Für einen einheitlichen Startstatus muss das Gerät zuerst in das Hochformat gestellt werden:

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

2. Erstelle einen Test, bei dem das Gerät während der Testausführung im Querformat eingestellt wird:

     @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()
     }

Mit Aufklappen des Displays testen

Hier ein Beispiel, wie Sie testen können, was mit Ihrer App passiert, wenn sie sich auf einem faltbaren Gerät befindet und sich das Display aufklappt:

1. Teste es zuerst im zugeklappten Zustand. Dazu rufst du onDevice().setClosedMode() auf. Das Layout deiner App muss sich an die kompakte Bildschirmbreite anpassen:

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

2. Rufen Sie onDevice().setFlatMode() auf, um in einen vollständig geöffneten Zustand zu wechseln. Prüfe, ob sich das Layout der App an die maximierte Größenklasse anpasst:

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

Angeben, welche Geräte für die 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 Annotation @RequiresDeviceMode. Der Test-Runner überspringt automatisch laufende Tests auf Geräten, die die zu testende Konfiguration nicht unterstützen. Du kannst die Geräteanforderungsregel jedem Test oder einer gesamten Testklasse hinzufügen.

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

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