BaronCyrus/ship-google-play

Google Play : du compte développeur à la soumission

Objectif : pousser d'abord une version test fermé en « En cours d'examen » (validée le jour même lors des tests), puis remplir les exigences de testeurs pour les comptes personnels, et enfin pousser la version production en « En cours d'examen ».

Prérequis : vérifier que les étapes 1 à 4 de ship-my-game sont terminées (fichier de progression, chaîne, bilan, navigateur). Sinon, les lire d'abord. La progression de cette chaîne est écrite dans la section ## google-play du fichier de progression.

Avant de commencer, demander ces cinq choses à l'utilisateur, inscrire les réponses dans le fichier de progression [Test : liste de vérification] :

1. A-t-il un compte développeur Play ? Personnel ou organisation ? Approximativement quand a-t-il été créé ?
2. Dans quel pays/région se trouve l'utilisateur ? Cela détermine si le compte commerçant peut percevoir des paiements officiel.
3. Comment compte-t-il générer des revenus : publicité, achats intégrés, téléchargement payant, ou pas de revenus ? Cela influence les informations personnelles divulguées et la déclaration de statut de commerçant.
4. À quelle URL HTTPS publique se trouve la politique de confidentialité ? Quelle adresse e-mail de contact sera affichée sur le store ?
5. A-t-il un compte AdMob ? Il est recommandé d'utiliser le même compte Google que pour le compte développeur Play.

Ensuite, informer l'utilisateur de trois choses :

1. Seuil de test : pour les comptes personnels créés après le 13/11/2023, il faut au moins 12 testeurs réels pendant 14 jours consécutifs en test fermé avant de demander la version production (examen généralement sous 7 jours) officiel. Donc du test fermé validé à la production, il faut au moins deux semaines.

2. Informations publiques :

   • Le compte personnel affiche le nom légal complet, le pays et l'e-mail du développeur ;
   • Dès qu'il génère des revenus sur Google Play (applications payantes, achats intégrés), l'adresse complète est rendue publique ;
   • Les comptes personnels déclarés comme « commerçants » affichent également le téléphone et l'adresse.

   Avant l'inscription, expliquer tout cela dans la section 1 de onboarding.md.

3. Téléchargement AAB : un AAB fait généralement quelques dizaines de Mo, mais l'outil navigateur ne gère que 10 Mo à la fois. Donc le premier AAB doit être glissé par l'utilisateur dans la page. Ensuite, on peut utiliser l'API Developer (non testée dans ce dépôt), voir automation.md.

Tâches humaines

Tâche	Phase
Inscription : payer 25 $ US, pièce d'identité, code de vérification e-mail/téléphone, vérification sur appareil Android (scanner le QR code dans la console Play), déclaration de statut de commerçant	P1
Accepter : Contrat de distribution pour les développeurs ; déclarations « Politique du programme pour les développeurs » et « Lois américaines sur les exportations » lors de la création de l'application ; conditions d'utilisation IARC ; conditions de PGS et Google Cloud (en cliquant sur « Utiliser ») ; « Politique relative aux données utilisateur des services Google API »	P1, P3, P6
Glisser l'AAB dans la zone de téléchargement de la page web	P4, puis à chaque mise à jour (hors API)
« Soumettre N modifications pour examen » : cliquer vous-même après que l'utilisateur dit « Soumettre » ; si le système d'autorisations bloque, l'utilisateur clique	P4, P7
Captcha lors de la création d'un groupe Google ; publier et s'entraider sur Reddit, etc. ; rejoindre le test avec son propre compte	P5
Vérifier le son, la connexion PGS et le ressenti général sur un vrai appareil	P2, P6
« Publier l'application » sur l'écran de consentement OAuth, « Publier le projet de jeu » pour PGS	P6
Inscription AdMob : pays, conditions, captcha, informations de paiement et fiscales	P6
Accepter de publier la politique de confidentialité et app-ads.txt sur le site de l'utilisateur ; si l'hébergement est payant, l'utilisateur décide	P2, P6
Paiements : pièce d'identité, code PIN, mode de paiement et informations fiscales américaines pour AdMob ; profil de paiement commerçant et compte bancaire pour Play	Après publication

