Znane problemy z Androidem Studio i wtyczką Android Gradle

Na tej stronie znajdziesz znane problemy z Android Studio i wtyczką Androida do obsługi Gradle. Jeśli napotkasz problem, którego nie ma na liście, zgłoś błąd.

Przejście na wersję testową: każda wersja Android 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 opisano znane problemy występujące w Android Studio.

Android Studio Panda 3 nie jest zgodne z wtyczką IntelliJ Develocity 1.2.0

Jeśli używasz wtyczki Develocity IDE w wersji 1.2.0, począwszy od Android Studio Panda 3 Canary 1, działanie uruchamiania kończy się niepowodzeniem z tym błędem (problem nr 492439205):

Found interface com.android.tools.idea.gradle.project.build.invoker.GradleBuildInvoker$Request, but class was expected

Deweloperzy Develocity pracują nad rozwiązaniem problemu w nowej wersji.

Obejście: wyłączenie wtyczki Develocity IDE w wersji 1.2.0 rozwiązuje problem do czasu, aż ta niezgodność zostanie naprawiona w nowej wersji wtyczki.

Kotlin 2.0: nie można rozpoznać funkcji lambda w narzędziu Layout Inspector

W przypadku korzystania z Kotlina 2.0 nie można rozwiązać lambd, a Layout Inspector nie może przejść do kodu źródłowego lambdy w zwykły sposób.

Obejście problemu: dodaj poniższą opcję kompilatora jako obejście problemu, dopóki nie zostanie on rozwiązany:

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

Uruchomienie konfiguracji bez opcji „Przed uruchomieniem” w Gradle-aware Make powoduje błąd wdrażania

W wersji Canary 9 pakietu nowych funkcji Android Studio Ladybug wystąpił błąd, który powodował usuwanie informacji o konfiguracji uruchamiania z projektów otwartych w tej wersji. Jeśli w którymś momencie otworzysz projekt w tej wersji i podczas uruchamiania aplikacji pojawi się błąd „loading build artifacts” (ładowanie artefaktów kompilacji), sprawdź, czy aktywna konfiguracja uruchamiania zawiera krok „Gradle-aware Make” (Kompilacja z użyciem Gradle) w sekcji „Before launch” (Przed uruchomieniem). Aby to sprawdzić, kliknij Konfiguracje uruchamiania i debugowania > Edytuj konfiguracje, kliknij aktywną konfigurację uruchamiania i potwierdź, że w sekcji „Przed uruchomieniem” znajduje się krok „Gradle-aware Make”. Android Studio nie może automatycznie rozwiązać tego problemu, ponieważ niektóre konfiguracje uruchamiania mogły zostać celowo skonfigurowane bez kroku „Gradle-aware Make”.

Opcja „Zastosuj zmiany i uruchom ponownie aktywność” nie uruchamia ponownie aktywności na urządzeniach lub emulatorach z interfejsem API na poziomie 35

Gdy wdrażasz zmiany w kodzie na urządzeniu z interfejsem API 35 za pomocą opcji „Zastosuj zmiany i uruchom ponownie aktywność”, aplikacja nie zostanie uruchomiona ponownie i nie zobaczysz efektów zmian. Jeśli ponownie uruchomisz aplikację, zobaczysz efekt zmian w kodzie. Nasz zespół aktywnie bada tę sprawę.

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

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

Nie można wyizolować widoku za pomocą narzędzia Layout Inspector

Możliwość wyizolowania widoku za pomocą wbudowanego narzędzia Layout Inspector 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 zauważysz, że nie wszystkie węzły Compose można sprawdzić za pomocą Layout Inspectora, prawdopodobnie jest to spowodowane błędem, który został naprawiony w Compose w wersji 1.5.0-alpha04. Jeśli masz ten problem, uaktualnij Compose do wersji 1.5.0-alpha04 lub nowszej.

Błąd podczas renderowania podglądu w Compose

Jeśli w panelu problemów w Android Studio Chipmunk lub nowszej wersji widzisz java.lang.NoSuchFieldError: view_tree_saved_state_registry_owner lub java.lang.ClassNotFoundException: androidx.savedstate.R$id, upewnij się, że w module uwzględniono zależność debugImplementation od androidx.lifecycle:lifecycle-viewmodel-savedstate.

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

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

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

