Plug-in do Android para Gradle 3.0.0 (outubro de 2017)

O Plug-in do Android para Gradle 3.0.0 inclui várias mudanças que buscam resolver problemas de desempenho de grandes projetos.

Por exemplo, em um exemplo 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 parecidas com estas:

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 mudanças causam falha nos 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 rastro do seu build usando o Gradle Profiler (em inglês).

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

Versão mínima Versão padrão Observações
Gradle 4.1 4.1 Para saber mais, consulte Como atualizar o Gradle.
Ferramentas de build do SDK 26.0.2 26.0.2 Instale ou configure as Ferramentas de build do SDK. 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, você pode remover a propriedade android.buildToolsVersion.

3.0.1 (novembro de 2017)

Esta é uma atualização pequena para oferecer suporte ao 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 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 (em inglês).
  • O processamento de recursos incrementais foi melhorado com o uso de 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.
  • Incluído um novo plug-in do módulo Feature para oferecer suporte a Apps instantâneos Android e o SDK deles (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.
  • Suporte integrado ao uso de alguns recursos da linguagem Java 8 e respectivas bibliotecas. O Jack foi descontinuado e não é mais necessário. Primeiro, é preciso desativar o Jack para usar o suporte aprimorado com Java 8 integrado no conjunto de ferramentas padrão. Para saber mais, leia Usar recursos da linguagem Java 8.

  • Foi adicionado suporte à execução de testes com o Android Test Orchestrator, que permite a execução de cada um dos testes do seu app na própria invocação de Instrumentação. Como cada teste é executado na própria instância de instrumentação, nenhum estado compartilhado entre os testes se acumula na CPU ou na memória do dispositivo. Mesmo que um teste falhe, ele só vai remover a própria instância de Instrumentação. Portanto, seus outros testes ainda serão executados.

    • testOptions.execution foi adicionado 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.

    Groovy

            android {
          testOptions {
            execution 'ANDROID_TEST_ORCHESTRATOR'
          }
        }

    Kotlin

            android {
          testOptions {
            execution = "ANDROID_TEST_ORCHESTRATOR"
          }
        }

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

    Groovy

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

    Kotlin

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

  • testOptions.unitTests.includeAndroidResources foi adicionado para oferecer suporte a testes de unidade que exigem recursos do Android, como Roboelectric (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 é uma nova funcionalidade apresentada no Android 8.0 (API de nível 26).
  • Suporte a APKs específicos de idiomas com o SDK 1.1 do Apps instantâneos Android ou mais recente.

  • Agora, você pode mudar o diretório de saída para seu projeto de build nativo externo, conforme mostrado abaixo:

    Groovy

            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"
                }
            }
        }

    Kotlin

            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 mais recente 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:

    Groovy

            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')
        }

    Kotlin

            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 vai apresentar 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 build de projetos que tenham muitos arquivos PNG. Para melhorar os tempos de build de outros tipos, é necessário desativar o processamento de PNG ou converter suas imagens em WebP.

    Groovy

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

    Kotlin

          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 descontinuado é 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.