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

Auf dieser Seite werden bekannte Probleme mit Android Studio Narwhal und dem Android-Gradle-Plug-in 8.11.0 aufgeführt. Sollte ein Problem auftreten, das hier noch nicht aufgeführt ist, melden Sie den Fehler bitte.

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

Bekannte Probleme mit Android Studio

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

Ausführen der Konfiguration ohne „Gradle-aware Make“ unter „Before launch“ führt zu Bereitstellungsfehler

In Android Studio Ladybug Feature Drop Canary 9 ist ein Problem aufgetreten, durch das Informationen zur Ausführungskonfiguration aus Projekten entfernt wurden, die mit dieser Version geöffnet wurden. Wenn Sie Ihr Projekt irgendwann mit dieser Version geöffnet haben und beim Ausführen Ihrer App der Fehler „loading build artifacts“ (Build-Artefakte werden geladen) auftritt, prüfen Sie, ob die aktive Ausführungskonfiguration den Schritt „Gradle-aware Make“ (Gradle-kompatibler Build) im Abschnitt „Before launch“ (Vor dem Start) enthält. Klicken Sie zur Bestätigung auf Run/Debug Configurations > Edit Configurations (Ausführungs-/Fehlerbehebungskonfigurationen > Konfigurationen bearbeiten), klicken Sie auf die aktive Ausführungskonfiguration und prüfen Sie, ob im Abschnitt „Before launch“ (Vor dem Start) der Schritt „Gradle-aware Make“ (Gradle-kompatibler Build) vorhanden ist. Leider kann Android Studio dieses Problem nicht automatisch beheben, da einige Ausführungskonfigurationen möglicherweise absichtlich ohne den Schritt „Gradle-aware Make“ eingerichtet wurden.

„Änderungen anwenden und Aktivität neu starten“ startet die Aktivität auf Geräten oder Emulatoren mit API‑Level 35 nicht neu

Wenn Sie Codeänderungen auf einem Gerät mit API 35 mit „Änderungen anwenden und Aktivität neu starten“ bereitstellen, wird die App nicht neu gestartet und die Änderungen sind nicht sichtbar. Wenn Sie die Anwendung noch einmal ausführen, sehen Sie die Auswirkungen der Codeänderungen. Unser Team arbeitet an einer Lösung.

Im Firebase-Assistentenfenster wird eine Fehlermeldung angezeigt

Wenn im Firebase Assistant-Fenster (über das Hauptmenü unter „Tools“ > „Firebase“) eine Fehlermeldung angezeigt wird, können Sie den Fehler beheben, indem Sie die Caches ungültig machen und Android Studio neu starten.

Ansicht mit Layout Inspector nicht isolieren

Die Möglichkeit, eine Ansicht mit dem eingebetteten Layout Inspector 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 Layout Inspector untersucht werden

Wenn Sie feststellen, dass nicht alle Compose-Knoten inspizierbar sind, wenn Sie den Layout Inspector verwenden, 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 durch.

Fehler beim Rendern der Compose-Vorschau

