Plug-in do Android para Gradle 7.1.0 (janeiro de 2022)

O Plug-in do Android para Gradle 7.1.0 é uma versão principal que inclui vários novos recursos e melhorias.

Compatibilidade

	Versão mínima	Versão padrão
Gradle	7.2	7.2
Ferramentas de build do SDK	30.0.3	30.0.3
NDK	N/A	21.4.7075529
JDK	11	11

A tarefa de análise do lint agora pode ser armazenada em cache

O AndroidLintAnalysisTask agora é compatível com o cache de build do Gradle (link em inglês). Se você ativar o cache de build definindo org.gradle.caching=true no arquivo gradle.properties, a tarefa de análise do lint vai receber a saída do cache de build quando possível.

A tarefa de análise do lint geralmente é o maior gargalo ao executar o lint com o Plug-in do Android para Gradle. Portanto, ativar o cache de build melhora a velocidade de build ao executar o lint em muitas situações. O desempenho terá uma melhoria perceptível. Por exemplo, se você tiver um projeto com vários módulos e limpar o diretório de build antes de executar o lint no servidor de CI.

Os módulos C/C++ agora podem referenciar outros módulos C/C++ no mesmo projeto.

Um módulo do Gradle para Android com código C/C++ agora pode ser configurado para referenciar arquivos principais e código da biblioteca em outro módulo do Gradle. O protocolo Prefab (link em inglês) é usado para comunicar os cabeçalhos e as bibliotecas entre os módulos do Gradle.

Requisitos

• O módulo de consumo precisa ser CMake, e não ndk-build. A compatibilidade com o ndk-build exige uma atualização futura do NDK. O módulo de publicação pode ser CMake ou ndk-build.

• O módulo de consumo precisa ativar prefab no arquivo build.gradle.

android {
  buildFeatures {
    prefab true
  }
}

• O módulo de publicação precisa ativar prefabPublishing no arquivo build.gradle.

android {
  buildFeatures {
    prefabPublishing true
  }
}

• O módulo de consumo precisa referenciar o módulo de publicação adicionando uma linha no bloco dependencies do arquivo build.gradle. Por exemplo:

dependencies {
  implementation project(':mylibrary')
}

• O módulo de publicação precisa expor um pacote usando uma seção prefab. Por exemplo:

android {
  prefab {
    mylibrary {
      libraryName "libmylibrary"
      headers "src/main/cpp/include"
    }
  }
}

• O arquivo CMakeLists.txt do módulo de consumo pode usar find_package() para localizar o pacote publicado pelo módulo de produção. Por exemplo:

find_package(mylibrary REQUIRED CONFIG)
target_link_libraries(
  myapplication
  mylibrary::mylibrary)

• É preciso haver um STL para todo o aplicativo. Por exemplo, os módulos de consumo e publicação podem usar o STL compartilhado por C++.

   android {
      defaultConfig {
        externalNativeBuild {
          cmake {
            arguments '-DANDROID_STL=c++_shared'
          }
        }
      }
    }

Para mais detalhes sobre como configurar produtores e consumidores de AAR nativos com o AGP, consulte Dependências nativas com o AGP.

Configurações do repositório no arquivo settings.gradle

Quando um novo projeto é criado no Android Studio Bumblebee, o arquivo build.gradle de nível superior contém o bloco plugins, seguido pelo código para limpar o diretório de build:

plugins {
    id 'com.android.application' version '7.1.0-beta02' apply false
    id 'com.android.library' version '7.1.0-beta02' apply false
    id 'org.jetbrains.kotlin.android' version '1.5.30' apply false
}
task clean(type: Delete) {
  delete rootProject.buildDir
}

As configurações do repositório que estavam anteriormente no arquivo build.gradle de nível superior agora estão no arquivo settings.gradle:

pluginManagement {
  repositories {
    gradlePluginPortal()
    google()
    mavenCentral()
  }
}
dependencyResolutionManagement {
  repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
  repositories {
    google()
    mavenCentral()
  }
}
rootProject.name = 'GradleManagedDeviceTestingNew'
include ':app'

O arquivo build.gradle no nível de módulos não mudou. Portanto, use o arquivo build.gradle de nível superior e o arquivo settings.gradle para definir configurações de build que se aplicam a todos os módulos do projeto ou aos repositórios e dependências que se aplicam ao próprio Gradle. Use o arquivo build.gradle do módulo para definir configurações de build específicas para um determinado módulo do projeto.

Redutor de recursos melhorado

O Android Studio Bumblebee inclui um redutor de recursos aprimorado que ajuda a diminuir o tamanho do app.

Suporte para apps com recursos dinâmicos

A implementação padrão do redutor de recursos do Android foi atualizada no Plug-in do Android para Gradle 7.1.0-alpha09. A nova implementação oferece suporte à redução de apps com recursos dinâmicos.

Mais reduções experimentais no tamanho de apps

