Chapitre 11.2 — Créer son development build

Où on en est : expo-dev-client est installé, la théorie est claire. On compile — par les DEUX chemins (cloud EAS et local gradle), pour ne jamais dépendre d’un seul.

⏱️ TL;DR — Chemin cloud : eas build --profile development --platform android (compte Expo gratuit, eas.json créé par eas build:configure, file d’attente, APK à télécharger). Chemin local : npx expo run:android (prebuild + gradle sur VOTRE machine — Android Studio de la P2 enfin exploité, illimité et hors ligne). Les deux produisent le même dev build ; on installe, on lance npx expo start, l’app s’y connecte — et le quotidien reprend.

🎯 Objectifs

• Configurer EAS (compte, CLI, eas.json) et lancer le premier build cloud.
• Faire le même build en local avec expo run:android (et savoir où va l’APK).
• Choisir le bon chemin selon le contexte (quotas, vitesse, CI).
• Se connecter au dev build et vérifier que tout Drill fonctionne.

Chemin 1 : EAS Build (le cloud)

npm install -g eas-cli          # la CLI globale
eas login                        # compte expo.dev gratuit
eas build:configure              # crée eas.json + le projectId dans app.json

Le eas.json généré, annoté :

{
  "build": {
    "development": {
      "developmentClient": true,      // ← inclut expo-dev-client
      "distribution": "internal",     // ← APK installable directement (pas un AAB store)
      "android": { "buildType": "apk" }
    },
    "preview": {
      "distribution": "internal",
      "android": { "buildType": "apk" }
    },
    "production": {
      "autoIncrement": true           // versionCode auto — P12/P13
    }
  }
}

Trois profils = trois usages : development (le dev build), preview (une prod-like à sideloader — P12), production (le AAB du store — P13). Lancement :

eas build --profile development --platform android

Le déroulé : la CLI uploade le projet → un runner cloud fait prebuild + gradle → ~10-20 min de file+build (plan gratuit) → un lien + QR code vers l’APK. Sur le téléphone : scanner, télécharger, installer (autoriser les « sources inconnues » pour le navigateur — Android le proposera).

Ce que le cloud vous épargne : la maintenance de la toolchain (versions de Java, SDK, gradle) et — surtout côté iOS un jour — les certificats. Ce qu’il coûte : la file d’attente et le quota mensuel du plan gratuit (~15-30 builds selon la période — largement assez à notre rythme « conteneur »).

Chemin 2 : le build local

npx expo run:android

Ce qu’il se passe (visible dans le terminal) : prebuild (génération d’android/ — chapitre 11.4) → gradle assembleDebug (compile, avec le SDK d’Android Studio de la P2 — ANDROID_HOME sert enfin) → installation sur l’appareil/émulateur connecté → lancement + connexion à Metro. Premier build : long (gradle télécharge la moitié d’internet — 5-15 min) ; les suivants : 1-3 min (caches).

L’APK produit vit dans android/app/build/outputs/apk/debug/app-debug.apk — installable sur n’importe quel appareil (adb install …).

Le match — et notre doctrine

Doctrine du cours (fidèle à la décision de la session de plan) : le local est le chemin par défaut sur votre machine à 64 Go — rapide, illimité, gratuit. EAS est le chemin des occasions : builds iOS un jour, CI, partager un APK sans câble, machine en panne. Connaître les deux = ne jamais être bloqué.

Se connecter — et le rituel de vérification

Dev build installé, lancez npx expo start : l’app (icône Drill !) s’ouvre sur l’écran dev-client, votre serveur Metro y apparaît (même réseau — les réflexes du ch. 2.2 valent). Tapez : le bundle charge, Drill tourne.

Le rituel de re-validation (10 min qui évitent des surprises) :

1. Une partie complète — timer, haptics, sons, explication, enregistrement SQLite.
2. npx uri-scheme open "drill://quiz?theme=php&count=5" --android — le VRAI deep link, enfin (plus de préfixe exp://).
3. La notification quotidienne à now+2 min, app tuée → tap → quiz direct.
4. Le mode avion + kill + relance (matrice offline du ch. 7.4).

⚠️ Piège — Le dev build et Expo Go peuvent cohabiter sur le téléphone, mais Metro propose par défaut le dernier utilisé : si l’app qui s’ouvre au scan n’est pas la bonne, touche s dans le terminal Metro (switch entre Expo Go et dev build). Et un dev build est lié à son projectId : celui d’un autre projet ne chargera pas Drill.

💡 Pour un dev Next.js — eas.json va vous rappeler vercel.json + les environnements Vercel (preview/production) : même philosophie de profils d’infrastructure versionnés dans le repo. La différence : le « déploiement » mobile produit un binaire à installer, pas une URL — la P12 comble justement ce fossé avec EAS Update (les URLs du pauvre… ou plutôt du malin).

✏️ Exercices

1. Faites les DEUX builds (EAS development + run:android), installez les deux tour à tour, et chronométrez chaque chemin. Notez votre verdict personnel dans le README de Drill.

2. Le rituel de vérification (4 points) : déroulez-le sur le dev build et documentez ce qui diffère d’Expo Go (au moins 2 différences observables).

3. Votre collègue n’a pas Android Studio et veut tester Drill sur SON téléphone ce soir. Quel chemin, quelles étapes exactes, et quelle limite ?

🧠 Quiz

1. Que contient eas.json et pourquoi trois profils ?

2. Que fait npx expo run:android, étape par étape ?

3. Où trouve-t-on l’APK d’un build local ?

4. Quelle est la doctrine locale/cloud du cours, et pourquoi ?

5. Un dev build fraîchement installé affiche un écran de connexion — pourquoi n’est-ce pas un bug ?

👉 Chapitre suivant : 11.3 — app.config.ts & config plugins — la config devient du code.