Znane problemy z Androidem Studio i wtyczką Android Gradle

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

Uaktualnij, aby wyświetlić podgląd: wszystkie wersje Android Studio i Androida Celem wtyczki Gradle jest zwiększenie stabilności i wydajności oraz dodanie nowych funkcji. Aby poznać zalety nadchodzących wersji już teraz, pobierz i zainstaluj aplikację Wersja testowa Android Studio

Znane problemy z Android Studio

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

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

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

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

Możliwość izolowania widoku za pomocą osadzonego Inspektor układu jest tymczasowo niedostępny. Pracujemy nad rozwiązaniem tego problemu w kolejnej wersji.

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

Jeśli zauważysz, że nie wszystkie węzły tworzenia są dostępne, gdy używasz inspektora układu, prawdopodobnie jest to spowodowane błędem. poprawionych w funkcji Compose w wersji 1.5.0-alfa04. Jeśli doświadczasz ten problem, upewnij się, że uaktualnisz funkcję Compose do wersji 1.5.0-alfa04 lub wyższe.

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

Poczynając od Chipmunk Studio, java.lang.NoSuchFieldError: view_tree_saved_state_registry_owner lub java.lang.ClassNotFoundException: androidx.savedstate.R$id w panelu problemów, dodaj zależność debugImplementation do androidx.lifecycle:lifecycle-viewmodel-savedstate.

Jeśli widzisz java.lang.NoSuchFieldError: view_tree_lifecycle_owner w problemów, dodaj zależność debugImplementation do androidx.lifecycle:lifecycle-runtime.

Jeśli pojawia się komunikat java.lang.NoClassDefFoundError: Could not initialize class androidx.customview.poolingcontainer.PoolingContainer lub java.lang.NoClassDefFoundError: androidx/customview/poolingcontainer/PoolingContainerListener w panelu Problemy dodaj zależność debugImplementation do androidx.customview:customview-poolingcontainer.

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

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

Po kliknięciu Kompilacja > Wygeneruj podpisany pakiet lub plik APK i próba skonfigurowania podpisywania aplikacji w przypadku pakietu aplikacji lub pliku APK, podanie 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 zarówno dla klucza, jak i do magazynu kluczy.

Android Studio nie uruchamia się po zainstalowaniu wersji 4.2

Studio próbuje zaimportować poprzednie .vmoptions i oczyść je, aby współpracowały z mechanizmem odśmiecania używanym przez JDK 11. Jeśli ten proces się nie powiedzie, IDE może się nie uruchomić w przypadku niektórych użytkowników, którzy ustawić niestandardowe opcje maszyn wirtualnych w pliku .vmoptions.

Aby rozwiązać ten problem, zalecamy dodanie komentarza do opcji niestandardowych. w .vmoptions (korzystając ze znaku „#”). Plikem .vmoptions mogą być: znalezione w następujących 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 Studio nadal się nie uruchamia po wypróbowaniu tego obejścia, zobacz Studio nie uruchamia się po uaktualnieniu poniżej.

Awaria aplikacji Database Inspector w emulatorze Androida 11

Aplikacje korzystające z inspektora baz danych mogą ulegać awarii podczas działania na Androidzie 11 emulator z błędem 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 do wybierając Narzędzia > Menedżer pakietów SDK. Na karcie Platformy SDK sprawdź, pole Pokaż szczegóły pakietu i wybierz wersję 9 lub nowszą za pomocą emulatora Androida 11.

Studio nie uruchamia się po uaktualnieniu

Jeśli Studio nie uruchomi się po uaktualnieniu, przyczyną problemu może być nieprawidłowa Konfiguracja Android Studio zaimportowana z poprzedniej wersji Android Studio lub niezgodnej wtyczki. Aby obejść ten problem, usuń fragment (lub zmień jego nazwę) w celu utworzenia kopii zapasowej) poniżej, w zależności od wersji Androida Studio. i system operacyjny, a następnie ponownie uruchom Android Studio. Spowoduje to zresetowanie Androida Studio do stanu domyślnego, bez wszystkich wtyczek innych firm.

Android Studio 4.1 i nowsze wersje:

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

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

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

Android Studio 4.0 lub starszy:

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

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

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

