O sistema de compilação do Android Studio é baseado no Gradle, e o Plug-in do Android para Gradle adiciona vários recursos específicos para a criação de apps Android. Embora o plug-in do Android normalmente seja atualizado no Android Studio, o plug-in e o resto do sistema do Gradle podem ser executados e atualizados de forma independente do Android Studio.
Esta página explica como manter suas ferramentas do Gradle atualizadas e quais são as atualizações recentes.
Para ver um resumo detalhado das próximas alterações interruptivas no Plug-in do Android para Gradle, consulte o cronograma do plug-in.
Para saber como configurar seus builds do Android com o Gradle, consulte as seguintes páginas:
- Configurar seu build
- Referência de DSL do plug-in do Android
- Referência de DSL do Gradle (em inglês)
Para mais informações sobre o sistema de compilação do Gradle, consulte o Guia do usuário do Gradle (em inglês).
Atualizar o Plug-in do Android para Gradle
Ao atualizar o Android Studio, talvez seja solicitado que você atualize automaticamente o Plug-in do Android para Gradle para a versão mais recente disponível. Você pode aceitar a atualização ou especificar manualmente uma versão com base nos requisitos de build do seu projeto.
Você pode especificar a versão do plug-in no
menu File > Project
Structure > Project no Android Studio ou
no arquivo build.gradle
do nível superior. A versão do plug-in se aplica a
todos os módulos criados no projeto do Android Studio em questão. O exemplo abaixo define
o plug-in para a versão 7.2.0 do arquivo
build.gradle
:
Groovy
plugins { id 'com.android.application' version '7.2.0' apply false id 'com.android.library' version '7.2.0' apply false id 'org.jetbrains.kotlin.android' version '1.5.31' apply false }
Kotlin
plugins { id("com.android.application") version "7.2.0" apply false id("com.android.library") version "7.2.0" apply false id("org.jetbrains.kotlin.android") version "1.5.31" apply false }
Atenção: não use dependências dinâmicas em números
de versão, como 'com.android.tools.build:gradle:2.+'
. O uso
desse recurso pode resultar em atualizações inesperadas e dificuldades para resolver
diferenças de versão.
Se a versão especificada do plug-in não tiver sido transferida por download, o Gradle fará o download da próxima vez que você criar o projeto ou clicar em File > Sync Project with Gradle Files na barra de menus do Android Studio.
Atualizar o Gradle
Ao atualizar o Android Studio, você poderá receber uma solicitação para também atualizar o Gradle para a versão mais recente disponível. Você pode aceitar a atualização ou especificar manualmente uma versão com base nos requisitos de build do projeto.
A tabela a seguir lista qual versão do Gradle é necessária para cada versão do Plug-in do Android para Gradle. Para ter a melhor performance, use a versão mais recente possível do Gradle e do plug-in.
Versão do plug-in | Versão necessária do Gradle |
---|---|
1.0.0 - 1.1.3 | 2.2.1 - 2.3 |
1.2.0 - 1.3.1 | 2.2.1 - 2.9 |
1.5.0 | 2.2.1 - 2.13 |
2.0.0 - 2.1.2 | 2.10 - 2.13 |
2.1.3 - 2.2.3 | 2.14.1 - 3.5 |
2.3.0+ | 3.3+ |
3.0.0+ | 4.1+ |
3.1.0+ | 4.4+ |
3.2.0 - 3.2.1 | 4.6+ |
3.3.0 - 3.3.3 | 4.10.1+ |
3.4.0 - 3.4.3 | 5.1.1+ |
3.5.0 - 3.5.4 | 5.4.1+ |
3.6.0 - 3.6.4 | 5.6.4+ |
4.0.0+ | 6.1.1+ |
4.1.0+ | 6.5+ |
4.2.0+ | 6.7.1+ |
7.0 | 7.0+ |
7.1 | 7.2+ |
7.2 | 7.3.3+ |
Você pode especificar a versão do Gradle acessando o menu File >
Project Structure > Project no
Android Studio ou editando a referência de distribuição do Gradle no arquivo
gradle/wrapper/gradle-wrapper.properties
. O exemplo abaixo
define a versão do Gradle como 7.4.2 no arquivo
gradle-wrapper.properties
.
...
distributionUrl = "https\://services.gradle.org/distributions/gradle-7.4.2-bin.zip"
...
Plug-in do Android para Gradle e compatibilidade com o Android Studio
O sistema de compilação do Android Studio é baseado no Gradle, e o plug-in do Android para Gradle adiciona vários recursos específicos para a criação de apps Android. A tabela abaixo lista qual versão do Plug-in do Android para Gradle é necessária para cada versão do Android Studio.
Versão do Android Studio | Versão do plug-in necessária |
---|---|
Arctic Fox | 2020.3.1 | 3.1-7.0 |
Bumblebee | 2021.1.1 | 3.2-7.1 |
Chipmunk | 2021.2.1 | 3.2-7.2 |
Para mais informações sobre as novidades do Plug-in do Android para Gradle, acesse as notas da versão.
Mudanças do controle de versões (novembro de 2020)
Estamos atualizando o número da versão do Plug-in do Android para Gradle (AGP, na sigla em inglês) para melhorar a integração com a ferramenta de build Gradle.
Veja as principais mudanças:
O AGP agora usará um controle de versões semântico, e as alterações interruptivas serão direcionadas para versões principais.
Haverá uma versão principal do AGP lançada por ano, alinhada à versão principal do Gradle.
Após o AGP 4.2, virá a versão 7.0, que exigirá um upgrade para o Gradle versão 7.x. Cada vez que uma versão do AGP com mudanças significativas é liberada, um upgrade de versão significativo na ferramenta Gradle se faz necessário.
O uso das APIs será descontinuado com aproximadamente um ano de antecedência, e a funcionalidade de substituição será disponibilizada simultaneamente. As APIs descontinuadas vão ser removidas cerca de um ano depois, quando houver uma atualização de larga escala.
7.2.0 (maio de 2022)
O Plug-in do Android para Gradle 7.2.0 é uma versão principal que inclui vários novos recursos e melhorias.
Esta atualização secundária corresponde ao lançamento do Android Studio Chipmunk Patch 2 e inclui as correções de bugs abaixo:
- Problema 232438924: o AndroidGradlePlugin versão 7.2 interrompe a API de transformação quando usado com a API ASM
- Problema 231037948: AGP 7.2.0-rc01 :buildSrc:generatePrecompiledScriptPluginAccessors: shadow/bundletool/com/android/prefs/AndroidLocation$AndroidLocationException
Esta atualização secundária corresponde ao lançamento do Android Studio Chipmunk Patch 1 e inclui as correções de bugs abaixo:
- Problema 230361284: o bundletool não agrupa perfis de referência corretamente
Para conferir as outras correções de bugs incluídas nesta versão, consulte as notas da versão do Android Studio Chipmunk Patch 1.
Aviso e análise do Jetifier do Build Analyzer
O Build Analyzer agora mostra um aviso se o arquivo gradle.properties
do projeto inclui android.enableJetifier=true
. Essa sinalização foi introduzida em uma
versão anterior do Android Studio para ativar o AndroidX em bibliotecas que não
oferecem suporte a ele. No entanto, o ecossistema das bibliotecas passou a
oferecer suporte ao AndroidX de forma nativa, e a sinalização Jetifier provavelmente não é mais necessária para
o projeto. A sinalização também pode deixar a performance do build mais lenta. Se
esse aviso aparecer, você pode executar uma verificação no Build Analyzer para confirmar se
a sinalização pode ser removida.
Suporte aos recursos de teste
O Android Studio Chipmunk Beta 1 e versões mais recentes oferece suporte aos recursos de teste do Android e do Java. Para mais informações, consulte o guia do Gradle sobre como usar os recursos de teste (em inglês) e descubra como usar esses recursos em um projeto Java.
Para ativar os recursos de teste no módulo da biblioteca Android, adicione o código abaixo ao
arquivo build.gradle
no nível da biblioteca:
android {
testFixtures {
enable true
// enable testFixtures's android resources (disabled by default)
// androidResources true
}
}
Por padrão, a publicação da biblioteca também publica as AARs dos recursos de teste com
a biblioteca principal. O arquivo de metadados do módulo do Gradle vai conter informações para que
o Gradle possa consumir o artefato certo ao solicitar o componente
testFixtures
.
Para desativar a publicação dos recursos da AAR de uma biblioteca na variante de lançamento,
adicione o código abaixo ao arquivo build.gradle
no nível da biblioteca:
afterEvaluate {
components.release.withVariantsFromConfiguration(
configurations.releaseTestFixturesVariantReleaseApiPublication) { skip() }
components.release.withVariantsFromConfiguration(
configurations.releaseTestFixturesVariantReleaseRuntimePublication) { skip() }
}
Para consumir as AARs dos recursos de teste de uma biblioteca Android publicada, use o
método auxiliar testFixtures()
do Gradle.
dependencies {
testImplementation testFixtures('com.example.company:publishedLib:1.0')
}
Por padrão, o lint vai analisar as fontes dos recursos de teste. Você pode configurar o lint para ignorar as fontes dos recursos de teste desta maneira:
android {
lint {
ignoreTestFixturesSources true
}
}
Não há suporte para raízes de conteúdo duplicado
A partir do AGP 7.2, não é mais possível compartilhar o mesmo diretório de origem entre vários conjuntos de origem. Por exemplo, não é possível usar as mesmas origens para testes de unidade e de instrumentação. Para saber mais, consulte Mudar as configurações dos conjuntos de origem padrão.
7.1.0 (janeiro de 2022)
O Plug-in do Android para Gradle 7.1.0 é uma versão principal que inclui vários novos recursos e melhorias.
7.1.3 (abril de 2022)
Esta atualização secundária inclui estas correções de bugs:
- Os problemas de classes duplicadas foram relatados pelo R8
Para ver uma lista completa de correções de bugs incluídas nesta versão, consulte a postagem do blog Android Studio Bumblebee Patch 3 (link em inglês).
7.1.2 (fevereiro de 2022)
Esta atualização secundária inclui estas correções de bugs:
- O Plug-in do Android para Gradle 7.1.0-rc01 falha ao realizar a transformação de bytecode do ASM durante testes de unidade.
- A sincronização do Gradle falha com "Não foi possível carregar a classe 'com.android.build.api.extension.AndroidComponentsExtension'".
- Alguns novos blocos de DSL não podem ser usados com a DSL do Groovy no Plug-in do Android para Gradle 7.0.0.
- Nova API de publicação do AGP 7.1: o javadoc jar criado não é assinado.
- O ClassesDataSourceCache precisa usar a versão mais recente do ASM.
- O Android BumbleBee nem sempre implanta as mudanças mais recentes.
Para ver uma lista completa de correções de bugs incluídas nesta versão, consulte a postagem do blog Android Studio Bumblebee Patch 2 (link em inglês).
7.1.1 (fevereiro de 2022)
Esta atualização secundária corresponde à versão do Android Studio Bumblebee Patch 1.
Para ver uma lista de correções de bugs incluídas nesta versão, consulte a postagem do blog Android Studio Bumblebee Patch 1 (link em inglês).
Compatibilidade
Versão mínima | Versão padrão | Observações | |
---|---|---|---|
Gradle | 7.2 | 7.2 | Para saber mais, consulte Como atualizar o Gradle. |
Ferramentas de build do SDK | 30.0.3 | 30.0.3 | Instale ou configure as Ferramentas de build do SDK. |
NDK | N/A | 21.4.7075529 | Instale ou configure uma versão diferente do NDK. |
JDK | 11 | 11 | Para saber mais, consulte Como configurar a versão do JDK. |
A tarefa de análise do lint agora pode ser armazenada em cache
O AndroidLintAnalysisTask
agora é compatível com o cache de build
do Gradle (link em inglês).
Se você ativar o cache de build definindo org.gradle.caching=true
no
arquivo gradle.properties
, a tarefa de análise do lint vai receber a saída do
cache de build, quando possível.
A tarefa de análise do lint geralmente é o maior gargalo ao executar o lint com o Plug-in do Android para Gradle. Portanto, ativar o cache de build melhora a velocidade de criação ao executar o lint em muitas situações. Você vai ver uma melhoria perceptível no desempenho. Por exemplo, se você tiver um projeto com vários módulos e limpar o diretório de build antes de executar o lint no servidor de CI.
Os módulos C/C++ agora podem referenciar outros módulos C/C++ no mesmo projeto
Um módulo do Gradle para Android com código C/C++ agora pode ser configurado para referenciar arquivos principais e código da biblioteca em outro módulo do Gradle. O protocolo Prefab (link em inglês) é usado para comunicar os arquivos principais e as bibliotecas entre os módulos do Gradle.
Requisitos
O módulo de consumo precisa ser
CMake
, e nãondk-build
. O suporte para ndk- build exige uma atualização futura do NDK. O módulo de publicação pode serCMake
oundk-build
.O módulo de consumo precisa ativar
prefab
no arquivobuild.gradle
.
android {
buildFeatures {
prefab true
}
}
- O módulo de publicação precisa ativar
prefabPublishing
no arquivobuild.gradle
.
android {
buildFeatures {
prefabPublishing true
}
}
- O módulo de consumo precisa referenciar o módulo de publicação adicionando uma linha ao bloco
dependencies
do arquivobuild.gradle
. Exemplo:
dependencies {
implementation project(':mylibrary')
}
- O módulo de publicação precisa expor um pacote usando uma seção
prefab
. Exemplo:
android {
prefab {
mylibrary {
libraryName "libmylibrary"
headers "src/main/cpp/include"
}
}
}
- O arquivo
CMakeLists.txt
do módulo de consumo pode usarfind_package()
para localizar o pacote publicado pelo módulo de produção. Exemplo:
find_package(mylibrary REQUIRED CONFIG)
target_link_libraries(
myapplication
mylibrary::mylibrary)
- É preciso haver um STL para todo o aplicativo. Por exemplo, os módulos de consumo e publicação podem usar o STL compartilhado por C++.
android {
defaultConfig {
externalNativeBuild {
cmake {
arguments '-DANDROID_STL=c++_shared'
}
}
}
}
Para ver uma explicação mais detlhada sobre como configurar produtores e consumidores de AAR nativos com o AGP, consulte as Dependências nativas com o AGP.
Configurações do repositório no arquivo settings.gradle
Quando um novo projeto é criado no Android Studio Bumblebee, o arquivo
build.gradle
de nível mais alto contém o bloco plugins
, seguido pelo código para limpar o
diretório de build:
plugins {
id 'com.android.application' version '7.1.0-beta02' apply false
id 'com.android.library' version '7.1.0-beta02' apply false
id 'org.jetbrains.kotlin.android' version '1.5.30' apply false
}
task clean(type: Delete) {
delete rootProject.buildDir
}
As configurações do repositório que estavam anteriormente no arquivo build.gradle
de nível mais alto agora estão no arquivo settings.gradle
:
pluginManagement {
repositories {
gradlePluginPortal()
google()
mavenCentral()
}
}
dependencyResolutionManagement {
repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
repositories {
google()
mavenCentral()
}
}
rootProject.name = 'GradleManagedDeviceTestingNew'
include ':app'
O arquivo build.gradle
no nível de módulos não mudou. Portanto, use o arquivo de nível mais alto
build.gradle
e o arquivo settings.gradle
para definir as configurações
do build que se aplicam a todos os módulos do projeto ou os repositórios
e dependências que se aplicam ao próprio Gradle. Use o arquivo
build.gradle
no nível de módulo para definir configurações do build específicas para um determinado
módulo dentro do projeto.
Redutor de recursos melhorado
O Android Studio Bumblebee inclui um redutor de recursos melhorado que ajuda a reduzir o tamanho do app.
Suporte para apps com recursos dinâmicos
A implementação padrão do redutor de recursos do Android foi atualizada no Plug-in do Android para Gradle 7.1.0-alpha09. A nova implementação oferece suporte à redução de apps com recursos dinâmicos.
Mais reduções experimentais no tamanho de apps
A nova implementação de redutor pode reduzir ainda mais o tamanho do app
ao modificar a tabela para remover recursos de valor não usados e
referências a recursos de arquivo não utilizados. O novo redutor de recursos pode excluir completamente
os recursos de arquivo não utilizados, reduzindo o tamanho do app. Esse comportamento ainda
não está ativado por padrão, mas é possível o ativar adicionando a
opção experimental
android.experimental.enableNewResourceShrinker.preciseShrinking=true
ao arquivo gradle.properties
do projeto.
Informe qualquer problema que você encontrar com o novo redutor de recursos ou a
sinalização experimental. Para ajudar a diagnosticar problemas ou, como uma solução temporária, você
pode voltar à implementação anterior adicionando
android.enableNewResourceShrinker=false
às gradle.properties
do projeto.
O novo redutor substitui recursos baseados em arquivos não utilizados por arquivos mínimos
um pouco diferentes do anterior, mas não é esperado que
isso tenha impacto no ambiente de execução.
A implementação antiga está programada para ser removida no Plug-in do Android para Gradle 8.0.0.
Publicação de variantes de build
O Plug-in do Android para Gradle 7.1.0, e versões mais recentes, permite que você configure quais variantes de build são publicadas em um repositório Apache Maven. O AGP cria um componente com uma ou mais variantes de build com base na nova DSL de publicação, que pode ser usada para personalizar uma publicação para um repositório Maven. Em comparação com versões mais antigas, isso também evita trabalhos desnecessários, já que nenhum componente é criado por padrão. Para saber mais, consulte o exemplo de código de publicação.
Publicar JAR do Javadoc
O AGP 7.1.0, e versões mais recentes, permite que você gere um Javadoc de origens
Java e Kotlin e publique arquivos Javadoc JAR, além de AARs para projetos de
biblioteca. O Javadoc é adicionado aos arquivos POM e
Gradle Module Metadata (link em inglês). Ative esse recurso adicionando withJavadocJar()
no
bloco de publicação singleVariant
ou no multipleVariants
. Para saber mais, consulte o
exemplo de código de opções de publicação.
Publicar JAR de origens
O AGP 7.1.0, e versões mais recentes, permite publicar arquivos JAR de origem Java e Kotlin, além
de AARs para projetos de bibliotecas. As origens são adicionadas aos arquivos POM e
Gradle Module Metadata (link em inglês). É possível ativar esse recurso adicionando
withSourcesJar()
no bloco de publicação singleVariant
ou
no multipleVariants
. Para saber mais, consulte o exemplo de código de opções de publicação.
Mudança semântica de bloco do lint
Todos os métodos de lint que substituem o nível de gravidade de um problema (enable
,
disable
/ignore
, informational
, warning
, error
ou fatal
) agora respeitam a
ordem de configuração. Por exemplo, definir um problema como fatal em
finalizeDsl()
agora substitui a desativação na DSL principal. Para ver mais informações, consulte os
documentos de referência de bloco
lint{}
e o
fluxo de build e pontos de extensão do Android.
Compatibilidade com o Safe Args de navegação
As APIs AGP de que o plug-in do Gradle para o Safe Args de navegação depende foram removidas. O AGP 7.1 não funciona com o Safe Args de navegação nas versões 2.4.0-rc1 ou 2.4.0, mas funciona com as versões 2.5.0-alpha01 e 2.4.1. Enquanto isso, como solução alternativa, você pode usar o AGP 7.1 com um build de snapshot do Safe Args de navegação, o Navigation 2.5.0-SNAPSHOT. Para usar a versão do snapshot, siga as instruções para snapshot com o código de build #8054565.
Além disso, as versões 2.4.1 e 2.5.0 do Safe Args de navegação não funcionam mais com o AGP 4.2. Para usar essas versões do Safe Args, é necessário usar o AGP 7.0 e versões mais recentes.
Desativar a criação automática de componentes
A partir do AGP 8.0, a criação automática de componentes vai ser desativada por padrão.
Atualmente, o AGP 7.1 cria automaticamente um componente para cada variante de build,
que tem o mesmo nome da variante, e um componente all
que
contém todas as variantes. A criação automática de componentes vai ser
desativada. A fim de fazer a transição para o novo comportamento, desative
manualmente a criação automática de componentes definindo
android.disableAutomaticComponentCreation
como true.
. Para mais informações, consulte
Usar o plug-in Maven Publish.
Compatibilidade do Monitoramento de desempenho do Firebase
O AGP 7.1 não é compatível com o plug-in do Gradle
para o Monitoramento de desempenho do Firebase versão 1.4.0 e mais antigas. O AGP Upgrade Assistant não vai atualizar
automaticamente o plug-in para a versão 1.4.1. Portanto, se você está usando firebase-perf
e quer
fazer upgrade do AGP para a versão 7.1, é necessário fazer esse upgrade específico manualmente.
Problemas conhecidos
Esta seção descreve problemas conhecidos que existem no Plug-in do Android para Gradle 7.1.0.
Problemas ao testar a 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 aplicativos não instrumentados. Isso significa que o Hilt não instrumenta as classes do app para processar a injeção de dependência ao executar testes de unidade.
Esse problema vai ser corrigido na versão 7.1.1, consulte o problema #213534628.
7.0.0 (julho de 2021)
O Plug-in do Android para Gradle 7.0.0 é uma versão principal que inclui uma variedade de novos recursos e melhorias.
7.0.1 (agosto de 2021)
Esta atualização secundária inclui várias correções de bugs. Para ver uma lista de correções de bugs importantes, leia a postagem relacionada no blog de Atualizações de versão (link em inglês).
Compatibilidade
Versão mínima | Versão padrão | Observações | |
---|---|---|---|
Gradle | 7.0.2 | 7.0.2 | Para saber mais, consulte Como atualizar o Gradle. |
SDK Build Tools | 30.0.2 | 30.0.2 | Instale ou configure as Ferramentas de build do SDK. |
NDK | N/A | 21.4.7075529 | Instale ou configure uma versão diferente do NDK. |
JDK | 11 | 11 | Para saber mais, consulte Como configurar a versão do JDK. |
JDK 11 necessário para executar o AGP 7.0
Ao usar o Plug-in do Android para Gradle 7.0 para criar seu app, o JDK 11 agora é necessário para executar o Gradle. O Android Studio Arctic Fox inclui o JDK 11 e configura o Gradle para usá-lo por padrão. Isso significa que a maioria dos usuários do Android Studio não precisa fazer nenhuma mudança de configuração nos projetos.
Se você precisar definir a versão do JDK usada pelo AGP no Android Studio manualmente, use o JDK 11 ou versão mais recente.
Ao usar o AGP, independentemente do Android Studio, faça upgrade da versão do JDK
configurando a variável de ambiente JAVA_HOME
ou a opção da linha de comando -Dorg.gradle.java.home
(links em inglês) para o diretório de instalação do JDK 11.
O SDK Manager e o AVD Manager no pacote descontinuado "Ferramentas do SDK" não funcionam com o JDK 11. Para continuar a usar o SDK Manager e o AVD Manager com o AGP 7.0 e versões mais recentes, você precisa mudar para as novas versões das ferramentas no pacote atual de Ferramentas de linha de comando do SDK do Android.
API Variant estável
A nova API Variant agora está estável. Veja as novas interfaces no pacote com.android.build.api.variant e os exemplos no projeto gradle-recipes (link em inglês) do GitHub. Como parte da nova API Variant, disponibilizamos vários arquivos intermediários, chamados artefatos, por meio da interface Artefatos. Esses artefatos, como o manifesto integrado, podem ser conseguidos e personalizados com segurança usando códigos e plug-ins de terceiros.
Continuaremos estendendo a API Variant com a adição de novas funções e o aumento do número de artefatos intermediários disponibilizados para personalização.
Mudanças de comportamento do lint
Esta seção descreve várias mudanças de comportamento do lint no Plug-in do Android para Gradle 7.0.0.
Lint aprimorado para dependências de biblioteca
A execução do lint com checkDependencies = true
agora está mais rápida do que antes.
Para projetos do Android compostos por um app com dependências de biblioteca,
é recomendável definir checkDependencies
como true
, conforme mostrado abaixo, e executar o lint usando
./gradlew :app:lint
, que analisará todos os módulos de dependência em paralelo e
produzirá um único relatório, incluindo problemas do app e todas as respectivas dependências.
Groovy
// build.gradle android { ... lintOptions { checkDependencies true } }
Kotlin
// build.gradle.kts android { ... lint { isCheckDependencies = true } }
As tarefas de lint agora podem ser atualizadas
Se as origens e os recursos de um módulo não tiverem sido modificados, a tarefa de análise do lint para o
módulo não precisará ser executada novamente. Quando isso acontece, a execução da
tarefa aparece como "UP-TO-DATE" (atualizada) na saída do Gradle. Com essa mudança, ao executar
o lint em um módulo de aplicativo com checkDependencies = true
, apenas os módulos que
foram modificados precisarão executar a análise. Como resultado, o lint pode ser executado ainda mais rapidamente.
A tarefa de relatório do lint também não precisará ser executada se as entradas não tiverem sido modificadas. Um problema conhecido relacionado é que não há saída de texto do lint impressa em stdout quando a tarefa do lint está atualizada (problema 191897708).
Como executar o lint em módulos de recursos dinâmicos
O AGP não é mais compatível com a execução do lint em módulos de recursos dinâmicos. A execução do lint
no módulo de aplicativo correspondente executará o lint nos módulos de recursos
dinâmicos e incluirá todos os problemas no relatório do lint do app. Um problema conhecido relacionado é que, 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 app (problema 191977888).
Como executar o lint apenas na variante padrão
A execução de ./gradlew :app:lint
agora executa o lint apenas para a variante padrão.
Nas versões anteriores do AGP, o lint seria executado para todas as variantes.
Avisos de classes ausentes no redutor R8
O R8 processa com mais precisão e
consistência as classes ausentes e a opção -dontwarn
. Portanto, comece
a avaliar os avisos de classes ausentes emitidos pelo R8.
Quando o R8 encontra uma referência de classe que não está definida no seu app ou em uma das dependências, ele emite um alerta que aparece na saída do build. Por exemplo:
R8: Missing class: java.lang.instrument.ClassFileTransformer
Esse alerta significa que a definição de classe java.lang.instrument.ClassFileTransformer
não foi encontrada ao analisar o código do app. Geralmente, isso significa que há um erro,
mas é possível ignorar esse alerta. Veja a seguir dois motivos comuns para ignorá-lo:
As bibliotecas voltados à JVM e a classe ausente são do tipo da biblioteca JVM (como no exemplo acima).
Uma das dependências usa uma API somente para tempo de compilação.
Você pode ignorar um alerta de classe ausente adicionando uma regra -dontwarn
ao
arquivo proguard-rules.pro
. Por exemplo:
-dontwarn java.lang.instrument.ClassFileTransformer
Por conveniência, o AGP gera um arquivo que contém todas as regras possivelmente
ausentes, gravando-as em um caminho de arquivo como o seguinte:
app/build/outputs/mapping/release/missing_rules.txt
. Adicione as regras ao
arquivo proguard-rules.pro
para ignorar os alertas.
No AGP 7.0, as mensagens de classes ausentes aparecerão como alertas, e você pode transformá-las
em erros configurando android.r8.failOnMissingClasses = true
em gradle.properties
.
No AGP 8.0, esses alertas se tornarão erros que corromperão o build. É
possível manter o comportamento do AGP 7.0 adicionando a opção -ignorewarnings
ao
arquivo proguard-rules.pro
, mas isso não é recomendado.
O cache de build do Plug-in do Android para Gradle foi removido
O cache de build do AGP foi removido no AGP 4.1. Introduzido no AGP 2.3 para complementar o cache de build do Gradle, o cache de build do AGP foi totalmente substituído pelo do Gradle no AGP 4.1. Essa mudança não afeta o tempo de compilação.
No AGP 7.0, as propriedades android.enableBuildCache
e android.buildCacheDir
e a tarefa cleanBuildCache
foram removidas.
Usar o código-fonte Java 11 no seu projeto
Agora, é possível compilar até o código-fonte Java 11 no projeto do app, o que permite usar recursos de linguagem mais recentes, como métodos de interface privados, o operador losango para classes anônimas e a sintaxe de variáveis local para parâmetros lambda.
Para ativar esse recurso, defina compileOptions
como a versão Java desejada e
defina compileSdkVersion
como 30 ou mais:
Groovy
// build.gradle android { compileSdkVersion 30 compileOptions { sourceCompatibility JavaVersion.VERSION_11 targetCompatibility JavaVersion.VERSION_11 } // For Kotlin projects kotlinOptions { jvmTarget = "11" } }
Kotlin
// build.gradle.kts android { compileSdkVersion(30) compileOptions { sourceCompatibility(JavaVersion.VERSION_11) targetCompatibility(JavaVersion.VERSION_11) } kotlinOptions { jvmTarget = "11" } }
Configurações de dependência removidas
No AGP 7.0, as seguintes configurações (ou escopos de dependência) foram removidas:
compile
Dependendo do caso de uso, foi substituído porapi
ouimplementation
.
Também se aplica a variantes *Compile, por exemplo:debugCompile
.provided
Foi substituído porcompileOnly
.
Também se aplica a variantes *Provided, por exemplo:releaseProvided
.apk
Foi substituído porruntimeOnly
.publish
Foi substituído porruntimeOnly
.
Na maioria dos casos, o Assistente de upgrade para AGP migrará seu projeto automaticamente para as novas configurações
Mudança do caminho de classe ao compilar com o Plug-in do Android para Gradle
Se você está compilando com o Plug-in do Android para Gradle, seu caminho de classe
de compilação pode mudar. Como o AGP agora usa configurações api/implementation
internamente,
alguns artefatos podem ser removidos do caminho de classe da compilação. Se você depende de uma
dependência do AGP durante a compilação, adicione-a como uma dependência explícita.
Não é possível adicionar bibliotecas nativas em uma pasta de recursos Java
Antes, era possível adicionar uma biblioteca nativa a uma pasta de recursos Java e
registrar essa pasta usando android.sourceSets.main.resources.srcDirs
para que
a biblioteca nativa fosse extraída e adicionada ao APK final. A partir do
AGP 7.0, esse recurso deixou de ter suporte e as bibliotecas nativas que estiverem em uma pasta de recursos Java
serão ignoradas. Em vez disso, use o método DSL destinado a bibliotecas
nativas, android.sourceSets.main.jniLibs.srcDirs
. Para saber mais, veja
como configurar conjuntos de origem.
Problemas conhecidos
Esta seção descreve problemas conhecidos que existem no Plug-in do Android para Gradle 7.0.0.
Incompatibilidade com o plug-in Kotlin Multiplatform 1.4.x
O Plug-in do Android para Gradle 7.0.0 é compatível com o plug-in Kotlin Multiplatform 1.5.0 e versões mais recentes. Os projetos que usam o Kotlin Multiplatform precisam ser atualizados para o Kotlin 1.5.0 para usar o Plug-in do Android para Gradle 7.0.0. Como alternativa, você pode fazer downgrade do Plug-in do Android para Gradle para a versão 4.2.x, embora isso não seja recomendado.
Para mais informações, consulte KT-43944.
Saída do lint ausente
Não há saída de texto do lint impressa em stdout quando a tarefa do lint está atualizada (problema 191897708). Para ver mais contexto, consulte Mudanças de comportamento do lint. Esse problema será corrigido no Plug-in do Android para Gradle 7.1.
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. Para ver mais contexto,
consulte Mudanças de comportamento do lint.
4.2.0 (março de 2021)
Compatibilidade
Versão mínima | Versão padrão | Observações | |
---|---|---|---|
Gradle | 6.7.1 | N/A | Para saber mais, consulte Como atualizar o Gradle. |
SDK Build Tools | 30.0.2 | 30.0.2 | Instale ou configure as Ferramentas de build do SDK. |
NDK | N/A | 21.4.7075529 | Instale ou configure uma versão diferente do NDK. |
Novos recursos
Esta versão do Plug-in do Android para Gradle inclui os novos recursos a seguir.
Versão 8 da linguagem Java como padrão
A partir da versão 4.2, o AGP usará o nível de linguagem Java 8 por padrão. O Java 8 oferece acesso a diversos recursos de linguagem mais recentes, incluindo expressões lambda, referências de método e métodos de interface estática. Para ver a lista completa de recursos compatíveis, consulte a documentação do Java 8.
Para manter o comportamento antigo, especifique o Java 7 explicitamente no arquivo
build.gradle.kts
ou build.gradle
do módulo:
Groovy
// build.gradle android { ... compileOptions { sourceCompatibility JavaVersion.VERSION_1_7 targetCompatibility JavaVersion.VERSION_1_7 } // For Kotlin projects, compile to Java 6 instead of 7 kotlinOptions { jvmTarget = "1.6" } }
Kotlin
// build.gradle.kts android { ... compileOptions { sourceCompatibility = JavaVersion.VERSION_1_7 targetCompatibility = JavaVersion.VERSION_1_7 } // For Kotlin projects, compile to Java 6 instead of 7 kotlinOptions { jvmTarget = "1.6" } }
Novo compilador de recursos do JVM
Um novo compilador de recursos JVM na ferramenta do Plug-in do Android para Gradle 4.2 substitui partes do compilador de recursos AAPT2, possivelmente melhorando a performance do build, especialmente em máquinas Windows. O novo compilador de recursos da JVM é ativado por padrão.
A assinatura de v3 e v4 agora é compatível
O Plug-in do Android para Gradle 4.2 agora é compatível com
os formatos de assinatura APK v3 e APK v4.
Para ativar um ou ambos os formatos no seu
build, adicione as seguintes propriedades ao arquivo build.gradle
ou build.gradle.kts
no nível do módulo:
Groovy
// build.gradle android { ... signingConfigs { config { ... enableV3Signing true enableV4Signing true } } }
Kotlin
// build.gradle.kts android { ... signingConfigs { config { ... enableV3Signing = true enableV4Signing = true } } }
A assinatura do APK v4 permite implantar rapidamente APKs grandes usando a instalação do APK incremental do ADB no Android 11. Essa nova sinalização cuida da etapa de assinatura do APK no processo de implantação.
Configurar a assinatura de apps por variante
Agora, é possível ativar ou desativar a assinatura de apps no Plug-in do Android para Gradle por variante.
Este exemplo mostra como definir a assinatura de apps por variante usando o método
onVariants()
em Kotlin ou Groovy:
androidComponents {
onVariants(selector().withName("fooDebug"), {
signingConfig.enableV1Signing.set(false)
signingConfig.enableV2Signing.set(true)
})
Nova propriedade do Gradle: android.native.buildOutput
Para reduzir a sobrecarga na saída de build, o AGP 4.2 filtra mensagens
de builds nativos que usam CMake e ndk-build
,
exibindo apenas a saída do compilador C/C++ por padrão. Antes disso, uma linha de saída
era gerada para cada arquivo criado, resultando em uma grande quantidade de
mensagens informativas.
Se você quiser ver toda a saída nativa, defina a nova
propriedade do Gradle android.native.buildOutput
como verbose
.
É possível definir essa propriedade no arquivo gradle.properties
ou pela
linha de comando.
gradle.properties
android.native.buildOutput=verbose
Linha de comando
-Pandroid.native.buildOutput=verbose
O valor padrão dessa propriedade é quiet
.
Mudança de comportamento para arquivos gradle.properties
A partir do AGP 4.2, não é mais possível substituir as propriedades Gradle
de subprojetos. Em outras palavras, se você declarar uma propriedade em um
arquivo gradle.properties
em um subprojeto em vez do projeto raiz, ele
será ignorado.
Como exemplo, em versões anteriores, o AGP leria valores de
projectDir/gradle.properties
,
projectDir/app/gradle.properties
,
projectDir/library/gradle.properties
etc. Para módulos
de apps, se a mesma propriedade do Gradle estivesse presente em
projectDir/gradle.properties
e
projectDir/app/gradle.properties
, o valor de
projectDir/app/gradle.properties
teria precedência.
No AGP 4.2, esse comportamento foi mudado, e o AGP não carrega valores de
gradle.properties
em subprojetos (por exemplo,
projectDir/app/gradle.properties
). Essa mudança
reflete o novo comportamento do Gradle
oferece suporte ao armazenamento em cache da configuração (links em inglês).
Para ver mais informações sobre como definir valores em arquivos gradle.properties
, consulte os
documentos do Gradle (em inglês).
Mudanças na configuração e compatibilidade do Gradle
Quando a ferramenta de compilação do Gradle é executada no Android Studio, ela usa o JDK empacotado no Studio. Em versões anteriores, o JDK 8 era incluído no Studio. No entanto, na versão 4.2, o JDK 11 agora é incluído. Ao usar o novo JDK incluído para executar o Gradle, isso pode resultar em alguma incompatibilidade ou afetar o desempenho do JVM devido a alterações no coletor de lixo. Esses problemas estão descritos abaixo.
Observação: embora seja recomendável executar o Gradle com o JDK 11, é possível alterar o JDK usado para executar o Gradle na caixa de diálogo Project Structure. Alterar essa configuração só mudará o JDK usado para executar o Gradle, e não o usado para executar o Studio.
Compatibilidade do Studio com o Plug-in do Android para Gradle (AGP)
O Android Studio 4.2 pode abrir projetos que usam o AGP 3.1 e mais recente, desde que o AGP esteja executando o Gradle 4.8.1 ou versões mais recentes. Para ver mais informações sobre a compatibilidade do Gradle, consulte Atualizar o Gradle.
Como otimizar os builds do Gradle para o JDK 11
Essa atualização para o JDK 11 afeta a configuração padrão do coletor de lixo da JVM, já que o JDK 8 usa o coletor de lixo paralelo, enquanto o JDK 11 usa o coletor de lixo G1 (link em inglês).
Para potencialmente melhorar o desempenho do build, recomendamos
testar seus builds do Gradle com o coletor
de lixo paralelo. Em gradle.properties
, defina o seguinte:
org.gradle.jvmargs=-XX:+UseParallelGC
Se já houver outras opções definidas nesse campo, adicione uma nova opção:
org.gradle.jvmargs=-Xmx1536m -XX:+UseParallelGC
Para medir a velocidade do build com diferentes configurações, consulte Criar perfil para seu build.
Arquivos DEX descompactados em APKs quando o valor de minSdk
for igual a 28 ou mais
Por padrão, agora o AGP agrupa os arquivos DEX descompactados em APKs quando o valor de minSdk
é igual a 28 ou
mais. Isso causa um aumento no tamanho do APK, mas resulta em um tamanho de
instalação menor no dispositivo, com tamanho de download praticamente igual.
Para forçar o AGP a empacotar os arquivos DEX compactados, adicione o
código abaixo ao arquivo build.gradle
:
android {
packagingOptions {
dex {
useLegacyPackaging true
}
}
}
Usar a DSL para empacotar bibliotecas nativas compactadas
Recomendamos empacotar bibliotecas nativas em formato não compactado, porque isso
resulta em arquivos menores de instalação e download do app e em um tempo de carregamento mais
rápido para os usuários. No entanto, se você quiser que o Plug-in do Android para Gradle empacote bibliotecas nativas compactadas ao criar seu app, defina
useLegacyPackaging
como true
no arquivo build.gradle
do app:
android {
packagingOptions {
jniLibs {
useLegacyPackaging true
}
}
}
A sinalização useLegacyPackaging
substitui o atributo de manifesto extractNativeLibs
.
Para mais informações, consulte a nota da versão Bibliotecas nativas empacotadas descompactadas por padrão.
4.1.0 (agosto de 2020)
Compatibilidade
Versão mínima | Versão padrão | Observações | |
---|---|---|---|
Gradle | 6.5 | N/A | Para saber mais, consulte Como atualizar o Gradle. |
SDK Build Tools | 29.0.2 | 29.0.2 | Instale ou configure o SDK Build Tools. |
NDK | N/A | 21.1.6352462 | Instale ou configure uma versão diferente do NDK. |
Novos recursos
Esta versão do Plug-in do Android para Gradle inclui os novos recursos a seguir.
Compatibilidade com DSL do script Kotlin
Para ajudar a melhorar a experiência de edição para usuários do buildscript do Kotlin, a DSL e as APIs do Plug-in do Android para Gradle 4.1 agora estão definidas em um conjunto de interfaces do Kotlin separado das classes de implementação. O que isso significa:
- Nulidade e mutabilidade agora são explicitamente declaradas em tipos Kotlin.
- A documentação gerada por essas interfaces é publicada na referência da API Kotlin.
- A superfície da API do Plug-in do Android para Gradle é claramente definida para tornar os builds do Android menos instáveis no futuro.
Os tipos de coleção projetados para serem transformados em DSL agora são definidos de maneira uniforme como:
val collection: MutableCollectionType
Isso significa que não é mais possível escrever o seguinte em scripts Kotlin para algumas coleções compatíveis anteriormente:
collection = collectionTypeOf(...)
No entanto, a modificação da coleção é aceita de modo uniforme, de modo que collection += …
e collection.add(...)
agora funcionam em qualquer lugar.
Se você descobrir algum problema ao fazer upgrade de um projeto que usa as APIs Kotlin do Plug-in do Android para Gradle e a DSL, informe um bug.
Exportar dependências C/C++ de AARs
O Plug-in do Android para Gradle 4.0 adicionou a capacidade de importar pacotes Prefab em dependências de AAR. No AGP 4.1, agora é possível exportar bibliotecas do seu build nativo externo em um AAR para um projeto de biblioteca do Android.
Para exportar suas bibliotecas nativas, adicione o seguinte ao bloco android
do arquivo build.gradle
do projeto da biblioteca:
Groovy
buildFeatures { prefabPublishing true } prefab { mylibrary { headers "src/main/cpp/mylibrary/include" } myotherlibrary { headers "src/main/cpp/myotherlibrary/include" } }
Kotlin
buildFeatures { prefabPublishing = true } prefab { create("mylibrary") { headers = "src/main/cpp/mylibrary/include" } create("myotherlibrary") { headers = "src/main/cpp/myotherlibrary/include" } }
Neste exemplo, as bibliotecas mylibrary
e myotherlibrary
do ndk-build ou do
build nativo externo do CMake serão empacotadas no AAR produzido pelo build, e cada uma exportará os cabeçalhos do diretório especificado para os dependentes.
Compatibilidade com metadados R8 do Kotlin
O Kotlin usa metadados personalizados em arquivos de classe Java para identificar construções
de linguagem Kotlin. O R8 agora é compatível com a manutenção e reescrita de metadados
Kotlin para oferecer compatibilidade total com a redução de bibliotecas e aplicativos Kotlin que
usam kotlin-reflect
.
Para manter os metadados do Kotlin, adicione as seguintes regras keep:
-keep class kotlin.Metadata { *; }
-keepattributes RuntimeVisibleAnnotations
Isso instruirá o R8 a manter os metadados de Kotlin em todas as classes que são mantidas diretamente.
Para saber mais, consulte Como reduzir bibliotecas e aplicativos com Kotlin usando a reflexão Kotlin com R8 (link em inglês) no Medium.
Declarações em builds de depuração
Quando você criar a versão de depuração do app usando o Plug-in do Android para Gradle 4.1.0 e versões mais recentes, o compilador integrado (D8) reescreverá o código do seu app para permitir declarações no tempo de compilação. Assim, você sempre terá verificações de declaração ativas.
Mudanças de comportamento
O cache de build do Plug-in do Android para Gradle foi removido
O cache de build do AGP foi removido no AGP 4.1. Introduzido no AGP 2.3 para complementar o cache de build do Gradle, o cache de build do AGP foi totalmente substituído pelo do Gradle no AGP 4.1. Essa mudança não afeta o tempo de compilação.
A tarefa cleanBuildCache
e as propriedades android.enableBuildCache
e
android.buildCacheDir
estão obsoletas e serão removidas no
AGP 7.0. Atualmente, a propriedade android.enableBuildCache
não tem efeito,
enquanto a propriedade android.buildCacheDir
e a tarefa cleanBuildCache
estarão funcionais até o AGP 7.0 para excluir qualquer conteúdo do cache de compilação do AGP
existente.
O tamanho dos apps que usam a redução de código foi significativamente diminuído
A partir dessa versão, os campos das classes R não são mais mantidos por padrão. Isso pode resultar em uma economia significativa no tamanho do APK para apps que permitem a redução de código. Isso não resultará em uma mudança de comportamento, a menos que você esteja acessando classes R por reflexão. Nesse caso, é necessário adicionar regras keep a essas classes R.
Renomeação da propriedade android.namespacedRClass para android.nonTransitiveRClass
A sinalização experimental android.namespacedRClass
foi renomeada para
android.nonTransitiveRClass
.
Definido no arquivo gradle.properties
, essa sinalização ativa o espaçamento
de nomes da classe R de cada biblioteca para que a ela inclua apenas os
recursos declarados na própria biblioteca e os recursos das dependências da biblioteca,
reduzindo assim o tamanho da classe R dessa biblioteca.
DSL de Kotlin: renomeação de coreLibraryDesugaringEnabled
A opção de compilação DSL do Kotlin coreLibraryDesugaringEnabled
foi
mudada para isCoreLibraryDesugaringEnabled
.
Para mais informações sobre essa sinalização, consulte
Suporte à simplificação de APIs do Java 8+ (Android Gradle Plugin 4.0.0+).
Propriedades de versão removidas da classe BuildConfig em projetos de biblioteca
Apenas em projetos de biblioteca, as propriedades BuildConfig.VERSION_NAME
e
BuildConfig.VERSION_CODE
foram removidas da classe
BuildConfig
gerada porque esses valores estáticos não refletiam os valores
finais do código e nome da versão do aplicativo, o que podia
causar confusão. Além disso, esses valores foram descartados durante a mesclagem do manifesto.
Em uma versão futura do Plug-in do Android para Gradle, as propriedades versionName
e
versionCode
também serão removidas da DSL para bibliotecas.
No momento, não há como acessar automaticamente o código/nome
da versão do app em um subprojeto de biblioteca.
Para os módulos de aplicativos, não há mudanças. Ainda é possível atribuir valores a
versionCode
e versionName
na DSL; esses valores serão propagados para o
manifesto do app e os campos BuildConfig
.
Definir o caminho do NDK
Você pode definir o caminho para a instalação do NDK local usando a propriedade android.ndkPath
no arquivo build.gradle
do módulo.
Groovy
android { ndkPath "your-custom-ndk-path" }
Kotlin
android { ndkPath = "your-custom-ndk-path" }
Se você usar essa propriedade com a
propriedade android.ndkVersion
,
esse caminho precisará conter uma versão do NDK que corresponda a android.ndkVersion
.
Mudanças de comportamento dos testes de unidade de biblioteca
Mudamos o comportamento de compilação e execução dos testes de unidade de biblioteca. Agora, os testes de unidade de uma biblioteca são compilados e executados em classes de compilação/tempo de execução da própria biblioteca, resultando em testes de unidade que consomem a biblioteca da mesma maneira que subprojetos externos. Essa configuração normalmente resulta em testes melhores.
Em alguns casos, os testes de unidade de biblioteca que usam vinculação de dados podem encontrar classes DataBindingComponent
ou BR
ausentes. Esses testes precisam ser transferidos para um teste de instrumentação no projeto
androidTest
, uma vez que a compilação e a execução nessas classes em
um teste de unidade pode produzir uma saída incorreta.
O plug-in io.fabric do Gradle foi descontinuado
O plug-in io.fabric do Gradle foi descontinuado e não é compatível com a versão 4.1 do Plug-in do Android para Gradle. Para ver mais informações sobre o SDK do Fabric obsoleto e a migração para o SDK do Firebase Crashlytics, consulte Fazer upgrade para o SDK do Firebase Crashlytics.
4.0.0 (abril de 2020)
Esta versão do plug-in do Android requer o seguinte:
Gradle 6.1.1. Para saber mais, leia a seção sobre a atualização do Gradle.
SDK Build Tools 29.0.2 ou versões mais recentes.
Esta atualização secundária é compatível com novas configurações e recursos padrão para visibilidade do pacote no Android 11.
Nas versões anteriores do Android, era possível ver uma lista de todos
os apps instalados em um dispositivo. A partir do Android 11 (nível 30 da API), por
padrão, os apps têm acesso somente a uma lista filtrada de pacotes instalados.
Para ver uma lista mais ampla de apps no sistema, é preciso
adicionar um elemento
<queries>
ao manifesto do Android do seu app
ou biblioteca.
O Plug-in do Android para Gradle 4.1+ já é compatível com a nova declaração
<queries>
. No entanto, as versões mais antigas não
são compatíveis. Se você adicionar o elemento <queries>
ou começar
a depender de uma biblioteca ou um SDK destinado ao Android 11, poderá
encontrar erros de mesclagem de manifesto ao criar seu app.
Para resolver esse problema, estamos lançando um conjunto de patches para o AGP 3.3 e versões mais recentes. Se você estiver usando uma versão mais antiga do AGP, faça upgrade para uma das seguintes versões:
Se você estiver usando a versão do AGP... |
Faça o upgrade para: |
---|---|
4.0.* | 4.0.1 |
3.6.* | 3.6.4 |
3.5.* | 3.5.4 |
3.4.* | 3.4.3 |
3.3.* | 3.3.3 |
Para ver mais informações sobre esse novo recurso, consulte Visibilidade do pacote no Android 11.
Novos recursos
Esta versão do Plug-in do Android para Gradle inclui os novos recursos a seguir.
Compatibilidade com o Build Analyzer do Android Studio
A janela Build Analyzer ajuda a entender e diagnosticar problemas no
processo de compilação, como otimizações desativadas e tarefas configuradas incorretamente.
Esse recurso está disponível no Android Studio 4.0 ou mais recente com o
Plug-in do Android para Gradle 4.0.0
e versões mais recentes. É possível abrir a janela Build Analyzer
no Android Studio da seguinte forma:
- Crie seu app selecionando Build > Make Project na barra de menus, caso ainda não tenha feito isso.
- Selecione View > Tool Windows > Build na barra de menus.
- Na janela Build, abra a janela Build Analyzer de uma das
seguintes maneiras:
- Depois que o Android Studio concluir a criação do projeto, clique na guia Build Analyzer.
- Depois que o Android Studio concluir a criação do seu projeto, clique no link no lado direito da janela Build Output.
A janela do Build Analyzer organiza possíveis problemas de build em uma árvore à esquerda. Inspecione e clique em cada problema para investigar os detalhes no painel à direita. Quando o Android Studio analisa seu build, ele computa o conjunto de tarefas que determinou a duração da criação e fornece uma visualização para ajudar você a entender o impacto de cada tarefa. Você também pode ver detalhes sobre os avisos expandindo o nó Warnings.
Para saber mais, leia Identificar regressões de velocidade do build.
Simplificação da biblioteca do Java 8 no D8 e R8
O Plug-in do Android para Gradle agora inclui suporte ao uso de diversas APIs da linguagem Java 8 sem a necessidade de um nível mínimo de API para seu app.
Por meio de um processo chamado desugaring (simplificação), o compilador DEX, D8, no Android Studio
3.0 e mais recentes, já fornecia compatibilidade significativa com recursos
da linguagem Java 8, como expressões lambda, métodos de interface padrão e try-with-resources, entre
outros. No Android Studio 4.0, o mecanismo de simplificação foi estendido para poder
simplificar APIs de linguagem Java. Isso significa que agora você pode incluir APIs
de linguagem padrão que estavam disponíveis apenas em versões recentes do Android (como
java.util.streams
) em apps compatíveis com versões mais antigas do Android.
O seguinte conjunto de APIs é compatível com esta versão:
- Fluxos sequenciais (
java.util.stream
) - Um subconjunto de
java.time
java.util.function
- Adições recentes a
java.util.{Map,Collection,Comparator}
- Recursos opcionais (
java.util.Optional
,java.util.OptionalInt
ejava.util.OptionalDouble
) e algumas outras novas classes úteis com as APIs acima - Algumas adições a
java.util.concurrent.atomic
(novos métodos emAtomicInteger
,AtomicLong
eAtomicReference
) ConcurrentHashMap
(com correções de bugs para o Android 5.0)
Para oferecer compatibilidade com essas APIs de linguagem, o D8 compila um arquivo DEX de biblioteca separado que contém uma implementação das APIs ausentes e as inclui no seu app. O processo de simplificação reescreve o código do seu app para usar essa biblioteca no momento da execução.
Para ativar a compatibilidade com essas APIs de linguagem, inclua o seguinte no arquivo build.gradle
do módulo
do app:
Groovy
android { defaultConfig { // Required when setting minSdkVersion to 20 or lower multiDexEnabled true } compileOptions { // Flag to enable support for the new language APIs coreLibraryDesugaringEnabled true // Sets Java compatibility to Java 8 sourceCompatibility JavaVersion.VERSION_1_8 targetCompatibility JavaVersion.VERSION_1_8 } } dependencies { coreLibraryDesugaring 'com.android.tools:desugar_jdk_libs:1.0.4' }
Kotlin
android { defaultConfig { // Required when setting minSdkVersion to 20 or lower multiDexEnabled = true } compileOptions { // Flag to enable support for the new language APIs isCoreLibraryDesugaringEnabled = true // Sets Java compatibility to Java 8 sourceCompatibility = JavaVersion.VERSION_1_8 targetCompatibility = JavaVersion.VERSION_1_8 } } dependencies { coreLibraryDesugaring("com.android.tools:desugar_jdk_libs:1.0.4") }
Também pode ser necessário incluir o snippet de código acima em um arquivo build.gradle
do módulo
da biblioteca se:
os testes de instrumentação do módulo da biblioteca usam essas APIs de linguagem, seja diretamente, pelo módulo da biblioteca ou pelas dependências dele. Dessa forma, as APIs que não estiverem presentes serão fornecidas para o APK de teste de instrumentação;
você quer executar o lint no módulo da biblioteca de forma isolada. O objetivo é ajudar o lint a reconhecer usos válidos das APIs de linguagem e evitar avisos falsos.
Novas opções para ativar ou desativar recursos de build
O Plug-in do Android para Gradle 4.0.0 introduz uma nova maneira de controlar quais recursos
de build você quer ativar e desativar, como a vinculação de visualizações e a vinculação de dados. Quando novos recursos são adicionados, eles ficam desativados por padrão. Você pode
usar o bloco buildFeatures
para ativar apenas os recursos que quiser, e isso
ajuda a otimizar o desempenho do build do projeto. Você pode definir
as opções para cada módulo no arquivo build.gradle
do módulo da seguinte maneira:
Groovy
android { // The default value for each feature is shown below. You can change the value to // override the default behavior. buildFeatures { // Determines whether to generate a BuildConfig class. buildConfig = true // Determines whether to support View Binding. // Note that the viewBinding.enabled property is now deprecated. viewBinding = false // Determines whether to support Data Binding. // Note that the dataBinding.enabled property is now deprecated. dataBinding = false // Determines whether to generate binder classes for your AIDL files. aidl = true // Determines whether to support RenderScript. renderScript = true // Determines whether to support injecting custom variables into the module’s R class. resValues = true // Determines whether to support shader AOT compilation. shaders = true } }
Kotlin
android { // The default value for each feature is shown below. You can change the value to // override the default behavior. buildFeatures { // Determines whether to generate a BuildConfig class. buildConfig = true // Determines whether to support View Binding. // Note that the viewBinding.enabled property is now deprecated. viewBinding = false // Determines whether to support Data Binding. // Note that the dataBinding.enabled property is now deprecated. dataBinding = false // Determines whether to generate binder classes for your AIDL files. aidl = true // Determines whether to support RenderScript. renderScript = true // Determines whether to support injecting custom variables into the module’s R class. resValues = true // Determines whether to support shader AOT compilation. shaders = true } }
Também pode especificar a configuração padrão para esses recursos em todos os módulos
de um projeto incluindo uma ou mais das seguintes opções no arquivo
gradle.properties
do seu projeto, como mostrado abaixo. Lembre-se de que também é possível usar o bloco
buildFeatures
no arquivo build.gradle
de cada módulo para substituir essas
configurações padrão do projeto.
android.defaults.buildfeatures.buildconfig=true
android.defaults.buildfeatures.aidl=true
android.defaults.buildfeatures.renderscript=true
android.defaults.buildfeatures.resvalues=true
android.defaults.buildfeatures.shaders=true
Dependências de recurso sobre recurso
Nas versões anteriores do Plug-in do Android para Gradle, todos os módulos
de recursos podiam depender apenas do módulo base do app. Ao usar o Plug-in do Android para Gradle
4.0.0, você pode incluir um módulo de recurso que dependa de outro módulo
de recurso. Ou seja, um recurso :video
pode depender do recurso :camera
, que
depende do módulo base, como mostrado na figura abaixo.
O módulo de recurso :video
depende do recurso
:camera
, que depende do módulo base :app
.
Isso significa que, quando o app solicita o download de um módulo de recurso, ele também faz o
download de outros módulos de recursos de que depende. Depois de criar
módulos de recursos
para seu app, você pode declarar uma dependência de recursos no arquivo
build.gradle
do módulo. Por exemplo, o módulo :video
declara uma dependência de
:camera
da seguinte maneira:
Groovy
// In the build.gradle file of the ':video' module. dependencies { // All feature modules must declare a dependency // on the base module. implementation project(':app') // Declares that this module also depends on the 'camera' // feature module. implementation project(':camera') ... }
Kotlin
// In the build.gradle file of the ':video' module. dependencies { // All feature modules must declare a dependency // on the base module. implementation(project(":app")) // Declares that this module also depends on the 'camera' // feature module. implementation(project(":camera")) ... }
Além disso, ative o recurso de dependência de recurso sobre recurso no Android Studio (para oferecer suporte ao editar a configuração de execução, por exemplo) clicando em Help > Edit Custom VM Options na barra de menus e incluindo o seguinte:
-Drundebug.feature.on.feature=true
Metadados de dependências
Quando você cria seu app usando o Plug-in do Android para Gradle 4.0.0 e mais recente, o plug-in inclui metadados que descrevem as dependências compiladas no app. Durante o upload do app, o Play Console inspeciona esses metadados para oferecer os seguintes benefícios:
- Receber alertas de problemas conhecidos com os SDKs e as dependências que o app usa
- Receber feedback útil para resolver esses problemas
Os dados são compactados, criptografados por uma chave de assinatura do Google Play e armazenados no
bloco de assinatura do app de lançamento. No entanto, você pode inspecionar os metadados
por conta própria nos arquivos de build intermediários locais no seguinte diretório:
<project>/<module>/build/outputs/sdk-dependencies/release/sdkDependency.txt
.
Se você preferir não compartilhar essas informações, desative isso incluindo o
seguinte no arquivo build.gradle
do módulo:
Groovy
android { dependenciesInfo { // Disables dependency metadata when building APKs. includeInApk = false // Disables dependency metadata when building Android App Bundles. includeInBundle = false } }
Kotlin
android { dependenciesInfo { // Disables dependency metadata when building APKs. includeInApk = false // Disables dependency metadata when building Android App Bundles. includeInBundle = false } }
Importar bibliotecas nativas das dependências de AAR
Agora você pode importar bibliotecas C/C++ das dependências de AAR do app. Quando você segue as etapas de configuração descritas abaixo, o Gradle disponibiliza automaticamente essas bibliotecas nativas para uso com o sistema de compilação nativo externo, como o CMake. O Gradle apenas disponibiliza essas bibliotecas para o build. Você ainda precisa configurar os scripts de build para que elas possam ser usadas.
As bibliotecas são exportadas usando o formato de pacote Prefab (link em inglês).
Cada dependência pode expor, no máximo, um pacote Prefab, que compreende um ou mais módulos. Um módulo Prefab é uma biblioteca única, que pode ser compartilhada, estática ou apenas de cabeçalho.
Normalmente, o nome do pacote corresponde ao nome do artefato Maven, e o nome do módulo corresponde ao nome da biblioteca, mas nem sempre isso ocorre. Como você precisa saber o nome do pacote e do módulo das bibliotecas, talvez seja necessário consultar a documentação da dependência para determiná-los.
Configurar o sistema de compilação nativo externo
Para ver as etapas a serem seguidas, clique no sistema de compilação nativo externo que você pretende usar.
As dependências nativas incluídas em um AAR são expostas ao projeto do CMake pela variável CMAKE_FIND_ROOT_PATH. Esse valor será definido automaticamente pelo Gradle quando o CMake for invocado. Portanto, se o sistema de compilação modificar essa variável, anexe-a em vez de atribuí-la.
Cada dependência expõe um pacote config-file ao build do CMake, que é
importado com o comando find_package
. Esse comando procura por pacotes config-file
que correspondam ao nome do pacote e da versão fornecidos e expõe os destinos que ele
define para serem usados no build. Por exemplo, se o aplicativo definir
libapp.so
e usar curl, inclua o seguinte no arquivo
CMakeLists.txt
:
add_library(app SHARED app.cpp)
# Add these two lines.
find_package(curl REQUIRED CONFIG)
target_link_libraries(app curl::curl)
Agora, você pode especificar #include "curl/curl.h"
em app.cpp
. Quando você cria seu
projeto, o sistema de compilação nativo externo vincula automaticamente libapp.so
a libcurl.so
e pacotes libcurl.so
no APK ou no pacote de apps. Para
ver mais informações, consulte a amostra de curl prefab.
Mudanças de comportamento
Ao usar esta versão do plug-in, você pode encontrar as seguintes mudanças no comportamento.
Atualizações da configuração de assinatura v1/v2
O comportamento das configurações de assinatura de apps no bloco signingConfig
foi
mudado para o seguinte:
Assinatura v1
- Se
v1SigningEnabled
for explicitamente ativada, o AGP realizará a assinatura de apps v1. - Se
v1SigningEnabled
for explicitamente desativada pelo usuário, a assinatura de apps v1 não será realizada. - Se o usuário não tiver ativado a assinatura v1, explicitamente, ela poderá ser desativada
automaticamente com base em
minSdk
etargetSdk
.
Assinatura v2
- Se
v2SigningEnabled
for explicitamente ativada, o AGP realizará a assinatura de apps v2. - Se
v2SigningEnabled
for explicitamente desativada pelo usuário, a assinatura de apps v2 não será realizada. - Se o usuário não tiver ativado a assinatura v2 explicitamente, ela poderá ser desativada
automaticamente com base em
targetSdk
.
Essas mudanças permitem que o AGP otimize builds desativando o mecanismo de assinatura
com base em se o usuário ativou explicitamente ou não essas sinalizações. Antes dessa
versão, era possível que v1Signing
fosse desativada mesmo quando explicitamente
ativada, o que poderia ser confuso.
Os Plug-ins do Android para Gradle feature
e instantapp
foram removidos
O Plug-in do Android para Gradle 3.6.0 descontinuou os plug-ins Feature
(com.android.feature
) e Instant App (com.android.instantapp
) e os
substituiu pelo plug-in Dynamic Feature (com.android.dynamic-feature
) para
criar e empacotar apps instantâneos usando Android App
Bundles.
No Plug-in do Android para Gradle 4.0.0 e versões mais recentes, esses plug-ins descontinuados foram totalmente removidos. Para usar o Plug-in do Android para Gradle mais recente, você precisa migrar seu app instantâneo para o Android App Bundles. Ao migrar seus apps instantâneos, você pode aproveitar os benefícios dos pacotes de apps e simplificar o design modular do app.
O recurso separado de processamento de anotações foi removido
A possibilidade de separar o processamento de anotações em uma tarefa dedicada foi
removida. Essa opção era usada para manter
a compilação Java incremental quando processadores de anotações não incrementais eram
usados em projetos somente Java. A opção era ativada configurando
android.enableSeparateAnnotationProcessing
como true
no arquivo
gradle.properties
, o que não funciona mais.
Em vez disso, você precisa migrar para usar processadores de anotações incrementais e melhorar a performance de build.
O uso de includeCompileClasspath foi descontinuado
O Plug-in do Android para Gradle não confere mais nem inclui processadores de anotações
declarados no caminho de classe de compilação, e a
propriedade DSL annotationProcessorOptions.includeCompileClasspath
não tem
mais efeito. Se você incluir processadores de anotações no caminho de classe de compilação, poderá
encontrar o seguinte erro:
Error: Annotation processors must be explicitly declared now.
Para resolver esse problema, é preciso incluir processadores de anotações nos arquivos
build.gradle
usando a configuração de dependência annotationProcessor
.
Para saber mais, leia Adicionar processadores
de anotações.
Empacotamento automático de dependências pré-criadas usadas pelo CMake
As versões anteriores do Plug-in do Android para Gradle exigiam o empacotamento explícito
de quaisquer bibliotecas pré-criadas usadas pelo build nativo externo do CMake usando
jniLibs
. Você pode ter bibliotecas no diretório src/main/jniLibs
do seu
módulo ou possivelmente em outro diretório configurado no arquivo
build.gradle
:
Groovy
sourceSets { main { // The libs directory contains prebuilt libraries that are used by the // app's library defined in CMakeLists.txt via an IMPORTED target. jniLibs.srcDirs = ['libs'] } }
Kotlin
sourceSets { main { // The libs directory contains prebuilt libraries that are used by the // app's library defined in CMakeLists.txt via an IMPORTED target. jniLibs.setSrcDirs(listOf("libs")) } }
Com o Plug-in do Android para Gradle 4.0, a configuração acima não é mais necessária e resultará em uma falha de build:
* What went wrong:
Execution failed for task ':app:mergeDebugNativeLibs'.
> A failure occurred while executing com.android.build.gradle.internal.tasks.Workers$ActionFacade
> More than one file was found with OS independent path 'lib/x86/libprebuilt.so'
O build nativo externo agora empacota automaticamente essas
bibliotecas. Portanto, empacotar explicitamente a biblioteca com jniLibs
resulta em uma
cópia. Para evitar o erro de build, mova a biblioteca pré-criada para um local
fora de jniLibs
ou remova a configuração jniLibs
do seu arquivo
build.gradle
.
Problemas conhecidos
Esta seção descreve problemas conhecidos que existem no Plug-in do Android para Gradle 4.0.0.
Disputa no mecanismo de worker do Gradle
Mudanças no Plug-in do Android para Gradle 4.0 podem acionar uma disputa no Gradle
ao ser executado com --no-daemon
e versões do Gradle 6.3 ou anteriores, fazendo
que os builds travem após o término da criação.
Esse problema será corrigido no Gradle 6.4.
3.6.0 (fevereiro de 2020)
Esta versão do plug-in do Android requer o seguinte:
Gradle 5.6.4. Para saber mais, leia a seção sobre a atualização do Gradle.
SDK Build Tools 28.0.3 ou versões mais recentes.
Esta atualização secundária é compatível com novas configurações e recursos padrão para visibilidade do pacote no Android 11.
Consulte as notas da versão 4.0.1 para saber mais detalhes.
Novos recursos
Esta versão do Plug-in do Android para Gradle inclui os novos recursos a seguir.
Vinculação de visualizações
A vinculação de visualizações fornece segurança no momento da compilação quando há referências a visualizações no código.
Agora você pode substituir findViewById()
pela referência
de classe de vinculação gerada automaticamente. Para começar a usar a vinculação de visualizações, inclua o seguinte no arquivo
build.gradle
de cada módulo:
Groovy
android { viewBinding.enabled = true }
Kotlin
android { viewBinding.enabled = true }
Para saber mais, leia a documentação de Vinculação de visualizações.
Compatibilidade com o plug-in Maven Publish
O Plug-in do Android para Gradle inclui compatibilidade com o plug-in Maven Publish para Gradle, que permite a publicação de artefatos de build em um repositório Apache Maven. O Plug-in do Android para Gradle cria um componente para cada artefato de variante de build no módulo do aplicativo ou da biblioteca usado para personalizar uma publicação para um repositório Maven (links em inglês).
Para saber mais, acesse a página sobre como usar o plug-in Maven Publish.
Nova ferramenta de empacotamento padrão
Ao criar a versão de depuração do app, o plug-in usa uma nova
ferramenta de empacotamento, chamada zipflinger, para criar o APK. Essa nova ferramenta trará
melhorias de velocidade de build. Se a nova ferramenta de empacotamento não funcionar como
esperado, informe um bug. Você pode voltar a usar a
ferramenta de empacotamento antiga incluindo o seguinte no arquivo gradle.properties
:
android.useNewApkCreator=false
Atribuição do build nativo
Agora é possível determinar o tempo que o Clang leva para criar e vincular cada arquivo C/C ++ no seu projeto. O Gradle pode gerar um trace do Chrome que contém carimbos de data/hora para esses eventos do compilador para que você possa analisar o tempo necessário para criar seu projeto. Para gerar esse arquivo de atribuição de build, faça o seguinte:
Adicione a sinalização
-Pandroid.enableProfileJson=true
ao gerar uma versão do Gradle. Por exemplo:gradlew assembleDebug -Pandroid.enableProfileJson=true
Abra o navegador Chrome e digite
chrome://tracing
na barra de pesquisa.Clique no botão Load e navegue até
project-root/build/android-profile
para encontrar o arquivo. O nome do arquivo éprofile-timestamp.json.gz
.
Você pode ver os dados de atribuição da versão nativa perto da parte superior do visualizador:
Mudanças de comportamento
Ao usar esta versão do plug-in, você pode encontrar as seguintes mudanças no comportamento.
Bibliotecas nativas empacotadas descompactadas por padrão
Quando você cria seu app, o plug-in agora define extractNativeLibs
como "false"
por
padrão. Ou seja, suas bibliotecas nativas são alinhadas na página e empacotadas
sem compactação. Apesar de isso gerar um tamanho do upload maior, seus usuários
se beneficiam pelos seguintes motivos:
- O tamanho de instalação do app é menor porque a plataforma pode acessar as bibliotecas nativas diretamente do APK instalado, sem criar uma cópia das bibliotecas.
- O tamanho de download é menor, porque a compactação da Play Store geralmente é melhor quando você inclui bibliotecas nativas não compactadas no seu APK ou Android App Bundle.
Se, em vez disso, você quiser que o Plug-in do Android para Gradle empacote bibliotecas nativas compactadas, inclua o seguinte no manifesto do app:
<application
android:extractNativeLibs="true"
... >
</application>
Versão padrão do NDK
Se você fizer o download de várias versões do NDK, o Plug-in do Android para Gradle agora
selecionará uma versão padrão para compilar seus arquivos de código-fonte. Antes,
o plug-in selecionava a versão mais recente do NDK transferida por download. Use a propriedade
android.ndkVersion
no arquivo build.gradle
do módulo para substituir
o padrão selecionado pelo plug-in.
Geração de classe R simplificada
O Plug-in do Android para Gradle simplifica o caminho de classe de compilação gerando apenas uma classe R para cada módulo de biblioteca no projeto e compartilhando essas classes R com outras dependências do módulo. Essa otimização proporcionará builds mais rápidos, mas exige que você tenha em mente o seguinte:
- Como o compilador compartilha classes R com dependências de módulo upstream, é importante que cada módulo do projeto use um nome de pacote exclusivo.
- A visibilidade da classe R de uma biblioteca para outras dependências do projeto é
determinada pela configuração usada para incluir a biblioteca como dependência.
Por exemplo, se a Biblioteca A incluir a Biblioteca B como uma dependência "API", a Biblioteca
A e outras bibliotecas que dependem dela terão acesso à classe
R da Biblioteca B. No entanto, outras bibliotecas podem não ter acesso à classe R da Biblioteca B
se a Biblioteca A usar a configuração de dependência
implementation
. Para saber mais, leia sobre as configurações de dependência.
Remover recursos ausentes da configuração padrão
Para módulos de Biblioteca, se você incluir um recurso para um idioma que não
incluiu no conjunto padrão de recursos (por exemplo, se você incluir
hello_world
como um recurso de string em /values-es/strings.xml
, mas não
definir esse recurso em /values/strings.xml
), o Plug-in do Android para Gradle não
incluirá mais esse recurso ao compilar seu projeto. Essa mudança de comportamento
resulta em menos exceções de tempo de execução Resource Not Found
e maior
velocidade de compilação.
O D8 agora respeita a política de retenção de classe para anotações
Ao compilar seu app, o D8 agora respeita quando as anotações aplicam uma política de retenção CLASS, e essas anotações não estão mais disponíveis no ambiente de execução. Esse comportamento também existe ao definir o SDK de destino do app para o nível 23 da API, que anteriormente permitia acessar essas anotações durante o tempo de execução ao compilar o app usando versões mais antigas do Plug-in do Android para Gradle e do D8.
Outras mudanças de comportamento
aaptOptions.noCompress
não diferencia mais caracteres maiúsculos de minúsculos em todas as plataformas (para APK e pacotes) e respeita caminhos que usam caracteres maiúsculos.- A vinculação de dados agora é incremental por padrão. Para saber mais, consulte o problema 110061530.
- Todos os testes de unidade, incluindo testes de unidade roboelétricos, agora podem ser totalmente armazenados em cache. Para saber mais, consulte o problema #115873047.
Correções de bugs
Esta versão do Plug-in do Android para Gradle inclui as seguintes correções de bugs:
- Agora, os testes de unidade robolétricos são compatíveis com módulos de biblioteca que usam vinculação de dados. Para saber mais, consulte o problema 126775542.
- Agora é possível executar tarefas
connectedAndroidTest
em vários módulos enquanto o modo de execução paralela do Gradle está ativado.
Problemas conhecidos
Esta seção descreve problemas conhecidos que existem no Plug-in do Android para Gradle 3.6.0.
Desempenho lento da tarefa Android Lint
O Android Lint pode levar muito mais tempo para ser concluído em alguns projetos devido a uma regressão na infraestrutura de análise, o que resulta em um cálculo mais lento de tipos de inferência para lambdas em determinadas construções de códigos.
O problema é relatado como um bug no IDEA e será corrigido no Plug-in do Android para Gradle 4.0.
Falta a classe do manifesto
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 tempo de execução.
A geração da classe de manifesto está corrompida no Plug-in do Android para Gradle 3.6.0. Se você
criar seu app com essa versão do plug-in e fizer referência à classe
de manifesto, talvez veja uma exceção ClassNotFoundException
. Para resolver esse
problema, execute 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"; } }
3.5.0 (agosto de 2019)
O Plug-in do Android para Gradle 3.5.0, assim como o Android Studio 3.5, é um lançamento importante do Project Marble. O objetivo desse projeto é melhorar três áreas principais das ferramentas para desenvolvedores Android: a integridade do sistema, o aperfeiçoamento de recursos e a correção de bugs. No caso específico dessa atualização, o foco foi melhorar a velocidade de build do projeto (link em inglês).
Para ver mais informações sobre essas e outras atualizações do Project Marble, leia a postagem no Blog de desenvolvedores Android (link em inglês) ou as seções abaixo.
Esta versão do plug-in do Android requer o seguinte:
Gradle 5.4.1. Para saber mais, leia a seção sobre a atualização do Gradle.
SDK Build Tools 28.0.3 ou versões mais recentes.
Esta atualização secundária é compatível com novas configurações e recursos padrão para visibilidade do pacote no Android 11.
Consulte as notas da versão 4.0.1 para saber mais detalhes.
3.5.3 (dezembro de 2019)
Esta pequena atualização é compatível com o Android Studio 3.5.3 e inclui várias correções de bugs e melhorias no desempenho.
3.5.2 (novembro de 2019)
Esta atualização secundária oferece suporte ao Android Studio 3.5.2 e inclui várias correções de bugs e melhorias de performance. Para ver uma lista das principais correções de bugs, leia a postagem relacionada no blog de atualizações de versão (link em inglês).
3.5.1 (outubro de 2019)
Esta atualização secundária oferece suporte ao Android Studio 3.5.1 e inclui várias correções de bugs e melhorias de performance. Para ver uma lista das principais correções de bugs, leia a postagem relacionada no blog de atualizações de versão (link em inglês).
Processamento incremental de anotações
O processador
de anotações da Vinculação de dados vai oferecer suporte ao processamento
incremental de anotações
(link em inglês) se você definir android.databinding.incremental=true
no arquivo gradle.properties
. Essa otimização resulta em melhor
desempenho de build incremental. Para ver uma lista completa de processadores
de anotações otimizados, consulte a tabela de processadores
de anotações incrementais (link em inglês).
Além disso, o KAPT 1.3.30 e versões mais recentes também são compatíveis com processadores
de anotações incrementais, que podem ser ativados incluindo kapt.incremental.apt=true
no
seu arquivo gradle.properties
.
Testes de unidade armazenáveis em cache
Quando você ativa testes de unidade para usar recursos e manifestos Android
configurando includeAndroidResources
como true
, o Plug-in do Android para Gradle gera um arquivo de configuração
de teste com caminhos absolutos, o que interrompe a realocação do cache. Em vez disso, você pode instruir
o plug-in para gerar a configuração de teste usando caminhos relativos, o que
permite que a tarefa AndroidUnitTest
seja totalmente armazenada em cache, pela inclusão do
seguinte no arquivo gradle.properties
:
android.testConfig.useRelativePath = true
Problemas conhecidos
Quando você usa o plug-in do Kotlin para Gradle 1.3.31 ou uma versão anterior, o seguinte aviso pode ser exibido ao criar ou sincronizar seu projeto:
WARNING: API 'variant.getPackageLibrary()' is obsolete and has been replaced with 'variant.getPackageLibraryProvider()'.
Para resolver esse problema, atualize o plug-in para a versão 1.3.40 ou mais recente.
3.4.0 (abril de 2019)
Esta versão do plug-in do Android requer o seguinte:
Gradle 5.1.1 (link em inglês) ou uma versão mais recente. Para saber mais, leia a seção sobre a atualização do Gradle.
SDK Build Tools 28.0.3 ou versões mais recentes.
Esta atualização secundária é compatível com novas configurações e recursos padrão para visibilidade do pacote no Android 11.
Consulte as notas da versão 4.0.1 para saber mais detalhes.
3.4.2 (julho de 2019)
Esta atualização secundária oferece suporte ao Android Studio 3.4.2 e inclui várias correções de bugs e melhorias de performance. Para ver uma lista das principais correções de bugs, leia a postagem relacionada no blog de atualizações de versão (link em inglês).
3.4.1 (maio de 2019)
Esta atualização secundária oferece suporte ao Android Studio 3.4.1 e inclui várias correções de bugs e melhorias de performance. Para ver uma lista das principais correções de bugs, leia a postagem relacionada no blog de atualizações de versão (link em inglês).
Novos recursos
Novas configurações de dependência de verificação de lint: o comportamento de
lintChecks
mudou, e uma nova configuração de dependência (lintPublish
) foi introduzida para oferecer mais controle sobre as verificações de lint que são empacotadas nas bibliotecas do Android.lintChecks
: esta é uma configuração existente necessária para verificações de lint que você queira executar somente ao criar seu projeto localmente. Se você estava usando a configuração de dependêncialintChecks
anteriormente para incluir verificações de lint no AAR publicado, precisará migrar essas dependências para usar a nova configuraçãolintPublish
descrita abaixo.lintPublish
: use esta nova configuração em projetos de biblioteca para verificações de lint que você queira incluir no AAR publicado, conforme mostrado abaixo. Isso significa que os projetos que consomem sua biblioteca também aplicam essas verificações de lint.
A amostra de código a seguir usa as duas configurações de dependência em um projeto de biblioteca local do Android.
Groovy
dependencies { // Executes lint checks from the ':lint' project at build time. lintChecks project(':lint') // Packages lint checks from the ':lintpublish' in the published AAR. lintPublish project(':lintpublish') }
Kotlin
dependencies { // Executes lint checks from the ':lint' project at build time. lintChecks(project(":lint")) // Packages lint checks from the ':lintpublish' in the published AAR. lintPublish(project(":lintpublish")) }
Em geral, as tarefas de empacotamento e assinatura terão uma melhoria geral na velocidade de build. Se você perceber uma regressão de desempenho relacionada a essas tarefas, informe um bug.
Mudanças de comportamento
Aviso de descontinuação do plug-in Instant Apps Android Feature: se você ainda estiver usando o plug-in
com.android.feature
para criar seu app instantâneo, o Plug-in do Android para Gradle 3.4.0 vai mostrar um aviso de descontinuação. Para garantir que seja possível criar seu app instantâneo em versões futuras do plug-in, migre-o para o plug-in de recurso dinâmico, que também permite a publicação das suas experiências de apps instalados e instantâneos de um único Android App Bundle.R8 ativado por padrão: o R8 integra a simplificação, redução, ofuscação, otimização e dexação em uma única etapa, o que resulta em melhorias significativas no desempenho do build (link em inglês). O R8 foi introduzido no Plug-in do Android para Gradle 3.3.0 e agora está ativado por padrão para os projetos de biblioteca Android e apps usando o plug-in 3.4.0 ou mais recente.
A imagem abaixo fornece uma visão geral de alto nível do processo de compilação antes da introdução do R8.
Agora, com o R8, a simplificação, redução, ofuscação, otimização e dexação (D8) são todas concluídas em uma única etapa, conforme ilustrado abaixo.
Lembre-se de que o R8 foi projetado para funcionar com suas regras do ProGuard. Desse modo, você provavelmente não precisará fazer nada para se beneficiar do R8. No entanto, como essa é uma tecnologia diferente do ProGuard e é projetada especificamente para projetos Android, a redução e a otimização podem resultar na remoção de códigos que o ProGuard talvez não removesse. Nessa situação improvável, talvez seja necessário adicionar outras regras para manter esse código no resultado de build.
Se você tiver problemas ao usar o R8, leia as Perguntas frequentes de compatibilidade do R8 (link em inglês) para conferir se há uma solução. Se nenhuma solução tiver sido documentada, informe um bug. Você pode desativar o R8 adicionando uma das seguintes linhas ao arquivo
gradle.properties
do projeto:# Disables R8 for Android Library modules only. android.enableR8.libraries = false # Disables R8 for all modules. android.enableR8 = false
O uso de
ndkCompile
foi descontinuado: agora você vai encontrar um erro de build se tentar usar ondkBuild
para compilar bibliotecas nativas. Em vez disso, use o CMake ou o ndk-build para adicionar código C e C++ ao seu projeto.
Problemas conhecidos
O uso correto de nomes de pacotes únicos não é obrigatório atualmente, mas se tornará mais rigoroso em versões mais recentes do plug-in. No Plug-in do Android para Gradle versão 3.4.0, você pode verificar se o projeto declara nomes de pacotes aceitáveis adicionando a linha abaixo ao seu arquivo
gradle.properties
.android.uniquePackageNames = true
Para saber mais sobre como definir um nome de pacote com o Plug-in do Android para Gradle, consulte Definir o ID do aplicativo.
3.3.0 (janeiro de 2019)
Esta versão do plug-in do Android requer o seguinte:
Gradle 4.10.1 (link em inglês) ou versões mais recentes. Para saber mais, leia a seção sobre a atualização do Gradle.
SDK Build Tools 28.0.3 ou versões mais recentes.
Esta atualização secundária é compatível com novas configurações e recursos padrão para visibilidade do pacote no Android 11.
Consulte as notas da versão 4.0.1 para saber mais detalhes.
3.3.2 (março de 2019)
Esta atualização secundária oferece suporte ao Android Studio 3.3.2 e inclui várias correções de bugs e melhorias de performance. Para ver uma lista das principais correções de bugs, leia a postagem relacionada no blog de atualizações de versão (link em inglês).
3.3.1 (fevereiro de 2019)
Esta atualização pequena é compatível com o Android Studio 3.3.1 e inclui várias correções de bugs e melhorias no desempenho.
Novos recursos
Melhoria na sincronização de caminho de classe: ao resolver dependências nos seus caminhos de classe de ambiente de execução e tempo de compilação, o Plug-in do Android para Gradle tenta corrigir alguns conflitos de versão para dependências em vários caminhos de classe.
Por exemplo, se o caminho de classe do tempo de execução incluir a Biblioteca A versão 2.0 e o de compilação incluir a Biblioteca A versão 1.0, o plug-in atualizará automaticamente a dependência do caminho de classe de compilação para a Biblioteca A versão 2.0 para evitar erros.
No entanto, se o caminho de classe de execução incluir a Biblioteca A versão 1.0 e a compilação incluir a Biblioteca A versão 2.0, o plug-in não vai fazer downgrade da dependência do caminho de classe de compilação para a Biblioteca A versão 1.0 e isso gera um erro. Para saber mais, consulte Corrigir conflitos entre caminhos de classe
Melhoria na compilação Java incremental ao usar processadores de anotações: esta atualização diminui o tempo de compilação porque melhora o suporte à compilação Java incremental quando usada com processadores de anotações.
- Para projetos que usam o Kapt (a maioria dos projetos somente em Kotlin e dos projetos híbridos em Kotlin-Java): a compilação incremental em Java é ativada, mesmo quando você usa a vinculação de dados ou o plug-in retro-lambda. O processamento de anotações pela tarefa do Kapt ainda não é incremental.
Para projetos que não usam o Kapt (projetos somente em Java): se os processadores de anotações que você usa oferecerem suporte ao processamento incremental de anotações (link em inglês), a compilação Java incremental vai ser ativada por padrão. Para monitorar a adoção do processador de anotações incremental, veja o problema 5277 do Gradle (link em inglês).
Entretanto, se um ou mais processadores de anotações não forem compatíveis com builds incrementais, a compilação incremental em Java não será ativada. Em vez disso, você pode incluir a seguinte sinalização no seu arquivo
gradle.properties
:android.enableSeparateAnnotationProcessing=true
Ao incluir essa sinalização, o Plug-in do Android para Gradle executa os processadores de anotações em uma tarefa separada e permite que as tarefas de compilação em Java sejam executadas de forma incremental.
Informações de depuração melhores ao usar uma API obsoleta: quando o plug-in detecta que você está usando uma API que não é mais compatível, agora ele pode fornecer informações mais detalhadas para ajudar a determinar onde essa API está sendo usada. Para ver outras informações, você precisa incluir o seguinte no arquivo
gradle.properties
do seu projeto:android.debug.obsoleteApi=true
Também é possível ativar a sinalização transmitindo
-Pandroid.debug.obsoleteApi=true
na linha de comando.Você pode executar testes de instrumentação em módulos de recursos da linha de comando.
Mudanças de comportamento
Configuração lenta de tarefas: agora, o plug-in usa a nova API de criação de tarefas do Gradle (link em inglês) para evitar a inicialização e a configuração de tarefas que não são necessárias para concluir a versão atual (ou tarefas que não estejam no gráfico de tarefas em execução). Por exemplo, se você tiver diversas variantes de compilação, como "release" e "debug", e estiver criando a versão "debug" do seu app, o plug-in evitará inicializar e configurar tarefas para a versão "release" do app.
Chamar alguns métodos antigos na API Variants, como
variant.getJavaCompile()
, ainda poderá forçar a configuração da tarefa. Para garantir que sua versão seja otimizada para a configuração lenta de tarefas, invoque novos métodos que retornem um objetoTaskProvider
, comovariant.getJavaCompileProvider()
.Se você executa tarefas personalizadas de build, aprenda a adaptar-se à nova API de criação de tarefas do Gradle (link em inglês).
Para um determinado tipo de build, ao configurar
useProguard false
, o plug-in agora vai usar o R8 em vez do ProGuard para reduzir e ofuscar o código e os recursos do app. Para saber mais sobre o R8, leia esta postagem do blog (link em inglês) para desenvolvedores Android.Geração de classe R mais rápida para projetos de biblioteca: anteriormente, o Plug-in do Android para Gradle gerava um arquivo
R.java
para cada uma das dependências do projeto e compilava essas classes R junto com as outras classes do app. O plug-in agora gera diretamente um JAR que contém a classe R compilada do seu app, sem criar classesR.java
intermediárias antes. Essa otimização pode melhorar significativamente o desempenho do build para projetos que incluem muitos subprojetos e dependências de biblioteca, além de melhorar a velocidade de indexação no Android Studio.Ao criar um Android App Bundle, os APKs gerados desse pacote de apps destinado ao Android 6.0 (nível 23 da API) ou versões mais recentes agora incluem versões descompactadas das suas bibliotecas nativas por padrão. Essa otimização evita que o dispositivo tenha que fazer uma cópia da biblioteca e, assim, reduz o tamanho do app no disco. Se você preferir desativar essa otimização, adicione o seguinte ao arquivo
gradle.properties
:android.bundle.enableUncompressedNativeLibs = false
O plug-in aplica versões mínimas de alguns plug-ins de terceiros.
Sincronização de projeto de variante única: sincronizar seu projeto com a configuração da compilação é uma etapa importante para permitir que o Android Studio entenda como o projeto está estruturado. No entanto, esse processo pode levar muito tempo em projetos grandes. Caso seu projeto use diversas variantes de compilação, agora você pode otimizar as sincronizações dele limitando-as apenas à variante selecionada no momento.
Para ativar essa otimização, é necessário usar o Android Studio 3.3 ou mais recente com o Plug-in do Android para Gradle 3.3.0 ou mais recente. Quando você atende a esses requisitos, o ambiente de desenvolvimento integrado solicita que você ative essa otimização ao sincronizar seu projeto. A otimização também é ativada por padrão em novos projetos.
Para ativar essa otimização manualmente, clique em File > Settings > Experimental > Gradle (Android Studio > Preferences > Experimental > Gradle em um Mac) e marque a caixa de seleção Only sync the active variant.
Observação: essa otimização oferece suporte total a projetos que incluem as linguagens Java e C++ e suporte parcial para Kotlin. Ao ativar a otimização para projetos com conteúdo em Kotlin, a sincronização do Gradle volta a usar variantes completas internamente.
Download automático de pacotes SDK ausentes: essa funcionalidade foi expandida para oferecer compatibilidade com o NDK. Para saber mais, leia Download automático de pacotes ausentes com o Gradle.
Correções de bugs
O Plug-in do Android para Gradle 3.3.0 corrige os seguintes problemas:
- O processo de compilação chama
android.support.v8.renderscript.RenderScript
em vez da versão do AndroidX, mesmo que o Jetifier esteja ativado. - Conflitos causados porque o
androidx-rs.jar
inclui este elemento com empacotamento estáticoannotation.AnyRes
. - Ao usar o RenderScript, não será mais necessário definir manualmente a versão do
Build Tools nos arquivos
build.gradle
.
- O processo de compilação chama
3.2.0 (setembro de 2018)
Esta versão do plug-in do Android requer o seguinte:
- Gradle 4.6 (link em inglês) ou versões mais recentes. Para saber mais, leia a seção sobre como atualizar o Gradle.
- SDK Build Tools 28.0.3 ou versões mais recentes.
3.2.1 (outubro de 2018)
Com esta atualização, não será mais necessário especificar uma versão para o SDK Build Tools. O Plug-in do Android para Gradle agora usa a versão 28.0.3 por padrão.
Novos recursos
Compatibilidade com a criação de Android App Bundles: o pacote de apps é um novo formato de upload que inclui todo o código e recursos compilados do app, e adia a geração e a assinatura do APK para a Google Play Store. Não é mais necessário criar, assinar e gerenciar vários APKs, e os usuários recebem downloads menores, otimizados para o dispositivo deles. Para saber mais, leia Sobre os Android App Bundles.
Suporte a velocidades aprimoradas de build incremental ao usar processadores de anotações: a DSL
AnnotationProcessorOptions
agora estende a interfaceCommandLineArgumentProvider
, que permite que você ou o autor do processador de anotações anote argumentos para o processador usando anotações de tipos de propriedade de build incremental (links em inglês). O uso dessas anotações melhora a exatidão e o desempenho de builds limpos incrementais e em cache. Para saber mais, leia Transmitir argumentos para os processadores de anotações.Ferramenta de migração para o AndroidX: ao usar o Plug-in do Android para Gradle 3.2.0 com o Android 3.2 e versões mais recentes, você pode migrar as dependências locais e do Maven do seu projeto para que usem as novas bibliotecas AndroidX selecionando Refactor > Migrate to AndroidX na barra de menus. O uso dessa ferramenta de migração também configura as seguintes sinalizações como
true
no seu arquivogradle.properties
:android.useAndroidX
: quando configurado comotrue
, o plug-in do Android usa a biblioteca AndroidX apropriada em vez de uma biblioteca de suporte. Quando essa sinalização não é especificada, o plug-in a configura comofalse
por padrão.android.enableJetifier
: quando configurado comotrue
, o plug-in do Android migrará automaticamente as bibliotecas de terceiros existentes para usar o AndroidX reescrevendo os binários delas. Quando essa sinalização não é especificada, o plug-in a configura comofalse
por padrão. Você pode configurar essa sinalização comotrue
apenas quandoandroid.useAndroidX
também estiver configurado comotrue
. Caso contrário, ocorre um erro de build.
Para saber mais, leia a Visão geral do AndroidX.
Novo redutor de código, R8: o R8 é uma nova ferramenta de redução e ofuscação de código que substitui o ProGuard. Comece a usar a versão de pré-lançamento do R8 incluindo o seguinte no arquivo
gradle.properties
do seu projeto:Groovy
android.enableR8 = true
Kotlin
android.enableR8 = true
Mudanças de comportamento
- Agora, a simplificação de leitura com D8 é ativada por padrão.
O AAPT2 agora fica no repositório Maven do Google. Para usar o AAPT2, verifique se você tem a dependência do
google()
no seu arquivobuild.gradle
, conforme mostrado abaixo:Groovy
buildscript { repositories { google() // here jcenter() } dependencies { classpath 'com.android.tools.build:gradle:3.2.0' } } allprojects { repositories { google() // and here jcenter() }
Kotlin
buildscript { repositories { google() // here jcenter() } dependencies { classpath 'com.android.tools.build:gradle:3.2.0' } } allprojects { repositories { google() // and here jcenter() }
Agora, o multidex nativo é ativado por padrão. As versões anteriores do Android Studio ativavam o multidex nativo ao implantar a versão de depuração de um app em um dispositivo com o nível 21 da API do Android ou mais recente. Agora, independentemente de você estar implantando em um dispositivo ou criando um APK para a versão, o Plug-in do Android para Gradle ativará o multidex nativo para todos os módulos configurados como
minSdkVersion=21
ou mais recente.O plug-in agora aplica uma versão mínima dos plug-ins protobuf (0.8.6), Kotlin (1.2.50) e Crashlytics (1.25.4).
O plug-in de módulo de recurso,
com.android.feature
, agora aplica o uso exclusivo de letras, dígitos e sublinhados ao especificar um nome de módulo. Por exemplo, se o nome do módulo de recursos incluir traços, haverá um erro de build. Esse comportamento corresponde ao do plug-in de recursos dinâmicos.
Correções de bugs
- O JavaCompile agora pode ser armazenado em cache em projetos com vinculação de dados (problema 69243050).
- Melhor evasão de compilação para módulos de biblioteca com vinculação de dados (problema 77539932).
- Agora, você pode reativar a configuração sob demanda (link em inglês) caso tenha desativado em versões anteriores devido a alguns erros de build imprevisíveis (problema 77910727).
3.1.0 (março de 2018)
Esta versão do plug-in do Android requer o seguinte:
- Gradle 4.4 (link em inglês) ou versões mais recentes. Para saber mais, leia a seção sobre como atualizar o Gradle.
- Build Tools 27.0.3 ou versões mais recentes.
Lembre-se que não será mais necessário especificar uma versão para o Build
Tools usando a propriedade
android.buildToolsVersion
, porque o plug-in usa a versão mínima necessária por padrão.
Novo compilador DEX, D8
Por padrão, o Android Studio agora usa um novo compilador DEX
denominado D8. A compilação DEX é o processo de transformar bytecode .class
em bytecode .dex
para o Android Runtime (ou Dalvik, para versões
mais antigas do Android). Em comparação com o compilador anterior, denominado DX, o D8
compila mais rapidamente e gera arquivos DEX menores, com desempenho igual ou
melhor em relação ao tempo de execução do app.
O fluxo de trabalho cotidiano de desenvolvimento de apps não será alterado pelo D8. No entanto, se você
tiver algum problema relacionado ao novo compilador,
informe um bug. Para desativar temporariamente o D8 e
usar o DX, inclua o seguinte no arquivo gradle.properties
do seu projeto:
android.enableD8=false
Para projetos que
usam recursos da linguagem Java 8,
a simplificação incremental é ativada por padrão. Você pode desativá-la
especificando o seguinte no arquivo gradle.properties
do seu projeto:
android.enableIncrementalDesugaring=false.
Usuário da versão de pré-lançamento: se você já estiver usando uma versão de pré-lançamento do D8, observe que agora ele é compilado em bibliotecas incluídas no SDK Build Tools, não no JDK. Portanto, se você estiver acessando APIs existentes no JDK, mas não nas bibliotecas do SDK Build Tools, haverá um erro de compilação.
Mudanças de comportamento
Ao criar vários APKs voltados, cada um, para uma ABI diferente, o plug-in não gera mais APKs para as seguintes ABIs por padrão:
mips
,mips64
earmeabi
.Se você quiser criar APKs voltados para essas ABIs, será preciso usar o NDK r16b ou anterior e especificar as ABIs no arquivo
build.gradle
, como mostrado abaixo:
Groovy
splits { abi { include 'armeabi', 'mips', 'mips64' ... } }
Kotlin
splits { abi { include("armeabi", "mips", "mips64") ... } }
- O cache de compilação do plug-in do Android agora exibe entradas de cache com mais de 30 dias.
- Transmitir
"auto"
pararesConfig
não seleciona mais recursos de string automaticamente para empacotar no seu APK. Se você continuar usando"auto"
, o plug-in empacotará todos os recursos de string que seu app e as dependências dele fornecerem. Portanto, é necessário especificar cada localidade a ser empacotada pelo plug-in no seu APK. Como os módulos locais não podem depender do APK de teste do app, adicionar dependências aos seus testes instrumentados usando a configuração
androidTestApi
, em vez deandroidTestImplementation
, faz com que o Gradle emita o seguinte aviso:Groovy
WARNING: Configuration 'androidTestApi' is obsolete and has been replaced with 'androidTestImplementation'
Kotlin
WARNING: Configuration 'androidTestApi' is obsolete and has been replaced with 'androidTestImplementation'
Correções
- Correção de um problema em que o Android Studio não reconhecia dependências em builds compostos.
- Correção de um problema em que havia um erro de sincronização do projeto ao carregar o plug-in do Android várias vezes em um único build. Por exemplo, quando vários subprojetos incluíam o plug-in do Android no caminho de classe do buildscript.
3.0.0 (outubro de 2017)
O Plug-in do Android para Gradle 3.0.0 inclui uma variedade de mudanças que buscam resolver problemas de desempenho em projetos grandes.
Por exemplo, em uma amostra de projeto esqueleto com aproximadamente 130 módulos e um grande número de dependências externas (mas nenhum código ou recursos), você pode ter melhorias de desempenho semelhantes às seguintes:
Versão do plug-in do Android + versão do Gradle | Plug-in do Android 2.2.0 + Gradle 2.14.1 | Plug-in do Android 2.3.0 + Gradle 3.3 | Plug-in do Android 3.0.0 + Gradle 4.1 |
---|---|---|---|
Configuração (por exemplo, executando ./gradlew --help ) |
Cerca de 2 min | Cerca de 9 s | Cerca de 2,5 s |
Alteração de 1 linha no Java (alteração de implementação) | Cerca de 2 min 15 s | Cerca de 29 s | Cerca de 6,4 s |
Algumas dessas alterações causam falha nas builds existentes. Portanto, você precisa considerar o esforço de migrar seu projeto antes de usar o novo plug-in.
Se você não perceber as melhorias de desempenho descritas acima, informe um bug e inclua um trace do seu build usando o Gradle Profiler (link em inglês).
Esta versão do plug-in do Android requer o seguinte:
- Gradle 4.1 (link em inglês) ou versões mais recentes. Para saber mais, leia a seção sobre como atualizar o Gradle.
- Build Tools 26.0.2 ou versões mais recentes.
Com esta atualização, não será mais necessário especificar uma versão para o Build
Tools. O plug-in usará a versão mínima necessária por padrão.
Então, agora você pode remover a propriedade
android.buildToolsVersion
.
3.0.1 (novembro de 2017)
Esta é uma atualização pequena para oferecer compatibilidade com o Android Studio 3.0.1 e inclui correções gerais de bugs e melhorias no desempenho.
Otimizações
- Melhor paralelismo para projetos com vários módulos com um gráfico de tarefas detalhado.
- Ao fazer mudanças na dependência, o Gradle cria mais rapidamente porque não recompila
módulos sem acesso à API dessa dependência. É necessário restringir quais dependências vazam APIs para outros módulos
usando as novas configurações de dependência do Gradle:
implementation
,api
,compileOnly
eruntimeOnly
. - Maior velocidade de build incremental devido à dexação por classe. Agora, cada classe é
compilada em arquivos DEX separados, e apenas as classes
modificadas são redexadas. Também vai haver aumento na velocidade de build de
apps que tenham definido a
minSdkVersion
como 20 ou menos e usem multi-dex legado. - Velocidades de build aumentadas pela otimização de algumas tarefas para usar as saídas armazenadas em cache. Para aproveitar essa otimização, ative o cache de build do Gradle (link em inglês).
- Melhoria do processamento de recursos incrementais usando AAPT2, que agora é ativado por
padrão.
Caso tenha problemas ao usar o AAPT2,
informe um bug. Você também pode desativar o AAPT2 configurando
android.enableAapt2=false
no seu arquivogradle.properties
e reiniciando o daemon Gradle executando./gradlew --stop
na linha de comando.
Novos recursos
- Gerenciamento de dependências com reconhecimento de variantes. Ao criar uma variante específica de um módulo, o plug-in agora faz a correspondência automática das variantes de dependências de módulo de biblioteca local com a variante do módulo que você está criando.
- Inclusão de um novo plug-in do módulo Feature para oferecer compatibilidade com Instant Apps Android e o SDK do Instant Apps Android (disponível para download usando o SDK Manager). Para saber mais sobre a criação de módulos Feature com o novo plug-in, leia Estrutura de um app instantâneo com vários recursos.
- Compatibilidade integrada com o uso de alguns recursos da linguagem Java 8 e respectivas bibliotecas. O Jack agora está obsoleto e não é mais necessário. Primeiro, é preciso desativar o Jack para usar a compatibilidade aprimorada com Java 8 integrada no conjunto de ferramentas padrão. Para mais informações, leia Usar recursos da linguagem Java 8.
- Compatibilidade com a execução de testes com o
Android Test Orchestrator,
que permite a execução de cada um dos testes do app na
própria invocação de
Instrumentation
. Como cada teste é executado na própria instância deInstrumentation
, nenhum estado compartilhado entre os testes se acumula na CPU ou na memória do dispositivo. Mesmo que um teste falhe, ele só removerá a própria instância deInstrumentation
. Portanto, seus outros testes ainda serão executados.- Inclusão do
testOptions.execution
para determinar se a orquestração de teste será usada no dispositivo. Se você quiser usar o Android Test Orchestrator, especifique oANDROID_TEST_ORCHESTRATOR
, conforme mostrado abaixo. Por padrão, essa propriedade é configurada comoHOST
, o que desativa a orquestração no dispositivo e é o método padrão de execução de testes.
- Inclusão do
Groovy
android { testOptions { execution 'ANDROID_TEST_ORCHESTRATOR' } }
Kotlin
android { testOptions { execution = "ANDROID_TEST_ORCHESTRATOR" } }
- A nova configuração de dependência
androidTestUtil
permite que você instale outro APK auxiliar de teste antes de executar testes de instrumentação, como o Android Test Orchestrator:
Groovy
dependencies { androidTestUtil 'com.android.support.test:orchestrator:1.0.0' ... }
Kotlin
dependencies { androidTestUtil("com.android.support.test:orchestrator:1.0.0") ... }
- Inclusão de
testOptions.unitTests.includeAndroidResources
para oferecer suporte a testes de unidade que exigem recursos do Android, como Roboelectric (link em inglês). Quando você configura essa propriedade comotrue
, o plug-in executa mesclagem de recursos, e manifestos antes de executar os testes de unidade. Seus testes podem inspecionarcom/android/tools/test_config.properties
no caminho de classe para as seguintes chaves:android_merged_assets
: o caminho absoluto para o diretório de assets mesclados.Observação: para módulos de biblioteca, os recursos mesclados não contêm os recursos de dependências. Consulte o problema 65550419.
android_merged_manifest
: o caminho absoluto para o arquivo de manifesto mesclado.android_merged_resources
: o caminho absoluto para o diretório de recursos mesclados, que contém todos os recursos do módulo e suas respectivas dependências.android_custom_package
: o nome do pacote da classe R final. Se você modificar dinamicamente o ID do aplicativo, talvez esse nome de pacote não corresponda ao atributopackage
no manifesto do app.
- Suporte a fontes como recursos, que é um novo recurso introduzido no Android 8.0 (nível 26 da API).
- Compatibilidade com APKs específicos de idiomas com o SDK 1.1 do Instant Apps Android ou versões mais recentes.
- Agora, você pode mudar o diretório de saída para seu projeto de build nativo externo, conforme mostrado abaixo:
Groovy
android { ... externalNativeBuild { // For ndk-build, instead use the ndkBuild block. cmake { ... // Specifies a relative path for outputs from external native // builds. You can specify any path that's not a subdirectory // of your project's temporary build/ directory. buildStagingDirectory "./outputs/cmake" } } }
Kotlin
android { ... externalNativeBuild { // For ndk-build, instead use the ndkBuild block. cmake { ... // Specifies a relative path for outputs from external native // builds. You can specify any path that's not a subdirectory // of your project's temporary build/ directory. buildStagingDirectory = "./outputs/cmake" } } }
- Agora você pode usar o CMake 3.7 ou versões mais recentes quando criar projetos nativos do Android Studio.
- A nova configuração de dependência
lintChecks
permite criar um JAR que define regras de lint personalizadas e o empacote nos seus projetos AAR e APK. Suas regras de lint personalizadas precisam pertencer a um projeto separado que produza um único JAR e inclua apenas dependênciascompileOnly
. Dessa forma, outros apps e módulos de biblioteca podem depender do seu projeto de lint usando a configuraçãolintChecks
.
Groovy
dependencies { // This tells the Gradle plugin to build ':lint-checks' into a lint.jar file // and package it with your module. If the module is an Android library, // other projects that depend on it automatically use the lint checks. // If the module is an app, lint includes these rules when analyzing the app. lintChecks project(':lint-checks') }
Kotlin
dependencies { // This tells the Gradle plugin to build ':lint-checks' into a lint.jar file // and package it with your module. If the module is an Android library, // other projects that depend on it automatically use the lint checks. // If the module is an app, lint includes these rules when analyzing the app. lintChecks(project(":lint-checks")) }
Mudanças de comportamento
- O plug-in do Android 3.0.0 remove algumas APIs, e seu build terá falhas se você
usá-las. Por exemplo, não é mais possível usar a API Variants para acessar objetos
outputFile()
ou usarprocessManifest.manifestOutputFile()
para receber o arquivo de manifesto para cada variante. Para saber mais, leia as Mudanças na API. - Não é mais necessário especificar uma versão para o Build Tools, portanto, agora
você pode remover a propriedade
android.buildToolsVersion
. Por padrão, o plug-in usa automaticamente a versão mínima necessária do Build Tools para a versão do plug-in do Android que você está usando. - Agora, você pode ativar ou desativar o processamento de PNG no bloco
buildTypes
, conforme mostrado abaixo. O processamento de PNG é ativado por padrão para todos os builds, exceto os de depuração, porque isso aumenta o tempo de compilação de projetos que tenham muitos arquivos PNG. Portanto, para melhorar os tempos de compilação de outros tipos, é necessário desativar o processamento de PNG ou converter suas imagens em WebP.
Groovy
android { buildTypes { release { // Disables PNG crunching for the release build type. crunchPngs false } } }
Kotlin
android { buildTypes { release { // Disables PNG crunching for the release build type. isCrunchPngs = false } } }
- Agora, o plug-in do Android cria automaticamente destinos executáveis que podem ser configurados nos seus projetos externos do CMake.
- Agora você precisa
adicionar processadores de anotações
ao caminho de classe do processador usando a configuração de dependência
annotationProcessor
. - O uso do
ndkCompile
, agora obsoleto, é mais restrito. Em vez disso, você precisa migrar para o CMake ou o ndk-build para compilar o código nativo que quer empacotar no seu APK. Para saber mais, leia Migrar do ndkcompile.
2.3.0 (fevereiro de 2017)
2.3.3 (junho de 2017)
Esta é uma pequena atualização que adiciona compatibilidade com o Android Studio 2.3.3.
2.3.2 (maio de 2017)
Esta é uma atualização secundária que adiciona compatibilidade com o Android Studio 2.3.2.
2.3.1 (abril de 2017)
Esta é uma atualização secundária do plug-in do Android 2.3.0 que corrige um problema em que alguns dispositivos físicos Android não funcionavam corretamente com o Instant Run. Consulte o problema 235879.
- Dependências:
-
- Gradle 3.3 ou versões mais recentes
- Build Tools 25.0.0 ou versões mais recentes
- Novidade:
-
- Usa o Gradle 3.3, que inclui melhorias de desempenho e novos recursos. Para ver mais detalhes, consulte as notas da versão do Gradle (em inglês).
- Cache de compilação: armazena algumas saídas geradas pelo plug-in do
Android ao criar seu projeto, como AARs
não empacotados e dependências remotas pré-dexadas. Seus builds limpos são
muito mais rápidos quando você usa o cache, porque o sistema de compilação pode
simplesmente reutilizar os arquivos em cache nos builds subsequentes, em vez
de criá-los novamente. Os projetos que usam o plug-in do Android 2.3.0 e versões mais recentes usam
o cache de build por padrão. Para saber mais, consulte
Melhorar a velocidade de compilação com o
cache de build.
- Inclui uma tarefa
cleanBuildCache
que limpa o cache de compilação. - Se você está usando a versão experimental do cache de build, incluída em versões anteriores do plug-in, atualize o plug-in para a versão mais recente.
- Inclui uma tarefa
- Mudanças:
-
- É compatível com mudanças no Instant Run incluídas no Android Studio 2.3.
- Os tempos de configuração de projetos muito grandes serão significativamente mais curtos.
- Correção de problemas com o download automático para a biblioteca Constraint Layout.
- O plug-in agora usa a versão 5.3.2 do ProGuard (link em inglês).
- Inclui muitas correções para bugs informados. Continue enviando relatórios de bugs quando encontrar problemas.
2.2.0 (setembro de 2016)
- Dependências:
-
- Gradle 2.14.1 ou versões mais recentes
- Build Tools 23.0.2 ou versões mais recentes.
- Novidade:
-
- Usa o Gradle 2.14.1, que inclui melhorias de desempenho e novos recursos, além de corrigir uma vulnerabilidade de segurança que permite o escalonamento de privilégios locais ao usar o daemon Gradle. Para ver mais detalhes, consulte as notas da versão do Gradle (link em inglês).
- Com o uso da DSL
externalNativeBuild {}
, o Gradle agora permite a vinculação a origens nativas e a compilação de bibliotecas nativas usando o CMake ou o ndk-build. Depois de criar suas bibliotecas nativas, o Gradle as empacota no seu APK. Para saber mais sobre como usar o CMake e o ndk-build com o Gradle, leia Adicionar código C e C++ ao seu projeto. - Quando você executa um build na linha de comando, o Gradle agora tenta fazer o download automático de todos os componentes ou atualizações do SDK ausentes de que seu projeto depende. Para saber mais, leia Download automático de pacotes ausentes com o Gradle.
- Um novo recurso experimental de armazenamento em cache permite que o Gradle acelere o tempo de compilação ao fazer a pré-dexação, o armazenamento e a reutilização das versões pré-dexadas das bibliotecas. Para saber mais sobre como usar esse recurso experimental, leia o guia Cache de compilação.
- Melhora a performance de build adotando um novo pipeline
de empacotamento padrão que cuida da compactação, assinatura e zipaligning em uma tarefa. Você
pode voltar a usar as ferramentas de empacotamento anteriores adicionando
android.useOldPackaging=true
ao arquivogradle.properties
. Ao usar a nova ferramenta de empacotamento, a tarefazipalignDebug
não ficará disponível. No entanto, você pode criar uma chamando o métodocreateZipAlignTask(String taskName, File inputFile, File outputFile)
. - A assinatura do APK agora usa o Esquema de assinatura de APK
v2, além da assinatura JAR tradicional. Todas as plataformas Android aceitam os
APKs resultantes. Qualquer modificação nesses APKs, após a assinatura, invalida as
assinaturas v2 e impede a instalação em dispositivos. Para desativar esse recurso,
adicione o seguinte ao seu arquivo
build.gradle
no módulo:Groovy
android { ... signingConfigs { config { ... v2SigningEnabled false } } }
Kotlin
android { ... signingConfigs { create("config") { ... v2SigningEnabled = false } } }
- Para builds multidex, agora você pode usar as regras do ProGuard para determinar quais
classes o Gradle precisa compilar no arquivo DEX principal do app. Como
o sistema Android carrega primeiro o arquivo DEX principal ao iniciar seu app, você
pode priorizar determinadas classes na inicialização, compilando-as no arquivo
DEX principal. Depois de criar um arquivo de configuração do ProGuard especificamente para seu
arquivo DEX principal, transmita o caminho do arquivo de configuração para o Gradle usando
buildTypes.multiDexKeepProguard
. O uso dessa DSL é diferente do uso debuildTypes.proguardFiles
, que fornece regras gerais do ProGuard para o app e não especifica classes para o arquivo DEX principal. - Foi adicionado suporte à sinalização
android:extractNativeLibs
, que pode reduzir o tamanho do app quando você o instala em um dispositivo. Quando você configura essa sinalização comofalse
no elemento<application>
do manifesto do app, o Gradle compacta as versões descompactadas e alinhadas das suas bibliotecas nativas com seu APK. Isso impede que oPackageManager
copie as bibliotecas nativas do APK para o sistema de arquivos do dispositivo durante a instalação, além de oferecer o benefício de diminuir as atualizações delta do seu app. - Agora você pode especificar
versionNameSuffix
eapplicationIdSuffix
para variações de produto (problema 59614).
- Mudanças:
-
-
O
getDefaultProguardFile
agora retorna os arquivos do ProGuard padrão fornecidos pelo Plug-in do Android para Gradle e não usa mais os que estão no SDK do Android. - Melhoria no desempenho e nos recursos do compilador Jack:
- Agora, o Jack oferece suporte à cobertura de teste Jacoco quando
testCoverageEnabled
for configurado comotrue
. - Suporte melhorado para processadores de anotações. Os processadores
de anotações no seu caminho de classe, como as dependências
compile
, são aplicados automaticamente ao build. Você também pode especificar um processador de anotação no seu build e transmitir argumentos usando a DSLjavaCompileOptions.annotationProcessorOptions {}
no arquivobuild.gradle
no módulo:Groovy
android { ... defaultConfig { ... javaCompileOptions { annotationProcessorOptions { className 'com.example.MyProcessor' // Arguments are optional. arguments = [ foo : 'bar' ] } } } }
Kotlin
android { ... defaultConfig { ... javaCompileOptions { annotationProcessorOptions { className = "com.example.MyProcessor" // Arguments are optional. arguments(mapOf(foo to "bar")) } } } }
Se você quiser aplicar um processador de anotações no tempo de compilação, sem incluí-lo no seu APK, use o escopo de dependência
annotationProcessor
:Groovy
dependencies { compile 'com.google.dagger:dagger:2.0' annotationProcessor 'com.google.dagger:dagger-compiler:2.0' // or use buildVariantAnnotationProcessor to target a specific build variant }
Kotlin
dependencies { implementation("com.google.dagger:dagger:2.0") annotationProcessor("com.google.dagger:dagger-compiler:2.0") // or use buildVariantAnnotationProcessor to target a specific build variant }
Para ver uma lista de parâmetros que podem ser configurados, execute o seguinte na linha de comando:
java -jar /build-tools/jack.jar --help-properties
- Agora, o Jack oferece suporte à cobertura de teste Jacoco quando
- Por padrão, se o tamanho de heap do daemon Gradle for de pelo menos 1,5
GB, o Jack será executado no mesmo processo que o Gradle. Para ajustar o
tamanho de heap do daemon, adicione o seguinte ao seu arquivo
gradle.properties
:# This sets the daemon heap size to 1.5GB. org.gradle.jvmargs=-Xmx1536M
-
O
2.1.0 (abril de 2016)
2.1.3 (agosto de 2016)
Esta atualização requer o Gradle 2.14.1 e versões mais recentes. O Gradle 2.14.1 inclui melhorias de desempenho, novos recursos e uma correção de segurança importante. Para ver mais detalhes, consulte as notas da versão do Gradle (link em inglês).
- Dependências:
-
- Gradle 2.10 ou versões mais recentes
- Build Tools 23.0.2 ou mais recente.
- Novidade:
-
- Inclusão de compatibilidade com os recursos da linguagem Java 8, do N Developer Preview e do JDK 8 usando o conjunto de ferramentas
Jack. Para saber mais, leia o Guia do N Preview.
Observação: o Instant Run não funciona com o Jack e vai ser desativado enquanto o novo conjunto de ferramentas estiver em uso. Você só precisa usar o Jack se estiver desenvolvendo para o N Preview e quiser usar os recursos da linguagem compatíveis com o Java 8.
- Suporte padrão à compilação Java incremental foi adicionado para reduzir
o tempo de compilação durante o desenvolvimento. Isso é feito apenas com a recompilação
de partes da origem que foram alteradas ou que precisam ser recompiladas. Para desativar
esse recurso, adicione o seguinte ao seu arquivo
build.gradle
no módulo:Groovy
android { ... compileOptions { incremental false } }
Kotlin
android { ... compileOptions { incremental = false } }
-
Inclusão de compatibilidade com dexação no processo, executada no processo de compilação, e não em um processo de VM externo separado. Isso não só torna os builds incrementais mais rápidos, mas também agiliza os builds completos. O recurso é ativado por padrão para projetos com o tamanho de heap máximo do daemon Gradle configurado como, pelo menos, 2.048 MB. Você pode fazer isso incluindo o seguinte no arquivo
```none org.gradle.jvmargs = -Xmx2048m ```gradle.properties
do seu projeto:Se você definiu um valor para
```none org.gradle.jvmargs = -Xmx3072m ```javaMaxHeapSize
no seu arquivobuild.gradle
no módulo, é necessário definirorg.gradle.jvmargs
para o valor dejavaMaxHeapSize
+ 1024 MB. Por exemplo, se você configuroujavaMaxHeapSize
como "2048m", é necessário adicionar o seguinte ao arquivogradle.properties
do seu projeto:Para desativar a dexação no processo, adicione o seguinte código ao seu arquivo
build.gradle
no módulo:Groovy
android { ... dexOptions { dexInProcess false } }
Kotlin
android { ... dexOptions { dexInProcess = false } }
- Inclusão de compatibilidade com os recursos da linguagem Java 8, do N Developer Preview e do JDK 8 usando o conjunto de ferramentas
Jack. Para saber mais, leia o Guia do N Preview.
2.0.0 (abril de 2016)
- Dependências:
-
- Gradle 2.10 ou versões mais recentes
- Build Tools 21.1.1 ou mais recente.
- Novidade:
-
- Ativa o Instant Run oferecendo compatibilidade com a injeção de bytecode e com o envio de atualizações de código e recursos para um app em execução no emulador ou em um dispositivo físico.
- Foi adicionado suporte a builds incrementais mesmo quando o app não está em execução. Os tempos de compilação completos foram aprimorados pelo envio de mudanças incrementais pelo Android Debug Bridge ao dispositivo conectado.
- Inclusão do
maxProcessCount
(link em inglês) para controlar quantos processos de dex worker podem ser gerados simultaneamente. O código abaixo, presente no arquivobuild.gradle
do módulo, define o número máximo de processos simultâneos como 4:Groovy
android { ... dexOptions { maxProcessCount = 4 // this is the default value } }
Kotlin
android { ... dexOptions { maxProcessCount = 4 // this is the default value } }
- Inclusão de um redutor de código experimental para ser compatível com a pré-dexação e reduzir a redexação
de dependências, que não são compatíveis com o Proguard. Isso melhora a velocidade
de compilação da variante de depuração. Como o redutor experimental não
é compatível com otimização e ofuscação, é importante ativar o Proguard nos seus
builds de lançamento. Para ativar o redutor experimental para seus builds de depuração, adicione
o seguinte ao arquivo
build.gradle
no módulo:Groovy
android { ... buildTypes { debug { minifyEnabled true useProguard false } release { minifyEnabled true useProguard true // this is a default setting } } }
Kotlin
android { ... buildTypes { getByName("debug") { minifyEnabled = true useProguard = false } getByName("release") { minifyEnabled = true useProguard = true // this is a default setting } } }
- Inclusão da compatibilidade com geração de registros e desempenho aprimorado do redutor de recurso.
O redutor de recurso agora registra todas as operações em um arquivo
resources.txt
localizado na mesma pasta dos arquivos de registros do Proguard.
- Comportamento alterado:
-
- Quando
minSdkVersion
é configurado como 18 ou mais, a assinatura do APK usa o SHA256. - As chaves de DSA e ECDSA agora podem assinar pacotes de APK.
Observação: o provedor Android Keystore não oferece mais suporte a chaves DSA no Android 6.0 (API de nível 23) e versões mais recentes.
- Quando
- Problemas corrigidos:
-
- Correção de um problema que causava dependências AAR duplicadas nas configurações teste e de compilação principal.