Znane problemy z Androidem Studio i wtyczką Android Gradle

Ta strona zawiera informacje o znanych problemach z Android Studio Ladybug i wtyczką Androida do obsługi Gradle w wersji 8.7.0. Jeśli napotkasz problem, którego nie ma na liście, zgłoś błąd.

Przejdź na wersję podglądową: każda wersja Android Studio i wtyczki Gradle dla Androida 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 wersję testową Android Studio.

Znane problemy z Android Studio

W tej sekcji opisaliśmy znane problemy występujące w najnowszej stabilnej wersji Android Studio.

Opcja „Zastosuj zmiany i ponowne uruchomienie aktywności” nie uruchamia ponownie aktywności na urządzeniach z poziomem interfejsu API 35 ani na emulatorach

Gdy wdrożysz zmiany kodu na urządzeniu z API 35 za pomocą opcji „Zastosuj zmiany i ponowne uruchomienie aktywności”, aplikacja nie zostanie ponownie uruchomiona i nie zobaczysz efektu zmian. Jeśli uruchomisz aplikację ponownie, zobaczysz efekty zmian w kodzie. Nasz zespół aktywnie go analizuje.

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

Możliwość wyodrębnienia widoku za pomocą wbudowanego inspektora układu jest tymczasowo niedostępna. Pracujemy nad rozwiązaniem tego problemu w kolejnej wersji.

Nie wszystkie węzły Compose można sprawdzić za pomocą narzędzia Layout Inspector

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 masz ten problem, zaktualizuj Compose do wersji 1.5.0-alpha04 lub nowszej.

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

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

Jeśli w panelu problemów widzisz java.lang.NoSuchFieldError: view_tree_lifecycle_owner, dodaj do modułu 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 w modułach, uwzględnij w nich zależność debugImplementation od modułu androidx.customview:customview-poolingcontainer.

Błąd podczas używania różnych haseł do klucza i magazynu kluczy

Począwszy od wersji 4.2, Android Studio działa na platformie JDK 11. Ta aktualizacja powoduje zmianę działania kluczy podpisywania.

Gdy klikniesz Generuj > wygeneruj podpisany pakiet / APK i spróbujesz skonfigurować podpisywanie aplikacji w przypadku pakietu aplikacji lub pliku APK, podanie różnych haseł dla klucza i sklepu z kluczami 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 .vmoptions i oczyścić je, aby mogły współpracować z odbieraczem śmieci używanym przez JDK 11. Jeśli ten proces zakończy się niepowodzeniem, IDE może się nie uruchomić w przypadku niektórych użytkowników, którzy skonfigurowali niestandardowe opcje maszyny wirtualnej w pliku .vmoptions.

