Esta página foi traduzida pela API Cloud Translation.

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

Esta página monitora problemas conhecidos com o Android Studio Ladybug e o Plug-in do Android para Gradle 8.7.0. 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 busca melhorar a estabilidade e a performance, 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.

A opção "Aplicar alterações e reiniciar a atividade" não reinicia a atividade em dispositivos ou emuladores com a API de nível 35.

Quando você implanta mudanças de código em um dispositivo com a API 35 usando "Apply Changes & Restart Activity", o app não é reiniciado e você não vai notar o efeito das mudanças. Se você executar o aplicativo novamente, vai notar o efeito das mudanças no código. Nossa equipe está investigando o caso.

A janela do Firebase Assistente mostra uma mensagem de erro

Se a janela do Firebase Assistente (no menu principal, Tools > Firebase) mostrar uma mensagem de erro, invalide os caches e reinicie o Android Studio para corrigir o erro.

Não é possível isolar uma visualização usando o Layout Inspector

A capacidade de isolar uma visualização usando o Layout Inspector incorporado está temporariamente indisponível. Estamos trabalhando para corrigir esse problema em uma versão futura.

Não é possível inspecionar todos os nós do Compose usando o Layout Inspector

Se você perceber que nem todos os nós do Compose podem ser inspecionados ao usar o Layout Inspector, provavelmente isso se deve a um bug corrigido na versão 1.5.0-alpha04 do Compose. Caso você tenha esse problema, faça upgrade para a versão 1.5.0-alpha04 ou mais recente do Compose.

Erro ao renderizar a visualização do Compose

No Android Studio Chipmunk e versões mais recentes, se você encontrar java.lang.NoSuchFieldError: view_tree_saved_state_registry_owner ou java.lang.ClassNotFoundException: androidx.savedstate.R$id no painel de problemas, inclua uma dependência debugImplementation para androidx.lifecycle:lifecycle-viewmodel-savedstate no módulo.

Se você encontrar java.lang.NoSuchFieldError: view_tree_lifecycle_owner no painel de problemas, inclua uma dependência debugImplementation para androidx.lifecycle:lifecycle-runtime no módulo.

Se você encontrar java.lang.NoClassDefFoundError: Could not initialize class androidx.customview.poolingcontainer.PoolingContainer ou java.lang.NoClassDefFoundError: androidx/customview/poolingcontainer/PoolingContainerListener no painel de problemas, inclua uma dependência debugImplementation para androidx.customview:customview-poolingcontainer no módulo.

Erro ao usar senhas diferentes para a chave e o keystore

A partir da versão 4.2, o Android Studio é executado no JDK 11. Essa atualização causa uma mudança de comportamento subjacente relacionada às chaves de assinatura.

Ao acessar Build > Generate Signed Bundle / APK e tentar configurar a assinatura de apps para um pacote de apps ou um APK, a inserção de senhas diferentes para a chave e o keystore pode gerar este erro:

Key was created with errors:
Warning: Different store and Key passwords not supported for PKCS12 Key stores

Para contornar esse problema, insira a mesma senha para a chave e o keystore.

O Android Studio não inicia após a instalação da versão 4.2

O Studio tenta importar .vmoptions anteriores e limpá-los para serem compatíveis com o coletor de lixo usado pelo JDK 11. Se esse processo falha, o ambiente de desenvolvimento integrado talvez não inicie para determinados usuários que definiram opções de VM personalizadas no arquivo .vmoptions.

Para contornar esse problema, recomendamos que você comente opções personalizadas em .vmoptions (usando o caractere "#"). O arquivo .vmoptions pode ser encontrado nos seguintes locais:

Windows

C:\Users\YourUserName\AppData\[Local|Roaming]\Google\AndroidStudio4.2\studio64.exe.vmoptions

macOS

~/Library/Application Support/Google/AndroidStudio4.2/studio.vmoptions

Linux

~/.config/Google/AndroidStudio4.2/studio64.vmoptions

Se o Studio ainda não iniciar depois dessa solução alternativa, consulte O Studio não inicia após o upgrade abaixo.

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 Canary do Android Studio 4.1 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. Fazer upgrade do plug-in do Kotlin para a versão 1.4 vai resolver esse problema.

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 da interface 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:

