Bekannte Probleme mit Android Studio und dem Android Gradle-Plug-in

Auf dieser Seite werden bekannte Probleme mit Android Studio Ladybug und dem Android Gradle-Plug-in 8.7.0 aufgeführt. Wenn ein Problem auftritt, das hier nicht aufgeführt ist, melden Sie den Fehler.

Auf die Vorabversion umstellen: Mit jeder Version von Android Studio und dem Android Gradle-Plug-in sollen Stabilität und Leistung verbessert und neue Funktionen hinzugefügt werden. Wenn Sie die Vorteile der kommenden Releases schon jetzt nutzen möchten, laden Sie Android Studio Preview herunter und installieren Sie es.

Bekannte Probleme mit Android Studio

In diesem Abschnitt werden bekannte Probleme in der neuesten stabilen Version von Android Studio beschrieben.

Durch „Änderungen anwenden und Aktivität neu starten“ wird die Aktivität auf Geräten oder Emulatoren mit API-Level 35 nicht neu gestartet

Wenn Sie Codeänderungen mit „Änderungen anwenden und Aktivität neu starten“ auf einem API 35-Gerät bereitstellen, wird die App nicht neu gestartet und Sie sehen keine Auswirkungen der Änderungen. Wenn Sie die Anwendung noch einmal ausführen, sehen Sie die Auswirkungen der Codeänderungen. Unser Team untersucht das Problem derzeit.

Im Firebase Assistant-Fenster wird eine Fehlermeldung angezeigt

Wenn im Firebase Assistant-Fenster (im Hauptmenü „Tools“ > „Firebase“) eine Fehlermeldung angezeigt wird, entwerten Sie die Caches und starten Sie Android Studio neu, um den Fehler zu beheben.

Isolieren einer Ansicht mit Layout Inspector nicht möglich

Die Möglichkeit, eine Ansicht mit dem eingebetteten Layout-Inspektor zu isolieren, ist vorübergehend nicht verfügbar. Wir arbeiten daran, dieses Problem in einer zukünftigen Version zu beheben.

Nicht alle Compose-Knoten können mit dem Layout-Inspektor geprüft werden

Wenn Sie feststellen, dass nicht alle Compose-Knoten mit dem Layout-Inspektor geprüft werden können, liegt das wahrscheinlich an einem Fehler, der in Compose-Version 1.5.0-alpha04 behoben wurde. Wenn dieses Problem bei Ihnen auftritt, führen Sie ein Upgrade auf Compose-Version 1.5.0-alpha04 oder höher aus.

Fehler beim Rendern der Schreibvorschau

Wenn Sie in Android Studio Chipmunk im Bereich „Probleme“ java.lang.NoSuchFieldError: view_tree_saved_state_registry_owner oder java.lang.ClassNotFoundException: androidx.savedstate.R$id sehen, müssen Sie in Ihrem Modul eine debugImplementation-Abhängigkeit von androidx.lifecycle:lifecycle-viewmodel-savedstate angeben.

Wenn im Bereich „Probleme“ java.lang.NoSuchFieldError: view_tree_lifecycle_owner angezeigt wird, müssen Sie in Ihrem Modul eine debugImplementation-Abhängigkeit von androidx.lifecycle:lifecycle-runtime angeben.

Wenn im Bereich „Probleme“ java.lang.NoClassDefFoundError: Could not initialize class androidx.customview.poolingcontainer.PoolingContainer oder java.lang.NoClassDefFoundError: androidx/customview/poolingcontainer/PoolingContainerListener angezeigt wird, müssen Sie in Ihrem Modul eine debugImplementation-Abhängigkeit von androidx.customview:customview-poolingcontainer angeben.

Fehler bei Verwendung verschiedener Passwörter für Schlüssel und Schlüsselspeicher

Ab Version 4.2 wird Android Studio jetzt mit JDK 11 ausgeführt. Dieses Update führt zu einer Änderung des Verhaltens im Zusammenhang mit Signaturschlüsseln.

Wenn du Build > Signiertes Bundle / APK generieren aufrufst und versuchst, die App-Signatur für ein App Bundle oder APK zu konfigurieren, kann die Eingabe unterschiedlicher Passwörter für Schlüssel und Schlüsselspeicher zu folgendem Fehler führen:

Key was created with errors:
Warning: Different store and Key passwords not supported for PKCS12 Key stores

Um dieses Problem zu umgehen, geben Sie dasselbe Passwort für den Schlüssel und den Schlüsselspeicher ein.

Android Studio startet nach der Installation von Version 4.2 nicht mehr

