Test fermé Google Play pour les applications Flutter

La signature d’application Play est obligatoire pour les nouvelles applications : Google conserve la clé de signature de l’application et vous signez chaque import avec votre propre clé d’importation. Si vous la perdez, vous pouvez demander à Google de la réinitialiser ; votre application n’est pas perdue pour autant. Créez la clé avec keytool :

keytool -genkey -v -keystore ~/upload-keystore.jks -keyalg RSA \
        -storetype JKS -keysize 2048 -validity 10000 -alias upload

Créez ensuite android/key.properties avec les mots de passe et le chemin du keystore. Ce fichier et le .jks ne doivent pas entrer dans le contrôle de version :

storePassword=<keystore password>
keyPassword=<key password>
keyAlias=upload
storeFile=/Users/<you>/upload-keystore.jks

Chargez le fichier dans android/app/build.gradle.kts et associez le type de build release à la nouvelle configuration de signature :

import java.util.Properties
import java.io.FileInputStream

val keystoreProperties = Properties()
val keystorePropertiesFile = rootProject.file("key.properties")
if (keystorePropertiesFile.exists()) {
    keystoreProperties.load(FileInputStream(keystorePropertiesFile))
}

android {
    // ...
    signingConfigs {
        create("release") {
            keyAlias = keystoreProperties.getProperty("keyAlias")
            keyPassword = keystoreProperties.getProperty("keyPassword")
            storeFile = keystoreProperties.getProperty("storeFile")?.let { file(it) }
            storePassword = keystoreProperties.getProperty("storePassword")
        }
    }
    buildTypes {
        release {
            signingConfig = signingConfigs.getByName("release")
        }
    }
}

Les anciens projets utilisent build.gradle (Groovy) au lieu de build.gradle.kts ; les champs sont les mêmes. Lancez flutter clean après avoir modifié les fichiers Gradle.

Chaque import exige un code de version supérieur à tous les bundles déjà importés, quel que soit le canal. Avec Flutter, c’est le nombre après le + dans pubspec.yaml :

version: 1.0.0+1

1.0.0 devient le nom de version visible par les utilisateurs et 1 le code de version. Passez à +2, +3, etc., ou remplacez les deux au moment du build avec --build-name et --build-number.

Depuis le 31 août 2026, les nouvelles applications et mises à jour doivent cibler Android 16 (niveau d’API 36) ou plus. Le fichier Gradle utilise targetSdk = flutter.targetSdkVersion : mettre Flutter à jour est donc la façon habituelle de l’augmenter. Si votre version de Flutter est plus ancienne, indiquez targetSdk = 36 vous-même et testez sur une version récente d’Android avant l’import.

• Numéro de build réutilisé. La Play Console refuse un bundle dont le code de version a déjà servi. Augmentez le +N de pubspec.yaml avant chaque build destiné à l’import.
• Obfuscation sans symboles. --obfuscate ne fonctionne qu’avec --split-debug-info. Conservez le dossier de symboles de chaque build importé ; sans lui, les traces de plantage des testeurs sont illisibles.
• Mauvais flavor. Avec des flavors, on importe vite le build de staging avec ses endpoints de staging. Les testeurs signalent alors des bugs que les utilisateurs de production ne verraient jamais.
• Pas de réseau en release. Sans l’autorisation INTERNET dans le manifeste principal, l’application marche en debug et échoue en silence chez les testeurs.
• Bundle signé en debug. Si le type de build release utilise encore la configuration de signature debug, la Play Console refuse l’import.
• Plugins au code natif ancien. 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. Mettez à jour plugins et SDK Flutter avant le test, pas au milieu.

flutter build appbundle --obfuscate --split-debug-info=build/symbols

Les testeurs collent des traces de pile dans leurs rapports de bug, et la Play Console regroupe les plantages sous Surveiller et améliorer → Android Vitals → Plantages et ANR. Une trace Flutter a deux moitiés : la partie Dart, que --obfuscate transforme en noms courts et sans signification, et la partie Android, que R8 réduit. Flutter active toujours la réduction du code en release, prévoyez donc les deux.

1. 1

   Conservez les symboles Dart

   Un build réalisé avec --split-debug-info écrit un fichier de symboles par architecture, par exemple app.android-arm64.symbols. Rangez le dossier avec le code de version correspondant : le fichier d’un autre build ne peut pas décoder la trace.

2. 2

   Décodez les traces Dart

   Enregistrez la trace dans un fichier et passez-la à flutter symbolize avec le fichier de symboles de l’architecture de l’appareil. La plupart des téléphones actuels sont en arm64.

3. 3

   Laissez la Play Console gérer la partie Java

   Avec le plug-in Android Gradle 4.1 ou plus récent, le fichier de mapping R8 voyage dans le .aab : la Play Console désobscurcit les lignes Java et Kotlin des plug-ins sans import séparé.

flutter symbolize -i crash.txt -d build/symbols/app.android-arm64.symbols

L’obscurcissement renomme les symboles ; il ne chiffre rien et n’est pas un endroit pour des secrets. Le code qui compare runtimeType.toString() à un nom de classe casse une fois obscurci, alors que les noms d’enum restent lisibles.

Une fois votre bundle Flutter 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 Flutter : augmentez le numéro de build, recompilez et importez le nouveau bundle dans le même canal fermé.

flutter build appbundle --build-name=1.0.1 --build-number=2

Avant chaque import, lancez le build release sur un vrai téléphone. flutter install installe l’APK release sur un appareil connecté et révèle en quelques minutes les autorisations manquantes, les mauvais flavors et les plantages propres à la release :

flutter build apk
flutter install

Pour vérifier le bundle exact que vous allez importer, transformez-le en APK d’appareil avec l’outil bundletool de Google, ou importez-le dans le canal fermé et installez-le depuis Google Play avec un compte testeur. Vous testez ainsi ce que reçoivent les testeurs, y compris les APK fractionnés par appareil de Play.

• Une modification ciblée par mise à jour. De petites releases montrent clairement quel correctif répond à quel rapport de testeur et fournissent des exemples concrets pour le formulaire d’accès en production.
• Ne changez pas de version de Flutter en plein test, sauf si un bug signalé par les testeurs l’exige. Une mise à niveau du SDK modifie en même temps le moteur, le code natif de chaque plug-in et parfois targetSdk.
• Laissez du temps pour l’examen. Chaque nouvelle release du canal fermé est envoyée à Google avant d’arriver chez les testeurs : ne gardez pas votre dernier correctif pour le dernier jour.