Znane problemy z Androidem Studio i wtyczką Android Gradle

Ta strona śledzi znane problemy z Android Studio Koala i wtyczką Android do Gradle 8.5.0. Jeśli masz problem, który nie został tu jeszcze omówiony, zgłoś błąd.

Uaktualnij, aby wyświetlić podgląd: każda wersja Android Studio i wtyczki Android do obsługi Gradle służą do poprawy stabilności i wydajności oraz dodania nowych funkcji. Aby poznać korzyści nadchodzących wersji już teraz, pobierz i zainstaluj Android Studio Preview.

Znane problemy z Android Studio

W tej sekcji opisujemy znane problemy, które występują w najnowszej stabilnej wersji Androida Studio.

Różnice w działaniu Gemini w Android Studio .aiexclude

Gdy konfigurujesz udostępnianie kontekstu dla Gemini w Android Studio, pliki .aiexclude zachowują się tak samo jak pliki .gitignore, z tymi wyjątkami:

  • Pusty plik .aiexclude blokuje wszystkie pliki w katalogu i wszystkich podkatalogach. Działa tak samo jak plik zawierający tylko „*”.
  • Pliki typu .aiexclude nie obsługują negacji (z prefiksem wzorców za pomocą !).

W oknie Asystenta Firebase wyświetla się komunikat o błędzie

Jeśli w oknie Asystenta Firebase (Narzędzia > Firebase w menu głównym) wyświetla się komunikat o błędzie, unieważnij pamięci podręczne i ponownie uruchom Androida Studio, by naprawić błąd.

Nie można izolować widoku za pomocą inspektora układu

Chwilowo nie można izolować widoku za pomocą osadzonego inspektora układu. Pracujemy nad rozwiązaniem tego problemu w kolejnej wersji.

Nie wszystkie węzły można sprawdzać za pomocą inspektora układu

Jeśli podczas korzystania z Inspektora układu zauważysz, że nie wszystkie węzły Compose nie są dostępne, najprawdopodobniej jest to spowodowane błędem naprawionym w funkcji Compose w wersji 1.5.0-alfa04. Jeśli występuje ten problem, pamiętaj, aby uaktualnić funkcję Compose do wersji 1.5.0-alfa04 lub nowszej.

Podczas renderowania podglądu tworzenia wiadomości wystąpił błąd

Począwszy od Chipmunk w Android Studio, jeśli w panelu problemów widzisz java.lang.NoSuchFieldError: view_tree_saved_state_registry_owner lub java.lang.ClassNotFoundException: androidx.savedstate.R$id, dodaj w module zależność debugImplementation od androidx.lifecycle:lifecycle-viewmodel-savedstate.

Jeśli w panelu problemów wyświetla się java.lang.NoSuchFieldError: view_tree_lifecycle_owner, upewnij się, że w module masz zależność debugImplementation od androidx.lifecycle:lifecycle-runtime.

Jeśli w panelu problemów widzisz java.lang.NoClassDefFoundError: Could not initialize class androidx.customview.poolingcontainer.PoolingContainer lub java.lang.NoClassDefFoundError: androidx/customview/poolingcontainer/PoolingContainerListener, sprawdź, czy w module masz zależność debugImplementation od androidx.customview:customview-poolingcontainer.

Podczas używania różnych haseł dla kluczy i magazynu kluczy wystąpił błąd

Od wersji 4.2 Android Studio działa na platformie JDK 11. Ta aktualizacja powoduje zmianę działania kluczy podpisywania.

Gdy otworzysz Kompilacja > Wygeneruj podpisany pakiet lub plik APK i spróbujesz skonfigurować podpisywanie aplikacji dla pakietu aplikacji lub pliku APK, wpisanie innych haseł do klucza i magazynu kluczy może spowodować ten błąd:

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

Aby obejść ten problem, wpisz to samo hasło dla klucza i magazynu kluczy.

Android Studio nie uruchamia się po zainstalowaniu wersji 4.2

