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

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

Upgrade auf Vorabversion:Jede Version von Android Studio und das Android Gradle-Plug-in zielt darauf ab, Stabilität und Leistung zu verbessern und neue Funktionen hinzuzufügen. Wenn du die Vorteile der kommenden Releases jetzt nutzen möchtest, lade die Vorschau von Android Studio herunter und installiere sie.

Bekannte Probleme bei Android Studio

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

Fenster des Firebase Assistant mit Fehlermeldung

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

Nicht alle Erstellungsknoten können mit dem Layout Inspector überprüft werden

Wenn Sie mit dem Layout Inspector nicht alle Knoten der Erstellung überprüfen können, liegt wahrscheinlich ein Fehler vor, der in der 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 durch.

Fehler beim Rendern der Vorschau „Compose“

Wenn in Android Studio Chipmunk java.lang.NoSuchFieldError: view_tree_saved_state_registry_owner oder java.lang.ClassNotFoundException: androidx.savedstate.R$id im Bereich „Probleme“ angezeigt wird, musst du in deinem Modul eine debugImplementation-Abhängigkeit zu androidx.lifecycle:lifecycle-viewmodel-savedstate angeben.

Wenn im Bereich „Probleme“ java.lang.NoSuchFieldError: view_tree_lifecycle_owner angezeigt wird, füge in deinem Modul eine debugImplementation-Abhängigkeit von androidx.lifecycle:lifecycle-runtime hinzu.

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, füge in deinem Modul eine debugImplementation-Abhängigkeit von androidx.customview:customview-poolingcontainer hinzu.

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

Ab Version 4.2 wird Android Studio jetzt unter JDK 11 ausgeführt. Diese Aktualisierung 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 die Eingabe 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

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

Android Studio wird nach der Installation von Version 4.2 nicht gestartet

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

Zur Umgehung dieses Problems empfehlen wir, benutzerdefinierte Optionen in .vmoptions mithilfe des Zeichens „#“ auskommentieren. Die .vmoptions-Datei 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 Ausprobieren dieser Problemumgehung immer noch nicht gestartet wird, lesen Sie den Abschnitt Studio wird nach dem Upgrade nicht gestartet weiter unten.

Apps, die Database Inspector im Android 11-Emulator nutzen

Anwendungen, die den Database 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)

Um dieses Problem zu beheben, aktualisiere deinen Android 11-Emulator auf Version 9 oder höher. Rufe dazu Tools > SDK-Manager auf. Klicke auf dem Tab SDK-Plattformen das Kästchen Paketdetails anzeigen an und wähle Version 9 oder höher des Android 11-Emulators aus.

Studio startet nach dem Upgrade nicht

Wenn Studio nach einem Upgrade nicht gestartet wird, wird das Problem möglicherweise durch eine ungültige Android Studio-Konfiguration verursacht, die aus einer früheren Version von Android Studio importiert wurde, oder auf ein inkompatibles Plug-in. Um das Problem zu umgehen, können Sie je nach Android Studio-Version und Betriebssystem das unten aufgeführte Verzeichnis löschen (oder zu Sicherungszwecken umbenennen) und Android Studio neu starten. Dadurch wird Android Studio auf den Standardstatus zurückgesetzt. Alle Drittanbieter-Plug-ins werden dabei 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

Hinweis: Das Konfigurationsverzeichnis für Canary- und Beta-Releases von Android Studio ist PreviewX.Y anstelle von X.Y für <version>. Android Studio 4.1 Canary-Builds verwenden beispielsweise AndroidStudioPreview4.1 anstelle des Verzeichnisses AndroidStudio4.1, das für Release-Kandidaten und stabile Releases verwendet wird.

Kompilierungsproblem in plattformübergreifenden Kotlin-Projekten

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

Konflikte bei der Schlüsselzuordnung unter Linux

Unter Linux verursachen bestimmte Tastenkombinationen Konflikte mit standardmäßigen Linux-Tastenkombinationen 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 möglicher Problemumgehungen) finden Sie im Programmfehler-Tracker von IntelliJ.

Kleiner UI-Text unter ChromeOS

Unter ChromeOS ist der Text möglicherweise viel kleiner als in früheren Releases. So umgehen Sie dieses 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. Klicke auf OK.

