Plug-in do Android para Gradle 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. |
Ferramentas de build do SDK | 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 conferir uma lista completa dos 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:
// 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"
}
}
// 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 oferece suporte aos
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:
// build.gradle
android {
...
signingConfigs {
config {
...
enableV3Signing true
enableV4Signing true
}
}
}
// build.gradle.kts
android {
...
signingConfigs {
config {
...
enableV3Signing = true
enableV4Signing = true
}
}
}
A assinatura do APK v4 permite implantar rapidamente APKs grandes usando a instalação incremental de APK do ADB no Android 11. Essa nova flag 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 demonstra 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
,
mostrando 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 acessar 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 do Gradle
de subprojetos. Em outras palavras, se você declarar uma propriedade em um
arquivo gradle.properties
em um subprojeto em vez do projeto
raiz, ela será ignorada.
Como exemplo, em versões anteriores, o AGP leria valores de
<var>projectDir</var>/gradle.properties
,
<var>projectDir</var>/app/gradle.properties
,
<var>projectDir</var>/library/gradle.properties
e assim por diante. Para módulos de apps, se a mesma propriedade do Gradle estivesse presente em
<var>projectDir</var>/gradle.properties
e
<var>projectDir</var>/app/gradle.properties
,
o valor de
<var>projectDir</var>/app/gradle.properties
teria precedência.
No AGP 4.2, esse comportamento mudou, e o AGP não carrega valores de
gradle.properties
em subprojetos (por exemplo,
<var>projectDir</var>/app/gradle.properties
).
Essa mudança reflete o
novo comportamento do Gradle e oferece suporte ao
armazenamento em cache da configuração.
Para 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 build 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 a performance do JVM devido a mudanças 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 mudar o JDK usado para executar o Gradle na caixa de diálogo Project Structure. Alterar essa configuração só muda 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 versões mais recentes, contanto que o AGP esteja executando o Gradle 4.8.1 ou versões mais recentes. Para 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 melhorar a performance do build, recomendamos
testar seus builds do Gradle com o
coletor de lixo paralelo. Em gradle.properties
, defina:
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
seguinte 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.