Test fermé Google Play pour les applications Ionic et Capacitor

Google Play exige la signature d’application Play pour les nouvelles applications. Le keystore que vous créez dans l’assistant d’Android Studio (Create new) ou que vous passez à npx cap build est votre clé d’importation ; Google conserve la clé de signature de l’application, distincte, après votre premier import.

Android Studio recommande une validité d’au moins 25 ans pour une nouvelle clé. Rangez le fichier .jks hors du dossier android/ au cas où vous régénéreriez le projet natif, et sauvegardez-le avec les deux mots de passe. Si la clé d’importation est perdue, vous pouvez demander sa réinitialisation dans la Play Console.

Si vous gardez des options de build dans la configuration Capacitor, n’écrivez pas les mots de passe dans le fichier versionné. La configuration fait partie de votre dépôt.

Capacitor ne lit pas la version dans package.json. Les valeurs que voit Google Play se trouvent dans android/app/build.gradle ; augmentez versionCode avant chaque import :

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). Capacitor définit targetSdkVersion dans android/variables.gradle, et chaque version majeure n’accepte qu’une seule valeur : Capacitor 8 utilise 36, Capacitor 7 utilise 35. Les valeurs personnalisées ne sont pas prises en charge : pour atteindre l’API 36, passez à Capacitor 8 avec vos plugins plutôt que de modifier le nombre.

ext {
    // ...
    targetSdkVersion = 36
}

• Live reload oublié. Un server.url dans la configuration Capacitor fait charger à l’application l’adresse de votre machine de développement. Les testeurs voient un écran blanc. Supprimez-le avant le build de release.
• Ressources web périmées. Générer le bundle dans Android Studio sans lancer npx cap sync android d’abord publie le build web précédent.
• Plugins sur une autre version majeure. Tous les paquets @capacitor/* et plugins communautaires doivent avoir la même version majeure que @capacitor/android. Sinon : erreurs de build natif ou plantages à l’exécution.
• Requêtes en clair. Android bloque par défaut le trafic http:// non chiffré. Les builds de production ne doivent appeler que des API HTTPS.
• Plugins natifs et pages de 16 Ko. Les plugins qui embarquent des bibliothèques .so 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.
• Tester seulement dans le navigateur. Le bouton retour, les autorisations et les liens profonds se comportent autrement dans la WebView Android. Installez le build de release sur un vrai appareil avant l’import.

La plupart des problèmes d’un build release Capacitor se trouvent dans la couche web : les outils du navigateur que vous connaissez déjà sont donc la meilleure porte d’entrée. Dans un build release, ils sont désactivés : webContentsDebuggingEnabled vaut false par défaut, et la journalisation de Capacitor suit loggingBehavior, dont la valeur par défaut est debug, si bien que les builds release restent muets.

1. 1

   Reproduisez sur un build debug

   Lancez l’application sur un téléphone depuis Android Studio, ouvrez chrome://inspect dans Chrome sur votre ordinateur et choisissez la WebView. Vous disposez de la console, du panneau réseau et des points d’arrêt pour votre code web. edge://inspect fonctionne de la même façon dans Edge.

2. 2

   N’inspectez un build release qu’en local

   Si un bug n’apparaît qu’en release, passez temporairement webContentsDebuggingEnabled à true dans un build que vous installez vous-même. N’importez jamais ce build : il rend le contenu web de votre application débogable sur n’importe quel appareil.

3. 3

   Récupérez les plantages natifs dans la Play Console

   Les plantages dans le code Java de Capacitor ou dans les plug-ins 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.

const config: CapacitorConfig = {
  // ...
  android: {
    // Never ship this to Google Play
    webContentsDebuggingEnabled: true,
  },
};

Demandez aux testeurs le modèle de l’appareil, la version d’Android et la version d’Android System WebView. Beaucoup de bugs propres à la WebView dépendent de ce dernier numéro, et tout ce qui est inférieur à android.minWebViewVersion sort de ce que votre application prend en charge.

Une fois votre bundle Ionic / Capacitor 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.

Recompilez l’application web, synchronisez, augmentez versionCode et générez un nouveau bundle signé pour le même canal fermé :

npm run build
npx cap sync android
npx cap open android

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, avec une exception pour le code exécuté dans un interpréteur ou une machine virtuelle, comme le JavaScript dans une WebView. C’est pour cela qu’il existe des services de mise à jour à chaud pour la couche web. Le code natif, les plug-ins et les autorisations exigent toujours un nouveau bundle via Google Play.

Pendant le test fermé, un nouveau versionCode dans le canal fermé reste la voie la plus directe : il est examiné, les testeurs le reçoivent via Google Play et il apparaît dans l’historique des releases. Si vous utilisez aussi un service de mise à jour à chaud, réservez-le aux vrais correctifs et gardez le build web du canal fermé synchronisé avec lui.

• Attention au minimum WebView. android.minWebViewVersion vaut 60 par défaut et ne peut pas descendre sous 55. Les testeurs en difficulté doivent d’abord mettre à jour Android System WebView depuis Google Play.
• Pas de contenu mixte. android.allowMixedContent est désactivé par défaut et n’est pas prévu pour la production. Servez chaque API et chaque ressource en HTTPS, et laissez server.cleartext à sa valeur par défaut false.
• Synchronisez avant chaque build. Chaque correctif nécessite npx cap sync android après le build web, sinon le nouveau bundle contient encore l’ancien JavaScript.