Codebearbeitung

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

Eingefrorene Tastatureingabe - Probleme mit "iBus" unter Linux

Es gibt einige bekannte Interaktionen zwischen dem iBus-Daemon unter Linux und Android Studio. In einigen Szenarien reagiert die IDE nicht mehr auf die Tastatureingabe oder beginnt mit der Eingabe von Zufallszeichen. Dieser Fehler wird durch eine fehlende Synchronisierung zwischen iBus und XLib und AWT ausgelöst und wurde bereits vorgelagert an JetBrains und iBus gemeldet. Für dieses Problem gibt es derzeit drei Lösungen:

• Problemumgehung 1:Erzwingen Sie iBus in den synchronen Modus. Bevor Sie Android Studio starten, führen Sie 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 folgenden Befehl in der Befehlszeile aus:

  $ XMODIFIERS= ./bin/studio.sh

  Bei dieser Umgehung werden nur Eingabemethoden für Android Studio deaktiviert, nicht für andere Anwendungen, die Sie möglicherweise verwenden. Wenn Sie den Daemon neu starten, während Android Studio ausgeführt wird (z. B. durch Ausführen von ibus-daemon -rd), deaktivieren Sie effektiv die Eingabemethoden für alle anderen Anwendungen. Außerdem kann die JVM von Android Studio mit einem Segmentierungsfehler abstürzen.
• Problemumgehung 3: Überprüfen Sie die Verknüpfungsbindungen, 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) wird Super+Space als Standardverknüpfung verwendet. Einstellungen aus früheren Versionen sind jedoch möglicherweise noch verfügbar. Um die Verknüpfungsbindungen zu prüfen, führen Sie ibus-setup in der Befehlszeile aus, um das Fenster „IBus-Einstellungen“ zu öffnen. Aktivieren Sie unter Tastenkombinationen die Option Nächste Eingabemethode. 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 Gradle-Synchronisierung beschrieben.

Gradle-Synchronisierung fehlgeschlagen: Defekte Pipe

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

• Problemumgehung 1: Unter Linux geben Sie Folgendes in Ihr ~/.profile oder ~/.bash_profile ein:

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

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

Fehler vom Typ „Peer nicht authentifiziert“ aus der Gradle-Synchronisierung oder dem 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 keytool verwenden, um das Zertifikat des Proxyservers der Cacerts-Datei hinzuzufü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. Dies führt zu einem leeren /etc/ssl/certs/java/cacerts. Führen Sie folgenden Befehl in der Befehlszeile aus, um dieses Problem zu umgehen:

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

Wird bereitgestellt

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

[Nur Mac OS] Inkrementelle Updates werden nicht angewendet, weil es ein Problem bei der Überwachung von Gradle-Dateien in Projekten gibt, die unter /System/Volumes/Data gespeichert sind

Das Gradle-Problem 18149 betrifft die Android Gradle-Plug-in-Version 7.0 und höher, da diese Gradle-Version 7.0 oder höher erfordert. 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 von der Gradle-Dateiüberwachung nicht richtig verfolgt. Dies führt dazu, dass das Build-System keine Dateiänderungen erkennt und die APKs daher nicht aktualisiert werden. Der inkrementelle Bereitstellungscode reagiert dann nichts, da der lokale APK-Status mit dem auf dem Gerät übereinstimmt.

Zur Umgehung dieses Problems sollten Sie das Verzeichnis Ihres Projekts in Ihr Nutzerverzeichnis unter /Users/username verschieben. Das Build-System wird dann durch die Gradle-Dateiüberwachung ordnungsgemäß über Dateiänderungen benachrichtigt und die inkrementellen Änderungen werden erfolgreich angewendet.

Android-Emulator HAXM auf macOS High Sierra

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

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

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

   

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

Änderungen übernehmen

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

Neuer App-Name nicht angewendet

Wenn Sie die Anwendung umbenennen und dann versuchen, diese Änderung anzuwenden, wird der aktualisierte Name möglicherweise nicht berücksichtigt. Klicken Sie zur Umgehung dieses Problems auf Ausführen , um die Anwendung noch einmal bereitzustellen und die Änderungen zu sehen.