Studio versucht, vorherige .vmoptions zu importieren und zu bereinigen, damit sie mit dem von JDK 11 verwendeten Garbage Collector funktionieren. Wenn dieser Vorgang fehlschlägt, wird die IDE möglicherweise nicht für bestimmte Nutzer gestartet, die benutzerdefinierte VM-Optionen in der Datei .vmoptions festgelegt haben.

Um dieses Problem zu umgehen, empfehlen wir, benutzerdefinierte Optionen in .vmoptions mit dem Zeichen „#“ zu kommentieren. Die Datei .vmoptions befindet sich an den folgenden Speicherorten:

Windows

C:\Users\YourUserName\AppData\[Local|Roaming]\Google\AndroidStudio4.2\studio64.exe.vmoptions

macOS

~/Library/Application Support/Google/AndroidStudio4.2/studio.vmoptions

Linux

~/.config/Google/AndroidStudio4.2/studio64.vmoptions

Falls Studio auch nach dieser Problemumgehung nicht gestartet wird, lesen Sie den Abschnitt Studio wird nach dem Upgrade nicht gestartet weiter unten.

Apps, die Database Inspector verwenden, stürzen im Android 11-Emulator ab

Apps, die den Database Inspector verwenden, können abstürzen, wenn sie auf dem Android 11-Emulator ausgeführt werden. Dabei wird im Logcat ein Fehler wie der folgende angezeigt:

 Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)

Führen Sie zum Beheben dieses Problems ein Upgrade Ihres Android 11-Emulators auf Version 9 oder höher durch. Gehen Sie dazu zu Tools > SDK Manager. Klicken Sie auf dem Tab SDK-Plattformen das Kästchen Paketdetails anzeigen an und wählen Sie Version 9 oder höher des Android 11-Emulators aus.

Studio startet nach dem Upgrade nicht

Wenn Studio nach einem Upgrade nicht gestartet wird, kann das an einer ungültigen Android Studio-Konfiguration liegen, die aus einer früheren Version von Android Studio importiert wurde, oder an einem inkompatiblen Plug-in. Als Problemumgehung können Sie je nach Android Studio-Version und Betriebssystem das folgende Verzeichnis löschen (oder zu Sicherungszwecken umbenennen) und Android Studio neu starten. Dadurch wird Android Studio auf den Standardzustand zurückgesetzt und alle Drittanbieter-Plug-ins werden entfernt.

Für Android Studio 4.1 und höher:

• Windows: %APPDATA%\Google\AndroidStudio<version>
  Beispiel: C:\Users\your_user_name\AppData\Roaming\Google\AndroidStudio4.1

• macOS:~/Library/Application Support/Google/AndroidStudio<version>
  Beispiel: ~/Library/Application Support/Google/AndroidStudio4.1

• Linux:~/.config/Google/AndroidStudio<version> und ~/.local/share/Google/AndroidStudio<version>
  Beispiel: ~/.config/Google/AndroidStudio4.1 und ~/.local/share/Google/AndroidStudio4.1

Für Android Studio 4.0 und niedriger:

• Windows: %HOMEPATH%\.AndroidStudio<version>\config
  Beispiel: C:\Users\your_user_name\.AndroidStudio3.6\config

• macOS: ~/Library/Preferences/AndroidStudio<version>
  Beispiel: ~/Library/Preferences/AndroidStudio3.6

• Linux: ~/.AndroidStudio<version>/config
  Beispiel: ~/.AndroidStudio3.6/config

Das Konfigurationsverzeichnis für Canary- und Betaversionen von Android Studio lautet PreviewX.Y anstelle von X.Y für die <version>. Beispielsweise verwenden Builds von Android Studio 4.1 Canary AndroidStudioPreview4.1 anstelle des Verzeichnisses AndroidStudio4.1, das für Releasekandidaten und stabile Releases genutzt wird.

Kompilierungsproblem in Kotlin-Multiplattform-Projekten

Kompilierungsfehler können im Kotlin-MPP-Code aufgrund fehlender Symbole auftreten. Durch ein Upgrade des Kotlin-Plug-ins auf Version 1.4 sollte dieses Problem behoben werden.

Schlüsselzuordnungskonflikte unter Linux

Unter Linux stehen bestimmte Tastenkürzel in Konflikt mit den standardmäßigen Linux-Tastenkürzeln und denen beliebter Fenstermanager wie KDE und GNOME. Diese in Konflikt stehenden Tastenkombinationen funktionieren in Android Studio möglicherweise nicht wie erwartet.

Weitere Informationen zu diesem Problem (einschließlich potenzieller Problemumgehungen) finden Sie im IntelliJ-Bug-Tracker.

