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 uma variedade de novos recursos e melhorias.

Compatibilidade

JDK 11 necessário para executar o AGP 7.0

Ao usar o Plug-in do Android para Gradle 7.0 para criar seu app, o JDK 11 agora é necessário para executar o Gradle. O Android Studio Arctic Fox inclui o JDK 11 e configura o Gradle para usá-lo por padrão. Isso significa que a maioria dos usuários do Android Studio não precisa fazer nenhuma mudança de configuração nos projetos.

Se você precisar definir a versão do JDK usada pelo AGP no Android Studio manualmente, use o JDK 11 ou mais recente.

Ao usar o AGP, independente do Android Studio, faça upgrade da versão do JDK configurando a variável de ambiente JAVA_HOME ou a opção da linha de comando -Dorg.gradle.java.home para o diretório de instalação do JDK 11.

O SDK Manager e o AVD Manager no pacote descontinuado "Ferramentas do SDK" não funcionam com o JDK 11. Para continuar a usar o SDK Manager e o AVD Manager com o AGP 7.0 e versões mais recentes, você precisa mudar para as novas versões das ferramentas no pacote atual de Ferramentas de linha de comando do SDK do Android.

API Variant estável

A nova API Variant agora está estável. Confira as novas interfaces no pacote com.android.build.api.variant e os exemplos no projeto gradle-recipes (link em inglês) do GitHub. Como parte da nova API Variant, disponibilizamos vários arquivos intermediários, chamados artefatos, pela interface Artefatos. Esses artefatos, como o manifesto integrado, podem ser conseguidos e personalizados com segurança usando códigos e plug-ins de terceiros.

Continuaremos estendendo a API Variant com a adição de novas funções e o aumento do número de artefatos intermediários disponibilizados para personalização.

Mudanças de comportamento do lint

Esta seção descreve várias mudanças de comportamento do lint no Plug-in do Android para Gradle 7.0.0.

Lint aprimorado para dependências de biblioteca

A execução do lint com checkDependencies = true agora está mais rápida do que antes. Para projetos do Android compostos por um app com dependências de biblioteca, é recomendável definir checkDependencies como true, conforme mostrado abaixo, e executar o lint usando ./gradlew :app:lint, que analisa todos os módulos de dependência em paralelo e produz um único relatório, incluindo problemas do app e todas as respectivas dependências.

// build.gradle
android {
  ...
  lintOptions {
    checkDependencies true
  }
}

// build.gradle.kts
android {
  ...
  lint {
    isCheckDependencies = true
  }
}

As tarefas de lint agora podem ser atualizadas

Se as origens e os recursos de um módulo não tiverem sido modificados, a tarefa de análise do lint para o módulo não precisa ser executada novamente. Quando isso acontece, a execução da tarefa aparece como "UP-TO-DATE" na saída do Gradle. Com essa mudança, ao executar o lint em um módulo de aplicativo com checkDependencies = true, apenas os módulos que foram modificados precisarão executar a análise. Como resultado, o lint pode ser executado ainda mais rapidamente.

A tarefa de relatório do lint também não precisa ser executada se as entradas não tiverem sido modificadas. Um problema conhecido relacionado é que não há saída de texto do lint impressa em stdout quando a tarefa do lint está atualizada (problema 191897708).

Como executar o lint em módulos de recursos dinâmicos

