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

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:

1. Selecione File > Settings (ou Android Studio > Preferences no macOS).
2. Na parte esquerda da janela, navegue até Appearance & Behavior > Menus and Toolbars.
3. Na parte direita da janela, navegue até Main Toolbar > Toolbar Run Actions e selecione Run/Debug.
4. Perto da parte superior da janela, clique em Revert e selecione Restore Run/Debug.
5. 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:

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 (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, 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 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:

1. Primeiro, tente instalar a versão mais recente do HAXM pelo 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 (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).

Observação: esse problema foi corrigido no Android Studio 4.1.1 e em versões mais recentes. Se o Android Studio estiver configurado para receber atualizações no Canal estável, você poderá receber a versão mais recente selecionando Help > Check for Updates (Android Studio > Check for Updates no macOS). Caso contrário, você poderá fazer o download dele na página do Android Studio.

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

Observação: esse problema foi corrigido no Android Studio 4.2 Canary 10 e em versões mais recentes. Se o Android Studio estiver configurado para receber atualizações nos Canais Canary ou de Desenvolvedor, você poderá receber a versão mais recente selecionando Help > Check for Updates (Android Studio > Check for Updates no MacOS). Caso contrário, faça o download dela na página Versão de pré-lançamento do Android 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 um android: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.

Observação: esse problema (135172147) 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 de Desenvolvedor, você poderá receber a versão mais recente selecionando Help > Check for Updates (Android Studio > Check for Updates no macOS). 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.

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.

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íficos) 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 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:

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.

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.