A nova implementação de redutor de recursos pode reduzir ainda mais o tamanho do app reduzido modificando a tabela de recursos para remover recursos de valor não utilizados e referências a recursos de arquivo não utilizados. O novo redutor de recursos pode excluir completamente os recursos de arquivo não utilizados, reduzindo o tamanho do app. Esse comportamento ainda não está ativado por padrão, mas é possível ativá-lo adicionando a opção experimental android.experimental.enableNewResourceShrinker.preciseShrinking=true ao arquivo gradle.properties do projeto.

Relate qualquer problema encontrado com o novo redutor de recursos ou a sinalização experimental. Para ajudar a diagnosticar problemas ou, como uma solução temporária, você pode voltar à implementação anterior adicionando android.enableNewResourceShrinker=false ao gradle.properties do projeto. O novo redutor substitui recursos baseados em arquivos não utilizados por arquivos mínimos um pouco diferentes do anterior, mas não é esperado que isso afete o ambiente de execução.

A implementação antiga está programada para ser removida no Plug-in do Android para Gradle 8.0.0.

Publicação de variantes de build

O Plug-in do Android para Gradle 7.1.0 e versões mais recentes permitem configurar quais variantes de build serão publicadas em um repositório Apache Maven. O AGP cria um componente com uma ou várias variantes de build com base na nova DSL de publicação, que pode ser usada para personalizar uma publicação para um repositório Maven. Em comparação com versões anteriores, isso também evita trabalhos desnecessários, já que nenhum componente será criado por padrão. Para saber mais, consulte o exemplo de código de publicação.

Publicar JAR do Javadoc

O AGP 7.1.0 e versões mais recentes permite que você gere um Javadoc de origens Java e Kotlin e publique arquivos Javadoc JAR, além de AARs para projetos de biblioteca. O Javadoc é adicionado aos arquivos POM e Gradle Module Metadata{:.external} (link em inglês). Ative esse recurso adicionando withJavadocJar() no bloco de publicação singleVariant ou multipleVariants. Para saber mais, consulte o exemplo de código de opções de publicação.

Publicar JAR de origens

O AGP 7.1.0 e versões mais recentes permitem que você publique arquivos JAR de origem Java e Kotlin, além de AARs para projetos de biblioteca. As origens são adicionadas aos arquivos POM e Gradle Module Metadata{:.external} (link em inglês). É possível ativar esse recurso adicionando withSourcesJar() no bloco de publicação singleVariant ou multipleVariants. Para saber mais, consulte o exemplo de código de opções de publicação.

Mudança semântica de bloco do lint

Todos os métodos de lint que substituem o nível de gravidade de um problema (enable, disable/ignore, informational, warning, error, fatal) agora respeitam a ordem de configuração. Por exemplo, definir um problema como fatal em finalizeDsl() agora substitui a desativação na DSL principal. Para ver mais informações, consulte os documentos de referência de bloco lint{} e o fluxo de build e pontos de extensão do Android.

Compatibilidade com o Safe Args de navegação

As APIs AGP de que o plug-in do Gradle Safe Args de navegação depende foram removidas. O AGP 7.1 não funciona com o Safe Args de navegação nas versões 2.4.0-rc1 ou 2.4.0, mas funciona com as versões 2.5.0-alpha01 e 2.4.1. Enquanto isso, como solução alternativa, você pode usar o AGP 7.1 com um build de snapshot do Safe Args de navegação, Navigation 2.5.0-SNAPSHOT. Para usar o build do snapshot, siga as instruções para snapshot com o ID de build 8054565.

Além disso, as versões 2.4.1 e 2.5.0 do Safe Args de navegação não funcionam mais com o AGP 4.2. Para usar essas versões do Safe Args, é necessário usar o AGP 7.0 ou mais recente.

Desativar a criação automática de componentes

A partir do AGP 8.0, a criação automática de componentes vai ser desativada por padrão. Atualmente, o AGP 7.1 cria automaticamente um componente para cada variante de build, que tem o mesmo nome da variante, e um componente all que contém todas as variantes. A criação automática de componentes será desativada. Para fazer a transição para o novo comportamento, desative manualmente a criação automática de componentes configurando android.disableAutomaticComponentCreation como true.. Para mais informações, consulte Usar o plug-in Maven Publish.

Compatibilidade do Monitoramento de desempenho do Firebase

O AGP 7.1 não é compatível com o plug-in do Gradle para o Monitoramento de desempenho do Firebase versão 1.4.0 e anteriores. O Assistente de upgrade do AGP não atualizará automaticamente o plug-in para a versão 1.4.1. Portanto, se você estiver usando firebase-perf e quiser fazer upgrade do AGP para a versão 7.1, será necessário fazer esse upgrade específico manualmente.

Problemas conhecidos

Esta seção descreve problemas conhecidos que existem no Plug-in do Android para Gradle 7.1.0.

Problemas ao testar a unidade de um projeto de app que usa o plug-in do Hilt

O caminho de classe do teste de unidade contém as classes de apps não instrumentados. Isso significa que o Hilt não instrumenta as classes do app para processar a injeção de dependência ao executar testes de unidade.

Esse problema vai ser corrigido na versão 7.1.1. Consulte o problema 213534628.