Kleiner Text in der Benutzeroberfläche unter ChromeOS

Unter ChromeOS erscheint Text möglicherweise viel kleiner als in früheren Releases. So umgehen Sie das Problem:

1. Öffnen Sie das Fenster Einstellungen, indem Sie auf Datei > Einstellungen klicken.
2. Gehen Sie zu Darstellung und Verhalten > Darstellung.
3. Wählen Sie Benutzerdefinierte Schriftart verwenden aus.
4. Die Schrift vergrößern
5. Gehen Sie im Fenster Einstellungen zu Editor > Schriftart.
6. Die Schrift vergrößern
7. Klicken Sie auf OK.

Codebearbeitung

In diesem Abschnitt werden bekannte Probleme im Zusammenhang mit dem Code-Editor beschrieben.

Eingefrorene Tastatureingabe – „iBus“-Probleme unter Linux

Es gibt einige bekannte Interaktionen zwischen dem iBus-Daemon unter Linux und Android Studio. In einigen Fällen reagiert die IDE nicht mehr auf die Tastatureingabe oder es werden zufällige Zeichen eingegeben. Dieser Fehler wird durch eine fehlende Synchronisierung zwischen iBus und XLib und AWT ausgelöst und wurde bereits vorgelagert an JetBrains und iBus gemeldet. Es gibt derzeit drei Möglichkeiten, dieses Problem zu umgehen:

• Problemumgehung 1: iBus in den synchronen Modus zwingen Führen Sie vor dem Starten von Android Studio den folgenden Befehl in der Befehlszeile aus:

  $ IBUS_ENABLE_SYNC_MODE=1 ibus-daemon -xrd

• Problemumgehung 2: Deaktivieren Sie die iBus-Eingabe in Android Studio. Wenn Sie die iBus-Eingabe nur für Android Studio deaktivieren möchten, führen Sie in der Befehlszeile Folgendes aus:

  $ XMODIFIERS= ./bin/studio.sh

  Mit dieser Problemumgehung werden nur die Eingabemethoden für Android Studio deaktiviert, nicht die von anderen Anwendungen, die Sie möglicherweise ausführen. Wenn Sie den Daemon neu starten, während Android Studio geöffnet ist (z. B. durch Ausführen von ibus-daemon -rd), werden die Eingabemethoden für alle anderen Anwendungen deaktiviert. Außerdem kann die JVM von Android Studio durch einen Segmentierungsfehler abstürzen.
• Umgehungslösung 3: Prüfen Sie die Tastenkürzel, um sicherzustellen, dass die Tastenkombination für die Nächste Eingabe nicht auf „Strg + Leertaste“ festgelegt ist, da dies auch die Tastenkombination für den Codeabschluss in Android Studio ist. In Ubuntu 14.04 (Trusty) ist Super + Leertaste die Standardverknüpfung, aber die Einstellungen aus früheren Versionen sind möglicherweise noch vorhanden. Wenn Sie die Tastenkürzel überprüfen möchten, geben Sie ibus-setup in der Befehlszeile ein, um das IBus-Fenster mit den Einstellungen zu öffnen. Setzen Sie unter Tastenkombinationen ein Häkchen bei Nächste Eingabemethode. Wenn die Tastenkombination auf „Strg + Leertaste“ festgelegt ist, ändern Sie sie zu „Super + Leertaste“ oder einer anderen Tastenkombination Ihrer Wahl.

Projektkonfiguration

In diesem Abschnitt werden bekannte Probleme im Zusammenhang mit der Projektkonfiguration und der Gradle-Synchronisierung beschrieben.

Gradle-Synchronisierung fehlgeschlagen: Broken Pipe

Das Problem ist, dass der Gradle-Daemon versucht, IPv4 anstelle von IPv6 zu verwenden.

• Problemumgehung 1: Geben Sie unter Linux Folgendes in ~/.profile oder ~/.bash_profile ein:

  export _JAVA_OPTIONS="-Djava.net.preferIPv6Addresses=true"

• Problemumgehung 2: Ändern Sie in der vmoptions-Datei von Android Studio die Zeile -Djava.net.preferIPv4Addresses=true in -Djava.net.preferIPv6Addresses=true. Weitere Informationen finden Sie im Netzwerk-IPv6-Nutzerhandbuch.

Fehler „peer not authenticated“ (Peer nicht authentifiziert) bei der Gradle-Synchronisierung oder im SDK-Manager

Die Ursache dieser Fehler ist ein fehlendes Zertifikat in $JAVA_HOME/jre/lib/certificates/cacerts. So beheben Sie diese Fehler:

