Problemas conhecidos com o Android Studio e o Android Gradle Plugin

Esta página monitora problemas atuais conhecidos com o Android Studio e o Android Gradle Plugin. Para relatar um problema que ainda não está incluído aqui, consulte Denunciar um erro.

Problemas conhecidos com o Android Studio

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

    Se seu projeto apresentar esse comportamento, recomendamos o uso do Android Studio 3.2. Para ver mais informações sobre esse problema, leia o bug (link em inglês) associado ao problema.

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

    Se você estiver usando o Android Studio 3.1 ou versões anteriores, poderá solucionar esse problema definindo uma dependência em uma versão de espresso-core anterior a 3.0.2 ou adicionando uma dependência de rules separada, conforme mostrado nas instruções de configuração do Espresso.

  • A verificação de lint @RestrictTo não funciona com máquinas Windows: no Android Studio 2.3, a verificação de lint @RestrictTo não aciona corretamente mensagens de erro em máquinas Windows.

  • Dispositivos virtuais com parênteses nos respectivos nomes não serão executados: no Android Studio versão 2.2, embora seja possível incluir parênteses no nome de um dispositivo virtual (e, de fato, alguns dispositivos, como o Android TV, incluem parênteses nos respectivos nomes automaticamente), não é possível executar um dispositivo virtual que use parênteses no nome. Para evitar esse problema, edite o dispositivo virtual para remover todos os caracteres "(" e ")" do nome.

    Esse problema foi resolvido a partir do Android Studio 2.3

  • O Instant Run não é compatível com o Jack: no momento, o Instant Run não é compatível com o compilador Jack. Por isso, ele fica desativado para projetos que usam o compilador Jack. O uso do compilador Jack é necessário somente ao usar recursos de linguagem do Java 8.

  • Ferramentas e bibliotecas que exigem os arquivos de classe do app não são compatíveis com o Jack: várias ferramentas que leem arquivos .class (como JaCoCo, Mockito e algumas verificações de lint) não são compatíveis com o compilador Jack.

  • A compilação do Gradle não pode limpar pastas de saída quando o projeto está em NTFS no Linux: devido ao comportamento de bloqueio de arquivos NTFS, em máquinas Windows, o Android Studio copia automaticamente os arquivos JAR das classes para outro local antes da indexação para que as compilações subsequentes do Gradle possam limpar e fazer alterações na compilação/árvore. Consulte o problema 202297 (link em inglês) para ver mais informações. Esse comportamento não ocorre com o uso do NTFS em máquinas Linux ou OSX, mas pode ser especificado manualmente no seu arquivo idea.properties, removendo a marca de comentário da seguinte linha:

    idea.jars.nocopy=false

  • Desempenho do Mac: o pacote OpenJDK 1.8.0_76 fornecido com o Studio 2.2 apresenta alguns problemas no Mac. O uso de um monitor 4K externo com uma resolução dimensionada pode afetar negativamente o desempenho de renderização, conforme discutido no problema 203412 e no IDEA-144261 (links em inglês), até que o ambiente de desenvolvimento integrado pare de responder. Além disso, conforme relatado no problema 223749 e no IDEA-158500 (links em inglês), a rolagem é muito sensível no Mac 10.12 (Sierra).

  • Falha na sincronização do Gradle: encadeamento corrompido: o problema é que o daemon do 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 do 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
  • O JUnit testa os recursos ausentes no caminho de classe quando executado 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.

  • Linux e Awesome WM 3.4: as versões 0.8.3 e posteriores do Android Studio podem não funcionar corretamente com o gerenciador de janelas “Awesome WM” versão 3.4. Para resolver esse problema, atualize para o Awesome WM versão 3.5.

  • Entrada de teclado congelada - Problemas "iBus" no Linux: existem 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 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.
  • Ubuntu e JAyatana: o JAyatana permite que aplicativos Java Swing se integrem ao menu global no shell gráfico Unity do Ubuntu. Em alguns casos, o Android Studio pode encontrar um NullPointerException em Unity, com uma mensagem de erro como:

    java.lang.NullPointerException
        at com.jarego.jayatana.swing.SwingGlobalMenu.getSwingGlobalMenuWindowController(SwingGlobalMenu.java:204)
        at com.jarego.jayatana.swing.SwingGlobalMenu.installLockParentGlobalMenu(SwingGlobalMenu.java:160)
        at ...
    Para saber mais, consulte o problema 187179 (link em inglês). Devido a esse problema, versões mais recentes do Ubuntu estão desativando o JAyatana por padrão (link em inglês). Se você encontrar esse problema, há duas soluções possíveis (consulte esta postagem em inglês do Stack Overflow para ver mais informações):

    • Solução alternativa 1: cancele a configuração da variável de ambiente JAVA_TOOL_OPTIONS ao executar o Android Studio.
    • Solução alternativa 2: desinstale o JAyatana.
  • Como adicionar 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 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).

  • Como 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 você 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 retomá-lo. Para saber mais, consulte o problema 224385 (link em inglês).

  • Exceção falsa de renderização: a mensagem de erro específica de renderização é "Não foi possível encontrar as seguintes classes: - android.support.v7.internal.app.WindowDecorActionBar". Apesar da mensagem de erro, a visualização do layout está correta, e a mensagem pode ser ignorada com segurança.

    Esse problema foi corrigido a partir da visualização do Android Studio 2.0.

  • 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 de 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, acesse 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).