Abra a janela Settings clicando em File > Settings.
Navegue até Appearance & Behavior > Appearance.
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 (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ê vai 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.preferIPv4Addresses=true para -Djava.net.preferIPv6Addresses=true. Para 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 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 pelo proxy talvez seja necessário usar keytool para adicionar o certificado do servidor proxy ao arquivo cacerts.
Reinstale um JDK com suporte 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.

[Somente Mac OS] Atualizações incrementais não são aplicadas devido a um problema com o arquivo Gradle que monitora projetos salvos em `/System/Volumes/Data`

O problema 18149 do Gradle (link em inglês) afeta o Plug-in do Android para Gradle 7.0 e versões mais recentes porque ele exige o Gradle versão 7.0 ou mais recente. A partir do Gradle 7.0, o monitoramento de arquivos é ativado por padrão. Se você estiver trabalhando no Mac OS e seu projeto estiver salvo em /System/Volumes/Data, a observação de arquivos do Gradle não vai monitorar corretamente as mudanças dos arquivos. O sistema de build não vai detectar mudanças de arquivo e, portanto, não vai atualizar os APKs. O código de implantação incremental não vai fazer nada porque o estado do APK local será igual ao do dispositivo.

Para contornar esse problema, mova o diretório do seu projeto para o diretório de usuários, ou seja, para /Users/username. O sistema de build vai ser notificado corretamente sobre mudanças no arquivo pela observação de arquivos do Gradle. As mudanças incrementais serão aplicadas.

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 mais informações e soluções alternativas, consulte esta página da Apple (link em inglês) e o problema 62395878.

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.

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 do Make com reconhecimento do Gradle.
Para corrigir o problema para todos os projetos futuros, clique em File > Close Project. A tela inicial será mostrada. Em seguida, clique em Configure > Project Defaults > Run Configurations e mude a configuração do JUnit para incluir apenas a etapa do Make com reconhecimento do Gradle.

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 saber mais, consulte o problema 224385.

O depurador nativo trava ao carregar bibliotecas

Ao usar o depurador nativo pela primeira vez após o upgrade para o Android Studio 4.2 e versões mais recentes, o depurador nativo pode parar de responder ao carregar bibliotecas do dispositivo Android. Esse é um problema recorrente que continua a acontecer mesmo que você pare e reinicie o depurador. Para corrigir esse problema, exclua o cache do LLDB em $USER/.lldb/module-cache/.

O depurador nativo falha com "Debugger process finished with exit code 127" (O processo do depurador terminou com o código de saída 127)

Esse erro ocorre em plataformas baseadas em Linux ao iniciar o depurador nativo. Isso indica que uma das bibliotecas exigidas pelo depurador nativo não está instalada no sistema local. Talvez o nome da biblioteca ausente já esteja gravado no arquivo idea.log. Caso contrário, você pode usar um terminal para navegar até o diretório de instalação do Android Studio e executar a linha de comando bin/lldb/bin/LLDBFrontend --version para saber quais bibliotecas estão faltando. Normalmente, a biblioteca que falta é ncurses5 porque algumas distribuições recentes do Linux já foram atualizadas para ncurses6.

Criadores de perfil

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

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, principalmente 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.

O plug-in impede o funcionamento da janela de saída de build

Usar o plug-in CMake Simple Highlighter (link em inglês) impede que o conteúdo apareça na janela "Build Output". O build é executado, e a guia "Build Output" aparece, mas nenhuma saída é mostrada (problema 204791544).

O pedido de instalação impede a inicialização

A instalação de uma versão mais recente do Android Studio antes de uma mais antiga pode impedir que a versão mais antiga seja iniciada. Por exemplo, se você primeiro instalar a versão Canary do Android Studio e, em seguida, tentar instalar e iniciar a versão estável, talvez a versão estável não seja iniciada. Nesses casos, é necessário limpar o cache para iniciar a versão estável (mais antiga). No macOS, para limpar o cache, exclua o diretório Library/ApplicationSupport/Google/AndroidStudioversion_number. No Windows, para limpar o cache, use a Limpeza de disco (link em inglês).

O Espresso Test Recorder não funciona com o Compose

O Espresso Test Recorder não funciona com projetos que incluem o Compose. Para criar testes de interface em projetos que incluem o Compose, consulte Testar o layout do Compose.

Conflitos de atalho do Logcat com layouts de teclado diferentes do inglês

Se você estiver usando um layout de teclado diferente do inglês, um atalho de teclado padrão do Logcat poderá entrar em conflito com o layout e impedir que você digite certos caracteres ao editar texto no Android Studio. Para contornar esse problema, exclua ou mapeie novamente o mapa de teclado conflitante do Logcat. Para editar os atalhos de teclado do Logcat no Android Studio, acesse Android Studio > Settings > Keymap e pesquise Logcat na lista de mapas de teclado. Para saber mais, consulte o problema 263475910.

Esse problema será resolvido com a remoção do atalho do Logcat no Android Studio Electric Eel Patch 1.

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.

Nem todas as dependências da biblioteca de recursos dinâmicos são verificadas no lint

Ao executar o lint com checkDependencies = true em um módulo de app, as dependências da biblioteca de recursos dinâmicos não são verificadas, a menos que também sejam dependências de apps (problema 191977888). Como alternativa, a tarefa do lint pode ser executada nessas bibliotecas.

Assinatura de arquivos nomeados com caracteres de retorno de carro

A assinatura JAR (esquema v1) não oferece suporte a nomes de arquivos que contêm caracteres de retorno de carro (problema 63885809).

A modificação de saídas de variantes no tempo de build 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ê vai receber o seguinte erro se o chamar:

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. O exemplo 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 com suporte à AIDL no AGP 7.3.0 e Kotlin 1.7.x

O uso do AGP 7.3.0 com KAPT no Kotlin 1.7.x faz com que os conjuntos de origem AIDL para variantes de build específicas sejam removidos. Ainda é possível usar os outros conjuntos de origem AIDL, incluindo os de main/, tipos de build, variações de produto e combinações de variações de produto. Se você precisar usar os conjuntos de origem AIDL específicos da variante, continue a usar o Kotlin 1.6.21.

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 2021.1.1

Saída do lint ausente: nenhuma saída de texto do lint é mostrada em stdout quando a tarefa do lint está UP-TO-DATE (atualizada) (problema 191897708). Corrigido no AGP 7.1.0-alpha05.
Problemas com testes de unidade de um projeto de app que usa o plug-in do Hilt: o caminho de classe do teste de unidade contém as classes de apps não instrumentadas. Isso significa que o Hilt não instrumenta as classes do app para processar a injeção da dependência ao executar testes de unidade (problema 213534628). Corrigido no AGP 7.1.1.

Corrigidos no Android Studio 2020.3.1

Exceções de lint em projetos Kotlin: os projetos Kotlin que definem checkDependencies = true podem encontrar exceções ou erros de ponteiro nulo (problema 158777858).

Corrigidos no Android Studio 4.2

O ambiente de desenvolvimento integrado congela no macOS Big Sur: o Android Studio 4.1 pode congelar quando você abrir uma caixa de diálogo.

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.
A classe do manifesto com strings de permissão personalizadas não é mais gerada por padrão: se você quiser gerar a classe, defina android.generateManifestClass = true.

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.