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 versão 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 Ferramentas de linha de comando do SDK do Android atual.

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, por meio da interface Artefatos. Esses artefatos, como o manifesto integrado, podem ser conseguidos e personalizados com segurança usando códigos e plug-ins de terceiros.

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

Mudanças de comportamento do lint

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

Lint aprimorado para dependências de biblioteca

A execução do lint com checkDependencies = true agora está mais rápida do que antes. Para projetos do Android compostos por um app com dependências de biblioteca, é recomendável definir checkDependencies como true, conforme mostrado abaixo. Em seguida, recomendamos 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 de novo. Quando isso acontece, a execução da tarefa aparece como "UP-TO-DATE" (atualizada) na saída do Gradle. Com essa mudança, ao executar o lint em um módulo de aplicativo com checkDependencies = true, apenas os módulos que foram modificados precisarão executar a análise. Como resultado, o lint pode ser executado ainda mais rapidamente.

A tarefa de relatório do lint também não 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 seria executado para todas as variantes.

Avisos de classes ausentes no redutor R8

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

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

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

Esse alerta significa que a definição de classe java.lang.instrument.ClassFileTransformer não foi encontrada ao analisar o código do app. Geralmente, isso significa que há um erro, é possível ignorar esse alerta. Descubra a seguir dois motivos comuns para ignorá-lo:

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 -dontwarn regra ao seu proguard-rules.pro arquivo. Exemplo:

-dontwarn java.lang.instrument.ClassFileTransformer

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

No AGP 7.0, as mensagens de classes ausentes 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 vão corromper o build. É possível manter o comportamento do AGP 7.0 adicionando a opção -ignorewarnings ao seu proguard-rules.pro arquivo, 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, a propriedade android.enableBuildCache, a propriedade android.buildCacheDir, e a tarefa cleanBuildCache foram removidas.

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

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

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

// 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
  Isto foi substituído por compileOnly.
  Também se aplica a variantes *Provided, por exemplo: releaseProvided.
• apk
  Isto foi substituído por runtimeOnly.
• publish
  Isto foi substituído por runtimeOnly.

Na maioria dos casos, o AGP Assistente de upgrade 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 as 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. Saiba mais em 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 Multiplatform plugin 1.5.0 e versões mais recentes. Os projetos que usam o Kotlin Multiplatform precisam ser atualizados para o Kotlin 1.5.0 para usar o Plug-in do Android para Gradle 7.0.0. Como alternativa, você pode fazer downgrade do Plug-in do Android para Gradle para a versão 4.2.x, embora isso não seja recomendado.

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

Saída do lint ausente

Não há saída de texto do lint impressa em stdout quando a tarefa do lint está atualizada (problema 191897708). Para saber o contexto, consulte Mudanças de comportamento do lint. Esse problema vai 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 o contexto, consulte Mudanças de comportamento do lint.