Notas da versão do Plug-in do Android para Gradle

O sistema de compilação do Android Studio é baseado no Gradle, e o Plug-in do Android para Gradle adiciona vários recursos específicos para a criação de apps Android. Embora o plug-in do Android normalmente seja atualizado no Android Studio, o plug-in e o resto do sistema do Gradle podem ser executados e atualizados de forma independente do Android Studio.

Esta página explica como manter suas ferramentas do Gradle atualizadas e quais são as atualizações recentes.

Para ver um resumo detalhado das próximas alterações interruptivas no Plug-in do Android para Gradle, consulte o cronograma do plug-in.

Para saber como configurar seus builds do Android com o Gradle, consulte estas páginas:

• Configurar seu build
• Referência de DSL do Plug-in do Android para Gradle
• Referência de DSL do Gradle (link em inglês)
• Guia do usuário sobre a performance do Gradle (link em inglês)

Para mais informações sobre o sistema de compilação do Gradle, consulte o Guia do usuário do Gradle (link em inglês).

Atualizar o Plug-in do Android para Gradle

Ao atualizar o Android Studio, talvez seja solicitado que você atualize automaticamente o Plug-in do Android para Gradle para a versão mais recente disponível. Você pode aceitar a atualização ou especificar manualmente uma versão com base nos requisitos de build do seu projeto.

Você pode especificar a versão do plug-in no menu File > Project Structure > Project no Android Studio ou no arquivo build.gradle do nível superior. A versão do plug-in se aplica a todos os módulos criados no projeto do Android Studio em questão. O exemplo abaixo define o plug-in para a versão 7.2.2 do arquivo build.gradle:

plugins {
    id 'com.android.application' version '7.2.2' apply false
    id 'com.android.library' version '7.2.2' apply false
    id 'org.jetbrains.kotlin.android' version '1.5.31' apply false
}

plugins {
    id("com.android.application") version "7.2.2" apply false
    id("com.android.library") version "7.2.2" apply false
    id("org.jetbrains.kotlin.android") version "1.5.31" apply false
}

Atenção: não use dependências dinâmicas em números de versão, como 'com.android.tools.build:gradle:2.+'. O uso desse recurso pode resultar em atualizações inesperadas e dificuldades para resolver diferenças de versão.

Se a versão especificada do plug-in não tiver sido transferida por download, o Gradle fará o download da próxima vez que você criar o projeto ou clicar em File > Sync Project with Gradle Files na barra de menus do Android Studio.

Atualizar o Gradle

Ao atualizar o Android Studio, você poderá receber uma solicitação para também atualizar o Gradle para a versão mais recente disponível. Você pode aceitar a atualização ou especificar manualmente uma versão com base nos requisitos de build do projeto.

A tabela a seguir lista qual versão do Gradle é necessária para cada versão do Plug-in do Android para Gradle. Para ter a melhor performance, use a versão mais recente possível do Gradle e do plug-in.

Você pode especificar a versão do Gradle no menu File > Project Structure > Project no Android Studio ou atualizar sua versão do Gradle usando a linha de comando. A maneira recomendada é usar a ferramenta de linha de comando Gradle Wrapper (link em inglês), que atualiza os scripts gradlew. O exemplo abaixo define a versão do Gradle como 7.5.1 usando o Gradle Wrapper. É preciso executar esse comando duas vezes para fazer upgrade do Gradle e do próprio Gradle Wrapper. Para ver mais informações, consulte Como fazer upgrade do Gradle Wrapper (link em inglês).

./gradle wrapper --gradle-version --7.5.1

No entanto, esse processo pode falhar em alguns casos. Por exemplo, se você acabou de atualizar o AGP e ele não é mais compatível com a versão atual do Gradle. Nesse caso, é necessário editar a referência de distribuição do Gradle no arquivo gradle/wrapper/gradle-wrapper.properties. O exemplo abaixo define a versão do Gradle como 7.5.1 no arquivo gradle-wrapper.properties.

...
distributionUrl = "https\://services.gradle.org/distributions/gradle-7.5.1-bin.zip"
...

Plug-in do Android para Gradle e compatibilidade com o Android Studio

O sistema de compilação do Android Studio é baseado no Gradle, e o Plug-in do Android para Gradle adiciona vários recursos específicos para a criação de apps Android. A tabela abaixo lista qual versão do Plug-in do Android para Gradle é necessária para cada versão do Android Studio.

Para mais informações sobre as novidades do Plug-in do Android para Gradle, acesse as notas da versão.

Mudanças do controle de versões (novembro de 2020)

Estamos atualizando o número da versão do Plug-in do Android para Gradle (AGP, na sigla em inglês) para melhorar a integração com a ferramenta de build Gradle.

Veja as principais mudanças:

• O AGP agora usará um controle de versões semântico, e as alterações interruptivas serão direcionadas para versões principais.

• Haverá uma versão principal do AGP lançada por ano, alinhada à versão principal do Gradle.

• Após o AGP 4.2, virá a versão 7.0, que exigirá um upgrade para o Gradle versão 7.x. Cada vez que uma versão do AGP com mudanças significativas é liberada, um upgrade de versão significativo na ferramenta Gradle se faz necessário.

• O uso das APIs será descontinuado com aproximadamente um ano de antecedência, e a funcionalidade de substituição será disponibilizada simultaneamente. As APIs descontinuadas vão ser removidas cerca de um ano depois, quando houver uma atualização de larga escala.

7.2.0 (maio de 2022)

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

Aviso e análise do Jetifier do Build Analyzer

O Build Analyzer agora mostra um aviso se o arquivo gradle.properties do projeto inclui android.enableJetifier=true. Essa sinalização foi introduzida em uma versão anterior do Android Studio para ativar o AndroidX em bibliotecas que não oferecem suporte a ele. No entanto, o ecossistema das bibliotecas passou a oferecer suporte ao AndroidX de forma nativa, e a sinalização Jetifier provavelmente não é mais necessária para o projeto. A sinalização também pode deixar a performance do build mais lenta. Se esse aviso aparecer, você pode executar uma verificação no Build Analyzer para confirmar se a sinalização pode ser removida.

Suporte aos recursos de teste

O Android Studio Chipmunk Beta 1 e versões mais recentes oferece suporte aos recursos de teste do Android e do Java. Para mais informações, consulte o guia do Gradle sobre como usar os recursos de teste (em inglês) e descubra como usar esses recursos em um projeto Java.

Para ativar os recursos de teste no módulo da biblioteca Android, adicione o código abaixo ao arquivo build.gradle no nível da biblioteca:

android {
    testFixtures {
        enable true

        // enable testFixtures's android resources (disabled by default)
        // androidResources true
    }
}

Por padrão, a publicação da biblioteca também publica as AARs dos recursos de teste com a biblioteca principal. O arquivo de metadados do módulo do Gradle vai conter informações para que o Gradle possa consumir o artefato certo ao solicitar o componente testFixtures.

Para desativar a publicação dos recursos da AAR de uma biblioteca na variante de lançamento, adicione o código abaixo ao arquivo build.gradle no nível da biblioteca:

afterEvaluate {
    components.release.withVariantsFromConfiguration(
        configurations.releaseTestFixturesVariantReleaseApiPublication) { skip() }
    components.release.withVariantsFromConfiguration(
        configurations.releaseTestFixturesVariantReleaseRuntimePublication) { skip() }
}

Para consumir as AARs dos recursos de teste de uma biblioteca Android publicada, use o método auxiliar testFixtures() do Gradle.

dependencies {
    testImplementation testFixtures('com.example.company:publishedLib:1.0')
}

Por padrão, o lint vai analisar as fontes dos recursos de teste. Você pode configurar o lint para ignorar as fontes dos recursos de teste desta maneira:

android {
    lint {
        ignoreTestFixturesSources true
    }
}

Não há suporte para raízes de conteúdo duplicado

A partir do AGP 7.2, não é mais possível compartilhar o mesmo diretório de origem entre vários conjuntos de origem. Por exemplo, não é possível usar as mesmas origens para testes de unidade e de instrumentação. Para saber mais, consulte Mudar as configurações dos conjuntos de origem padrão.

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 de criação ao executar o lint em muitas situações. Você vai ver uma melhoria perceptível no desempenho. 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 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 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 ver uma explicação mais detlhada sobre como configurar produtores e consumidores de AAR nativos com o AGP, consulte as 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 de nível mais alto build.gradle e o arquivo settings.gradle para definir as configurações do build que se aplicam a todos os módulos do projeto ou os repositórios e dependências que se aplicam ao próprio Gradle. Use o arquivo build.gradle no nível de módulo para definir configurações do build específicas para um determinado módulo dentro do 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 ao modificar a tabela 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 o 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 às 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, permite 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 mais antigas, 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, 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 (link em inglês). Ative esse recurso adicionando withJavadocJar() no bloco de publicação singleVariant ou no 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, permite publicar arquivos JAR de origem Java e Kotlin, além de AARs para projetos de bibliotecas. As origens são adicionadas aos arquivos POM e Gradle Module Metadata (link em inglês). É possível ativar esse recurso adicionando withSourcesJar() no bloco de publicação singleVariant ou no 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 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 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 a versão do snapshot, siga as instruções para snapshot com o código 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. A fim de 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 aplicativos 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.

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, independentemente 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 (links em inglês) 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. Veja 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, e executar o lint usando ./gradlew :app:lint, que analisará todos os módulos de dependência em paralelo e produzirá 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 precisará ser executada novamente. 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 precisará 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 executará o lint nos módulos de recursos dinâmicos e incluirá 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. Por 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, mas é possível ignorar esse alerta. Veja a seguir dois motivos comuns para ignorá-lo:

1. As bibliotecas voltados à 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. Por 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 aparecerão 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 compilação.

No AGP 7.0, as propriedades android.enableBuildCache e 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
  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 migrará 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 saber mais, veja 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 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 ver mais contexto, 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 ver mais contexto, consulte Mudanças de comportamento do lint.

4.2.0 (março de 2021)

Compatibilidade

Novos recursos

Esta versão do Plug-in do Android para Gradle inclui os novos recursos a seguir.

Versão 8 da linguagem Java como padrão

A partir da versão 4.2, o AGP usará o nível de linguagem Java 8 por padrão. O Java 8 oferece acesso a diversos recursos de linguagem mais recentes, incluindo expressões lambda, referências de método e métodos de interface estática. Para ver a lista completa de recursos compatíveis, consulte a documentação do Java 8.

Para manter o comportamento antigo, especifique o Java 7 explicitamente no arquivo build.gradle.kts ou build.gradle do módulo:

// build.gradle

android {
  ...
  compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_7
    targetCompatibility JavaVersion.VERSION_1_7
  }
  // For Kotlin projects, compile to Java 6 instead of 7
  kotlinOptions {
    jvmTarget = "1.6"
  }
}

// build.gradle.kts

android {
  ...
  compileOptions {
    sourceCompatibility = JavaVersion.VERSION_1_7
    targetCompatibility = JavaVersion.VERSION_1_7
  }
  // For Kotlin projects, compile to Java 6 instead of 7
  kotlinOptions {
    jvmTarget = "1.6"
  }
}

Novo compilador de recursos do JVM

Um novo compilador de recursos JVM na ferramenta do Plug-in do Android para Gradle 4.2 substitui partes do compilador de recursos AAPT2, possivelmente melhorando a performance do build, especialmente em máquinas Windows. O novo compilador de recursos da JVM é ativado por padrão.

A assinatura de v3 e v4 agora é compatível

O Plug-in do Android para Gradle 4.2 agora é compatível com os formatos de assinatura APK v3 e APK v4. Para ativar um ou ambos os formatos no seu build, adicione as seguintes propriedades ao arquivo build.gradle ou build.gradle.kts no nível do módulo:

// build.gradle

android {
  ...
  signingConfigs {
    config {
        ...
        enableV3Signing true
        enableV4Signing true
    }
  }
}

