Cet article fait partie d’une série de 4.

L’objectif est de décrire comment faire pour optimiser un maximum le déploiement d’une application Android en automatisant les étapes 🤖.

  1. 📦 Builder et signer son application Android
  2. 🚀 Automatiser les builds avec Fastlane
  3. 🔥 Déployer son application sur Firebase
  4. 🛳 Déployer son application sur le Play Store
  5. 🤖 Utiliser Gitlab pour déployer son application lors d’un tag de release sur git.

Dans la première partie de cette série, nous allons voir comment “automatiser” la génération et la signature de l’application Android (app bundle ou apk 📦).

Vous pouvez retrouver une grande partie de ce que je vais dire sur internet, notemment sur le site Dev Android ici et là.
L'idée est de voir cet article comme une introduction pour les articles suivants

🍑 La recette du bonheur

On n’est pas bien là ? Avec notre bel arbre git et notre framework tout frais d’il y a 3j !

On a un process aux petits oignons, on récupère un ticket, on le développe, on fait la PR, on merge et hop…

Et une fois tous les 6 mois, un des dev va prendre une demi-journée pour faire une release et l’envoyer au PO/Client !

Oép bon… En même temps on doit

Relou, et comme tout bon dev qui se respecte, une question se pose.

Comment pouvons nous faire pour automatiser tout ça ?

Pour commencer, faire le build d’une application Android, ce n’est pas si compliqué. Cela peut être long et fastidieux, mais pas compliqué.

(Sauf pour toi, qui a 5 flavors et 3 dimensions. Toi tu dois en chier)

De la même manière qu’une recette de cuisine, on a besoin d’ingrédients et d’étapes.

Les ingrédients sont:

Quant aux étapes, elles se résument à

chef préparant une recette

Vu les ingrédients de qualité dont on dispose, on va faire une application aux petits oignons (MDR trop bonne blague, oignons, recette, haha).

🧰 Créer une clé de signature

Quand on lance un build sur Android, cela génère une application 📦 (apk ou appbundle)

Cette application pour être installé (ou même déployé) doit être signée avec une clé 🔑.

🔑 A quoi sert une clé de signature

Voyez ça comme un tampon que met le développeur pour certifier que c’est bien lui qui a généré l’application et pas une tierce personne malveillante. 😈

Sans cela, impossible d’installer l’application sur le téléphone.

Au passage, Android utilise une clé dite “de debug” 🗝 pour signer les applications en mode développement. (jettez un oeil 👀 dans ~/.android/debug.keystore)

Conclusion, nous avons besoin d’une clé spécifique 🔑 pour les releases de notre application.

⚒️ Générer une clé

Pour créer une clé de signature, deux méthodes existent.

🤖 Via Android Studio

La plus simple aujourd’hui est de le faire via Android Studio.

Vous trouverez cette procédure sur le site dev Android.

Remplacez juste le key store path par la racine de votre projet suivi de keystore (exemple : ~/path/to/myproject/keystore oui sans le .jks)

🖥 En LDC

Si vous n’avez pas Android Studio ou que vous ne voulez pas, l’autre moyen est d’utiliser les lignes de commande 💻 .

Cela se fait avec l’outil keytool.

Placez-vous à la racine de votre projet et utilisez la commande suivante:

keytool -genkey -v -keystore keystore -alias *ALIAS* -keyalg RSA -keysize 2048 -validity 10000

Je vous laisse vous renseigner sur la signification des différentes options de keytool.

La commande va vous demander plein d’informations dont 2 mots de passe: un pour le store et un pour l’alias.

