Plug-in do Android para Gradle 7.0.0 (julho de 2021)
O Plug-in do Android para Gradle 7.0.0 é uma versão principal que inclui várias novas recursos e melhorias.
7.0.1 (agosto de 2021)
Esta atualização secundária inclui várias correções de bugs. Para acessar uma lista de correções de bugs importantes, leia a postagem relacionada na blog de atualizações de versão.
Compatibilidade
Versão mínima | Versão padrão | Observações | |
---|---|---|---|
Gradle | 7.0.2 | 7.0.2 | Para saber mais, consulte Como atualizar o Gradle. |
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. |
JDK | 11 | 11 | Para saber mais, consulte Como configurar a versão do JDK. |
JDK 11 necessário para executar o AGP 7.0
Ao usar o Plug-in do Android para Gradle 7.0 para criar seu app, o JDK 11 agora é necessárias para executar o Gradle. O Android Studio Arctic Fox inclui o JDK 11 e configura o Gradle para usá-lo por padrão, ou seja, a maioria os usuários não precisam fazer alterações na configuração dos projetos.
Se você precisar definir manualmente o Versão do JDK usada pelo AGP no Android Studio, você precisa usar o JDK 11. ou superior.
Ao usar o AGP independente do Android Studio, faça upgrade da versão do JDK.
defina a variável de ambiente JAVA_HOME.
ou a opção de linha de comando -Dorg.gradle.java.home
no diretório de instalação do JDK 11.
O SDK Manager e o AVD Manager no pacote descontinuado do SDK Tools não funcionam com o JDK 11. Para continuar usando o SDK Manager e o AVD Manager com o AGP 7.0 e versões mais recentes, é necessário mudar para as novas versões das ferramentas no o atual Ferramentas de linha de comando do SDK do Android .
API Variant estável
A nova API Variant agora está estável. Confira as novas interfaces na com.android.build.api.variant (link em inglês) e exemplos na filosofia gradle-receitas (em inglês) do GitHub. Como parte do novo API Variant, disponibilizamos vários arquivos intermediários, chamados artefatos, por meio do Artefatos interface gráfica do usuário. Esses artefatos, como o manifesto integrado, podem ser obtidos com segurança e personalizado usando plug-ins e códigos de terceiros.
Vamos continuar estendendo a API Variant com a adição de novas funcionalidades e aumentar o número de artefatos intermediários disponibilizados para e personalização.
Mudanças de comportamento do lint
Esta seção descreve várias mudanças de comportamento do Lint no Android para Gradle. plug-in 7.0.0.
Lint aprimorado para dependências de biblioteca
A execução do lint com checkDependencies = true
agora é mais rápida
do que antes. Para projetos Android que consistem em um app com biblioteca
dependências, é recomendável definir checkDependencies
como
true
, como mostrado abaixo, e para executar o lint por meio de
./gradlew :app:lint
, que analisará todas as dependências
em paralelo e produzir um único relatório, incluindo problemas da
e todas as dependências dele.
Groovy
// build.gradle
android {
...
lintOptions {
checkDependencies true
}
}
Kotlin
// build.gradle.kts
android {
...
lint {
isCheckDependencies = true
}
}
As tarefas de lint agora podem ser atualizadas
Se as fontes e os recursos de um módulo não tiverem mudado, a análise do lint
para o módulo não precisa ser executada novamente. Quando isso acontece, o
execução da tarefa aparece como "UP-TO-DATE" na versão do Gradle
saída. Com essa mudança, ao executar o lint em um módulo de aplicativo com checkDependencies = true
, apenas os módulos que foram alterados serão
precisam para fazer a análise. Como resultado, o lint pode ser executado ainda mais rapidamente.
A tarefa de relatório do lint também não precisa ser executada se as entradas não tiverem sido mudou. Um problema conhecido relacionado é a ausência do lint. saída de texto impressa em stdout quando a tarefa do lint está UP-TO-DATE (problema 191897708).
Como executar o lint em módulos de recursos dinâmicos
O AGP não é mais compatível com a execução do lint em módulos de recursos dinâmicos.
A execução do lint no módulo de aplicativo correspondente será executada
os módulos de recursos dinâmicos e incluir todos os problemas no lint do app
relatório. Um problema conhecido relacionado é que, ao executar o lint
com checkDependencies = true
em um módulo de app,
as dependências da biblioteca de recursos dinâmicos não são verificadas, a menos que também sejam aplicativos
dependências (problema
#191977888).
Como executar o lint apenas na variante padrão
A execução de ./gradlew :app:lint
agora executa o lint apenas para o
variante padrão. Nas versões anteriores do AGP, ele executava o lint para todos os
variantes.
Avisos de classes ausentes no redutor R8
R8 com mais precisão e
lida de forma consistente com as turmas ausentes e a opção -dontwarn
.
Portanto, comece a avaliar os avisos de classes ausentes emitidos.
pelo R8.
Quando o R8 encontra uma referência de classe que não está definida no app ou uma das dependências, ele emitirá um aviso que aparece no build saída. Exemplo:
R8: Missing class: java.lang.instrument.ClassFileTransformer
Esse aviso significa que a definição da classe
Não foi possível encontrar java.lang.instrument.ClassFileTransformer
ao analisar o código do seu app. Isso geralmente significa que há um erro,
você pode ignorar esse aviso. Dois motivos comuns
para ignorar o aviso são:
-
As bibliotecas destinadas à JVM e a classe ausente são da JVM tipo de biblioteca (como no exemplo acima).
-
Uma das dependências usa uma API somente para tempo de compilação.
É possível ignorar um aviso de classe ausente adicionando um -dontwarn
.
ao arquivo proguard-rules.pro
. Exemplo:
-dontwarn java.lang.instrument.ClassFileTransformer
Por conveniência, o AGP gera um arquivo que contém todas
regras ausentes, gravando-as em um caminho de arquivo como o seguinte:
app/build/outputs/mapping/release/missing_rules.txt
: Adicione o método
ao arquivo proguard-rules.pro
para ignorar os avisos.
No AGP 7.0, as mensagens de classes ausentes vão aparecer como avisos, e é possível
transformá-los em erros, definindo
android.r8.failOnMissingClasses = true
pol.
gradle.properties
. No AGP 8.0, esses avisos se tornarão
erros que corrompem seu build. É possível manter o comportamento do AGP 7.0
adicionando a opção -ignorewarnings
ao seu
proguard-rules.pro
, mas isso não é recomendado.
O cache de build do Plug-in do Android para Gradle foi removido
O cache de build do AGP foi removido no AGP 4.1. Introduzido anteriormente no AGP 2.3 para complementar o cache de build do Gradle, o cache de build do AGP foi substituído. inteiramente pelo cache de build do Gradle no AGP 4.1. Essa mudança não afeta tempo de build.
No AGP 7.0, a propriedade android.enableBuildCache
,
android.buildCacheDir
, e a propriedade
cleanBuildCache
tarefa foi removida.
Usar o código-fonte Java 11 no seu projeto
Agora é possível compilar até código-fonte em Java 11 no projeto do app, o que permite o uso de recursos de linguagem mais recentes, como métodos de interface privados, o para classes anônimas e a sintaxe de variáveis locais para parâmetros lambda.
Para ativar esse recurso, defina compileOptions
como o valor
Versão do Java e defina compileSdkVersion
como 30 ou mais recente:
// build.gradle
android {
compileSdkVersion 30
compileOptions {
sourceCompatibility JavaVersion.VERSION_11
targetCompatibility JavaVersion.VERSION_11
}
// For Kotlin projects
kotlinOptions {
jvmTarget = "11"
}
}
// build.gradle.kts
android {
compileSdkVersion(30)
compileOptions {
sourceCompatibility(JavaVersion.VERSION_11)
targetCompatibility(JavaVersion.VERSION_11)
}
kotlinOptions {
jvmTarget = "11"
}
}
Configurações de dependência removidas
No AGP 7.0, as seguintes configurações (ou escopos de dependência) foram removido:
-
compile
Dependendo do caso de uso, foi substituído porapi
ouimplementation
.
Também se aplica a variantes *Compile, por exemplo:debugCompile
. -
provided
Ele foi substituído porcompileOnly
.
Isso também se aplica a variantes *Provided, por exemplo:releaseProvided
. -
apk
Ele foi substituído porruntimeOnly
. -
publish
Ele foi substituído porruntimeOnly
.
Na maioria dos casos, o AGP O Assistente de upgrade vai migrar seu projeto automaticamente para o novo personalizadas.
Mudança do caminho de classe ao compilar no Android Plug-in do Gradle
Se você está compilando com o Plug-in do Android para Gradle, o build
o caminho de classe pode mudar. Como o AGP agora usa api/implementation
internas do aplicativo, alguns artefatos podem ser removidos da compilação
o caminho de classe. Se você depende de uma dependência do AGP durante a compilação,
adicioná-lo como uma dependência explícita.
Adição de bibliotecas nativas em recursos Java a pasta não é compatível
Antes, era possível adicionar uma biblioteca nativa em uma pasta de recursos Java e
registrar a pasta usando android.sourceSets.main.resources.srcDirs
para que a biblioteca nativa seja extraída e adicionada ao arquivo
APK. A partir do AGP 7.0, ele não tem suporte, e bibliotecas nativas em um
de recursos Java serão ignorados. Em vez disso, use o método DSL destinado a
bibliotecas nativas, android.sourceSets.main.jniLibs.srcDirs
. Para
mais informações, consulte
como configurar
conjuntos de origem.
Problemas conhecidos
Esta seção descreve problemas conhecidos que existem no Plug-in do Android para Gradle 7.0.0
Incompatibilidade com o plug-in Kotlin Multiplatform 1.4.x
O Plug-in do Android para Gradle 7.0.0 é compatível com Kotlin Plug-in Multiplatform 1.5.0 e mais recentes. Projetos que usam o Kotlin O suporte multiplataforma precisa ser atualizado para o Kotlin 1.5.0 para usar o Android para Gradle. Plug-in 7.0.0. Como solução alternativa, você pode fazer downgrade do Plug-in do Android para Gradle. para 4.2.x, embora isso não seja recomendado.
Para mais informações, consulte KT-43944 (link em inglês).
Saída do lint ausente
Não há saída de texto do lint impressa em stdout quando a tarefa do lint é atualizados (problema 191897708). Para mais contexto, consulte Mudanças de comportamento para lint. Este problema serão corrigidas no Plug-in do Android para Gradle 7.1.
Nem todas as dependências da biblioteca de recursos dinâmicos são verificadas no lint
Ao executar o lint com checkDependencies = true
de um
módulo do app, as dependências da biblioteca de recursos dinâmicos não são verificadas, a menos que
eles também são dependências de apps
(problema 191977888).
Como alternativa, a tarefa do lint pode ser executada nessas bibliotecas. Para mais contexto,
Consulte Mudanças de comportamento para lint.