Exigences techniques

L'étape 3 de ship-my-game liste les écarts selon ce tableau. Détails dans references/build.md.

Élément	Exigence	Référence
Unity	API cible 36 nécessite 6000.0.46f1+ ou 2022.3.62f1+ ; pages 16 Ko nécessitent 6000.0.38f1+ ou 2022.3.56f1+, Burst 1.8.21+. Testé avec 6000.6.5f1	Officiel ; [Test]
Module	Android Build Support (incluant OpenJDK, SDK, NDK)	—
targetSdk	36 (à partir du 31/08/2026 ; la date limite reportée au 01/11/2026 est dépassée). minSdk ≥ 24, testé avec 26	Officiel ; [Test]
Architecture et format	IL2CPP, ARM64 + ARMv7, AAB ; tables de symboles intégrées dans l'AAB	[Test], défini par scripts/ShipAndroidBuild.cs
Pages mémoire 16 Ko	Les paquets contenant des bibliothèques natives (Unity en contient toujours) doivent être alignés sur 16 Ko ; vérifier après construction	Officiel
Signature	Clé de téléchargement générée par scripts/make_upload_keystore.sh, placée en dehors du projet ; clé de signature d'application gérée par Google	[Test]
Son	Chaque scène lancée doit avoir un et un seul AudioListener	[Test-Échec] Deux jeux ont été publiés sans son à cause de cela
Publicité	Pendant le test fermé, utiliser exclusivement les ID de test Google ; masquer les entrées si aucune annonce n'est reçue	[Test]
Achats intégrés	Unity IAP ≥ 4.14.0 ou 5.x (bibliothèque Play Billing ≥ 8)	Officiel
Politique de confidentialité	Page web publique HTTPS, lien dans la console Play et dans le jeu ; modèle templates/privacy-policy.en.html	Officiel ; [Test]
Autorisations sensibles	Le manifeste fusionné ne doit pas contenir d'autorisations inutilisées pour photos, vidéos, contacts, localisation, etc.	Officiel

Phases

Les chemins relatifs dans les commandes et liens (scripts/…, ../ship-my-game/…) partent du répertoire de cette compétence. Les chemins dans la console Play utilisent le texte original de l'interface en français.

P1 Compte (si déjà existant, passer directement à la vérification des critères de complétude)

1. Ouvrir https://play.google.com/console, lire la page pour déterminer s'il y a un compte développeur, personnel ou organisation.
2. Pas de compte : expliquer d'abord la section 1 de onboarding.md « Quelles informations seront divulguées », puis guider l'utilisateur dans l'inscription après son accord. Paiement, pièce d'identité, codes de vérification, vérification de l'appareil sont faits par l'utilisateur Officiel.
3. Statut de commerçant : doit être déclaré lors de la création du nouveau compte (« Gérer le compte → Détails du compte → À propos de vous ») ; pour les comptes existants, date limite au 01/02/2027. L'utilisateur décide honnêtement ; expliquer clairement les critères et conséquences Officiel.
4. Dans « Page d'accueil », nettoyer toutes les tâches de vérification et confirmer le statut « Vérification du développeur Android » (le nom du paquet est automatiquement enregistré lors de la création de l'application) Officiel.

Critères de complétude :

• Aucune tâche de vérification en attente sur la page d'accueil.
• Le fichier de progression indique le type de compte, la date d'inscription (pour déterminer si la règle 12 × 14 jours s'applique), et le statut de commerçant.

P2 Projet, clé de téléchargement, premier AAB

