O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

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 para 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 saber como configurar suas versões do Android com o Gradle, consulte as seguintes páginas:

Para mais informações sobre o sistema de compilação do Gradle, consulte o Guia do usuário do Gradle (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 uma versão manualmente 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 a seguir define o plug-in para a versão 3.6.0 no arquivo build.gradle: 

    buildscript {
        repositories {
            // Gradle 4.1 and higher include support for Google's Maven repo using
            // the google() method. And you need to include this repo to download
            // Android Gradle plugin 3.0.0 or higher.
            google()
            ...
        }
        dependencies {
            classpath 'com.android.tools.build:gradle:3.6.0'
        }
    }

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 seu projeto ou clicar em Tools > Android > 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 versão do seu 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 o melhor desempenho, use a versão mais recente possível do Gradle e do plug-in.

Versão do plug-inVersão necessária do Gradle
1.0.0 - 1.1.32.2.1 - 2.3
1.2.0 - 1.3.12.2.1 - 2.9
1.5.02.2.1 - 2.13
2.0.0 - 2.1.22.10 - 2.13
2.1.3 - 2.2.32.14.1+
2.3.0+3.3+
3.0.0+4.1+
3.1.0+4.4+
3.2.0 - 3.2.14.6+
3.3.0 - 3.3.24.10.1+
3.4.0 - 3.4.15.1.1+
3.5.0-3.5.35.4.1+
3.6.0+5.6.4+

Você pode especificar a versão do Gradle acessando o menu File > Project Structure > Project no Android Studio ou editando a referência de distribuição do Gradle no arquivo gradle/wrapper/gradle-wrapper.properties. O exemplo a seguir define a versão do Gradle como 5.4.1 no arquivo gradle-wrapper.properties. 

    ...
    distributionUrl = https\://services.gradle.org/distributions/gradle-5.4.1-all.zip
    ...

3.6.0 (fevereiro de 2020)

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

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 tempo de compilação quando há referências a visualizações no seu 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
    }

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 suporte para o plug-in do Maven Publish para Gradle, que permite a publicação de artefatos de compilação em um repositório Apache Maven. O Plug-in do Android para Gradle cria um componente para cada artefato de variante de compilação no módulo do aplicativo ou da biblioteca usado para personalizar uma publicação para um repositório Maven.

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

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 rastros 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 versão, faça o seguinte:

  1. Adicione a sinalização -Pandroid.enableProfileJson=true ao gerar uma versão do Gradle. 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:

Traço de atribuição da versão nativa no Chrome

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. 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 da Biblioteca A 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 da Biblioteca, se você incluir um recurso para um idioma que não inclui 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 inclui mais esse recurso ao compilar seu projeto. Essa mudança de comportamento deve resultar 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 de classe, 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 o acesso a essas anotações durante o tempo de execução ao compilar seu aplicativo usando versões mais antigas do Plug-in do Android para Gradle e do D8.

Outras alterações 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 seu app definir permissões personalizadas no manifesto, o Plug-in do Android para Gradle normalmente gerará uma classe Manifest.java que inclui 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 da atualização do plug-in, o foco foi, sobretudo, 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:

3.5.3 (dezembro de 2019)

Esta pequena atualização é compatível com o Android Studio 3.5.3 e inclui várias correções de bugs e melhorias no desempenho.

3.5.2 (novembro de 2019)

Esta pequena atualização é compatível com o Android Studio 3.5.2 e inclui várias correções de bugs e melhorias no desempenho. Para ver uma lista de correções de bugs em destaque, leia a postagem correspondente no blog de atualizações de versão (link em inglês).

3.5.1 (outubro de 2019)

Esta pequena atualização é compatível com o Android Studio 3.5.1 e inclui várias correções de bugs e melhorias no desempenho. Para ver uma lista de correções de bugs em destaque, leia a postagem correspondente no blog de atualizações de versão (link em inglês).

Processamento incremental de anotações

O processador de anotações da Vinculação de dados será compatível com o processamento incremental de anotações (link em inglês) se você definir android.databinding.incremental=true no seu 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 para 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 versão anterior, o seguinte aviso pode ser exibido ao compilar 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:

3.4.2 (julho de 2019)

Esta pequena atualização é compatível com o Android Studio 3.4.2 e inclui várias correções de bugs e melhorias no desempenho. Para ver uma lista de correções de bugs em destaque, leia a postagem correspondente no blog de atualizações de versão (em inglês).

3.4.1 (maio de 2019)

Esta pequena atualização é compatível com o Android Studio 3.4.1 e inclui várias correções de bugs e melhorias no desempenho. Para ver uma lista de correções de bugs em destaque, leia a postagem correspondente no blog de atualizações de versão (em inglês).