Un keystore peut généralement contenir plusieurs clés (alias), mais par convention (ou parce qu'on est tous des 🐑) on a souvent 1 keystore = 1 alias

Une fois cela fait, nous allons considérer que vous avez un fichier keystore (c’est le -keystore keystore pour changer le nom),

Ce fichier se trouve normalement à la racine de votre projet.

📦 Utiliser la clé pour signer l’application

Que vous choisissiez la solution 1 (Android Studio) ou la solution 2 (CLI) il est très important de noter/retenir 3 choses

⚠️ Si vous perdez une de ces infos, vous êtes chocolat vert bleu pâle. 😱 Aucun moyen n’existe pour les retrouver.

(Peut-être avec une séance de spiritisme ou d’hypnose pour creuser dans vos souvenirs profonds 🔮)

Maintenant pour signer votre application. Vous avez 2 méthodes.

La première, la méthode Android Studio qui se fait à base de clics. Vous conviendrez que ce n’est pas forcément pratique. Mais ça fait le taf.

Le problème en plus de ça ? Vous devrez remettre *les mots de passe à chaque fois… *🤦‍♀️🤦‍♂️

Dans une optique d’optimisation de temps, vous conviendrez qu’on va éviter de passer par une procédure de 5 étapes en clics clics dans laquelle on va prend 15 min pour retrouver un mot de passe ?

Si tel est le cas, alors on continue. 👍

🤯 Utiliser la clé dans son fichier build.gradle

Cela nous amène donc à la méthode 2.

On va simplement ajouter une configuration dans un fichier et hop.

Magicien

Incroyable ce qu’on peut faire avec des fichiers de configuration.

Premièrement, on va créer une configuration de signature dans notre fichier app/build.gradle et y mettre toutes les infos qu’on a notées.

android {

    buildTypes {

        signingConfigs {
            release {
                keyAlias 'KEY_ALIAS'
                keyPassword 'KEY_PASSWORD'
                storeFile file('../keystore')
                storePassword 'STORE_PASSWORD'
            }
        }

        release {
            signingConfig signingConfigs.release
        }

    }

}

Remarquez quand même le ../keystore, en effet, quand je vous ai fait générer votre clé, on l’a mise à la racine du projet.

Le fichier app/build.gradle étant dans le sous-répertoire app. Il faut remonter d’un cran, d’où le ..

🏹 Faire une release de son application

./gradlew assembleRelease

L’application 📦 générée sera déjà signée avec votre clé de release.

Et voilà, le build de release est automatisé ! 🚀🎉

🗃 Remplacer les infos par un fichier properties

Bon, c’est vrai que c’est sympa. Mais si vous avez suivi, il reste une pierre dans la claquette.

Les mots de passe du store sont en clair dans le fichier. 🔥🧨

Pire, ce même fichier est versionné, ce qui n’est pas vraiment terrible.

Note au passage, je vous invite à NE SOURTOUT PAS versionner le fichier keystore.

Voyez cela comme vos clés de maison.

Vous conviendrez qu’on peut dire que ça n’a rien à faire dans un dépôt public (public = plusieurs personnes ont accès, même si elles sont de confiance).

Une solution pour cela, c’est d’utiliser les fichiers properties.

👉 Extraire les informations dans un fichier properties.

Premièrement, nous allons tout simplement créer un fichier key.properties à la racine du projet (donc pas dans le module).

Secondement, dans ce fichier key.properties, nous allons mettre les infos nécessaires à la façon clé=valeur

torePassword=STORE_PASSWORD
keyPassword=Tq=KEY_PASSWORD
keyAlias=KEY_ALIAS
storeFile=../keystore

Vous remarquerez que j’ai ajouté le .gitignore de la racine… C’est pour vous rappeler d’y ajouter

key.properties
keystore

En effet, le but étant de faire en sorte que dans notre fichier app/build.gradle, plus rien ne soit utilisable car en clair, mais surtout versionné.

De la même façon, cela serait dommage de versionner le fichier key.properties et le keystore et perdre l’avantage gagné.

📖 Lire le fichier properties dans le fichier gradle

Dans notre fichier app/build.gradle, on va remplacer la signingConfig de release par cela

signingConfigs {
        release {
            def keystorePropertiesFile = rootProject.file('key.properties')
            def keystoreProperties = new Properties()
            if (keystorePropertiesFile.exists()) {
                keystoreProperties.load(
                    new FileInputStream(keystorePropertiesFile)
                )
            } else {
                throw new GradleException('Can\'t open the signing properties')
            }

            keyAlias keystoreProperties['keyAlias']
            keyPassword keystoreProperties['keyPassword']
            storeFile file(keystoreProperties['storeFile'])
            storePassword keystoreProperties['storePassword']
        }
     }

On remarque qu’on a fait plusieurs choses ici

  1. On charge le fichier de properties qui s’appelle key.properties.
  2. Ce même fichier contient 4 _clés - valeurs
    • keyAlias qui est notre KEY_ALIAS
    • keyPassword qui est notre KEY_PASSWORD
    • storeFile qui représente l’emplacement de notre KEYSTORE
    • storePassword, notre STORE_PASSWORD

Ce qui est important ici, c’est que si notre fichier keystore est à la racine du projet, il ne faut pas oublier de préfixer par ../

Tout simplement parce qu’au runtime, nous sommes dans le dossier du module ! (app généralement)

Maintenant, quand vous lancez votre

./gradlew assembleRelease

L’application 📦 générée sera déjà signé avec votre clé de release sans que vos mots de passe ne soient exposés ! Pas mal 👍

Maintenant vous allez me dire : Si on est plusieurs devs sur le projet…

Ce à quoi je vais répondre : patience papillon 🦋. On verra ça à l’étape 3.

Cela dit, si vous n’avez pas de service de déploiement continu (gitlab runner, jenkins, github actions, etc etc etc), vous pouvez toujours vous partager le fichier keystore et le key.properties.

Dites-vous bien que plus nombreux sont les personnes qui ont accès à ce fichier, plus grands sont les risques.

🥳 En résumé

Nous vennons de voir qu’avec une clé de release et quelques fichiers de configurations, on peut se passer des clics clics d’Android Studio et qu’on peut lancer un build facilement en une ligne.

La suite, ça va être de s’intéresser à Fastlane. Un outil qui au début ne va pas révolutionner notre vie, mais qui très vite va s’avérer un allié précieux.

  1. 📦 Builder et signer son application Android
  2. 🚀 Automatiser les builds avec Fastlane
  3. 🔥 Déployer son application sur Firebase
  4. 🛳 Déployer son application sur le Play Store
  5. 🤖 Utiliser Gitlab pour déployer son application lors d’un tag de release sur git.