Test fermé Google Play pour les apps FlutterFlow

FlutterFlow (sa documentation appelle désormais l'éditeur visuel FlutterFlow Studio) peut déployer sur Google Play sans quitter l'éditeur. Le chemin qu'il documente : un premier envoi sur le canal de test interne, puis une promotion en production (doc FlutterFlow).

Ce chemin saute l'étape que Google impose aux nouveaux comptes personnels. Si votre compte Play Console est personnel et a été créé après le 13 novembre 2023, la production reste désactivée tant que vous n'avez pas mené un test fermé avec au moins 12 testeurs inscrits pendant 14 jours sans interruption et que Google n'a pas approuvé votre demande d'accès production (Aide Play Console). Cette page montre comment insérer un test fermé dans le parcours de FlutterFlow. Pour la règle elle-même, voyez le guide du test fermé.

Les réglages irréversibles

Vérifiez-les avant le premier déploiement :

• Nom du package. FlutterFlow prévient qu'il ne peut plus être changé une fois l'app déployée. Quand vous créez l'app dans la Play Console, Google associe aussi ce nom de package à votre compte pour la vérification des développeurs Android (Android Developers).
• Icône de lancement. Les prérequis de FlutterFlow précisent qu'elle ne peut être ni transparente ni contenir de canal alpha.
• Tâches de configuration de la Play Console. FlutterFlow vous demande de terminer toutes les tâches de la rubrique Set up your app de la Play Console avant de déployer. Les sauter est la cause la plus fréquente de l'erreur de brouillon décrite plus bas.

Relier FlutterFlow à la Play Console

FlutterFlow déploie via un compte de service Google (doc FlutterFlow) :

1. Dans la console Google Cloud, activez l'API Google Play Developer et créez un compte de service avec une clé JSON.
2. Dans la Play Console, allez dans Utilisateurs et autorisations, invitez l'adresse e-mail du compte de service et accordez-lui Edit and delete draft apps, Release to production…, Release apps to testing tracks et Manage testing tracks and edit tester lists.
3. Dans FlutterFlow, ouvrez Settings & Integrations > App Settings > Mobile Deployment et importez le JSON sous Service Account Credentials.

Première version : mettez l'AAB sur la piste de test fermé

Le guide de FlutterFlow indique que, pour le premier déploiement, vous téléchargez l'AAB et l'importez vous-même ; ensuite, FlutterFlow peut gérer les versions (doc FlutterFlow).

1. Dans FlutterFlow, réglez le Google Play Track et cliquez sur Deploy to Play Store.
2. Patientez, cliquez sur Check Build Status, puis téléchargez l'AAB.
3. Dans la Play Console, allez dans Tester et publier > Tests > Tests fermés > Gérer le canal et créez une version avec ce fichier. La page de dépannage de FlutterFlow confirme que le premier envoi manuel peut aller en test interne, fermé, ouvert ou en production (doc FlutterFlow). Choisissez le test fermé.
4. Dans l'onglet Testeurs, ajoutez vos testeurs (liste d'adresses e-mail ou groupe Google), choisissez les pays, enregistrez et envoyez les modifications pour examen.

Si le déploiement de l'étape 1 échoue avec « Package not found » (package introuvable), c'est normal pour un premier déploiement. FlutterFlow le liste comme un symptôme du premier envoi ; l'AAB reste téléchargeable.

Pourquoi ne pas utiliser le canal interne par défaut de FlutterFlow pour les testeurs ? Le test interne ne compte pas pour l'exigence de Google. Et Google indique qu'un utilisateur inscrit à votre test interne ne peut plus recevoir votre test fermé (Aide Play Console). Gardez le test interne pour vos propres appareils. Le guide interne, fermé ou ouvert explique les différents canaux.

Les mises à jour pendant les 14 jours

Vous corrigerez des choses pendant le test. Google le recommande, et le formulaire d'accès production demande ce que vous avez modifié (Aide Play Console).