Studio próbuje zaimportować poprzednie pliki .vmoptions i oczyścić je, aby działały z mechanizmem czyszczenia pamięci używanym w JDK 11. Jeśli ten proces się nie powiedzie, IDE może się nie uruchomić dla niektórych użytkowników, którzy ustawili niestandardowe opcje maszyn wirtualnych w pliku .vmoptions.

Aby rozwiązać ten problem, zalecamy dodanie komentarza do opcji niestandardowych w pliku .vmoptions (za pomocą znaku „#”). Plik .vmoptions znajdziesz w tych lokalizacjach:

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

Jeśli po wypróbowaniu tego obejścia Studio nadal się nie uruchamia, zapoznaj się z sekcją Studio nie uruchamia się po uaktualnieniu poniżej.

Awaria aplikacji Database Inspector w emulatorze Androida 11

Aplikacje korzystające z inspektora baz danych mogą ulegać awarii, gdy działa w emulatorze Androida 11, a w logcat jest widoczny błąd podobny do tego:

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

Aby rozwiązać ten problem, uaktualnij emulator Androida 11 do wersji 9 lub nowszej, klikając Narzędzia > SDK Manager. Na karcie Platformy SDK zaznacz pole wyboru Pokaż szczegóły pakietu i wybierz emulator Androida 11 w wersji 9 lub nowszej.

Studio nie uruchamia się po uaktualnieniu

Jeśli Studio nie uruchomi się po uaktualnieniu, problem może być spowodowany nieprawidłową konfiguracją Androida Studio zaimportowaną z poprzedniej wersji Android Studio lub niezgodnej wtyczki. Aby obejść ten problem, usuń poniższy katalog (lub zmień jego nazwę w celu utworzenia kopii zapasowej) – w zależności od wersji Androida Studio i systemu operacyjnego, a następnie uruchom ponownie Android Studio. Spowoduje to przywrócenie domyślnego stanu Android Studio i usunięcie wszystkich wtyczek innych firm.

Android Studio 4.1 i nowsze wersje:

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

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

  • Linux: ~/.config/Google/AndroidStudio<version> i ~/.local/share/Google/AndroidStudio<version>
    Przykład: ~/.config/Google/AndroidStudio4.1 i ~/.local/share/Google/AndroidStudio4.1

Android Studio 4.0 lub starszy:

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

  • macOS: ~/Library/Preferences/AndroidStudio<version>
    Przykład: ~/Library/Preferences/AndroidStudio3.6

  • Linux: ~/.AndroidStudio<version>/config
    Przykład: ~/.AndroidStudio3.6/config

Zwróć uwagę, że katalog konfiguracji wersji Canary i beta Androida Studio to PreviewX.Y, a nie X.Y dla wersji <version>. Na przykład kompilacje Android Studio 4.1 do wczesnych testów używają AndroidStudioPreview4.1 zamiast katalogu AndroidStudio4.1 używanego na potrzeby kandydatów do wersji i wersji stabilnych.

Problem z kompilacją w projektach wieloplatformowych Kotlin

W kodzie MPP Kotlin mogą wystąpić błędy kompilacji z powodu brakujących symboli. Aktualizacja wtyczki Kotlin do wersji 1.4 powinna rozwiązać ten problem.

Konflikty mapowania kluczy w systemie Linux

W systemie Linux niektóre skróty klawiszowe powodują konflikty z domyślnymi skrótami klawiszowymi tego systemu oraz ze skrótami popularnych menedżerów okien, takich jak KDE czy GNOME. Te będące w konflikcie skróty klawiszowe mogą nie działać zgodnie z oczekiwaniami w Android Studio.

Więcej informacji na temat tego problemu (w tym potencjalnych sposobów obejścia) znajdziesz w narzędziu IntelliJ do śledzenia błędów.

Mały tekst interfejsu w ChromeOS

W ChromeOS tekst może być znacznie mniejszy niż w poprzednich wersjach. Aby obejść ten problem, wykonaj te czynności:

  1. Otwórz okno Ustawienia, klikając Plik > Ustawienia.
  2. Otwórz Wygląd i zachowanie > Wygląd.
  3. Wybierz Użyj czcionki niestandardowej.
  4. Zwiększ rozmiar czcionki.
  5. W oknie Ustawienia wybierz Edytor > Czcionka.
  6. Zwiększ rozmiar czcionki.
  7. Kliknij OK.

Edytowanie kodu

W tej sekcji opisano znane problemy związane z edytorem kodu.

Zablokowane wprowadzanie tekstu – problemy z „iBus” w systemie Linux

Istnieje kilka znanych interakcji między demonem iBus w systemie Linux i Android Studio. W niektórych sytuacjach IDE przestaje reagować na dane wejściowe z klawiatury lub zaczyna wpisywać losowe znaki. Ten błąd wynika z braku synchronizacji między iBus a XLib + AWT i został już zgłoszony przez JetBrains i iBus. Obecnie istnieją 3 możliwości obejścia tego problemu:

  • Rozwiązanie tymczasowe 1: wymuś tryb synchroniczny iBus. Przed uruchomieniem Android Studio uruchom to w wierszu poleceń:
    $ IBUS_ENABLE_SYNC_MODE=1 ibus-daemon -xrd
  • Obejście 2. Wyłącz wejście iBus w Android Studio. Aby wyłączyć dane wejściowe iBus tylko w Android Studio, uruchom to polecenie w wierszu poleceń: 
    $ XMODIFIERS= ./bin/studio.sh
    To obejście wyłącza tylko metody wprowadzania w Android Studio, a nie innych używanych aplikacjach. Pamiętaj, że jeśli uruchomisz demona, gdy działa Android Studio (np. ibus-daemon -rd), spowoduje to wyłączenie metod wprowadzania we wszystkich innych aplikacjach. Może to też doprowadzić do awarii biblioteki JVM w Android Studio z błędem podziału na segmenty.
  • Obejście nr 3: dokładnie sprawdź powiązania skrótów i upewnij się, że skrót Następny do wprowadzania danych nie jest ustawiony na klawisze Ctrl + spacja, ponieważ jest to też skrót do uzupełniania kodu w Android Studio. W Ubuntu 14.04 (Trusty) skrót Super+Space jest domyślnym skrótem, ale ustawienia z poprzednich wersji mogą wciąż być dostępne. Aby sprawdzić powiązania skrótów, uruchom polecenie ibus-setup w wierszu poleceń, aby otworzyć okno ustawień IBus. W sekcji Skróty klawiszowe zaznacz Następna metoda wprowadzania. Jeśli ustawiona jest kombinacja Ctrl+Spacja, zmień ją na Super+spacja lub inny wybrany skrót.

Konfiguracja projektu

W tej sekcji opisano znane problemy związane z konfiguracją projektu i synchronizacją Gradle.

Nie udało się zsynchronizować Gradle: uszkodzony potok

Problem polega na tym, że demon Gradle próbuje użyć IPv4 zamiast IPv6.

  • Obejście problemu 1. W przypadku Linuksa umieść w ~/.profile lub ~/.bash_profile ten kod: 
    export _JAVA_OPTIONS="-Djava.net.preferIPv6Addresses=true"
  • Sposób obejścia 2: w pliku vmoptions w Android Studio zmień wiersz -Djava.net.preferIPv4Addresses=true na -Djava.net.preferIPv6Addresses=true. Więcej informacji znajdziesz w Przewodniku użytkownika dotyczącym adresów IPv6 sieci.

Błędy „peer nieuwierzytelniony” z synchronizacji Gradle lub Menedżera SDK

Główną przyczyną tych błędów jest brak certyfikatu w regionie $JAVA_HOME/jre/lib/certificates/cacerts. Aby naprawić błędy, wykonaj te czynności:

  • Jeśli korzystasz z serwera proxy, spróbuj połączyć się bezpośrednio. Jeśli połączenie bezpośrednie działa, być może trzeba będzie użyć keytool w celu dodania certyfikatu serwera proxy do pliku cacerts.
  • Zainstaluj ponownie obsługiwany, niezmodyfikowany pakiet JDK. W przypadku użytkowników Ubuntu występuje znany problem, który skutkuje pustym plikiem /etc/ssl/certs/java/cacerts. Aby obejść ten problem, wykonaj w wierszu poleceń to polecenie:
    sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

Wdrażam

W tej sekcji opisujemy znane problemy związane z wdrażaniem aplikacji na połączonym urządzeniu.

[Tylko Mac OS] Aktualizacje przyrostowe nie są stosowane z powodu problemu z oglądaniem pliku Gradle w projektach zapisanych w pakiecie /System/Volumes/Data

Problem z Gradle 18149 dotyczy wtyczki Androida do obsługi Gradle w wersji 7.0 lub nowszej, ponieważ wymaga ona Gradle w wersji 7.0 lub nowszej. Od wersji Gradle 7.0 oglądanie plików jest domyślnie włączone. Jeśli pracujesz w systemie Mac OS, a Twój projekt jest zapisany pod adresem /System/Volumes/Data, podczas oglądania plików Gradle nie będzie można prawidłowo śledzić zmian w pliku. System kompilacji nie zobaczy żadnych zmian w plikach, więc pliki APK nie będą aktualizowane. Przyrostowy kod wdrożenia nie zrobi nic, ponieważ stan lokalnego pliku APK jest taki sam jak na urządzeniu.

Aby obejść ten problem, przenieś katalog projektu do katalogu użytkownika, czyli do katalogu /Users/username. System kompilacji będzie wówczas odpowiednio powiadamiany o zmianach w plikach podczas obserwacji plików Gradle, a zmiany przyrostowe zostaną zastosowane.

Emulator Androida HAXM w macOS High Sierra

Emulator Androida w systemie macOS High Sierra (10.13) wymaga HAXM w wersji 6.2.1 lub nowszej, by uzyskać najlepszą zgodność i stabilność z macOS. Jednak w systemie macOS 10.13 proces instalowania rozszerzeń jądra, takich jak HAXM, jest bardziej skomplikowany. Musisz ręcznie zezwolić na zainstalowanie rozszerzenia jądra w ten sposób:

  1. Najpierw spróbuj zainstalować najnowszą wersję HAXM z Menedżera pakietów SDK.
  2. W systemie macOS otwórz Preferencje systemowe > Ochrona i prywatność.

  3. Jeśli zobaczysz alert informujący o tym, że ładowanie oprogramowania systemowego dewelopera „Intel Corporation” zostało zablokowane, kliknij Zezwól:

Więcej informacji i sposobów obejścia tego problemu znajdziesz na tej stronie Apple i w numerze 62395878.

Apply Changes

W tej sekcji opisano znane problemy związane z opcją Zastosuj zmiany.

Nie zastosowano nowej nazwy aplikacji

Jeśli zmienisz nazwę aplikacji, a następnie spróbujesz zastosować tę zmianę, zaktualizowana nazwa może nie zostać uwzględniona. Aby obejść ten problem, kliknij Uruchom Ikona uruchamiania, aby ponownie wdrożyć aplikację i zobaczyć zmiany.

Problem w środowisku wykonawczym Androida powoduje błąd

Jeśli korzystasz z urządzenia z Androidem 8.0 lub 8.1, podczas próby zastosowania niektórych typów zmian (zwłaszcza w Kotlin) możesz zobaczyć komunikaty „VERIFICATION_ERROR”. Ten komunikat jest spowodowany problemem ze środowiskiem wykonawczym Androida, poprawionym w Androidzie 9.0 i nowszych. Mimo że ten problem powoduje błąd Zastosuj zmiany, możesz uruchomić Ikona uruchamianiaaplikację ponownie, aby zobaczyć zmiany. Zalecamy jednak uaktualnienie Androida do wersji 9.0 lub nowszej.

Debugowanie i testowanie

W tej sekcji opisano znane problemy związane z debugowaniem i testowaniem aplikacji.

JUnit testuje brakujące zasoby w ścieżce klasy po uruchomieniu z Android Studio

Jeśli moduły zasobów zawierają określone foldery zasobów, te zasoby nie zostaną znalezione podczas wykonywania testów w IDE. Przeprowadzanie testów przy użyciu Gradle z poziomu wiersza poleceń zadziała. Uruchomienie zadania Gradle check z IDE również będzie działać. Więcej informacji znajdziesz w artykule o problemie 64887.

Ten problem występuje, ponieważ od wersji IntelliJ 13, która wymaga, aby ścieżką klasy był tylko 1 folder. Kreator IntelliJ kopiuje wszystkie zasoby do tego folderu kompilacji, ale Gradle ich nie kopiuje.

  • Obejście 1. Uruchom zadanie Gradle check w IDE, zamiast uruchamiać test jednostkowy.
  • Obejście nr 2. Zaktualizuj skrypt kompilacji, aby ręcznie kopiować zasoby do folderu kompilacji. Więcej informacji znajdziesz w komentarzu 13.

Testy JUnit mogą spowodować dwukrotne skompilowanie kodu

Podczas tworzenia nowego projektu można utworzyć szablon konfiguracji JUnit z 2 krokami przed uruchomieniem: tworzeniem i tworzeniem z uwzględnieniem Gradle. Ta konfiguracja jest następnie propagowana do wszystkich utworzonych konfiguracji uruchamiania JUnit.

  • Aby rozwiązać problem w bieżącym projekcie, kliknij Uruchom > Edytuj konfiguracje i zmień domyślną konfigurację JUnit tak, aby uwzględniała tylko krok tworzenia wykorzystujący Gradle.
  • Aby rozwiązać ten problem we wszystkich przyszłych projektach, kliknij Plik > Zamknij projekt. Powinien pojawić się ekran powitalny. Następnie kliknij Skonfiguruj > Ustawienia domyślne projektu > Uruchom konfiguracje i zmień konfigurację JUnit tak, aby uwzględniała tylko krok tworzenia oparty na Gradle.

Niektóre konfiguracje uruchomienia testowego nie działają

Nie wszystkie konfiguracje uruchamiania, które są dostępne po kliknięciu metody testowej prawym przyciskiem myszy, są prawidłowe. Następujące konfiguracje są nieprawidłowe:

  • Konfiguracje uruchamiania Gradle (które mają logo Gradle jako ikonę) nie działają.
  • Konfiguracje uruchamiania JUnit (które mają ikonę bez zielonego Androida) nie mają zastosowania do testów instrumentacji, których nie można uruchomić na lokalnej maszynie wirtualnej.
Android Studio zapamiętuje również konfigurację uruchamiania utworzoną w danym kontekście (np. kliknięcie prawym przyciskiem myszy konkretnej klasy lub metody) i nie oferuje ponownego uruchomienia w innej konfiguracji. Aby rozwiązać ten problem, kliknij Uruchom > Edytuj konfiguracje i usuń nieprawidłowo utworzone konfiguracje.

Dodawanie punktów przerwania w Javie podczas debugowania kodu natywnego

Gdy aplikacja jest wstrzymana w punkcie przerwania w kodzie natywnym, debugery Auto i Podwójne mogą nie rozpoznać od razu nowo ustawionych punktów przerwania Javy. Aby uniknąć tego problemu, dodaj punkty przerwania Java przed rozpoczęciem sesji debugowania lub wtedy, gdy aplikacja jest wstrzymana na punkcie przerwania Java. Więcej informacji znajdziesz w problemie 229949.

Zamykanie natywnego debugera

Jeśli podczas debugowania kodu Java i Dual używasz debugera Auto lub Podwójnego do debugowania kodu Java i kodu natywnego, gdy uruchomisz funkcję natywną z kodu Java (np. debuger wstrzymuje wykonanie w wierszu, który wywołuje funkcję natywną, i klikasz Przejdź do), a Ty chcesz wrócić do kodu Java, kliknij Wznów program (zamiast Wznów program ). your-module Więcej informacji znajdziesz w problemie 224385.

Debuger natywny zawiesza się podczas wczytywania bibliotek

Podczas pierwszego korzystania z debugera natywnego po uaktualnieniu do Androida Studio 4.2 lub nowszego może on przestać odpowiadać podczas wczytywania bibliotek na urządzeniu z Androidem. Jest to stały problem, który występuje nawet po zatrzymaniu i ponownym uruchomieniu debugera. Aby rozwiązać ten problem, usuń pamięć podręczną LLDB na $USER/.lldb/module-cache/.

Awaria natywnego debugera z komunikatem „Proces debugera zakończył się z kodem wyjścia 127”

Ten błąd występuje na platformach z systemem Linux podczas uruchamiania natywnego debugera. Wskazuje on, że jedna z bibliotek wymaganych przez natywny debuger nie jest zainstalowana w systemie lokalnym. Nazwa brakującej biblioteki może być już wydrukowana w pliku idea.log. W przeciwnym razie możesz użyć terminala, aby przejść do katalogu instalacyjnego Android Studio i uruchomić wiersz poleceń bin/lldb/bin/LLDBFrontend --version, aby sprawdzić, których bibliotek brakuje. Zwykle brakującą biblioteką jest ncurses5, ponieważ niektóre najnowsze dystrybucje Linuksa zostały już uaktualnione do wersji ncurses6.

Programy profilujące

W tej sekcji opisano znane problemy z programami profilowymi.

Natywna aplikacja do profilowania pamięci: profilowanie jest niedostępne podczas uruchamiania aplikacji

Program Native Memory Profiler jest obecnie niedostępny podczas uruchamiania aplikacji. Ta opcja będzie dostępna w kolejnej wersji.

Aby obejść ten problem, możesz użyć samodzielnego narzędzia do profilowania Perfetto w celu przechwytywania profili startowych.

Błędy związane z limitem czasu w narzędziu do profilowania procesora

Po wybraniu konfiguracji Przykładowych metod Java lub Trace Java Methods w Profilu procesora procesora w Android Studio mogą wystąpić błędy „Nagrywanie nie udało się zatrzymać”. Są to często błędy przekroczenia limitu czasu, zwłaszcza jeśli w pliku idea.log widzisz ten komunikat o błędzie:

Wait for ART trace file timed out

Błędy limitu czasu mają zwykle wpływ na metody śledzenia w większym stopniu niż metody próbkowane, a na dłuższych nagraniach częściej niż na krótsze nagrania. Aby tymczasowo obejść problem, warto spróbować krótszych nagrań i sprawdzić, czy błąd zniknie.

W przypadku problemów z limitem czasu w narzędziu do profilowania zgłoś błąd, uwzględniając markę/model urządzeń oraz wszystkie istotne wpisy z idea.log i logcat.

Wyjątek ADB podczas debugowania lub profilowania

W przypadku korzystania z narzędzi Platform Tools w wersji 29.0.3 debugowanie natywne oraz profile profilu Android Studio mogą nie działać prawidłowo, a gdy wybierzesz Pomoc > Pokaż dziennik w pliku idea.log, możesz zobaczyć komunikat „AdbCommandRequestException” (Nie udało się połączyć z portem). Uaktualnienie narzędzi platformy do wersji 29.0.4 lub nowszej rozwiązuje oba te problemy.

Aby uaktualnić narzędzia platformy:

  1. Otwórz Menedżera pakietów SDK w Android Studio, klikając Narzędzia > Menedżer SDK, lub kliknij Menedżer SDK na pasku narzędzi.

  2. Kliknij pole wyboru obok opcji Android SDK Platform- Tools (Narzędzia platformy pakietu SDK na Androida), aby pojawił się znacznik wyboru. W lewej kolumnie powinna pojawić się ikona pobierania .

  3. Kliknij Zastosuj lub OK.

Wtyczka uniemożliwia działanie okna danych wyjściowych kompilacji

Użycie wtyczki CMake upraszczaj zapobiega wyświetlaniu treści w oknie kompilacji danych wyjściowych. Kompilacja działa i pojawia się karta Dane wyjściowe kompilacji, ale nie ma żadnych wydrukowanych danych wyjściowych (problem nr 204791544).

Kolejność instalacji uniemożliwia uruchomienie

Zainstalowanie nowszej wersji Android Studio przed starszą wersją może uniemożliwić uruchomienie starszej wersji. Jeśli na przykład najpierw zainstalujesz Androida Studio w wersji do wczesnych testów, a potem spróbujesz zainstalować i uruchomić wersję stabilną, wersja stabilna może się nie uruchomić. W takich przypadkach musisz wyczyścić pamięć podręczną, aby uruchomić wersję stabilną (starszą). Aby wyczyścić pamięć podręczną w systemie macOS, usuń katalog Library/ApplicationSupport/Google/AndroidStudioversion_number. Aby wyczyścić pamięć podręczną w systemie Windows, użyj Oczyszczania dysku.

Dyktafon Espresso Tester nie działa z funkcją tworzenia

Espresso Test Recorder (Rejestrator testów Espresso) nie działa w przypadku projektów zawierających funkcję Compose. Informacje o tym, jak utworzyć testy UI w projektach korzystających z funkcji tworzenia wiadomości, znajdziesz w artykule Testowanie układu tworzenia wiadomości.

Skrót Logcat powoduje konflikt z układami klawiatury w języku innym niż angielski

Jeśli używasz układu klawiatury w języku innym niż angielski, domyślny skrót Logcat może kolidować z układem i uniemożliwiać wpisywanie określonych znaków podczas edytowania tekstu w Android Studio. Aby obejść ten problem, usuń lub ponownie zmapuj kolidującą mapę klawiszy Logcat. Aby edytować mapy klawiszy Logcat w Android Studio, otwórz Android Studio > Ustawienia > Mapa klawiszy i na liście wyszukaj Logcat. Więcej informacji znajdziesz w problemie nr 263475910.

Ten problem zostanie rozwiązany, usuwając skrót Logcat w Android Studio Electric Eel Patch 1.

Znane problemy z wtyczką Androida do obsługi Gradle

W tej sekcji opisano znane problemy, które występują w najnowszej stabilnej wersji wtyczki Androida do obsługi Gradle.

Nie wszystkie zależności biblioteki funkcji dynamicznych są sprawdzane

Podczas uruchamiania lintowania za pomocą funkcji checkDependencies = true z modułu aplikacji zależności biblioteki funkcji dynamicznych nie są sprawdzane, chyba że są to również zależności aplikacji (problem nr 191977888). Aby obejść ten problem, w tych bibliotekach można uruchomić zadanie lintowania.

Plik podpisujący o nazwie ze znakami przejścia do nowej linii

Podpisywanie JAR (schemat w wersji 1) nie obsługuje nazw plików zawierających znaki przejścia do nowej linii (numer problemu 63885809).

Modyfikowanie danych wyjściowych wariantu podczas kompilacji może nie zadziałać

Nowa wtyczka nie działa w celu manipulowania danymi wyjściowymi wariantów za pomocą interfejsu API wariantów. Nadal działa w przypadku prostych zadań, takich jak zmiana nazwy pakietu APK podczas kompilacji, jak pokazano poniżej:

// 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"
    }
}

