Gradle, build variants, flavors et applicationId

Gradle, build variants, flavors et applicationId

Dans le cadre d’un développement Android, vous êtes parfois amené à devoir publier
deux versions différentes de la même application.

Vous voulez donc publier deux .apk différents mais qui utilisent le même code source.
Cela peut être une version payante qui vient s’ajouter à une version free,
ou une version bleue qui vient s’ajouter à une version verte.

Imaginez que vous ayez développé une superbe application pour les automobiles VW. Elle est tellement réussie que le patron de Skoda (appartenant au même groupe que VW) veuille exactement la même chose mais “brandée skoda”.
Ca tombe bien, tout le backend est centralisé, et il est alors seulement nécessaire d’envoyer un cookie “skoda” pour différencier de quelle application vient les appels.

C’est dans ce cas de figure que les flavors, permises par le fichier gradle au niveau du module, sont utiles.

Il suffit de spécifier un nouveau “productFlavor” qui contiendra son attribut applicationId.

Gradle:

productFlavors {
  skoda {
    applicationId = "com.skoda"
  }
}

 

Il est important de noter que le package utilisé par les deux flavors restent identiques.  Seul l’attribut “applicationId” définit dans le fichier Gradle diffère et détermine la différentiation faite sur le store.

Chaque dossier “java” sera actif et considéré comme source java (colorisé en bleu dans Android Studio) lorsque le buildVariant sélectionne soit “skodaDebug” ou “skodaRelease”

 

Au delà du fait qu’on puisse changer d’application id, on peut aussi utiliser le paramètre “applicationIdSuffix” qui permet par exemple de différencier les environnements de développement, exemple :

productFlavors {
 sandbox {
 applicationIdSuffix ".sandbox"
 ...
 }
 production {
 applicationIdSuffix ".production"
 ...
 }
}

Ainsi en “sandbox”, l’app id sera com.example.sandbox et en “production” com.example.production

On peut, de la même manière, différencier les API à utiliser (toujours dans les blocs “sandbox” et “production”) :

productFlavors {
 sandbox {
 ...
 buildConfigField("String", "MY_API", "\"http://sandbox.api.example.com\"")
 buildConfigField("String", "MY_API_KEY", "\"abc123\"")
 ...
 }
 production {
 ...
 buildConfigField("String", "MY_API", "\"http://prod.api.example.com\"")
 buildConfigField("String", "MY_API_KEY", "\"xyz789\"")
 ...
 }
}

Vous pouvez dès lors accéder à cette variable via :

BuildConfig.MY_API_KEY

Dans le même ordre d’idée, vous pouvez tester l’environnement ou le type de build dans lequel vous vous trouvez en vérifiant BuildConfig.BUILD_TYPE ou BuildConfig.FLAVOR:

if(BuildConfig.BUILD_TYPE.equals(“release”){
//…
}

gradle

 

Structure des fichiers

Exemple de structure des fichiers:

gradle3

AndroidManifest.xml

Veillez à ne dupliquer le manifest que pour les tags et les attributs qui sont spécifiques à la nouvelle flavor.

Code Java

Lorsque vous changez de buildVariant, vous n’êtes pas sans savoir que la classe auto-générée BuildConfig.java est réécrite par le système.  Elle contiendra une propriété de type String FLAVOR = “skoda” lorsque le buildVariant sélectionné est “skodaDebug” ou “skodaRelease”.

Cela vous permet de faire ceci dans votre code source, sans duplication de classe:

String cookieValue;
if(BuildConfig.FLAVOR.startsWith("skoda")){
 cookieValue = COOKIE_VALUE_SKODA;
}else{
 cookieValue = COOKIE_VALUE_VW;
}

 

 

Maintenant, si votre code diffère d’une flavor à l’autre, ou que vous ne voulez pas faire de check sur cette propriété de BuildConfig, vous avez toujours la possibilité d’écrire des classes propre à une flavor.  Attention toutefois que vous ne pouvez pas avoir une classe A.java dans main et une classe A.java dans le main de la flavor skoda par exemple, car cela serait le même objet et le compilateur ne saurait pas quel objet utiliser.

 

Plus d’infos sur le sujet:

http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Build-Variants
http://tulipemoutarde.be/2013/10/06/gradle-build-variants-for-your-android-project.html
http://stackoverflow.com/questions/16737006/using-build-flavors-structuring-source-folders-and-build-gradle-correctly/16746755#16746755
http://blog.brainattica.com/how-to-work-with-flavours-on-android/

Leave a Reply

Your email address will not be published. Required fields are marked *