• Wenn du dich hinter einem Proxy befindest, versuche, eine direkte Verbindung herzustellen. Wenn die direkte Verbindung funktioniert, müssen Sie möglicherweise das Zertifikat des Proxyservers mit keytool zur Datei „cacerts“ hinzufügen, um eine Verbindung über den Proxy herzustellen.
• Installieren Sie ein unterstütztes, unverändertes JDK noch einmal. Es gibt ein bekanntes Problem von Ubuntu-Nutzern, das zu einem leeren /etc/ssl/certs/java/cacerts führt. Um dieses Problem zu umgehen, führen Sie folgenden Befehl in der Befehlszeile aus:

  sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

Bereitstellung

In diesem Abschnitt werden bekannte Probleme bei der Bereitstellung der App auf einem verbundenen Gerät beschrieben.

[Nur macOS] Incrementale Updates werden aufgrund eines Problems mit der Gradle-Dateiüberwachung bei Projekten, die unter /System/Volumes/Data gespeichert sind, nicht angewendet.

Das Gradle-Problem 18149 betrifft das Android-Gradle-Plug-in ab Version 7.0, da Gradle-Version 7.0 oder höher erforderlich ist. Ab Gradle 7.0 ist die Dateiüberwachung standardmäßig aktiviert. Wenn Sie unter macOS arbeiten und Ihr Projekt unter /System/Volumes/Data gespeichert ist, werden Dateiänderungen durch die Gradle-Dateiüberwachung nicht richtig erfasst. Dadurch erkennt das Build-System keine Dateiänderungen und aktualisiert die APKs nicht. Der Code für die inkrementelle Bereitstellung führt dann nichts aus, da der lokale APK-Status mit dem auf dem Gerät übereinstimmt.

Um dieses Problem zu umgehen, sollten Sie das Verzeichnis Ihres Projekts in Ihr Nutzerverzeichnis verschieben, also unter /Users/username. Das Build-System wird dann über die Gradle-Dateiüberwachung ordnungsgemäß über Dateiänderungen informiert und inkrementelle Änderungen werden erfolgreich angewendet.

Android-Emulator HAXM unter macOS High Sierra

Der Android-Emulator unter macOS High Sierra (10.13) benötigt HAXM 6.2.1 oder höher für optimale Kompatibilität und Stabilität mit macOS. Unter macOS 10.13 ist die Installation von Kernelerweiterungen wie HAXM jedoch etwas aufwendiger. Sie müssen die Installation der Kernel-Erweiterung manuell so manuell zulassen:

1. Versuchen Sie zuerst, die neueste Version von HAXM über den SDK-Manager zu installieren.
2. Unter macOS gehen Sie zu Systemeinstellungen > Sicherheit und Datenschutz.

3. Wenn Sie die Meldung Laden der Systemsoftware des Entwicklers „Intel Corporation Apps“ wurde blockiert sehen, klicken Sie auf Zulassen:

   

Weitere Informationen und Problemumgehungen finden Sie auf der Apple-Webseite und im Problem 62395878.

Änderungen übernehmen

In diesem Abschnitt werden bekannte Probleme im Zusammenhang mit Änderungen anwenden beschrieben.

Neuer App-Name nicht angewendet

Wenn Sie Ihre App umbenennen und dann versuchen, diese Änderung anzuwenden, wird der neue Name möglicherweise nicht übernommen. Klicken Sie zum Umgehen dieses Problems auf Ausführen , um Ihre App neu bereitzustellen und die Änderungen zu sehen.

Problem in der Android-Laufzeit führt zu Fehler

Wenn Sie ein Gerät mit Android 8.0 oder 8.1 verwenden, werden beim Anwenden bestimmter Änderungen möglicherweise Meldungen vom Typ „VERIFICATION_ERROR“ angezeigt (insbesondere bei Verwendung von Kotlin). Diese Meldung wird durch ein Problem mit der Android Runtime verursacht, das in Android 9.0 und höher behoben wurde. Auch wenn das Problem dazu führt, dass die Änderungen nicht angewendet werden können, können Sie Ihre App noch einmal ausführen , um die Änderungen zu sehen. Wir empfehlen jedoch, das Gerät auf Android 9.0 oder höher zu aktualisieren.

Debugging und Tests

In diesem Abschnitt werden bekannte Probleme beim Debugging und Testen Ihrer App beschrieben.

JUnit testet fehlende Ressourcen im Klassenpfad, wenn sie über Android Studio ausgeführt wird

