Gradle outil préconisé par Google pour construire les applications Android

Une des nouveautés annoncée à la Google I/O 2013 concernait la mise à disposition d’un nouveau système de build. Il était nécessaire de disposer d’un système commun facilitant la gestion de toutes les étapes de construction d’un projet. Plusieurs initiatives existaient à base de Maven, Ant... mais au final Google a décidé de s’appuyer sur Gradle.

Le choix de Gradle
Gradle a été choisi pour plusieurs raisons

• il est plus souple dans son utilisation que Maven, qui impose une convention de développement plutôt adaptée au développement d’applications Java.
• il propose une gestion automatique des dépendances basée sur celle de Maven et/ou celle de Ivy tout en permettant de désactiver la résolution transitive.
• Un autre intérêt est d’avoir des fichiers de configuration en Groovy. La configuration se résume soit en des éléments déclaratifs se basant sur le DSL Gradle soit en des éléments de code Groovy
• son intégration commence à être correcte dans les IDE et notamment dans IntelliJ et AndroidStudio

Tout comme Maven, Gradle propose un processus basé sur des conventions. Si vous suivez le processus standard de construction vous n’avez pratiquement rien à paramétrer. Mais tout reste surchargeable pour que vous puissiez adapter vos spécificités.

Mais quelle est donc la convention liée à un projet Android ?

Structuration d’un projet
Des répertoires pour le projet mais aussi pour les tests.


Noter que contrairement à un projet java le répertoire de test se nomme instrumentTest et non pas test. Pour un projet Android la tâche test a été remplacée par instrumentTest car le process est différent, ce sont des tests d’IHM, des tests d’intégration. Le package doit être construit déployé sur un device (virtuel ou non) avant que les tests soient lancés, et l'instrumentation permet à vos tests de jouer sur le cycle de vie de vos composants pour faciliter leur test.

Cycle de vie du projet et tâches
Toute application passe par différentes étapes avant de pouvoir être utilisée par les utilisateurs. On doit récupérer les sources, vérifier, tester, créer un package pour debugger, retester, déployer, signer, releaser... Toutes ces différentes étapes constituent le cycle de vie de votre application. Ce terme vient de Maven mais
il s’applique aussi à des constructions gérées via Ant ou Gradle

Le principe de Gradle (ou de Ant) est de déclarer des tâches qui dépendent les unes des autres. Lorsque vous lancez une tâche toutes les sous tâches sont d’abord lancées

Pour avoir une idée de toutes les tâches que vous pouvez lancer vous pouvez lancer la commande

gradlew tasks --all

Lorsque vous générez un artifact lié à un projet Android vous produisez soit un APK pour le debug soit un APK pour une livraison sur le store. Vous retrouvez deux tâches différentes dans le cycle de vie pour gérer ces problématiques. La tâche par défaut générera les deux

assemble
      assembleDebug
      assemblRelease

Configurer le projet pour utiliser le plugin Gradle Android
Toute la configuration s’effectue dans le fichier build.gradle disponible à la racine de votre projet. Si vous êtes novice en Gradle je vous conseille fortement de générer un squelette de projet à l’aide d’Android Studio. Cela vous évitera d’installer Gradle manuellement. Le générateur met à disposition un wrapper Gradle, une configuration par défaut et un script gradlew permettant de l’exécuter.

Certaines choses ne peuvent pas être devinées comme le fait que

• Gradle est en train de construire une application Android
• la version de l’API est la X.0 et que la version minimale est la 2.2
• ....

Prenons le fichier de base build.gradle

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:0.4'
    }
}

apply plugin: 'android'

repositories {
    mavenCentral()
}

dependencies {
    compile files('libs/android-support-v4.jar')
    compile  'com.google.guava:guava:14.0.1'
}

android {
    compileSdkVersion 17
    buildToolsVersion "17.0.0"

    defaultConfig {
        minSdkVersion 11
        targetSdkVersion 16
    }
}

Dans ce script on retrouve la configuration minimale pour pouvoir gérer un projet Android. Après pour
chacune de vos spécificités vous devrez enrichir ce fichier.

Ajouter une dépendance à votre projet
Si votre projet utilise une librairie externe comme Guava vous pouvez la paramétrer dans la zone propre
aux dépendances. Pour le moment la configuration donnée précédemment contient déjà une déclaration de dépendance vers la librairie de rétrocompatibilité ('libs/android-support-v4.jar).

dependencies {
    compile files('libs/android-support-v4.jar')
    compile 'com.google.guava:guava:14.0.1'
}

Si vous souhaitez utiliser des dépendances que pour les tests vous pouvez remplacer le mot clef compile par instrumentTestCompile. Il existe différents scope (compile, instrumentTestCompile, debugCompile, releaseCompile)

Par exemple

instrumentTestCompile 'com.squareup:fest-android:1.0.5'

Plus haut je disais que un des avantages de Gradle est de pouvoir gérer les dépendances en mode transitif ou non. La résolution transitive est la fonctionnalité qui a fait la force et qui est aussi une faiblesse de Maven.

Quand vous déclarez une dépendance dans votre projet et que cette dernière possède elle même des dépendances déclarées dans son fichier de configuration, vous n'avez pas besoin de déclarer toute la hiérarchie des dépendances. Le mode transitif permet de les récupérer toutes automatiquement. Par contre parfois quand le fichier de configuration est mal défini le mode transitif va entraîner la récupération de x librairies qui ne sont pas toujours utiles à votre projet. Chose qui peut être problématique pour une application mobile qui a besoin d'être la moins volumineuse possible.

dependencies {
    compile files('libs/android-support-v4.jar')
    compile ('com.google.guava:guava:14.0.1'){

      transitive true

    }

}

Mais encore...
Je n’aborde pas deux fonctionnalités intéressantes dans cet article qui sont l’exécution des tests et la construction de multiples livrables. J’aborderai certainement ces problématiques ultérieurement. Pour en savoir plus vous pouvez suivre le wiki officiel.

La vidéo de présentation au Google I/O est aussi intéressante