Test fermé Google Play pour les jeux Unity

Sans votre propre keystore, Unity signe avec une clé de debug, et la Play Console refuse les bundles signés en debug. Créez-en un dans l’éditeur :

1. 1

   Ouvrir le Keystore Manager

   Allez dans Edit → Project Settings → Player → Android → Publishing Settings et ouvrez Keystore Manager.

2. 2

   Créer le keystore

   Choisissez Keystore → Create New, enregistrez le fichier (n’importe où ou dans votre dossier dédié aux keystores), définissez un mot de passe et ajoutez une clé avec un alias.

3. 3

   L’utiliser pour les builds

   De retour dans Publishing Settings, sélectionnez le keystore et l’alias de la clé, puis saisissez les mots de passe.

Ce keystore est votre clé d’importation. Au premier import, la Play Console configure la signature d’application Play et Google conserve la clé de signature de l’application. Sauvegardez le fichier et les deux mots de passe hors du projet ; une clé d’importation perdue impose une demande de réinitialisation dans la Play Console.

Dans Player → Other Settings → Identification, Version est ce que voient les joueurs et Bundle Version Code l’entier que Google compare. Augmentez le Bundle Version Code avant chaque build importé ; la Play Console refuse les codes réutilisés.

Juste à côté se trouve Target API Level. Depuis le 31 août 2026, les nouvelles applications et mises à jour doivent cibler Android 16 (niveau d’API 36). En mode automatique, Unity utilise le SDK le plus élevé installé : vérifiez qu’il vaut au moins 36. Les anciennes versions de l’éditeur peuvent ne pas prendre en charge le niveau le plus récent ; mettez alors Unity à jour avant le test, pas pendant.

• Build Mono. Mono ne peut pas produire d’ARM64. La Play Console signale alors que la release ne respecte pas l’exigence 64 bits. Passez à IL2CPP avec ARM64.
• Development Build oublié. Les builds de développement sont plus lents, affichent un filigrane de développement et peuvent être marqués débogables, ce que la Play Console refuse.
• Anciens SDK de pub et d’analytics. Des SDK tiers obsolètes apportent d’anciennes bibliothèques natives et autorisations. Mettez-les à jour avant le test : la Play Console signale les bibliothèques qui ne prennent pas en charge les pages mémoire de 16 Ko et, à partir du 1er février 2027, les mises à jour non compatibles ne pourront plus être publiées.
• Bundle trop volumineux. Si l’import échoue à cause de la taille, activez Split Application Binary pour qu’Unity place les ressources dans des packs Play Asset Delivery plutôt que dans le module de base.
• Minify casse les plugins. La minification en release peut supprimer des classes Java que les plugins chargent par leur nom. Ajoutez des règles de conservation ou testez la release minifiée sur un appareil avant l’import.
• Code de version oublié. Le second import avec le même Bundle Version Code échoue. Automatisez l’incrément ou ajoutez-le à votre checklist de release.

Quand un jeu Unity plante sur le téléphone d’un testeur, la trace pointe dans libil2cpp, libunity ou libmain. Sans symboles, la Play Console n’affiche que des adresses brutes, et Google Play ne symbolise pas les plantages reçus avant l’import des symboles. Configurez cela avant la première release fermée, pas après le premier plantage.

1. 1

   Activez les symboles

   Dans File → Build Profiles → Android, réglez Debug Symbols sur Public. Les symboles publics ne contiennent que la table des symboles, ce qui suffit pour des noms de fonctions lisibles et garde un fichier léger. Debugging ajoute toutes les informations de débogage pour brancher un débogueur natif en local.

2. 2

   Choisissez comment ils arrivent chez Google

   Choisissez .zip pour obtenir un paquet nommé par exemple MyApp-0.1-v100-IL2CPP.symbols.zip que vous importez vous-même, ou intégrez les symboles au bundle pour qu’ils partent avec le .aab. Dans un script de build, l’extrait ci-dessous fait la seconde option.

3. 3

   Associez symboles et versions

   Les symboles appartiennent à un seul Bundle Version Code. Si vous importez le zip à la main, faites-le dans l’explorateur d’app bundles de la Play Console, onglet Téléchargements de cette version, avant que les testeurs ne l’installent.

// Public symbols, embedded in the .aab so they upload with it
UserBuildSettings.DebugSymbols.level = DebugSymbolLevel.SymbolTable;
UserBuildSettings.DebugSymbols.format = DebugSymbolFormat.IncludeInBundle;

Si un plug-in natif fournit un fichier de symboles séparé, sélectionnez ce fichier dans l’Inspector et réglez Shared Library Type sur Symbol avec le bon CPU. Il doit porter le même nom que la bibliothèque et se trouver dans un dossier à part.

Une fois votre bundle Unity 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 Unity : augmentez Bundle Version Code, recompilez le .aab et importez-le dans le même canal fermé. Un petit correctif publié en cours de test suffit.

Sur vos propres appareils, Build and Run installe le jeu sur le téléphone choisi dans Run Device ; une fois le chemin de sortie défini, Ctrl+B (macOS : Cmd+B) recommence. L’application patching de Unity raccourcit les builds debug sur votre appareil, mais ne livre rien aux testeurs : il leur faut toujours un nouveau .aab dans le canal fermé.

• Les mots de passe ne sont pas enregistrés. Unity ne stocke pas les mots de passe du keystore et de la clé sur le disque : vous les saisissez à nouveau après chaque redémarrage de l’Editor. Pour des builds CI reproductibles, définissez-les dans le script de build de l’Editor, à côté de l’incrément du code de version vu dans la section build.
• Surveillez la taille. Google Play limite le module de base à 500 Mo de téléchargement compressé. Les jeux plus lourds ont besoin de packs d’éléments via Play Asset Delivery ; modules et packs install-time peuvent atteindre ensemble 4 Go.
• Recompilez après les mises à jour natives. L’Editor affiche un avertissement au build pour chaque .so aligné sur 4 Ko au lieu de 16 Ko. Passez à la dernière version corrective de votre Editor et des paquets natifs comme Burst, puis recompilez avant le prochain import.
• Gardez une version d’Editor stable. Changer de version de Unity en plein test modifie les bibliothèques du moteur que lancent les testeurs. Figez la version pendant les 14 jours, sauf si un plantage impose une mise à jour.