Wenn Sie in Ihren Java-Modulen bestimmte Ressourcenordner haben, werden diese Ressourcen beim Ausführen von Tests aus der IDE nicht gefunden. Das Ausführen von Tests mit Gradle über die Befehlszeile funktioniert. Sie können die Gradle-check-Aufgabe auch über die IDE ausführen. Weitere Informationen finden Sie unter Problem 64887.

Dieses Problem tritt auf, weil ab IntelliJ 13 nur noch ein einzelner Ordner als Klassenpfad zulässig ist. Der Builder von IntelliJ kopiert alle Ressourcen in diesen Build-Ordner, Gradle jedoch nicht.

• Problemumgehung 1: Führen Sie die Gradle-check-Aufgabe aus der IDE aus, anstatt einen Unit-Test auszuführen.
• Problemumgehung 2: Aktualisieren Sie Ihr Build-Script, um Ressourcen manuell in den Build-Ordner zu kopieren. Weitere Informationen finden Sie in Kommentar 13.

Beim Ausführen von JUnit-Tests wird der Code möglicherweise zweimal kompiliert

Beim Erstellen eines neuen Projekts wird die JUnit-Konfiguration der Vorlage möglicherweise mit zwei Schritten „Vor dem Start“ erstellt: „Make“ und „Gradle-aware Make“. Diese Konfiguration wird dann auf alle erstellten JUnit-Ausführungskonfigurationen angewendet.

• Klicken Sie auf Run > Edit Configurations (Ausführen > Konfigurationen bearbeiten) und ändern Sie die JUnit-Standardkonfiguration so, dass nur der Schritt „Gradle-aware Make“ enthalten ist, um das Problem für das aktuelle Projekt zu beheben.
• Wenn Sie das Problem für alle zukünftigen Projekte beheben möchten, klicken Sie auf Datei > Projekt schließen. Daraufhin wird der Willkommensbildschirm angezeigt. Klicken Sie dann auf Konfigurieren > Projektstandardeinstellungen > Ausführungskonfigurationen und ändern Sie die JUnit-Konfiguration so, dass nur der Gradle-kompatible Make-Schritt enthalten ist.

Einige Testlaufkonfigurationen funktionieren nicht

Nicht alle Ausführungskonfigurationen, die beim Klicken mit der rechten Maustaste auf eine Testmethode verfügbar sind, sind gültig. Insbesondere sind die folgenden Konfigurationen ungültig:

• Gradle-Ausführungskonfigurationen (mit dem Gradle-Logo als Symbol) funktionieren nicht.
• JUnit-Ausführungskonfigurationen (mit einem Symbol ohne das grüne Android-Symbol) gelten nicht für Instrumentierungstests, die nicht auf der lokalen JVM ausgeführt werden können.

Android Studio speichert auch die in einem bestimmten Kontext erstellte Ausführungskonfiguration (z. B. durch Rechtsklick auf eine bestimmte Klasse oder Methode) und bietet keine weitere Ausführung in einer anderen Konfiguration an. Klicken Sie zum Beheben dieses Problems auf Ausführen > Konfigurationen bearbeiten und entfernen Sie die fälschlicherweise erstellten Konfigurationen.

Java-Haltepunkte beim Debuggen von nativem Code hinzufügen

Wenn Ihre App an einem Haltepunkt in Ihrem nativen Code angehalten ist, erkennen die Debugger Auto und Dual möglicherweise nicht sofort neue Java-Haltepunkte, die Sie setzen. Um dieses Problem zu vermeiden, fügen Sie Java-Haltepunkte hinzu, bevor Sie eine Fehlerbehebungssitzung starten oder während die Anwendung an einem Java-Haltepunkt pausiert ist. Weitere Informationen finden Sie unter Problem 229949.

Nativen Debugger verlassen

Wenn Sie mit dem Auto- oder Dual-Debugger Java- und nativen Code debuggen und aus Ihrem Java-Code heraus in eine native Funktion eintreten (z. B. wenn der Debugger die Ausführung an einer Zeile in Ihrem Java-Code anhält, die eine native Funktion aufruft, und Sie auf Step Into klicken), und Sie zum Java-Code zurückkehren möchten, klicken Sie auf Programm fortsetzen (anstelle von Step Out oder Step Over ). Der App-Prozess wird weiterhin angehalten. Klicken Sie auf dem Tab your-module-java auf Programm fortsetzen , um ihn fortzusetzen. Weitere Informationen finden Sie unter Problem 224385.

Nativer Debugger hängt beim Laden von Bibliotheken