1. Modifier le projet selon les « Exigences techniques » : copier scripts/ShipAndroidBuild.cs dans Assets/Editor/, vérifier l'AudioListener dans chaque scène.
2. Générer la clé de téléchargement : bash scripts/make_upload_keystore.sh <nom_du_paquet>, puis demander à l'utilisateur de sauvegarder ~/.shipmygame/keys/<nom_du_paquet>/ [Test].
3. Construire : ../ship-my-game/scripts/unity_build.sh <répertoire_du_projet> Android ShipAndroidBuild.Aab release -shipVersion 1.0.0 -shipVersionCode 1.
   • [Test] : Ce script a déjà produit un APK de débogage sur un projet vide ; un script de construction similaire a produit des AAB signés sur deux jeux.
4. Auto-vérification : utiliser bundletool pour examiner le manifeste (targetSdk 36, ID App de test pour les annonces), confirmer que les symboles sont intégrés dans l'AAB, vérifier l'alignement 16 Ko. Voir section 4 de build.md.
5. Construire un APK de débogage avec ShipAndroidBuild.Apk, demander à l'utilisateur de l'installer sur son téléphone et de confirmer qu'il y a du son [Test : l'émulateur ne permet pas de tester le son].
6. Générer la politique de confidentialité à partir de templates/privacy-policy.en.html : remplacer tous les {{placeholders}}, supprimer les sections AdMob, PGS, achats intégrés inutilisées. Après accord de l'utilisateur, publier sur une URL HTTPS publique, vérifier avec curl qu'elle renvoie 200 [Test].

Critères de complétude :

• Un AAB signé existe, avec versionCode et résultats d'auto-vérification enregistrés dans le fichier de progression.
• L'utilisateur a confirmé le son sur un vrai appareil.
• L'URL de la politique de confidentialité renvoie 200.

P3 Création de l'application, contenu de l'application, fiche Store

1. « Page d'accueil → Créer une application » : remplir le nom, le nom du paquet (d'abord cliquer sur « Vérifier la disponibilité »), la langue par défaut, le type (jeu), gratuit ou payant ; les deux déclarations sont cochées par l'utilisateur. Détails champ par champ dans la section 1 de console.md [Test].
2. Remplir les 11 éléments du centre d'information « Configurer le jeu » un par un : politique de confidentialité, informations de connexion, publicité, classification du contenu, public cible, sécurité des données, application gouvernementale, produits et services financiers, santé, catégorie et coordonnées, fiche du Store. Réponses dans la section 2 de console.md [Test].
3. « Surveillance et amélioration → Politiques et programmes → Contenu de l'application » : effacer toutes les « Déclarations commencées », surtout « ID de publicité ». Il ne fait pas partie des 11 éléments ; s'il n'est pas rempli, la soumission sera bloquée [Test-Échec → Réparé].
4. « Store → Paramètres du Store » : catégorie, jusqu'à 5 tags, coordonnées (le site web doit utiliser le domaine où se trouve app-ads.txt) [Test].
5. « Store → Fiche du Store » : texte, icône, grande photo en haut, captures d'écran, déclaration sur les ressources IA. Pour les langues multiples, utiliser « Importer les traductions avec l'IA », puis vérifier langue par langue. Voir listing.md [Test].

Critères de complétude :

• Le bloc « Configurer le jeu » du centre d'information a disparu.
• Aucun élément en attente dans « Contenu de l'application ».
• Le statut de la fiche Store est « Prêt à soumettre », les fichiers sources des ressources sont dans publish/google-play/.

P4 Première publication du test fermé (passerelle de soumission)

1. « Test et publication → Test → Test fermé » (canal par défaut « Test fermé - Alpha ») :

   • Pays/régions : sélectionner « Tous » ;
   • Testeurs : choisir Groupe Google (recommandé) ou liste de diffusion, un seul des deux ;
   • Remplir l'e-mail de feedback.

   Voir section 5 de console.md [Test].