// build.gradle.kts

android {
   ...
   signingConfigs {
      config {
          ...
          enableV3Signing = true
          enableV4Signing = true
      }
   }
}

A assinatura do APK v4 permite implantar rapidamente APKs grandes usando a instalação do APK incremental do ADB no Android 11. Essa nova sinalização cuida da etapa de assinatura do APK no processo de implantação.

Configurar a assinatura de apps por variante

Agora, é possível ativar ou desativar a assinatura de apps no Plug-in do Android para Gradle por variante.

Este exemplo mostra como definir a assinatura de apps por variante usando o método onVariants() em Kotlin ou Groovy:

androidComponents {
    onVariants(selector().withName("fooDebug"), {
        signingConfig.enableV1Signing.set(false)
        signingConfig.enableV2Signing.set(true)
    })

Nova propriedade do Gradle: android.native.buildOutput

Para reduzir a sobrecarga na saída de build, o AGP 4.2 filtra mensagens de builds nativos que usam CMake e ndk-build, exibindo apenas a saída do compilador C/C++ por padrão. Antes disso, uma linha de saída era gerada para cada arquivo criado, resultando em uma grande quantidade de mensagens informativas.

Se você quiser ver toda a saída nativa, defina a nova propriedade do Gradle android.native.buildOutput como verbose.

É possível definir essa propriedade no arquivo gradle.properties ou pela linha de comando.

gradle.properties
android.native.buildOutput=verbose

Linha de comando
-Pandroid.native.buildOutput=verbose

O valor padrão dessa propriedade é quiet.

Mudança de comportamento para arquivos gradle.properties

A partir do AGP 4.2, não é mais possível substituir as propriedades Gradle de subprojetos. Em outras palavras, se você declarar uma propriedade em um arquivo gradle.properties em um subprojeto em vez do projeto raiz, ele será ignorado.

Como exemplo, em versões anteriores, o AGP leria valores de projectDir/gradle.properties, projectDir/app/gradle.properties, projectDir/library/gradle.properties etc. Para módulos de apps, se a mesma propriedade do Gradle estivesse presente em projectDir/gradle.properties e projectDir/app/gradle.properties, o valor de projectDir/app/gradle.properties teria precedência.

No AGP 4.2, esse comportamento foi mudado, e o AGP não carrega valores de gradle.properties em subprojetos (por exemplo, projectDir/app/gradle.properties). Essa mudança reflete o novo comportamento do Gradle oferece suporte ao armazenamento em cache da configuração (links em inglês).

Para ver mais informações sobre como definir valores em arquivos gradle.properties, consulte os documentos do Gradle (em inglês).

Mudanças na configuração e compatibilidade do Gradle

Quando a ferramenta de compilação do Gradle é executada no Android Studio, ela usa o JDK empacotado no Studio. Em versões anteriores, o JDK 8 era incluído no Studio. No entanto, na versão 4.2, o JDK 11 agora é incluído. Ao usar o novo JDK incluído para executar o Gradle, isso pode resultar em alguma incompatibilidade ou afetar o desempenho do JVM devido a alterações no coletor de lixo. Esses problemas estão descritos abaixo.

Compatibilidade do Studio com o Plug-in do Android para Gradle (AGP)

O Android Studio 4.2 pode abrir projetos que usam o AGP 3.1 e mais recente, desde que o AGP esteja executando o Gradle 4.8.1 ou versões mais recentes. Para ver mais informações sobre a compatibilidade do Gradle, consulte Atualizar o Gradle.

Como otimizar os builds do Gradle para o JDK 11

Essa atualização para o JDK 11 afeta a configuração padrão do coletor de lixo da JVM, já que o JDK 8 usa o coletor de lixo paralelo, enquanto o JDK 11 usa o coletor de lixo G1 (link em inglês).

Para potencialmente melhorar o desempenho do build, recomendamos testar seus builds do Gradle com o coletor de lixo paralelo. Em gradle.properties, defina o seguinte:

org.gradle.jvmargs=-XX:+UseParallelGC

Se já houver outras opções definidas nesse campo, adicione uma nova opção:

org.gradle.jvmargs=-Xmx1536m -XX:+UseParallelGC

Para medir a velocidade do build com diferentes configurações, consulte Criar perfil para seu build.

Arquivos DEX descompactados em APKs quando o valor de minSdk for igual a 28 ou mais

Por padrão, agora o AGP agrupa os arquivos DEX descompactados em APKs quando o valor de minSdk é igual a 28 ou mais. Isso causa um aumento no tamanho do APK, mas resulta em um tamanho de instalação menor no dispositivo, com tamanho de download praticamente igual.

Para forçar o AGP a empacotar os arquivos DEX compactados, adicione o código abaixo ao arquivo build.gradle:

android {
    packagingOptions {
        dex {
            useLegacyPackaging true
        }
    }
}

Usar a DSL para empacotar bibliotecas nativas compactadas

Recomendamos empacotar bibliotecas nativas em formato não compactado, porque isso resulta em arquivos menores de instalação e download do app e em um tempo de carregamento mais rápido para os usuários. No entanto, se você quiser que o Plug-in do Android para Gradle empacote bibliotecas nativas compactadas ao criar seu app, defina useLegacyPackaging como true no arquivo build.gradle do app:

android {
    packagingOptions {
        jniLibs {
            useLegacyPackaging true
        }
    }
}

A sinalização useLegacyPackaging substitui o atributo de manifesto extractNativeLibs. Para mais informações, consulte a nota da versão Bibliotecas nativas empacotadas descompactadas por padrão.

4.1.0 (agosto de 2020)

Compatibilidade

Novos recursos

Esta versão do Plug-in do Android para Gradle inclui os novos recursos a seguir.

Compatibilidade com DSL do script Kotlin

Para ajudar a melhorar a experiência de edição para usuários do buildscript do Kotlin, a DSL e as APIs do Plug-in do Android para Gradle 4.1 agora estão definidas em um conjunto de interfaces do Kotlin separado das classes de implementação. O que isso significa:

• Nulidade e mutabilidade agora são explicitamente declaradas em tipos Kotlin.
• A documentação gerada por essas interfaces é publicada na referência da API Kotlin.
• A superfície da API do Plug-in do Android para Gradle é claramente definida para tornar os builds do Android menos instáveis no futuro.

Os tipos de coleção projetados para serem transformados em DSL agora são definidos de maneira uniforme como:

val collection: MutableCollectionType

Isso significa que não é mais possível escrever o seguinte em scripts Kotlin para algumas coleções compatíveis anteriormente:

collection = collectionTypeOf(...)

No entanto, a modificação da coleção é aceita de modo uniforme, de modo que collection += … e collection.add(...) agora funcionam em qualquer lugar.

Se você descobrir algum problema ao fazer upgrade de um projeto que usa as APIs Kotlin do Plug-in do Android para Gradle e a DSL, informe um bug.

Exportar dependências C/C++ de AARs

O Plug-in do Android para Gradle 4.0 adicionou a capacidade de importar pacotes Prefab em dependências de AAR. No AGP 4.1, agora é possível exportar bibliotecas do seu build nativo externo em um AAR para um projeto de biblioteca do Android.

Para exportar suas bibliotecas nativas, adicione o seguinte ao bloco android do arquivo build.gradle do projeto da biblioteca:

buildFeatures {
    prefabPublishing true
}

prefab {
    mylibrary {
      headers "src/main/cpp/mylibrary/include"
    }

    myotherlibrary {
        headers "src/main/cpp/myotherlibrary/include"
    }
}

buildFeatures {
    prefabPublishing = true
}

prefab {
    create("mylibrary") {
      headers = "src/main/cpp/mylibrary/include"
    }

    create("myotherlibrary") {
        headers = "src/main/cpp/myotherlibrary/include"
    }
}

Neste exemplo, as bibliotecas mylibrary e myotherlibrary do ndk-build ou do build nativo externo do CMake serão empacotadas no AAR produzido pelo build, e cada uma exportará os cabeçalhos do diretório especificado para os dependentes.

Compatibilidade com metadados R8 do Kotlin

O Kotlin usa metadados personalizados em arquivos de classe Java para identificar construções de linguagem Kotlin. O R8 agora é compatível com a manutenção e reescrita de metadados Kotlin para oferecer compatibilidade total com a redução de bibliotecas e aplicativos Kotlin que usam kotlin-reflect.

Para manter os metadados do Kotlin, adicione as seguintes regras keep:

-keep class kotlin.Metadata { *; }

-keepattributes RuntimeVisibleAnnotations

Isso instruirá o R8 a manter os metadados de Kotlin em todas as classes que são mantidas diretamente.

Para saber mais, consulte Como reduzir bibliotecas e aplicativos com Kotlin usando a reflexão Kotlin com R8 (link em inglês) no Medium.

Declarações em builds de depuração

Quando você criar a versão de depuração do app usando o Plug-in do Android para Gradle 4.1.0 e versões mais recentes, o compilador integrado (D8) reescreverá o código do seu app para permitir declarações no tempo de compilação. Assim, você sempre terá verificações de declaração ativas.

Mudanças de comportamento

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 compilação.

A tarefa cleanBuildCache e as propriedades android.enableBuildCache e android.buildCacheDir estão obsoletas e serão removidas no AGP 7.0. Atualmente, a propriedade android.enableBuildCache não tem efeito, enquanto a propriedade android.buildCacheDir e a tarefa cleanBuildCache estarão funcionais até o AGP 7.0 para excluir qualquer conteúdo do cache de compilação do AGP existente.

O tamanho dos apps que usam a redução de código foi significativamente diminuído

A partir dessa versão, os campos das classes R não são mais mantidos por padrão. Isso pode resultar em uma economia significativa no tamanho do APK para apps que permitem a redução de código. Isso não resultará em uma mudança de comportamento, a menos que você esteja acessando classes R por reflexão. Nesse caso, é necessário adicionar regras keep a essas classes R.

Renomeação da propriedade android.namespacedRClass para android.nonTransitiveRClass

A sinalização experimental android.namespacedRClass foi renomeada para android.nonTransitiveRClass.

Definido no arquivo gradle.properties, essa sinalização ativa o espaçamento de nomes da classe R de cada biblioteca para que a ela inclua apenas os recursos declarados na própria biblioteca e os recursos das dependências da biblioteca, reduzindo assim o tamanho da classe R dessa biblioteca.

DSL de Kotlin: renomeação de coreLibraryDesugaringEnabled

A opção de compilação DSL do Kotlin coreLibraryDesugaringEnabled foi mudada para isCoreLibraryDesugaringEnabled. Para mais informações sobre essa sinalização, consulte Suporte à simplificação de APIs do Java 8+ (Android Gradle Plugin 4.0.0+).

Propriedades de versão removidas da classe BuildConfig em projetos de biblioteca

Apenas em projetos de biblioteca, as propriedades BuildConfig.VERSION_NAME e BuildConfig.VERSION_CODE foram removidas da classe BuildConfig gerada porque esses valores estáticos não refletiam os valores finais do código e nome da versão do aplicativo, o que podia causar confusão. Além disso, esses valores foram descartados durante a mesclagem do manifesto.

Em uma versão futura do Plug-in do Android para Gradle, as propriedades versionName e versionCode também serão removidas da DSL para bibliotecas. No momento, não há como acessar automaticamente o código/nome da versão do app em um subprojeto de biblioteca.

Para os módulos de aplicativos, não há mudanças. Ainda é possível atribuir valores a versionCode e versionName na DSL; esses valores serão propagados para o manifesto do app e os campos BuildConfig.

Definir o caminho do NDK

Você pode definir o caminho para a instalação do NDK local usando a propriedade android.ndkPath no arquivo build.gradle do módulo.

android {
   ndkPath "your-custom-ndk-path"
}

android {
   ndkPath = "your-custom-ndk-path"
}

Se você usar essa propriedade com a propriedade android.ndkVersion, esse caminho precisará conter uma versão do NDK que corresponda a android.ndkVersion.

Mudanças de comportamento dos testes de unidade de biblioteca

Mudamos o comportamento de compilação e execução dos testes de unidade de biblioteca. Agora, os testes de unidade de uma biblioteca são compilados e executados em classes de compilação/tempo de execução da própria biblioteca, resultando em testes de unidade que consomem a biblioteca da mesma maneira que subprojetos externos. Essa configuração normalmente resulta em testes melhores.

Em alguns casos, os testes de unidade de biblioteca que usam vinculação de dados podem encontrar classes DataBindingComponent ou BR ausentes. Esses testes precisam ser transferidos para um teste de instrumentação no projeto androidTest, uma vez que a compilação e a execução nessas classes em um teste de unidade pode produzir uma saída incorreta.

O plug-in io.fabric do Gradle foi descontinuado

O plug-in io.fabric do Gradle foi descontinuado e não é compatível com a versão 4.1 do Plug-in do Android para Gradle. Para ver mais informações sobre o SDK do Fabric obsoleto e a migração para o SDK do Firebase Crashlytics, consulte Fazer upgrade para o SDK do Firebase Crashlytics.

4.0.0 (abril de 2020)

Esta versão do plug-in do Android requer o seguinte:

• Gradle 6.1.1. Para saber mais, leia a seção sobre a atualização do Gradle.

• SDK Build Tools 29.0.2 ou versões mais recentes.

Novos recursos

Esta versão do Plug-in do Android para Gradle inclui os novos recursos a seguir.

Compatibilidade com o Build Analyzer do Android Studio

A janela Build Analyzer ajuda a entender e diagnosticar problemas no processo de compilação, como otimizações desativadas e tarefas configuradas incorretamente. Esse recurso está disponível no Android Studio 4.0 ou mais recente com o Plug-in do Android para Gradle 4.0.0 e versões mais recentes. É possível abrir a janela Build Analyzer no Android Studio da seguinte forma:

1. Crie seu app selecionando Build > Make Project na barra de menus, caso ainda não tenha feito isso.
2. Selecione View > Tool Windows > Build na barra de menus.
3. Na janela Build, abra a janela Build Analyzer de uma das seguintes maneiras:
   • Depois que o Android Studio concluir a criação do projeto, clique na guia Build Analyzer.
   • Depois que o Android Studio concluir a criação do seu projeto, clique no link no lado direito da janela Build Output.

A janela do Build Analyzer organiza possíveis problemas de build em uma árvore à esquerda. Inspecione e clique em cada problema para investigar os detalhes no painel à direita. Quando o Android Studio analisa seu build, ele computa o conjunto de tarefas que determinou a duração da criação e fornece uma visualização para ajudar você a entender o impacto de cada tarefa. Você também pode ver detalhes sobre os avisos expandindo o nó Warnings.

Para saber mais, leia Identificar regressões de velocidade do build.

Simplificação da biblioteca do Java 8 no D8 e R8

O Plug-in do Android para Gradle agora inclui suporte ao uso de diversas APIs da linguagem Java 8 sem a necessidade de um nível mínimo de API para seu app.

Por meio de um processo chamado desugaring (simplificação), o compilador DEX, D8, no Android Studio 3.0 e mais recentes, já fornecia compatibilidade significativa com recursos da linguagem Java 8, como expressões lambda, métodos de interface padrão e try-with-resources, entre outros. No Android Studio 4.0, o mecanismo de simplificação foi estendido para poder simplificar APIs de linguagem Java. Isso significa que agora você pode incluir APIs de linguagem padrão que estavam disponíveis apenas em versões recentes do Android (como java.util.streams) em apps compatíveis com versões mais antigas do Android.

O seguinte conjunto de APIs é compatível com esta versão:

• Fluxos sequenciais (java.util.stream)
• Um subconjunto de java.time
• java.util.function
• Adições recentes a java.util.{Map,Collection,Comparator}
• Recursos opcionais (java.util.Optional, java.util.OptionalInt e java.util.OptionalDouble) e algumas outras novas classes úteis com as APIs acima
• Algumas adições a java.util.concurrent.atomic (novos métodos em AtomicInteger, AtomicLong e AtomicReference)
• ConcurrentHashMap (com correções de bugs para o Android 5.0)

Para oferecer compatibilidade com essas APIs de linguagem, o D8 compila um arquivo DEX de biblioteca separado que contém uma implementação das APIs ausentes e as inclui no seu app. O processo de simplificação reescreve o código do seu app para usar essa biblioteca no momento da execução.

Para ativar a compatibilidade com essas APIs de linguagem, inclua o seguinte no arquivo build.gradle do módulo do app:

android {
  defaultConfig {
    // Required when setting minSdkVersion to 20 or lower
    multiDexEnabled true
  }

  compileOptions {
    // Flag to enable support for the new language APIs
    coreLibraryDesugaringEnabled true
    // Sets Java compatibility to Java 8
    sourceCompatibility JavaVersion.VERSION_1_8
    targetCompatibility JavaVersion.VERSION_1_8
  }
}

dependencies {
  coreLibraryDesugaring 'com.android.tools:desugar_jdk_libs:1.0.4'
}

android {
  defaultConfig {
    // Required when setting minSdkVersion to 20 or lower
    multiDexEnabled = true
  }

  compileOptions {
    // Flag to enable support for the new language APIs
    isCoreLibraryDesugaringEnabled = true
    // Sets Java compatibility to Java 8
    sourceCompatibility = JavaVersion.VERSION_1_8
    targetCompatibility = JavaVersion.VERSION_1_8
  }
}

dependencies {
  coreLibraryDesugaring("com.android.tools:desugar_jdk_libs:1.0.4")
}

Também pode ser necessário incluir o snippet de código acima em um arquivo build.gradle do módulo da biblioteca se:

• os testes de instrumentação do módulo da biblioteca usam essas APIs de linguagem, seja diretamente, pelo módulo da biblioteca ou pelas dependências dele. Dessa forma, as APIs que não estiverem presentes serão fornecidas para o APK de teste de instrumentação;

• você quer executar o lint no módulo da biblioteca de forma isolada. O objetivo é ajudar o lint a reconhecer usos válidos das APIs de linguagem e evitar avisos falsos.

Novas opções para ativar ou desativar recursos de build

O Plug-in do Android para Gradle 4.0.0 introduz uma nova maneira de controlar quais recursos de build você quer ativar e desativar, como a vinculação de visualizações e a vinculação de dados. Quando novos recursos são adicionados, eles ficam desativados por padrão. Você pode usar o bloco buildFeatures para ativar apenas os recursos que quiser, e isso ajuda a otimizar o desempenho do build do projeto. Você pode definir as opções para cada módulo no arquivo build.gradle do módulo da seguinte maneira:

android {
    // The default value for each feature is shown below. You can change the value to
    // override the default behavior.
    buildFeatures {
        // Determines whether to generate a BuildConfig class.
        buildConfig = true
        // Determines whether to support View Binding.
        // Note that the viewBinding.enabled property is now deprecated.
        viewBinding = false
        // Determines whether to support Data Binding.
        // Note that the dataBinding.enabled property is now deprecated.
        dataBinding = false
        // Determines whether to generate binder classes for your AIDL files.
        aidl = true
        // Determines whether to support RenderScript.
        renderScript = true
        // Determines whether to support injecting custom variables into the module’s R class.
        resValues = true
        // Determines whether to support shader AOT compilation.
        shaders = true
    }
}

android {
    // The default value for each feature is shown below. You can change the value to
    // override the default behavior.
    buildFeatures {
        // Determines whether to generate a BuildConfig class.
        buildConfig = true
        // Determines whether to support View Binding.
        // Note that the viewBinding.enabled property is now deprecated.
        viewBinding = false
        // Determines whether to support Data Binding.
        // Note that the dataBinding.enabled property is now deprecated.
        dataBinding = false
        // Determines whether to generate binder classes for your AIDL files.
        aidl = true
        // Determines whether to support RenderScript.
        renderScript = true
        // Determines whether to support injecting custom variables into the module’s R class.
        resValues = true
        // Determines whether to support shader AOT compilation.
        shaders = true
    }
}

Também pode especificar a configuração padrão para esses recursos em todos os módulos de um projeto incluindo uma ou mais das seguintes opções no arquivo gradle.properties do seu projeto, como mostrado abaixo. Lembre-se de que também é possível usar o bloco buildFeatures no arquivo build.gradle de cada módulo para substituir essas configurações padrão do projeto.

android.defaults.buildfeatures.buildconfig=true
android.defaults.buildfeatures.aidl=true
android.defaults.buildfeatures.renderscript=true
android.defaults.buildfeatures.resvalues=true
android.defaults.buildfeatures.shaders=true

Dependências de recurso sobre recurso

Nas versões anteriores do Plug-in do Android para Gradle, todos os módulos de recursos podiam depender apenas do módulo base do app. Ao usar o Plug-in do Android para Gradle 4.0.0, você pode incluir um módulo de recurso que dependa de outro módulo de recurso. Ou seja, um recurso :video pode depender do recurso :camera, que depende do módulo base, como mostrado na figura abaixo.

O módulo de recurso :video depende do recurso :camera, que depende do módulo base :app.

Isso significa que, quando o app solicita o download de um módulo de recurso, ele também faz o download de outros módulos de recursos de que depende. Depois de criar módulos de recursos para seu app, você pode declarar uma dependência de recursos no arquivo build.gradle do módulo. Por exemplo, o módulo :video declara uma dependência de :camera da seguinte maneira:

// In the build.gradle file of the ':video' module.
dependencies {
    // All feature modules must declare a dependency
    // on the base module.
    implementation project(':app')
    // Declares that this module also depends on the 'camera'
    // feature module.
    implementation project(':camera')
    ...
}

// In the build.gradle file of the ':video' module.
dependencies {
    // All feature modules must declare a dependency
    // on the base module.
    implementation(project(":app"))
    // Declares that this module also depends on the 'camera'
    // feature module.
    implementation(project(":camera"))
    ...
}

Além disso, ative a função de dependência de recurso sobre recurso no Android Studio para oferecer suporte ao editar a configuração de execução, por exemplo. Faça isso clicando em Help > Edit Custom VM Options na barra de menus e incluindo o código abaixo:

-Drundebug.feature.on.feature=true

Metadados de dependências

Quando você cria seu app usando o Plug-in do Android para Gradle 4.0.0 e mais recente, o plug-in inclui metadados que descrevem as dependências compiladas no app. Durante o upload do app, o Play Console inspeciona esses metadados para oferecer os seguintes benefícios:

• Receber alertas de problemas conhecidos com os SDKs e as dependências que o app usa
• Receber feedback útil para resolver esses problemas

Os dados são compactados, criptografados por uma chave de assinatura do Google Play e armazenados no bloco de assinatura do app de lançamento. No entanto, você pode inspecionar os metadados por conta própria nos arquivos de build intermediários locais no seguinte diretório: <project>/<module>/build/outputs/sdk-dependencies/release/sdkDependency.txt.

Se você preferir não compartilhar essas informações, desative isso incluindo o seguinte no arquivo build.gradle do módulo:

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs.
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles.
        includeInBundle = false
    }
}

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs.
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles.
        includeInBundle = false
    }
}

