Plug-in do Android para Gradle 4.1.0 (agosto de 2020)

Compatibilidade

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

• Gradle 6.5. Para saber mais, leia a seção sobre como atualizar o Gradle.

• SDK Build Tools 29.0.2 ou mais recente.

A versão padrão do NDK neste lançamento é 21.1.6352462. Para instalar uma versão diferente do NDK, consulte Instalar uma versão específica do NDK.

Novos recursos

Esta versão do Plug-in do Android para Gradle (AGP, na sigla em inglês) inclui os novos recursos a seguir.

Suporte à 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.

Importante: se você já adotou scripts de build KTS ou usa Kotlin em buildSrc, isso pode causar falhas na compatibilidade de origem de alguns erros que teriam ocorrido como erros de execução em versões anteriores.

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

val collection: MutableCollectionType

Isso significa que não é mais possível escrever o código abaixo em scripts Kotlin para algumas coleções que ofereciam suporte anteriormente:

collection = collectionTypeOf(...)

No entanto, a modificação da coleção é aceita de maneira 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. A partir do AGP 4.1, é 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 {
    <var>mylibrary</var&;gt {
      headers "src/main/cpp/<var>mylibrary</var>/include"
    }
<var>myotherlibrary</var> {
    headers "src/main/cpp/<var>myotherlibrary</var>/include"
}

}
     
buildFeatures {
    prefabPublishing = true
}


prefab {
    create("<var>mylibrary</var>") {
      headers = "src/main/cpp/<var>mylibrary</var>/include"
    }
create("<var>myotherlibrary</var>") {
    headers = "src/main/cpp/<var>myotherlibrary</var>/include"
}

}
      

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

Observação: para usuários do Plug-in do Android para Gradle 4.0 e versões mais recentes, as configurações de importação de bibliotecas nativas pré-criadas foram modificadas. Para mais informações, consulte as Notas da versão 4.0.

R8 oferece suporte a metadados Kotlin

O Kotlin usa metadados personalizados em arquivos de classe Java para identificar construções de linguagem Kotlin. O R8 agora oferece suporte à manutenção e reescrita de metadados Kotlin para suporte total à redução de bibliotecas e aplicativos Kotlin que usam kotlin-reflect.

Para armazenar os metadados do Kotlin, adicione estas regras keep:

-keep class kotlin.Metadata { *; }


-keepattributes RuntimeVisibleAnnotations

Isso instrui 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 Kotlin usando a reflexão Kotlin com R8{:.external} (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) vai reescrever o código do seu app para permitir declarações durante a 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 build.

A tarefa cleanBuildCache e as propriedades android.enableBuildCache e android.buildCacheDir foram descontinuadas e serão removidas no AGP 7.0. Atualmente, a propriedade android.enableBuildCache não tem efeito, já a propriedade android.buildCacheDir e a tarefa cleanBuildCache vão continuar funcionando até o AGP 7.0 para excluir qualquer conteúdo do cache de build do AGP.

O tamanho dos apps que usam a redução de código diminuiu significativamente

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 resulta em uma mudança de comportamento, a menos que você esteja acessando classes R por reflexão. Nesse caso, é necessário adicionar regras keep para elas.

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

A flag experimental android.namespacedRClass foi renomeada como android.nonTransitiveRClass.

Definida no arquivo gradle.properties, essa flag ativa o namespace da classe R de cada biblioteca para incluir apenas os recursos declarados na própria biblioteca e não os declarados nas dependências, reduzindo assim o tamanho da classe R dessa biblioteca.

DSL do Kotlin: renomeação de coreLibraryDesugaringEnabled

A opção de compilação DSL do Kotlin coreLibraryDesugaringEnabled foi alterada para isCoreLibraryDesugaringEnabled. Para mais informações sobre essa flag, consulte Suporte à simplificação de APIs do Java 8+ (Plug-in do Android para Gradle 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 eram 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ê usa essa propriedade com a propriedade android.ndkVersion, esse caminho precisa 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/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 ter problemas causados por 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 entender melhor o SDK descontinuado do Fabric e a migração para o SDK do Firebase Crashlytics, consulte Fazer upgrade para o SDK do Firebase Crashlytics.