2. « Créer une nouvelle version » : d'abord remplir le nom de la version et les notes de version multilingues, cliquer sur « Enregistrer comme brouillon ». Ensuite demander à l'utilisateur de glisser l'AAB dans la zone de téléchargement, vous interrogez la page jusqu'à voir apparaître une entrée comme « 1 (1.0.0) » [Test].

3. « Suivant » → Lire « Afficher les détails de vérification » → « Enregistrer » → « Aperçu de la version », attendre la fin de la vérification rapide (maximum environ 14 minutes), signaler les problèmes d'abord [Test].

4. Lister le contenu pour l'utilisateur selon la passerelle de soumission. Après que l'utilisateur dit « Soumettre », cliquer sur « Soumettre N modifications pour examen » → « Soumettre les modifications pour examen » ; si le système d'autorisations bloque, demander à l'utilisateur de cliquer. Détails dans la section 1 de review.md [Test].

Critères de complétude :

• L'aperçu de la version affiche « Modifications en cours d'examen ».
• Le fichier de progression enregistre l'heure de soumission et la durée estimée (testée entre 10 et 42 minutes, officiellement généralement sous 7 jours), ainsi que l'endroit pour voir le résultat (« Aperçu de la version »).

P5 Recrutement des testeurs, attendre 14 jours (compte personnel ; peut être parallèle à P6)

1. Après validation, aller dans l'onglet « Testeurs », prendre les deux liens d'invitation dans l'attribut aria-label du bouton de copie [Test].
2. Rédiger le message de recrutement avec templates/testers-recruitment.md. Le captcha final lors de la création du groupe Google est fait par l'utilisateur ; les publications sur les communautés sont faites par l'utilisateur [Test]. Voir section 2 de review.md.
3. Lire chaque jour la carte du centre d'information « Demander l'autorisation de publication en production » : « Actuellement N testeurs ont participé pendant M jours consécutifs » [Test : texte exact de la carte].
4. Envoyer des mises à jour selon les retours : incrémenter versionCode de 1, suivre les étapes 2 à 4 de P4, ou utiliser l'API de automation.md. Regrouper les modifications en une seule soumission, car une nouvelle soumission annule l'examen en cours [Test].
5. Enregistrer les retours de « Surveillance et amélioration → Évaluations et avis → Retours des testeurs » et les corrections correspondantes dans le fichier de progression, pour le questionnaire de P7 Officiel.

Critères de complétude : les deux conditions « Au moins 12 testeurs » et « Au moins 14 jours » sont cochées sur la carte ; le fichier de progression contient les retours et les corrections.

P6 Capacités de la plateforme (parallèle à P5)