Importar bibliotecas nativas das dependências de AAR

Agora você pode importar bibliotecas C/C++ das dependências de AAR do app. Quando você segue as etapas de configuração descritas abaixo, o Gradle disponibiliza automaticamente essas bibliotecas nativas para uso com o sistema de compilação nativo externo, como o CMake. O Gradle apenas disponibiliza essas bibliotecas para o build. Você ainda precisa configurar os scripts de build para que elas possam ser usadas.

As bibliotecas são exportadas usando o formato de pacote Prefab (link em inglês).

Cada dependência pode expor, no máximo, um pacote Prefab, que compreende um ou mais módulos. Um módulo Prefab é uma biblioteca única, que pode ser compartilhada, estática ou apenas de cabeçalho.

Normalmente, o nome do pacote corresponde ao nome do artefato Maven, e o nome do módulo corresponde ao nome da biblioteca, mas nem sempre isso ocorre. Como você precisa saber o nome do pacote e do módulo das bibliotecas, talvez seja necessário consultar a documentação da dependência para determiná-los.

Configurar o sistema de compilação nativo externo

Para ver as etapas a serem seguidas, clique no sistema de compilação nativo externo que você pretende usar.

CMake ndk-build

As dependências nativas incluídas em um AAR são expostas ao projeto do CMake pela variável CMAKE_FIND_ROOT_PATH. Esse valor será definido automaticamente pelo Gradle quando o CMake for invocado. Portanto, se o sistema de compilação modificar essa variável, anexe-a em vez de atribuí-la.