Uwaga: katalog konfiguracji Androida w wersji Canary i Beta Studio kosztuje PreviewX.Y, a nie X.Y w przypadku <version> Na przykład Android Kompilacje Studio 4.1 w wersji Canary używają parametru AndroidStudioPreview4.1, a nie Katalog AndroidStudio4.1 używany na potrzeby kandydatów do wersji i wersji stabilnej wersji.

Problem z kompilacją w projektach wieloplatformowych Kotlin

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

Konflikty mapowania kluczy w systemie Linux

W Linuksie niektóre skróty klawiszowe powodują konflikty z domyślną klawiaturą w Linuksie skrótów, a także 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 na temat tego problemu (w tym możliwe sposoby obejścia) można znaleźć na stronie w narzędziu IntelliJ do wykrywania błędów.

Mały tekst interfejsu w ChromeOS

W ChromeOS tekst może być znacznie mniejszy niż w poprzednich wersjach. Do pracy W tej kwestii wykonaj te czynności:

  1. Otwórz okno Ustawienia, klikając Plik > Ustawienia
  2. Przejdź do sekcji Wygląd Zachowanie > Wygląd.
  3. Wybierz Użyj czcionki niestandardowej.
  4. Zwiększ rozmiar czcionki.
  5. W oknie Ustawienia przejdź do sekcji 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 z klawiatury – „iBus” problemy w systemie Linux

Istnieje kilka filmów, w których z demonem iBus w systemach Linux i Android Studio. W niektórych w scenariuszach IDE przestaje reagować na wprowadzanie tekstu z klawiatury lub zaczyna wprowadzać tekst losowe znaki. Ten błąd jest aktywowany przez brak synchronizacji między iBus a XLib + AWT i został już zgłoszony Odrzutowe mózgi i iBus. Istnieją dostępne są trzy aktualne sposoby obejścia tego problemu:

  • Rozwiązanie tymczasowe 1: wymuś tryb synchroniczny iBus. Zanim uruchomisz Androida W Studio uruchom to polecenie:
    $ IBUS_ENABLE_SYNC_MODE=1 ibus-daemon -xrd
  • Obejście 2. Wyłącz wejście iBus w Android Studio. Wyłączanie wejścia iBus (tylko w Android Studio), uruchom w wierszu poleceń to polecenie:
    $ XMODIFIERS= ./bin/studio.sh
    To obejście wyłącza tylko metody wprowadzania w Android Studio, a nie innych uruchomionych aplikacji. Pamiętaj, że po ponownym uruchomieniu demona podczas działania Android Studio (na przykład ibus-daemon -rd), metody wprowadzania zostaną wyłączone w przypadku wszystkich innych aplikacji. Może też doprowadzić do awarii JVM Androida Studio, błąd segmentacji.
  • Rozwiązanie problemu 3: dokładnie sprawdź powiązania skrótów i upewnij się, że Skrót do następnego wprowadzania nie jest ustawiony na klawisze Ctrl+spacja, ponieważ jest to też lub skrót do uzupełniania kodu w Android Studio. Ubuntu 14.04 (Trusty) ustawia skrót Super+Spacja jako domyślny skrót, ale nie zmienia ustawień z poprzedniego które mogą być wciąż dostępne. Aby sprawdzić powiązania skrótów, uruchom polecenie ibus-setup w wierszu polecenia, aby otworzyć okno preferencji IBus. W sekcji Skróty klawiszowe zaznacz Następna metoda wprowadzania. Jeśli tak naciśnij Control+spacja, zmień na Super+spacja lub inny skrót wyboru.

Konfiguracja projektu

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

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

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

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

Główną przyczyną tych błędów jest brak certyfikatu w regionie $JAVA_HOME/jre/lib/certificates/cacerts Aby naprawić te błędy, przejdź dalej w następujący sposób:

  • Jeśli korzystasz z serwera proxy, spróbuj połączyć się bezpośrednio. Jeśli bezpośrednia połączenia, więc aby połączyć się przez serwer proxy, konieczne może być Użyj keytool, aby dodać certyfikat serwera proxy do pliku cacerts.
  • Ponownie zainstaluj obsługiwany, niezmodyfikowany pakiet JDK. Jest znany problem która ma wpływ na użytkowników systemu Ubuntu, co skutkuje pustym /etc/ssl/certs/java/cacerts Aby obejść ten problem, uruchom polecenie 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 w połączonym urządzenia.

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

