Test fermé Google Play pour les applications Kotlin et Jetpack Compose

Les nouvelles applications doivent utiliser la signature d’application Play : Google conserve la clé de signature de l’application et vous signez chaque import avec une clé d’importation. L’assistant d’Android Studio peut créer le keystore ; il recommande une validité d’au moins 25 ans.

Pour signer en ligne de commande ou en CI, gardez les identifiants dans un fichier keystore.properties hors du contrôle de version et lisez-le dans app/build.gradle.kts :

storePassword=myStorePassword
keyPassword=myKeyPassword
keyAlias=upload
storeFile=/path/to/upload-keystore.jks

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

val keystoreProperties = Properties().apply {
    load(FileInputStream(rootProject.file("keystore.properties")))
}

android {
    signingConfigs {
        create("release") {
            keyAlias = keystoreProperties["keyAlias"] as String
            keyPassword = keystoreProperties["keyPassword"] as String
            storeFile = file(keystoreProperties["storeFile"] as String)
            storePassword = keystoreProperties["storePassword"] as String
        }
    }
    buildTypes {
        release {
            isMinifyEnabled = true
            proguardFiles(getDefaultProguardFile("proguard-android-optimize.txt"), "proguard-rules.pro")
            signingConfig = signingConfigs.getByName("release")
        }
    }
}

Sauvegardez le keystore et les deux mots de passe. Si la clé d’importation est perdue ou divulguée, créez-en une nouvelle et demandez sa réinitialisation dans la Play Console ; la clé de signature de l’application reste la même.

versionCode doit dépasser celui de tout bundle déjà importé, quel que soit le canal ; versionName est ce que voient les utilisateurs. Les deux se trouvent dans defaultConfig, à côté des niveaux de SDK :

android {
    compileSdk = 36
    defaultConfig {
        applicationId = "com.yourcompany.app"
        targetSdk = 36
        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). Relever targetSdk active de nouveaux comportements de la plateforme. Les applications qui ciblent Android 15 ou plus s’affichent bord à bord, et sous Android 16 la désactivation ne fonctionne plus : vérifiez avant le test que vos écrans Compose gèrent correctement les window insets.

• R8 supprime ce dont la réflexion a besoin. Avec isMinifyEnabled = true, les modèles de sérialisation, les classes Retrofit ou Gson et certaines configurations d’injection de dépendances peuvent casser uniquement en release. Ajoutez des règles dans proguard-rules.pro et testez la variante release.
• Surprises du bord à bord. Le contenu dessiné sous la barre d’état et la barre de navigation masque des boutons. Utilisez le padding de Scaffold ou les modificateurs WindowInsets sur chaque écran que verront les testeurs.
• Release débogable. Avec isDebuggable = true dans le type de build release, la Play Console refuse le bundle.
• Secrets de signature dans git. Les mots de passe écrits directement dans build.gradle.kts finissent dans votre dépôt. Gardez-les dans keystore.properties ou dans les secrets de la CI.
• Bibliothèques natives et pages de 16 Ko. Les applications 100 % Kotlin prennent déjà en charge les pages mémoire de 16 Ko, mais le code NDK et les bibliothèques qui embarquent des fichiers .so doivent être recompilés ou mis à jour. La Play Console le signale et, à partir du 1er février 2027, les mises à jour non compatibles ne pourront plus être publiées.
• Ne tester que le debug. Les testeurs reçoivent la variante release. Lancez-la sur au moins une version récente d’Android avant chaque import.

Les testeurs n’exécutent que la variante release : leurs plantages viennent donc d’un code optimisé par R8, aux classes et méthodes renommées. Le build écrit le mapping qui annule cela dans app/build/outputs/mapping/release/mapping.txt, l’écrase à chaque build et l’intègre aussi au .aab.

1. 1

   Laissez la Play Console désobscurcir

   Avec le plug-in Android Gradle 4.1 ou plus récent, la Play Console récupère le fichier de mapping dans le bundle importé. Les plantages sous Surveiller et améliorer → Android Vitals → Plantages et ANR affichent alors vos vrais noms de classes et de méthodes.

2. 2

   Gardez une copie par release

   Archivez mapping.txt avec chaque code de version importé. Vous en avez besoin pour les traces que les testeurs collent dans leurs rapports et pour tout outil de plantage hors de Google Play.

3. 3

   Faites un retrace à la main

   Lancez retrace depuis les outils de ligne de commande avec le mapping et un fichier contenant la trace. Les versions récentes d’Android Studio font aussi le retrace automatiquement dans Logcat.

$ANDROID_HOME/cmdline-tools/latest/bin/retrace \
  app/build/outputs/mapping/release/mapping.txt trace.txt

Vous utilisez le NDK ? Définissez debugSymbolLevel sur le type de build release. SYMBOL_TABLE donne les noms de fonctions dans la Play Console, FULL ajoute fichiers et numéros de ligne. Pour les app bundles, les symboles natifs sont inclus et importés automatiquement.

android {
    buildTypes {
        release {
            ndk {
                debugSymbolLevel = "FULL" // or "SYMBOL_TABLE"
            }
        }
    }
}

Quand R8 conserve du code inattendu, ou supprime du code dont la réflexion a besoin, -whyareyoukeeping montre le chemin d’une classe conservée vers un point d’entrée, et configuration.txt à côté du mapping liste toutes les règles fusionnées.

Une fois votre bundle Kotlin / Jetpack Compose 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.

Augmentez versionCode, recompilez le bundle (Gradle ou l’assistant d’Android Studio) et importez-le dans le même canal fermé.

./gradlew bundleRelease

Pour installer le bundle que vous allez importer, générez-en des APK propres à l’appareil avec bundletool, signés avec votre clé d’importation. C’est ce qui se rapproche le plus de ce que livre Google Play, y compris le découpage par densité d’écran, langue et ABI :

bundletool build-apks --connected-device \
  --bundle=app/build/outputs/bundle/release/app-release.aab --output=app.apks \
  --ks=/path/to/upload-keystore.jks --ks-key-alias=upload
bundletool install-apks --apks=app.apks

Pour des vérifications rapides par votre équipe, le partage interne d’applications de la Play Console accepte n’importe quel code de version et fournit un lien de téléchargement pour 100 personnes au maximum. Ces imports ne peuvent pas faire partie d’un canal de test et ne remplacent pas le test fermé : vos 12 testeurs installent toujours depuis le canal fermé.