Cada dependência expõe um pacote config-file ao build do CMake, que é importado com o comando find_package. Esse comando procura por pacotes config-file que correspondam ao nome do pacote e da versão fornecidos e expõe os destinos que ele define para serem usados no build. Por exemplo, se o aplicativo definir libapp.so e usar curl, inclua o seguinte no arquivo CMakeLists.txt:

add_library(app SHARED app.cpp)

# Add these two lines.
find_package(curl REQUIRED CONFIG)
target_link_libraries(app curl::curl)

Agora, você pode especificar #include "curl/curl.h" em app.cpp. Quando você cria seu projeto, o sistema de compilação nativo externo vincula automaticamente libapp.so a libcurl.so e pacotes libcurl.so no APK ou no pacote de apps. Para ver mais informações, consulte a amostra de curl prefab.

Mudanças de comportamento

Ao usar esta versão do plug-in, você pode encontrar as seguintes mudanças no comportamento.

Atualizações da configuração de assinatura v1/v2

O comportamento das configurações de assinatura de apps no bloco signingConfig foi mudado para o seguinte:

Assinatura v1

• Se v1SigningEnabled for explicitamente ativada, o AGP realizará a assinatura de apps v1.
• Se v1SigningEnabled for explicitamente desativada pelo usuário, a assinatura de apps v1 não será realizada.
• Se o usuário não tiver ativado a assinatura v1, explicitamente, ela poderá ser desativada automaticamente com base em minSdk e targetSdk.

Assinatura v2

• Se v2SigningEnabled for explicitamente ativada, o AGP realizará a assinatura de apps v2.
• Se v2SigningEnabled for explicitamente desativada pelo usuário, a assinatura de apps v2 não será realizada.
• Se o usuário não tiver ativado a assinatura v2 explicitamente, ela poderá ser desativada automaticamente com base em targetSdk.

Essas mudanças permitem que o AGP otimize builds desativando o mecanismo de assinatura com base em se o usuário ativou explicitamente ou não essas sinalizações. Antes dessa versão, era possível que v1Signing fosse desativada mesmo quando explicitamente ativada, o que poderia ser confuso.

Os Plug-ins do Android para Gradle feature e instantapp foram removidos

O Plug-in do Android para Gradle 3.6.0 descontinuou os plug-ins Feature (com.android.feature) e Instant App (com.android.instantapp) e os substituiu pelo plug-in Dynamic Feature (com.android.dynamic-feature) para criar e empacotar apps instantâneos usando Android App Bundles.

No Plug-in do Android para Gradle 4.0.0 e versões mais recentes, esses plug-ins descontinuados foram totalmente removidos. Para usar o Plug-in do Android para Gradle mais recente, você precisa migrar seu app instantâneo para o Android App Bundles. Ao migrar seus apps instantâneos, você pode aproveitar os benefícios dos pacotes de apps e simplificar o design modular do app.

O recurso separado de processamento de anotações foi removido

A possibilidade de separar o processamento de anotações em uma tarefa dedicada foi removida. Essa opção era usada para manter a compilação Java incremental quando processadores de anotações não incrementais eram usados em projetos somente Java. A opção era ativada configurando android.enableSeparateAnnotationProcessing como true no arquivo gradle.properties, o que não funciona mais.

Em vez disso, você precisa migrar para usar processadores de anotações incrementais e melhorar a performance de build.

O uso de includeCompileClasspath foi descontinuado

O Plug-in do Android para Gradle não confere mais nem inclui processadores de anotações declarados no caminho de classe de compilação, e a propriedade DSL annotationProcessorOptions.includeCompileClasspath não tem mais efeito. Se você incluir processadores de anotações no caminho de classe de compilação, poderá encontrar o seguinte erro:

Error: Annotation processors must be explicitly declared now.

Para resolver esse problema, é preciso incluir processadores de anotações nos arquivos build.gradle usando a configuração de dependência annotationProcessor. Para saber mais, leia Adicionar processadores de anotações.

Empacotamento automático de dependências pré-criadas usadas pelo CMake

As versões anteriores do Plug-in do Android para Gradle exigiam o empacotamento explícito de quaisquer bibliotecas pré-criadas usadas pelo build nativo externo do CMake usando jniLibs. Você pode ter bibliotecas no diretório src/main/jniLibs do seu módulo ou possivelmente em outro diretório configurado no arquivo build.gradle:

sourceSets {
    main {
        // The libs directory contains prebuilt libraries that are used by the
        // app's library defined in CMakeLists.txt via an IMPORTED target.
        jniLibs.srcDirs = ['libs']
    }
}

sourceSets {
    main {
        // The libs directory contains prebuilt libraries that are used by the
        // app's library defined in CMakeLists.txt via an IMPORTED target.
        jniLibs.setSrcDirs(listOf("libs"))
    }
}

Com o Plug-in do Android para Gradle 4.0, a configuração acima não é mais necessária e resultará em uma falha de build:

* What went wrong:
Execution failed for task ':app:mergeDebugNativeLibs'.
> A failure occurred while executing com.android.build.gradle.internal.tasks.Workers$ActionFacade
   > More than one file was found with OS independent path 'lib/x86/libprebuilt.so'

O build nativo externo agora empacota automaticamente essas bibliotecas. Portanto, empacotar explicitamente a biblioteca com jniLibs resulta em uma cópia. Para evitar o erro de build, mova a biblioteca pré-criada para um local fora de jniLibs ou remova a configuração jniLibs do seu arquivo build.gradle.

Problemas conhecidos

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

Disputa no mecanismo de worker do Gradle

Mudanças no Plug-in do Android para Gradle 4.0 podem acionar uma disputa no Gradle ao ser executado com --no-daemon e versões do Gradle 6.3 ou anteriores, fazendo que os builds travem após o término da criação.

Esse problema será corrigido no Gradle 6.4.

3.6.0 (fevereiro de 2020)

Esta versão do plug-in do Android requer o seguinte:

• Gradle 5.6.4. Para saber mais, leia a seção sobre a atualização do Gradle.

• SDK Build Tools 28.0.3 ou versões mais recentes.

Novos recursos

Esta versão do Plug-in do Android para Gradle inclui os novos recursos a seguir.

Vinculação de visualizações

A vinculação de visualizações fornece segurança no momento da compilação quando há referências a visualizações no código. Agora você pode substituir findViewById() pela referência de classe de vinculação gerada automaticamente. Para começar a usar a vinculação de visualizações, inclua o seguinte no arquivo build.gradle de cada módulo:

android {
    viewBinding.enabled = true
}

android {
    viewBinding.enabled = true
}

Para saber mais, leia a documentação de Vinculação de visualizações.

Compatibilidade com o plug-in Maven Publish

O Plug-in do Android para Gradle inclui compatibilidade com o plug-in Maven Publish para Gradle, que permite a publicação de artefatos de build em um repositório Apache Maven. O Plug-in do Android para Gradle cria um componente para cada artefato de variante de build no módulo do aplicativo ou da biblioteca usado para personalizar uma publicação para um repositório Maven (links em inglês).

Para saber mais, acesse a página sobre como usar o plug-in Maven Publish.

Nova ferramenta de empacotamento padrão

Ao criar a versão de depuração do app, o plug-in usa uma nova ferramenta de empacotamento, chamada zipflinger, para criar o APK. Essa nova ferramenta trará melhorias de velocidade de build. Se a nova ferramenta de empacotamento não funcionar como esperado, informe um bug. Você pode voltar a usar a ferramenta de empacotamento antiga incluindo o seguinte no arquivo gradle.properties:

android.useNewApkCreator=false

Atribuição do build nativo

Agora é possível determinar o tempo que o Clang leva para criar e vincular cada arquivo C/C ++ no seu projeto. O Gradle pode gerar um trace do Chrome que contém carimbos de data/hora para esses eventos do compilador para que você possa analisar o tempo necessário para criar seu projeto. Para gerar esse arquivo de atribuição de build, faça o seguinte:

1. Adicione a sinalização -Pandroid.enableProfileJson=true ao gerar uma versão do Gradle. Por exemplo:

   gradlew assembleDebug -Pandroid.enableProfileJson=true

2. Abra o navegador Chrome e digite chrome://tracing na barra de pesquisa.

3. Clique no botão Load e navegue até project-root/build/android-profile para encontrar o arquivo. O nome do arquivo é profile-timestamp.json.gz.

Você pode ver os dados de atribuição da versão nativa perto da parte superior do visualizador:

Mudanças de comportamento

Ao usar esta versão do plug-in, você pode encontrar as seguintes mudanças no comportamento.

Bibliotecas nativas empacotadas descompactadas por padrão

Quando você cria seu app, o plug-in agora define extractNativeLibs como "false" por padrão. Ou seja, suas bibliotecas nativas são alinhadas na página e empacotadas sem compactação. Apesar de isso gerar um tamanho do upload maior, seus usuários se beneficiam pelos seguintes motivos:

• O tamanho de instalação do app é menor porque a plataforma pode acessar as bibliotecas nativas diretamente do APK instalado, sem criar uma cópia das bibliotecas.
• O tamanho de download é menor, porque a compactação da Play Store geralmente é melhor quando você inclui bibliotecas nativas não compactadas no seu APK ou Android App Bundle.

Se, em vez disso, você quiser que o Plug-in do Android para Gradle empacote bibliotecas nativas compactadas, inclua o seguinte no manifesto do app:

<application
    android:extractNativeLibs="true"
    ... >
</application>

Versão padrão do NDK

Se você fizer o download de várias versões do NDK, o Plug-in do Android para Gradle agora selecionará uma versão padrão para compilar seus arquivos de código-fonte. Antes, o plug-in selecionava a versão mais recente do NDK transferida por download. Use a propriedade android.ndkVersion no arquivo build.gradle do módulo para substituir o padrão selecionado pelo plug-in.

Geração de classe R simplificada

O Plug-in do Android para Gradle simplifica o caminho de classe de compilação gerando apenas uma classe R para cada módulo de biblioteca no projeto e compartilhando essas classes R com outras dependências do módulo. Essa otimização proporcionará builds mais rápidos, mas exige que você tenha em mente o seguinte:

• Como o compilador compartilha classes R com dependências de módulo upstream, é importante que cada módulo do projeto use um nome de pacote exclusivo.
• A visibilidade da classe R de uma biblioteca para outras dependências do projeto é determinada pela configuração usada para incluir a biblioteca como dependência. Por exemplo, se a Biblioteca A incluir a Biblioteca B como uma dependência "API", a Biblioteca A e outras bibliotecas que dependem dela terão acesso à classe R da Biblioteca B. No entanto, outras bibliotecas podem não ter acesso à classe R da Biblioteca B se a Biblioteca A usar a configuração de dependência implementation. Para saber mais, leia sobre as configurações de dependência.

Remover recursos ausentes da configuração padrão

Para módulos de Biblioteca, se você incluir um recurso para um idioma que não incluiu no conjunto padrão de recursos (por exemplo, se você incluir hello_world como um recurso de string em /values-es/strings.xml, mas não definir esse recurso em /values/strings.xml), o Plug-in do Android para Gradle não incluirá mais esse recurso ao compilar seu projeto. Essa mudança de comportamento resulta em menos exceções de tempo de execução Resource Not Found e maior velocidade de compilação.

