Test fermé Google Play pour les applications React Native

Google Play exige la signature d’application Play pour les nouvelles applications : Google conserve la clé de signature de l’application et vous signez les imports avec une clé d’importation. Générez-la avec keytool, fourni avec le JDK :

keytool -genkeypair -v -storetype PKCS12 -keystore my-upload-key.keystore \
  -alias my-key-alias -keyalg RSA -keysize 2048 -validity 10000

Placez le fichier dans android/app/ et les identifiants dans ~/.gradle/gradle.properties pour qu’ils n’arrivent jamais dans git :

MYAPP_UPLOAD_STORE_FILE=my-upload-key.keystore
MYAPP_UPLOAD_KEY_ALIAS=my-key-alias
MYAPP_UPLOAD_STORE_PASSWORD=*****
MYAPP_UPLOAD_KEY_PASSWORD=*****

Ajoutez ensuite une configuration de signature release dans android/app/build.gradle et utilisez-la dans le type de build release. Celui du modèle signe avec la clé de debug tant que vous ne le modifiez pas :

android {
    signingConfigs {
        release {
            if (project.hasProperty('MYAPP_UPLOAD_STORE_FILE')) {
                storeFile file(MYAPP_UPLOAD_STORE_FILE)
                storePassword MYAPP_UPLOAD_STORE_PASSWORD
                keyAlias MYAPP_UPLOAD_KEY_ALIAS
                keyPassword MYAPP_UPLOAD_KEY_PASSWORD
            }
        }
    }
    buildTypes {
        release {
            // ...
            signingConfig signingConfigs.release
        }
    }
}

Chaque import exige un versionCode supérieur à tout ce que vous avez déjà importé. Dans un projet bare, il se trouve dans android/app/build.gradle ; versionName est le libellé visible par les utilisateurs :

android {
    defaultConfig {
        versionCode 2
        versionName "1.0.1"
    }
}

Depuis le 31 août 2026, les nouvelles applications et mises à jour doivent cibler Android 16 (niveau d’API 36). Les niveaux de SDK se trouvent dans le bloc ext de android/build.gradle (compileSdkVersion, targetSdkVersion). Les nouvelles versions de React Native les augmentent. Sur une version ancienne, mettre React Native à jour est généralement plus sûr que de relever seulement targetSdkVersion, car vos bibliothèques natives doivent aussi être compatibles.

• Bundle signé en debug. Si vous oubliez de passer le type de build release sur signingConfigs.release, la Play Console refuse l’import comme signé en debug.
• Surprises R8/ProGuard. Avec enableProguardInReleaseBuilds = true, les bibliothèques qui utilisent la réflexion peuvent planter uniquement en release. Ajoutez leurs règles de conservation dans android/app/proguard-rules.pro et testez la release sur un appareil.
• Rapports de plantage illisibles. Hermes, le moteur par défaut, exécute du bytecode précompilé ; les traces de release pointent vers le bundle compilé. Conservez les source maps de chaque build importé pour symboliser ce que les testeurs envoient.
• L’application cherche Metro. Un build de release qui tente de joindre le serveur de développement n’a pas de JavaScript intégré. Vérifiez le réglage configureondemand et recompilez.
• Modules natifs et pages de 16 Ko. Les bibliothèques avec des fichiers .so natifs doivent prendre en charge les pages mémoire de 16 Ko. La Play Console le signale et, à partir du 1er février 2027, les mises à jour non compatibles ne pourront plus être publiées. Mettez-les à jour avant le début du test.
• Keystore perdu. Sauvegardez le keystore et ses mots de passe. Vous pouvez demander une réinitialisation de la clé d’importation dans la Play Console, mais cela prend du temps que vous ne voulez pas perdre en plein test.

Un plantage JavaScript dans un build release vous arrive sous la forme d’une position de bytecode Hermes comme p@1:132161, qui ne dit rien à elle seule. React Native génère par défaut des source maps pour les builds release Android ; l’essentiel est de garder la bonne map pour chaque bundle importé.

1. 1

   Archivez la source map

   Après chaque build release, copiez la map depuis android/app/build/generated/sourcemaps/react/release/ et étiquetez-la avec le code de version. Elle doit correspondre exactement au commit du build qui a planté : même une petite modification du code décale les offsets.

2. 2

   Lancez metro-symbolicate

   Enregistrez la trace du testeur dans un fichier, ou lisez-la directement depuis adb logcat, puis passez-la dans metro-symbolicate avec cette map. L’outil retransforme les offsets de bytecode en noms de fichiers, lignes et fonctions.

3. 3

   Vérifiez les lignes natives dans la Play Console

   Les plantages dans le code Java ou Kotlin des modules natifs apparaissent sous Surveiller et améliorer → Android Vitals → Plantages et ANR. Avec R8 activé, le fichier de mapping inclus dans le .aab les rend lisibles sans import supplémentaire.

# From a saved stack trace
npx metro-symbolicate android/app/build/generated/sourcemaps/react/release/index.android.bundle.map < stacktrace.txt

# From a connected device
adb logcat -d | npx metro-symbolicate android/app/build/generated/sourcemaps/react/release/index.android.bundle.map

Si metro-symbolicate se termine aussitôt sans rien afficher, il n’a reçu aucune entrée : transmettez la trace par un pipe ou une redirection, pas en la tapant dans le terminal.

Une fois votre bundle React Native 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 React Native : augmentez versionCode (et versionName), recompilez et importez le nouveau bundle dans le même canal fermé.

cd android
./gradlew bundleRelease

Désinstallez l’application debug avant d’installer la variante release avec npm run android -- --mode="release" : Android ne remplace pas une application signée avec une autre clé. Refaites cette vérification avant chaque import, car les problèmes propres à la release, comme des règles keep manquantes, n’apparaissent jamais en debug.

Les mises à jour JavaScript over the air sont une zone grise qui revient souvent. La règle Google Play sur l’usage abusif des appareils et des réseaux interdit à une application de se mettre à jour en dehors de Google Play, mais cette restriction ne s’applique pas au code exécuté dans une machine virtuelle ou un interpréteur, comme le JavaScript. Le code natif, les nouvelles autorisations et les modules natifs exigent toujours un nouveau bundle via Google Play.

• Le canal fermé reste la voie principale. Un nouveau versionCode dans le canal fermé atteint chaque testeur inscrit via Google Play et apparaît dans l’historique de vos releases.
• Ne touchez pas aux dépendances natives. Mettre à niveau React Native ou un module natif en plein test change bien plus que le bug que vous corrigez. Faites-le avant le test ou après l’accès en production.
• Une map par release. Chaque nouveau build produit une nouvelle source map. Rangez-la avec le code de version, sinon le prochain rapport de plantage de cette version ne pourra pas être décodé.