Interdependências de ferramentas e bibliotecas

As dependências de build são componentes externos necessários para criar seu projeto. Um build pode depender de bibliotecas, plug-ins, subprojetos, do SDK do Android, ferramentas como os compiladores do Kotlin e do Java, ambientes de desenvolvimento como o Android Studio e o próprio Gradle.

Cada dependência pode exigir outras dependências. Chamamos essas dependências transitivas e podemos aumentar rapidamente as dependências gerais usadas pelo aplicativo. Quando você quer fazer upgrade de uma dependência, seja uma biblioteca, ferramenta ou o SDK do Android, esse upgrade pode ser em cascata, atualizando muitas outras dependências.

Muitas vezes, isso não causa problemas, já que muitas bibliotecas seguem um esquema conhecido como controle de versões semântico. Essas bibliotecas restringem os tipos de mudanças que fazem para oferecer compatibilidade com as versões anteriores.

O controle de versões semântico segue um formato major.minor.patch. Por exemplo, no número de versão 4.8.3, 4 é a versão major, 8 é a versão minor e 3 é o número patch. Quando a parte major muda, a biblioteca pode ter mudanças de ruptura na API ou no comportamento. Isso pode afetar o comportamento do build ou do aplicativo.

Quando as partes minor (novos recursos) ou patch (correções de bugs) mudam, os desenvolvedores da biblioteca informam que ela ainda é compatível e não vai afetar seu aplicativo.

É importante observar essas mudanças, porque várias ferramentas de upgrade de dependência podem ajudar.

Relacionamentos no build

Os builds do Android contêm relações entre:

• Código-fonte: o código e os recursos que você controla
• Dependências de biblioteca: bibliotecas ou módulos externos que seu projeto e subprojetos incluem ao criar
• Ferramentas: compiladores, plug-ins e SDKs que traduzem a origem em um aplicativo ou biblioteca

Código-fonte

O código-fonte é o código em Kotlin ou Java que você escreve no aplicativo ou na biblioteca. Para mais detalhes sobre o uso de C++, consulte Android NDK.

O código-fonte depende de bibliotecas (incluindo bibliotecas de execução Kotlin e Java) e do SDK do Android, além de exigir o compilador Kotlin ou Java correspondente.

Alguns códigos-fonte incluem anotações que exigem processamento adicional. Por exemplo, se você estiver escrevendo código do Jetpack Compose, adicione anotações como @Composable que precisam ser processadas pelo plug-in do compilador Kotlin do Compose. Outras anotações podem ser processadas por um processador de símbolos do Kotlin (KSP) ou por ferramentas de processamento de anotações separadas.

Dependências de biblioteca

As bibliotecas contêm bytecodes puxados como parte do seu aplicativo. Ele pode ser um Java JAR, uma biblioteca Android (AAR) ou um subprojeto no seu build. Muitas bibliotecas seguem o controle de versões semânticas, que pode ajudar a entender quando elas permanecem compatíveis (ou não) quando atualizadas.

As bibliotecas podem depender de outras bibliotecas para reutilização, o que é chamado de dependência transitiva. Isso reduz as dependências que você precisa gerenciar explicitamente. Especifique as dependências que você usa diretamente e o Gradle as puxa junto com essas dependências transitivas. Esteja ciente de que, à medida que você atualiza suas dependências diretas, elas podem atualizar essas dependências transitivas.

Às vezes, uma biblioteca pode exigir versões mínimas do SDK do Android no ambiente de execução (minSdk) ou no momento da compilação (compileSdk). Isso é necessário quando uma biblioteca usa funções incluídas no SDK do Android ou nas APIs do JDK fornecidas. O minSdk efetivo do aplicativo é o minSdk mais alto solicitado pelo aplicativo e todas as dependências de biblioteca diretas e transitivas dele.

O uso de algumas bibliotecas pode exigir o uso de um plug-in específico do Gradle. Esses plug-ins auxiliares geralmente instalam processadores de símbolos Kotlin ou outros processadores de anotações que geram código ou modificam a compilação da fonte para oferecer suporte ao uso de recursos da biblioteca. Por exemplo, o Jetpack Room inclui anotações e um KSP que os transforma em código gerado para recuperar e modificar dados em um banco de dados. O Jetpack Compose exige que o plug-in do compilador do Compose modifique funções anotadas para gerenciar como e quando essa função é executada novamente.

Ferramentas

Escopos do Gradle

O Gradle agrupa as dependências de biblioteca em diferentes escopos (chamados configurações na API do Gradle), permitindo que você especifique diferentes conjuntos de dependências de biblioteca para serem usados em diferentes partes do build. Por exemplo, provavelmente você não quer incluir bibliotecas de teste (como JUnit) no aplicativo ou biblioteca publicado, mas precisa delas ao criar e executar testes de unidade. Você também usa escopos para adicionar processadores de símbolos ou anotações para analisar seu código.

Por exemplo, o AGP define os escopos implementation e api, sua maneira de especificar se uma dependência precisa ser exposta aos usuários do subprojeto. Consulte Configurar dependências para descrições desses e de outros escopos usados em um build do Android.

Adicione dependências de biblioteca no bloco dependencies dos arquivos de build como strings group:artifact:version:

// In a module-level build script
// explicit dependency strings ("group:artifact:version")
dependencies {
    implementation("com.example:library1:1.2.3")
    api("com.example:library2:1.1.1")
}

// In a module-level build script
// explicit dependency strings ("group:artifact:version")
dependencies {
    implementation 'com.example:library1:1.2.3'
    api 'com.example:library2:1.1.1'
}

ou em um catálogo de versões:

# Version catalog - gradle/libs.versions.toml
[versions]
exampleLib = "1.2.3"
examplePlugin = "2.3.4"

[libraries]
example-library = { group = "com.example", name = "library", version.ref = "exampleLib" }

[plugins]
example-plugin = { id = "com.example.plugin", version.ref = "examplePlugin" }

e especifique as variáveis geradas nos arquivos de build:

// In a module-level build script
// Using a version catalog
plugins {
    alias(libs.plugins.example.plugin)
}

dependencies {
    implementation(libs.example.library)
}

// In a module-level build script
// Using a version catalog
plugins {
    alias(libs.plugins.example.plugin)
}

dependencies {
    implementation libs.example.library
}