Problemas conhecidos com o Android Studio e o plug-in do Android para Gradle

Esta página monitora problemas conhecidos com o Android Studio 3.5 e o plug-in do Android para Gradle 3.5.0. Se você tiver um problema que ainda não esteja incluído aqui, informe um bug.

Faça upgrade para visualizar: 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.

Edição de código

Esta seção descreve problemas conhecidos relacionados ao editor de código.

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. Para corrigir esse problema, redefina para o estilo de código Android adequado, da seguinte maneira:

  1. Abra a janela Settings clicando em File > Settings (no Mac, Android Studio > Preferences).
  2. No painel esquerdo, clique em Editor > Code Style > XML.
  3. Perto do canto superior direito do painel à direita, selecione Set from > Predefined Style > Android.
  4. Clique em OK.

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á efetivamente os métodos de entrada para todos os outros aplicativos e também 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 (atalho da entrada "Próxima") 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 Preferências do IBus. 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, altere 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 (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, proceda da seguinte maneira:

  • Se você estiver protegido por 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, o que resulta 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+ 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 própria 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 alterações

Esta seção descreve problemas conhecidos relacionados à ação de Aplicar alterações.

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 "Aplicar alterações" falhe, você ainda pode executar Ícone de execução seu aplicativo novamente para ver suas alterações. No entanto, recomendamos que você faça upgrade do dispositivo para o Android 9.0 ou versão posterior.

Não é possível aplicar alterações ao usar android:sharedUserId

Se você tentar fazer alterações em uma classe que ainda não tenha sido implantada no aplicativo em execução, a opção "Apply Changes" (aplicar alterações) falhará se o app estiver configurado de uma das seguintes maneiras:

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 Ícone de execução para implantar novamente seu aplicativo e ver suas alterações.

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 construtor do IntelliJ copia todos os recursos para essa pasta de compilaçã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 executar um teste de unidade.
  • Solução alternativa 2: atualize seu script de compilação para copiar recursos manualmente para a pasta de compilaçã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 altere a configuração da 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.
  • 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 em uma classe ou 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 o depurador 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 ao código Java, clique em Resume Program , em vez de em Step Out ou Step Over . O processamento do seu app ainda será pausado. Clique em Resume Program na guia seu-módulo-java para continuar. Para saber mais, consulte o problema 224385 (link em inglês).

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.

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 alterar 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ê recebe o seguinte erro quando o chama:

    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 manifest 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 manifest 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 desses problemas estiver ocorrendo, atualize o Android Studio para a versão estável ou de pré-lançamento mais recente.

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.

Corrigidos no Android Studio 3.2

  • Falha de compilação do Espresso Test Recorder: a compilação falha com a mensagem Execution failed for task ':app:compileDebugAndroidTestJavaWithJavac' quando você tenta criar um projeto que usa o Espresso Test Recorder. Esse problema afeta versões do Android Studio anteriores a 3.2 que usam a versão 3.0.2 ou posterior da dependência do espresso-core. Esse problema não afeta o Android Studio 3.2 e versões posteriores.