Diese Seite wurde von der Cloud Translation API übersetzt.

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

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

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 die Vorabversion von Android Studio herunter und installieren Sie sie.

Bekannte Probleme mit Android Studio

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

Kotlin 2.0: Lambdas können im Layout Inspector nicht aufgelöst werden

Bei Verwendung von Kotlin 2.0 können Lambdas nicht aufgelöst werden und der Layout Inspector kann nicht wie gewohnt zum Quellcode des Lambda navigieren.

Problemumgehung: Fügen Sie die Compileroption unten als Problemumgehung hinzu, bis dieses Problem behoben ist:

kotlin {
  compilerOptions {
    freeCompilerArgs.add("-Xlambdas=class")
  }
}

Ausführung der Konfiguration ohne ein Gradle-aware Make „vor dem Start“ führt zu einem Bereitstellungsfehler

In der Ladybug-Funktionsversion Canary 9 von Android Studio wurden Informationen zur Ausführungskonfiguration aus Projekten entfernt, die mit dieser Version geöffnet wurden. Wenn Sie Ihr Projekt einmal mit dieser Version geöffnet haben und beim Ausführen Ihrer App der Fehler „Build-Artefakte werden geladen“ auftritt, prüfen Sie, ob die aktive Ausführungskonfiguration im Abschnitt „Vor dem Start“ den Schritt „Gradle-aware Make“ enthält. Klicken Sie dazu auf Konfigurationen ausführen/debuggen > Konfigurationen bearbeiten, klicken Sie auf die aktive Ausführungskonfiguration und prüfen Sie, ob im Abschnitt „Vor dem Start“ der Schritt „Gradle-aware Make“ vorhanden ist. Leider kann dieses Problem in Android Studio nicht automatisch behoben werden, da einige Ausführungskonfigurationen möglicherweise absichtlich ohne den Schritt „Gradle-aware Make“ eingerichtet wurden.

Die Aktivität wird bei Geräten oder Emulatoren mit API-Level 35 nicht durch „Änderungen übernehmen und Aktivität neu starten“ neu gestartet

Wenn Sie Codeänderungen mit „Änderungen übernehmen 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-Assistentenfenster wird eine Fehlermeldung angezeigt

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

Ansicht mit dem 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 dem Layout Inspector geprüft werden

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

Fehler beim Rendern der Vorschau in Compose

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 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 > Signierten Bundle erstellen / APK aufrufen und versuchen, die App-Signatur für ein App-Bundle oder ein APK zu konfigurieren, kann das Eingeben verschiedener Passwörter für den Schlüssel und den 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

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 Datenbank Inspector verwenden, können beim Ausführen im Android 11-Emulator abstürzen. In Logcat wird dann 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 <version>. Bei Android Studio 4.1-Canary-Builds wird beispielsweise AndroidStudioPreview4.1 anstelle des Verzeichnisses AndroidStudio4.1 verwendet, das für Release-Kandidaten 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 potenzieller Problemumgehungen) finden Sie im IntelliJ-Bug-Tracker.

Kleiner UI-Text in ChromeOS

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

Öffnen Sie das Fenster Einstellungen, indem Sie auf Datei > Einstellungen klicken.
Gehen Sie zu Darstellung und Verhalten > Darstellung.
Wählen Sie Benutzerdefinierte Schriftart verwenden aus.
Vergrößern Sie die Schriftgröße.
Klicken Sie im Fenster Einstellungen auf Editor > Schriftart.
Vergrößern Sie die Schriftgröße.
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 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 Eingabemethoden 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 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.
Problemumgehung 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 in der Befehlszeile ibus-setup ein, um das IBus-Fenster mit den Einstellungen zu öffnen. Klicken Sie unter Tastenkombinationen auf das Kästchen 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.

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 Netzwerk-IPv6-Nutzerhandbuch.

„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 sich hinter einem Proxy befinden, versuchen Sie, 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 neu. Es gibt ein bekanntes Problem, das Ubuntu-Nutzer betrifft und zu einer leeren /etc/ssl/certs/java/cacerts führt. Führen Sie in der Befehlszeile Folgendes aus, um dieses Problem zu umgehen:
```
sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure
```

Bereitstellung

In diesem Abschnitt werden bekannte Probleme beschrieben, die beim Bereitstellen Ihrer App auf einem verbundenen Gerät auftreten können.

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

Das Gradle-Problem 18149 wirkt sich auf Android-Gradle-Plug-ins ab Version 7.0 aus, da für diese 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 werden dem Build-System keine Dateiänderungen angezeigt und die APKs werden daher nicht aktualisiert. Der Code für die inkrementelle Bereitstellung führt dann nichts aus, da der lokale APK-Status mit dem auf dem Gerät identisch ist.

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 Kernelerweiterung selbst manuell zulassen:

Versuchen Sie zuerst, die neueste Version von HAXM über den SDK-Manager zu installieren.
Gehen Sie unter macOS zu Systemeinstellungen > Sicherheit und Datenschutz.
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 übernehmen beschrieben.

Neuer App-Name nicht übernommen

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 Runtime 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 übernommen werden, 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 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. 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 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 die Gradle-check-Aufgabe in 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 unter 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.

