Gradle é um sistema de compilação que automatiza a compilação, os testes e o empacotamento de aplicativos Android. Ao contrário do Apache Ant ou Maven, ele suporta compilação incremental e armazenamento em cache de resultados. Saiba mais sobre seus recursos em a documentação oficial do Gradle. Desde 2013, a ferramenta é usada como sistema de compilação padrão para projetos Android no Android Studio.
Pontos-chave
Gradle é uma ferramenta de automação de compilação de código aberto escrita em Java, executada na JVM. Ela recebe como entrada código-fonte, dependências e recursos, e produz como saída um aplicativo pronto — APK ou AAB para Android. Em seu núcleo, o Gradle usa o conceito de um Grafo Acíclico Direcionado (DAG) de tarefas, onde cada tarefa é uma unidade atômica de trabalho e as conexões entre elas determinam a ordem de execução. Ao contrário do Make ou Ant, o Gradle não requer a descrição manual de uma sequência de etapas: basta declarar dependências entre tarefas, e o sistema determinará a ordem ideal por conta própria. Essa abordagem torna o Gradle flexível e escalável para projetos de qualquer tamanho.
O sistema usa três fases de execução: inicialização (identificação dos projetos participantes), configuração (construção do grafo de tarefas) e execução (execução das tarefas na ordem necessária). A fase de configuração é uma distinção chave do Gradle: todo o script de compilação é executado antes do início das tarefas, permitindo alterações dinâmicas no grafo com base nas condições. Isso possibilita, por exemplo, adicionar tarefas apenas para variantes de compilação específicas sem duplicar código. O compilador é escrito em Groovy, mas os arquivos de configuração suportam dois idiomas: Groovy DSL e Kotlin DSL.
O plugin Android para Gradle consiste em com.android.application e com.android.library, que adicionam tarefas ao projeto para trabalhar com ferramentas Android. Quando um desenvolvedor inicia uma compilação, o Gradle executa sequencialmente dezenas de tarefas: compilar Kotlin e Java via javac ou kotlinc, processar recursos via AAPT2, gerar R.java, compilar bytecode em DEX via D8 ou R8, assinar e zipar o APK. Cada tarefa verifica se seus dados de entrada mudaram e, se não, usa o resultado em cache. Esse mecanismo é chamado de compilação incremental e acelera a recompilação em 60–80% em comparação com uma reconstrução completa.
A configuração do módulo Android é definida no bloco android do arquivo build.gradle.kts. Dentro do bloco, são definidos compileSdk, minSdk, targetSdk, versão do aplicativo, assinaturas e outros parâmetros. O Gradle cria automaticamente várias variantes de compilação para cada módulo — uma combinação de tipo (release, debug) e sabor. Por exemplo, para um módulo com dois sabores e dois tipos, o Gradle gera quatro tarefas: assembleDemoDebug, assembleDemoRelease, assembleFullDebug, assembleFullRelease. Todas essas tarefas podem ser executadas individualmente ou com um único comando para todas as variantes de uma vez.
Cada projeto Android contém dois níveis de configuração: o build.gradle.kts raiz (configurações para todos os módulos) e o build.gradle.kts do módulo (configurações para um módulo específico). No arquivo raiz, os plugins são declarados sem aplicação, repositórios e variáveis comuns. No arquivo do módulo, os plugins são aplicados ao módulo específico e os parâmetros de compilação são configurados. Essa abordagem permite o gerenciamento centralizado das versões de dependências por meio de um catálogo de versões ou bloco ext.
@Suppress("UnstableApiUsage")
plugins {
id("com.android.application") version "8.2.2"
id("org.jetbrains.kotlin.android") version "1.9.22"
}
android {
namespace = "com.example.myapp"
compileSdk = 34
defaultConfig {
applicationId = "com.example.myapp"
minSdk = 24
targetSdk = 34
versionCode = 1
versionName = "1.0"
}
}O bloco dependencies é outro elemento crítico do build.gradle.kts. Ele lista as bibliotecas, módulos e dependências de arquivo que o aplicativo precisa. O Gradle suporta várias configurações de dependência: implementation (disponível apenas para o módulo atual), api (disponível também para módulos dependentes), testImplementation (apenas para testes), androidTestImplementation (para testes instrumentados) e compileOnly (apenas em tempo de compilação). Cada configuração gerencia a visibilidade das classes no grafo de dependências, o que afeta o tempo de compilação e o tamanho do artefato final.
dependencies {
implementation("androidx.core:core-ktx:1.12.0")
implementation("androidx.lifecycle:lifecycle-runtime-ktx:2.7.0")
implementation("androidx.activity:activity-compose:1.8.2")
testImplementation("junit:junit:4.13.2")
androidTestImplementation("androidx.test.ext:junit:1.1.5")
}Uma build variant é uma combinação de tipo de compilação e sabor de produto que define uma versão do aplicativo com configurações, código e recursos exclusivos. O tipo de compilação define os parâmetros de empacotamento: debug (com depuração e sufixo .debug) ou release (com ofuscação e assinatura). O sabor de produto define variantes funcionais: por exemplo, demo (versão limitada) e full (versão completa com recursos adicionais). O Gradle gera automaticamente tarefas para cada combinação, permitindo compilar todas as versões com um único comando.
android {
buildTypes {
release {
isMinifyEnabled = true
proguardFiles(
getDefaultProguardFile("proguard-android-optimize.txt"),
"proguard-rules.pro"
)
}
debug {
applicationIdSuffix = ".debug"
}
}
flavorDimensions += "version"
productFlavors {
create("demo") {
dimension = "version"
applicationIdSuffix = ".demo"
}
create("full") {
dimension = "version"
applicationIdSuffix = ".full"
}
}
}Cada build variant possui um conjunto de fontes separado. O Gradle usa diretórios src/demo/release, src/full/debug e outros, que armazenam recursos, manifestos e arquivos de origem exclusivos para uma variante específica. O código comum permanece em src/main. Essa abordagem permite reutilizar a lógica principal e substituir apenas as partes diferentes: strings, ícones, endpoints de API ou arquivos de configuração. Um conjunto de fontes pode substituir qualquer recurso do main: manifesto, drawable, values ou até classes Kotlin. Ao compilar uma variante específica, o Gradle mescla arquivos do main e do conjunto de fontes correspondente, com os arquivos da variante tendo prioridade.
O ecossistema de plugins do Gradle cobre todas as etapas do desenvolvimento de aplicativos Android. Os plugins oficiais do Google incluem com.android.application (para o módulo do aplicativo), com.android.library (para o módulo de biblioteca), com.android.test (para módulos de teste) e plugins Kotlin da JetBrains. Os plugins adicionam novas tarefas ao projeto, estendem o DSL com novos blocos de configuração e conectam ferramentas adicionais. Sem o plugin com.android.application, um projeto não pode compilar um APK: este plugin registra todas as tarefas específicas do Android e as vincula no grafo de compilação.
Plugins de terceiros resolvem tarefas mais específicas. Google Services (com.google.gms.google-services) integra Firebase e Google Play Services, inserindo automaticamente google-services.json na compilação. Hilt (dagger.hilt.android.plugin) gera código de injeção de dependência em tempo de compilação. Safe Args (androidx.navigation.safeargs.kotlin) cria classes type-safe para navegação entre fragmentos. Cada plugin é adicionado no build.gradle.kts raiz através do bloco plugins e geralmente requer configuração mínima. O Gradle resolve automaticamente dependências transitivas entre plugins e garante compatibilidade de versões através de arquivos Bom e catálogos de versões.
Uma tarefa é uma unidade atômica de trabalho no Gradle. Cada tarefa tem dados de entrada, dados de saída e uma ação. As tarefas integradas para Android incluem assemble (compilação de todas as variantes), lint (verificação de código), test (execução de testes unitários) e clean (limpeza de arquivos temporários). Os desenvolvedores podem adicionar suas próprias tarefas usando Groovy ou Kotlin DSL. Tarefas personalizadas são úteis para automatizar operações rotineiras: gerar relatórios, copiar artefatos, implantar em dispositivos de teste ou integrar com sistemas CI.
tasks.register("printBuildInfo") {
description = "Exibe informações de compilação"
group = "custom"
doLast {
println("Build variant: ${project.name}")
println("Version: ${android.defaultConfig.versionName}")
}
}Cada tarefa pode depender de outras tarefas através do mecanismo dependsOn. Se a tarefa A depende da tarefa B, o Gradle garante que B será executada antes de A. O sistema não requer especificação manual da ordem para cada par — basta declarar as dependências, e o Gradle construirá um grafo direcionado otimizado para execução paralela de tarefas independentes. As tarefas integradas do plugin Android já estão vinculadas: lint depende da compilação, test depende de assemble, assembleDebug depende de compileDebugKotlin. Os desenvolvedores podem inserir suas próprias tarefas em qualquer nó do grafo usando dependsOn, mustRunAfter ou shouldRunAfter.
Um dos problemas frequentes são conflitos de versão de dependências, quando duas bibliotecas exigem versões diferentes da mesma dependência transitiva. O Gradle relata um erro de conflito, mas nem sempre oferece uma solução automática. Para diagnóstico, use o comando ./gradlew :app:dependencies, que exibe a árvore de dependências completa. Recomenda-se forçar a versão da biblioteca conflitante através do bloco resolutionStrategy. Outro cenário comum é a compilação lenta devido à falta de processamento incremental. Certifique-se de que todos os plugins estejam atualizados, o Gradle Daemon esteja ativado (org.gradle.daemon=true) e memória suficiente seja definida em gradle.properties: org.gradle.jvmargs=-Xmx4096m.
Problemas de cache surgem após a atualização de dependências: o Gradle pode usar um cache desatualizado e a compilação falha. A solução é executar a compilação com a flag --refresh-dependencies ou limpar o cache manualmente via ./gradlew cleanBuildCache. O terceiro erro mais comum é a incompatibilidade de versão entre Android Gradle Plugin (AGP) e Gradle. Cada versão do AGP requer uma versão mínima específica do Gradle. A tabela de compatibilidade é publicada em developer.android.com. Se as versões forem incompatíveis, o Gradle falha na fase de configuração com uma mensagem sobre a versão mínima necessária. Sempre verifique se a versão do wrapper do Gradle atende aos requisitos do AGP.
Perguntas frequentes
Gradle é um programa automatizador para compilar projetos. Ele pega seu código-fonte em Kotlin ou Java, conecta bibliotecas da internet, compila tudo em bytecode e empacota em APK. Funciona na JVM e usa scripts declarativos em vez de instruções manuais. O desenvolvedor só precisa descrever as regras, e o Gradle faz o resto.
Build.gradle é escrito em Groovy — uma linguagem dinâmica com sintaxe flexível e menos rigor. Build.gradle.kts usa Kotlin DSL: tipagem forte, preenchimento automático no Android Studio e verificação de erros em tempo de compilação. O Google recomenda Kotlin DSL para todos os projetos novos. Arquivos Groovy são mais fáceis de migrar, mas arquivos Kotlin são mais confiáveis na manutenção.
Ative o Gradle Daemon (org.gradle.daemon=true) e a compilação paralela (org.gradle.parallel=true). Aumente a memória da JVM para 4–8 GB via org.gradle.jvmargs. Use configuração de projetos sob demanda (org.gradle.configureondemand=true). Para projetos Android, configure o cache de tarefas e compile apenas para a ABI necessária. No Android Studio, execute o Build Analyzer para encontrar gargalos.
Uma build variant é uma combinação de tipo de compilação (por exemplo, debug ou release) e sabor de produto (por exemplo, demo ou full). Cada variante pode ter seu próprio nome de pacote, versão, recursos e arquivos de origem. O Gradle cria automaticamente uma tarefa de compilação separada para cada variante. Isso permite compilar várias versões do aplicativo a partir de um único projeto.
As dependências são adicionadas no bloco dependencies do arquivo build.gradle.kts. O formato é: configuration("group:artifact:version"). Por exemplo, implementation("androidx.core:core-ktx:1.12.0"). Para testes use testImplementation, para testes instrumentados — androidTestImplementation. As versões são convenientemente organizadas em um catálogo de versões separado através do arquivo libs.versions.toml.
Resumo
Vamos desenvolver um aplicativo móvel chave na mão
A IT Sectr cria aplicativos para iOS e Android para startups e empresas desde 2017. Nós vamos aconselhá-lo e propor a melhor solução.
Leia também