Aby obejść ten problem, zalecamy dodanie komentarza do opcji niestandardowych w pliku .vmoptions (za pomocą znaku „#”). Plik .vmoptions możesz znaleźć 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 wypróbowaniu tego obejścia Studio nadal się nie uruchamia, zapoznaj się z sekcją Studio nie uruchamia się po uaktualnieniu poniżej.

Aplikacje korzystające z Database Inspector ulegają awarii na emulatorze Androida 11

Aplikacje korzystające z inspektora baz danych mogą ulegać awarii podczas korzystania z emulatora Androida 11 z komunikatem o błędzie podobnym do tego w logcat:

 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 > Menedżer pakietu SDK. Na karcie Platformy pakietu SDK zaznacz pole Pokaż szczegóły pakietu i wybierz wersję 9 lub nowszą emulatora Androida 11.

Studio nie uruchamia się po uaktualnieniu

Jeśli po uaktualnieniu Studio nie uruchamia się, problem może być spowodowany nieprawidłową konfiguracją Android Studio zaimportowaną z poprzedniej wersji Android Studio lub niezgodnym wtykiem. Aby obejść ten problem, spróbuj usunąć (lub zmienić nazwę w celu utworzenia kopii zapasowej) katalog poniżej (w zależności od wersji Android Studio i systemu operacyjnego) i ponownie uruchom Android Studio. Spowoduje to zresetowanie Android Studio do stanu domyślnego z usuniętymi wszystkimi wtyczkami 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

Pamiętaj, że katalog konfiguracji w przypadku wersji Canary i Beta Android Studio to PreviewX.Y, a nie X.Y, jak w przypadku wersji <version>. Na przykład kompilacje Android Studio 4.1 Canary używają katalogu AndroidStudioPreview4.1 zamiast katalogu AndroidStudio4.1, który jest używany w przypadku wersji kandydatów i wersji stabilnych.

Problem z kompilacją w projektach wieloplatformowych Kotlina

W kodzie MPP Kotlin mogą wystąpić błędy kompilacji z powodu brakujących symboli. Problem powinien zostać rozwiązany przez uaktualnienie wtyczki Kotlin do wersji 1.4.

Konflikty mapowania kluczy w systemie Linux

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

Więcej informacji o tym problemie (w tym o możliwych obejściach) znajdziesz w narzędziu do śledzenia błędów IntelliJ.

Mały tekst interfejsu w ChromeOS

Na ChromeOS tekst może być znacznie mniejszy niż w poprzednich wersjach. Aby obejść ten problem:

  1. Otwórz okno Ustawienia, klikając Plik > Ustawienia.
  2. Kliknij Wygląd i zachowanie > Wygląd.
  3. Wybierz Użyj czcionki niestandardowej.
  4. Zwiększ rozmiar czcionki.
  5. W oknie Ustawienia kliknij 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 Linuksie

Istnieją pewne znane interakcje między demonem iBus w systemie Linux a Android Studio. W niektórych przypadkach środowisko IDE przestaje reagować na dane wprowadzane z klawiatury lub zaczyna generować losowe znaki. Ten błąd jest spowodowany brakiem synchronizacji między iBus a XLib + AWT. Został już zgłoszony do JetBrains i iBus. Obecnie istnieją 3 sposoby obejścia tego problemu:

  • Obejście 1: wymuś tryb synchroniczny w iBus. Przed uruchomieniem Android Studio wykonaj to polecenie w linii komend: 
    $ IBUS_ENABLE_SYNC_MODE=1 ibus-daemon -xrd
  • Obejście 2: wyłącz wejście iBus w Android Studio. Aby wyłączyć klawiaturę iBus (tylko w Android Studio), uruchom w wierszu poleceń następujące polecenie: 
    $ 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 ponownie uruchomisz demona podczas działania Android Studio (np. przez uruchomienie ibus-daemon -rd), wyłączysz metody wprowadzania danych we wszystkich innych aplikacjach. Może to też spowodować awarię JVM w Android Studio z błędem segmentacji.
  • Rozwiązanie 3: sprawdź ponownie skróty, aby upewnić się, że skrót do następnego pola tekstowego nie jest ustawiony na Ctrl+Spacja, ponieważ jest to też skrót do funkcji uzupełniania kodu w Android Studio. W Ubuntu 14.04 (Trusty) domyślnym skrótem jest Super+Spacja, ale ustawienia z poprzednich wersji mogą być nadal dostępne. Aby sprawdzić powiązania skrótów, uruchom w wierszu poleceń polecenie ibus-setup, 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: Broken Pipe

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 problemu 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ącego IPv6.

Błędy „peer not authenticated” (urządzenie nie jest uwierzytelnione) w synchronizacji Gradle lub Menedżerze pakietu SDK

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

  • Jeśli korzystasz z serwera proxy, spróbuj połączyć się bezpośrednio. Jeśli połączenie bezpośrednie działa, aby połączyć się przez serwer proxy, może być konieczne użycie polecenia keytool w celu dodania certyfikatu serwera proxy do pliku cacerts.
  • Zainstaluj ponownie obsługiwaną, niemodyfikowaną wersję JDK. Istnieje znane problem, który dotyczy użytkowników Ubuntu i powoduje pusty ekran /etc/ssl/certs/java/cacerts. Aby obejść ten problem, uruchom w wierszu poleceń następujące polecenie: 
    sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

Wdrażam

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

[Tylko Mac OS] Aktualizacje przyrostowe nie są stosowane z powodu problemu z monitorowaniem plików Gradle w przypadku projektów zapisanych w folderze /System/Volumes/Data

Problem Gradle 18149 dotyczy wersji wtyczki Android Gradle w wersji 7.0 lub nowszej, ponieważ wymagają one Gradle w wersji 7.0 lub nowszej. Od wersji Gradle 7.0 oglądanie plików jest domyślnie włączone. Jeśli pracujesz na Mac OS, a Twój projekt jest zapisany w folderze /System/Volumes/Data, śledzenie zmian plików w Gradle nie będzie działać prawidłowo. W efekcie system kompilacji nie zauważy żadnych zmian w plikach i nie zaktualizuje plików APK. 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 /Users/username. System kompilacji będzie wówczas odpowiednio powiadamiany o zmianach w plikach podczas obserwacji plików Gradle, a zmiany przyrostowe zostaną zastosowane.

Android Emulator HAXM w systemie macOS High Sierra

Aby zapewnić najlepszą zgodność i stabilność emulatora Androida w systemie macOS High Sierra (10.13), należy użyć HAXM 6.2.1 lub nowszej wersji. 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 za pomocą Menedżera pakietu SDK.
  2. Na komputerze Mac kliknij 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 obejść można znaleźć na tej stronie Apple oraz w problemie 62395878.

Apply Changes

W tej sekcji opisaliśmy znane problemy związane z opcją Zastosuj zmiany.

Nowa nazwa aplikacji nie została zastosowana

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ć wprowadzone 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 z platformą Android Runtime, który został rozwiązany w Androidzie 9.0 i nowszych. Chociaż problem uniemożliwia zastosowanie zmian, możesz ponownie uruchomićIkona uruchomieniaaplikację, aby zobaczyć zmiany. Zalecamy jednak zaktualizowanie urządzenia do Androida 9.0 lub nowszego.

Debugowanie i testowanie

W tej sekcji opisaliśmy znane problemy związane z debugowaniem i testowaniem aplikacji.

testy JUnit z brakami zasobów w ścieżce klas, gdy są uruchamiane z Android Studio;

Jeśli w modułach Java masz określone foldery zasobów, nie zostaną one znalezione podczas uruchamiania testów z IDE. Wykonywanie 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 problemie 64887.

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

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

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

Podczas tworzenia nowego projektu konfiguracja szablonu JUnit może zostać utworzona z 2 etapami „Przed uruchomieniem”: Make i Make z uwzględnieniem Gradle. Ta konfiguracja jest następnie propagowana do wszystkich utworzonych konfiguracji uruchomienia JUnit.

  • Aby rozwiązać problem w bieżącym projekcie, kliknij Uruchom > Edytuj konfiguracje i zmień domyślną konfigurację JUnit, aby zawierała tylko krok Make obsługujący Gradle.
  • Aby rozwiązać problem w przyszłych projektach, kliknij Plik > Zamknij projekt. Powinien pojawić się ekran powitalny. Następnie kliknij Konfiguracja > Ustawienia projektu > Konfiguracje uruchomień i zmień konfigurację JUnit, aby zawierała tylko krok Make obsługujący 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. Nieprawidłowe są w szczególności te konfiguracje:

  • Konfiguracje uruchomienia Gradle (których ikona to logo Gradle) 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 też konfigurację uruchomienia utworzoną w danym kontekście (np. po kliknięciu prawym przyciskiem myszy konkretnej klasy lub metody) i nie będzie w przyszłości proponować uruchomienia w innej konfiguracji. Aby to naprawić, kliknij Uruchom > Edytuj konfiguracje i usuń nieprawidłowo utworzone konfiguracje.

Dodawanie punktów przerwania w Javie podczas debugowania kodu natywnego

Gdy aplikacja jest wstrzymana na punkcie przerwania w natywnym kodzie, debugery Auto i Dual mogą nie od razu rozpoznać nowych punktów przerwania w języku Java. Aby uniknąć tego problemu, dodaj punkty przerwania Javy przed rozpoczęciem sesji debugowania lub 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 swojego 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 korzystania z narzędzia do debugowania natywnego po raz pierwszy po przejściu na Android Studio 4.2 lub nowszą wersję może ono przestać odpowiadać podczas wczytywania bibliotek z urządzenia z Androidem. Ten problem jest trwały i pojawia się nawet wtedy, gdy zatrzymasz i ponownie uruchomisz debuger. Aby rozwiązać ten problem, usuń pamięć podręczną LLDB na stronie $USER/.lldb/module-cache/.

Narzędzia do debugowania natywnego ulegają awarii z komunikatem „Debugger process finished with exit code 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. Jeśli nie, możesz użyć terminala, aby przejść do katalogu instalacji Android Studio i wykonać wiersz poleceń bin/lldb/bin/LLDBFrontend --version, aby dowiedzieć się, których bibliotek brakuje. Zwykle brakującą biblioteką jest ncurses5, ponieważ niektóre najnowsze dystrybucje Linuksa zostały już uaktualnione do wersji ncurses6.

Profilatory

W tej sekcji opisaliśmy znane problemy związane z profilatorami.

Narzędzia do profilowania pamięci: profilowanie niedostępne podczas uruchamiania aplikacji

Narzędzie Native Memory Profiler 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 do profilowania w wierszu poleceń Peretto do rejestrowania profili uruchamiania.

Błędy związane z czasem oczekiwania w CPU Profiler

Po wybraniu konfiguracji Przykładowe metody Java lub Śledzenie metod Java w profilu CPU w Android Studio mogą wystąpić błędy „Nie udało się zatrzymać nagrywania”. Często są to błędy 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 dotyczą częściej metod śledzonych niż metod próbkowych, a dłuższych nagrań niż krótszych. Aby tymczasowo rozwiązać problem, możesz nagrać krótsze nagranie 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

Gdy używasz Platform Tools 29.0.3, debugowanie natywne i profilowanie w Android Studio mogą nie działać prawidłowo. Po wybraniu Help > Show Log (Pomoc > Pokaż dziennik) w pliku idea.log może pojawić się błąd „AdbCommandRejectedException” lub „Failed to connect port” (Nie udało się połączyć z portem). Aktualizacja Platform Tools do wersji 29.0.4 lub nowszej rozwiązuje oba problemy.

Aby uaktualnić Platform Tools:

  1. Otwórz Menedżera pakietu SDK w Android Studio, klikając Narzędzia > Menedżer pakietu SDK lub klikając Menedżer pakietu 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 kolumnie po lewej stronie powinna pojawić się ikona pobierania .

  3. Kliknij Zastosuj lub OK.

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

Użycie wtyczki CMake simple highlighter uniemożliwia wyświetlanie treści w oknie „Wyjście kompilacji”. 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 wersję Canary Android Studio, a potem spróbujesz zainstalować i uruchomić wersję stabilną, ta ostatnia może się nie uruchomić. W takich przypadkach musisz wyczyścić pamięć podręczną, aby uruchomić wersję stabilną (starszą). W systemie macOS, aby wyczyścić pamięć podręczną, usuń katalog Library/ApplicationSupport/Google/AndroidStudioversion_number. Aby wyczyścić pamięć podręczną w systemie Windows, użyj funkcji Oczyszczanie dysku.

Espresso Test Recorder nie działa z Compose

Nagrywarka testów Espresso nie działa z projektami, które obejmują Compose. Aby utworzyć testy interfejsu użytkownika dla projektów, które obejmują Compose, zapoznaj się z artykułem Testowanie układu Compose.

Skrót logcat jest w konflikcie z układami klawiatury w językach innych niż angielski

Jeśli używasz układu klawiatury innego niż angielski, domyślny skrót klawiaturowy Logcat może wchodzić w kolizję z układem i uniemożliwiać wpisywanie niektórych znaków podczas edytowania tekstu w Android Studio. Aby obejść ten problem, usuń lub ponownie mapuj konfliktowy układ klawiszy Logcat. Aby edytować mapy klawiszy Logcat w Android Studio, kliknij Android Studio > Ustawienia > Mapa klawiszy i na liście map klawiszy wyszukaj Logcat. Więcej informacji znajdziesz w problemie 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 opisaliśmy znane problemy występujące w najnowszej stabilnej wersji wtyczki Gradle dla Androida.

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

Podczas uruchamiania lint z checkDependencies = true w module ue aplikacji zależności bibliotek dynamicznych funkcji nie są sprawdzane, chyba że są też zależnościami aplikacji (problem #191977888). Aby obejść ten problem, można uruchomić zadanie lint dla tych bibliotek.

Podpisywanie pliku o nazwie zawierającej znaki powrotu karetki

Podpisywanie plików JAR (schemat v1) nie obsługuje nazw plików zawierających znaki tabulacji (problem #63885809).

Modyfikowanie wyników wariantów w czasie kompilacji może nie działać.

Korzystanie z interfejsu Variant API do manipulowania wyjściami wariantów nie działa w nowym wtyczce. Nadal działa ona jednak 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"
    }
}

Bardziej skomplikowane zadania, które wymagają dostępu do obiektów outputFile, nie będą już jednak działać. Dzieje się tak, ponieważ zadania związane z wariantami nie są już tworzone na etapie konfiguracji. W efekcie wtyczka nie zna wszystkich swoich danych wyjściowych z góry, ale szybciej się konfiguruje.

manifestOutputFile nie jest już dostępny

Metoda processManifest.manifestOutputFile() jest niedostępna i po jej wywołaniu pojawia się ten komunikat o błędzie: 

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 zlokalizować plik manifestu i zastosować do niego swoją logikę. Przykład poniżej 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ą AIDL w wersji AGP 7.3.0 i Kotlin 1.7.x

Użycie wersji AGP 7.3.0 z KAPT w Kotlinie 1.7.x powoduje usunięcie zestawów źródeł AIDL dla określonych wariantów kompilacji. Nadal możesz używać innych zbiorów danych AIDL, w tym tych dotyczących main/, typów kompilacji, wersji produktu i ich kombinacji. Jeśli musisz używać zestawów źródeł AIDL dla poszczególnych wariantów, nadal używaj Kotlina w wersji 1.6.21.

Rozwiązane znane problemy

W tej sekcji opisano znane problemy, które zostały rozwiązane w ostatniej wersji. Jeśli napotkasz któryś z tych problemów, zaktualizuj Android Studio do najnowszej stabilnej lub wersji podglądowej.

Rozwiązano w Android Studio 2021.1.1

  • Brak wyjścia lint: w przypadku zadania lint o nazwie UP-TO-DATE nie jest drukowany żaden tekst w pliku stdout (problem #191897708). Naprawiono w AGP 7.1.0-alpha05.
  • Problemy z testowaniem jednostkowym projektu aplikacji, który korzysta z wtyczki Hilt: classpath testu jednostkowego zawiera nieprzetworzone klasy aplikacji, co oznacza, że Hilt nie przekształca klas aplikacji, aby obsługiwać wstrzyknięcie zależności podczas wykonywania testów jednostkowych (problem 213534628). Rozwiązano w wersji AGP 7.1.1.

Poprawiono w Android Studio 2020.3.1

  • Wyjątki lint w projektach Kotlina: w projektach Kotlina, które ustawiającheckDependencies = true, mogą wystąpić wyjątki lub błędy związane z wskaźnikiem null (problem #158777858).

Poprawiono w Android Studio 4.2

  • IDE zawiesza się w systemie macOS Big Sur: Android Studio 4.1 może zawiesić się podczas otwierania okna dialogowego.

Rozwiązano 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 znaków uprawnień nie jest już generowana domyślnie: jeśli chcesz wygenerować klasę, ustaw wartość android.generateManifestClass = true.

Rozwiązano w Android Studio 3.6

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

    W wersji Android Studio 3.6 Beta 1 i wyższych IDE obsługuje tę wyjątek, wykonując pełną instalację aplikacji podczas wdrażania jej na urządzeniach z LineageOS lub CyanogenMod, co może wydłużyć czas wdrażania.

Rozwiązano w Android Studio 3.5.2

  • Błędny styl kodu XML: podczas edytowania kodu XML IDE zastosowało nieprawidłowy styl kodu po wybraniu Kod > Zmień format kodu na pasku menu.

Rozwiązano w Android Studio 3.3.1

  • Błędy braku pamięci podczas skanowania projektów opartych na C++: gdy Gradle skanuje projekt, który ma kod C++ w więcej niż 1 miejscu 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 spowodować wystąpienie błędów związanych z brakiem pamięci.

    Więcej informacji o tym problemie znajdziesz w błędzie z nim powiązanym.