Test fermé Google Play pour les jeux Unity

Unity ne change pas la règle de Google. Si votre compte Play Console est un compte personnel créé après le 13 novembre 2023, vous devez mener un test fermé avec au moins 12 testeurs inscrits pendant 14 jours sans interruption avant de pouvoir demander l'accès production (aide Play Console).

Ce que Unity change, c'est le build. Votre version de l'éditeur décide si vous pouvez cibler l'API 36, le 64 bits exige IL2CPP, le keystore de débogage fait refuser l'import, et les gros jeux butent sur les limites de taille. Cette page couvre ces points. Pour la règle et chaque écran de la Play Console, commencez par le guide du test fermé Google Play.

Étape 1 : une version de Unity capable de cibler l'API 36

Depuis le 31 août 2026, les nouvelles applications et les mises à jour doivent cibler Android 16 (niveau d'API 36) ou plus. Les applications Wear OS et Android Automotive OS doivent cibler l'API 35, les applications Android TV et Android XR l'API 34 (aide Play Console).

Unity indique quelles versions peuvent cibler quels niveaux d'API. Vérifié le 9 novembre 2026 :

Sur une version corrective plus ancienne, mettez d'abord l'éditeur à jour. Unity 6.6 prend en charge Android 8.0 (niveau d'API 26) et plus : le minimum bouge donc aussi quand vous changez de version.

Étape 2 : régler le niveau d'API cible

Les étapes de Unity (doc Unity) :

1. Ouvrez File > Build Profiles et sélectionnez Android.
2. Sélectionnez Player Settings.
3. Dans Other Settings > Identification, réglez Target API Level au moins sur le niveau exigé par Google Play.

La même section contient Minimum API Level et Bundle Version Code (étape 6). Le guide de l'API cible 36 liste les changements de comportement d'Android 16 à tester après le passage.

Étape 3 : IL2CPP et ARM64

Google Play exige la prise en charge du 64 bits. Dans Unity, ouvrez les Player Settings, puis Other Settings > Configuration, et activez ARM64. Unity ne le permet que si le scripting backend est IL2CPP : quittez Mono d'abord (doc Unity).

Une deuxième exigence sur le code natif arrive. Google indique que les applications qui ciblent l'API 35 ou plus doivent prendre en charge les pages mémoire de 16 Ko sur les appareils 64 bits, et qu'à partir du 1er février 2027 les mises à jour qui ne les prennent pas en charge ne pourront plus être publiées (Android Developers). Unity prend en charge les pages de 16 Ko. Son conseil : mettre l'éditeur à jour vers la dernière version corrective, mettre à jour les plug-ins natifs et les packages qui contiennent des bibliothèques natives, comme Burst, puis recompiler (doc Unity).

Étape 4 : produire un Android App Bundle

Google Play exige des AAB pour les nouvelles applications. Les étapes de Unity (doc Unity) :

1. Dans Player Settings > Publishing Settings, activez Split Application Binary.
2. Dans la fenêtre Build Profiles, sous Platform Settings, activez Build App Bundle (Google Play). L'option n'apparaît que si Export Project est désactivé.
3. Désactivez Development Build. Unity prévient que l'import risque d'échouer sinon.

Si vous exportez plutôt vers Android Studio, activez Export Project, puis Export for App Bundle.

Étape 5 : signer avec votre propre keystore

Sans keystore personnalisé, Unity signe avec un keystore de débogage. La documentation Unity précise que le store refusera les applications signées de cette façon (doc Unity).

1. Dans Player Settings > Publishing Settings, ouvrez le Keystore Manager.
2. Créez un keystore et ajoutez-y une clé avec un alias. Les champs de mot de passe de Unity n'acceptent que les caractères ASCII (doc Unity).
3. De retour dans Publishing Settings, activez Custom Keystore, sélectionnez-le et choisissez l'alias de la clé.

Unity n'enregistre pas les mots de passe du keystore ni de la clé : vous les saisissez à chaque session. Gardez le keystore hors de votre dépôt et sauvegardez-le avec ses deux mots de passe.

Avec la signature d'application Play, Google détient la clé de signature d'application et vous gardez la clé d'importation. Google peut réinitialiser une clé d'importation perdue, mais une clé de signature d'application que vous gérez vous-même ne peut pas l'être si vous la perdez (aide Play Console).

Étape 6 : augmenter le Bundle Version Code à chaque version

Bundle Version Code est un entier qui doit être plus élevé à chaque nouvelle version. Version est la chaîne que voient les joueurs, commune avec iOS (doc Unity). Le maximum de Google Play est 2 100 000 000 (aide Play Console).

Vous publierez des correctifs pendant les 14 jours. Augmentez le nombre de un à chaque fois. La remarque de Unity sur l'ajout de 100000 ou 200000 par architecture ne vaut que si Split APKs by target architecture est activé.

Étape 7 : limites de taille et Play Asset Delivery

La documentation Unity indique que le module de base d'un AAB doit faire moins de 200 Mo (doc Unity). La page de Google sur les tailles, consultée le 9 novembre 2026, indique 500 Mo pour le module de base, 1,5 Go par asset pack, 4 Go pour l'ensemble des modules et des asset packs installés avec l'application, et 30 Go pour les packs à la demande et fast-follow (aide Play Console). Prévoyez avec le chiffre de Unity, le plus bas.

Au-delà, utilisez Play Asset Delivery. Google héberge et distribue les asset packs : pas besoin de votre propre CDN. Toutes les versions de Unity depuis 2021.3 le prennent en charge, mais Unity ne prend pas en charge Play Feature Delivery (doc Unity).

Le ciblage de la compression des textures aide aussi. Il active le découpage du binaire et place les ressources de la première scène dans un asset pack installé avec l'application, appelé UnityTextureCompressionsAssetPack, ce qui allège le module de base (doc Unity).

Étape 8 : vérifier les autorisations ajoutées par Unity et les plug-ins

Unity ajoute des autorisations selon les API qu'appelle votre code C# (doc Unity) :

• Les API de localisation comme LocationService ajoutent ACCESS_FINE_LOCATION.
• WebCamTexture ajoute CAMERA, la classe Microphone ajoute RECORD_AUDIO, Handheld.Vibrate ajoute VIBRATE.
• UnityWebRequest, les sockets et les packages Analytics et Cloud Diagnostics ajoutent INTERNET.

Les plug-ins fusionnent les autorisations de leur propre manifeste pendant l'étape Gradle. Un SDK publicitaire peut apporter com.google.android.gms.permission.AD_ID : le Google Mobile Ads SDK la déclare et elle est fusionnée même si vous ne l'avez jamais écrite (aide Play Console). Déclarez ces données dans votre formulaire Sécurité des données.

Google évalue aussi les autorisations à risque, comme les SMS ou le journal d'appels, sur les canaux de test. Une version fermée active qui exige un formulaire de déclaration des autorisations non rempli vous empêche de publier la moindre modification (aide Play Console).

Internet Access. Unity le règle sur Require par défaut pour les builds de développement. Sur Auto, Unity n'ajoute l'autorisation que si vous utilisez une API réseau (doc Unity). Si votre build de release n'atteint pas votre serveur, passez-le sur Require.

Étape 9 : tester le build de release minifié sur un téléphone

Sous Publishing Settings > Minify, Unity peut réduire le code Java des builds de release. Le code appelé par réflexion est supprimé : un plug-in peut fonctionner en développement et planter en release. Ajoutez des règles de conservation avec Custom Proguard File (doc Unity).

Testez sur de vrais téléphones : Unity ne prend pas en charge les émulateurs Android (doc Unity).

Report Dependencies in App Bundle, dans Publishing Settings, permet à Google Play de vérifier vos packages du Package Manager et de l'Asset Store contre les échecs de certification connus, juste après l'import (doc Unity).

Étape 10 : publier sur le canal de test fermé

Dans la Play Console, allez dans Tester et publier > Tests > Tests fermés, puis Gérer le canal. Créez une version, importez le .aab, ajoutez les testeurs dans l'onglet Testeurs, choisissez les pays et envoyez les modifications pour examen.

Le lien d'inscription (opt-in) n'apparaît qu'une fois l'application à l'état « Publiée », et la première fois il peut mettre plusieurs heures à fonctionner (aide Play Console). S'il manque, voyez où trouver le lien d'inscription. Gardez vos 12 testeurs du test fermé hors du canal interne : Google indique qu'un utilisateur qui active votre test interne ne peut plus recevoir votre test fermé (aide Play Console).

Combien de temps ça prend vraiment

• Premier AAB signé à partir d'un projet Unity qui fonctionne : prévoyez une journée, davantage s'il faut d'abord mettre l'éditeur à jour et passer à IL2CPP.
• Première version fermée : Google peut prendre jusqu'à sept jours, voire plus dans des cas exceptionnels, pour certains comptes (aide Play Console).
• Le test : 14 jours sans interruption avec au moins 12 testeurs inscrits.
• Examen de la demande d'accès production : en général sept jours ou moins (aide Play Console).

Comptez trois à quatre semaines entre votre premier import en test fermé et une publication en production.