Znane problemy z Androidem Studio i wtyczką Android Gradle

Na tej stronie można śledzić znane problemy z Androidem Studio iguana i wtyczką Android Gradle 8.3.0. Jeśli napotkasz problem, którego nie ma na tej liście, zgłoś błąd.

Uaktualnij do podglądu: każda wersja Androida Studio i wtyczki Androida do obsługi Gradle ma na celu poprawę stabilności i wydajności oraz dodanie nowych funkcji. Aby już teraz korzystać z zalet nadchodzących wersji, 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 Android Studio.

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

Jeśli w oknie Asystenta Firebase (Narzędzia > Firebase w menu głównym) pojawi się komunikat o błędzie, unieważnij pamięć podręczną i ponownie uruchom Android Studio, aby naprawić błąd.

Nie wszystkie węzły tworzenia można kontrolować za pomocą Inspektora układu

Jeśli zauważysz, że podczas korzystania z Inspektora układu nie można sprawdzić wszystkich węzłów tworzenia wiadomości, najprawdopodobniej wynika to z błędu, który został naprawiony w komponencie w wersji 1.5.0-alfa04. Jeśli występuje ten problem, pamiętaj, aby zaktualizować aplikację do tworzenia w wersji 1.5.0-alfa04 lub nowszej.

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

Zacznij 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, pamiętaj, by uwzględnić w module zależność debugImplementation od androidx.lifecycle:lifecycle-viewmodel-savedstate.

Jeśli w panelu problemów widzisz java.lang.NoSuchFieldError: view_tree_lifecycle_owner, pamiętaj, by uwzględnić w module 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 znajduje się zależność debugImplementation od androidx.customview:customview-poolingcontainer.

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

Od wersji 4.2 Android Studio działa teraz na platformie JDK 11. Ta aktualizacja powoduje bazową zmianę działania związaną z kluczami podpisywania.

Gdy przejdziesz do opcji Kompilacja > Wygeneruj podpisany pakiet / plik APK i spróbujesz skonfigurować podpisywanie aplikacji na potrzeby pakietu aplikacji lub pliku APK, wpisanie różnych haseł do klucza i magazynu kluczy może spowodować wyświetlenie tego błędu:

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 spróbuje zaimportować poprzednią wersję .vmoptions i oczyścić ją, aby współpracowała z kolejką czyszczenia pamięci używaną przez JDK 11. Jeśli ten proces się nie powiedzie, IDE może nie zostać uruchomione w przypadku niektórych użytkowników, którzy ustawili niestandardowe opcje maszyn wirtualnych w pliku .vmoptions.