Gdy przejdziesz do sekcji Build > Generate Signed Bundle / APK (Utwórz > Wygeneruj podpisany pakiet / plik APK) i spróbujesz skonfigurować podpisywanie aplikacji w przypadku pakietu aplikacji lub pliku APK, wpisanie różnych 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 odśmiecaczem pamięci używanym przez JDK 11. Jeśli ten proces się nie powiedzie, IDE może nie uruchomić się u niektórych użytkowników, którzy ustawili niestandardowe opcje maszyny wirtualnej w pliku .vmoptions.

Aby obejść ten problem, zalecamy zmianę opcji niestandardowych w pliku .vmoptions w komentarze (za pomocą znaku „#”). Plik .vmoptions można znaleźć 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 zastosowaniu 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 w emulatorze Androida 11

Aplikacje korzystające z Database Inspector mogą ulegać awarii podczas działania w emulatorze Androida 11, a w logcat może pojawić się 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 SDK Platforms (Platformy SDK) zaznacz pole Show Package Details (Pokaż szczegóły pakietu) i wybierz wersję 9 lub nowszą emulatora Androida 11.

Studio nie uruchamia się po uaktualnieniu

Jeśli Studio nie uruchamia się po uaktualnieniu, problem może być spowodowany nieprawidłową konfiguracją Android Studio zaimportowaną z poprzedniej wersji Android Studio lub niezgodną wtyczką. Aby obejść ten problem, spróbuj usunąć (lub zmienić nazwę, aby utworzyć kopię zapasową) katalog poniżej, w zależności od wersji Android Studio i systemu operacyjnego, i ponownie uruchom Android Studio. Spowoduje to przywrócenie Android Studio do stanu domyślnego i usunięcie wszystkich wtyczek innych firm.

W przypadku Android Studio 4.1 lub nowszego:

• 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

W przypadku Android Studio 4.0 i starszych wersji:

• 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 dla <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 kandydujących do publikacji i wersji stabilnych.

Problem z kompilacją w projektach Kotlin Multiplatform

W kodzie Kotlin 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 klawiszy w systemie Linux

W systemie Linux niektóre skróty klawiszowe kolidują z domyślnymi skrótami klawiszowymi systemu Linux i popularnych menedżerów okien, takich jak KDE i GNOME. Te skróty klawiszowe mogą nie działać zgodnie z oczekiwaniami w Android Studio.

Więcej informacji o tym problemie (w tym potencjalne obejścia) znajdziesz w narzędziu do śledzenia błędów IntelliJ.

Mały tekst interfejsu w ChromeOS

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

1. Otwórz okno Ustawienia, klikając Plik > Ustawienia.
2. Kliknij Appearance & Behavior > Appearance (Wygląd i zachowanie > Wygląd).
3. Wybierz Użyj czcionki niestandardowej.
4. Może zwiększyć rozmiar czcionki
5. W oknie Settings (Ustawienia) kliknij Editor > Font (Edytor > Czcionka).
6. Może zwiększyć rozmiar czcionki
7. Kliknij OK.

Edytowanie kodu

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

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

Istnieją pewne znane interakcje między demonem iBus w systemie Linux a Android Studio. W niektórych przypadkach IDE przestaje reagować na dane wejściowe z klawiatury lub zaczyna wprowadzać 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 sposoby obejścia tego problemu:

• Obejście 1. Wymuś tryb synchroniczny iBus. Przed uruchomieniem Android Studio wykonaj w wierszu poleceń to polecenie:

  $ IBUS_ENABLE_SYNC_MODE=1 ibus-daemon -xrd

• Obejście 2. Wyłącz metodę wprowadzania iBus w Android Studio. Aby wyłączyć metodę wprowadzania iBus tylko w Android Studio, uruchom w wierszu poleceń to polecenie:

  $ XMODIFIERS= ./bin/studio

  To obejście wyłącza metody wprowadzania tylko w Android Studio, a nie w innych aplikacjach, które mogą być uruchomione. Pamiętaj, że jeśli ponownie uruchomisz demona, gdy Android Studio jest uruchomione (np. przez uruchomienie ibus-daemon -rd), skutecznie wyłączysz metody wprowadzania we wszystkich innych aplikacjach, a także możesz spowodować awarię maszyny JVM Androida Studio z błędem segmentacji.
• Obejście 3. Sprawdź powiązania skrótów, aby upewnić się, że skrót Następne dane wejściowe nie jest ustawiony na Control+Spacja, ponieważ jest to również skrót do uzupełniania kodu w Android Studio. W Ubuntu 14.04 (Trusty) domyślnym skrótem jest Super+Spacja, ale ustawienia z poprzednich wersji mogą nadal obowiązywać. Aby sprawdzić powiązania skrótów, uruchom ibus-setup w wierszu poleceń, aby otworzyć okno ustawień IBus. W sekcji Skróty klawiszowe zaznacz Następna metoda wprowadzania. Jeśli jest ustawiony na Control+Spacja, zmień go 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żywać protokołu IPv4 zamiast IPv6.

• Obejście 1. W systemie Linux umieść w pliku ~/.profile lub ~/.bash_profile ten kod:

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

• Obejście 2. W pliku vmoptions Android Studio zmień wiersz -Djava.net.preferIPv4Addresses=true na -Djava.net.preferIPv6Addresses=true. Więcej informacji znajdziesz w przewodniku użytkownika dotyczącym sieci IPv6.

Błędy „peer not authenticated” (host nie został uwierzytelniony) podczas synchronizacji Gradle lub w SDK Managerze

Główną przyczyną tych błędów jest brak certyfikatu w $JAVA_HOME/jre/lib/certificates/cacerts. Aby poprawić 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 aby połączyć się przez serwer proxy, może być konieczne użycie narzędzia keytool w celu dodania certyfikatu serwera proxy do pliku cacerts.
• Zainstaluj ponownie obsługiwany, niezmodyfikowany pakiet JDK. Występuje znany problem, który dotyczy użytkowników Ubuntu i powoduje, że plik /etc/ssl/certs/java/cacerts jest pusty. Aby obejść ten problem, uruchom w wierszu poleceń:

  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 połączonym urządzeniu.

[Tylko system operacyjny Mac] Aktualizacje przyrostowe nie są stosowane z powodu problemu z obserwowaniem plików Gradle w projektach zapisanych w /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. Począwszy od Gradle 7.0, obserwowanie plików jest domyślnie włączone. Jeśli pracujesz w systemie Mac OS, a projekt jest zapisany w katalogu /System/Volumes/Data, monitorowanie plików Gradle nie będzie prawidłowo śledzić zmian w plikach. Spowoduje to, że system kompilacji nie będzie widział żadnych zmian w plikach i nie zaktualizuje plików APK. Kod wdrożenia przyrostowego nie wykona żadnych 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 zostanie wtedy prawidłowo powiadomiony o zmianach w plikach przez obserwowanie plików Gradle, a zmiany przyrostowe zostaną zastosowane.

Android Emulator HAXM w systemie macOS High Sierra

Android Emulator w systemie macOS High Sierra (10.13) wymaga HAXM w wersji 6.2.1 lub nowszej, aby zapewnić najlepszą zgodność i stabilność z systemem macOS. Jednak w systemie macOS 10.13 proces instalacji rozszerzeń jądra, takich jak HAXM, jest bardziej skomplikowany. Musisz ręcznie zezwolić na instalację rozszerzenia jądra w następujący sposób:

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

3. Jeśli pojawi się alert z informacją, że wczytywanie oprogramowania systemowego od dewelopera „Intel Corporation Apps” zostało zablokowane, kliknij Pozwól:

   

Więcej informacji i obejścia znajdziesz na tej stronie Apple i w opisie problemu 62395878.

Apply Changes

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

Nowa nazwa aplikacji nie została zastosowana

Jeśli zmienisz nazwę aplikacji, a potem spróbujesz zastosować tę zmianę, zaktualizowana nazwa może nie zostać odzwierciedlona. Aby obejść ten problem, kliknij Uruchom , 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 zastosowania niektórych typów zmian (zwłaszcza jeśli używasz Kotlina) mogą pojawiać się komunikaty „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 funkcji Apply Changes, nadal możesz uruchomićaplikację, 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.

Testy JUnit nie mają zasobów w ścieżce klasy, gdy są uruchamiane z Android Studio

Jeśli w modułach Javy masz określone foldery zasobów, te zasoby nie zostaną znalezione podczas przeprowadzania testów w IDE. Uruchamianie testów za pomocą Gradle z poziomu wiersza poleceń będzie działać. Możesz też wykonać zadanie Gradle check z poziomu IDE. Więcej informacji znajdziesz w opisie problemu 64887.

Ten problem występuje, ponieważ od wersji IntelliJ 13 wymagane jest, aby ścieżka klasy zawierała tylko 1 folder. Kreator IntelliJ kopiuje wszystkie zasoby do tego folderu kompilacji, ale Gradle nie kopiuje zasobów.

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

Uruchamianie testów JUnit może spowodować dwukrotną kompilację kodu

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

• Aby rozwiązać problem w bieżącym projekcie, kliknij Run > Edit Configurations (Uruchom > Edytuj konfiguracje) i zmień domyślną konfigurację JUnit, tak aby obejmowała tylko krok Make obsługujący Gradle.
• Aby rozwiązać ten problem we wszystkich przyszłych projektach, kliknij File > Close Project (Plik > Zamknij projekt). Powinien wyświetlić się ekran powitalny. Następnie kliknij Configure > Project Defaults > Run Configurations (Konfiguruj > Domyślne ustawienia projektu > Konfiguracje uruchamiania) i zmień konfigurację JUnit, aby uwzględniała tylko krok Make obsługujący Gradle.

Niektóre konfiguracje uruchamiania testów nie działają

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

• Konfiguracje uruchamiania Gradle (które mają ikonę z logo Gradle) nie działają.
• Konfiguracje uruchamiania JUnit (które mają ikonę bez zielonego Androida) nie mają zastosowania do testów z instrumentacją, których nie można uruchomić na lokalnej maszynie JVM.

Dodawanie punktów przerwania w kodzie Java podczas debugowania kodu natywnego

Gdy aplikacja jest wstrzymana w punkcie przerwania w kodzie natywnym, debugery Auto i Dual mogą nie od razu rozpoznać nowe punkty przerwania w kodzie Javy. Aby uniknąć tego problemu, dodaj punkty przerwania Javy przed rozpoczęciem sesji debugowania lub gdy aplikacja jest wstrzymana w punkcie przerwania Javy. Więcej informacji znajdziesz w opisie problemu 229949.

Wyjście z natywnego debugera

Jeśli podczas debugowania kodu Javy i kodu natywnego za pomocą debugera Auto lub Dual wejdziesz do funkcji natywnej z kodu Javy (np. debuger wstrzyma wykonywanie w wierszu kodu Javy, który wywołuje funkcję natywną, i klikniesz Step Into (Wejdź do) ) i zechcesz wrócić do kodu Javy, kliknij Resume Program (Wznów program)  (zamiast Step Out (Wyjdź)  lub Step Over (Przejdź) ). Proces aplikacji nadal będzie wstrzymany, więc kliknij Resume Program (Wznów program)  na karcie your-module-java, aby go wznowić. Więcej informacji znajdziesz w opisie problemu 224385.

Debuger natywny zawiesza się podczas wczytywania bibliotek

Podczas pierwszego użycia natywnego debugera po uaktualnieniu do Android Studio 4.2 lub nowszej wersji może on przestać odpowiadać podczas wczytywania bibliotek z urządzenia z Androidem. Ten problem jest trudny do rozwiązania i występuje nawet po zatrzymaniu i ponownym uruchomieniu debugera. Aby rozwiązać ten problem, usuń pamięć podręczną LLDB w $USER/.lldb/module-cache/.

Natywny debuger ulega awarii i wyświetla komunikat „Debugger process finished with exit code 127” (Proces debugera zakończył się z kodem wyjścia 127)

Ten błąd występuje na platformach opartych na Linuksie podczas uruchamiania natywnego debugera. Oznacza to, ż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 instalacyjnego Android Studio i wykonać polecenie 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.

Narzędzia do profilowania

W tej sekcji opisano znane problemy z profilatorami.

Native Memory Profiler: profilowanie jest niedostępne podczas uruchamiania aplikacji

Profiler pamięci natywnej 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 profilera Perfetto w wierszu poleceń, aby przechwytywać profile uruchamiania.

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

W profilerze procesora w Android Studio mogą pojawiać się błędy „Nie udało się zatrzymać nagrywania”, gdy wybierzesz konfigurację Próbkowanie metod Javy lub Śledzenie metod Javy. Często są to 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 przekroczenia limitu czasu zwykle wpływają na metody śledzone bardziej niż na metody próbkowane, a na dłuższe nagrania bardziej niż na krótsze. Tymczasowym rozwiązaniem może być nagrywanie krótszych filmów, aby sprawdzić, czy błąd zniknie.

Jeśli masz problemy z przekroczeniem limitu czasu w Profilerze, zgłoś błąd, podając markę i model urządzeń oraz odpowiednie wpisy z idea.log i logcat.

Wyjątek ADB podczas debugowania lub profilowania

Podczas korzystania z narzędzi platformy w wersji 29.0.3 debugowanie natywne i profilery Android Studio mogą nie działać prawidłowo. Po wybraniu Pomoc > Pokaż dziennik w pliku idea.log może pojawić się komunikat „AdbCommandRejectedException” lub „Nie udało się połączyć z portem”. Uaktualnienie narzędzi platformy do wersji 29.0.4 lub nowszej rozwiązuje oba problemy.

Aby uaktualnić narzędzia platformy:

1. Otwórz SDK Managera w Android Studio, klikając Narzędzia > SDK Manager lub kliknij SDK Manager  na pasku narzędzi.
2. Kliknij pole wyboru obok opcji Android SDK Platform-Tools, aby pojawił się w nim znacznik wyboru. W lewej kolumnie powinna pojawić się ikona pobierania .
3. Kliknij Zastosuj lub OK.

Wtyczka uniemożliwia działanie okna Build Output

Użycie wtyczki CMake simple highlighter uniemożliwia wyświetlanie treści w oknie Build Output. Kompilacja zostanie uruchomiona i pojawi się karta Dane wyjściowe kompilacji, ale nie zostaną wyświetlone żadne dane wyjściowe (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ą, 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. W systemie Windows pamięć podręczną możesz wyczyścić za pomocą narzędzia Oczyszczanie dysku.

Espresso Test Recorder nie działa z Compose

Espresso Test Recorder nie działa z projektami, które zawierają Compose. Aby dowiedzieć się, jak tworzyć testy interfejsu w projektach, które zawierają Compose, przeczytaj artykuł Testowanie układu Compose.

Skrót Logcat powoduje konflikt z nieangielskimi układami klawiatury

Jeśli używasz układu klawiatury innego niż angielski, domyślny skrót klawiszowy Logcat może kolidować z układem i uniemożliwiać wpisywanie niektórych znaków podczas edytowania tekstu w Android Studio. Aby obejść ten problem, usuń lub ponownie przypisz konfliktową mapę klawiszy Logcat. Aby edytować mapy klawiszy Logcat w Android Studio, otwórz Android Studio > Ustawienia > Mapa klawiszy i wyszukaj Logcat na liście map klawiszy. Więcej informacji znajdziesz w opisie problemu nr 263475910.

Ten problem zostanie rozwiązany przez usunięcie skrótu Logcat w 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 dotyczące biblioteki funkcji dynamicznych są lintowane

Podczas uruchamiania lintera z checkDependencies = true w module aplikacji zależności dotyczących bibliotek modułów funkcji dynamicznych nie są sprawdzane, chyba że są też zależnościami aplikacji (problem 191977888). Możesz jednak uruchomić zadanie lintowania w przypadku tych bibliotek.

Podpisywanie pliku o nazwie zawierającej znaki przejścia do nowej linii

Podpisywanie JAR (schemat v1) nie obsługuje nazw plików zawierających znaki przejścia do nowej linii (problem nr 63885809).

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

Używanie interfejsu Variant API do manipulowania danymi wyjściowymi wariantów nie działa w nowej wtyczce. Nadal działa 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ż działać. Dzieje się tak, ponieważ zadania związane z konkretnymi wariantami nie są już tworzone na etapie konfiguracji. Wtyczka nie zna wszystkich swoich danych wyjściowych z góry, ale dzięki temu konfiguracja jest szybsza.

manifestOutputFile nie jest już dostępny

Metoda processManifest.manifestOutputFile() nie jest już dostępna, a gdy ją wywołasz, pojawi 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ć funkcję manifestOutputFile(), aby uzyskać plik manifestu dla każdego wariantu, możesz wywołać funkcję 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ę. Poniższy przykład pokazuje, jak dynamicznie zmienić 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żywanie wtyczki AGP 7.3.0 z KAPT w Kotlin 1.7.x powoduje usunięcie zbiorów źródeł AIDL w przypadku określonych wariantów kompilacji. Nadal możesz używać innych zbiorów źródeł AIDL, w tym main/, typów kompilacji, wariantów usługi i kombinacji wariantów usługi. Jeśli musisz używać zbiorów źródeł AIDL dla konkretnych wariantów, nadal używaj Kotlina 1.6.21.

Rozwiązane znane problemy

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

Naprawiono w Android Studio Rabbit 1 Canary 5

• Równoległe wykonywanie synchronizacji Gradle: w Android Studio Quail 1 właściwość org.gradle.parallel=true w gradle.properties nie włącza już równoległego pobierania modelu podczas synchronizacji Gradle, gdy używasz Gradle w wersji 9.4 lub nowszej. Spowodowało to regresję czasu synchronizacji w przypadku dużych projektów. Nowo wprowadzona właściwość org.gradle.tooling.parallel włączyłaby równoległe pobieranie modeli, ale nie w przypadku kreatorów modeli IDEA. To ograniczenie zostało usunięte.

Naprawiono w Android Studio 2021.1.1

• Brak danych wyjściowych lintera: gdy zadanie lintowania jest UP-TO-DATE, tekstowe dane wyjściowe lintowania nie są wyświetlane w strumieniu stdout (problem nr 191897708). Poprawiono w AGP 7.1.0-alpha05.
• Problemy z testowaniem jednostkowym projektu aplikacji, który korzysta z wtyczki Hilt: ścieżka klasy testu jednostkowego zawiera nieinstrumentowane klasy aplikacji, co oznacza, że Hilt nie instrumentuje klas aplikacji do obsługi wstrzykiwania zależności podczas przeprowadzania testów jednostkowych (problem nr 213534628). Problem został rozwiązany we wtyczce Androida do obsługi Gradle w wersji 7.1.1.

Naprawiono w Android Studio 2020.3.1

• Wyjątki Lint w projektach Kotlin: w projektach Kotlin, które ustawiają checkDependencies = true, mogą wystąpić wyjątki wskaźnika o wartości null lub błędy (problem nr 158777858).

Naprawiono w Android Studio 4.2

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

Naprawiono w Android Studio 4.1

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

Naprawiono w Android Studio 3.6

• Błąd instalacji pliku APK w systemie LineageOS: wdrażanie aplikacji na urządzeniach z niektórymi wersjami systemu LineageOS lub CyanogenMod może się nie powieść i spowodować wyjątek INSTALL_PARSE_FAILED_NOT_APK.

  W Android Studio 3.6 Beta 1 i nowszych wersjach IDE obsługuje ten 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.

Naprawiono w Android Studio 3.5.2

• Nieprawidłowy styl kodu XML: podczas edytowania kodu XML środowisko IDE stosowało nieprawidłowy styl kodu, gdy na pasku menu wybrano Kod > Sformatuj ponownie kod.

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 spowodować błędy braku pamięci.

  Więcej informacji o tym problemie znajdziesz w artykule o błędzie.