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 compilação Gradle. Portanto, o AGP 7.0 será a próxima versão após o AGP 4.2.
Veja mais detalhes abaixo.
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 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 a seguir define
o plug-in para a versão 4.0.0 no arquivo
build.gradle
:
buildscript { repositories { // Gradle 4.1 and higher include support for Google's Maven repo using // the google() method. And you need to include this repo to download // Android Gradle plugin 3.0.0 or higher. google() ... } dependencies { classpath 'com.android.tools.build:gradle:4.0.0' } }
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 seu projeto ou clicar em Tools > Android > 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 versão do seu 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 o melhor desempenho, 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+ |
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+ |
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 a seguir
define a versão do Gradle como 6.1.1 no arquivo
gradle-wrapper.properties
.
... distributionUrl = https\://services.gradle.org/distributions/gradle-6.1.1-all.zip ...
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 compilação 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.
As APIs serão suspensas com aproximadamente um ano de antecedência, e a funcionalidade de substituição será disponibilizada simultaneamente. As APIs obsoletas serão removidas cerca de um ano depois, quando houver uma atualização de larga escala.
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:
buildFeatures {
prefabPublishing true
}
prefab {
mylibrary {
headers "src/main/cpp/mylibrary/include"
}
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 compilação do Plug-in do Android para Gradle foi removido
O cache de compilação do AGP foi removido no AGP 4.1. Introduzido no AGP 2.3 para complementar o cache de compilação do Gradle, o cache de compilação do AGP foi substituído inteiramente 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
.
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.
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.
Suspensão do plug-in io.fabric do Gradle
O plug-in io.fabric do Gradle está obsoleto 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 seu 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 é compatível com o 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
seu módulo:
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'
}
Novas opções para ativar ou desativar recursos de compilação
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:
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:
// 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 compatibilidade com o recurso 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:
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 só disponibiliza essas bibliotecas para seu build. Você ainda precisa configurar scripts de compilação para usá-las.
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 suspendeu o uso dos plug-ins Feature
(com.android.feature
) e Instant App (com.android.instantapp
) em
favor do uso do plug-in Dynamic Feature (com.android.dynamic-feature
) para
criar e empacotar seus 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 obsoletos 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.
Remoção do recurso de processamento de anotações separado
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 para melhorar o desempenho de compilação.
O includeCompileClasspath está obsoleto
O Plug-in do Android para Gradle não verifica 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
:
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']
}
}
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 tempo de compilação quando há referências a visualizações no seu 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:
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 do Maven Publish para Gradle, que permite a publicação de artefatos de compilação 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 da versão nativa
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. 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 compilação 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 é compatível com o Android Studio 3.5.2 e inclui várias correções de bugs e melhorias no desempenho. Para ver uma lista de correções de bugs em destaque, leia a postagem correspondente no blog de atualizações de versão (link em inglês).
3.5.1 (outubro de 2019)
Esta atualização secundária é compatível com o Android Studio 3.5.1 e inclui várias correções de bugs e melhorias no desempenho. Para ver uma lista de correções de bugs em destaque, leia a postagem correspondente 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 será compatível com o processamento
incremental de anotações
(link em inglês) se você definir android.databinding.incremental=true
no seu 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 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 é compatível com o Android Studio 3.4.2 e inclui várias correções de bugs e melhorias no desempenho. Para ver uma lista de correções de bugs em destaque, leia a postagem correspondente no blog de atualizações de versão (link em inglês).
3.4.1 (maio de 2019)
Esta atualização secundária é compatível com o Android Studio 3.4.1 e inclui várias correções de bugs e melhorias no desempenho. Para ver uma lista de correções de bugs em destaque, leia a postagem correspondente 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
foi alterado, 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.
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 compilação. Se você perceber uma regressão de desempenho relacionada a essas tarefas, informe um bug.
Mudanças de comportamento
Aviso de suspensão do uso do plug-in Instant Apps Android: 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 exibirá um aviso de suspensão de uso. 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 de compilação (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. Portanto, nessa situação improvável, talvez seja necessário adicionar outras regras para manter esse código no seu resultado de compilação.
Se você tiver problemas ao usar o R8, leia as Perguntas frequentes de compatibilidade do R8 (link em inglês) para verificar se há uma solução para o problema. 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
ndkCompile
está obsoleto: agora você verá um erro de compilação se tentar usar ondkBuild
para compilar suas 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 ou versões posteriores. 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 é compatível com o Android Studio 3.3.2 e inclui várias correções de bugs e melhorias no desempenho. Para ver uma lista de correções de bugs em destaque, leia a postagem correspondente 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 tempo de compilação e execuçã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 do tempo de execução incluir a Biblioteca A versão 1.0 e o de compilação incluir a Biblioteca A versão 2.0, o plug-in não fará downgrade da dependência do caminho de classe de compilação para a Biblioteca A versão 1.0, e isso gerará um erro. Para saber mais, consulte Corrigir conflitos entre caminhos de classe
Melhoria na compilação incremental em Java ao usar processadores de anotações: esta atualização diminui o tempo de compilação porque melhora a compatibilidade com compilação incremental em Java durante o uso de 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 forem compatíveis com o processamento incremental de anotações, a compilação incremental em Java 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 determinado tipo de build, ao configurar
useProguard false
, o plug-in agora usará o R8 em vez do ProGuard para reduzir e ofuscar o código e os recursos do seu 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 é totalmente compatível com projetos que incluem as linguagens Java e C++, e é parcialmente compatível com 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 ou versões posteriores. 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.
Compatibilidade com velocidades aprimoradas de compilação incremental ao usar processadores de anotações: a DSL
AnnotationProcessorOptions
agora estendeCommandLineArgumentProvider
, 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 compilação 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, haverá um erro de compilação.
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: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: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ê poderá reativar a configuração sob demanda se tiver desativado ela em versões anteriores devido a alguns erros de compilação 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 ou versões posteriores. Para saber mais, leia a seção sobre como atualizar o Gradle.
- Build Tools 27.0.3 ou versões posteriores.
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:splits { abi { include 'armeabi', 'mips', 'mips64' ... } }
Ao criar APKs de configuração para um Instant App Android, as divisões de configuração de idioma agora são agrupadas pelo idioma raiz por padrão. Por exemplo, se o app incluir recursos para localidades
zh-TW
ouzh-CN
, o Gradle empacotará esses recursos em uma divisão de configuração do idiomazh
. Para modificar esse comportamento, defina seus próprios grupos usando a propriedadeinclude
, conforme mostrado abaixo:splits { language { enable true // Each string defines a group of locales that // Gradle should package together. include "in,id", "iw,he", "fil,tl,tgl", "yue,zh,zh-TW,zh-CN" } }
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: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 sentir 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 ou versões posteriores. Para saber mais, leia a seção sobre como atualizar o Gradle.
- Build Tools 26.0.2 ou versões posteriores.
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 por meio de 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 compilação incremental devido à dexação por classe. Agora, cada classe é
compilada em arquivos DEX separados, e apenas as classes
modificadas são redexadas. Também haverá aumento na velocidade de compilação de
apps que tenham
minSdkVersion
configurado como 20 ou menos e usem multi-dex legado. - Velocidades de compilação aumentadas pela otimização de determinadas tarefas para usar as saídas em cache. Para aproveitar essa otimização, é necessário ativar o cache de compilação 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. Agora, na criação de determinada variante de um módulo, o plug-in 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
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:
dependencies { androidTestUtil 'com.android.support.test:orchestrator:1.0.0' ... }
- Inclusão de
testOptions.unitTests.includeAndroidResources
para oferecer compatibilidade com 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 assets 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.
- Compatibilidade com fontes como recursos, que é um novo recurso introduzido no Android 8.0 (API de nível 26).
- Compatibilidade com APKs específicos de idiomas com o SDK 1.1 do Instant Apps Android ou versões mais recentes. Para ver mais informações, consulte Configurar sua versão para divisões puras.
- Agora, você pode alterar o diretório de saída para seu projeto de compilação nativo externo, conforme mostrado abaixo:
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
.
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.
android { buildTypes { release { // Disables PNG crunching for the release build type. crunchPngs 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 atualização secundária 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 no 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 posteriores
- Build Tools 25.0.0 ou mais recente.
- 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 (link 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 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, leia Melhorar a velocidade de compilação com o cache de compilação.
-
Inclui uma tarefa
cleanBuildCache
que limpa o cache de compilação. - Se você estiver usando a versão experimental do cache de compilação (incluído 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 alterações no Instant Run incluídas no Android Studio 2.3.
- Os tempos de configuração de projetos muito grandes serão significativamente mais rápidos.
- 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 posteriores
- Build Tools 23.0.2 ou mais recente.
- 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 predexar, armazenar e reutilizar as versões pré-dexadas das suas bibliotecas. Para saber mais sobre como usar esse recurso experimental, leia o guia Cache de compilação.
- Melhora o desempenho de compilação 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:android { ... signingConfigs { 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. - Adiciona compatibilidade com a sinalização
android:extractNativeLibs
, que pode reduzir o tamanho do app quando você o instalar 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 é compatível com a cobertura de teste Jacoco quando
testCoverageEnabled
for configurado comotrue
. - Melhoria na compatibilidade com 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:android { ... defaultConfig { ... javaCompileOptions { annotationProcessorOptions { className 'com.example.MyProcessor' // Arguments are optional. arguments = [ foo : 'bar' ] } } } }
Se você quiser aplicar um processador de anotações no tempo de compilação, mas não incluí-lo no seu APK, use o escopo de dependência
annotationProcessor
: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 }
- É possível definir outras sinalizações para o Jack usando
jackOptions.additionalParameters()
. O snippet de código a seguir define o parâmetrojack.incremental
comotrue
:android { defaultConfig { ... jackOptions { enabled true additionalParameters("jack.incremental" : true) } } }
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
- 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
- Agora, o Jack é compatível com a cobertura de teste Jacoco quando
-
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 posteriores
- 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 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.
- Inclusão de compatibilidade padrão com compilação Java incremental 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: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
gradle.properties
do seu projeto:org.gradle.jvmargs = -Xmx2048m
Se você definiu um valor para
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:org.gradle.jvmargs = -Xmx3072m
Para desativar a dexação no processo, adicione o seguinte código ao seu arquivo
build.gradle
no módulo: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 posteriores
- 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.
- Inclusão de compatibilidade com 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
para controlar quantos processos dex subordinados podem ser gerados simultaneamente. O código a seguir, presente no arquivobuild.gradle
do módulo, define o número máximo de processos simultâneos como 4: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:android { ... buildTypes { debug { minifyEnabled true useProguard false } 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 é mais compatível com 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.