Problemas conhecidos com o Android Gradle Plugin

  • Configuração sob demanda com Gradle 4.6 e versões posteriores: se você usa o Android Gradle Plugin 3.0.x ou 3.1.x com Gradle 4.6 e versões posteriores, desative a configuração sob demanda para evitar alguns erros imprevisíveis de compilação. Se você estiver usando o Android Gradle Plugin 3.2.0 ou versão posterior, não será necessário executar nenhuma ação para desativar a configuração sob demanda.

    Desabilite a configuração sob demanda no seu arquivo gradle.properties, como mostrado abaixo:

    org.gradle.configureondemand=false
        

    Para desativar a configuração sob demanda nas configurações do Android Studio, selecione File > Settings (Android Studio > Preferences no Mac), selecione a categoria Compiler no painel esquerdo e desmarque a caixa de seleção Configure on demand.

    No Android Studio 3.2 Beta 1 e versões posteriores, as opções para ativar a configuração sob demanda foram removidas.

  • Erro de sincronização do projeto ao carregar o plug-in do Android 3.0.0 várias vezes: carregar o plug-in do Android várias vezes em uma única compilação leva a um erro de sincronização do projeto. Isso pode ocorrer quando você tem vários subprojetos, e cada um deles inclui o plug-in do Android no caminho de classe de buildscript. Essa é uma limitação do novo gerenciamento de dependências com variantes do Gradle, que ainda não consegue processar a correspondência de atributos de carregadores de classe diferentes. Se você estiver usando o plug-in do Android 3.0.0 ou versões anteriores, faça upgrade para o plug-in do Android 3.1.0 ou versões posteriores ou siga as etapas abaixo para resolver o problema:

    • Compilações de vários módulos: adicione o plug-in do Android somente ao caminho de classe de compilação do seu arquivo build.gradle de nível superior, conforme mostrado abaixo:

      // Additionally, make sure that you don't wrap this in a
          // subprojects block.
          buildscript {
              ...
              dependencies {
                  classpath 'com.android.tools.build:gradle:3.4.2'
              }
          }
          
    • Compilações compostas: verifique se, para o projeto principal e para cada projeto incluído que usa o plug-in do Android, os caminhos de classe de buildscript são idênticos. Isso também exige que a ordem dos caminhos de classe adicionados ao bloco buildscript seja idêntica. Por exemplo, considere as seguintes dependências de caminho de classe incluídas no arquivo build.gradle do projeto principal:

      buildscript {
              ...
              dependencies {
                  classpath "com.android.tools.build:gradle:3.4.2"
                  classpath "me.tatarka:gradle-retrolambda:3.7.0"
              }
          }
          

      Agora, considere o seguinte arquivo build.gradle para outro projeto incluído na compilação composta:

      buildscript {
              dependencies {
                  // Note that the order of plugins differs from that
                  // of the main project's build.gradle file. This results
                  // in a build error because Gradle registers this as a
                  // different classloader.
                  classpath "me.tatarka:gradle-retrolambda:3.7.0"
                  classpath "com.android.tools.build:gradle:3.4.2"
              }
          }
          
  • Incompatibilidade no erro de dependências do Guava com o plug-in do Firebase versão 1.1.0: o plug-in do Firebase versão 1.1.0 pode causar uma incompatibilidade nas dependências do Guava, resultando no seguinte erro:

        Error:Execution failed for task ':app:packageInstantRunResourcesDebug'.
        com.google.common.util.concurrent.MoreExecutors.directExecutor()Ljava/util/concurrent/Executor;
        
    Para contornar esse erro de compilação, inclua o seguinte no bloco dependencies do arquivo build.gradle do projeto:

    dependencies {
            classpath ('com.google.firebase:firebase-plugins:1.1.0') {
                        exclude group: 'com.google.guava', module: 'guava-jdk5'
            }
            ...
        }
        

    Para saber mais, consulte o problema 63180002 (link em inglês).

  • Para usar Protobufs, faça upgrade do plug-in do Protobuf para a versão 0.8.2 ou posteriores.

  • Não há mais compatibilidade com o plug-in android-apt de terceiros. Alterne para a compatibilidade com o processador de anotações incorporado, que foi aprimorado para resolver dependências lentamente.

  • 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)
            }
        }
    }