Esta página monitora problemas conhecidos com o Android Studio 4.1 e o Plug-in do Android para Gradle 4.1. Se você tem um problema que ainda não está incluído aqui, informe um bug.
Faça upgrade para a versão de pré-lançamento: cada versão do Android Studio e do Plug-in do Android para Gradle visa melhorar a estabilidade e o desempenho, além de acrescentar novos recursos. Para conhecer os benefícios das próximas versões, faça o download da versão de pré-lançamento do Android Studio e a instale.
Problemas conhecidos com o Android Studio
Esta seção descreve problemas conhecidos que existem na versão estável mais recente do Android Studio.
O Android Studio trava no macOS Big Sur
Em máquinas com o macOS Big Sur, o Android Studio 4.1 pode travar quando você abre uma caixa de diálogo.
Para resolver esse problema, siga uma destas etapas:
- Acesse o menu Apple, selecione Preferências do Sistema > Geral. Na opção Preferir abas ao abrir documentos, selecione "nunca". Em seguida, reinicie o Android Studio.
- Faça upgrade para o Android Studio 4.2, disponível no Canal Beta.
Apps que usam o Database Inspector falham no emulador do Android 11
Os apps que usam o Database Inspector podem falhar ao serem executados no emulador do Android 11. Um erro como este aparecerá no logcat:
Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
Para corrigir esse problema, atualize o emulador do Android 11 para a versão 9 ou mais recente em Tools > SDK Manager. Na guia SDK Platforms, marque a caixa Show Package Details e selecione a revisão 9 ou mais recente do emulador do Android 11.
O Studio não inicia após o upgrade
Se a ferramenta não for iniciada após um upgrade, é possível que o problema esteja relacionado a uma configuração inválida do Android Studio importada de uma versão mais antiga dele ou um plug-in incompatível. Como solução alternativa, tente excluir (ou renomear, para fins de backup) o diretório abaixo, dependendo da versão do Android Studio e do sistema operacional, e reiniciar a ferramenta. Essa ação redefinirá o Android Studio para o estado padrão, com todos os plug-ins de terceiros removidos.
Para o Android Studio 4.1 e versões mais recentes:
Windows:
%APPDATA%\Google\AndroidStudio<version>
Exemplo:C:\Users\your_user_name\AppData\Roaming\Google\AndroidStudio4.1
macOS:
~/Library/Application Support/Google/AndroidStudio<version>
Exemplo:~/Library/Application Support/Google/AndroidStudio4.1
Linux:
~/.config/Google/AndroidStudio<version>
e~/.local/share/Google/AndroidStudio<version>
Exemplo:~/.config/Google/AndroidStudio4.1
e~/.local/share/Google/AndroidStudio4.1
Para o Android Studio 4.0 e versões anteriores:
Windows:
%HOMEPATH%\.AndroidStudio<version>\config
Exemplo:C:\Users\your_user_name\.AndroidStudio3.6\config
macOS:
~/Library/Preferences/AndroidStudio<version>
Exemplo:~/Library/Preferences/AndroidStudio3.6
Linux:
~/.AndroidStudio<version>/config
Exemplo:~/.AndroidStudio3.6/config
Observe que o diretório de configuração para as versões Canary e Beta do Android
Studio é PreviewX.Y
em vez de X.Y
para
a versão <version>
. Por exemplo, os builds do Android
Studio 4.1 Canary usam AndroidStudioPreview4.1
em vez do
diretório AndroidStudio4.1
, que é usado para os candidatos a lançamento e as versões
estáveis.
Problema de compilação em projetos Kotlin multiplataforma
Erros de compilação podem surgir no código MPP do Kotlin devido à ausência de símbolos. O upgrade do seu plug-in do Kotlin para a versão 1.4 resolverá esse problema.
Os botões Run, Debug e Profile não aparecem na barra de ferramentas
Se você personalizou o grupo de botões de ação Run/Debug, por exemplo, modificando as opções em Appearance & Behavior > Menus and Toolbars na janela Settings ou Preferences, esses botões de ação podem desaparecer da barra de ferramentas após a reinicialização do ambiente de desenvolvimento integrado. Esse é um problema conhecido na versão do IntelliJ em que o Android Studio 4.0 é criado. Consulte o problema IDEA-228450 (link em inglês).
Para resolver esse problema, reverta as personalizações feitas nesses botões da seguinte maneira:
- Selecione File > Settings (ou Android Studio > Preferences no macOS).
- Na parte esquerda da janela, navegue até Appearance & Behavior > Menus and Toolbars.
- Na parte direita da janela, navegue até Main Toolbar > Toolbar Run Actions e selecione Run/Debug.
- Perto da parte superior da janela, clique em Revert
e selecione Restore Run/Debug.
- Clique em OK. Agora você verá os botões que não estavam aparecendo na barra de ferramentas.
Conflitos de mapeamento de atalhos no Linux
No Linux, alguns atalhos de teclado entram em conflito com os atalhos de teclado padrão do sistema e de gerenciadores de janelas conhecidos, como KDE e GNOME. Esses atalhos de teclado conflitantes podem não funcionar como esperado no Android Studio.
Mais informações sobre esse problema, incluindo possíveis soluções, podem ser encontradas no rastreador de bugs do IntelliJ (link em inglês).
Texto pequeno na IU do Chrome OS
No Chrome OS, o texto pode parecer muito menor do que nas versões anteriores. Para contornar esse problema, faça o seguinte:
- Abra a janela Configurações clicando em Arquivo > Configurações.
- Navegue até Aparência e Comportamento > Aparência.
- Selecione Use custom font.
- Aumente o tamanho da fonte.
- Na janela Settings, navegue até Editor > Font.
- Aumente o tamanho da fonte.
- Clique em OK.
Edição de código
Esta seção descreve problemas conhecidos relacionados ao editor de código.
Entrada de teclado congelada: problemas do iBus no Linux
Há algumas interações conhecidas entre o daemon iBus no Linux e o Android Studio. Em alguns cenários, o ambiente de desenvolvimento integrado para de responder à entrada do teclado ou começa a inserir caracteres aleatórios. Esse bug ocorre por alguma sincronização ausente entre o iBus e o XLib + AWT e já foi relatado ao JetBrains (link em inglês) e ao iBus. Existem três soluções alternativas atuais para esse problema:
- Solução alternativa 1: force o iBus para o modo síncrono. Antes de iniciar o Android
Studio, execute o seguinte na linha de comando:
$ IBUS_ENABLE_SYNC_MODE=1 ibus-daemon -xrd
- Solução alternativa 2: desative a entrada do iBus no Android Studio. Para desativar a entrada do iBus
somente para o Android Studio, execute o seguinte na linha de comando:
$ XMODIFIERS= ./bin/studio.sh
Essa solução só desativa métodos de entrada para o Android Studio, e não para os outros aplicativos que você possa estar executando. Se você reiniciar o daemon enquanto o Android Studio estiver em execução (por exemplo, executandoibus-daemon -rd
), você desativará os métodos de entrada para todos os outros aplicativos e poderá causar uma falha na JVM do Android Studio com um erro de segmentação. - Solução alternativa 3: confira as vinculações de atalho para garantir que o
Next input shortcut não esteja definido como "Control+Space" (Ctrl+Espaço), já que esse também é
o atalho de conclusão de código no Android Studio. O Ubuntu 14.04 (Trusty)
torna "Super+Space" (Super+Espaço) o atalho padrão, mas as configurações das versões
anteriores ainda podem estar disponíveis. Para conferir suas vinculações de atalhos, execute
ibus-setup
na linha de comando para abrir a janela IBus Preferences. Em Keyboard Shortcuts, confira o Next input method. Se ele estiver definido como "Control+Space" (Ctrl+Espaço), mude para "Super+Space" (Super+Espaço) ou outro atalho que preferir.
Configuração do projeto
Esta seção descreve problemas conhecidos relacionados à configuração do projeto e à sincronização do Gradle.
Falha na sincronização do Gradle: encadeamento corrompido
O problema é que o daemon Gradle está tentando usar IPv4 em vez de IPv6.
- Solução alternativa 1: no Linux, coloque o seguinte no seu
~/.profile
ou~/.bash_profile
:export _JAVA_OPTIONS="-Djava.net.preferIPv6Addresses=true"
- Solução alternativa 2: no arquivo
vmoptions do Android Studio,
mude a linha
-Djava.net.preferIPv6Addresses=true
para-Djava.net.preferIPv6Addresses=true
. Para ver mais informações, consulte o Guia do usuário de rede IPv6 (em inglês).
Erros "par não autenticado" da sincronização do Gradle ou SDK Manager
A causa desses erros é um certificado ausente em
$JAVA_HOME/jre/lib/certificates/cacerts
. Para resolver esses erros, faça o
seguinte:
- Se você tiver a proteção de um proxy, tente se conectar diretamente. Se a conexão
direta funcionar, para se conectar pelo proxy talvez seja necessário
usar
keytool
para adicionar o certificado do servidor proxy ao arquivo cacerts. - Reinstale um JDK compatível e não modificado. Há um
problema conhecido (link em inglês)
que afeta os usuários do Ubuntu, resultando em um
/etc/ssl/certs/java/cacerts
vazio. Para contornar esse problema, execute o seguinte na linha de comando:sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure
Implantação
Esta seção descreve problemas conhecidos relacionados à implantação do seu app em um dispositivo conectado.
HAXM do Android Emulator no macOS High Sierra
O Android Emulator no macOS High Sierra (10.13) requer o HAXM 6.2.1 ou uma versão mais recente para melhor compatibilidade e estabilidade com o macOS. No entanto, o macOS 10.13 tem um processo mais complicado para instalar extensões do kernel, como o HAXM. Você precisa fazer o seguinte para permitir manualmente que a extensão do kernel seja instalada:
- Primeiro, tente instalar a versão mais recente do HAXM pelo SDK Manager.
- No MacOS, vá para Preferências do Sistema > Segurança e Privacidade.
Se você receber um alerta informando que O carregamento do software do sistema do desenvolvedor "Intel Corporation Apps" foi bloqueado, clique em Permitir:
Para ver mais informações e soluções alternativas, consulte esta página da Apple (link em inglês) e o problema 62395878.
O Android Studio força o fechamento do app de maneira incorreta
Nas versões 4.0.x ou 4.1, o Android Studio força incorretamente o fechamento de um app depurável se o app é fechado.
Esse problema causa os seguintes efeitos colaterais indesejáveis:
- Serviços que são iniciados usando
START_STICKY
não são tratados como fixos (problema 156855259). - Os jobs e alarmes programados para serem executados em segundo plano são cancelados (problema 165787618).
- O evento de fechamento forçado é registrado no logcat (problema 168311418).
Apply Changes
Esta seção descreve problemas conhecidos relacionados ao recurso Apply Changes.
O novo nome do app não foi aplicado
Se você renomear o app e tentar aplicar essa mudança, o nome atualizado poderá
não ser apresentado. Para contornar esse problema, clique em Run
para implantar o app novamente e ver as mudanças.
Problema no Android Runtime gera erro
Se você estiver usando um dispositivo com o Android 8.0 ou 8.1, poderá encontrar mensagens
"VERIFICATION_ERROR" ao tentar aplicar alguns tipos de mudanças,
principalmente se estiver usando o Kotlin. Essa mensagem é causada por um problema no
Android Runtime que foi corrigido no Android 9.0 e em versões mais recentes. Embora o problema
faça com que o Apply Changes falhe, você ainda pode clicar em Run
para executar seu app novamente e ver as mudanças. No entanto, recomendamos que você faça upgrade do
dispositivo para o Android 9.0 ou uma versão mais recente.
O Apply Changes falha com ShellCommandUnresponsiveException
Ao usar o Apply Changes no Android Studio 4.1 e em versões anteriores, é possível que um
dispositivo fique preso em um estado que impede que mudanças sejam aplicadas
a ele. Quando esse problema ocorre, o Apply Changes falha com um
ShellCommandUnresponsiveException
.
Para solucionar o problema, execute o seguinte comando adb:
adb shell rm -fr /data/local/tmp/.studio
Não é possível aplicar as mudanças ao usar android:sharedUserId
Se você tentar modificar uma classe que ainda não tenha sido implantada no app em execução, a opção Apply Changes falhará caso o app esteja configurado de uma das seguintes maneiras:
- Seu app compartilha dados com outro app usando um
android:sharedUserId
compartilhado. - Seu app é executado no mesmo processo que outro app usando um
android:sharedUserId
e umandroid:process
compartilhados.
Quando o Apply Changes falha devido a esse problema, o Android Studio exibe a seguinte mensagem:
Changes were not applied. JVMTI error: UNKNOWN_JVMTI_ERROR
Para solucionar o problema no Android Studio 3.5, clique em Run
para implantar novamente o app e ver as mudanças.
Depuração e testes
Esta seção descreve problemas conhecidos relacionados a depuração e testes do seu aplicativo.
Recursos de testes JUnit ausentes no caminho de classe quando executados no Android Studio
Se você tiver pastas de recursos específicas nos seus módulos Java, esses
recursos não serão encontrados quando os testes do ambiente de desenvolvimento integrado forem executados. A execução de testes
usando o Gradle na linha de comando funcionará. A execução da tarefa check
do Gradle no ambiente de desenvolvimento integrado também funcionará. Para ver mais detalhes,
consulte o problema
64887.
Esse problema ocorre porque, a partir do IntelliJ 13, você só pode ter uma única pasta como o caminho de classe. O builder do IntelliJ copia todos os recursos para essa pasta de build, mas o Gradle não copia por cima dos recursos.
- Solução alternativa 1: execute a tarefa
check
do Gradle pelo ambiente de desenvolvimento integrado em vez de um teste de unidade. - Solução alternativa 2: atualize seu script de compilação para copiar recursos manualmente para a pasta de build. Consulte o comentário 13 para ver mais informações.
A execução de testes JUnit pode compilar o código duas vezes
Durante a criação de um novo projeto, a configuração JUnit do modelo pode ser criada com duas etapas "Antes do lançamento": Make e Gradle-aware Make. Em seguida, essa configuração é propagada para todas as configurações de execução do JUnit criadas.
- Para corrigir o problema do projeto atual, clique em Run > Edit Configurations e mude a configuração padrão do JUnit para incluir apenas a etapa Gradle-aware Make.
- Para corrigir o problema para todos os projetos futuros, clique em File > Close Project. Você verá a tela de boas-vindas. Em seguida, clique em Configure > Project Defaults > Run Configurations e mude a configuração do JUnit para incluir apenas a etapa Gradle-aware Make.
Algumas configurações de execução de teste não funcionam
Nem todas as configurações de execução que estão disponíveis ao clicar com o botão direito do mouse em um método de teste são válidas. Especificamente, as configurações a seguir não são válidas:
- As configurações de execução do Gradle, que têm o logotipo do Gradle como ícone, não funcionam.
- As configurações de execução do JUnit, que têm um ícone sem o Android verde, não se aplicam a testes de instrumentação, que não podem ser executados na JVM local.
Acréscimo de pontos de interrupção Java ao depurar código nativo
Enquanto seu app está pausado em um ponto de interrupção no código nativo, os depuradores Auto e Dual podem não reconhecer imediatamente os novos pontos de interrupção Java que você definiu. Para evitar esse problema, adicione pontos de interrupção Java antes de iniciar uma sessão de depuração ou enquanto o app estiver pausado em um ponto de interrupção Java. Para ver mais informações, consulte o problema 229949.
Sair do depurador nativo
Ao usar o depurador Auto ou Dual para
depurar um código nativo e Java, se você entrar em uma função nativa usando
seu código Java (por exemplo, o depurador pausa a execução em uma linha no seu
código Java que chama uma função nativa e você clica em Step Into
) e quiser retornar ao código Java, clique em
Resume Program
, em vez de em Step Out
ou Step Over
. O processo do seu app ainda ficará pausado, então clique em Resume
Program
na guia your-module-java
para retomá-lo. Para ver mais informações, consulte o problema
224385.
Criadores de perfil
Esta seção descreve problemas conhecidos com o Criadores de perfil.
Etiquetas ausentes na IU do Rastreamento do sistema
Em máquinas Windows com fatores de escalonamento de 125% e 175%, as etiquetas podem desaparecer de determinados elementos na IU do Rastreamento do sistema, incluindo a linha do tempo de atividade das linhas de execução. Para solucionar esse problema, mude o fator de escalonamento da sua tela para qualquer valor, exceto 125% ou 175%.
Esse problema foi corrigido no Android Studio 4.2.
Memory Profiler nativo: a criação de perfil não está disponível durante a inicialização do app
O Memory Profiler nativo não está disponível durante a inicialização do app. Essa opção estará disponível em uma versão futura.
Como solução alternativa, você pode usar o Perfetto, um criador de perfil autônomo de linha de comando, para capturar perfis de inicialização.
Erros de tempo limite no CPU Profiler
Você pode enfrentar erros "Recording failed to stop" no CPU Profiler do Android Studio ao selecionar as configurações Sample Java Methods ou Trace Java Methods. Eles costumam ser erros de tempo limite, especialmente quando é exibida a seguinte mensagem de erro no arquivo idea.log
:
Wait for ART trace file timed out
Os erros de tempo limite tendem a afetar os métodos rastreados mais do que os métodos de amostra e os registros longos mais do que os registros curtos. Como solução temporária, pode ser útil tentar gravações mais curtas para ver se o erro desaparece.
Se você tiver problemas de tempo limite com o Profiler, registre um bug
que inclua a marca/modelo dos seus dispositivos e quaisquer entradas relevantes de
idea.log
e logcat.
Exceção do adb durante a depuração ou criação de perfil
Ao usar o Platform Tools 29.0.3, a depuração nativa e os Criadores de perfil do
Android Studio podem não funcionar corretamente, e talvez você veja a mensagem
"AdbCommandRejectedException" ou "Falha ao conectar porta" no arquivo idea.log
ao selecionar Help > Show Log. A atualização do Platform Tools para
29.0.4 ou uma versão mais recente corrige os dois problemas.
Para fazer upgrade do Platform Tools, faça o seguinte:
- Abra o SDK Manager no Android Studio clicando em Tools >
SDK Manager ou em SDK Manager
na barra de ferramentas.
- Clique na caixa de seleção ao lado de Android SDK
Platform-Tools para mostrar uma marca de seleção. Um ícone de download
aparecerá na coluna da esquerda.
- Clique em Apply ou OK.
Problemas conhecidos com o Plug-in do Android para Gradle
Esta seção descreve problemas conhecidos que existem na versão estável mais recente do Plug-in do Android para Gradle.
Classe do manifesto ausente
Se o app definir permissões personalizadas no manifesto, o Plug-in
do Android para Gradle normalmente gerará uma classe Manifest.java
que incluirá suas permissões
personalizadas como constantes de string. O plug-in empacota essa classe com seu app
para que você possa referenciar essas permissões com mais facilidade no momento da execução.
A geração da classe de manifesto está corrompida no Plug-in
do Android para Gradle 3.6.0 e em versões mais recentes. Se você criar seu app com essa versão do plug-in
e referenciar a classe de manifesto, talvez veja uma exceção
ClassNotFoundException
. Para resolver esse problema, faça uma das seguintes ações:
- Faça referência a suas permissões personalizadas pelo nome totalmente qualificado. Por exemplo,
"com.example.myapp.permission.DEADLY_ACTIVITY"
. Defina suas próprias constantes, conforme mostrado abaixo:
public final class CustomPermissions { public static final class permission { public static final String DEADLY_ACTIVITY="com.example.myapp.permission.DEADLY_ACTIVITY"; }
Assinatura de arquivos nomeados com caracteres de retorno de carro (CR, na sigla em inglês)
A assinatura de JARs (esquema v1) não é compatível com nomes de arquivos que contenham caracteres de retorno de carro (CR, na sigla em inglês). Consulte o problema 63885809.
Mudanças na API
O Plug-in do Android para Gradle 3.0.0 e versões mais recentes introduz mudanças na API que removem funcionalidades específicas e podem invalidar builds já existentes. Versões mais recentes do plug-in podem apresentar novas APIs públicas que substituem funcionalidades inválidas.
A modificação de saídas de variantes no momento da compilação pode não funcionar
O uso da API Variant para manipular saídas de variantes é invalidado com o novo plug-in. Ela ainda funciona para tarefas simples, como mudar o nome do APK durante o tempo de compilação, conforme mostrado abaixo:
// 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" } }
Entretanto, tarefas mais complicadas que envolvem o acesso a objetos outputFile
não funcionam mais. Isso ocorre porque tarefas específicas de variantes não são mais criadas
durante a fase de configuração. Assim, o plug-in não conhece
todas as saídas imediatamente, mas também gera tempos de configuração mais rápidos.
manifestOutputFile não está mais disponível
O método processManifest.manifestOutputFile()
não está mais
disponível, e você receberá o seguinte erro se chamá-lo:
A problem occurred configuring project ':myapp'. Could not get unknown property 'manifestOutputFile' for task ':myapp:processDebugManifest' of type com.android.build.gradle.tasks.ProcessManifest.
Em vez de chamar manifestOutputFile()
para conseguir o arquivo de manifesto para cada
variante, chame processManifest.manifestOutputDirectory()
para retornar o
caminho do diretório que contém todos os manifestos gerados. Em seguida, você pode
localizar um manifesto e aplicar sua lógica a ele. A amostra abaixo muda o código de versão
dinamicamente no manifesto:
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) } } }
Problemas conhecidos corrigidos
Esta seção descreve problemas conhecidos que foram corrigidos em uma versão recente. Se algum deles estiver ocorrendo, atualize o Android Studio para a versão estável ou de pré-lançamento mais recente.
Corrigidos no Android Studio 4.1
- Reinicialização para aplicar as configurações de memória da versão anterior do ambiente de desenvolvimento integrado: depois da atualização, é necessário reiniciar o Android Studio para aplicar as configurações de memória migradas de uma versão anterior do ambiente de desenvolvimento integrado.
Corrigidos no Android Studio 3.6
Erro de instalação do APK no LineageOS: a implantação do app em dispositivos com certas versões do LineageOS ou do CyanogenMod pode falhar e gerar uma exceção
INSTALL_PARSE_FAILED_NOT_APK
.No Android Studio 3.6 Beta 1 e em versões mais recentes, o ambiente de desenvolvimento integrado processa essa exceção com uma instalação completa do app quando você o implanta em dispositivos LineageOS ou CyanogenMod, o que pode resultar em tempos de implantação maiores.
Problemas corrigidos no Android Studio 3.5.2
- Estilo de código XML corrompido: durante a edição de código XML, o ambiente de desenvolvimento integrado aplicava um estilo de código incorreto quando você selecionava Code > Reformat Code na barra de menus.
Corrigidos no Android Studio 3.3.1
Erros de falta de memória ao verificar projetos baseados em C++: quando o Gradle verifica um projeto que tem código C++ em mais de um local na mesma unidade, a verificação inclui todos os diretórios abaixo do primeiro diretório comum. A verificação de um grande número de diretórios e arquivos pode causar erros de falta de memória.
Para ver mais informações sobre esse problema, consulte o bug associado a ele.