Dotyczy problemu Gradle 18149 Wtyczka Androida do obsługi Gradle w wersji 7.0 lub nowszej, ponieważ wymaga ona narzędzia Gradle w wersji 7.0 lub nowszej. Od wersji Gradle 7.0 oglądanie plików jest domyślnie włączone. Jeśli pracujesz w systemie Mac OS, a Twój projekt jest zapisany w katalogu /System/Volumes/Data, podczas oglądania plików Gradle nie będzie można prawidłowo śledzić zmian w plikach. Dzięki temu system kompilacji nie będzie widzieć żadnych zmian w plikach i będzie dlatego nie aktualizuj plików APK. Przyrostowy kod wdrożenia Nic, ponieważ stan lokalnego pliku APK jest taki sam jak na urządzeniu.

Aby obejść ten problem, przenieś katalog projektu na użytkownika czyli w katalogu /Users/username. System kompilacji zostanie dodany prawidłowe powiadomienia o zmianach w plikach przez obserwowanie plików Gradle i przyrostowe zmiany zostaną zastosowane.

Emulator Androida HAXM w macOS High Sierra

Emulator Androida jest włączony macOS High Sierra (10.13) wymaga HAXM w wersji 6.2.1 lub nowszej, i stabilne działanie systemu macOS. System macOS 10.13 ma jednak jest proces instalowania rozszerzeń jądra, np. HAXM. Potrzebujesz , aby ręcznie zainstalować rozszerzenie jądra w taki sposób:

  1. Najpierw spróbuj zainstalować najnowszą wersję HAXM z Menedżer SDK
  2. W systemie MacOS otwórz Preferencje systemowe > Bezpieczeństwo i prywatność.
  3. Jeśli pojawi się alert informujący o tym, że Oprogramowanie systemowe firmy Intel Corporation Aplikacje został zablokowany wczytywanie, kliknij Zezwól:

Więcej informacji i sposobów obejścia problemu znajdziesz w sekcji tę stronę internetową firmy Apple oraz nr 62395878.

Apply Changes

W tej sekcji opisano znane problemy związane ze stosowaniem strategii Zastosuj Zmiany.

Nie zastosowano nowej nazwy aplikacji

Jeśli zmienisz nazwę aplikacji, a potem spróbujesz ją zastosować, zaktualizowana nazwa może nie zostaną uwzględnione. 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, możesz napotkać „VERIFICATION_ERROR” komunikatów podczas próby zastosowania określonych typów zmian (zwłaszcza w przypadku korzystania z Kotlina). Przyczyną tego komunikatu jest problem z usługą środowisko wykonawcze Androida naprawione w Androidzie 9.0 i nowszych. Chociaż problem sprawia, że zastosowanie zmian kończy się niepowodzeniem, możesz mimo to Uruchom Ikona uruchamiania jeszcze raz aplikację, aby zobaczyć zmiany. Zalecamy jednak uaktualnienie z Androidem 9.0 lub nowszym.

Debugowanie i testowanie

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

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

Jeśli w modułach Java są określone foldery zasobów, podczas wykonywania testów z IDE nie można znaleźć zasobów. Przeprowadzanie testów użycie Gradle z wiersza poleceń. Wykonywanie polecenia Gradle check z IDE. Zobacz problem 64887, aby dowiedzieć się więcej. .

Ten problem występuje, ponieważ od wersji IntelliJ 13, która wymaga pojedynczy folder jako ścieżki klasy. Kreator IntelliJ kopiuje wszystkie zasoby do tego folderu kompilacji, ale Gradle nie kopiuje zasobów.

  • Rozwiązanie problemu 1. Uruchom zadanie Gradle check z IDE, a nie przeprowadzając test jednostkowy.
  • Obejście problemu 2. Zaktualizuj skrypt kompilacji, ręcznie kopiując zasoby w folderze kompilacji. Zobacz komentarz 13 .

Testy JUnit mogą spowodować dwukrotne skompilowanie kodu