O D8 agora respeita a política de retenção de classe para anotações

Ao compilar seu app, o D8 agora respeita quando as anotações aplicam uma política de retenção CLASS, e essas anotações não estão mais disponíveis no ambiente de execução. Esse comportamento também existe ao definir o SDK de destino do app para o nível 23 da API, que anteriormente permitia acessar essas anotações durante o tempo de execução ao compilar o app usando versões mais antigas do Plug-in do Android para Gradle e do D8.

Outras mudanças de comportamento

• aaptOptions.noCompress não diferencia mais caracteres maiúsculos de minúsculos em todas as plataformas (para APK e pacotes) e respeita caminhos que usam caracteres maiúsculos.
• A vinculação de dados agora é incremental por padrão. Para saber mais, consulte o problema 110061530.
• Todos os testes de unidade, incluindo testes de unidade roboelétricos, agora podem ser totalmente armazenados em cache. Para saber mais, consulte o problema #115873047.

Correções de bugs

Esta versão do Plug-in do Android para Gradle inclui as seguintes correções de bugs:

• Agora, os testes de unidade robolétricos são compatíveis com módulos de biblioteca que usam vinculação de dados. Para saber mais, consulte o problema 126775542.
• Agora é possível executar tarefas connectedAndroidTest em vários módulos enquanto o modo de execução paralela do Gradle está ativado.

Problemas conhecidos

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

Desempenho lento da tarefa Android Lint

O Android Lint pode levar muito mais tempo para ser concluído em alguns projetos devido a uma regressão na infraestrutura de análise, o que resulta em um cálculo mais lento de tipos de inferência para lambdas em determinadas construções de códigos.

O problema é relatado como um bug no IDEA e será corrigido no Plug-in do Android para Gradle 4.0.

Falta a classe do manifesto

Se o app definir permissões personalizadas no manifesto, o Plug-in do Android para Gradle normalmente gerará uma classe Manifest.java que incluirá suas permissões personalizadas como constantes de string. O plug-in empacota essa classe com seu app para que você possa referenciar essas permissões com mais facilidade no tempo de execução.

A geração da classe de manifesto está corrompida no Plug-in do Android para Gradle 3.6.0. Se você criar seu app com essa versão do plug-in e fizer referência à classe de manifesto, talvez veja uma exceção ClassNotFoundException. Para resolver esse problema, execute uma das seguintes ações:

• Faça referência a suas permissões personalizadas pelo nome totalmente qualificado. Por exemplo, "com.example.myapp.permission.DEADLY_ACTIVITY".

• Defina suas próprias constantes, conforme mostrado abaixo:

  public final class CustomPermissions {
    public static final class permission {
      public static final String DEADLY_ACTIVITY="com.example.myapp.permission.DEADLY_ACTIVITY";
    }
  }
  

3.5.0 (agosto de 2019)

O Plug-in do Android para Gradle 3.5.0, assim como o Android Studio 3.5, é um lançamento importante do Project Marble. O objetivo desse projeto é melhorar três áreas principais das ferramentas para desenvolvedores Android: a integridade do sistema, o aperfeiçoamento de recursos e a correção de bugs. No caso específico dessa atualização, o foco foi melhorar a velocidade de build do projeto (link em inglês).

Para ver mais informações sobre essas e outras atualizações do Project Marble, leia a postagem no Blog de desenvolvedores Android (link em inglês) ou as seções abaixo.

Esta versão do plug-in do Android requer o seguinte:

• Gradle 5.4.1. Para saber mais, leia a seção sobre a atualização do Gradle.

• SDK Build Tools 28.0.3 ou versões mais recentes.

Processamento incremental de anotações

O processador de anotações da Vinculação de dados vai oferecer suporte ao processamento incremental de anotações (link em inglês) se você definir android.databinding.incremental=true no arquivo gradle.properties. Essa otimização resulta em melhor desempenho de build incremental. Para ver uma lista completa de processadores de anotações otimizados, consulte a tabela de processadores de anotações incrementais (link em inglês).

Além disso, o KAPT 1.3.30 e versões mais recentes também são compatíveis com processadores de anotações incrementais, que podem ser ativados incluindo kapt.incremental.apt=true no seu arquivo gradle.properties.

Testes de unidade armazenáveis em cache

Quando você ativa testes de unidade para usar recursos e manifestos Android configurando includeAndroidResources como true, o Plug-in do Android para Gradle gera um arquivo de configuração de teste com caminhos absolutos, o que interrompe a realocação do cache. Em vez disso, você pode instruir o plug-in para gerar a configuração de teste usando caminhos relativos, o que permite que a tarefa AndroidUnitTest seja totalmente armazenada em cache, pela inclusão do seguinte no arquivo gradle.properties:

android.testConfig.useRelativePath = true

Problemas conhecidos

• Quando você usa o plug-in do Kotlin para Gradle 1.3.31 ou uma versão anterior, o seguinte aviso pode ser exibido ao criar ou sincronizar seu projeto:

  WARNING: API 'variant.getPackageLibrary()' is obsolete and has been replaced
           with 'variant.getPackageLibraryProvider()'.
  

  Para resolver esse problema, atualize o plug-in para a versão 1.3.40 ou mais recente.

3.4.0 (abril de 2019)

Esta versão do plug-in do Android requer o seguinte:

• Gradle 5.1.1 (link em inglês) ou uma versão mais recente. Para saber mais, leia a seção sobre a atualização do Gradle.

• SDK Build Tools 28.0.3 ou versões mais recentes.

Novos recursos

• Novas configurações de dependência de verificação de lint: o comportamento de lintChecks mudou, e uma nova configuração de dependência (lintPublish) foi introduzida para oferecer mais controle sobre as verificações de lint que são empacotadas nas bibliotecas do Android.

  • lintChecks: esta é uma configuração existente necessária para verificações de lint que você queira executar somente ao criar seu projeto localmente. Se você estava usando a configuração de dependência lintChecks anteriormente para incluir verificações de lint no AAR publicado, precisará migrar essas dependências para usar a nova configuração lintPublish descrita abaixo.
  • lintPublish: use esta nova configuração em projetos de biblioteca para verificações de lint que você queira incluir no AAR publicado, conforme mostrado abaixo. Isso significa que os projetos que consomem sua biblioteca também aplicam essas verificações de lint.

  A amostra de código a seguir usa as duas configurações de dependência em um projeto de biblioteca local do Android.

  Groovy

  
  dependencies {
  // Executes lint checks from the ':lint' project at build time.
  lintChecks project(':lint')
  // Packages lint checks from the ':lintpublish' in the published AAR.
  lintPublish project(':lintpublish')
  }
  

  Kotlin

  
  dependencies {
  // Executes lint checks from the ':lint' project at build time.
  lintChecks(project(":lint"))
  // Packages lint checks from the ':lintpublish' in the published AAR.
  lintPublish(project(":lintpublish"))
  }
  

• Em geral, as tarefas de empacotamento e assinatura terão uma melhoria geral na velocidade de build. Se você perceber uma regressão de desempenho relacionada a essas tarefas, informe um bug.

Mudanças de comportamento

• Aviso de descontinuação do plug-in Instant Apps Android Feature: se você ainda estiver usando o plug-in com.android.feature para criar seu app instantâneo, o Plug-in do Android para Gradle 3.4.0 vai mostrar um aviso de descontinuação. Para garantir que seja possível criar seu app instantâneo em versões futuras do plug-in, migre-o para o plug-in de recurso dinâmico, que também permite a publicação das suas experiências de apps instalados e instantâneos de um único Android App Bundle.

• R8 ativado por padrão: o R8 integra a simplificação, redução, ofuscação, otimização e dexação em uma única etapa, o que resulta em melhorias significativas no desempenho do build (link em inglês). O R8 foi introduzido no Plug-in do Android para Gradle 3.3.0 e agora está ativado por padrão para os projetos de biblioteca Android e apps usando o plug-in 3.4.0 ou mais recente.

  A imagem abaixo fornece uma visão geral de alto nível do processo de compilação antes da introdução do R8.

  

  Agora, com o R8, a simplificação, redução, ofuscação, otimização e dexação (D8) são todas concluídas em uma única etapa, conforme ilustrado abaixo.

  

  Lembre-se de que o R8 foi projetado para funcionar com suas regras do ProGuard. Desse modo, você provavelmente não precisará fazer nada para se beneficiar do R8. No entanto, como essa é uma tecnologia diferente do ProGuard e é projetada especificamente para projetos Android, a redução e a otimização podem resultar na remoção de códigos que o ProGuard talvez não removesse. Nessa situação improvável, talvez seja necessário adicionar outras regras para manter esse código no resultado de build.

  Se você tiver problemas ao usar o R8, leia as Perguntas frequentes de compatibilidade do R8 para conferir se há uma solução. Se nenhuma solução tiver sido documentada, informe um bug. Você pode desativar o R8 adicionando uma das seguintes linhas ao arquivo gradle.properties do projeto:

  # Disables R8 for Android Library modules only.
  android.enableR8.libraries = false
  # Disables R8 for all modules.
  android.enableR8 = false
  

• O uso de ndkCompile foi descontinuado: agora você vai encontrar um erro de build se tentar usar o ndkBuild para compilar bibliotecas nativas. Em vez disso, use o CMake ou o ndk-build para adicionar código C e C++ ao seu projeto.

Problemas conhecidos

• O uso correto de nomes de pacotes únicos não é obrigatório atualmente, mas se tornará mais rigoroso em versões mais recentes do plug-in. No Plug-in do Android para Gradle versão 3.4.0, você pode verificar se o projeto declara nomes de pacotes aceitáveis adicionando a linha abaixo ao seu arquivo gradle.properties.

  android.uniquePackageNames = true
  

  Para saber mais sobre como definir um nome de pacote com o Plug-in do Android para Gradle, consulte Definir o ID do aplicativo.

3.3.0 (janeiro de 2019)

Esta versão do plug-in do Android requer o seguinte:

• Gradle 4.10.1 (link em inglês) ou versões mais recentes. Para saber mais, leia a seção sobre a atualização do Gradle.

• SDK Build Tools 28.0.3 ou versões mais recentes.

Novos recursos

• Melhoria na sincronização de caminho de classe: ao resolver dependências nos seus caminhos de classe de ambiente de execução e tempo de compilação, o Plug-in do Android para Gradle tenta corrigir alguns conflitos de versão para dependências em vários caminhos de classe.

  Por exemplo, se o caminho de classe do tempo de execução incluir a Biblioteca A versão 2.0 e o de compilação incluir a Biblioteca A versão 1.0, o plug-in atualizará automaticamente a dependência do caminho de classe de compilação para a Biblioteca A versão 2.0 para evitar erros.

  No entanto, se o caminho de classe de execução incluir a Biblioteca A versão 1.0 e a compilação incluir a Biblioteca A versão 2.0, o plug-in não vai fazer downgrade da dependência do caminho de classe de compilação para a Biblioteca A versão 1.0 e isso gera um erro. Para saber mais, consulte Corrigir conflitos entre caminhos de classe

• Melhoria na compilação Java incremental ao usar processadores de anotações: esta atualização diminui o tempo de compilação porque melhora o suporte à compilação Java incremental quando usada com processadores de anotações.

  • Para projetos que usam o Kapt (a maioria dos projetos somente em Kotlin e dos projetos híbridos em Kotlin-Java): a compilação incremental em Java é ativada, mesmo quando você usa a vinculação de dados ou o plug-in retro-lambda. O processamento de anotações pela tarefa do Kapt ainda não é incremental.

  • Para projetos que não usam o Kapt (projetos somente em Java): se os processadores de anotações que você usa oferecerem suporte ao processamento incremental de anotações (link em inglês), a compilação Java incremental vai ser ativada por padrão. Para monitorar a adoção do processador de anotações incremental, veja o problema 5277 do Gradle (link em inglês).

    Entretanto, se um ou mais processadores de anotações não forem compatíveis com builds incrementais, a compilação incremental em Java não será ativada. Em vez disso, você pode incluir a seguinte sinalização no seu arquivo gradle.properties:

    android.enableSeparateAnnotationProcessing=true
    

    Ao incluir essa sinalização, o Plug-in do Android para Gradle executa os processadores de anotações em uma tarefa separada e permite que as tarefas de compilação em Java sejam executadas de forma incremental.