Wenn Sie in Android Studio Chipmunk im Bereich „Problems“ (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 zu androidx.lifecycle:lifecycle-viewmodel-savedstate einfügen.

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

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 zu androidx.customview:customview-poolingcontainer einfügen.

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

Ab Version 4.2 wird Android Studio mit JDK 11 ausgeführt. Dieses Update führt zu einer zugrunde liegenden Verhaltensänderung in Bezug auf Signaturschlüssel.

Wenn Sie Build> Signiertes Bundle / APK generieren aufrufen und versuchen, die App-Signatur für ein App-Bundle oder ein APK zu konfigurieren, kann es zu folgendem Fehler kommen, wenn Sie unterschiedliche Passwörter für den Schlüssel und den Keystore eingeben:

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

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

Android Studio startet nach der Installation von Version 4.2 nicht

Studio versucht, frühere .vmoptions zu importieren und so zu bereinigen, dass sie mit dem Garbage Collector von JDK 11 funktionieren. Wenn dieser Vorgang fehlschlägt, kann es sein, dass die IDE für bestimmte Nutzer, die benutzerdefinierte VM-Optionen in der Datei .vmoptions festgelegt haben, nicht gestartet wird.

Um dieses Problem zu umgehen, empfehlen wir, benutzerdefinierte Optionen in .vmoptions auszukommentieren (mit dem Zeichen „#“). 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

Wenn Studio nach diesem Workaround immer noch nicht startet, lies den Abschnitt Studio startet nach dem Upgrade nicht unten.

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

Apps, die den Database Inspector verwenden, stürzen möglicherweise ab, wenn sie auf dem Android 11-Emulator ausgeführt werden. In logcat wird dann ein Fehler wie der folgende angezeigt:

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

Um dieses Problem zu beheben, aktualisieren Sie Ihren Android 11-Emulator auf Version 9 oder höher. Klicken Sie dazu auf Tools > SDK Manager. Klicken Sie auf dem Tab SDK Platforms das Kästchen Show Package Details an und wählen Sie Revision 9 oder höher des Android 11-Emulators aus.

Studio startet nach dem Upgrade nicht

Wenn Studio nach einem Upgrade nicht startet, liegt das Problem möglicherweise an einer ungültigen Android Studio-Konfiguration, die aus einer früheren Version von Android Studio importiert wurde, oder an einem inkompatiblen Plug-in. Als Problemumgehung können Sie versuchen, das unten aufgeführte Verzeichnis zu löschen (oder zu Sicherungszwecken umzubenennen) und Android Studio neu zu starten. Das Verzeichnis hängt von der Android Studio-Version und dem Betriebssystem ab. 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 Beta-Releases von Android Studio ist PreviewX.Y anstelle von X.Y für die <version>. In Android Studio 4.1-Canary-Builds wird beispielsweise AndroidStudioPreview4.1 anstelle des Verzeichnisses AndroidStudio4.1 verwendet, das für Release Candidates und stabile Releases verwendet wird.

Kompilierungsproblem in Kotlin Multiplatform-Projekten

In Kotlin-MPP-Code können aufgrund fehlender Symbole Kompilierungsfehler auftreten. Dieses Problem sollte durch ein Upgrade Ihres Kotlin-Plug-ins auf Version 1.4 behoben werden.

Konflikte bei der Tastenzuordnung unter Linux

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

Weitere Informationen zu diesem Problem (einschließlich möglicher Problemumgehungen) finden Sie im Bugtracker von IntelliJ.

Kleiner UI-Text in ChromeOS

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

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

Code bearbeiten

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

Eingabe über die Tastatur reagiert nicht – „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 Tastatureingaben oder gibt zufällige Zeichen ein. Dieser Fehler wird durch eine fehlende Synchronisierung zwischen iBus und XLib + AWT ausgelöst und wurde bereits 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 Start von Android Studio Folgendes in der Befehlszeile aus: 
    $ IBUS_ENABLE_SYNC_MODE=1 ibus-daemon -xrd
  • Problemumgehung 2:iBus-Eingabe in Android Studio deaktivieren Wenn Sie die iBus-Eingabe nur für Android Studio deaktivieren möchten, führen Sie Folgendes in der Befehlszeile aus: 
    $ XMODIFIERS= ./bin/studio.sh
     Mit dieser Problemumgehung werden Eingabemethoden nur für Android Studio deaktiviert, nicht für andere Anwendungen, die Sie möglicherweise ausführen. Wenn Sie den Daemon neu starten, während Android Studio ausgeführt wird (z. B. durch Ausführen von ibus-daemon -rd), werden die Eingabemethoden für alle anderen Anwendungen deaktiviert. Außerdem kann es zu einem Segmentierungsfehler in der JVM von Android Studio kommen.
  • Problemumgehung 3:Prüfen Sie die Tastenkombinationen, um sicherzustellen, dass die Tastenkombination für die nächste Eingabe nicht auf Strg+Leertaste festgelegt ist, da dies auch die Tastenkombination für die Codevervollständigung in Android Studio ist. In Ubuntu 14.04 (Trusty) ist Super + Leertaste die Standardtastenkombination, aber Einstellungen aus früheren Versionen sind möglicherweise noch vorhanden. Führen Sie ibus-setup in der Befehlszeile aus, um das Fenster „IBus Preferences“ (IBus-Einstellungen) zu öffnen und die Tastenkürzelbindungen zu prüfen. Sehen Sie unter Tastenkombinationen nach, ob Nächste Eingabemethode aktiviert ist. Wenn sie auf „Strg + Leertaste“ festgelegt ist, ändern Sie sie in „Super + Leertaste“ oder eine andere Tastenkombination Ihrer Wahl.

Projektkonfiguration

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

Fehler bei der Gradle-Synchronisierung: Broken Pipe

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

  • Problemumgehung 1: Fügen 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 Networking IPv6 User Guide.

„peer not authenticated“-Fehler 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 Sie einen Proxy verwenden, versuchen Sie, eine direkte Verbindung herzustellen. Wenn die direkte Verbindung funktioniert, müssen Sie möglicherweise keytool verwenden, um das Zertifikat des Proxyservers der Datei „cacerts“ hinzuzufügen, damit eine Verbindung über den Proxy hergestellt werden kann.
  • Installieren Sie ein unterstütztes, unverändertes JDK neu. Es gibt ein bekanntes Problem, das Ubuntu-Nutzer betrifft und dazu führt, dass /etc/ssl/certs/java/cacerts leer ist. Führen Sie Folgendes in der Befehlszeile aus, um dieses Problem zu umgehen: 
    sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

Bereitstellung

In diesem Abschnitt werden bekannte Probleme beim Bereitstellen Ihrer App auf einem verbundenen Gerät beschrieben.

[Nur Mac OS] Inkrementelle Updates werden aufgrund eines Problems mit der Gradle-Dateiüberwachung für Projekte, die unter /System/Volumes/Data gespeichert sind, nicht angewendet.

Gradle-Problem 18149 betrifft Android-Gradle-Plug-in-Versionen 7.0 und höher, da sie Gradle-Version 7.0 und höher erfordern. 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 werden dem Build-System keine Dateiänderungen angezeigt und die APKs werden nicht aktualisiert. Der Code für die inkrementelle Bereitstellung führt dann keine Aktion 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 durch die Gradle-Dateiüberwachung ordnungsgemäß über Dateiänderungen informiert und inkrementelle Änderungen werden erfolgreich angewendet.

Android Emulator HAXM unter macOS High Sierra

Für den Android-Emulator unter macOS High Sierra (10.13) ist HAXM 6.2.1 oder höher erforderlich, um eine optimale Kompatibilität und Stabilität mit macOS zu gewährleisten. Unter macOS 10.13 ist die Installation von Kernel-Erweiterungen wie HAXM jedoch aufwendiger. Sie müssen die Installation der Kernel-Erweiterung selbst manuell zulassen:

  1. Versuchen Sie zuerst, die aktuelle Version von HAXM über den SDK Manager zu installieren.
  2. Gehen Sie unter macOS zu Systemeinstellungen > Sicherheit & Datenschutz.

  3. Wenn Sie eine Benachrichtigung sehen, dass Laden der Systemsoftware des Entwicklers „Intel Corporation Apps“ wurde blockiert, klicken Sie auf Erlauben:

Weitere Informationen und Problemumgehungen finden Sie auf dieser Apple-Webseite und in Problem 62395878.

Änderungen übernehmen

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

Neuer App-Name wurde nicht angewendet

Wenn Sie Ihre App umbenennen und dann versuchen, diese Änderung zu übernehmen, wird der aktualisierte Name möglicherweise nicht angezeigt. Klicken Sie auf Ausführen Symbol „Run“, um Ihre App noch einmal bereitzustellen und die Änderungen zu sehen.

Problem in Android-Laufzeit löst Fehler aus

Wenn Sie ein Gerät mit Android 8.0 oder 8.1 verwenden, werden möglicherweise „VERIFICATION_ERROR“-Meldungen angezeigt, wenn Sie versuchen, bestimmte Arten von Änderungen vorzunehmen (insbesondere wenn Sie Kotlin verwenden). Diese Meldung wird durch ein Problem mit der Android-Laufzeit verursacht, das in Android 9.0 und höher behoben wurde. Obwohl das Problem dazu führt, dass „Änderungen anwenden“ fehlschlägt, können Sie Ihre App trotzdem noch einmal ausführen Symbol „Run“, 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 Debuggen und Testen Ihrer App beschrieben.

Bei JUnit-Tests fehlen Ressourcen im Klassenpfad, wenn sie über Android Studio ausgeführt werden

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

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

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

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

Wenn Sie ein neues Projekt erstellen, wird die JUnit-Konfiguration der Vorlage möglicherweise mit zwei Schritten vom Typ „Vor dem Start“ erstellt: „Make“ und „Gradle-aware Make“. Diese Konfiguration wird dann auf alle erstellten JUnit-Laufzeitkonfigurationen übertragen.

  • Um das Problem für das aktuelle Projekt zu beheben, klicken Sie auf Run > Edit Configurations (Ausführen > Konfigurationen bearbeiten) und ändern Sie die Standard-JUnit-Konfiguration so, dass sie nur den Gradle-kompatiblen Make-Schritt enthält.
  • Wenn Sie das Problem für alle zukünftigen Projekte beheben möchten, klicken Sie auf Datei > Projekt schließen. Sie sollten den Willkommensbildschirm sehen. Klicken Sie dann auf Konfigurieren > Projektstandardeinstellungen > Ausführungskonfigurationen und ändern Sie die JUnit-Konfiguration so, dass sie nur den Gradle-kompatiblen Make-Schritt enthält.

Einige Testlaufkonfigurationen funktionieren nicht

Nicht alle Ausführungskonfigurationen, die beim Rechtsklicken auf eine Testmethode verfügbar sind, sind gültig. Die folgenden Konfigurationen sind nicht gültig:

  • Gradle-Ausführungskonfigurationen (mit einem Gradle-Logo als Symbol) funktionieren nicht.
  • JUnit-Ausführungskonfigurationen (mit einem Symbol ohne das grüne Android) gelten nicht für Instrumentierungstests, die nicht in der lokalen JVM ausgeführt werden können.
Android Studio merkt sich auch die in einem bestimmten Kontext erstellte Ausführungskonfiguration (z. B. durch Klicken mit der rechten Maustaste auf eine bestimmte Klasse oder Methode) und bietet in Zukunft keine andere Konfiguration an. Klicken Sie zur Behebung des Problems auf Run > Edit Configurations (Ausführen > Konfigurationen bearbeiten) und entfernen Sie die falsch erstellten Konfigurationen.

Java-Breakpoints beim Debuggen von nativem Code hinzufügen

Wenn Ihre App an einem Haltepunkt in Ihrem nativen Code pausiert wird, erkennen die Debugger Auto und Dual möglicherweise nicht sofort neue Java-Haltepunkte, die Sie festlegen. Um dieses Problem zu vermeiden, fügen Sie Java-Haltepunkte entweder vor dem Start einer Debugging-Sitzung oder während die App an einem Java-Haltepunkt pausiert ist hinzu. Weitere Informationen finden Sie unter Problem 229949.

Aus dem nativen Debugger aussteigen

Wenn Sie den Debugger Auto oder Dual verwenden, um Java- und nativen Code zu debuggen, und Sie in eine native Funktion aus Ihrem Java-Code gehen (z. B. wenn der Debugger die Ausführung in einer Zeile Ihres Java-Codes unterbricht, in der eine native Funktion aufgerufen wird, und Sie auf Step Into klicken) und Sie zu Ihrem Java-Code zurückkehren möchten, klicken Sie auf Resume Program (anstatt auf Step Out oder Step Over ). Der Prozess Ihrer App wird weiterhin pausiert. Klicken Sie daher auf dem Tab your-module-java auf Resume Program , um ihn fortzusetzen. Weitere Informationen finden Sie unter Problem 224385.

Der native Debugger hängt beim Laden von Bibliotheken

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

Der native Debugger stürzt mit der Meldung „Debugger process finished with exit code 127“ ab.

Dieser Fehler tritt auf Linux-basierten Plattformen auf, wenn der native Debugger gestartet wird. Dies weist darauf hin, 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 angegeben. Falls nicht, können Sie ein Terminal verwenden, um zum Installationsverzeichnis von Android Studio zu navigieren und die Befehlszeile bin/lldb/bin/LLDBFrontend --version auszuführen, um herauszufinden, welche Bibliotheken fehlen. Normalerweise ist die fehlende Bibliothek ncurses5, da einige aktuelle Linux-Distributionen bereits auf ncurses6 aktualisiert wurden.

Profiler

In diesem Abschnitt werden bekannte Probleme mit den Profilern beschrieben.

Native Memory Profiler: Profilerstellung beim App-Start nicht verfügbar

Der Native Memory Profiler ist derzeit während des App-Starts nicht verfügbar. Diese Option wird in einer künftigen Version verfügbar sein.

Als Workaround können Sie den eigenständigen Perfetto-Befehlszeilenprofiler verwenden, um Startprofile zu erfassen.

Zeitüberschreitungsfehler im CPU Profiler

Im Android Studio CPU Profiler können Fehler vom Typ „Aufzeichnung konnte nicht beendet werden“ auftreten, wenn Sie die Konfigurationen Sample Java Methods (Java-Methoden analysieren) oder Trace Java Methods (Java-Methoden aufzeichnen) auswählen. Häufig handelt es sich dabei um Zeitüberschreitungsfehler, insbesondere wenn Sie die folgende Fehlermeldung in der Datei idea.log sehen:

Wait for ART trace file timed out

Die Zeitüberschreitungsfehler wirken sich tendenziell stärker auf verfolgte Methoden als auf Methoden mit Stichprobenerhebung und auf längere Aufzeichnungen als auf kürzere Aufzeichnungen aus. Als vorübergehende Problemumgehung kann es hilfreich sein, kürzere Aufnahmen zu versuchen, um zu sehen, ob der Fehler dadurch behoben wird.

Wenn beim Profiler Zeitüberschreitungsprobleme auftreten, reichen Sie einen Fehlerbericht ein, der die Marke und das Modell Ihres Geräts bzw. Ihrer Geräte sowie alle relevanten Einträge aus idea.log und logcat enthält.

ADB-Ausnahme beim Debuggen oder Erstellen von Profilen

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

So aktualisieren Sie die Plattformtools:

  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. Klicke das Kästchen neben Android SDK Platform-Tools an, sodass ein Häkchen angezeigt wird. In der linken Spalte sollte ein Downloadsymbol  angezeigt werden.

  3. Klicken Sie auf Übernehmen oder OK.

Plug-in verhindert, dass das Fenster „Build Output“ funktioniert

Wenn Sie das Plug-in CMake simple highlighter verwenden, werden Inhalte nicht im Fenster „Build Output“ (Build-Ausgabe) angezeigt. Der Build wird ausgeführt und der Tab „Build-Ausgabe“ wird angezeigt, aber es wird keine Ausgabe ausgegeben (Problem 204791544).

Starten durch Installationsreihenfolge verhindert

Wenn Sie eine neuere Version von Android Studio vor einer älteren Version installieren, kann es sein, dass die ältere Version nicht gestartet werden kann. 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 zum Leeren des Caches das Verzeichnis Library/ApplicationSupport/Google/AndroidStudioversion_number. 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 mit Compose finden Sie unter Compose-Layout testen.

Logcat-Tastenkombinationen sind mit nicht englischen Tastaturlayouts nicht kompatibel

Wenn Sie ein nicht englisches Tastaturlayout verwenden, kann ein standardmäßiger Logcat-Tastenkürzel mit dem Layout in Konflikt geraten und verhindern, dass Sie bestimmte Zeichen eingeben, wenn Sie Text in Android Studio bearbeiten. Um dieses Problem zu umgehen, löschen Sie die in Konflikt stehende Logcat-Tastenzuordnung oder ordnen Sie sie neu zu. Wenn Sie die Logcat-Tastenzuordnungen in Android Studio bearbeiten möchten, gehen Sie zu Android Studio > Einstellungen > Tastenzuordnung und suchen Sie in der Liste der Tastenzuordnungen 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 aktuellen stabilen Version des Android-Gradle-Plug-ins beschrieben.

Nicht alle Abhängigkeiten von Dynamic-Feature-Bibliotheken werden mit Lint geprüft

Wenn Sie Lint mit checkDependencies = true in einem App-Modul ausführen, werden Abhängigkeiten von Dynamic-Feature-Bibliotheken nur geprüft, wenn sie auch App-Abhängigkeiten sind (Problem 191977888). Als Workaround kann der Lint-Task für diese Bibliotheken ausgeführt werden.

Signaturdatei mit Namen, der Zeichen für Zeilenumbruch enthält

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

Das Ändern von Variantenausgaben zur Build-Zeit funktioniert möglicherweise nicht

Die Verwendung der Variant API zum Bearbeiten von Variantenausgaben funktioniert mit dem neuen Plug-in nicht mehr. Für einfache Aufgaben wie das Ändern des APK-Namens während der Build-Zeit funktioniert es weiterhin, 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, bei denen auf outputFile-Objekte zugegriffen werden muss, funktionieren jedoch nicht mehr. Das liegt daran, dass während der Konfigurationsphase keine variantenspezifischen Aufgaben mehr erstellt werden. Das bedeutet, dass das Plug-in nicht alle Ausgaben im Voraus kennt, aber auch, dass die Konfiguration schneller erfolgt.

manifestOutputFile ist nicht mehr verfügbar

Die Methode processManifest.manifestOutputFile() ist nicht mehr verfügbar. Wenn Sie sie aufrufen, wird der folgende 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 in 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 Build-Varianten entfernt. Sie können weiterhin die anderen AIDL-Quellsätze verwenden, einschließlich derer von main/, Build-Typen, Produktvarianten und Kombinationen von Produktvarianten. Wenn Sie die variantspezifischen AIDL-Quellsätze verwenden müssen, verwenden Sie weiterhin Kotlin 1.6.21.

Behobene bekannte Probleme

In diesem Abschnitt werden bekannte Probleme beschrieben, die in einem aktuellen Release behoben wurden. Wenn eines dieser Probleme bei Ihnen auftritt, sollten Sie Android Studio auf die neueste stabile Version aktualisieren oder die Preview-Version verwenden.

In Android Studio 2021.1.1 behoben

  • Fehlende Lint-Ausgabe: Es wird keine Lint-Textausgabe in stdout ausgegeben, wenn die Lint-Aufgabe UP-TO-DATE ist (Problem 191897708). Behoben in AGP 7.1.0-alpha05.
  • Probleme beim Unittesting eines App-Projekts, das das Hilt-Plug-in verwendet: Der Unittest-Klassenpfad enthält die nicht instrumentierten App-Klassen. Das bedeutet, dass Hilt die App-Klassen nicht instrumentiert, um die Abhängigkeitsinjektion beim Ausführen von Unittests zu verarbeiten (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 Nullzeiger-Ausnahmen 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

  • Neu starten, um Speichereinstellungen aus der vorherigen Version der IDE anzuwenden:Nach dem Aktualisieren von Android Studio müssen Sie Android Studio neu starten, damit alle Speichereinstellungen angewendet werden, die aus einer früheren Version der IDE migriert wurden.
  • Manifest-Klasse mit benutzerdefinierten Berechtigungsstrings wird nicht mehr standardmäßig generiert:Wenn Sie die Klasse generieren möchten, legen Sie android.generateManifestClass = true fest.

In Android Studio 3.6 behoben

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

    In Android Studio 3.6 Beta 1 und höher wird diese Ausnahme von der IDE abgefangen. Wenn Sie Ihre App auf LineageOS- oder CyanogenMod-Geräten bereitstellen, wird die App vollständig installiert. Das kann zu längeren Bereitstellungszeiten führen.

In Android Studio 3.5.2 behoben

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

In Android Studio 3.3.1 behoben

  • „Out of memory“-Fehler beim Scannen von C++-basierten Projekten: Wenn Gradle ein Projekt scannt, das C++-Code an mehreren Stellen auf demselben Laufwerk enthält, umfasst der Scan alle Verzeichnisse unter dem ersten gemeinsamen Verzeichnis. Das Scannen einer großen Anzahl von Verzeichnissen und Dateien kann zu Speicherfehlern führen.

    Weitere Informationen zu diesem Problem finden Sie im Fehlerbericht.