Esta página monitora problemas conhecidos com Android Studio. Plug-in do Koala e do Android para Gradle 8.5.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 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 O Layout Inspector 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:
Essa solução desativa apenas métodos de entrada para o Android Studio, não qualquer outro aplicativo que você esteja executando. Se você reiniciar o daemon enquanto o Android Studio está em execução (por exemplo, ao executar$ XMODIFIERS= ./bin/studio.sh
ibus-daemon -rd
), você desativa os métodos de entrada para todos outros aplicativos e também pode causar uma falha na JVM do Android Studio com um falha 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.
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 criador de perfil de linha de comando autônomo do Perfetto (em inglês). 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.