• Informações de depuração melhores ao usar uma API obsoleta: quando o plug-in detecta que você está usando uma API que não é mais compatível, agora ele pode fornecer informações mais detalhadas para ajudar a determinar onde essa API está sendo usada. Para ver outras informações, você precisa incluir o seguinte no arquivo gradle.properties do seu projeto:

  android.debug.obsoleteApi=true
  

  Também é possível ativar a sinalização transmitindo -Pandroid.debug.obsoleteApi=true na linha de comando.

• Você pode executar testes de instrumentação em módulos de recursos da linha de comando.

Mudanças de comportamento

• Configuração lenta de tarefas: agora, o plug-in usa a nova API de criação de tarefas do Gradle (link em inglês) para evitar a inicialização e a configuração de tarefas que não são necessárias para concluir a versão atual (ou tarefas que não estejam no gráfico de tarefas em execução). Por exemplo, se você tiver diversas variantes de compilação, como "release" e "debug", e estiver criando a versão "debug" do seu app, o plug-in evitará inicializar e configurar tarefas para a versão "release" do app.

  Chamar alguns métodos antigos na API Variants, como variant.getJavaCompile(), ainda poderá forçar a configuração da tarefa. Para garantir que sua versão seja otimizada para a configuração lenta de tarefas, invoque novos métodos que retornem um objeto TaskProvider, como variant.getJavaCompileProvider().

  Se você executa tarefas personalizadas de build, aprenda a adaptar-se à nova API de criação de tarefas do Gradle (link em inglês).

• Para um determinado tipo de build, ao configurar useProguard false, o plug-in agora vai usar o R8 em vez do ProGuard para reduzir e ofuscar o código e os recursos do app. Para saber mais sobre o R8, leia esta postagem do blog (link em inglês) para desenvolvedores Android.

• Geração de classe R mais rápida para projetos de biblioteca: anteriormente, o Plug-in do Android para Gradle gerava um arquivo R.java para cada uma das dependências do projeto e compilava essas classes R junto com as outras classes do app. O plug-in agora gera diretamente um JAR que contém a classe R compilada do seu app, sem criar classes R.java intermediárias antes. Essa otimização pode melhorar significativamente o desempenho do build para projetos que incluem muitos subprojetos e dependências de biblioteca, além de melhorar a velocidade de indexação no Android Studio.

• Ao criar um Android App Bundle, os APKs gerados desse pacote de apps destinado ao Android 6.0 (nível 23 da API) ou versões mais recentes agora incluem versões descompactadas das suas bibliotecas nativas por padrão. Essa otimização evita que o dispositivo tenha que fazer uma cópia da biblioteca e, assim, reduz o tamanho do app no disco. Se você preferir desativar essa otimização, adicione o seguinte ao arquivo gradle.properties:

  android.bundle.enableUncompressedNativeLibs = false
  

• O plug-in aplica versões mínimas de alguns plug-ins de terceiros.

• Sincronização de projeto de variante única: sincronizar seu projeto com a configuração da compilação é uma etapa importante para permitir que o Android Studio entenda como o projeto está estruturado. No entanto, esse processo pode levar muito tempo em projetos grandes. Caso seu projeto use diversas variantes de compilação, agora você pode otimizar as sincronizações dele limitando-as apenas à variante selecionada no momento.

  Para ativar essa otimização, é necessário usar o Android Studio 3.3 ou mais recente com o Plug-in do Android para Gradle 3.3.0 ou mais recente. Quando você atende a esses requisitos, o ambiente de desenvolvimento integrado solicita que você ative essa otimização ao sincronizar seu projeto. A otimização também é ativada por padrão em novos projetos.

  Para ativar essa otimização manualmente, clique em File > Settings > Experimental > Gradle (Android Studio > Preferences > Experimental > Gradle em um Mac) e marque a caixa de seleção Only sync the active variant.

  Observação: essa otimização oferece suporte total a projetos que incluem as linguagens Java e C++ e suporte parcial para Kotlin. Ao ativar a otimização para projetos com conteúdo em Kotlin, a sincronização do Gradle volta a usar variantes completas internamente.

• Download automático de pacotes SDK ausentes: essa funcionalidade foi expandida para oferecer compatibilidade com o NDK. Para saber mais, leia Download automático de pacotes ausentes com o Gradle.

Correções de bugs

• O Plug-in do Android para Gradle 3.3.0 corrige os seguintes problemas:

  • O processo de compilação chama android.support.v8.renderscript.RenderScript em vez da versão do AndroidX, mesmo que o Jetifier esteja ativado.
  • Conflitos causados porque o androidx-rs.jar inclui este elemento com empacotamento estático annotation.AnyRes.
  • Ao usar o RenderScript, não será mais necessário definir manualmente a versão do Build Tools nos arquivos build.gradle.

3.2.0 (setembro de 2018)

Esta versão do plug-in do Android requer o seguinte:

• Gradle 4.6 (link em inglês) ou versões mais recentes. Para saber mais, leia a seção sobre como atualizar o Gradle.
• SDK Build Tools 28.0.3 ou versões mais recentes.

Novos recursos

• Compatibilidade com a criação de Android App Bundles: o pacote de apps é um novo formato de upload que inclui todo o código e recursos compilados do app, e adia a geração e a assinatura do APK para a Google Play Store. Não é mais necessário criar, assinar e gerenciar vários APKs, e os usuários recebem downloads menores, otimizados para o dispositivo deles. Para saber mais, leia Sobre os Android App Bundles.

• Suporte a velocidades aprimoradas de build incremental ao usar processadores de anotações: a DSL AnnotationProcessorOptions agora estende a interface CommandLineArgumentProvider, que permite que você ou o autor do processador de anotações anote argumentos para o processador usando anotações de tipos de propriedade de build incremental (links em inglês). O uso dessas anotações melhora a exatidão e o desempenho de builds limpos incrementais e em cache. Para saber mais, leia Transmitir argumentos para os processadores de anotações.

• Ferramenta de migração para o AndroidX: ao usar o Plug-in do Android para Gradle 3.2.0 com o Android 3.2 e versões mais recentes, você pode migrar as dependências locais e do Maven do seu projeto para que usem as novas bibliotecas AndroidX selecionando Refactor > Migrate to AndroidX na barra de menus. O uso dessa ferramenta de migração também configura as seguintes sinalizações como true no seu arquivo gradle.properties:

  • android.useAndroidX: quando configurado como true, o plug-in do Android usa a biblioteca AndroidX apropriada em vez de uma biblioteca de suporte. Quando essa sinalização não é especificada, o plug-in a configura como false por padrão.
  • android.enableJetifier: quando configurado como true, o plug-in do Android migrará automaticamente as bibliotecas de terceiros existentes para usar o AndroidX reescrevendo os binários delas. Quando essa sinalização não é especificada, o plug-in a configura como false por padrão. Você pode configurar essa sinalização como true apenas quando android.useAndroidX também estiver configurado como true. Caso contrário, ocorre um erro de build.

  Para saber mais, leia a Visão geral do AndroidX.

• Novo redutor de código, R8: o R8 é uma nova ferramenta de redução e ofuscação de código que substitui o ProGuard. Comece a usar a versão de pré-lançamento do R8 incluindo o seguinte no arquivo gradle.properties do seu projeto:

  Groovy

  
  android.enableR8 = true
  

  Kotlin

  
  android.enableR8 = true
  

Mudanças de comportamento

• Agora, a simplificação de leitura com D8 é ativada por padrão.