Podczas tworzenia nowego projektu może zostać utworzona szablonowa konfiguracja JUnit i dwie opcje „Przed uruchomieniem” kroki: Marka z uwzględnieniem Gradle. Ta konfiguracja jest następnie propagowana do wszystkich utworzonych konfiguracji uruchamiania JUnit.

  • Aby rozwiązać problem w bieżącym projekcie, kliknij Uruchom > Edytuj Configurations (Konfiguracje) i zmień domyślną konfigurację JUnit na tylko dodaj krok tworzenia z uwzględnieniem Gradle.
  • Aby rozwiązać ten problem we wszystkich przyszłych projektach, kliknij Plik > Zamknij Projekt. Powinien pojawić się ekran powitalny. Następnie kliknij Skonfiguruj > Domyślne ustawienia projektu > Uruchom konfiguracje i zmień JUnit aby uwzględnić tylko krok tworzenia z uwzględnieniem Gradle.

Niektóre konfiguracje uruchomienia testowego nie działają

Nie wszystkie uruchamiane konfiguracje, które są dostępne, jeśli kliknięcie prawym przyciskiem myszy dla metody testowej jest prawidłowe. Mówiąc konkretnie, te konfiguracje są nieprawidłowe:

  • Konfiguracje uruchamiania Gradle (które mają logo Gradle jako ikonę) nie są w naszej pracy.
  • Konfiguracje uruchamiania JUnit (które mają ikonę bez zielonego elementu Android) nie mają zastosowania do testów narzędziowych, których nie można uruchamiać na lokalnej maszynie wirtualnej JVM.
. Android Studio pamięta również konfigurację uruchamiania utworzoną w danym (na przykład kliknięcie prawym przyciskiem myszy konkretnej klasy lub metody) i nie że w przyszłości będzie działać w innej konfiguracji. Aby rozwiązać ten problem, kliknij Uruchom > Edytuj konfiguracje i usuń nieprawidłowo utworzone konfiguracji.

Dodawanie punktów przerwania w Javie podczas debugowania kodu natywnego

Gdy aplikacja jest wstrzymana w punkcie przerw w interfejsie natywnym kodu, debugery Auto i Podwójne mogą nie rozpoznać od razu tego ustawione przez Ciebie nowe punkty przerwania. Aby uniknąć tego problemu, dodaj punkty przerwania Javy przed rozpoczęciem sesji debugowania lub gdy aplikacja jest wstrzymana w kodzie Java między punktami przerwania. Więcej informacji znajdziesz w artykule Problem 229949).

Zamykanie natywnego debugera

Jeśli używasz debugera automatycznego lub podwójnego do: debugowanie Javy i kodu natywnego, jeśli uruchomisz funkcję natywną z w kodzie Java (np. debuger wstrzymuje wykonywanie wiersza w w kodzie Java, który wywołuje funkcję natywną i klikasz Step Into (Krok 1). ) i chcesz wrócić do kodu Java, kliknij Wznów program (zamiast Wyjścia i Kroku Over ). Proces aplikacji nadal zostanie wstrzymany, więc kliknij Wznów Programuj w komponencie your-module-java aby ją wznowić. Więcej informacji znajdziesz w artykule Problem 224385).

Debuger natywny zawiesza się podczas wczytywania bibliotek

Podczas pierwszego korzystania z debugera natywnego po przejściu na Androida Studio 4.2 lub nowszym, natywny debuger może przestać odpowiadać podczas wczytywania z bibliotek z Androidem. Ten problem jest trwały może się pojawić nawet po zatrzymaniu i ponownym uruchomieniu debugera. Aby rozwiązać ten problem: usuń pamięć podręczną LLDB na $USER/.lldb/module-cache/.

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

Ten błąd występuje na platformach Linux przy uruchamianiu natywny debuger. Wskazuje on, że jedna z bibliotek wymaganych przez natywny w systemie lokalnym nie jest zainstalowany debuger. imię i nazwisko zaginionej osoby, biblioteka może być już wydrukowana w pliku idea.log. Jeśli nie, możesz użyć w terminalu i przejść do katalogu instalacyjnego Android Studio i uruchomić polecenie wiersza poleceń bin/lldb/bin/LLDBFrontend --version, aby dowiedzieć się, które biblioteki których brakuje. Zwykle brakującą biblioteką jest ncurses5, ponieważ w niektórych nowszych wersjach systemu Linux dystrybucja została już uaktualniona do ncurses6.