Jednak bardziej skomplikowane zadania, które wymagają dostępu do obiektów outputFile, nie będą już działać. Dzieje się tak, ponieważ zadania dla konkretnego wariantu nie są już tworzone na etapie konfiguracji. Sprawia to, że wtyczka nie zna wszystkich danych wyjściowych z góry, ale skraca czas konfiguracji.

Plik manifestOutputFile nie jest już dostępny

Metoda processManifest.manifestOutputFile() nie jest już dostępna, a podczas jej wywoływania pojawia się ten błąd:

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

Zamiast wywoływać manifestOutputFile() w celu pobrania pliku manifestu dla każdego wariantu, możesz użyć wywołania processManifest.manifestOutputDirectory(), aby zwrócić ścieżkę katalogu zawierającego wszystkie wygenerowane pliki manifestu. Następnie możesz znaleźć plik manifestu i zastosować do niego swoją logikę. W przykładzie poniżej dynamicznie zmienia się kod wersji w pliku manifestu:

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

Problemy z obsługą AIDL w AGP 7.3.0 i Kotlin 1.7.x

Użycie AGP 7.3.0 z KAPT w kotlinie 1.7.x powoduje usunięcie zestawów źródłowych AIDL dla określonych wariantów kompilacji. Nadal możesz używać innych zbiorów źródłowych AIDL, w tym main/, typów kompilacji, smaków produktów i kombinacji smaków produktów. Jeśli musisz używać zbiorów źródłowych AIDL właściwych dla konkretnego wariantu, nadal używaj Kotlin 1.6.21.

