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.

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á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.

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

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

1. As bibliotecas destinadas à JVM e a classe ausente são da JVM tipo de biblioteca (como no exemplo acima).

2. 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 por api ou implementation.
  Também se aplica a variantes *Compile, por exemplo: debugCompile.
• provided
  Ele foi substituído por compileOnly.
  Isso também se aplica a variantes *Provided, por exemplo: releaseProvided.
• apk
  Ele foi substituído por runtimeOnly.
• publish
  Ele foi substituído por runtimeOnly.

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.