Programy profilujące

W tej sekcji opisano znane problemy z programami profilowymi.

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

Program Native Memory Profiler jest obecnie niedostępny podczas uruchamiania aplikacji. Ten zostanie udostępniona w kolejnej wersji.

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

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

Może pojawić się komunikat „Nie udało się zatrzymać nagrywania” Błędy procesora w Android Studio program profilujący po wybraniu opcji Sample Java Methods (Przykładowe metody Java) lub Trace Java Methods (Śledzenie w języku Java). konfiguracji. Są to często błędy przekroczenia limitu czasu, zwłaszcza jeśli widzisz ten komunikat o błędzie w pliku idea.log:

Wait for ART trace file timed out

Błędy limitu czasu mają zwykle większy wpływ na metody śledzenia niż metody próbkowane. dłuższe nagrania są dłuższe niż krótsze. W ramach tymczasowego obejścia tego problemu warto spróbować krótszych nagrań, by sprawdzić, czy błąd zniknie.

Jeśli w narzędziu do profilowania wystąpią problemy z limitem czasu, zgłoś błąd. z uwzględnieniem marki/modelu urządzeń oraz wszelkich odpowiednich pozycji idea.log i logcat.

Wyjątek ADB podczas debugowania lub profilowania

Jeśli korzystasz z narzędzi Platform Tools w wersji 29.0.3, debugowania natywnego i Android Studio, Profile mogą nie działać prawidłowo i możesz zobaczyć jeden z tych komunikatów: „AdbCommandRequestException” lub „Nie udało się połączyć z portem” idea.log po wybraniu Pomoc > Pokaż dziennik. Uaktualnianie narzędzi platformy do 29.0.4 lub nowsza wersja rozwiązuje oba te problemy.

Aby uaktualnić narzędzia platformy:

  1. Otwórz Menedżera SDK w Android Studio, klikając Narzędzia > SDK Manager lub Menedżer SDK na pasku narzędzi.
  2. Zaznacz pole wyboru obok Android SDK. Platform-Narzędzia, aby pojawił się znacznik wyboru. Ikona pobierania W lewej kolumnie powinien pojawić się .
  3. Kliknij Zastosuj lub OK.

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

Użycie wtyczki CMake prostego zaznaczania zapobiega wyświetlaniu treści w Utwórz okno danych wyjściowych. Kompilacja jest uruchomiona i pojawia się karta Wyniki kompilacji, nie wydrukuje się żadnych danych (problem #204791544).

Kolejność instalacji uniemożliwia uruchomienie

Zainstalowanie nowszej wersji Android Studio przed starszą wersją może i uniemożliwia uruchomienie starszej wersji. Na przykład, jeśli po raz pierwszy zainstalujesz do wczesnych testów Androida Studio, a potem spróbuj zainstalować i uruchomić stabilną wersję wersja stabilna może się nie uruchomić. W takich przypadkach musisz Wyczyść pamięć podręczną, aby uruchomić aplikację w wersji stabilnej (starszej). W systemie macOS, aby wyczyścić dane pamięć podręczna usuń Library/ApplicationSupport/Google/AndroidStudioversion_number katalogu. Do wyczyszczenia pamięci podręcznej w systemie Windows użyj polecenia Czyszczenie dysku.

Dyktafon Espresso Tester nie działa z funkcją tworzenia

Rejestrator testów espresso nie działa w projektach, które zawierają funkcję Utwórz. Tworzenie testów UI w projektach zawierające funkcję Compose, przeczytaj artykuł Testowanie układu tworzenia wiadomości.

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

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

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

Znane problemy z wtyczką Androida do obsługi Gradle

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

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

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

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

Podpisywanie JAR (schemat w wersji 1) nie obsługuje nazw plików zawierających znaki karetki zwracaj znaki (numer problemu 63885809).

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

Używanie interfejsu API wariantów do manipulowania wynikami wariantów nie działa w ramach wtyczki. Nadal działa też w przypadku prostych zadań, takich jak zmiana nazwy pakietu APK w trakcie czas 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"
    }
}

