La Formation et l'Expertise Android à votre service Comme AirFrance, Orange, Capgemini, Atos WorldLine et bien d'autres. Vous aussi, bénéficiez des meilleures formations Android du moment. |
 |
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:
| Code : | Sélectionner tout |
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'
}
} |
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.
Build4)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):
BuildVariantsIl 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:
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 | signingConfigs{
releaseConfig{
storeFile file("myKeyStore.jks");
storePassword ("toto");
keyAlias "myKeyName";
keyPassWord "toto"
}
} |
| Code : | Sélectionner tout |
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
} |
, 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:
| Code : | Sélectionner tout |
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
}
} |
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:
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 | productFlavors {
blackberry {
packageName "testproject.firstproject.androidstudio.gradle.myblackberryflavor"
}
strawberry {
}
} |
| Code : | Sélectionner tout |
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'
}
} |
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).
[URL="http://blog.developpez.com/android2ee-mathias-seguy/files/2015/01/test-la-structure.png"]...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.