Novos recursos

  • Novas configurações de dependência de verificação de lint: o comportamento de lintChecks foi alterado, 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.

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

    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 suspensão do uso do plug-in Instant Apps Android: 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 exibirá um aviso de suspensão de uso. 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, a redução, a ofuscação, a otimização e a dexação em uma única etapa, o que resulta em melhorias significativas no desempenho da versão (link em inglês). O R8 foi introduzido no Plug-in do Android para Gradle 3.3.0 e agora é ativado por padrão para projetos de biblioteca de aplicativos e do Android que usam o plug-in 3.4.0 ou versões posteriores.

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

    Antes do R8, o ProGuard era uma etapa de build diferente da dexação e da simplificação de leitura.

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

    Com o R8, a simplificação, a redução, a ofuscação, a otimização e a dexação são realizadas em uma única etapa de build.

    Lembre-se de que o R8 foi projetado para funcionar com suas regras existentes 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. Portanto, nessa situação improvável, talvez seja necessário adicionar outras regras para manter esse código no seu resultado do build.

    Se você tiver problemas ao usar o R8, leia as Perguntas frequentes de compatibilidade do R8 (link em inglês) para verificar se há uma solução para o problema. 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 ndkCompileestá obsoleto: agora você receberá um erro de versão se tentar usar o ndkBuild para compilar suas 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 seu 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 por meio do 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:

3.3.2 (março de 2019)

Esta pequena atualização é compatível com o Android Studio 3.3.2 e inclui várias correções de bugs e melhorias no desempenho. Para ver uma lista de correções de bugs em destaque, leia a postagem correspondente no blog de atualizações de versão (em inglês).

3.3.1 (fevereiro de 2019)

Esta atualização pequena é compatível com o Android Studio 3.3.1 e inclui várias correções de bugs e melhorias no desempenho.

Novos recursos

  • Melhoria na sincronização de caminho de classe: ao resolver dependências nos seus caminhos de classe de tempo de execução e build, 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 ambiente de execução incluir a Biblioteca A versão 2.0 e o de build incluir a Biblioteca A versão 1.0, o plug-in automaticamente atualizará a dependência do caminho de classe de build para a Biblioteca A 2.0 para evitar erros.

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

  • Melhoria no build incremental em Java ao usar processadores de anotações: esta atualização diminui o tempo de compilação porque melhora a compatibilidade com build incremental em Java durante o uso de 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): o build incremental em Java é ativado, 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 forem compatíveis com o processamento incremental de anotações, o build incremental em Java será ativado por padrão. Para monitorar a adoção do processador de anotações incremental, veja o problema 5277 do Gradle (links em inglês).

      Entretanto, se um ou mais processadores de anotações não forem compatíveis com versões incrementais, o build incremental em Java não será ativado. 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 build em Java sejam executadas de forma incremental.

  • Informações de depuração melhores ao usar 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 dinâmicos na 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, saiba como adaptar-se à nova API de criação de tarefas do Gradle (link em inglês).

  • Para um determinado tipo de compilação, ao configurar useProguard false, o plug-in agora usará o R8 em vez do ProGuard para reduzir e ofuscar o código e os recursos do seu 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 aplicativos voltado ao Android 6.0 (nível de API 23) 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 versão, 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 posterior com o Plug-in do Android para Gradle 3.3.0 ou versões posteriores. Quando você atende a esses requisitos, o IDE 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 é totalmente compatível com projetos que incluem as linguagens Java e C++, e é parcialmente compatível com 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 build chama android.support.v8.renderscript.RenderScript em vez da versão do AndroidX, mesmo que o Jetifier esteja ativado.
    • Conflitos porque o androidx-rs.jar inclui este elemento com empacotamento estático: annotation.AnyRes.
    • Quando você 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:

3.2.1 (outubro de 2018)

Com esta atualização, não será mais necessário especificar uma versão para o SDK Build Tools. O Plug-in do Android para Gradle agora usa a versão 28.0.3 por padrão.

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 seu aplicativo, ao mesmo tempo em que 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.

  • Compatibilidade com velocidades aprimoradas de build incremental ao usar processadores de anotações: a DSL AnnotationProcessorOptionsagora estende 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 limpas incrementais e em cache. Para saber mais, leia Transmitir argumentos para os processadores de anotações.

  • Ferramenta de migração para 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 migra 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, haverá 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:

    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:

    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 API do Android de nível 21 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 ativa 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 do módulo de recurso dinâmico.

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 build para módulos de biblioteca com vinculação de dados (problema 77539932).
  • Agora, você poderá reativar a configuração sob demanda se tiver desativado em versões anteriores devido a alguns erros de build imprevisíveis (problema 77910727, links em inglês).