ale bardziej skomplikowane zadania wymagają dostępu do obiektów outputFile. już nie działa. Dzieje się tak, ponieważ nie są już tworzone zadania dla konkretnego wariantu podczas konfiguracji. Dzięki temu dodatek nie wie, wszystkich danych wyjściowych, ale też skraca czas konfiguracji.

Plik manifestOutputFile nie jest już dostępny

Metoda processManifest.manifestOutputFile() nie jest już i po wywołaniu pojawi się następujący błąd:

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

Zamiast wywoływać manifestOutputFile() w celu pobrania pliku manifestu dla każdego wariantu, możesz wywołać metodę processManifest.manifestOutputDirectory(), aby zwrócić ścieżki do katalogu zawierającego wszystkie wygenerowane pliki manifestu. Następnie możesz: zlokalizuj plik manifestu i zastosuj do niego swoją logikę. Przykład poniżej dynamicznego 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 Kotlin 1.7.x

Użycie AGP 7.3.0 z KAPT w kotlinie 1.7.x powoduje, że źródła AIDL ustawiają konkretnych wersji kompilacji, które mają zostać usunięte. Nadal możesz używać innego źródła AIDL zestawy, w tym te z kategorii main/, typy kompilacji, rodzaje produktów i kombinacje smaków produktów. Jeśli musisz używać zbiorów źródłowych AIDL dla konkretnego wariantu: nadal korzystać z Kotlin 1.6.21.

Rozwiązano znane problemy

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

Poprawione w Android Studio 2021.1.1

  • Brak danych wyjściowych lintowania: na serwerze stdout nie ma danych wyjściowych lintowania, zadanie lintowania to UP-TO-DATE (numer problemu 191897708). Poprawiono w AGP 7.1.0-alpha05.
  • Problemy z testowaniem jednostkowym projektu aplikacji korzystającego z wtyczki Hilt: Ścieżka klasy testu jednostkowego zawiera klasy aplikacji nieinstrumentowane, co oznacza, że Hilt nie dopasowuje klas aplikacji do wstrzykiwania zależności, gdy przeprowadzanie testów jednostkowych (numer problemu: 213534628). Poprawiono w AGP 7.1.1.

Poprawiono w Android Studio 2020.3.1

  • Wyjątki Lint w projektach Kotlin: projekty Kotlin, które W przypadku checkDependencies = true mogą występować błędy lub wyjątki dotyczące wskaźnika null (numer problemu 158777858).

Poprawiono w Android Studio 4.2

  • IDE zawiesza się na macOS Big Sur: Android Studio 4.1 może zawiesić się otworzyć okno dialogowe.

Poprawiono w Android Studio 4.1

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

Naprawiono w Android Studio 3.6

  • Błąd instalacji pliku APK w systemie LineageOS: wdrażanie aplikacji na urządzeniach w przypadku określonych wersji systemu LineageOS lub CyanogenMod mogą wystąpić problemy wyjątek: INSTALL_PARSE_FAILED_NOT_APK.

    W Android Studio 3.6 Beta 1 lub nowszym IDE obsługuje ten wyjątek przez przeprowadzanie pełnej instalacji aplikacji po jej wdrożeniu. na urządzeniach LineageOS lub CyanogenMod, co może skutkować dłuższym czasem wdrożenia razy.

Naprawiono w Android Studio 3.5.2

  • Nieprawidłowy styl kodu XML: podczas edytowania kodu XML w IDE zastosowano komponent niepoprawny styl kodu po wybraniu opcji Kod > Sformatuj kod z na pasku menu.

Naprawiono w Android Studio 3.3.1

  • Błędy braku pamięci podczas skanowania projektów opartych na C++: podczas skanowania przez Gradle. projektu, który ma kod C++ w więcej niż jednej lokalizacji na tym samym dysku, skanowanie obejmuje wszystkie katalogi poniżej pierwszego wspólnego katalogu. Skanuję duża liczba katalogów i plików może powodować błędy braku pamięci.

    Więcej informacji na ten temat znajdziesz na stronie błąd powiązany z tagiem Google Cloud.