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

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 do build ao executar o lint em muitas situações. A performance vai melhorar perceptivelmente. 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 é usado para comunicar os arquivos principais e as bibliotecas entre os módulos do Gradle.

Requisitos

• O módulo de consumo precisa ser CMake, e não ndk-build. O suporte para 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 ao bloco dependencies do arquivo build.gradle. Exemplo:

dependencies {
  implementation project(':mylibrary')
}

• O módulo de publicação precisa expor um pacote usando uma seção prefab. 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. Exemplo:

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

• É preciso ter 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 explicações 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 mais alto 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 mais alto 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 os repositórios e as dependências que se aplicam ao próprio Gradle. Use o arquivo build.gradle de nível de módulo para definir configurações de build específicas para um determinado módulo no projeto.

Redutor de recursos melhorado

O Android Studio Bumblebee inclui um redutor de recursos melhorado que ajuda a reduzir 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 pode reduzir ainda mais o tamanho do app, modificando a tabela de recursos para remover recursos de valor não usados 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 ativar adicionando a opção experimental android.experimental.enableNewResourceShrinker.preciseShrinking=true ao arquivo gradle.properties do projeto.

Informe qualquer problema que você encontrar 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 à 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 tenha impacto no 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 que você configure quais variantes de build são publicadas em um repositório Apache Maven. O AGP cria um componente com uma ou mais 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 é 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 permitem que você gere um Javadoc de origens Java e Kotlin e publique arquivos JAR do Javadoc, 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 publicar 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 ou 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 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 para o 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, o Navigation 2.5.0-SNAPSHOT. Para usar o build de 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 e versões mais recentes.

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 vai ser desativada. Para fazer a transição para o novo comportamento, desative manualmente a criação automática de componentes definindo 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 mais antigas. O AGP Upgrade Assistant não vai atualizar automaticamente o plug-in para a versão 1.4.1. Portanto, se você está usando firebase-perf e quer fazer upgrade do AGP para a versão 7.1, é 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 instrumentadas. 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 será corrigido na versão 7.1.1. Consulte o problema 213534628.