3.1.0 (março de 2018)

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

  • Gradle 4.4 ou versões mais recentes (link em inglês). Para saber mais, leia a seção sobre a atualização do Gradle.
  • Build Tools 27.0.3 ou versões posteriores. Lembre-se de 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 usa um novo compilador DEX chamado D8. O build 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, chamado DX, o D8 compila mais rapidamente e gera arquivos DEX menores, com desempenho em tempo de execução do aplicativo igual ou superior.

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 de leitura 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'
          ...
      }
    }

  • Ao criar APKs de configuração para um Instant App Android, as divisões de configuração de idioma agora são agrupadas pelo idioma raiz por padrão. Por exemplo, se o app incluir recursos para localidades zh-TW ou zh-CN, o Gradle empacotará esses recursos em uma divisão de configuração do idioma zh. Para modificar esse comportamento, defina seus próprios grupos usando a propriedade include, conforme mostrado abaixo:

    splits {
        language {
            enable true
            // Each string defines a group of locales that
            // Gradle should package together.
            include "in,id",
                    "iw,he",
                    "fil,tl,tgl",
                    "yue,zh,zh-TW,zh-CN"
        }
    }

  • O cache de build do plug-in do Android agora exibe entradas de cache com mais de 30 dias.

  • Passar "auto" para resConfig não seleciona mais recursos de string automaticamente para empacotar no seu APK (link em inglês). 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 seu 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:

      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 reconhece dependências em builds compostas.
  • Correção de um problema em que há 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 incluem 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 de grandes projetos.

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

Versão do plug-in do Android + versão do Gradle Plug-in do Android 2.2.0 + Gradle 2.14.1 Plug-in do Android 2.3.0 + Gradle 3.3 Plug-in do Android 3.0.0 + Gradle 4.1
Configuração (por exemplo, executando ./gradlew --help) Cerca de 2 min Cerca de 9 s Cerca de 2,5 s
Alteração de 1 linha no Java (alteração de implementação) Cerca de 2 min 15 s Cerca de 29 s Cerca de 6,4 s

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 sentir 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 ou versões mais recentes (link em inglês). Para saber mais, leia a seção sobre a atualização do Gradle.
  • Build Tools 26.0.2 ou versões posteriores. Com esta atualização, não será mais necessário especificar uma versão para o Build Tools. O plug-in usa a versão mínima necessária por padrão. Então, agora você pode remover a propriedade android.buildToolsVersion.

3.0.1 (novembro de 2017)

Esta é uma atualização pequena para oferecer compatibilidade com o Android Studio 3.0.1 e inclui correções gerais de bugs e melhorias no desempenho.

Otimizações

  • Melhor paralelismo para projetos com vários módulos por meio de um gráfico de tarefas detalhado.
  • Ao fazer mudanças na dependência, o Gradle executa builds mais rápidos 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 (link em inglês).
  • 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 haverá aumento na velocidade de build de aplicativos que tenham minSdkVersion configurado como 20 ou menos e usem multi-dex legado.
  • Velocidades de build aumentadas pela otimização de determinadas tarefas para usar as saídas em cache. Para aproveitar essa otimização, é necessário ativar o cache de build do Gradle.
  • 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 da linha de comando.

Novos recursos

  • Gerenciamento de dependências com reconhecimento de variantes. Agora, na criação de determinada variante de um módulo, o plug-in 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á compilando.
  • 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 seu aplicativo 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'
      }
    }
  • 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'
      ...
    }
  • Inclusão de testOptions.unitTests.includeAndroidResources para oferecer compatibilidade com 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, assets e manifestos antes de executar 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 assets mesclados não contêm os assets de dependências. Consulte o problema 65550419 (link em inglês).

    • 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 aplicativo.
  • Compatibilidade com fontes como recursos, que é um novo recurso introduzido no Android 8.0 (API de nível 26).
  • Compatibilidade com APKs específicos de idiomas com o SDK 1.1 do Instant Apps Android ou versões mais recentes. Para ver mais informações, consulte Configurar sua versão para divisões puras.
  • 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"
            }
        }
    }
  • 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 que você construa um JAR que defina 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')
    }

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 o processamento de PNG no bloco buildTypes, conforme mostrado abaixo. O processamento de PNG é ativado por padrão para todas as versões, exceto as de depuração, porque isso aumenta o tempo de build 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
        }
      }
    }
  • 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)

2.3.3 (junho de 2017)

Esta é uma pequena atualização que adiciona compatibilidade com o Android Studio 2.3.3.

2.3.2 (maio de 2017)

Esta é uma pequena atualização que adiciona compatibilidade com o Android Studio 2.3.2.

2.3.1 (abril de 2017)

Esta é uma pequena atualização no plug-in do Android 2.3.0 que corrige um problema em que alguns dispositivos físicos Android não funcionavam corretamente com o Instant Run Consulte o problema 235879 (link em inglês).

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

