Znane problemy z Androidem Studio i wtyczką Android Gradle

Na tej stronie znajdziesz informacje o znanych problemach z Androidem Studio Narwhal i wtyczką Androida do obsługi Gradle w wersji 8.11.0. Jeśli napotkasz problem, którego nie ma na tej liście, zgłoś błąd.

Uaktualnienie do wersji podglądowej: każda wersja Androida Studio i wtyczki Androida do Gradle ma na celu zwiększenie stabilności i wydajności oraz dodanie nowych funkcji. Aby już teraz korzystać z zalet przyszłych wersji, pobierz i zainstaluj wersję testową Android Studio.

Znane problemy z Android Studio

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

Uruchomienie konfiguracji bez opcji „Przed uruchomieniem” w przypadku kompilacji Gradle powoduje błąd wdrażania

W wersji Canary 9 funkcji Android Studio Ladybug wystąpił problem, który spowodował usunięcie informacji o konfiguracji uruchamiania z projektów otwartych w tej wersji. Jeśli projekt został otwarty w tej wersji, a uruchomienie aplikacji powoduje błąd „loading build artifacts” (wczytywanie artefaktów kompilacji), sprawdź, czy w sekcji „Before launch” (Przed uruchomieniem) aktywnej konfiguracji uruchamiania znajduje się krok „Gradle-aware Make” (Kompilacja z uwzględnieniem Gradle). Aby to sprawdzić, kliknij Run/Debug Configurations > Edit Configurations (Konfiguracje uruchamiania/debugowania > Edytuj konfiguracje), kliknij aktywną konfigurację uruchamiania i sprawdź, czy w sekcji „Before launch” (Przed uruchomieniem) znajduje się krok „Gradle-aware Make” (Kompilacja z uwzględnieniem Gradle). Niestety 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”.

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

Gdy wdrożysz zmiany w kodzie na urządzeniu z API 35 za pomocą opcji „Zastosuj zmiany i ponownie uruchom aktywność”, aplikacja nie zostanie ponownie uruchomiona i nie zobaczysz efektu zmian. Jeśli ponownie uruchomisz aplikację, zobaczysz efekt zmian w kodzie. Nasz zespół pracuje nad tym problemem.

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ęć podręczną i uruchom ponownie Android Studio, aby go naprawić.

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

Możliwość wyodrębnienia widoku za pomocą osadzonego 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 zauważysz, że podczas korzystania z inspektora układu nie wszystkie węzły kompozycji są dostępne do sprawdzenia, prawdopodobnie jest to spowodowane błędem, który został naprawiony w wersji 1.5.0-alpha04 kompozycji. Jeśli występuje ten problem, uaktualnij Compose do wersji 1.5.0-alpha04 lub nowszej.

Błąd podczas renderowania podglądu Compose

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

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

Jeśli w panelu problemów widzisz java.lang.NoClassDefFoundError: Could not initialize class androidx.customview.poolingcontainer.PoolingContainer lubjava.lang.NoClassDefFoundError: androidx/customview/poolingcontainer/PoolingContainerListener, upewnij się, że w module znajduje się 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ę podstawowego działania związanego z kluczami podpisywania.