Rozwiązano znane problemy

W tej sekcji opisano znane problemy, które zostały naprawione w najnowszej wersji. Jeśli napotkasz którykolwiek z tych problemów, zaktualizuj Androida Studio do najnowszej stabilnej wersji lub wersji testowej.

Poprawione w Android Studio 2021.1.1

  • Brak danych wyjściowych lintowania: gdy zadanie lintowania ma wartość UP-TO-DATE (problem nr 191897708), na arkuszu stdout nie ma danych wyjściowych lintowania. Poprawiono kod AGP 7.1.0-alfa05.
  • Problemy z testowaniem jednostkowym projektu aplikacji, który korzysta z wtyczki Hilt: ścieżka klasy testu jednostkowego zawiera nieinstruktowane klasy aplikacji, co oznacza, że Hilt nie przystosowuje klas aplikacji do wstrzykiwania zależności podczas przeprowadzania testów jednostkowych (problem nr 213534628). Poprawiono w AGP 7.1.1.

Poprawiono w Android Studio 2020.3.1

  • Wyjątki Lint w projektach Kotlin: w projektach Kotlin, które mają ustawioną wartość checkDependencies = true, mogą występować błędy lub wyjątki dotyczące wskaźników null (problem nr 158777858).

Poprawiono w Android Studio 4.2

  • IDE zawiesza się na macOS Big Sur: Android Studio 4.1 może zawiesić się po otwarciu okna.

