par , 29/01/2015 à 10h36 (2980 Affichages)
Bonjour,
Ben ça y est, vous avez migré sous AndroidStudio grace à mon précédent billet Migration AndroidStudio, maintenant passons aux choses sérieuses et avançons dans notre compréhension du système de build basé sur Gradle. En particulier je souhaite vous parler du mode release et debug, des flavors et de la mise en place du projet de tests. Je ferrai un détour aussi sur les deux bugs qui m'ont pourri la vie pendant quelques quart d'heures que vous gagniez du temps :)
Une première chose importante à comprendre, la notion de module. Dans un projet AndroidStudio, vous pouvez avoir plusieurs modules, chaque module est une application. Le plus souvent vous avez deux modules par projet, l'application principale et son application de tests mais vous pourriez avoir plusieurs projets indépendants (ce qui est je crois une mauvaise pratique).
Je vous conseille dans AndroidStudio d'utiliser la vue projet plutôt que la vue Android pour votre projet, vous comprendrez mieux comment est structuré votre application dans l'I.D.E.:
1)Première chose :votre Android SDK
Pour pouvoir vraiment utiliser les librairies native android (android-support, googleplayservice,...), il faut que votre android sdk soit à jour et en particulier le repository. Pour cela, ouvrez votre SDK Manager et assurez vous que les deux repository android et google sont installés :
SDK Manager à jour.
Cela permet a gradle de récupérer les dîtes librairies pour construire vos projets.
2)Deuxième chose: Le bug du Error:(1, 0) Plugin with id 'com.android.application' not found.
Vous avez créé votre projet ou l'avez importé et AndroidStudio vous dit que gradle ne peut synchroniser le projet avec cette erreur improbable "Error:(1, 0) Plugin with id 'com.android.application' not found". Pourquoi improbable ? Parce que vous utilisez la dernière version d'AndroidStudio et que votre plugin gradle possède une version supérieure à 2. Pour vérifier votre version de gradle, il vous suffit d'ouvrir le fichier gradle-wrapper.properties et de vérifier la ligne: distributionUrl=https\://services.gradle.org/distributions/gradle-2.2.1-all.zip. Vous pouvez aussi aller dans votre répertoire d'installation de gradle (sous ~User\.gradle\wrapper\dists et vérifier la présence du dossier gradle-2.2.1-all). Donc normalement, vous êtes à jour et le plugin com.android.application n'a aucune raison de ne pas être trouvé par AndroidStudio pour construire votre projet.
En fait, il vous suffit d'ouvrir le fichier build.gradle de votre projet (il y en a deux, celui du projet et celui du projet... ahah. Le premier est global au projet, le second est destiné à votre application et est donc associé à son module). Donc il vous suffit d'ouvrir le fichier du projet (<em]build.gradle (Project:MonProjet)</em]) et de le mettre à jour avec les lignes suivantes:
1
2
3
4
5
6
7
8
9
10
11
|
// Top-level build file where you can add configuration options common to all sub-projects/modules.
buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath 'com.android.tools.build:gradle:1.0.0'
}
} |
Votre projet devient moins con et se construit alors lui-même maintenant qu'il sait où se trouve son plugin android.
3)Lancer un build
Oui, c'est tout bête comme question mais pas évident quand on débarque d'Eclipse. En fait rien de plus simple, vous faîtes un click droit sur votre fichier gradle.build et sélectionnez run ou vous appuyer sur le bouton SyncProject with GradleFile.
Build
4)Le mode release ou le mode debug
Une bonne nouvelle, nous pouvons, sans aucune difficulté construire notre application en mode debug et en mode release. Le mode debug a sa variable debuggable à true, là où le mode release l'a à false. Rien que pour cela ça vaut le coup. Il y a bien sûr d'autres différences, par exemple la clef utilisée pour signer votre projet avant de le déployer.
Si l'on sélectionne l'un ou l'autre de ces modes, il sera automatiquement utilisé lors du build du projet. Trop bon, non ?
Pour sélectionnez votre variante de build, ouvrez le panneau BuildVariants (le bouton en bas à gauche):
BuildVariants
Il ouvre alors, le panneau vous permettant de choisir votre variante de build pour les différents modules de votre projet. Vous sélectionnez le mode release ou debug en clickant sur release ou debug (ouvre un spinner).
Vous êtes trop content de savoir ça et du coup, vous sélectionnez la variante release et lancez le build, et paf, ça plante avec une exception obscure sur votre clef de signature (<em]"Apk non signé, le mode release ne peut être effectué"</em]).
En fait, c'est cohérent, comment AndroidStudio pourrait-il savoir où se trouve la clef à utiliser pour signer votre application, le mot de passe du keystore qui la contient et le mot de passe de la clef ? Il n'est pas omniscient (ça rassure). Il faut donc lui fournir ces informations. Pour faire ça, dans le menu Build d'AndroidStudio, on va sur Generate SignedApk, on choisit son module, puis le keystore (soit on en créé un soit on pointe vers un existant) et voilà, c'est fini. Pour plus d'information sur cette notion de clef, vous pouvez lire (ou relire) cet article :Signer et déployer son application.
Pour aller plus loin (vers l'infini et au-delà:), vous pouvez rajouter ce keystore (le fichier *.jks) à votre projet. Il y a plein de cas où cela est utile (travail en équipe, projet open source, persistence du keystore, tout ça). Pour cela, rien de plus simple, vous copiez collez le fichier jks dans votre projet et vous expliquez a gradle qu'il faut l'utiliser pour signer votre application.
Ensuite, dans le build.gradle du module, on rajoute un bloc de configuration pour la signature:
1
2
3
4
5
6
7
8
| signingConfigs{
releaseConfig{
storeFile file("myKeyStore.jks");
storePassword ("toto");
keyAlias "myKeyName";
keyPassWord "toto"
}
} |
Ensuite, il suffit d'expliquer, dans le bloc des buildTypes, que la variante release utilise cette configuration pour signer l'apk:
1
2
3
4
5
6
7
8
|
buildTypes {
release {
debuggable false
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.releaseConfig
} |
Pour aller encore plus loin ("Il y a bien longtemps, dans une galaxie lointaine, très lointaine...":), vous pouvez customiser votre variante de build debug aussi, par exemple:
- rajouter le debuggable à true,
- suffixer le package root de votre application en mode debug avec debug, pour pouvoir déployer le mode debug et le mode release sur un même device sans avoir à désintaller/réinstaller)
- activer ou désactiver proguard
Pour cela rien de plus simple, on rajoute le bloc suivant dans les buildtypes, juste sous celui de release:
1
2
3
4
5
6
7
8
| debug {
debuggable true
packageNameSuffix ".debug"
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.releaseConfig
}
} |
5)Flavor
Le système des saveurs avec gradle, yes, yes et yes !
Bon, c'est quoi les saveurs ? C'est la capacité avec un même module de construire plusieurs apk qui ont du code différent. En d'autres termes, avec un même projet on est capable en un build de le construire en mode premium, payant ou gratuit. Un autre scénario est de le construire en mode amd ou intel. On pourrait aussi, le construire en mode tablette, phablette ou téléphone (mauvaise idée en fait à part pour l'optimisation de la taille de l'apk pour les images). On pourrait aussi se faire plaisir avec un mode post ou pre Honeycomb. Bref, cela nous permet de faire des branches de code indépendantes les unes des autres, séparées dans le code et qui construisent plusieurs apk.
L'idée est que votre code principal se trouve dans le dossier src/main et toutes les classes et les ressources qui changent de comportement en fonction de la saveur seront surchargées dans une branche src/maSaveur. Le système de build ferra le merge lui-même (que ce soit pour les classes, les fichiers de ressources et même les fichiers xml, typiquement vos chaînes de caractères).
Pour cela, la première chose à faire est de rajouter dans votre gradle.build un bloc productFlavor et de décrire les saveurs que vous souhaitez mettre en place sur votre projet. En vis-à-vis de ces saveurs, vous mettez en place dans votre projet la structure correspondante:
Il ne vous reste plus qu'à surcharger les classes ou les ressources qui changent en fonction de la saveur.
Quand vous avez fait cela, il vous suffit de revenir dans le panneau BuildVariant et de sélectionner le build souhaité. Vous avez le mode release et debug pour chacune de vos saveurs. ce qui donne release/debug/maSaveurRelease/maSaveurDebug.
Pour pouvoir déployer tous ces apk sur le même appareil, vous pouvez pour chacune de ces saveur, changer le package root, par exepmle:
1
2
3
4
5
6
7
8
| productFlavors {
blackberry {
packageName "testproject.firstproject.androidstudio.gradle.myblackberryflavor"
}
strawberry {
}
} |
6)Le fichier gradle.build obtenu
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
| apply plugin: 'com.android.application'
android {
compileSdkVersion 21
buildToolsVersion "21.1.2"
defaultConfig {
applicationId "testproject.firstproject.androidstudio.gradle.formation.android2ee.com.mytestproject"
minSdkVersion 8
targetSdkVersion 21
versionCode 1
versionName "1.0"
}
// signingConfigs{
// releaseConfig{
// storeFile file("myKeyStore.jks");
// storePassword ("toto");
// keyAlias "myKeyName";
// keyPassWord "toto"
// }
// }
buildTypes {
release {
debuggable false
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
// signingConfig signingConfigs.releaseConfig
}
debug {
debuggable true
applicationIdSuffix ".debug"
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
// signingConfig signingConfigs.releaseConfig
}
}
productFlavors {
blackberry {
packageName "testproject.firstproject.androidstudio.gradle.formation.android2ee.com.myblackberryflavor"
}
strawberry {
}
}
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile 'com.android.support:appcompat-v7:21.0.3'
}
} |
7)Les tests
Soit vous démarrez un nouveau projet et là il n'y a rien à faire, le wizard de création de projet le fait pour vous.
Sinon, ben il faut le faire :
Pour cela, sous MyApp\src vous créez votre structure de test; new Folder "MyTest" ou "androidTest", puis un folder java et enfin le package de vos tests qui est soit le même que celui de votre application, soit un autre (comme vous souhaitez, vous êtes libres).
Projet de tests
Si c'est le même package, il n'y a rien à faire, si c'est un autre package que celui de votre application, il faut modifier le fichier gradle.build et ajouter dans votre bloc de defaultConfig la balise testApplicationId
1
2
3
4
5
6
7
8
| defaultConfig {
applicationId "com.android2ee.formation.gradle.androidstudio.firstproject"
minSdkVersion 8
targetSdkVersion 21
versionCode 1
versionName "1.0"
testApplicationId "com.android2ee.formation.gradle.androidstudio.firstproject.test"
} |
Ensuite vous écrivez vos tests. Le mieux là, c'est que vous lisiez les articles d'android2ee consacrés à la mise en place des tests : Les tests sous Android.
Pour lancer vos tests, click droit sur le nom de votre application "MonApp" et runAllTests.
Et normalement, les tests se passent et vous obtenez le rapport dans l'onglet run en bas à gauche
Moi, j'ai eu un bug où l'activité n'était pas trouvée (ClassNotFoundException) car j'avais surchargée la balise TestApplicationId en y mettant le même path que celui de mon projet, donc il installait le projet puis le désinstallait pour y mettre celui de tests (ils avaient le même package) et du coup la classe à tester n'était plus là. Par contre si on omet cette balise, le système rajoute un .test au nom de package du projet de test et donc il n'y a plus de conflit.
8)Rajouter une dépendence (un jar)
Tout d'abord, cela ne s'applique pas aux librairies natives google (googleservices) et android (support-librairie) mais seulement aux librairies externes.
Pour cela, la marche à suivre est simple :
- Déposez votre jar dans le dossier libs de votre module
- Click droit sur le dossier et choisissez "Add as librairy"
- Vérifier que votre build.gradle contient la ligne compile files('libs/maLib.jar')
- Faîtes un clean build (dans le menu Build, choisir "clean project" ou via la console gradle, faîtes gradlew clean)
Et voilà, vous avez rajouter votre librairie à votre projet.
9) Faire une librairie
Vous souhaitez que votre projet soit une librarie, rajouter une module de type librairie et cela suffit.
Pour ceal, "new Module", choisir librairie.
Conclusion
Bon ben voilà, vous avez atteint le niveau 1 de la migration vers AndroidStudio et de l'utilisation de Gradle.
Pour information, je fais des formations Android, c'est mon métier et je ne fais que ça, alors n'hésitez pas à montée en compétence avec moi, c'est le moment et je vous donnerai tout un tas de conseils d'experts qu'aucune autre formation ne peut vous fournir. Devenez un excellent développeur Android, qu'attendez-vous : Calendrier
Bonne journée à vous et au plaisir de vous rencontrez.
Mathias Séguy
mathias.seguy@android2ee.com
Fondateur Android2EE
Formation - Expertise - Consulting Android.
Ebooks pour apprendre la programmation sous Android.
Retrouvez moi sur Google+
Suivez moi sur Twitter
Rejoignez mon réseau LinkedIn
Consulter le profil
Marquer ce blog comme lu