Gdy otworzysz Build> Generate Signed Bundle / APK (Utwórz > Wygeneruj podpisany pakiet / 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ć 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 zarówno w przypadku klucza, jak i magazynu kluczy.

Android Studio nie uruchamia się po zainstalowaniu wersji 4.2

Studio próbuje zaimportować poprzednie pliki .vmoptions i dostosować je do działania z mechanizmem odśmiecania pamięci używanym przez JDK 11. Jeśli ten proces się nie powiedzie, IDE może się nie uruchomić u niektórych użytkowników, którzy ustawili niestandardowe opcje maszyny wirtualnej w pliku .vmoptions.

Aby obejść ten problem, zalecamy wykomentowanie opcji niestandardowych w pliku .vmoptions (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 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 inspektora bazy danych ulegają awarii na emulatorze Androida 11

Aplikacje korzystające z inspektora bazy danych mogą ulegać awarii podczas działania na emulatorze Androida 11. W logcat może 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. W tym celu kliknij Tools > SDK Manager. 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 po uaktualnieniu Studio nie uruchamia się, problem może być spowodowany nieprawidłową konfiguracją Androida Studio zaimportowaną z poprzedniej wersji lub niezgodną wtyczką. Aby rozwiązać ten problem, spróbuj usunąć (lub zmienić nazwę w celu utworzenia kopii zapasowej) poniższy katalog w zależności od wersji Android Studio i systemu operacyjnego, a następnie ponownie uruchom Android Studio. Spowoduje to zresetowanie Androida Studio do stanu domyślnego i usunięcie wszystkich wtyczek innych firm.

W przypadku Androida 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 Androida 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 wersji Canary i beta Androida Studio to PreviewX.Y, a nie X.Y w przypadku <version>. Na przykład kompilacje Androida Studio 4.1 w wersji Canary używają katalogu AndroidStudioPreview4.1 zamiast katalogu AndroidStudio4.1, który jest używany w przypadku wersji kandydujących i stabilnych.

Problem z kompilacją w projektach wieloplatformowych w Kotlinie

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

Konflikty mapowania klawiszy w Linuksie

W systemie Linux niektóre skróty klawiszowe są sprzeczne z domyślnymi skrótami klawiszowymi systemu Linux i popularnych menedżerów okien, takich jak KDE i GNOME. Te sprzeczne 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 obejść ten problem, wykonaj te czynności:

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

Edytowanie kodu

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

Zablokowane wprowadzanie tekstu z klawiatury – problemy z „iBus” w Linuksie

Istnieją pewne znane interakcje między demonem iBus w systemie Linux a Androidem Studio. W niektórych przypadkach środowisko IDE przestaje reagować na wprowadzanie danych z klawiatury lub zaczyna wprowadzać 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ś przejście iBusa w tryb synchroniczny. Przed uruchomieniem Androida Studio wykonaj w wierszu poleceń to działanie:

  $ IBUS_ENABLE_SYNC_MODE=1 ibus-daemon -xrd

• Obejście 2: wyłącz wprowadzanie tekstu za pomocą iBus w Android Studio. Aby wyłączyć wprowadzanie za pomocą iBus tylko w przypadku Android Studio, w wierszu poleceń uruchom to polecenie:

  $ XMODIFIERS= ./bin/studio.sh

  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 podczas działania Androida Studio (np. uruchamiając ibus-daemon -rd), 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 do następnego wejścia nie jest ustawiony na Control+Spacja, ponieważ jest to również skrót do uzupełniania kodu w Android Studio. Ubuntu 14.04 (Trusty) używa skrótu Super+Spacja jako domyślnego, ale ustawienia z poprzednich wersji mogą nadal być dostępne. Aby sprawdzić powiązania skrótów, uruchom ibus-setup w wierszu poleceń, aby otworzyć okno Ustawienia IBus. W sekcji Skróty klawiszowe zaznacz Następna metoda wprowadzania. Jeśli jest ustawiony na Control+Space, zmień go na Super+Space lub inny skrót klawiszowy.

Konfiguracja projektu

W tej sekcji opisujemy 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żywać protokołu IPv4 zamiast IPv6.

• Obejście 1. W systemie Linux umieść w ~/.profile lub ~/.bash_profile te informacje:

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

• Obejście 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 sieci IPv6.

Błędy „peer not authenticated” podczas synchronizacji Gradle lub w Menedżerze pakietów SDK

Przyczyną tych błędów jest brak certyfikatu w $JAVA_HOME/jre/lib/certificates/cacerts. Aby rozwiązać te problemy, 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, 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ługiwany, niezmodyfikowany pakiet JDK. Występuje znany problem, który dotyczy użytkowników Ubuntu i powoduje wyświetlanie pustego /etc/ssl/certs/java/cacerts. Aby obejść ten problem, w wierszu poleceń wykonaj to polecenie:

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

Wdrażanie

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 18149 w Gradle 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 śledzenie plików jest domyślnie włączone. Jeśli pracujesz w systemie macOS, a projekt jest zapisany w folderze /System/Volumes/Data, funkcja śledzenia zmian w plikach Gradle nie będzie działać prawidłowo. Spowoduje to, że system kompilacji nie wykryje żadnych zmian w plikach, a w konsekwencji nie zaktualizuje plików APK. Kod wdrożenia przyrostowego nie wykona wtedy żadnej czynności, 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 folderu /Users/username. System kompilacji zostanie wtedy prawidłowo powiadomiony o zmianach w plikach przez funkcję obserwowania plików Gradle, a zmiany przyrostowe zostaną zastosowane.

Android Emulator HAXM na macOS High Sierra

Emulator Androida na komputerze z systemem 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 przypadku systemu macOS 10.13 proces instalacji 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 Wczytywanie oprogramowania systemowego od dewelopera „Intel Corporation Apps” zostało zablokowane, kliknij Zezwól:

   

Więcej informacji i obejść znajdziesz na tej stronie Apple i w  tym artykule.

Apply Changes

W tej sekcji opisujemy 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 i ponownie wdróż aplikację, aby 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 niektórych typów zmian (zwłaszcza jeśli używasz języka Kotlin) mogą pojawiać się komunikaty „VERIFICATION_ERROR”. Ten komunikat jest spowodowany problemem z Android Runtime, który został rozwiązany w Androidzie 9.0 i nowszym. Chociaż problem powoduje niepowodzenie zastosowania zmian, możesz ponownie uruchomić aplikację, aby zobaczyć wprowadzone zmiany. Zalecamy jednak uaktualnienie urządzenia do Androida 9.0 lub nowszego.

Debugowanie i testowanie

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

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

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

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

• Obejście 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 nr 13.

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

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

• Aby rozwiązać ten problem w bieżącym projekcie, kliknij Uruchom > Edytuj konfiguracje i zmień domyślną konfigurację JUnit, aby zawierała tylko krok Make z obsługą Gradle.
• Aby rozwiązać ten problem we wszystkich przyszłych projektach, kliknij Plik > Zamknij projekt. Powinien pojawić się ekran powitalny. Następnie kliknij Konfiguracja > Domyślne ustawienia projektu > Konfiguracje uruchamiania i zmień konfigurację JUnit, aby zawierała tylko krok Make obsługujący Gradle.

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

Nie wszystkie konfiguracje uruchamiania, które są dostępne po kliknięciu prawym przyciskiem myszy metody testowej, są prawidłowe. W szczególności nie są prawidłowe te konfiguracje:

• Konfiguracje uruchamiania Gradle (z 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 JVM.

Dodawanie punktów przerwania w Javie podczas debugowania kodu natywnego

Gdy aplikacja jest wstrzymana w punkcie przerwania w kodzie natywnym, debugery Auto i Dual mogą nie od razu rozpoznawać nowych punktów przerwania w kodzie Java, które ustawisz. Aby uniknąć tego problemu, dodaj punkty przerwania w kodzie Java przed rozpoczęciem sesji debugowania lub gdy aplikacja jest wstrzymana w punkcie przerwania w kodzie Java. Więcej informacji znajdziesz w tym artykule.

Wyjście z debugera kodu natywnego

Jeśli podczas debugowania kodu Java i kodu natywnego za pomocą debugera Auto lub Dual przejdziesz do funkcji natywnej z kodu Java (np. debuger wstrzyma wykonywanie wiersza kodu Java, który wywołuje funkcję natywną, a Ty klikniesz Krok w głąb ) i chcesz wrócić do kodu Java, kliknij Wznów program (zamiast Krok na zewnątrz lub Krok dalej ). Proces aplikacji nadal będzie wstrzymany, więc kliknij Wznów program na karcie your-module-java, aby go wznowić. Więcej informacji znajdziesz w tym artykule.

Debuger natywny zawiesza się podczas wczytywania bibliotek

Podczas pierwszego użycia natywnego debugera po uaktualnieniu do Androida Studio 4.2 lub nowszego może on przestać odpowiadać podczas wczytywania bibliotek z urządzenia z Androidem. Ten problem jest uporczywy i występuje nadal, nawet jeśli zatrzymasz i ponownie uruchomisz debuger. Aby rozwiązać ten problem, usuń pamięć podręczną LLDB w lokalizacji $USER/.lldb/module-cache/.

Debuger natywny ulega awarii z komunikatem „Debugger process finished with exit code 127” (Proces debugera zakończony z kodem wyjścia 127)

Ten błąd występuje na platformach opartych na Linuksie podczas uruchamiania debugera natywnego. 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 Androida Studio i wykonać wiersz poleceń bin/lldb/bin/LLDBFrontend --version, aby dowiedzieć się, których bibliotek brakuje. Zwykle brakuje biblioteki ncurses5, ponieważ niektóre najnowsze dystrybucje Linuksa zostały już uaktualnione do wersji ncurses6.

Narzędzia do profilowania

W tej sekcji opisujemy znane problemy z Profilerami.

Profilowanie pamięci natywnej: profilowanie 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 wiersza poleceń Perfetto do rejestrowania profili uruchamiania.

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

W profilerze procesora Android Studio mogą się pojawiać błędy „Nie udało się zatrzymać nagrywania”, gdy wybierzesz konfiguracje Próbkowanie metod Java lub Śledzenie metod Java. Są to często błędy przekroczenia limitu czasu, zwłaszcza jeśli w idea.log zobaczysz ten komunikat o błędzie:

Wait for ART trace file timed out

Błędy przekroczenia limitu czasu częściej występują w przypadku śledzonych metod niż w przypadku metod próbkowania, a także w przypadku dłuższych nagrań niż krótszych. Jako tymczasowe rozwiązanie możesz spróbować nagrywać krótsze filmy, aby sprawdzić, czy błąd zniknie.

Jeśli w Profilerze wystąpią problemy z przekroczeniem limitu czasu, zgłoś błąd, podając markę i model urządzenia 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 Androida Studio mogą nie działać prawidłowo. Po wybraniu kolejno Pomoc > Pokaż log w idea.logmoże pojawić się komunikat „AdbCommandRejectedException” lub „Failed to connect port”. Zaktualizowanie narzędzi platformy do wersji 29.0.4 lub nowszej rozwiązuje oba problemy.

Aby uaktualnić narzędzia platformy:

1. Otwórz Menedżera SDK w Android Studio, klikając Narzędzia > Menedżer SDK, lub kliknij Menedżer SDK na pasku narzędzi.
2. Zaznacz pole wyboru obok Android SDK Platform-Tools, 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 simple highlighter uniemożliwia wyświetlanie treści w oknie Build Output. Kompilacja jest uruchamiana i wyświetla się karta Wyniki kompilacji, ale nie są drukowane żadne dane wyjściowe (problem 204791544).

Kolejność instalacji uniemożliwia uruchomienie

Zainstalowanie nowszej wersji Android Studio przed starszą może uniemożliwić uruchomienie starszej wersji. Jeśli na przykład najpierw zainstalujesz wersję Canary Androida Studio, a potem spróbujesz zainstalować i uruchomić wersję stabilną, może się okazać, że nie będzie ona działać. W takich przypadkach musisz wyczyścić pamięć podręczną, aby uruchomić stabilną (starszą) wersję. 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 Oczyszczania dysku.

Espresso Test Recorder nie działa z Compose

Rejestrator testów Espresso nie działa w przypadku projektów, które zawierają Compose. Informacje o tworzeniu testów interfejsu projektów zawierających Compose znajdziesz w artykule Testowanie układu Compose.

Skrót Logcat powoduje konflikt z układami klawiatury w innych językach

Jeśli używasz układu klawiatury w innym języku niż angielski, domyślny skrót klawiaturowy Logcat może powodować konflikt 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 konfliktujący układ klawiszy Logcat. Aby edytować mapowania klawiszy Logcat w Android Studio, otwórz Android Studio > Ustawienia > Mapowanie klawiszy i na liście mapowań klawiszy wyszukaj Logcat. Więcej informacji znajdziesz w tym artykule.

Ten problem zostanie rozwiązany przez usunięcie skrótu Logcat w Androidzie 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 przez narzędzie lint

Podczas uruchamiania narzędzia lint z parametrem checkDependencies = true w module aplikacji zależności biblioteki funkcji dynamicznych nie są sprawdzane, chyba że są też zależnościami aplikacji (problem 191977888). Możesz jednak uruchomić zadanie lint w przypadku tych bibliotek.

Podpisywanie pliku o nazwie zawierającej znaki powrotu karetki

Podpisywanie plików JAR (schemat 1) nie obsługuje nazw plików zawierających znaki powrotu karetki (problem 63885809).

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

Używanie interfejsu Variant API do manipulowania wynikami wariantów jest w przypadku nowej wtyczki niemożliwe. 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"
    }
}

Jednak bardziej skomplikowane zadania, które wymagają dostępu do obiektów outputFile, nie działają już prawidłowo. Dzieje się tak, ponieważ na etapie konfiguracji nie są już tworzone zadania dotyczące konkretnych wersji. W rezultacie wtyczka nie zna wszystkich swoich danych wyjściowych z góry, ale oznacza to też krótszy czas konfiguracji.

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ć funkcję manifestOutputFile(), aby uzyskać plik manifestu dla każdego wariantu, możesz wywołać funkcję manifestOutputFile(), aby zwrócić ścieżkę katalogu zawierającego wszystkie wygenerowane pliki manifestu.processManifest.manifestOutputDirectory() Następnie możesz znaleźć plik manifestu i zastosować do niego swoją logikę. 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ą AIDL w AGP 7.3.0 i Kotlinie 1.7.x

Używanie 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 zestawów źródeł AIDL, w tym zestawów main/, typów kompilacji, wersji produktu i kombinacji wersji produktu. Jeśli musisz używać zestawów źródeł AIDL specyficznych dla wariantu, nadal używaj Kotlin w wersji 1.6.21.

Rozwiązane znane problemy

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

Naprawiono w Android Studio 2021.1.1

• Brak danych wyjściowych narzędzia lint: w stdout nie ma tekstu wyjściowego narzędzia lint, gdy zadanie lint jest UP-TO-DATE (problem nr 191897708). Poprawiono w AGP 7.1.0-alpha05.
• Problemy z testami jednostkowymi projektu aplikacji, który korzysta z wtyczki Hilt: ścieżka klas testów jednostkowych zawiera nieinstrumentowane klasy aplikacji, co oznacza, że Hilt nie instrumentuje klas aplikacji w celu obsługi wstrzykiwania zależności podczas przeprowadzania testów jednostkowych (problem nr 213534628). Rozwiązano w AGP 7.1.1.

Naprawiono w Android Studio 2020.3.1

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

Naprawiono w Androidzie Studio 4.2

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

Naprawiono w Androidzie Studio 4.1

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

Naprawiono w Androidzie Studio 3.6

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

  W Androidzie Studio 3.6 Beta 1 i nowszych to środowisko IDE obsługuje ten wyjątek, przeprowadzają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 wybierano Code > Reformat Code (Kod > Zmień format kodu).

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ż jednej 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 związane z brakiem pamięci.

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