1. Services Google Play :

   • Console : configuration, écran de consentement OAuth, identifiants (tous les certificats SHA-1 pour la signature de l'application doivent être créés), succès (au moins 10), classements, testeurs ;
   • Unity : scripts/ShipPgsSetup.cs et scripts/ShipPlayGames.cs ;
   • « Publier l'application » et « Publier le projet de jeu » sont cliqués par l'utilisateur.

   Voir section 1 de capabilities.md [Test : configuration console].

2. AdMob :

   • Créer l'application et les unités publicitaires, scripts/ShipAds.cs (consentement UMP → initialisation → récompense, interstitiel, bannière) ;
   • Publier le message GDPR, préparer app-ads.txt ;
   • Utiliser les ID de test pendant la phase de test, associer au Store uniquement après publication.

   Voir section 2 de capabilities.md [Test : configuration console].

3. Avis in-app, mises à jour in-app : scripts/ShipPlayReview.cs ; achats intégrés : Unity IAP. Voir sections 3 et 4 de capabilities.md [Officiel].

4. Chaque fois qu'une capacité est intégrée, mettre à jour simultanément la déclaration de sécurité des données et la politique de confidentialité, et les soumettre avec la version suivante (étapes 2 à 4 de P4) [Test].

Critères de complétude :

• Chaque capacité intégrée est vérifiée par l'utilisateur sur un vrai appareil, installé depuis le canal de test.
• La configuration PGS est publiée ; la déclaration de sécurité des données et la politique de confidentialité sont à jour avec les fonctionnalités.
• Les ID de publicité réels sont uniquement enregistrés dans le fichier de progression, pas inclus dans les paquets de test.

P7 Demander la publication en production et publier la version production (passerelle de soumission)

1. Une fois les trois conditions de la carte cochées, d'abord consulter les données de test sur les pages listées dans le modèle, puis rédiger les trois parties du questionnaire avec templates/production-access-answers.md (9 questions au total, chaque réponse texte max 300 caractères), et demander à l'utilisateur de confirmer une par une [Test].
2. Lister le contenu pour l'utilisateur selon la passerelle de soumission : réponses au questionnaire, nombre de testeurs et jours, résultat estimé sous 7 jours. Après que l'utilisateur dit « Soumettre », dans « Centre d'information → Demander l'autorisation de publication en production », cliquer sur « Demander la publication en production », cliquer sur « Suivant » pour les deux premières étapes, puis sur « Appliquer » pour la dernière. La soumission est réussie seulement quand la page affiche « Nous avons bien reçu votre demande d'autorisation de publication en production » [Test]. Enregistrer l'heure de soumission dans le fichier de progression ; le résultat se voit par e-mail et sur la carte du centre d'information.
3. Après approbation (notification par e-mail au propriétaire du compte), préparer la version production selon la section 6 de review.md :
   • Remplacer les ID de test par les ID de publicité réels et l'ID App, incrémenter versionCode de 1 (le paquet peut être préparé en attendant le résultat ; ce paquet sera utilisé uniquement pour la version production) ;
   • Publier d'abord la configuration PGS, attendre au moins 2 heures avant de publier le jeu ;
   • « Test et publication → Production → 'Créer une nouvelle version' ». 
4. Repasser par la passerelle de soumission, soumettre la version production, confirmer sur la page qu'elle est en « En cours d'examen ».

Critères de complétude :

• Dans l'aperçu de la version, l'entrée de la version production apparaît sous « Modifications en cours d'examen ».
• Le fichier de progression enregistre l'heure de soumission, la durée estimée et l'endroit pour voir le résultat (aperçu de la version, e-mail).

Période d'attente et après publication

• Attente de l'examen du test fermé (testé : quelques dizaines de minutes) : pendant ce temps, préparer les ressources du Store, la configuration PGS et AdMob.
• Attente des 14 jours : chaque jour, consulter le nombre de testeurs et les jours sur la carte ; envoyer 1 à 2 mises à jour selon les retours ; intégrer les capacités pendant cette période.
• Attente de l'examen de l'autorisation de production (environ 7 jours) : préparer le paquet avec les publicités réelles et vérifier la liste de contrôle (section 6 de review.md) ; préparer les ressources promotionnelles pour le Store.
• Après publication : associer le Store dans AdMob et terminer la vérification app-ads.txt (section 2.7 de capabilities.md) ; les testeurs du test fermé reçoivent aussi la version production et les publicités réelles, la mise en pause du canal de test ne les bloque pas (section 6 de review.md) ; surveiller le taux de plantages et les ANR dans Android vitals. À partir de février 2027, la mémoire sera évaluée, et les jeux avec un DEX dépassant 50 Mo devront être optimisés en code (Officiel). Chaque mise à jour incrémente versionCode, regrouper les modifications pour une seule soumission.
• Paiements : quand le solde AdMob atteint 10 $, vérifier l'identité et l'adresse (code PIN par courrier postal, environ 3 semaines) ; à partir de 100 $, paiement autour du 21 de chaque mois ; pour les achats intégrés, créer d'abord un profil de paiement commerçant et ajouter un compte bancaire, paiement à partir du 15 de chaque mois pour les revenus du mois précédent. Voir payouts.md.
• Rejet ou blocage : voir section 4 de review.md et troubleshooting.md.