Poprawiono w Android Studio 4.1

  • Uruchom ponownie, aby zastosować ustawienia pamięci z poprzedniej wersji IDE: po zaktualizowaniu Android Studio musisz ponownie uruchomić Android Studio, aby zastosować ustawienia pamięci przeniesione z wcześniejszej wersji IDE.
  • Klasa pliku manifestu z niestandardowymi ciągami uprawnień nie jest już domyślnie generowana: jeśli chcesz wygenerować klasę, ustaw android.generateManifestClass = true.

Naprawiono w Android Studio 3.6

  • Błąd instalacji pliku APK w systemie LineageOS: wdrożenie aplikacji na urządzeniach z określonymi wersjami systemu LineageOS lub CyanogenMod może się nie udać i zgłosić wyjątek INSTALL_PARSE_FAILED_NOT_APK.

    W Android Studio 3.6 w wersji beta 1 lub nowszej IDE obsługuje ten wyjątek, wykonując pełną instalację aplikacji podczas wdrażania na urządzeniach LineageOS lub CyanogenMod, co może wydłużyć czas wdrażania.

Naprawiono w Android Studio 3.5.2

  • Nieprawidłowy styl kodu XML: podczas edytowania kodu XML IDE zastosowało nieprawidłowy styl kodu po wybraniu Kod > Reformatuj kod na pasku menu.

Naprawiono w Android Studio 3.3.1

  • Błędy braku pamięci podczas skanowania projektów opartych na C++: gdy Gradle skanuje projekt, który zawiera kod C++ w więcej niż 1 lokalizacji na tym samym dysku, skanowanie obejmuje wszystkie katalogi poniżej pierwszego wspólnego katalogu. Skanowanie dużej liczby katalogów i plików może powodować błędy braku pamięci.

    Więcej informacji znajdziesz w opisie powiązanego z nim błędu.