2.2.0 (setembro de 2016)

Dependências:
Novidade:
  • Usa o Gradle 2.14.1, que inclui melhorias de desempenho e novos recursos, e corrige uma vulnerabilidade de segurança que permite o escalonamento de privilégios locais ao usar o daemon Gradle. Para 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 fontes nativas e a compilação build de bibliotecas nativas usando o CMake ou o ndk-build. Depois de criar suas bibliotecas nativas, o Gradle as insere 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 predexar, armazenar e reutilizar as versões pré-dexadas das suas bibliotecas. Para saber mais sobre como usar esse recurso experimental, leia o guia Cache de build.
  • Melhora o desempenho do 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: 
        android {
      ...
      signingConfigs {
        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 aplicativo. Como o sistema Android carrega primeiro o arquivo DEX principal ao iniciar seu aplicativo, 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 seu app e não especifica classes para o arquivo DEX principal.
  • Adiciona compatibilidade com a sinalização android:extractNativeLibs, que pode reduzir o tamanho do seu 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 versões descompactadas e alinhadas das suas bibliotecas nativas com seu APK. Isso impede que o PackageManagercopie suas 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, link em inglês).
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 compatibilidade com a cobertura de teste Jacoco quando testCoverageEnabled for configurado como true.
    • Melhoria na compatibilidade com processadores de anotações. Os processadores de anotações no seu caminho de classe, como as dependências compile, são aplicados automaticamente à build. Você também pode especificar um processador de anotação no seu build e transmitir argumentos usando a DSL javaCompileOptions.annotationProcessorOptions {} (link em inglês) no arquivo build.gradle no módulo: 
          android {
      ...
      defaultConfig {
        ...
        javaCompileOptions {
          annotationProcessorOptions {
            className 'com.example.MyProcessor'
            // Arguments are optional.
            arguments = [ foo : 'bar' ]
          }
        }
      }
    }

      Se você quiser aplicar um processador de anotações no tempo de compilação, mas não incluí-lo no seu APK, use o escopo de dependência annotationProcessor: 

          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
    }
    • É possível definir outras sinalizações para o Jack usando jackOptions.additionalParameters() (link em inglês). O snippet de código a seguir ilustra como usar o parâmetro jack.incremental como true: 
          android {
      defaultConfig {
        ...
        jackOptions {
          enabled true
          additionalParameters("jack.incremental" : true)
        }
      }
    }

      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)

2.1.3 (agosto de 2016)

Esta atualização requer o Gradle 2.14.1 e versões mais recentes. O Gradle 2.14.1 inclui melhorias de desempenho, novos recursos e uma correção de segurança importante. Para mais detalhes, consulte as notas da versão do Gradle (link em inglês).

Dependências:
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 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.

  • Inclusão de compatibilidade padrão com compilação Java incremental para reduzir o tempo de compilação durante o desenvolvimento. Isso é feito apenas com a recompilação de partes da fonte que foram alteradas ou que precisam ser recompiladas. Para desativar esse recurso, adicione o seguinte ao seu arquivo build.gradle no módulo: 
        android {
      ...
      compileOptions {
        incremental false
      }
    }

  • Inclusão de compatibilidade com dexação no processo, executada no processo de build, e não em um processo de VM externo separado. Isso não só torna as builds incrementais mais rápidas, mas também agiliza as builds completas. 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: 

        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 (link em inglês). Por exemplo, se você configurou javaMaxHeapSize como "2048m", é necessário adicionar o seguinte ao arquivo gradle.properties do seu projeto: 

        org.gradle.jvmargs = -Xmx3072m

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

        android {
      ...
      dexOptions {
          dexInProcess false
      }
    }

2.0.0 (abril de 2016)

Dependências:
Novidade:
  • Ativa o Instant Run por meio da compatibilidade com a injeção de bytecode e com o envio de atualizações de código e recursos para um aplicativo em execução no emulador ou em um dispositivo físico.
  • Inclusão de compatibilidade com compilações 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 para controlar quantos processos de dex subordinados podem ser gerados simultaneamente (link em inglês). O código a seguir, presente no arquivo build.gradle do módulo, define o número máximo de processos simultâneos como 4: 
        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 nas suas builds de versão. Para ativar o redutor experimental para suas versões de depuração, adicione o seguinte ao arquivo build.gradle no módulo: 
        android {
      ...
      buildTypes {
        debug {
          minifyEnabled true
          useProguard false
        }
        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 é mais compatível com chaves DSA no Android 6.0 (nível de API 23) e versões mais recentes.

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

Versões anteriores

Anterior
Ferramentas de versão do SDK
Próxima
Plataforma do SDK