Problem in Android Runtime führt zu Fehler

Wenn Sie ein Gerät mit Android 8.0 oder 8.1 verwenden, wird möglicherweise die Meldung „VERIFICATION_ERROR“ angezeigt, wenn Sie bestimmte Arten von Änderungen anwenden möchten (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 übernehmen“ fehlschlägt, können Sie die Anwendung trotzdem noch einmal ausführen , um Ihre Änderungen zu sehen. Wir empfehlen jedoch ein Upgrade auf Android 9.0 oder höher.

Fehlerbehebung und Tests

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

JUnit testet fehlende Ressourcen im Klassenpfad bei Ausführung über Android Studio

Wenn Ihre Java-Module bestimmte Ressourcenordner haben, werden diese Ressourcen beim Ausführen von Tests über die IDE nicht gefunden. Es funktioniert also, Tests mit Gradle über die Befehlszeile auszuführen. Die Ausführung der Gradle-Aufgabe check über die IDE funktioniert ebenfalls. Weitere Informationen finden Sie unter Problem 64887.

Dieses Problem tritt auf, da ab IntelliJ 13 nur ein einziger Ordner als Klassenpfad vorhanden sein muss. Der Builder von IntelliJ kopiert alle Ressourcen in diesen Build-Ordner, Gradle kopiert jedoch nicht die Ressourcen.

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

Beim Ausführen von JUnit-Tests kann der Code zweimal kompiliert werden

Wenn Sie ein neues Projekt erstellen, müssen Sie zum Erstellen der JUnit-Vorlagenkonfiguration zwei Schritte namens „Vor dem Start“ ausführen: „Make“ und „Gradle-aware Make“. Diese Konfiguration wird dann für alle erstellten JUnit-Ausführungskonfigurationen übernommen.

• Klicken Sie auf Run > Edit Configurations (Ausführen > Konfigurationen bearbeiten), um das Problem für das aktuelle Projekt zu beheben. Ändern Sie dann die JUnit-Standardkonfiguration so, dass sie nur den Gradle-fähigen Make-Schritt enthält.
• Klicken Sie auf Datei > Projekt schließen, um das Problem für alle zukünftigen Projekte zu beheben. Der Begrüßungsbildschirm sollte angezeigt werden. Klicken Sie dann auf Konfigurieren > Projektstandard > Ausführungskonfigurationen und ändern Sie die JUnit-Konfiguration so, dass nur der Gradle-aware Mac-Schritt enthalten ist.

Einige Testlaufkonfigurationen funktionieren nicht

Nicht alle Ausführungskonfigurationen, die verfügbar sind, wenn mit der rechten Maustaste auf eine Testmethode geklickt wird, sind gültig. Insbesondere die folgenden Konfigurationen sind nicht gültig:

• Gradle-Ausführungskonfigurationen (mit 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 merkt sich auch die Ausführungskonfiguration, die in einem bestimmten Kontext (z. B. ein Rechtsklick auf eine bestimmte Klasse oder Methode) erstellt wurde, und bietet künftig keine andere Konfiguration an. Klicken Sie auf Ausführen > Konfigurationen bearbeiten und entfernen Sie die falsch erstellten Konfigurationen, um das Problem zu beheben.

Java-Haltepunkte beim Debuggen von nativem Code hinzufügen

Während Ihre Anwendung an einem Haltepunkt in Ihrem nativen Code pausiert wird, erkennen die von Ihnen festgelegten neuen Java-Haltepunkte möglicherweise nicht sofort von den Debuggern Auto und Dual. Fügen Sie Java-Haltepunkte hinzu, um dieses Problem zu vermeiden, bevor Sie eine Fehlerbehebungssitzung starten oder während die Anwendung an einem Java-Haltepunkt pausiert wird. Weitere Informationen finden Sie unter Problem 229949.

Nativen Debugger beenden

Wenn Sie den Auto- oder Dual-Debugger zum Debuggen von Java und nativem Code verwenden und eine native Funktion aus Ihrem Java-Code aufrufen (z. B. pausiert der Debugger die Ausführung in einer Zeile in Ihrem Java-Code, die eine native Funktion aufruft, und Sie auf Schritt in klicken) und Sie zu Ihrem Java-Code zurückkehren möchten, klicken Sie auf Programm fortsetzen, (anstatt auf Weiter, oder Weiter, um die Anwendung fortzusetzen.your-module Weitere Informationen findest du unter Problem 224385.

Nativer Debugger bleibt beim Laden von Bibliotheken hängen

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. Es handelt sich um ein dauerhaftes Problem, das auch dann auftritt, 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 „Debugger process complete with Exit code 127“ ab.

Dieser Fehler tritt auf Linux-basierten Plattformen beim Starten des nativen Debuggers auf. Dies weist darauf hin, dass eine der für den nativen Debugger erforderlichen 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 ein Terminal verwenden, um das Installationsverzeichnis von Android Studio aufzurufen und die bin/lldb/bin/LLDBFrontend --version-Befehlszeile auszuführen, um herauszufinden, welche Bibliotheken fehlen. In der Regel ist ncurses5 die fehlende Bibliothek, da einige aktuelle Linux-Distributionen bereits auf ncurses6 aktualisiert wurden.

Profiler

In diesem Abschnitt werden bekannte Probleme mit den Profilers beschrieben.

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

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

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

Zeitüberschreitungsfehler im CPU-Profiler

Wenn Sie die Konfigurationen Beispiel-Java-Methoden oder Trace-Java-Methoden auswählen, wird im CPU-Profiler von Android Studio möglicherweise der Fehler „Aufzeichnung konnte nicht beendet werden“ angezeigt. Dies sind oft Zeitüberschreitungsfehler, insbesondere wenn die folgende Fehlermeldung in der Datei idea.log angezeigt wird:

Wait for ART trace file timed out

Zeitüberschreitungsfehler wirken sich tendenziell stärker auf verfolgte Methoden aus als Stichprobenmethoden und längere Aufzeichnungen als kürzere. Als vorübergehende Problemumgehung kannst du mit kürzeren Aufnahmen versuchen, um zu sehen, ob der Fehler nicht mehr auftritt.

Wenn beim Profiler Zeitüberschreitungsprobleme auftreten, melden Sie den Fehler. Er enthält die Marke bzw. das Modell Ihrer Geräte sowie alle relevanten Einträge aus idea.log und Logcat.

ADB-Ausnahme beim Debugging oder bei der Profilerstellung

Wenn Sie Platform Tools 29.0.3 verwenden, funktionieren das native Debugging und die Profiler von Android Studio möglicherweise nicht richtig. Wenn Sie Help > Show Log (Hilfe > Protokoll anzeigen) auswählen, wird in der Datei idea.log entweder „AdbCommandFailedException“ oder „Fehler beim Verbinden“ 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. Klicken Sie dazu auf Tools > SDK-Manager oder in der Symbolleiste auf SDK-Manager .
2. Klicken Sie das Kästchen neben Android SDK Platform-Tools an, damit 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 Build-Ausgabefenster funktioniert

Durch die Verwendung des Plug-ins CMake simple Markierunger wird verhindert, dass Inhalte im Fenster „Build-Ausgabe“ angezeigt werden. Der Build wird ausgeführt und der Tab „Build-Ausgabe“ wird angezeigt, aber keine Ausgabe (Problem Nr. 204791544).

Installationsreihenfolge verhindert Start

Wenn eine neuere Version von Android Studio vor einer älteren Version installiert wird, kann die ältere Version nicht gestartet werden. 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 werden kann. Löschen Sie unter macOS das Verzeichnis Library/ApplicationSupport/Google/AndroidStudioversion_number, um den Cache zu leeren. Unter Windows können Sie die Datenträgerbereinigung verwenden, um den Cache zu leeren.

Espresso-Test-Rekorder funktioniert nicht mit der Funktion „Compose“

Die 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 Layout testen.

Logcat-Tastenkombination steht mit nicht-englischen Tastaturlayouts in Konflikt

Wenn Sie ein nicht englisches Tastaturlayout verwenden, kann eine Logcat-Standardverknüpfung das Layout beeinträchtigen und verhindert, dass Sie beim Bearbeiten von Text in Android Studio bestimmte Zeichen eingeben. Sie können dieses Problem umgehen, indem Sie die in Konflikt stehende Logcat-Tastaturbelegung löschen oder neu zuordnen. Rufen Sie zum Bearbeiten der Logcat-Tastaturbelegung in Android Studio 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 die Entfernung 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 der Bibliothek mit dynamischen Funktionen sind mit Lint überprüft

Wenn Sie Lint mit checkDependencies = true aus einem Anwendungsmodul ausführen, werden Abhängigkeiten der Dynamic Feature Library nicht überprüft, es sei denn, es sind auch Anwendungsabhängigkeiten (Problem #191977888). Als Behelfslösung kann die Lint-Task für diese Bibliotheken ausgeführt werden.

Signaturdatei mit dem Namen mit Zeilenumbruchzeichen

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

Das Ändern der Variantenausgaben zum Zeitpunkt der Build-Erstellung funktioniert möglicherweise nicht

Die Verwendung der Variant API zum Bearbeiten von Variantenausgaben funktioniert mit dem neuen Plug-in nicht mehr. Es funktioniert weiterhin für einfache Aufgaben wie das Ändern des APK-Namens während der Build-Phase, 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 wird, funktionieren jedoch nicht mehr. Das liegt daran, dass variantenspezifische Aufgaben während der Konfigurationsphase nicht mehr erstellt werden. Dies führt dazu, dass das Plug-in nicht alle Ausgaben im Vorfeld kennt, die Konfigurationszeit jedoch verkürzt wird.

„manifestOutputFile“ ist nicht mehr verfügbar

Die Methode processManifest.manifestOutputFile() ist nicht mehr verfügbar und Sie erhalten den folgenden Fehler, wenn Sie sie aufrufen:

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 zu erhalten, 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 Unterstützung von AGP 7.3.0 AIDL 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 der Gruppen von main/, Build-Typen, 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, solltest du Android Studio auf die neueste stabile Version oder auf die neueste Vorabversion aktualisieren.

Behoben in Android Studio 2021.1.1

• 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 Unittest eines App-Projekts, das das Hilt-Plug-in verwendet: Der Unittest-Klassenpfad enthält die nicht instrumentierten Anwendungsklassen. Das bedeutet, dass Hilt die App-Klassen nicht instrumentiert, um die Abhängigkeitsinjektion beim Ausführen von Unittests zu verarbeiten (Problem #213534628). Behoben in AGP 7.1.1.

Behoben in Android Studio 2020.3.1

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

Behoben in Android Studio 4.2

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

Behoben in Android Studio 4.1

• Zum Anwenden der Arbeitsspeichereinstellungen aus einer vorherigen IDE-Version neu starten:Nach der Aktualisierung von Android Studio müssen Sie Android Studio neu starten, um alle Arbeitsspeichereinstellungen zu übernehmen, die aus einer früheren IDE-Version 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.

Behoben in Android Studio 3.6

• Fehler bei der APK-Installation in LineageOS: Die Bereitstellung Ihrer App auf Geräten, auf denen bestimmte Versionen von LineageOS oder CyanogenMod ausgeführt werden, kann fehlschlagen und die Ausnahme INSTALL_PARSE_FAILED_NOT_APK auslösen.

  Unter 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, was zu längeren Bereitstellungszeiten führen kann.

Behoben in Android Studio 3.5.2

• Fehlerhafter XML-Codestil: Beim Bearbeiten von XML-Code wurde in der IDE ein falscher Codestil angewendet, als in der Menüleiste Code > Code neu formatieren ausgewählt wurde.

Behoben in Android Studio 3.3.1

• Fehler aufgrund fehlenden Arbeitsspeichers beim Scannen von C++-basierten Projekten: Wenn Gradle ein Projekt scannt, das C++-Code an mehreren Speicherorten auf demselben Laufwerk enthält, werden alle Verzeichnisse unter dem ersten gemeinsamen Verzeichnis berücksichtigt. Das Scannen einer großen Anzahl von Verzeichnissen und Dateien kann zu Fehlern aufgrund fehlenden Arbeitsspeichers führen.

  Weitere Informationen zu diesem Problem finden Sie unter Bug im Zusammenhang mit dem Problem.