Test fermé Google Play pour les apps React Native et Expo

La règle est la même pour tous les frameworks. Un compte Play Console personnel créé après le 13 novembre 2023 doit mener un test fermé avec au moins 12 testeurs inscrits pendant 14 jours sans interruption avant de pouvoir demander l'accès production (Aide Play Console).

React Native vous offre deux chemins : la CLI React Native avec Gradle, ou Expo avec EAS Build et EAS Submit. Ils diffèrent sur l'emplacement du SDK cible, sur qui détient votre keystore, et sur le canal où atterrit votre premier envoi. Ce dernier point piège beaucoup d'utilisateurs d'Expo. Le guide du test fermé couvre la règle elle-même.

Compiler l'AAB

Depuis août 2021, les nouvelles apps doivent être publiées sur Google Play au format Android App Bundle (Android Developers). Les deux chemins en produisent un.

CLI React Native (doc React Native) :

npx react-native build-android --mode=release

La commande lance la tâche Gradle bundleRelease et écrit android/app/build/outputs/bundle/release/app-release.aab.

Expo (doc Expo) :

eas build --platform android --profile production

Le profil production par défaut produit un .aab. Un profil ne produit un .apk que s'il règle android.buildType sur apk, et un .apk ne peut pas être envoyé sur Google Play. EAS Build fonctionne avec l'offre gratuite d'Expo ; les offres payantes réduisent surtout l'attente dans la file (doc Expo).

API cible 36 : où regarder

