Chapitre 13.2 — Préparer la release : AAB, signing, submit

Où on en est : le compte existe. Côté technique, TOUT est déjà en place (P12) — ce chapitre ne fait que brancher le pipeline sur la Console : l’AAB du profil production, Play App Signing, et l’upload automatisé.

⏱️ TL;DR — eas build --profile production sort l’AAB (channel production pour les OTA). Play App Signing (obligatoire) : GOOGLE détient la clé de signature finale ; votre keystore devient la « upload key » (perdable et remplaçable — le drame du keystore perdu appartient au passé). eas submit uploade l’AAB dans la Console sans clic. La première release passe par la piste interne (vous, tout de suite) avant le test fermé.

🎯 Objectifs

• Produire l’AAB de production (et re-situer chaque réglage déjà connu).
• Comprendre Play App Signing : upload key vs app signing key.
• Automatiser l’envoi avec eas submit (service account, une fois).
• Créer la première release sur la piste interne et l’auto-tester.

L’AAB de production

Le profil existe depuis le ch. 11.2 — relecture annotée :

"production": {
  "autoIncrement": true,                    // versionCode géré (ch. 12.6)
  "channel": "production",                  // les OTA du store (ch. 12.5)
  "env": { "APP_VARIANT": "production" }    // identité com.alex.drill
}

eas build --profile production --platform android    # buildType par défaut = AAB (app-bundle)

Rien de neuf : mêmes prebuild, gradle, signature — seul le format de sortie change (bundleRelease au lieu d’assembleRelease). L’AAB ne s’installe pas (ch. 12.2) : son seul destin est la Console.

Play App Signing — qui signe quoi

Depuis 2021, le Play Store impose son modèle à deux clés :

• L’app signing key (celle qui compte pour les utilisateurs) est générée et détenue par Google — vous ne la voyez jamais.
• Votre keystore (celui d’EAS, ch. 12.2) devient l’upload key : il authentifie VOS uploads. Perdu ? Contrairement au passé : un formulaire de reset auprès de Google et une nouvelle upload key — l’app survit. (La paranoïa keystore du ch. 12.3 reste valable pour… la voie perso, où VOTRE clé est la seule.)
• Conséquence pratique : l’APK que télécharge un utilisateur du Store n’a PAS la même signature que votre APK sideloadé → on ne met pas à jour l’un par l’autre. Les deux voies (P12/P13) sont des lignées parallèles — même package name, mais un téléphone suit l’une OU l’autre.

L’activation est automatique à la première release (opt-in par défaut) — Configuration → Intégrité de l’app pour le vérifier.

eas submit — l’upload sans clics

eas submit --platform android --latest     # envoie le dernier build EAS vers la Console

Le setup une-fois : un service account Google Cloud (la doc EAS guide pas à pas : créer la clé JSON dans la Console Google Cloud, la lier dans la Play Console, la déclarer dans eas.json) :

"submit": {
  "production": {
    "android": {
      "serviceAccountKeyPath": "./secrets/play-service-account.json",
      "track": "internal"                   // ← la piste cible (internal → closed → production)
    }
  }
}

(⚠️ le JSON du service account = un secret : .gitignore + gestionnaire de mots de passe — c’est une clé d’API qui peut publier votre app.)

Subtilité de la PREMIÈRE fois : le tout premier AAB d’une app doit être uploadé manuellement dans la Console (créer la release de piste interne à la main) — eas submit prend le relais ensuite. Et le premier upload FIGE le package name (le dernier irréversible de la liste).

La piste interne — votre bac à sable de Console

Tests → Tests internes → créer la release (l’AAB uploadé), ajouter votre email de testeur → lien d’opt-in → le Play Store vous propose Drill en quelques minutes (pas de review sur cette piste). C’est la répétition générale : l’app telle que le Store la livre (APK dérivé, signé Google), sur votre téléphone, via le vrai canal.

Le rituel d’auto-test s’enrichit d’un point store : vérifier que la version Store se met bien à jour PAR le Store (pousser un second AAB, la mise à jour apparaît) — et que vos OTA (channel production) l’atteignent.

⚠️ Piège — Le téléphone qui a l’APK sideloadé (P12) ne peut PAS installer la version Store par-dessus (signatures différentes — voir plus haut). Pour tester la piste interne : désinstaller la version perso d’abord (adieu l’historique local de CE téléphone — on l’accepte, ou on teste sur l’émulateur/un second appareil). Anticipez ce moment : le jour où une app perso « passe au Store », ses premiers utilisateurs (vous, la famille) doivent migrer manuellement.

💡 Pour un dev Next.js — eas submit + les pistes = votre pipeline preview/production Vercel, mais avec un intermédiaire souverain au milieu. Play App Signing en est le symbole : sur le web, VOUS êtes l’autorité de ce que reçoivent les navigateurs ; sur le Store, l’autorité finale est Google — vous ne faites que proposer.

✏️ Exercices

1. Construisez le vrai AAB de production de Drill (local ou cloud) et inspectez-le : taille vs l’APK preview, et contenu (un AAB est un zip — regardez dedans).

2. Documentez la lignée de signatures de Drill : qui signe quoi sur les trois canaux (dev build, APK perso, Store), et quelles mises à jour croisées sont possibles.

3. Écrivez la checklist « première release interne » de A à Z (elle servira pour chaque nouvelle app) — de l’AAB au Drill installé via le Store.

🧠 Quiz

1. Upload key vs app signing key ?

2. Pourquoi l’APK Store et l’APK perso sont-ils incompatibles ?

3. Que faut-il configurer pour eas submit ?

4. Que permet la piste interne ?

5. Quel est le dernier « irréversible » déclenché dans ce chapitre ?

👉 Chapitre suivant : 13.3 — La fiche du store — la vitrine : assets, textes, et les questionnaires qui bloquent tout.