Construire l'application Android
Fabriquer, avec EAS Build, un fichier APK installable sur un téléphone Android, sans passer par Expo Go ni par le Play Store.
Objectifs de la séance
- comprendre ce que fait EAS Build et la différence entre un APK et un AAB ;
- donner à l'application un identifiant Android (
android.package) ; - écrire le fichier
eas.jsonavec un profilpreviewqui produit un APK ; - fournir à EAS les variables d'environnement de Supabase, car
.env.localn'est pas envoyé ; - lancer le build, installer l'APK sur un téléphone, puis fusionner le tutoriel dans
main.
Petite vérification
Avant de commencer, vérifiez si vous savez...
- lire dans
app.jsonla valeur deweb.output - citer la commande qui exporte le site Web et le nom du dossier qu'elle crée
- si vous avez publié le site : afficher l'adresse de votre version publiée et vérifier qu'elle se termine par
.expo.app
📌 Réponse attendue
TP pour réfléchir et résoudre des problèmes
Votre mission : obtenir un fichier .apk que vous (ou un camarade) pouvez installer sur un téléphone Android et
ouvrir comme n'importe quelle application. Le travail de construction est réalisé sur les serveurs d'Expo : vous
n'avez besoin ni d'Android Studio, ni d'un câble. Vous restez sur la branche feature/deploiement, et vous
avez besoin du compte Expo créé à la séance précédente.
Les commandes de cette séance viennent de la documentation officielle d'Expo (docs.expo.dev, rubriques
« Create your first build », « APK » et « Environment variables »). Elles n'ont pas pu être exécutées pendant la
conception du cours. Peuvent donc varier : les questions posées par l'outil, le nom exact de certaines commandes,
le temps d'attente (la file d'attente du plan gratuit peut durer plusieurs minutes), et les limites du plan
gratuit (nombre de builds par mois). Lisez les messages affichés et suivez-les ; en cas de désaccord entre ce cours et
la documentation actuelle, la documentation a raison.
Étape 1 — Donner un identifiant à l'application Android
Chaque application Android est reconnue par un identifiant unique (le package), écrit à l'envers comme un
nom de domaine : com.exemple.quizcyber. Ouvrez app.json et ajoutez-le dans la section "android", à la suite de
predictiveBackGestureEnabled (sans oublier la virgule). Complétez la ligne :
Ajoutez de la même façon, dans la section "ios", la clé "bundleIdentifier": "com.exemple.quizcyber" (c'est
l'équivalent pour iOS ; sans elle, EAS le demanderait plus tard). Remplacez exemple par un nom qui vous
est propre (par exemple com.dupont.quizcyber) : l'identifiant doit être unique au monde, en minuscules, sans espace
ni tiret.
Sur le Play Store, l'identifiant ne peut plus être changé après la première publication : c'est lui qui distingue votre application de toutes les autres. Mieux vaut y réfléchir avant, même pour un projet scolaire.
Étape 2 — Relier le projet à EAS
EAS doit savoir à quel projet appartiennent vos builds. Lancez, dans le terminal :
npx eas-cli@latest init
L'outil crée le projet sur votre compte Expo et ajoute son identifiant dans app.json (section extra.eas).
Si le projet est déjà relié (par le déploiement Web de la séance précédente), il vous l'indique et ne modifie rien.
Après une commande qui modifie vos fichiers, ouvrez-les (ou lancez git diff) et vérifiez ce qui a changé. Un
outil automatique reste un outil : il vaut mieux savoir ce qu'il a écrit dans votre projet.
Étape 3 — Écrire le fichier eas.json
eas.json décrit les profils de construction (build profiles). Créez ce fichier à la racine du projet, avec deux
profils : preview (un APK pour tester) et production (pour un futur envoi sur le Play Store). Complétez la ligne qui
indique que le profil preview est destiné à une distribution interne (installation directe, hors magasin) :
Les propriétés importantes :
"distribution": "internal": le build n'est pas destiné à un magasin ; il se télécharge et s'installe depuis un lien ;"buildType": "apk": produit un APK, installable directement (par défaut, EAS produit un AAB, le format réservé au Play Store) ;"environment": "preview": le build utilise les variables d'environnement EAS de l'environnementpreview(étape suivante) ;"appVersionSource": "remote": le numéro de version de l'application est géré par EAS ;"autoIncrement": truel'augmente à chaque build de production.
Le profil preview sert aux tests (rapide, installable en un clic) ; production servira à la publication
(signature et numéro de version gérés). Les séparer évite de publier par erreur une version de test.
Étape 4 — Fournir les variables d'environnement à EAS
Votre fichier .env.local est ignoré par Git (c'est voulu !) : il n'est donc jamais envoyé aux serveurs d'EAS.
Sans lui, l'APK afficherait « Configuration Supabase manquante » : l'application ne connaîtrait ni l'adresse du projet,
ni la clé publishable. Il faut donc créer les deux variables chez EAS, pour l'environnement preview
(remplacez les valeurs par celles de votre fichier .env.local) :
npx eas-cli@latest env:set --name EXPO_PUBLIC_SUPABASE_URL --value https://votre-projet.supabase.co --environment preview --visibility plaintext
Complétez la commande qui crée la seconde variable, la clé publishable :
Vérifiez avec npx eas-cli@latest env:list --environment preview : les deux variables doivent apparaître.
Les variables EXPO_PUBLIC_... sont recopiées dans le code de l'application, et n'importe qui peut extraire un APK et le
lire. La clé publishable est faite pour cela. Une clé secret ou service_role ne doit jamais être mise dans une
variable EXPO_PUBLIC_..., ni dans EAS, ni ailleurs dans l'application : le niveau de visibilité « secret » d'EAS protège la
variable pendant le build, mais pas ce qui est ensuite embarqué dans l'application.
La documentation actuelle d'Expo utilise eas env:set pour créer ou mettre à jour une variable. Selon la version
de l'outil, vous pouvez aussi rencontrer eas env:create ; lancez npx eas-cli@latest env --help pour voir les commandes disponibles.
Local : .env.local. Chez EAS : variables par environnement (development, preview, production).
Vous pouvez ainsi, plus tard, faire pointer la version production vers un autre projet Supabase que celle de test.
Étape 5 — Enregistrer la configuration
EAS construit l'application à partir des fichiers versionnés de votre projet : enregistrez donc app.json et eas.json
avant de lancer le build. Comme c'est la dernière modification du tutoriel, le message est celui de la séance :
Avant git add -A, lancez git status : ni .env.local, ni dist/, ni un fichier de clé (*.jks) ne doivent apparaître. Le
.gitignore du projet les ignore, mais on vérifie toujours.
Étape 6 — Lancer le build Android
Lancez la construction du profil preview pour la plateforme Android :
npx eas-cli@latest build --platform android --profile preview
Le premier build pose quelques questions :
- « Generate a new Android Keystore? » : répondez oui. Le keystore est la clé de signature de votre application ; EAS la génère et la conserve sur ses serveurs. Une application doit être signée toujours avec la même clé pour pouvoir être mise à jour.
- l'outil envoie votre projet, puis affiche un lien vers la page du build sur expo.dev : vous suivez la progression (file d'attente, installation, compilation) sur cette page.
La construction dure plusieurs minutes. Vous pouvez interrompre l'outil dans le terminal (Ctrl + C) : le build continue sur les serveurs, et
npx eas-cli@latest build:list liste vos builds.
Si le build échoue, ouvrez sa page sur expo.dev et lisez le journal (logs) : l'erreur est presque toujours expliquée à la fin de l'étape en échec (identifiant manquant, variable absente, dépendance incompatible). Corrigez, enregistrez dans Git, puis relancez le build.
Étape 7 — Installer l'APK sur un téléphone
Quand le build est terminé, sa page affiche un bouton de téléchargement et un QR code.
- Sur votre téléphone Android, ouvrez le lien (ou scannez le QR code avec l'appareil photo).
- Téléchargez le fichier
.apk. - Android demande d'autoriser « Installer des applications inconnues » pour votre navigateur : acceptez, car l'application ne vient pas du Play Store. Un message de Play Protect peut aussi s'afficher : c'est normal pour une application de test non publiée.
- Ouvrez l'application Quiz Cyber et déroulez la recette (parties 2 et 3) sur le téléphone.
Jusqu'ici, l'application n'a été vérifiée que dans le navigateur. Sur un téléphone, certaines choses diffèrent : le clavier,
la mémorisation de la session (la bibliothèque expo-sqlite remplace localStorage), la reprise de l'application après
une mise en veille. Si une fonction se comporte différemment de la version Web (connexion qui échoue, pseudo
perdu au redémarrage...), notez-le dans le cahier de recette et signalez-le à votre enseignant : c'est précisément le but de ce test.
L'émulateur et le navigateur ne reproduisent pas tout : réseau mobile, capteurs, gestes, vitesse réelle. Un APK de test distribué à quelques camarades révèle les problèmes avant une vraie publication.
Étape 8 — Fusionner le tutoriel dans main
Le tutoriel 10 est terminé. Sur GitHub, ouvrez une Pull Request de feature/deploiement vers main (le dépôt propose le
bouton Compare & pull request), relisez l'onglet Files changed : vous devez y voir docs/RECETTE.md, package.json,
app.json et eas.json, et aucun secret. Cliquez sur Merge pull request, puis, en local :
Pour une Pull Request, l'onglet Files changed est votre dernière occasion de repérer un fichier qui n'a rien à faire là (clé, fichier de configuration personnel, gros fichier généré).
📌 Une solution
Notions théoriques
Expo Go, build de développement et application autonome
Jusqu'ici, sur téléphone, vous utilisiez Expo Go : une application « bac à sable » qui charge votre code à distance. C'est parfait pour développer, mais ce n'est pas votre application : elle n'a ni son nom, ni son icône, ni son identifiant. EAS Build fabrique une application autonome (standalone) : votre code, compilé avec le moteur React Native, signé et emballé dans un fichier installable.
EAS : les services d'Expo
EAS (Expo Application Services) regroupe des services hébergés par Expo, que vous avez déjà croisés :
| Service | Rôle | Dans ce cours |
|---|---|---|
| EAS Hosting | héberger un site Web statique | séance précédente |
| EAS Build | compiler l'application sur des serveurs | cette séance |
| Variables d'environnement | fournir configuration et clés aux builds | étape 4 |
| EAS Update, Submit | envoyer une mise à jour, déposer sur le Play Store | pour aller plus loin |
La compilation d'une application Android demande des outils lourds (Java, Android SDK, Gradle). EAS les met à disposition dans le nuage : vous n'installez rien, et vous pouvez même construire une application iOS sans Mac (avec un compte Apple Developer payant pour la signature).
APK ou AAB ?
| APK | AAB | |
|---|---|---|
| Usage | test, distribution directe | publication sur le Play Store |
| Installation directe | oui | non |
| Taille | contient tout | optimisé par Google pour chaque téléphone |
Signature et identifiant
Un téléphone refuse d'installer une application non signée, et refuse une « mise à jour » signée avec une autre
clé. La clé de signature (le keystore) prouve que la mise à jour vient bien du même auteur. L'identifiant
(android.package) désigne l'application : deux applications avec le même identifiant sont considérées comme la même.
Variables d'environnement d'un build
Un build s'exécute sur les serveurs d'Expo, pas chez vous : les fichiers ignorés par Git (comme .env.local) n'y
existent pas. Les variables de l'environnement EAS (preview, production...) sont donc injectées pendant le build, et
les valeurs EXPO_PUBLIC_... sont recopiées dans le code de l'application, lisible par quiconque possède l'APK.
Test de mémorisation/compréhension
Exercices complémentaires
Exercice A : un profil qui hérite d'un autre
Ajoutez au eas.json un profil essai qui hérite de preview ("extends": "preview") et ne change que la
distribution. Quel intérêt voyez-vous à hériter d'un profil plutôt que de le recopier ?
📌 Réponse attendue
Exercice B : le rapport de test mobile
Sur votre téléphone, déroulez le parcours normal puis les tests 3.1, 3.4 et 3.5 de la recette. Ajoutez au cahier une cinquième partie « 5. Spécifique mobile » avec deux tests que vous avez imaginés (par exemple : mise en veille en pleine partie, rotation de l'écran).
Ce qu'il faut retenir
| Notion | Résumé |
|---|---|
| EAS Build | Compile l'application sur des serveurs Expo : ni Android Studio, ni câble. |
android.package | Identifiant unique de l'application Android, à choisir avec soin. |
eas.json | Profils de construction : preview (APK interne de test) et production. |
| APK / AAB | APK : installation directe ; AAB : format du Play Store. |
| Variables EAS | .env.local n'est pas envoyé : on crée EXPO_PUBLIC_... avec eas env:set pour l'environnement du profil. |
| Secrets | Tout ce qui est embarqué dans l'application est lisible : jamais de clé secrète dans une variable EXPO_PUBLIC_.... |
| Keystore | Clé de signature de l'application, conservée par EAS, à ne jamais publier. |
| Pull Request | Fin de tutoriel : relecture des fichiers, fusion dans main, git switch main puis git pull. |
Aperçu de la prochaine séance
Votre application est testée, publiée sur le Web et installable sur Android. Dans le dernier tutoriel, vous allez la rendre plus agréable et plus accessible : annonces vocales pour les personnes qui utilisent un lecteur d'écran, vibrations sur téléphone, puis un formulaire permettant aux joueurs de proposer de nouvelles questions.