• FlutterFlow incrémente automatiquement le Build Number (le versionCode Android) à chaque déploiement : inutile de l'augmenter à la main.
• Le guide de FlutterFlow documente les réglages des canaux Internal et Production. Si le menu des canaux de votre projet ne propose pas votre piste de test fermé, téléchargez l'AAB de chaque build et importez-le sur la piste de test fermé dans la Play Console. Ou déployez depuis GitHub avec votre propre pipeline.
• N'envoyez pas un correctif en test interne en espérant que vos testeurs du test fermé le reçoivent. Ils ne reçoivent que ce qui est sur la piste de test fermé (ou un code de version plus élevé en production, que vous n'avez pas encore).

Le keystore, c'est à vous de le sauvegarder

FlutterFlow génère automatiquement un keystore d'importation et signe chaque version avec. Son guide indique que vous pouvez télécharger le keystore avec le bouton orange en forme de clé (doc FlutterFlow). Faites-le avant la première version. Si vous avez déjà publié cette app avec votre propre keystore, activez Upload Keystore dans Advanced Settings et indiquez plutôt l'alias.

Avec la Signature d'application Play, Google peut réinitialiser une clé d'importation perdue (Aide Play Console). Mais la vérification des développeurs peut exiger la preuve que vous possédez la clé de signature d'un package, et la FAQ de Google précise qu'une clé de signature perdue vous empêche d'enregistrer vos packages (FAQ Android Developers). Un keystore téléchargé et sauvegardé vous coûte un clic.

Beaucoup d'apps FlutterFlow utilisent Firebase Auth. Ajoutez dans Firebase le SHA-1 ou le SHA-256 de la clé de signature d'application détenue par Google (Play Console > Protégé avec Play > Distribution sur le Play Store > Accéder à la signature d'application Play). Google indique que les fournisseurs d'API ont besoin de cette empreinte, pas seulement de votre clé d'importation. Sautez cette étape et Google Sign-In peut échouer pour chaque testeur.

API cible 36 : comment vérifier un build FlutterFlow

Depuis le 31 août 2026, les nouvelles apps et les mises à jour doivent cibler le niveau d'API 36 ou une version ultérieure (Aide Play Console). La documentation de FlutterFlow ne publie pas le SDK cible des projets générés : vérifiez le code.

1. Exportez-le (téléchargez le code, poussez-le sur GitHub, ou lancez flutterflow export-code --project <id> --dest <folder> avec la CLI FlutterFlow (doc FlutterFlow)).
2. Ouvrez android/app/build.gradle.kts (ou build.gradle) et cherchez targetSdk.
3. S'il indique flutter.targetSdkVersion, la valeur suit la version de Flutter utilisée pour compiler. Sur la branche stable de Flutter aujourd'hui (3.47), c'est 36 (code source Flutter).

Sur les offres Enterprise, un projet figé sur une version stable de FlutterFlow ne reçoit pas de mises à jour, y compris celles de Flutter, et chaque version stable est maintenue six mois (doc FlutterFlow). Si votre projet est figé, vérifiez le SDK cible avant de lancer les 14 jours. La page Flutter détaille le côté Gradle.

Erreurs de déploiement FlutterFlow et solutions

Avant que les testeurs ouvrent l'app

• Testez d'abord sur un vrai appareil. FlutterFlow en fait un prérequis.
• Si l'app a une 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 (Aide Play Console).
• Gardez courte la liste des fonctionnalités à faire tester. Vous résumerez les retours dans le formulaire de demande d'accès production.

Calendrier

• Compte de service et premier envoi manuel : une soirée, passée surtout dans les écrans de Google Cloud et de la Play Console.
• Premier examen de Google : jusqu'à sept jours, voire plus dans des cas exceptionnels, pour certains nouveaux comptes (Aide Play Console), puis plusieurs heures avant que le lien d'inscription (opt-in) fonctionne.
• 14 jours de test sans interruption, puis un examen de l'accès production qui prend généralement une semaine ou moins (Aide Play Console).

Comptez trois à quatre semaines entre le premier envoi en test fermé et votre premier déploiement en production depuis FlutterFlow.