Wenn Sie den nativen Debugger zum ersten Mal nach dem Upgrade auf Android Studio 4.2 und höher verwenden, reagiert der native Debugger möglicherweise nicht mehr, während Bibliotheken vom Android-Gerät geladen werden. Dieses Problem tritt auch dann auf, wenn Sie den Debugger beenden und neu starten. Löschen Sie den LLDB-Cache unter $USER/.lldb/module-cache/, um das Problem zu beheben.

Nativer Debugger stürzt mit der Meldung „Debuggerprozess beendet mit dem Exit-Code 127“ ab

Dieser Fehler tritt auf Linux-basierten Plattformen beim Starten des nativen Debuggers auf. Dies bedeutet, dass eine der vom nativen Debugger benötigten Bibliotheken nicht auf dem lokalen System installiert ist. Der Name der fehlenden Bibliothek ist möglicherweise bereits in der Datei idea.log gedruckt. Falls nicht, können Sie über ein Terminal zum Installationsverzeichnis von Android Studio wechseln und die Befehlszeile bin/lldb/bin/LLDBFrontend --version ausführen, um herauszufinden, welche Bibliotheken fehlen. In der Regel ist die fehlende Bibliothek ncurses5, da einige neuere Linux-Distributionen bereits auf ncurses6 umgestellt haben.

Profiler

In diesem Abschnitt werden bekannte Probleme mit den Profilern beschrieben.

Nativer Speicher-Profiler: Profiling nicht beim Start der App verfügbar

Der Native Memory Profiler ist derzeit beim Start der Anwendung nicht verfügbar. Diese Option wird in einer künftigen Version verfügbar sein.

Als Behelfslösung können Sie den eigenständigen Perfetto-Befehlszeilen-Profiler verwenden, um Startprofile zu erfassen.

Zeitüberschreitungsfehler im CPU-Profiler

Wenn Sie die Konfiguration Java-Beispielmethoden oder Trace-Java-Methoden auswählen, kann im CPU Profiler von Android Studio die Fehlermeldung „Aufzeichnung konnte nicht gestoppt werden“ auftreten. Häufig handelt es sich dabei um Zeitüberschreitungsfehler, insbesondere wenn in der idea.log-Datei die folgende Fehlermeldung angezeigt wird:

Wait for ART trace file timed out

Zeitüberschreitungsfehler treten bei getrackten Methoden häufiger auf als bei Stichprobenmethoden und bei längeren Aufzeichnungen häufiger als bei kürzeren. Als vorübergehende Lösung können Sie kürzere Aufnahmen ausprobieren, um zu sehen, ob der Fehler dadurch verschwindet.

Wenn beim Profiler Zeitüberschreitungen auftreten, erstellen Sie bitte einen Fehlerbericht. Geben Sie dabei die Marke und das Modell Ihres Geräts sowie alle relevanten Einträge aus idea.log und logcat an.

ADB-Ausnahme beim Debuggen oder Erstellen von Profilen

Wenn Sie Platform Tools 29.0.3 verwenden, funktionieren die native Fehlerbehebung und die Android Studio-Profiler möglicherweise nicht richtig. Wenn Sie Hilfe > Protokoll anzeigen auswählen, wird in der Datei idea.log möglicherweise entweder „AdbCommandRejectedException“ oder „Failed to connect port“ angezeigt. Durch ein Upgrade der Plattformtools auf 29.0.4 oder höher werden beide Probleme behoben.

So führen Sie ein Upgrade der Plattformtools aus:

1. Öffnen Sie den SDK-Manager in Android Studio, indem Sie auf Tools > SDK-Manager klicken oder in der Symbolleiste auf SDK-Manager klicken.
2. Klicken Sie das Kästchen neben Android SDK-Plattformtools an. In der linken Spalte sollte ein Downloadsymbol  angezeigt werden.
3. Klicken Sie auf Übernehmen oder OK.

Plug-in verhindert, dass das Build-Ausgabefenster funktioniert

