Test fermé Google Play pour les applications Expo (EAS)

Lors du premier build Android, EAS propose de générer un keystore et le stocke sur les serveurs d’Expo ; les builds suivants le réutilisent. Pour Google Play, ce keystore est votre clé d’importation. Au premier import, la signature d’application Play est configurée et Google conserve la clé de signature de l’application.

Utilisez eas credentials pour voir le keystore configuré, en télécharger une sauvegarde ou le remplacer. Gardez cette sauvegarde en lieu sûr : vous en aurez besoin si vous compilez un jour en local ou quittez EAS.

eas credentials -p android

Ne générez pas de nouveau keystore après votre premier import. Un bundle signé avec une autre clé d’importation est refusé tant que vous n’avez pas demandé sa réinitialisation dans la Play Console.

La Play Console refuse tout bundle dont le versionCode a déjà servi. Le plus simple est de laisser EAS le gérer à distance et l’incrémenter à chaque build de production :

{
  "cli": { "appVersionSource": "remote" },
  "build": {
    "production": { "autoIncrement": true }
  },
  "submit": {
    "production": {
      "android": { "track": "alpha", "releaseStatus": "draft" }
    }
  }
}

Avec appVersionSource réglé sur remote, EAS stocke le code de version et ignore android.versionCode dans la configuration de l’application. Si vous avez déjà importé des builds à la main, lancez une fois eas build:version:set pour qu’EAS reparte de votre dernier numéro.

Depuis le 31 août 2026, les nouvelles applications et mises à jour doivent cibler Android 16 (niveau d’API 36). Chaque version du SDK Expo fixe elle-même le SDK cible : la solution fiable est donc une version du SDK qui cible 36. Le plugin de configuration expo-build-properties peut remplacer targetSdkVersion, mais seulement si votre SDK et vos bibliothèques le prennent en charge.

• eas submit envoie vers le test interne. Par défaut, eas submit -p android envoie le build dans le canal interne, qui ne compte pas pour la règle des 12 testeurs. Indiquez "track": "alpha" (le canal fermé par défaut de Google) dans le profil de soumission, comme ci-dessus, ou importez à la main le .aab téléchargé dans le canal fermé.
• Premières releases en brouillon uniquement. Tant que l’application n’a jamais été publiée, Google n’accepte via l’API que des releases en brouillon. Gardez "releaseStatus": "draft" et terminez le déploiement dans la Play Console.
• Un compte de service est nécessaire. eas submit utilise une clé de compte de service Google que vous importez dans EAS, dans les identifiants de l’application. Sans elle, importez manuellement.
• Builds de développement. Un build avec developmentClient: true attend un serveur de développement. Vérifiez que les testeurs reçoivent le profil de production.
• Variables d’environnement manquantes. Les valeurs d’un fichier .env ignoré par git ne sont pas envoyées à EAS Build. Définissez les valeurs de production comme variables d’environnement EAS, sinon la release interroge le mauvais backend.
• Les changements natifs exigent un nouveau build. Autorisations, nom de package et plugins de configuration n’atteignent les testeurs que via un nouveau build EAS, pas via une mise à jour over-the-air.

eas submit -p android --profile production

Un build de production ne se comporte pas comme Expo Go ou un development build : pas de serveur de développement, un JavaScript minifié et uniquement les modules natifs que vous avez compilés. Reproduisez ce que voient les testeurs avant de faire des hypothèses.

1. 1

   Lancez le mode production en local

   npx expo start --no-dev --minify exécute votre JavaScript comme un bundle release et affiche des erreurs que le mode développement ne lève jamais.

2. 2

   Lisez les journaux natifs

   Branchez le téléphone en USB et lancez adb logcat. Les journaux natifs révèlent souvent la cause quand une error boundary JavaScript n’attrape pas le problème.

3. 3

   Consultez la Play Console

   Les plantages des testeurs apparaissent sous Surveiller et améliorer → Android Vitals → Plantages et ANR. Le rapport de pré-lancement, que Google génère automatiquement après un import, lance aussi l’application sur des appareils de test et liste les plantages trouvés.

4. 4

   Rendez les erreurs JavaScript lisibles

   Avec Sentry, EAS Build importe automatiquement les source maps dès que SENTRY_AUTH_TOKEN est défini comme variable d’environnement EAS sensible. Après eas update, lancez npx sentry-expo-upload-sourcemaps dist pour que les mises à jour soient lisibles aussi.

Besoin de déboguer le natif ? npx expo prebuild -p android crée le dossier android pour que vous puissiez brancher le débogueur d’Android Studio. Supprimez-le ensuite pour que le projet reste géré par Expo.

Une fois votre bundle Expo compilé et signé, la suite se passe dans la Play Console et fonctionne de la même manière pour tous les frameworks. Voici la liste de contrôle ; chaque menu et chaque écran sont décrits dans le guide Play Console complet.

• Terminez la configuration de l’application dans le tableau de bord : règles de confidentialité, accès à l’application, annonces, classification du contenu, audience cible, sécurité des données et fiche Play Store.
• Créez une release de test fermé sous Tester et publier → Tests → Test fermé : choisissez les pays de vos testeurs, importez le .aab et envoyez-le en examen.
• Ajoutez les testeurs avec un Google Group dans l’onglet Testeurs et partagez le lien d’inscription. Il fonctionne dès que le canal affiche Publié.
• Gardez au moins 12 testeurs inscrits pendant 14 jours d’affilée. Les tests internes ne comptent pas, et une personne qui part puis revient recommence ses 14 jours.
• Publiez au moins une mise à jour pendant le test et notez ce que les testeurs ont trouvé et ce que vous avez modifié.
• Demandez l’accès en production depuis le tableau de bord et répondez aux trois sections sur votre test, votre application et votre préparation. La décision revient à Google ; personne ne peut garantir l’approbation.

Prévoyez des départs : recrutez plus de 12 testeurs pour qu’un abandon ne retarde pas votre calendrier. Voir toutes les étapes Play Console.

Avec le versionnage distant, relancez simplement le build de production, puis importez-le ou soumettez-le dans le canal fermé ; le code de version augmente tout seul.

eas build -p android --profile production

Pour les correctifs purement JavaScript, EAS Update peut livrer un nouveau bundle sans nouvelle soumission au store. La règle Google Play sur l’usage abusif des appareils et des réseaux autorise ce type de mise à jour pour le code exécuté dans un interpréteur ou une machine virtuelle, comme le JavaScript ; elle n’autorise pas le téléchargement de code natif. Réservez les mises à jour aux vrais correctifs et restez dans le périmètre du build examiné.

eas update --channel production --message "Fix checkout crash" --environment production

• Canaux. eas update:configure définit un channel sur les profils de build preview et production. Un build ne reçoit que les mises à jour publiées sur son canal. Depuis le SDK 55, --environment est obligatoire.
• Version d’exécution. Une mise à jour n’atteint que les builds qui ont la même version d’exécution. La règle fingerprint la change dès qu’un élément affectant le runtime natif change, ce qui rend les mises à jour incompatibles très improbables.
• Redémarrages. Les builds release téléchargent une mise à jour en arrière-plan et l’appliquent après un redémarrage de l’application. Demandez aux testeurs de fermer puis rouvrir l’application, jusqu’à deux fois.
• Les changements natifs exigent un build. Nouvelles autorisations, config plugins ou bibliothèques natives n’arrivent aux testeurs que par un nouveau build de production dans le canal fermé, qui laisse aussi une release visible dans la Play Console.