Desde que o Android Studio tornou-se a ferramenta oficial do Google para desenvolvimento Android, o Gradle veio como principal aliado para ajudar no gerenciamento do projeto e controle de dependências.
Para entender como funciona o Gradle, antes precisamos entender um pouco sobre como funciona o processo de build de um aplicativo Android.
Processo de Build de Aplicativos Android
O processo de compilação de um aplicativo Android envolve muitas ferramentas e etapas mas que não percebemos o que está acontecendo por baixo dos panos no caminho para a produção de um .apk (extensão de aplicativo Android).
Quando utilizamos o Android Studio, o processo de build completo é feito a cada vez que você executa o Gradle para construir seus projetos ou módulos. Podemos customizar algumas etapas do processo de build, no entanto, precisamos entender o que está acontecendo por baixo dos panos para conseguir customizar o processo.
O processo de build mescla todos os recursos da plataforma que estão sendo usados, tipos de build (teste ou produção) e as dependências que podem ser frameworks ou bibliotecas proprietárias.
Etapa 01
A primeira etapa começa com o Android Asset Packaging Tool (aapt), procurando por arquivos de recursos como o AndroidManifest, os layouts XML das suas Activities e etc.
Basicamente tudo que está dentro da pasta res juntamente com a pasta asset são compilados. Após essa primeira etapa um arquivo chamado R.java é gerado fazendo referencia a todos os arquivos de recursos.
Etapa 02
Nessa segunda etapa todos as interfaces .aidl são convertidas para interfaces Java.
Mas, o que são interfaces .aidl?
AIDL (Android Interface Definition Language) é uma linguagem usada para gerar código que permite que dois processos em um dispositivo Android possam conversar entre si usando a comunicação entre processos (IPC). Se você tem um código rodando em um processo (por exemplo, em uma Activity) que precisa chamar métodos de um objeto em outro processo (por exemplo, um Service), você usaria a AIDL para fazer essa comunicação.
Etapa 03
Todo seu código é compilado usando o compilador do Java e é gerado os .class. O .class é o resultado final quando compilamos códigos Java, ou seja, seria o “executavél”.
Etapa 04
Essa etapa é o momento onde todo seu código Java compilado, os .class, são convertidos pelo processo de compilação para os Bytecodes da Dalvik, a Virtual Machine do Android. Esses Bytecodes são chamados de arquivos DEX e quaisquer bibliotecas e arquivos .class que você tenha incluído em sua compilação, também serão convertidos para que eles possam ser empacotados no arquivo .apk final.
Etapa 05
Todos os arquivos de recursos não compilados (como imagens e outros arquivos), recursos compilados e os arquivos DEX são enviados para a ferramenta apkbuilder para serem empacotados em um arquivo .apk.
Etapa 06
Última mas não menos importante etapa, é nesse momento que o .apk é construído, ele deve ser assinado tanto com uma chave de Debug ou Release antes que possa ser instalado em um dispositivo.
Finalmente, se o aplicativo está sendo assinado no modo de Release, você deve “alinhar” o .apk com a ferramenta Zipalign. “Alinhar” o .apk otimiza e diminui o uso de memória quando o aplicativo é executado em um dispositivo.
O que é o Gradle?
Agora que já vimos como funciona as etapas de build de um projeto Android, vamos entender como usar o Gradle juntamente com o Android Studio para automatizar todo esse processo e facilitar nosso desenvolvimento no dia a dia.
Gradle é um sistema de automatização de builds, assim como o Ant e Maven.
Todo projeto criado no Android Studio já vem por padrão estruturado para usar o Gradle, sendo assim, temos um arquivo de configuração para o projeto principal e um para cada modulo.
Os arquivos de configuração são chamados de build.gradle, e eles são arquivos de texto simples que usam a sintaxe da linguagem Groovy para configurar a compilação com os elementos fornecidos pelo plugin do Gradle para Android. Na maioria dos casos, você só precisa editar os arquivos de configuração de cada modulo.
Arquivo build.gradle do Projeto
Por padrão, o arquivo Gradle do projeto principal usa um buildscript para definir os repositórios e dependências do Gradle, isso permite que diferentes projetos use diferentes versões do Gradle. Os repositórios suportados incluem o JCenter, Maven Central, ou Ivy.
Este exemplo abaixo configura o repositório JCenter e uma dependência que contém o plugin do Gradle versão 1.0.1 para Android.
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:1.0.1'
}
}
allprojects {
repositories {
jcenter()
}
}
Vamos entender para que serve cada linha do arquivo.
- buildscript: Configura o plugin do Gradle para Android.
- repositories: Repositórios usados para buscar as dependências.
- dependencies: Dependências do plugin do Gradle.
- allprojects: Configurações que ficam disponíveis para todos os módulos do projeto.
Arquivo build.gradle do Módulo
O arquivo build.gradle do modulo do projeto permite que você defina as configurações de compilação especificas daquele módulo, inclusive substituindo as configurações do arquivo de manifesto definindo opções de compilação personalizadas.
apply plugin: 'com.android.application'
android {
compileSdkVersion 19
buildToolsVersion "19.0.0"
defaultConfig {
minSdkVersion 8
targetSdkVersion 19
versionCode 1
versionName "1.0"
}
buildTypes {
release {
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
dependencies {
compile project(":lib")
compile 'com.android.support:appcompat-v7:19.0.1'
compile fileTree(dir: 'libs', include: ['*.jar'])
}
Vamos entender para que serve cada linha do arquivo.
- apply plugin: ‘com.android.application’: Indica para usar o plugin do Gradle para Android. Isso adiciona as tarefas de compilação especificas para Android e configura os elementos que estão dentro de android {…}.
- android {…}: Configura as especificações de compilação do Android.
- compileSdkVersion: Versão da plataforma que será compilado o aplicativo.
- buildToolsVersion: Versão das ferramentas de compilação da plataforma.
- defaultConfig: Configurações principais e valores que vão ser adicionados dinamicamente no AndroidManifest.xml. Os valores dessa seção sempre sobreescrevem os valores do arquivo de manifesto.
- buildTypes: Controla como a compilação do seu aplicativo será feita. Por padrão, o processo de compilação entende dois tipos: debug e release.
- dependencies: Configura as dependências e bibliotecas do modulo.
Dependências
O sistema de build do Android Studio gerencia as dependências do projeto, do módulo, dependências locais e dependências externas.
...
dependencies {
// Dependencia de modulo
compile project(":lib")
// Dependencia externa
compile 'com.android.support:appcompat-v7:19.0.1'
// Dependencia local
compile fileTree(dir: 'libs', include: ['*.jar'])
}
Dependências de módulo
Um módulo do projeto pode depender de outros módulos, incluindo no seu arquivo de build uma lista de outros módulos que ele depende. Quando você fizer o build deste módulo, o sistema de build reúne e inclui os módulos necessários.
Dependências locais
Se você tiver bibliotecas em seu projeto local que um módulo depende, tais como arquivos JAR, você pode declarar essas dependências no arquivo de configuração para esse módulo.
Dependências externas
Quando algumas de suas dependências estão disponíveis em um repositório externo, você não tem que baixá-las e copiá-las para o seu projeto. O sistema de build do Android Studio suporta dependências externas a partir de repositórios, como Maven e Ivy.
Muitas bibliotecas de software mais populares e ferramentas estão disponíveis em repositórios públicos do Maven. Para essas dependências você só tem que especificar o nome do pacote que está no repositório Maven. O formato de configuração no Maven é o grupo:Nome:versão. Por exemplo, no Maven temos a versão 16.0.1 da biblioteca Google Guavam então: com.google.guava: goiaba: 16.0.1.
O Maven Central Repository é amplamente usado para distribuir muitas bibliotecas e frameworks.
Identificando o aplicativo
No sistema de build do Android, o atributo ApplicationID é usado para identificar exclusivamente os pacotes dos aplicativos no momento da publicação na Google Play. A identificação do aplicativo é definido na seção android do arquivo build.gradle.
apply plugin: 'com.android.application'
android {
compileSdkVersion 19
buildToolsVersion "19.1"
defaultConfig {
applicationId "br.com.androidpro.appgradleteste"
minSdkVersion 15
targetSdkVersion 19
versionCode 1
versionName "1.0"
}
...
Definindo diferentes versões de produtos
O sistema de build permite identificar exclusivamente pacotes diferentes para cada versões de produtos (demo ou full) e tipos de build. O ID do aplicativo no tipo de build é adicionado como um sufixo na versão do produto.
productFlavors {
demo {
applicationId = "br.com.androidpro.appgradleteste.demo"
}
full {
applicationId = "br.com.androidpro.appgradleteste.full"
}
}
buildTypes {
debug {
applicationIdSuffix ".debug"
}
}
....
Para definir dois produtos, edite o arquivo de configuração do módulo do aplicativo para adicionar a seguinte configuração:
...
android {
...
defaultConfig { ... }
signingConfigs { ... }
buildTypes { ... }
productFlavors {
demo {
applicationId "br.com.androidpro.appgradleteste.demo"
versionName "1.0-demo"
}
full {
applicationId "br.com.androidpro.appgradleteste.full"
versionName "1.0-full"
}
}
}
...
As definições de versão do produto pode usar as mesmas propriedades do elemento DefaultConfig. A configuração base para todos as versões é especificado em DefaultConfig, e cada versão substitui quaisquer valores padrão.
O arquivo de build acima usa a propriedade ApplicationID para atribuir um nome de pacote diferente para cada versão: uma vez que cada definição cria um aplicativo diferente, cada um deles precisa de um nome de pacote diferente.
Adicionando a nova versão
Agora você precisa criar as pastas e adicionar uma MainActivity para cada versão. Para criar a estrutura de diretório para a versão demo:
- No painel de projeto, expanda AppGradleTeste, em seguida, expanda o diretório app.
- Clique com o botão direito do mouse no diretório src e selecione New > Directory.
- Digite “demo”, como o nome do novo diretório e clique em OK.
- Da mesma forma, crie os seguintes diretórios:
- app/src/demo/java
- app/src/demo/res
- app/src/demo/res/layout
- app/src/demonstração/res/valores
Tipos de Build
Tipos de build representam as versões de compilação gerados para cada pacote da aplicação. Por padrão, são fornecidos os tipos de debug e release de build.
...
android {
...
defaultConfig { ... }
signingConfigs { ... }
buildTypes { ... }
productFlavors {...}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
debug {
debuggable true
}
}
}
...
Seguindo nosso exemplo, as versões de produtos e build ficariam assim:
- demoDebug
- demoRelease
- fullDebug
- fullRelease
Para trabalhar com as versões acima, clique em Build Variant do lado esquerdo da janela do Android Studio e selecione a versão que você deseja modificar no painel, como mostrado na figura abaixo.
Esse foi um mini tutorial sobre Gradle para Android. Essa ferramenta faz parte do dia a dia do desenvolvedor Android, então é importante conhecer bem ela para facilitar o desenvolvimento de aplicativos.
Nesse Treinamento Completo, trato desse e de outros recursos e passos imprescindíveis na hora de se desenvolver aplicativos Android profissionais, além de ele ser baseado no Método COMPROVADO dos 4 Elementos do Desenvolvimento Android.
Código fonte do aplicativo exemplo: https://github.com/AndroidProBlog/appgradletest
Deixe suas dúvidas e sugestões nos comentários aqui em baixo 😉