Mit dem Plug-in CMake simple highlighter werden Inhalte nicht im Fenster „Build-Ausgabe“ angezeigt. Der Build wird ausgeführt und der Tab „Build-Ausgabe“ wird angezeigt, aber es wird keine Ausgabe gedruckt (Problem #204791544).

Installationsreihenfolge verhindert Start

Wenn Sie eine neuere Version von Android Studio vor einer älteren Version installieren, wird die ältere Version möglicherweise nicht gestartet. Wenn Sie beispielsweise zuerst die Canary-Version von Android Studio installieren und dann versuchen, die stabile Version zu installieren und zu starten, wird die stabile Version möglicherweise nicht gestartet. In solchen Fällen müssen Sie den Cache leeren, damit die stabile (ältere) Version gestartet wird. Unter macOS löschen Sie den Cache, indem Sie das Verzeichnis Library/ApplicationSupport/Google/AndroidStudioversion_number löschen. Unter Windows können Sie den Cache mit der Datenträgerbereinigung leeren.

Espresso Test Recorder funktioniert nicht mit Compose

Der Espresso Test Recorder funktioniert nicht mit Projekten, die Compose enthalten. Informationen zum Erstellen von UI-Tests für Projekte, die Compose enthalten, finden Sie unter Compose-Layout testen.

Tastenkürzel für Logcat kollidiert mit Tastaturlayouts, die nicht auf Englisch sind

Wenn Sie ein Tastaturlayout verwenden, das nicht auf Englisch basiert, kann eine Standard-Logcat-Tastaturkürzel mit dem Layout in Konflikt stehen und Sie daran hindern, bestimmte Zeichen beim Bearbeiten von Text in Android Studio einzugeben. Löschen oder ordnen Sie die in Konflikt stehende Logcat-Tastaturbelegung neu zu, um dieses Problem zu umgehen. Wenn Sie die Logcat-Tastenkombinationen in Android Studio bearbeiten möchten, rufen Sie Android Studio > Einstellungen > Tastenkombination auf und suchen Sie in der Liste der Tastenkombinationen nach Logcat. Weitere Informationen finden Sie unter Problem 263475910.

Dieses Problem wird durch das Entfernen der Logcat-Verknüpfung in Android Studio Electric Eel Patch 1 behoben.

Bekannte Probleme mit dem Android Gradle-Plug-in

In diesem Abschnitt werden bekannte Probleme in der neuesten stabilen Version des Android-Gradle-Plug-ins beschrieben.

Nicht alle Abhängigkeiten von Bibliotheken für dynamische Funktionen werden mit Lint geprüft

Wenn Sie „lint“ mit checkDependencies = true aus einem App-Modul ausführen, werden die Abhängigkeiten von Bibliotheken für dynamische Funktionen nur dann geprüft, wenn sie auch App-Abhängigkeiten sind (Problem #191977888). Als Behelfslösung kann die Lint-Aufgabe auf diesen Bibliotheken ausgeführt werden.

Signaturdatei mit Zeilenumbruchzeichen

Die JAR-Signatur (V1-Schema) unterstützt keine Dateinamen, die Wagenrücklaufzeichen enthalten (Problem #63885809).

Das Ändern von Variantenausgaben zum Zeitpunkt des Builds funktioniert möglicherweise nicht

Die Bearbeitung von Variantenausgaben über die Variant API funktioniert mit dem neuen Plug-in nicht mehr. Sie funktioniert jedoch weiterhin für einfache Aufgaben wie das Ändern des APK-Namens während der Buildzeit, wie unten gezeigt:

// If you use each() to iterate through the variant objects,
// you need to start using all(). That's because each() iterates
// through only the objects that already exist during configuration time—
// but those object don't exist at configuration time with the new model.
// However, all() adapts to the new model by picking up object as they are
// added during execution.
android.applicationVariants.all { variant ->
    variant.outputs.all {
        outputFileName = "${variant.name}-${variant.versionName}.apk"
    }
}

Komplexere Aufgaben, die den Zugriff auf outputFile-Objekte erfordern, funktionieren jedoch nicht mehr. Das liegt daran, dass variantenspezifische Aufgaben in der Konfigurationsphase nicht mehr erstellt werden. Dadurch weiß das Plug-in nicht im Voraus, welche Ausgabewerte es hat. Die Konfigurationszeit ist jedoch kürzer.

manifestOutputFile ist nicht mehr verfügbar

Die Methode processManifest.manifestOutputFile() ist nicht mehr verfügbar. Beim Aufrufen wird folgender Fehler angezeigt:

A problem occurred configuring project ':myapp'.
   Could not get unknown property 'manifestOutputFile' for task
   ':myapp:processDebugManifest' of type
   com.android.build.gradle.tasks.ProcessManifest.

Anstatt manifestOutputFile() aufzurufen, um die Manifestdatei für jede Variante abzurufen, können Sie processManifest.manifestOutputDirectory() aufrufen, um den Pfad des Verzeichnisses zurückzugeben, das alle generierten Manifeste enthält. Sie können dann ein Manifest suchen und Ihre Logik darauf anwenden. Im folgenden Beispiel wird der Versionscode im Manifest dynamisch geändert:

android.applicationVariants.all { variant ->
    variant.outputs.all { output ->
        output.processManifest.doLast {
            // Stores the path to the maifest.
            String manifestPath = "$manifestOutputDirectory/AndroidManifest.xml"
            // Stores the contents of the manifest.
            def manifestContent = file(manifestPath).getText()
            // Changes the version code in the stored text.
            manifestContent = manifestContent.replace('android:versionCode="1"',
                    String.format('android:versionCode="%s"', generatedCode))
            // Overwrites the manifest with the new text.
            file(manifestPath).write(manifestContent)
        }
    }
}

Probleme mit der AIDL-Unterstützung für AGP 7.3.0 und Kotlin 1.7.x

Wenn Sie AGP 7.3.0 mit KAPT in Kotlin 1.7.x verwenden, werden die AIDL-Quellsätze für bestimmte Buildvarianten entfernt. Sie können weiterhin die anderen AIDL-Quellsätze verwenden, einschließlich der von main/, Buildtypen, Produktvarianten und Kombinationen von Produktvarianten. Wenn Sie die variantenspezifischen AIDL-Quellsätze verwenden müssen, verwenden Sie weiterhin Kotlin 1.6.21.

Bekannte Probleme behoben

In diesem Abschnitt werden bekannte Probleme beschrieben, die in einer aktuellen Version behoben wurden. Wenn eines dieser Probleme auftritt, sollten Sie Android Studio auf die neueste stabile Version oder Vorabversion aktualisieren.

In Android Studio 2021.1.1 behoben

• Fehlende Lint-Ausgabe: Wenn die Lint-Aufgabe UP-TO-DATE ist (Problem 191897708), wird kein Lint-Text an stdout ausgegeben. Behoben in AGP 7.1.0-alpha05.
• Probleme beim Unit-Testen eines App-Projekts, das das Hilt-Plug-in verwendet: Der Klassenpfad für den Unit-Test enthält die nicht instrumentierten App-Klassen. Das bedeutet, dass Hilt die App-Klassen nicht für die Abhängigkeitsinjektion instrumentiert, wenn Unit-Tests ausgeführt werden (Problem #213534628). In AGP 7.1.1 behoben.

In Android Studio 2020.3.1 behoben

• Lint-Ausnahmen in Kotlin-Projekten:In Kotlin-Projekten, in denen checkDependencies = true festgelegt ist, können Nullzeigerausnahmen oder Fehler auftreten (Problem #158777858).

In Android Studio 4.2 behoben

• IDE friert unter macOS Big Sur ein: Android Studio 4.1 friert möglicherweise ein, wenn Sie ein Dialogfeld öffnen.

In Android Studio 4.1 behoben

• Neustart, um Arbeitsspeichereinstellungen aus der vorherigen Version der IDE anzuwenden:Nachdem Sie Android Studio aktualisiert haben, müssen Sie es neu starten, um Arbeitsspeichereinstellungen anzuwenden, die aus einer früheren Version der IDE migriert wurden.
• Manifestklasse mit benutzerdefinierten Berechtigungsstrings wird nicht mehr standardmäßig generiert:Wenn Sie die Klasse generieren möchten, legen Sie android.generateManifestClass = true fest.

Behoben in Android Studio 3.6

• APK-Installationsfehler unter LineageOS: Die Bereitstellung Ihrer App auf Geräten mit bestimmten Versionen von LineageOS oder CyanogenMod kann fehlschlagen und die Ausnahme INSTALL_PARSE_FAILED_NOT_APK auslösen.

  In Android Studio 3.6 Beta 1 und höher verarbeitet die IDE diese Ausnahme, indem sie eine vollständige App-Installation durchführt, wenn Sie Ihre App auf LineageOS- oder CyanogenMod-Geräten bereitstellen. Dies kann zu längeren Bereitstellungszeiten führen.

In Android Studio 3.5.2 behoben

• Fehlerhafter XML-Codestil: Beim Bearbeiten von XML-Code hat die IDE einen falschen Codestil angewendet, als Sie in der Menüleiste Code > Code neu formatieren ausgewählt haben.

In Android Studio 3.3.1 behoben

• Fehlermeldungen wegen fehlendem Arbeitsspeicher beim Scannen C++-basierter Projekte: Wenn Gradle ein Projekt mit C++-Code an mehreren Stellen auf demselben Laufwerk scannt, werden alle Verzeichnisse unter dem ersten gemeinsamen Verzeichnis gescannt. Das Scannen einer großen Anzahl von Verzeichnissen und Dateien kann zu Fehlern aufgrund von unzureichendem Arbeitsspeicher führen.

  Weitere Informationen zu diesem Problem finden Sie im entsprechenden Fehler.