Klicken Sie auf Ausführen > Konfigurationen bearbeiten, um das Problem für das aktuelle Projekt zu beheben. Ändern Sie die Standard-JUnit-Konfiguration so, dass nur der Gradle-kompatible Make-Schritt enthalten ist.
Wenn Sie das Problem für alle zukünftigen Projekte beheben möchten, klicken Sie auf Datei > Projekt schließen. Daraufhin wird der Begrüßungsbildschirm 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 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 Ausführungskonfiguration, die in einem bestimmten Kontext erstellt wurde (z. B. durch Klicken mit der rechten Maustaste auf eine bestimmte Klasse oder Methode), und bietet in Zukunft keine Möglichkeit, in einer anderen Konfiguration auszuführen. Klicken Sie zum Beheben dieses Problems auf Ausführen > Konfigurationen bearbeiten und entfernen Sie die fälschlicherweise erstellten Konfigurationen.

Java-Breakpoints beim Debuggen von nativem Code hinzufügen

Während Ihre App an einem Haltepunkt in Ihrem nativen Code angehalten wird, erkennen die Debugger Auto und Dual möglicherweise nicht sofort neue Java-Haltepunkte, die Sie setzen. Um dieses Problem zu vermeiden, füge Java-Bruchstellen entweder vor Beginn einer Debug-Sitzung hinzu oder während die App an einem Java-Bruchpunkt angehalten wird. Weitere Informationen finden Sie unter Problem 229949.

Aus dem nativen Debugger aussteigen

Wenn Sie mit dem Auto- oder Dual-Debugger Java- und nativen Code debuggen und aus Ihrem Java-Code in eine native Funktion wechseln (z. B. wenn der Debugger die Ausführung an einer Zeile in deinem Java-Code anhält, die eine native Funktion aufruft, und Sie auf Step Into klicken) und 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.

Der native Debugger hängt beim Laden von Bibliotheken

Wenn Sie den nativen Debugger nach dem Upgrade auf Android Studio 4.2 oder höher zum ersten Mal verwenden, reagiert er 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.

Der native Debugger stürzt mit der Meldung „Debugger process finished with exit code 127“ (Debuggerprozess mit Exit-Code 127 beendet) 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 ausgegeben. 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 beim Start der App nicht verfügbar

Der native Speicher-Profiler ist beim Start der App derzeit nicht verfügbar. Diese Option wird in einer künftigen Version verfügbar sein.

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

Zeitüberschreitungsfehler im CPU Profiler

Wenn Sie die Konfigurationen Java-Methoden beispielhaft ausführen oder Java-Methoden erfassen auswählen, wird im Android Studio-CPU-Profiler möglicherweise der Fehler „Aufzeichnung konnte nicht beendet werden“ angezeigt. 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 Aufzeichnungen 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 Ihrer Geräte 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 Version 29.0.4 oder höher werden beide Probleme behoben.

So aktualisieren Sie die Plattformtools:

Öffnen Sie den SDK-Manager in Android Studio, indem Sie auf Tools > SDK-Manager oder in der Symbolleiste auf SDK-Manager klickst.

Klicken Sie das Kästchen neben Android SDK-Plattformtools an. In der linken Spalte sollte das Downloadsymbol angezeigt werden.

Klicken Sie auf Übernehmen oder OK.

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

Mit dem Plug-in CMake simple highlighter werden Inhalte im Fenster „Build-Ausgabe“ nicht angezeigt. Der Build wird ausgeführt und der Tab „Build-Ausgabe“ wird angezeigt, aber es wird keine Ausgabe gedruckt (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 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.

Tastenkombination für Logcat kollidiert mit Tastaturlayouts (ausgenommen Englisch)

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 Sie die kollidierende Logcat-Tastaturbelegung oder ordnen Sie sie neu zu, um dieses Problem zu umgehen. Wenn Sie die Logcat-Tastaturbelegungen in Android Studio bearbeiten möchten, rufen Sie Android Studio > Einstellungen > Tastaturbelegung auf und suchen Sie in der Liste der Tastaturbelegungen 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 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 für diese Bibliotheken ausgeführt werden.

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

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

Das Ändern von Variantenausgaben während der Build-Erstellung funktioniert möglicherweise nicht

Die Verwendung der Variant API zum Manipulieren von Variantenausgaben funktioniert mit dem neuen Plug-in nicht. Sie funktioniert jedoch weiterhin für einfache Aufgaben wie das Ändern des APK-Namens während der Build-Erstellung, 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. Beim Aufruf der Methode 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 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-Source-Sets für bestimmte Buildvarianten entfernt. Sie können weiterhin die anderen AIDL-Source-Sets verwenden, einschließlich derjenigen von main/, Buildtypen, Produktvarianten und Kombinationen von Produktvarianten. Wenn Sie die variantenspezifischen AIDL-Source-Sets verwenden müssen, verwenden Sie weiterhin Kotlin 1.6.21.

Behobene bekannte Probleme

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, wird keine Lint-Textausgabe an stdout ausgegeben (Problem 191897708). In AGP 7.1.0-alpha05 behoben.
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.
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 behandelt 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

„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 Artikel zum Fehler.

Bekannte Probleme mit Android Studio und dem Android Gradle-Plug-in Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.