O AGP não é mais compatível com a execução do lint em módulos de recursos dinâmicos. A execução do lint no módulo de aplicativo correspondente executa o lint nos módulos de recursos dinâmicos e inclui todos os problemas no relatório do lint do app. Um problema conhecido relacionado é que, ao executar o lint com checkDependencies = true em um módulo de app, as dependências da biblioteca de recursos dinâmicos não são verificadas, a menos que também sejam dependências de app (problema #191977888).

Como executar o lint apenas na variante padrão

A execução de ./gradlew :app:lint agora executa o lint apenas para a variante padrão. Nas versões anteriores do AGP, o lint era executado para todas as variantes.

Avisos de classes ausentes no redutor R8

O R8 processa com mais precisão e consistência as classes ausentes e a opção -dontwarn. Portanto, comece a avaliar os avisos de classes ausentes emitidos pelo R8.

Quando o R8 encontra uma referência de classe que não está definida no seu app ou em uma das dependências, ele emite um alerta que aparece na saída do build. Exemplo:

R8: Missing class: java.lang.instrument.ClassFileTransformer

Esse alerta significa que a definição de classe java.lang.instrument.ClassFileTransformer não foi encontrada ao analisar o código do app. Embora isso geralmente signifique que há um erro, é possível ignorar esse aviso. Dois motivos comuns para ignorar o aviso são:

1. As bibliotecas voltadas à JVM e a classe ausente são do tipo da biblioteca JVM, como no exemplo acima.

2. Uma das dependências usa uma API somente para tempo de compilação.

Você pode ignorar um alerta de classe ausente adicionando uma regra -dontwarn ao arquivo proguard-rules.pro. Exemplo:

-dontwarn java.lang.instrument.ClassFileTransformer

Por conveniência, o AGP gera um arquivo que contém todas as regras possivelmente ausentes, gravando-as em um caminho de arquivo como o seguinte: app/build/outputs/mapping/release/missing_rules.txt. Adicione as regras ao arquivo proguard-rules.pro para ignorar os avisos.

No AGP 7.0, as mensagens de classes ausentes vão aparecer como alertas, e você pode transformá-las em erros configurando android.r8.failOnMissingClasses = true em gradle.properties. No AGP 8.0, esses alertas se tornarão erros que corromperão o build. É possível manter o comportamento do AGP 7.0 adicionando a opção -ignorewarnings ao arquivo proguard-rules.pro, mas isso não é recomendado.

O cache de build do Plug-in do Android para Gradle foi removido

O cache de build do AGP foi removido no AGP 4.1. Introduzido no AGP 2.3 para complementar o cache de build do Gradle, o cache de build do AGP foi totalmente substituído pelo do Gradle no AGP 4.1. Essa mudança não afeta o tempo de build.

No AGP 7.0, as propriedades android.enableBuildCache, android.buildCacheDir e cleanBuildCache foram removidas.

Usar o código-fonte Java 11 no seu projeto

Agora, é possível compilar até o código-fonte Java 11 no projeto do app, o que permite usar recursos de linguagem mais recentes, como métodos de interface privados, o operador losango para classes anônimas e a sintaxe de variáveis local para parâmetros lambda.

Para ativar esse recurso, defina compileOptions como a versão Java desejada e defina compileSdkVersion como 30 ou mais:

// 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 removidas:

• compile
  Dependendo do caso de uso, foi substituído por api ou implementation.
  Também se aplica a variantes *Compile, por exemplo: debugCompile.
• provided
  Foi substituído por compileOnly.
  Também se aplica a variantes *Provided, por exemplo: releaseProvided.
• apk
  Foi substituído por runtimeOnly.
• publish
  Foi substituído por runtimeOnly.

Na maioria dos casos, o Assistente de upgrade para AGP migra seu projeto automaticamente para as novas configurações.

Mudança do caminho de classe ao compilar com o Plug-in do Android para Gradle

Se você está compilando com o Plug-in do Android para Gradle, seu caminho de classe de compilação pode mudar. Como o AGP agora usa configurações api/implementation internamente, alguns artefatos podem ser removidos do caminho de classe da compilação. Se você precisa de uma dependência do AGP durante a compilação, é necessário que ela seja adicionada como uma dependência explícita.

Não é possível adicionar bibliotecas nativas em uma pasta de recursos Java

Antes, era possível adicionar uma biblioteca nativa a uma pasta de recursos Java e registrar essa pasta usando android.sourceSets.main.resources.srcDirs para que a biblioteca nativa fosse extraída e adicionada ao APK final. A partir do AGP 7.0, esse recurso deixou de ter suporte e as bibliotecas nativas que estiverem em uma pasta de recursos Java serão ignoradas. Em vez disso, use o método DSL destinado a bibliotecas nativas, android.sourceSets.main.jniLibs.srcDirs. Para 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 o plug-in Kotlin Multiplatform 1.5.0 e versões mais recentes. Os projetos que usam o suporte Kotlin Multiplatform precisam ser atualizados para o Kotlin 1.5.0 para usar o Plug-in do Android para Gradle 7.0.0. Como alternativa, você pode fazer downgrade do Plug-in do Android para Gradle para a versão 4.2.x, embora isso não seja recomendado.

Para mais informações, consulte KT-43944.

Saída do lint ausente

Não há saída de texto do lint impressa em stdout quando a tarefa do lint está atualizada (problema 191897708). Para saber mais, consulte Mudanças de comportamento do lint. Esse problema será corrigido no Plug-in do Android para Gradle 7.1.

Nem todas as dependências da biblioteca de recursos dinâmicos são verificadas no lint

Ao executar o lint com checkDependencies = true em um módulo de app, as dependências da biblioteca de recursos dinâmicos não são verificadas, a menos que também sejam dependências de apps (problema 191977888). Como alternativa, a tarefa do lint pode ser executada nessas bibliotecas. Para saber mais, consulte Mudanças de comportamento do lint.