Depuis le 31 août 2026, les nouvelles apps et les mises à jour doivent cibler Android 16 (niveau d'API 36) ou une version ultérieure (Aide Play Console).

CLI React Native. La valeur se trouve dans le fichier android/build.gradle de votre projet, dans buildscript { ext { ... } }. Sur la branche 0.88-stable du modèle officiel (0.88 est la dernière version listée sur reactnative.dev/versions aujourd'hui), on lit (modèle) :

minSdkVersion = 24
compileSdkVersion = 37
targetSdkVersion = 36

Ce fichier appartient à votre projet. Mettre à jour le package react-native ne le réécrit pas. Si votre projet est parti d'un modèle plus ancien, ouvrez le fichier et vérifiez le nombre vous-même.

Expo. C'est la version du SDK qui décide. Le tableau d'Expo liste les SDK 56, 57 et 58, et tous trois utilisent targetSdkVersion 36 (le SDK 58 compile avec l'API 37 et va avec React Native 0.88) (doc Expo). Les SDK plus anciens ne figurent plus dans le tableau. Si vous êtes sur l'un d'eux, mettez à jour avant le test fermé plutôt que de bricoler autour.

Le guide de l'API cible 36 liste ce qu'il faut retester après la mise à niveau.

La signature, et qui détient la clé

CLI React Native. Générez une clé d'importation avec keytool, placez les variables MYAPP_UPLOAD_* dans ~/.gradle/gradle.properties (et non android/gradle.properties, pour qu'elles restent hors de git), et ajoutez une configuration de signature release dans android/app/build.gradle (doc React Native). La même page précise que Google Play n'accepte l'AAB que si la Signature d'application Play est configurée pour l'app.

Expo. EAS CLI peut générer le keystore pour vous et le stocke sur les serveurs d'Expo (doc Expo). eas credentials affiche les identifiants configurés et peut les synchroniser sur votre machine (doc Expo). Faites-le une fois et sauvegardez le fichier.

Pourquoi c'est important maintenant : avec la Signature d'application Play, Google peut réinitialiser une clé d'importation perdue, mais une clé de signature d'application que vous gérez vous-même ne peut pas être réinitialisée (Aide Play Console). La vérification des développeurs Android ajoute une deuxième raison. Enregistrer un package peut exiger la preuve que vous possédez sa clé de signature, et la FAQ de Google précise qu'une clé de signature perdue vous empêche d'enregistrer vos packages (FAQ Android Developers).

Autre piège : Google Sign-In et Firebase ont besoin de l'empreinte de la clé de signature d'application détenue par Google, pas seulement de votre clé d'importation (Aide Play Console). Sinon, la connexion marche dans votre build local et échoue chez les testeurs qui ont installé l'app depuis Google Play.

Le piège d'Expo : votre premier envoi part en test interne

La documentation d'Expo indique que, lors d'un premier envoi, eas submit par défaut « creates your app's first release on the internal testing track » (crée la première version de votre app sur le canal de test interne) (doc Expo). Il faut d'abord avoir envoyé à Expo une clé de compte de service Google.

Le test interne ne remplit pas l'exigence de Google. Pire, Google indique qu'un utilisateur inscrit à votre test interne ne peut plus recevoir votre test fermé (Aide Play Console). Si vous envoyez le lien du test interne à vos futurs testeurs du test fermé, ils ne pourront pas rejoindre le test fermé avant de s'être désinscrits du test interne. Le guide interne, fermé ou ouvert explique la différence.

À faire à la place :

1. Importez vous-même la première version fermée dans la Play Console : Tester et publier > Tests > Tests fermés > Gérer le canal > créer une version, et choisissez le .aab de votre build EAS.
2. Ensuite, automatisez. Le champ track du profil de soumission de votre eas.json accepte production, beta, alpha et internal (doc Expo). Dans l'API Google Play Developer, beta désigne le canal de test ouvert (Google for Developers), qui reste verrouillé tant que vous n'avez pas l'accès production. Vérifiez dans la Play Console le nom du canal de votre test fermé avant de vous fier à une valeur.
3. Si votre app est encore à l'état de brouillon dans la Play Console, réglez releaseStatus sur draft dans le profil de soumission et terminez la publication dans la Play Console.

Codes de version

Chaque envoi exige un versionCode plus élevé (Aide Play Console). Vous publierez des correctifs pendant les 14 jours : automatisez-le.

• CLI React Native : versionCode dans defaultConfig de android/app/build.gradle.
• Expo : android.versionCode dans la configuration de votre app, « Increment by one for each release » (à augmenter de un à chaque version) (doc Expo). Ou réglez autoIncrement dans le profil de build ; avec cli.appVersionSource sur remote, ce sont les serveurs d'Expo qui tiennent le compteur (doc Expo).

Les autorisations que vous n'avez pas demandées

React Native ajoute l'autorisation INTERNET par défaut. SYSTEM_ALERT_WINDOW n'est ajoutée qu'en debug et retirée en production (doc React Native).

Les bibliothèques natives fusionnent leurs propres autorisations dans le manifeste final. Dans Expo, android.blockedPermissions retire les autorisations qu'ajoutent les packages ; dans un projet bare, utilisez tools:node="remove" dans AndroidManifest.xml (doc Expo). C'est important, car Google évalue aussi les autorisations à haut risque sur les canaux de test, et une autorisation non déclarée sur une version fermée active peut vous empêcher de publier des modifications (Aide Play Console).

Les bugs du build release que les testeurs trouveront

• Build release vide ou qui plante. La documentation React Native prévient que org.gradle.configureondemand=true dans gradle.properties fait sauter au build release l'empaquetage du JS et des ressources (doc React Native). Retirez cette ligne.
• Réduction de code. Si vous activez Proguard, chaque bibliothèque native peut demander ses propres règles. Testez le build réduit.
• Testez le vrai artefact. Désinstallez la version debug, puis lancez npm run android -- --mode="release" sur un téléphone. Avec Expo, installez le build de production lui-même, pas un development client.
• Écrans de connexion. Donnez aux testeurs des identifiants qui fonctionnent, et remplissez la section Accès aux applications de la Play Console pour les examinateurs de Google.

Le guide de configuration du test fermé détaille l'onglet Testeurs, les pays et le lien d'inscription (opt-in).

Combien de temps ça prend

• Mise en place de la signature avec la CLI React Native : environ une heure si Java et Android Studio fonctionnent déjà.
• EAS : Expo indique que le build d'une petite app démarre en quelques minutes ; les offres payantes réduisent surtout l'attente dans la file. La signature tient en quelques questions.
• Premier examen de Google : pour certains nouveaux comptes, jusqu'à sept jours, voire plus dans des cas exceptionnels (Aide Play Console). Ensuite, le lien d'inscription peut mettre plusieurs heures à fonctionner.
• Le test : 14 jours sans interruption. Examen de l'accès production : généralement une semaine ou moins (Aide Play Console).

Prévoyez trois à quatre semaines entre le premier envoi en test fermé et la production.