Problemas conhecidos do Android Studio e do Plug-in do Android para Gradle

Esta página monitora problemas conhecidos com o Android Studio 3.6 e o Plug-in do Android para Gradle 3.6.0. Se você tiver um problema que ainda não esteja 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 e acrescenta 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 instale-a.

Problemas conhecidos com o Android Studio

Esta seção descreve problemas conhecidos que existem na versão estável mais recente do Android Studio.

Erros de controle de versão do Git no ambiente de desenvolvimento integrado

As operações que exigem autenticação no controle de versão do Git são interrompidas no ambiente de desenvolvimento integrado do Android Studio 3.6.

Para corrigir esse problema, faça upgrade para o Android Studio 3.6.1.

Conflitos de mapeamento de atalhos no Linux

No Linux, determinados atalhos de teclado entram em conflito com os atalhos de teclado padrão do Linux e os gerenciadores de janelas conhecidos, como o KDE e o 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.

Texto pequeno da IU no 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:

1. Abra a janela Configurações clicando em Arquivo > Configurações
2. Navegue até Aparência e Comportamento > Aparência.
3. Selecione Use custom font.
4. Aumente o tamanho da fonte.
5. Na janela Settings, navegue até Editor > Font.
6. Aumente o tamanho da fonte.
7. 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 e ao iBus (links em inglês). 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 desabilitar 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 quaisquer outros aplicativos que você possa estar executando. Observe que, se você reiniciar o daemon enquanto o Android Studio estiver em execução (por exemplo, executando ibus-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 uma falha de segmentação.
• Solução alternativa 3: verifique as vinculações de atalho para garantir que o Next input shortcut não esteja definido como Control+Space (Ctrl+Espaço), porque 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 verificar suas vinculações de atalhos, execute ibus-setup na linha de comando para abrir a janela IBus Preferences. Em Keyboard Shortcuts, verifique o Next input method. Se ele estiver definido como Control+Space, mude para Super+Space ou outro atalho da sua escolha.

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 em ~/.profile ou ~/.bash_profile:

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

• Solução alternativa 2: no arquivo vmoptions (link em inglês) do Android Studio, mude a linha -Djava.net.preferIPv6Addresses=true para -Djava.net.preferIPv6Addresses=true. Para saber mais, consulte o Guia do usuário de rede IPv6 (link em inglês).

Erros "par não autenticado" da sincronização do Gradle ou SDK Manager

A causa raiz 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 por meio do proxy talvez seja necessário usar keytool para adicionar o certificado do servidor proxy ao arquivo cacerts.
• Reinstale um JDK não modificado e compatível. Há um problema conhecido (link em inglês) que afeta os usuários do Ubuntu, resultando em um arquivo /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.

Android Emulator HAXM no macOS High Sierra

O Android Emulator no macOS High Sierra (10.13) requer o HAXM 6.2.1 ou mais recentes para melhor compatibilidade e estabilidade com o macOS. No entanto, o macOS 10.13 tem um processo mais envolvido para instalar extensões do kernel, como o HAXM. Você precisa permitir manualmente que a extensão do kernel seja instalada da seguinte maneira:

1. Primeiro, tente instalar a versão mais recente do HAXM no SDK Manager.
2. No MacOS, vá para Preferências do sistema > Segurança e privacidade.

3. 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 e o problema 62395878 (links em inglês).

Aplicar mudanças

Esta seção descreve problemas conhecidos relacionados à ação Apply Changes (Aplicar mudanças).

Problema no Android Runtime gera erro

Se você estiver usando um dispositivo com Android 8.0 ou 8.1, poderá encontrar mensagens "VERIFICATION_ERROR" ao tentar aplicar alguns tipos de alterações (principalmente se estiver usando o Kotlin). Essa mensagem é causada por um problema no Android Runtime que foi corrigido no Android 9.0 e versões posteriores. Embora o problema faça com que "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.

Não é possível aplicar as mudanças ao usar android:sharedUserId

Se você tentar fazer modificações em uma classe que ainda não tenha sido implantada no app em execução, a opção "Apply Changes" falhará se o app estiver 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 um android:process compartilhados.

Quando "Apply Changes" falha devido a esse problema, o Android Studio exibe a seguinte mensagem:

Changes were not applied. JVMTI error: UNKNOWN_JVMTI_ERROR
    

Para resolver esse problema no Android Studio 3.5, clique em Run para implantar novamente seu app e ver as alterações.

Observação: esse problema (135172147, link em inglês) foi corrigido no Android Studio 3.6 Canary 6 e em versões mais recentes. Se o Android Studio estiver configurado para receber atualizações nos canais Canary ou Dev, você poderá receber a versão mais recente selecionando Help > Check for Updates (no macOS, Android Studio > Check for Updates). Caso contrário, você poderá fazer o download dele na página Versão de pré-lançamento do Android Studio.

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 (link em inglês).

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 versão, mas o Gradle não copia por cima desses recursos.

• Solução alternativa 1: execute a tarefa check do Gradle no 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 versão. Consulte o comentário 13 (link em inglês) 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 da inicialização": 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 altere a configuração padrão de JUnit para incluir apenas a etapa Gradle-aware Make.
• Para corrigir o problema de 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 quando se clica com o botão direito do mouse em um método de teste são válidas. Especificamente, as seguintes configurações não são válidas:

• 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.

O Android Studio também se lembra da configuração de execução criada em um determinado contexto (por exemplo, clicar com o botão direito do mouse em uma classe ou um método específico) e não oferecerá a execução em uma configuração diferente no futuro. Para corrigir isso, clique em Run > Edit Configurations e remova as configurações criadas incorretamente.

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 definidos por você. 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 saber mais, consulte o problema 229949 (link em inglês).

Sair do depurador nativo

Ao usar os depuradores Auto ou Dual para depurar um código nativo e Java, se você entrar em uma função nativa a partir do 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 para ele, clique em Resume Program, em vez de em Step Out ou Step Over . O processo do seu app ainda estará pausado, então clique em Resume Program na guia your-module-java para retomá-lo. Para saber mais, consulte o problema 224385 (link em inglês).

Criadores de perfil

Esta seção descreve problemas conhecidos com o Criadores de perfil.

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 você poderá encontrar a mensagem “AdbCommandRejectedException” ou “Falha ao conectar porta” no arquivo idea.log quando 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:

1. Abra o SDK Manager no Android Studio clicando em Tools > SDK Manager ou em SDK Manager na barra de ferramentas.
2. 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.
3. 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.

Falta a classe do manifesto

Se seu app definir permissões personalizadas no manifesto, o Plug-in Android para Gradle normalmente gerará uma classe Manifest.java que inclui 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 tempo de execução.

A geração da classe de manifesto está corrompida no Plug-in do Android para Gradle 3.6.0 e versões posteriores. Se você criar seu app com essa versão do plug-in e fizer referência à classe de manifesto, talvez veja uma exceção ClassNotFoundException. Para resolver esse problema, execute 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)

A assinatura de JARs (esquema v1) não permite nomes de arquivos que contenham caracteres de retorno de carro (CR, na sigla em inglês). Consulte o problema 63885809 (link em inglês).

Mudanças na API

O Android Gradle Plugin versão 3.0.0 e posteriores introduz alterações na API que removem certas funcionalidades e podem quebrar as compilações já existentes. Versões posteriores do plug-in podem introduzir novas APIs públicas que substituem funcionalidades inválidas.

A modificação de saídas de variantes em tempo de 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. Isso faz com que o plug-in não conheça todas as suas 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, você pode chamar processManifest.manifestOutputDirectory() para retornar o caminho do diretório que contém todos os manifestos gerados. Então, você pode localizar um manifesto e aplicar sua lógica a ele. O exemplo abaixo altera o código de versão dinamicamente no manifest:

    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 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 mais longos.

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 pode aplicar um estilo de código incorreto quando você seleciona 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, leia o bug (link em inglês) associado ao problema.