Aby obejść ten problem, zalecamy skomentowanie opcji niestandardowych w .vmoptions (za pomocą znaku „#”). Plik .vmoptions znajdziesz w tych miejscach:

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 zastosowaniu tego obejścia Studio nadal się nie uruchamia, przeczytaj sekcję Studio nie uruchamia się po uaktualnieniu.

Aplikacje korzystające z awarii usługi Database Inspector w emulatorze Androida 11

Aplikacje korzystające z inspektora baz danych mogą ulegać awarii podczas działania na emulatorze Androida 11, a w logcat pojawia się błąd podobny do tego:

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

Aby rozwiązać ten problem, zaktualizuj emulator Androida 11 do wersji 9 lub nowszej. Aby to zrobić, kliknij Narzędzia > Menedżer pakietów SDK. Na karcie Platformy SDK zaznacz pole Pokaż szczegóły pakietu i wybierz wersję 9 lub nowszą emulatora Androida 11.

Studio nie uruchamia się po uaktualnieniu

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

Android Studio w wersji 4.1 lub nowszej:

  • 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 w wersji 4.0 lub starszej:

  • 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

Pamiętaj, że katalog konfiguracji Android Studio w wersji Canary i beta to PreviewX.Y, a nie X.Y dla środowiska <version>. Na przykład kompilacje Androida Studio 4.1 do wersji Canary używają katalogu AndroidStudioPreview4.1, a nie katalogu AndroidStudio4.1 używanego na potrzeby wersji stabilnej i kandydatów do wydania.

Problem z kompilacją w projektach wieloplatformowych Kotlin

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

Konflikty mapowania kluczy w systemie Linux

W systemie Linux niektóre skróty klawiszowe kolidują z domyślnymi skrótami klawiszowymi tego systemu oraz z popularnymi menedżerami okien, takimi jak KDE i GNOME. Te powodujące konflikt skróty mogą nie działać zgodnie z oczekiwaniami w Android Studio.

Więcej informacji na temat tego problemu (w tym potencjalnych rozwiązań) znajdziesz w narzędziu do śledzenia błędów firmy IntelliJ.

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. Kliknij Wygląd i zachowanie > Wygląd.
  3. Wybierz Użyj niestandardowej czcionki.
  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 na klawiaturze - problemy z „iBus” w systemie Linux

Istnieją pewne znane interakcje między demonem iBus w systemie Linux i Android Studio. W niektórych sytuacjach IDE przestanie odpowiadać na dane z klawiatury lub zaczyna wpisywać losowe znaki. Ten błąd jest wywoływany przez brak synchronizacji między iBus a XLib + AWT i został już zgłoszony do JetBrains i iBus. Obecnie istnieją 3 obejścia tego problemu:

  • Rozwiązanie tymczasowe 1: wymuszaj iBus w trybie synchronicznym. Zanim uruchomisz Android Studio, uruchom to polecenie w wierszu poleceń:
    $ IBUS_ENABLE_SYNC_MODE=1 ibus-daemon -xrd
  • Obejście 2: wyłącz w Android Studio wejście iBus. Aby wyłączyć wejście 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 inne uruchomione aplikacje. Pamiętaj, że jeśli uruchomisz ponownie demona, gdy działa Android Studio (np. uruchamiając ibus-daemon -rd), spowoduje to wyłączenie metod wprowadzania we wszystkich innych aplikacjach. Może to również spowodować awarię JVM w Android Studio z błędem podziału na segmenty.
  • Rozwiązanie tymczasowe 3: dokładnie sprawdź powiązania skrótów i upewnij się, że Następny skrót do wprowadzania danych nie jest ustawiony na Ctrl+spacja, ponieważ jest to też skrót do uzupełniania kodu w Android Studio. Ubuntu 14.04 (Trusty) ustawia Super+Space jako domyślny skrót, ale ustawienia z poprzednich wersji mogą nadal być dostępne. Aby sprawdzić powiązania skrótów, uruchom polecenie ibus-setup w wierszu poleceń, aby otworzyć okno preferencji IBus. W sekcji Skróty klawiszowe zaznacz Następna metoda wprowadzania. Jeśli ustawiona jest kombinacja Control+spacja, zmień ją na Super+spację lub inny dowolny skrót.

Konfiguracja projektu

W tej sekcji opisaliśmy znane problemy związane z konfiguracją projektu i synchronizacją Gradle.

Nie udało się zsynchronizować Gradle: uszkodzona rura

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

  • Sposób obejścia 1. W przypadku systemu Linux dodaj do ~/.profile lub ~/.bash_profile te polecenia:
    export _JAVA_OPTIONS="-Djava.net.preferIPv6Addresses=true"
  • Sposób obejścia 2: w pliku vmoptions Androida Studio zmień wiersz -Djava.net.preferIPv4Addresses=true na -Djava.net.preferIPv6Addresses=true. Więcej informacji znajdziesz w Przewodniku użytkownika protokołu IPv6 dla sieci.

Błędy „peer nie uwierzytelniony” z synchronizacji Gradle lub SDK Manager

Główną przyczyną tych błędów jest brak certyfikatu w pliku $JAVA_HOME/jre/lib/certificates/cacerts. Aby naprawić te 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, to w celu nawiązania połączenia przez serwer proxy może być konieczne użycie keytool w celu dodania certyfikatu serwera proxy do pliku cacerts.
  • Ponownie zainstaluj obsługiwany, niezmodyfikowany pakiet JDK. Istnieje znany problem, który dotyczy użytkowników Ubuntu, przez co plik /etc/ssl/certs/java/cacerts jest pusty. Aby obejść ten problem, wykonaj te polecenia w wierszu poleceń:
    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 obserwowaniem plików Gradle w projektach zapisanych w /System/Volumes/Data

Problem Gradle 18149 dotyczy wtyczki Androida do obsługi Gradle w wersji 7.0 lub nowszej, ponieważ wymagają one narzędzia Gradle w wersji 7.0 lub nowszej. Od wersji Gradle 7.0 wyświetlanie plików jest domyślnie włączone. Jeśli pracujesz w systemie macOS, a Twój projekt jest zapisany w folderze /System/Volumes/Data, obserwowanie plików przez Gradle nie będzie prawidłowo śledzić zmian w pliku. System kompilacji nie zauważy żadnych zmian w plikach, a pliki APK nie będą aktualizowane. Przyrostowy kod wdrożenia nie będzie wtedy działać, 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 /Users/username. System kompilacji będzie wtedy odpowiednio powiadamiany o zmianach w plikach przez funkcję śledzenia plików Gradle i zastosuje się stopniowe wprowadzanie zmian.

Emulator Androida HAXM w systemie macOS High Sierra

Aby uzyskać jak największą zgodność i stabilność z systemem macOS, emulator Androida w systemie macOS High Sierra (10.13) wymaga protokołu HAXM w wersji 6.2.1 lub nowszej. W systemie macOS 10.13 jest jednak bardziej skomplikowany proces instalowania rozszerzeń jądra, takich jak HAXM. Musisz ręcznie zezwolić na instalację tego 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 wczytywanie oprogramowania systemowego od dewelopera „Intel Corporation Apps” zostało zablokowane, kliknij Zezwól:

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

Apply Changes

W tej sekcji opisujemy znane problemy związane z funkcją Stosowanie zmian.

Nie zastosowano nazwy nowej aplikacji

Jeśli zmienisz nazwę aplikacji, a potem spróbujesz ją zastosować, 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 używasz urządzenia z Androidem 8.0 lub 8.1, podczas próby wprowadzenia określonych typów zmian (zwłaszcza jeśli używasz Kotlin) możesz zobaczyć komunikat „VERIFICATION_ERROR”. Ten komunikat jest spowodowany problemem ze środowiskiem wykonawczym Androida, który został rozwiązany w Androidzie 9.0 i nowszych. Chociaż ten problem powoduje niepowodzenie zastosowania zmian, nadal możesz uruchomić Ikona uruchamianiaaplikację ponownie, aby zobaczyć zmiany. Zalecamy jednak uaktualnienie urządzenia do Androida 9.0 lub nowszego.

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 podczas uruchamiania z Android Studio

Jeśli w modułach Java masz określone foldery zasobów, nie będzie można ich znaleźć podczas testów z IDE. Testy można przeprowadzić za pomocą narzędzia Gradle z poziomu wiersza poleceń. Będzie też można wykonać zadanie check Gradle w IDE. Więcej informacji znajdziesz w problemie 64887.

Ten problem występuje od wersji IntelliJ 13, która wymaga, aby ścieżka klasy miała tylko jeden folder. Kreator IntelliJ kopiuje wszystkie zasoby do tego folderu kompilacji, ale Gradle ich nie kopiuje.

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

Uruchamianie testów JUnit może skompilować kod dwukrotnie.

Podczas tworzenia nowego projektu można utworzyć konfigurację JUnit w szablonie, wykonując 2 kroki „Przed uruchomieniem”: Tworzenie i Markę opartą na Gradle. Ta konfiguracja jest następnie rozpowszechniana do wszystkich utworzonych konfiguracji uruchomienia JUnit.

  • Aby rozwiązać ten problem w bieżącym projekcie, kliknij Uruchom > Edytuj konfiguracje i zmień domyślną konfigurację JUnit tak, aby uwzględniała tylko krok tworzenia przez Gradle-aware.
  • Aby rozwiązać ten problem we wszystkich przyszłych projektach, kliknij Plik > Zamknij projekt. Powinien wyświetlić 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 zależny od Gradle.

Niektóre konfiguracje uruchomień testowych nie działają

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

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

Dodawanie punktów przerwania Java podczas debugowania kodu natywnego

Gdy aplikacja jest wstrzymana w punkcie przerwania w kodzie natywnym, debugery Auto i Dual mogą nie rozpoznawać od razu nowych punktów przerwania w języku Java. Aby uniknąć tego problemu, dodawaj punkty przerwania w języku Java przed rozpoczęciem sesji debugowania lub gdy aplikacja jest wstrzymana w punkcie przerwania Java. Więcej informacji znajdziesz w problemie 229949.

Wyłączanie natywnego debugera

Jeśli podczas korzystania z debugera Auto lub Dual do debugowania funkcji Java i kodu natywnego uruchomisz funkcję natywną z kodu Java (na przykład debuger wstrzyma wykonanie w wierszu kodu Java, który wywołuje funkcję natywną, a Ty klikniesz Step Into ), i chcesz wrócić do kodu Java, kliknij Wznów program. W menu Wznów działanie programu. W polu Kontynuuj działanie aplikacji kliknij Wznowienie działania aplikacji. W polu Kontynuuj działanie aplikacji bądź your-moduleKrok w celu wznowienia: lub your-moduleKrok w celu wznowienia działania: lub your-moduleKrok w kroku. . Więcej informacji znajdziesz w problemie 224385.

Natywny debuger zawiesza się podczas wczytywania bibliotek

Jeśli używasz natywnego debugera po raz pierwszy po uaktualnieniu do Androida Studio 4.2 lub nowszego, natywny debuger może przestać odpowiadać podczas wczytywania bibliotek z urządzenia z Androidem. Jest to problem trwały, który występuje nawet po zatrzymaniu i ponownym uruchomieniu debugera. Aby rozwiązać ten problem, usuń pamięć podręczną LLDB pod adresem $USER/.lldb/module-cache/.

Awaria debugera natywnego z komunikatem „Proces debugera został zakończony z kodem wyjścia 127”

Ten błąd występuje na platformach opartych na systemie Linux podczas uruchamiania natywnego debugera. Wskazuje ona, że jedna z bibliotek wymaganych przez natywny debuger nie jest zainstalowana w systemie lokalnym. Nazwa brakującej biblioteki może już być wydrukowana w pliku idea.log. Jeśli nie, możesz za pomocą terminala przejść do katalogu instalacyjnego Android Studio i wykonać wiersz poleceń bin/lldb/bin/LLDBFrontend --version, aby sprawdzić, których bibliotek brakuje. Zwykle brakująca biblioteka 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 profilującymi.

Program profilujący pamięci natywnej: profilowanie jest niedostępne podczas uruchamiania aplikacji

Narzędzie do profilowania pamięci natywnej jest obecnie niedostępne podczas uruchamiania aplikacji. Ta opcja będzie dostępna w kolejnej wersji.

Aby obejść ten problem, możesz użyć samodzielnego narzędzia profilującego wiersza poleceń Perfetto do przechwytywania profili uruchamiania.

Błędy związane z przekroczeniem limitu czasu w programie profilującym procesora

Po wybraniu konfiguracji Sample Java Methods (Przykładowe metody Java) lub Trace Java Methods (Śledzenie metod Java) w narzędziu profilu CPU w Android Studio mogą wystąpić błędy „Nagrywanie nie udało się zatrzymać”. Często są to błędy związane z przekroczeniem limitu czasu, zwłaszcza jeśli w pliku idea.log występuje ten komunikat o błędzie:

Wait for ART trace file timed out

Błędy związane z czasem oczekiwania mają większy wpływ na metody śledzone w większym stopniu niż na metody próbkowane, a dłuższe nagrania częściej niż na krótsze nagrania. Aby tymczasowo obejść problem, spróbuj użyć krótszych nagrań i zobacz, czy błąd zniknie.

Jeśli w programie profilującym wystąpią problemy z czasem oczekiwania, zgłoś błąd, podając markę/model urządzenia oraz odpowiednie wpisy z idea.log i logcat.

Wyjątek ADB podczas debugowania lub profilowania

Jeśli korzystasz z narzędzi Platform Tools w wersji 29.0.3, debugowanie natywne i Profilery w Android Studio mogą nie działać prawidłowo, a gdy klikniesz Pomoc > Pokaż dziennik, w pliku idea.log może pojawić się komunikat „AdbCommand disapprovedException” lub „Failed to connect port” (Nie udało się połączyć portu). Uaktualnienie narzędzi platformy do wersji 29.0.4 lub nowszej rozwiązuje oba problemy.

Aby uaktualnić narzędzia platformy:

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

  2. Kliknij pole wyboru Narzędzia platformy SDK na Androida, aby wyświetlić 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 Simple Marker zapobiega wyświetlaniu treści w oknie danych wyjściowych kompilacji. Kompilacja zostanie uruchomiona i pojawi się karta Dane wyjściowe kompilacji, ale nie ma wydrukowanych danych wyjściowych (numer problemu 204791544).

Kolejność instalacji uniemożliwia uruchomienie

Zainstalowanie nowszej wersji Android Studio przed uruchomieniem starszej wersji może uniemożliwić uruchomienie starszej wersji. Jeśli na przykład najpierw zainstalujesz wersję do wczesnych testów Android Studio, 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ć stabilną (starszą) wersję. 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 funkcji Czyszczenie dysku.

Dyktafon testu espresso nie działa z funkcją tworzenia wiadomości

Rejestrator Testowy Espresso nie działa z projektami, które obejmują tworzenie. Informacje o tym, jak utworzyć testy interfejsu użytkownika w projektach, które obejmują tworzenie wiadomości, znajdziesz w sekcji Testowanie układu tworzenia wiadomości.

Skrót do Logcat powoduje konflikty z układami klawiatury w językach innych niż angielski

Jeśli używasz układu klawiatury w języku innym niż angielski, domyślny skrót klawiszowy Logcat może kolidować z układem i uniemożliwić 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, kliknij Android Studio > Ustawienia > Mapa klawiszy i wyszukaj Logcat na liście map klawiszy. Więcej informacji znajdziesz w problemie nr 263475910.

Problem ten rozwiążemy, usuwając skrót do Logcat w aplikacji Android Studio Electric Eel Patch 1.

Znane problemy z wtyczką Androida do obsługi Gradle

W tej sekcji opisujemy 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 pod kątem lintowania

Gdy uruchamiasz lint z użyciem funkcji checkDependencies = true z modułu aplikacji, zależności biblioteki funkcji dynamicznych nie są sprawdzane, chyba że są też zależnościami aplikacji (problem nr 191977888). Aby obejść ten problem, zadanie lintowania można uruchomić w tych bibliotekach.

Plik podpisywania o nazwie zawierającej znaki przejścia do nowej linii

Podpisywanie JAR (schemat v1) nie obsługuje nazw plików zawierających znaki powrotu karetki (numer problemu: 63885809).

Modyfikowanie danych wyjściowych wariantów podczas kompilacji może nie działać

Używanie interfejsu Variant API do manipulowania wynikami wariantów nie działa zgodnie z nową wtyczką. Sprawdza się on nadal w przypadku prostych zadań, takich jak zmiana nazwy pliku 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 złożone zadania obejmujące dostęp do obiektów outputFile nie będą już działać. Dzieje się tak, ponieważ na etapie konfiguracji nie są już tworzone zadania związane z wariantami. W rezultacie wtyczka nie wie z góry wszystkich swoich danych wyjściowych, ale skraca też czas konfiguracji.

Plik manifestoutputFile nie jest już dostępny

Metoda processManifest.manifestOutputFile() nie jest już dostępna, a po jej wywołaniu 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żdej wersji, 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ć w nim swoje działanie. Poniższy przykład dynamicznie zmienia 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ą AGP 7.3.0 AIDL i Kotlin 1.7.x

Używanie AGP 7.3.0 z KAPT w Kotlin 1.7.x powoduje usunięcie zbiorów źródłowych AIDL dla określonych wariantów kompilacji. Nadal możesz korzystać z innych zbiorów źródłowych AIDL, m.in. main/, typów kompilacji, smaków usług i kombinacji smaków produktów. Jeśli musisz używać zbiorów źródłowych AIDL specyficznych dla wariantu, nadal używaj Kotlin 1.6.21.

Rozwiązano znane problemy

W tej sekcji opisujemy znane problemy, które zostały rozwiązane w niedawnej wersji. Jeśli występuje któryś z tych problemów, zaktualizuj Android Studio do najnowszej wersji stabilnej lub wersji testowej.

Poprawiono w Android Studio w wersji 2021.1.1.

  • Brak danych wyjściowych lint: w stdout nie są drukowane lintowanie, gdy zadanie lintowania to UP-TO-DATE (numer problemu 191897708). Poprawiono w AGP 7.1.0-alfa05.
  • Problemy z testowaniem jednostkowym projektu aplikacji, który korzysta z wtyczki Hilt: ścieżka klasy do testów jednostkowych zawiera nieprzypisane klasy aplikacji. Oznacza to, że Hilt nie instrumentuje klas aplikacji do obsługi wstrzykiwania zależności podczas testów jednostkowych (numer sprawy: 213534628). Poprawiono w AGP 7.1.1.

Poprawiono w Android Studio w wersji 2020.3.1.

  • Wyjątki lub błędy związane ze wskaźnikiem o wartości null w projektach Kotlin: projekty Kotlin, które mają ustawioną wartość checkDependencies = true, mogą napotkać błędy lub wyjątki dotyczące wskaźnika o wartości null (numer problemu 158777858).

Naprawiliśmy w Android Studio 4.2

  • IDE zawiesza się w systemie macOS Big Sur: Android Studio 4.1 może się zawiesić, gdy otworzysz okno.

Naprawiliśmy w Android Studio 4.1

  • Uruchom ponownie, aby zastosować ustawienia pamięci z poprzedniej wersji IDE: po zaktualizowaniu Androida 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ż generowana domyślnie: jeśli chcesz wygenerować klasę, ustaw wartość android.generateManifestClass = true.

Naprawiony w Android Studio 3.6

  • Błąd instalacji pliku APK w LineageOS: wdrożenie aplikacji na urządzeniach z określonymi wersjami LineageOS lub CyanogenMod może zakończyć się niepowodzeniem i spowodować zgłoszenie wyjątku INSTALL_PARSE_FAILED_NOT_APK.

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

Naprawiono w Android Studio 3.5.2

  • Uszkodzony styl kodu XML: podczas edytowania kodu XML IDE zastosował nieprawidłowy styl kodu po wybraniu z paska menu Kod > Zmień format kodu.

Naprawiono w Android Studio 3.3.1

  • Błędy za mało pamięci podczas skanowania projektów opartych na C++: gdy Gradle skanuje projekt, którego kod C++ znajduje się 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 związane z brakiem pamięci.

    Więcej informacji na ten temat znajdziesz w powiązanym z nim błędzie.