Esta página foi traduzida pela API Cloud Translation.

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

Gradle 4.1 ou mais recente. Para saber mais, leia a seção sobre como atualizar o Gradle.
Build Tools 26.0.2 ou mais recente. Com esta atualização, não vai ser mais necessário especificar uma versão para o Build Tools. O plug-in vai usar 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 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 executa builds mais rápidos, não compilando novamente os módulos que não têm acesso à API dessa dependência. Para restringir quais dependências vazam APIs para outros módulos, use 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 é um novo recurso introduzido no Android 8.0 (nível 26 da API).
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.