• O AAPT2 agora fica no repositório Maven do Google. Para usar o AAPT2, verifique se você tem a dependência do google() no seu arquivo build.gradle, conforme mostrado abaixo:

  Groovy

  
  buildscript {
      repositories {
          google() // here
          jcenter()
      }
      dependencies {
          classpath 'com.android.tools.build:gradle:3.2.0'
      }
  }
  allprojects {
      repositories {
          google() // and here
          jcenter()
  }
  

  Kotlin

  
  buildscript {
      repositories {
          google() // here
          jcenter()
      }
      dependencies {
          classpath 'com.android.tools.build:gradle:3.2.0'
      }
  }
  allprojects {
      repositories {
          google() // and here
          jcenter()
  }
  

• Agora, o multidex nativo é ativado por padrão. As versões anteriores do Android Studio ativavam o multidex nativo ao implantar a versão de depuração de um app em um dispositivo com o nível 21 da API do Android ou mais recente. Agora, independentemente de você estar implantando em um dispositivo ou criando um APK para a versão, o Plug-in do Android para Gradle ativará o multidex nativo para todos os módulos configurados como minSdkVersion=21 ou mais recente.

• O plug-in agora aplica uma versão mínima dos plug-ins protobuf (0.8.6), Kotlin (1.2.50) e Crashlytics (1.25.4).

• O plug-in de módulo de recurso, com.android.feature, agora aplica o uso exclusivo de letras, dígitos e sublinhados ao especificar um nome de módulo. Por exemplo, se o nome do módulo de recursos incluir traços, haverá um erro de build. Esse comportamento corresponde ao do plug-in de recursos dinâmicos.

Correções de bugs

• O JavaCompile agora pode ser armazenado em cache em projetos com vinculação de dados (problema 69243050).
• Melhor evasão de compilação para módulos de biblioteca com vinculação de dados (problema 77539932).
• Agora, você pode reativar a configuração sob demanda (link em inglês) caso tenha desativado em versões anteriores devido a alguns erros de build imprevisíveis (problema 77910727).

3.1.0 (março de 2018)

Esta versão do plug-in do Android requer o seguinte:

• Gradle 4.4 (link em inglês) ou versões mais recentes. Para saber mais, leia a seção sobre como atualizar o Gradle.
• Build Tools 27.0.3 ou versões mais recentes. Lembre-se que não será mais necessário especificar uma versão para o Build Tools usando a propriedade android.buildToolsVersion, porque o plug-in usa a versão mínima necessária por padrão.

Novo compilador DEX, D8

Por padrão, o Android Studio agora usa um novo compilador DEX denominado D8. A compilação DEX é o processo de transformar bytecode .class em bytecode .dex para o Android Runtime (ou Dalvik, para versões mais antigas do Android). Em comparação com o compilador anterior, denominado DX, o D8 compila mais rapidamente e gera arquivos DEX menores, com desempenho igual ou melhor em relação ao tempo de execução do app.

O fluxo de trabalho cotidiano de desenvolvimento de apps não será alterado pelo D8. No entanto, se você tiver algum problema relacionado ao novo compilador, informe um bug. Para desativar temporariamente o D8 e usar o DX, inclua o seguinte no arquivo gradle.properties do seu projeto:

android.enableD8=false

Para projetos que usam recursos da linguagem Java 8, a simplificação incremental é ativada por padrão. Você pode desativá-la especificando o seguinte no arquivo gradle.properties do seu projeto:

android.enableIncrementalDesugaring=false.

Usuário da versão de pré-lançamento: se você já estiver usando uma versão de pré-lançamento do D8, observe que agora ele é compilado em bibliotecas incluídas no SDK Build Tools, não no JDK. Portanto, se você estiver acessando APIs existentes no JDK, mas não nas bibliotecas do SDK Build Tools, haverá um erro de compilação.

Mudanças de comportamento

• Ao criar vários APKs voltados, cada um, para uma ABI diferente, o plug-in não gera mais APKs para as seguintes ABIs por padrão: mips, mips64 e armeabi.

  Se você quiser criar APKs voltados para essas ABIs, será preciso usar o NDK r16b ou anterior e especificar as ABIs no arquivo build.gradle, como mostrado abaixo:

  splits {
      abi {
          include 'armeabi', 'mips', 'mips64'
          ...
      }
  }

  splits {
      abi {
          include("armeabi", "mips", "mips64")
          ...
      }
  }

• O cache de compilação do plug-in do Android agora exibe entradas de cache com mais de 30 dias.
• Transmitir "auto" para resConfig não seleciona mais recursos de string automaticamente para empacotar no seu APK. Se você continuar usando "auto", o plug-in empacotará todos os recursos de string que seu app e as dependências dele fornecerem. Portanto, é necessário especificar cada localidade a ser empacotada pelo plug-in no seu APK.

• Como os módulos locais não podem depender do APK de teste do app, adicionar dependências aos seus testes instrumentados usando a configuração androidTestApi, em vez de androidTestImplementation, faz com que o Gradle emita o seguinte aviso:

  Groovy

  
  
  WARNING: Configuration 'androidTestApi' is obsolete
    and has been replaced with 'androidTestImplementation'
    

  Kotlin

  
  
  WARNING: Configuration 'androidTestApi' is obsolete
    and has been replaced with 'androidTestImplementation'
    

Correções

• Correção de um problema em que o Android Studio não reconhecia dependências em builds compostos.
• Correção de um problema em que havia um erro de sincronização do projeto ao carregar o plug-in do Android várias vezes em um único build. Por exemplo, quando vários subprojetos incluíam o plug-in do Android no caminho de classe do buildscript.

3.0.0 (outubro de 2017)

O Plug-in do Android para Gradle 3.0.0 inclui uma variedade de mudanças que buscam resolver problemas de desempenho em projetos grandes.

Por exemplo, em uma amostra de projeto esqueleto com aproximadamente 130 módulos e um grande número de dependências externas (mas nenhum código ou recursos), você pode ter melhorias de desempenho semelhantes às seguintes:

Algumas dessas alterações causam falha nas builds existentes. Portanto, você precisa considerar o esforço de migrar seu projeto antes de usar o novo plug-in.

Se você não perceber as melhorias de desempenho descritas acima, informe um bug e inclua um trace do seu build usando o Gradle Profiler (link em inglês).

Esta versão do plug-in do Android requer o seguinte:

• Gradle 4.1 (link em inglês) ou versões mais recentes. Para saber mais, leia a seção sobre como atualizar o Gradle.
• Build Tools 26.0.2 ou versões mais recentes. Com esta atualização, não será mais necessário especificar uma versão para o Build Tools. O plug-in usará a versão mínima necessária por padrão. Então, agora você pode remover a propriedade android.buildToolsVersion.

Otimizações

• Melhor paralelismo para projetos com vários módulos com um gráfico de tarefas detalhado.
• Ao fazer mudanças na dependência, o Gradle cria mais rapidamente porque não recompila módulos sem acesso à API dessa dependência. É necessário restringir quais dependências vazam APIs para outros módulos usando as novas configurações de dependência do Gradle: implementation, api, compileOnly e runtimeOnly.
• Maior velocidade de build incremental devido à dexação por classe. Agora, cada classe é compilada em arquivos DEX separados, e apenas as classes modificadas são redexadas. Também vai haver aumento na velocidade de build de apps que tenham definido a minSdkVersion como 20 ou menos e usem multi-dex legado.
• Velocidades de build aumentadas pela otimização de algumas tarefas para usar as saídas armazenadas em cache. Para aproveitar essa otimização, ative o cache de build do Gradle (link em inglês).
• Melhoria do processamento de recursos incrementais usando AAPT2, que agora é ativado por padrão. Caso tenha problemas ao usar o AAPT2, informe um bug. Você também pode desativar o AAPT2 configurando android.enableAapt2=false no seu arquivo gradle.properties e reiniciando o daemon Gradle executando ./gradlew --stop na linha de comando.

Novos recursos

• Gerenciamento de dependências com reconhecimento de variantes. Ao criar uma variante específica de um módulo, o plug-in agora faz a correspondência automática das variantes de dependências de módulo de biblioteca local com a variante do módulo que você está criando.
• Inclusão de um novo plug-in do módulo Feature para oferecer compatibilidade com Instant Apps Android e o SDK do Instant Apps Android (disponível para download usando o SDK Manager). Para saber mais sobre a criação de módulos Feature com o novo plug-in, leia Estrutura de um app instantâneo com vários recursos.
• Compatibilidade integrada com o uso de alguns recursos da linguagem Java 8 e respectivas bibliotecas. O Jack agora está obsoleto e não é mais necessário. Primeiro, é preciso desativar o Jack para usar a compatibilidade aprimorada com Java 8 integrada no conjunto de ferramentas padrão. Para mais informações, leia Usar recursos da linguagem Java 8.
• Compatibilidade com a execução de testes com o Android Test Orchestrator, que permite a execução de cada um dos testes do app na própria invocação de Instrumentation. Como cada teste é executado na própria instância de Instrumentation, nenhum estado compartilhado entre os testes se acumula na CPU ou na memória do dispositivo. Mesmo que um teste falhe, ele só removerá a própria instância de Instrumentation. Portanto, seus outros testes ainda serão executados.
  • Inclusão do testOptions.execution para determinar se a orquestração de teste será usada no dispositivo. Se você quiser usar o Android Test Orchestrator, especifique o ANDROID_TEST_ORCHESTRATOR, conforme mostrado abaixo. Por padrão, essa propriedade é configurada como HOST, o que desativa a orquestração no dispositivo e é o método padrão de execução de testes.

android {
  testOptions {
    execution 'ANDROID_TEST_ORCHESTRATOR'
  }
}

android {
  testOptions {
    execution = "ANDROID_TEST_ORCHESTRATOR"
  }
}

• A nova configuração de dependência androidTestUtil permite que você instale outro APK auxiliar de teste antes de executar testes de instrumentação, como o Android Test Orchestrator:

dependencies {
  androidTestUtil 'com.android.support.test:orchestrator:1.0.0'
  ...
}

dependencies {
  androidTestUtil("com.android.support.test:orchestrator:1.0.0")
  ...
}

• Inclusão de testOptions.unitTests.includeAndroidResources para oferecer suporte a testes de unidade que exigem recursos do Android, como Roboelectric (link em inglês). Quando você configura essa propriedade como true, o plug-in executa mesclagem de recursos, e manifestos antes de executar os testes de unidade. Seus testes podem inspecionar com/android/tools/test_config.properties no caminho de classe para as seguintes chaves:
  • android_merged_assets: o caminho absoluto para o diretório de assets mesclados.

    Observação: para módulos de biblioteca, os recursos mesclados não contêm os recursos de dependências. Consulte o problema 65550419.

  • android_merged_manifest: o caminho absoluto para o arquivo de manifesto mesclado.
  • android_merged_resources: o caminho absoluto para o diretório de recursos mesclados, que contém todos os recursos do módulo e suas respectivas dependências.
  • android_custom_package: o nome do pacote da classe R final. Se você modificar dinamicamente o ID do aplicativo, talvez esse nome de pacote não corresponda ao atributo package no manifesto do app.
• Suporte a fontes como recursos, que é um novo recurso introduzido no Android 8.0 (nível 26 da API).
• Compatibilidade com APKs específicos de idiomas com o SDK 1.1 do Instant Apps Android ou versões mais recentes.
• Agora, você pode mudar o diretório de saída para seu projeto de build nativo externo, conforme mostrado abaixo:

android {
    ...
    externalNativeBuild {
        // For ndk-build, instead use the ndkBuild block.
        cmake {
            ...
            // Specifies a relative path for outputs from external native
            // builds. You can specify any path that's not a subdirectory
            // of your project's temporary build/ directory.
            buildStagingDirectory "./outputs/cmake"
        }
    }
}

android {
    ...
    externalNativeBuild {
        // For ndk-build, instead use the ndkBuild block.
        cmake {
            ...
            // Specifies a relative path for outputs from external native
            // builds. You can specify any path that's not a subdirectory
            // of your project's temporary build/ directory.
            buildStagingDirectory = "./outputs/cmake"
        }
    }
}

• Agora você pode usar o CMake 3.7 ou versões mais recentes quando criar projetos nativos do Android Studio.
• A nova configuração de dependência lintChecks permite criar um JAR que define regras de lint personalizadas e o empacote nos seus projetos AAR e APK. Suas regras de lint personalizadas precisam pertencer a um projeto separado que produza um único JAR e inclua apenas dependências compileOnly. Dessa forma, outros apps e módulos de biblioteca podem depender do seu projeto de lint usando a configuração lintChecks.

dependencies {
    // This tells the Gradle plugin to build ':lint-checks' into a lint.jar file
    // and package it with your module. If the module is an Android library,
    // other projects that depend on it automatically use the lint checks.
    // If the module is an app, lint includes these rules when analyzing the app.
    lintChecks project(':lint-checks')
}

dependencies {
    // This tells the Gradle plugin to build ':lint-checks' into a lint.jar file
    // and package it with your module. If the module is an Android library,
    // other projects that depend on it automatically use the lint checks.
    // If the module is an app, lint includes these rules when analyzing the app.
    lintChecks(project(":lint-checks"))
}

Mudanças de comportamento

• O plug-in do Android 3.0.0 remove algumas APIs, e seu build terá falhas se você usá-las. Por exemplo, não é mais possível usar a API Variants para acessar objetos outputFile() ou usar processManifest.manifestOutputFile() para receber o arquivo de manifesto para cada variante. Para saber mais, leia as Mudanças na API.
• Não é mais necessário especificar uma versão para o Build Tools, portanto, agora você pode remover a propriedade android.buildToolsVersion. Por padrão, o plug-in usa automaticamente a versão mínima necessária do Build Tools para a versão do plug-in do Android que você está usando.
• Agora, você pode ativar ou desativar o processamento de PNG no bloco buildTypes, conforme mostrado abaixo. O processamento de PNG é ativado por padrão para todos os builds, exceto os de depuração, porque isso aumenta o tempo de compilação de projetos que tenham muitos arquivos PNG. Portanto, para melhorar os tempos de compilação de outros tipos, é necessário desativar o processamento de PNG ou converter suas imagens em WebP.

android {
  buildTypes {
    release {
      // Disables PNG crunching for the release build type.
      crunchPngs false
    }
  }
}

android {
  buildTypes {
    release {
      // Disables PNG crunching for the release build type.
      isCrunchPngs = false
    }
  }
}

• Agora, o plug-in do Android cria automaticamente destinos executáveis que podem ser configurados nos seus projetos externos do CMake.
• Agora você precisa adicionar processadores de anotações ao caminho de classe do processador usando a configuração de dependência annotationProcessor.
• O uso do ndkCompile, agora obsoleto, é mais restrito. Em vez disso, você precisa migrar para o CMake ou o ndk-build para compilar o código nativo que quer empacotar no seu APK. Para saber mais, leia Migrar do ndkcompile.

2.3.0 (fevereiro de 2017)

Dependências:

• Gradle 3.3 ou versões mais recentes
• Build Tools 25.0.0 ou versões mais recentes

Novidade:

• Usa o Gradle 3.3, que inclui melhorias de desempenho e novos recursos. Para ver mais detalhes, consulte as notas da versão do Gradle (em inglês).
• Cache de compilação: armazena algumas saídas geradas pelo plug-in do Android ao criar seu projeto, como AARs não empacotados e dependências remotas pré-dexadas. Seus builds limpos são muito mais rápidos quando você usa o cache, porque o sistema de compilação pode simplesmente reutilizar os arquivos em cache nos builds subsequentes, em vez de criá-los novamente. Os projetos que usam o plug-in do Android 2.3.0 e versões mais recentes usam o cache de build por padrão. Para saber mais, consulte Melhorar a velocidade de compilação com o cache de build.
  • Inclui uma tarefa cleanBuildCache que limpa o cache de compilação.
  • Se você está usando a versão experimental do cache de build, incluída em versões anteriores do plug-in, atualize o plug-in para a versão mais recente.

Mudanças:

• É compatível com mudanças no Instant Run incluídas no Android Studio 2.3.
• Os tempos de configuração de projetos muito grandes serão significativamente mais curtos.
• Correção de problemas com o download automático para a biblioteca Constraint Layout.
• O plug-in agora usa a versão 5.3.2 do ProGuard (link em inglês).
• Inclui muitas correções para bugs informados. Continue enviando relatórios de bugs quando encontrar problemas.

2.2.0 (setembro de 2016)

Dependências:

• Gradle 2.14.1 ou versões mais recentes
• Build Tools 23.0.2 ou versões mais recentes.

Novidade:

• Usa o Gradle 2.14.1, que inclui melhorias de desempenho e novos recursos, além de corrigir uma vulnerabilidade de segurança que permite o escalonamento de privilégios locais ao usar o daemon Gradle. Para ver mais detalhes, consulte as notas da versão do Gradle (link em inglês).
• Com o uso da DSL externalNativeBuild {}, o Gradle agora permite a vinculação a origens nativas e a compilação de bibliotecas nativas usando o CMake ou o ndk-build. Depois de criar suas bibliotecas nativas, o Gradle as empacota no seu APK. Para saber mais sobre como usar o CMake e o ndk-build com o Gradle, leia Adicionar código C e C++ ao seu projeto.
• Quando você executa um build na linha de comando, o Gradle agora tenta fazer o download automático de todos os componentes ou atualizações do SDK ausentes de que seu projeto depende. Para saber mais, leia Download automático de pacotes ausentes com o Gradle.
• Um novo recurso experimental de armazenamento em cache permite que o Gradle acelere o tempo de compilação ao fazer a pré-dexação, o armazenamento e a reutilização das versões pré-dexadas das bibliotecas. Para saber mais sobre como usar esse recurso experimental, leia o guia Cache de compilação.
• Melhora a performance de build adotando um novo pipeline de empacotamento padrão que cuida da compactação, assinatura e zipaligning em uma tarefa. Você pode voltar a usar as ferramentas de empacotamento anteriores adicionando android.useOldPackaging=true ao arquivo gradle.properties. Ao usar a nova ferramenta de empacotamento, a tarefa zipalignDebug não ficará disponível. No entanto, você pode criar uma chamando o método createZipAlignTask(String taskName, File inputFile, File outputFile).
• A assinatura do APK agora usa o Esquema de assinatura de APK v2, além da assinatura JAR tradicional. Todas as plataformas Android aceitam os APKs resultantes. Qualquer modificação nesses APKs, após a assinatura, invalida as assinaturas v2 e impede a instalação em dispositivos. Para desativar esse recurso, adicione o seguinte ao seu arquivo build.gradle no módulo:

  Groovy

  android {
    ...
    signingConfigs {
      config {
        ...
        v2SigningEnabled false
      }
    }
  }
  

  Kotlin

  android {
    ...
    signingConfigs {
      create("config") {
        ...
        v2SigningEnabled = false
      }
    }
  }
  

• Para builds multidex, agora você pode usar as regras do ProGuard para determinar quais classes o Gradle precisa compilar no arquivo DEX principal do app. Como o sistema Android carrega primeiro o arquivo DEX principal ao iniciar seu app, você pode priorizar determinadas classes na inicialização, compilando-as no arquivo DEX principal. Depois de criar um arquivo de configuração do ProGuard especificamente para seu arquivo DEX principal, transmita o caminho do arquivo de configuração para o Gradle usando buildTypes.multiDexKeepProguard. O uso dessa DSL é diferente do uso de buildTypes.proguardFiles, que fornece regras gerais do ProGuard para o app e não especifica classes para o arquivo DEX principal.
• Foi adicionado suporte à sinalização android:extractNativeLibs, que pode reduzir o tamanho do app quando você o instala em um dispositivo. Quando você configura essa sinalização como false no elemento <application> do manifesto do app, o Gradle compacta as versões descompactadas e alinhadas das suas bibliotecas nativas com seu APK. Isso impede que o PackageManager copie as bibliotecas nativas do APK para o sistema de arquivos do dispositivo durante a instalação, além de oferecer o benefício de diminuir as atualizações delta do seu app.
• Agora você pode especificar versionNameSuffix e applicationIdSuffix para variações de produto (problema 59614).

Mudanças:

• O getDefaultProguardFile agora retorna os arquivos do ProGuard padrão fornecidos pelo Plug-in do Android para Gradle e não usa mais os que estão no SDK do Android.
• Melhoria no desempenho e nos recursos do compilador Jack:
  • Agora, o Jack oferece suporte à cobertura de teste Jacoco quando testCoverageEnabled for configurado como true.
  • Suporte melhorado para processadores de anotações. Os processadores de anotações no seu caminho de classe, como as dependências compile, são aplicados automaticamente ao build. Você também pode especificar um processador de anotação no seu build e transmitir argumentos usando a DSL javaCompileOptions.annotationProcessorOptions {} no arquivo build.gradle no módulo:

    Groovy

    android {
      ...
      defaultConfig {
        ...
        javaCompileOptions {
          annotationProcessorOptions {
            className 'com.example.MyProcessor'
            // Arguments are optional.
            arguments = [ foo : 'bar' ]
          }
        }
      }
    }
    

    Kotlin

    android {
      ...
      defaultConfig {
        ...
        javaCompileOptions {
          annotationProcessorOptions {
            className = "com.example.MyProcessor"
            // Arguments are optional.
            arguments(mapOf(foo to "bar"))
          }
        }
      }
    }
    

    Se você quiser aplicar um processador de anotações no momento da compilação, sem incluir esse elemento no seu APK, use o escopo de dependência annotationProcessor:

    Groovy

    dependencies {
        compile 'com.google.dagger:dagger:2.0'
        annotationProcessor 'com.google.dagger:dagger-compiler:2.0'
       // or use buildVariantAnnotationProcessor to target a specific build variant
    }
    

    Kotlin

    dependencies {
        implementation("com.google.dagger:dagger:2.0")
        annotationProcessor("com.google.dagger:dagger-compiler:2.0")
       // or use buildVariantAnnotationProcessor to target a specific build variant
    }
    

  Para ver uma lista de parâmetros que podem ser configurados, execute o seguinte na linha de comando:

  java -jar /build-tools/jack.jar --help-properties
  

  • Por padrão, se o tamanho de heap do daemon Gradle for de pelo menos 1,5 GB, o Jack será executado no mesmo processo que o Gradle. Para ajustar o tamanho de heap do daemon, adicione o seguinte ao seu arquivo gradle.properties:

    # This sets the daemon heap size to 1.5GB.
    org.gradle.jvmargs=-Xmx1536M
    

2.1.0 (abril de 2016)

Dependências:

• Gradle 2.10 ou versões mais recentes
• Build Tools 23.0.2 ou mais recente.

Novidade:

• Inclusão de compatibilidade com os recursos da linguagem Java 8, do N Developer Preview e do JDK 8 usando o conjunto de ferramentas Jack. Para saber mais, leia o Guia do N Preview.

  Observação: o Instant Run não funciona com o Jack e vai ser desativado enquanto o novo conjunto de ferramentas estiver em uso. Você só precisa usar o Jack se estiver desenvolvendo para o N Preview e quiser usar os recursos da linguagem compatíveis com o Java 8.

• Suporte padrão à compilação Java incremental foi adicionado para reduzir o tempo de compilação durante o desenvolvimento. Isso é feito apenas com a recompilação de partes da origem que foram alteradas ou que precisam ser recompiladas. Para desativar esse recurso, adicione o seguinte ao seu arquivo build.gradle no módulo:

  Groovy

  android {
    ...
    compileOptions {
      incremental false
    }
  }
  

  Kotlin

  android {
    ...
    compileOptions {
      incremental = false
    }
  }
  

• Inclusão de compatibilidade com dexação no processo, executada no processo de compilação, e não em um processo de VM externo separado. Isso não só torna os builds incrementais mais rápidos, mas também agiliza os builds completos. O recurso é ativado por padrão para projetos com o tamanho de heap máximo do daemon Gradle configurado como, pelo menos, 2.048 MB. Você pode fazer isso incluindo o seguinte no arquivo gradle.properties do seu projeto:

  ```none org.gradle.jvmargs = -Xmx2048m ```

  Se você definiu um valor para javaMaxHeapSize no seu arquivo build.gradle no módulo, é necessário definir org.gradle.jvmargs para o valor de javaMaxHeapSize + 1024 MB. Por exemplo, se você configurou javaMaxHeapSize como "2048m", é necessário adicionar o seguinte ao arquivo gradle.properties do seu projeto:

  ```none org.gradle.jvmargs = -Xmx3072m ```

  Para desativar a dexação no processo, adicione o seguinte código ao seu arquivo build.gradle no módulo:

  Groovy

  android {
    ...
    dexOptions {
        dexInProcess false
    }
  }
  

  Kotlin

  android {
    ...
    dexOptions {
        dexInProcess = false
    }
  }
  

2.0.0 (abril de 2016)

Dependências:

• Gradle 2.10 ou versões mais recentes
• Build Tools 21.1.1 ou mais recente.

Novidade:

• Ativa o Instant Run oferecendo compatibilidade com a injeção de bytecode e com o envio de atualizações de código e recursos para um app em execução no emulador ou em um dispositivo físico.
• Foi adicionado suporte a builds incrementais mesmo quando o app não está em execução. Os tempos de compilação completos foram aprimorados pelo envio de mudanças incrementais pelo Android Debug Bridge ao dispositivo conectado.
• Inclusão do maxProcessCount (link em inglês) para controlar quantos processos de dex worker podem ser gerados simultaneamente. O código abaixo, presente no arquivo build.gradle do módulo, define o número máximo de processos simultâneos como 4:

  Groovy

  android {
    ...
    dexOptions {
      maxProcessCount = 4 // this is the default value
    }
  }
  

  Kotlin

  android {
    ...
    dexOptions {
      maxProcessCount = 4 // this is the default value
    }
  }
  

• Inclusão de um redutor de código experimental para ser compatível com a pré-dexação e reduzir a redexação de dependências, que não são compatíveis com o Proguard. Isso melhora a velocidade de compilação da variante de depuração. Como o redutor experimental não é compatível com otimização e ofuscação, é importante ativar o Proguard nos seus builds de lançamento. Para ativar o redutor experimental para seus builds de depuração, adicione o seguinte ao arquivo build.gradle no módulo:

  Groovy

  android {
    ...
    buildTypes {
      debug {
        minifyEnabled true
        useProguard false
      }
      release {
        minifyEnabled true
        useProguard true // this is a default setting
      }
    }
  }
  

  Kotlin

  android {
    ...
    buildTypes {
      getByName("debug") {
        minifyEnabled = true
        useProguard = false
      }
      getByName("release") {
        minifyEnabled = true
        useProguard = true // this is a default setting
      }
    }
  }
  

• Inclusão da compatibilidade com geração de registros e desempenho aprimorado do redutor de recurso. O redutor de recurso agora registra todas as operações em um arquivo resources.txt localizado na mesma pasta dos arquivos de registros do Proguard.

Comportamento alterado:

• Quando minSdkVersion é configurado como 18 ou mais, a assinatura do APK usa o SHA256.
• As chaves de DSA e ECDSA agora podem assinar pacotes de APK.

  Observação: o provedor Android Keystore não oferece mais suporte a chaves DSA no Android 6.0 (API de nível 23) e versões mais recentes.

Problemas corrigidos:

• Correção de um problema que causava dependências AAR duplicadas nas configurações teste e de compilação principal.

Versões anteriores