L'histoire du travail de sortie de l'application que Google ne raconte pas

Je travaille sur une version et je suis toujours inquiet, alors j'aimerais résumer le code de version et les spécifications du nom de la version.

Peut-être que les utilisateurs avancés d'Android ne rencontreront pas ces problèmes en automatisant le flux de publication ou en utilisant des outils CI / CD, mais cette fois, c'est dans le but de comprendre les spécifications de GooglePlayConsole. Je ne vais pas aborder ces parties hautement qualifiées, je vais l'écrire pour les débutants aux intermédiaires: santa_tone1:

1. Publiez le fichier APK / AAB de l'application créée dans la boutique

Lors de la publication d'une application aux utilisateurs, téléchargez le fichier de construction créé à l'endroit où la page [Gestion des versions] -> [Version de l'application] de GooglePlayConsole indique Suivi de la version du produit et publiez-le. Si vous le faites, vous pouvez le libérer.

Si c'est la première version, je pense qu'elle peut être publiée sans aucun problème.

Dans l'image ci-dessus, le code de version est «1» et le nom de version est «1.0». Ceci est lié aux paramètres versionCode et versionName définis dans ʻapp / build.gradle`.

À propos, la première fois que vous rencontrez un problème (vous êtes anxieux), c'est lorsque vous souhaitez mettre à niveau la version produit de l'application.

2. Je souhaite mettre à jour l'application de la version commerciale publiée

L'application de vente au détail doit être mise à jour pour diverses raisons. À ce moment-là, si vous essayez de publier le fichier APK / AAB sans penser à quoi que ce soit, les problèmes suivants peuvent survenir.

Vous êtes en colère que le code de version soit autre chose que «1». La version avec le code de version «1» a déjà été utilisée lors de la première publication de l'application. Vous ne pouvez pas télécharger plusieurs fichiers de construction avec le même code de version. Maintenant, changeons ʻapp / build.gradle` pour changer le code de version.

.... Cependant, comment la valeur doit-elle être modifiée à ce stade? Par exemple, cette question ne se poserait-elle pas?

―― Puisque le code de version est un nombre, est-il possible de l'incrémenter pour le moment?

• Est-il acceptable d'utiliser un grand nombre s'il ne chevauche pas le code de version existant?
• Qu'est-ce que «System.currentTimeMillis ()» en Java? Est-ce que ça va si "un autre code de version" est inférieur au code de version existant? ――Est-ce que les noms de version sont identiques?

Résolvons chacun.

-Comme le code de version est un nombre, est-il possible de l'incrémenter pour le moment?

Lors de la mise à jour de l'application, l'incrémentation est possible à tout moment. Si vous l'incrémentez, personne ne devrait être mécontent.

・ Est-il acceptable d'utiliser un grand nombre s'il ne chevauche pas le code de version existant?

Dans u2020 / JakeWharton, j'ai vu la description suivante. Cela peut être utile!

u2020/build.gradle

def versionMajor = 1
def versionMinor = 0
def versionPatch = 0
def versionBuild = 0

android {
    
    defaultConfig {

        versionCode versionMajor * 10000 + versionMinor * 1000 + versionPatch * 100 + versionBuild
        versionName "${versionMajor}.${versionMinor}.${versionPatch}"
    }
}

Au fait, versionCode semble provoquer une erreur de construction s'il s'agit d'un nombre de 10 chiffres ou plus. Il m'a également averti que le nombre était trop grand, alors n'utilisez pas un nombre extraordinaire. En ce sens, il est dangereux d'utiliser la valeur de System.currentTimeMillis (): joy:

・ Est-ce correct si "un autre code de version" est inférieur au code de version existant?

Si vous essayez de publier un fichier de build dont la valeur est inférieure au code de la version commerciale publiée, l'importation réussira si le fichier de build possède un code de version qui n'a jamais été téléchargé dans la console Google Play. .. Cependant, la publication échouera. J'obtiens l'erreur suivante: En d'autres termes

** Code de version supérieur à la version commerciale existante = l'utilisateur peut mettre à niveau l'application cible à partir du magasin **

Cela semble être la spécification. Même si vous publiez une version avec un code de version basse, cela n'affectera pas du tout les utilisateurs existants, il est donc inutile de le faire? Même lors de l'installation d'une application à partir de Deploygate, si vous souhaitez utiliser une application avec un code de version inférieur à l'application installée, vous devez la désinstaller une fois.

・ Est-ce que les noms de version sont identiques?

La valeur par défaut versionName est 1.0, il semble donc que vous deviez l'augmenter avec le code de version. En ce qui concerne le nom de la version, il semble que le même que celui existant est correct. Cela ne peut pas être un facteur pour décider de mettre à jour ou non sur la console Google Play. Par exemple, ** Si le code de version est le même que la version commerciale existante, mais que le nom de la version est différent, le fichier de construction ne peut pas être mis à jour en tant que version commerciale. ** Il semble que le code de version soit particulièrement important du côté de la console Google Play.

De plus, le nom de la version peut être modifié sur la console Google Play avant et après la sortie, alors à quoi sert-il? .. .. De plus, le nom de la version n'a pas besoin d'être un nombre car il peut être spécifié sous forme de chaîne. À l'extrême, vous pouvez définir n'importe quoi: no_mouth:

La valeur définie semble être reflétée dans la partie version actuelle suivante affichée sur l'écran des détails de l'application du magasin.

Maintenant, suivons le code de version et les spécifications de nom de version, y compris la version bêta et la version de test interne!

3. Je souhaite utiliser le test d'application manuel avant la publication

Il existe quatre façons de publier des applications que les développeurs peuvent utiliser.

• Camion de version de produit (version de produit) --Ouvrir la piste (bêta)
• Piste fermée (version alpha)
• Piste de version de test interne (version de test interne)

Il est devenu. Il suffit de se référer aux liens suivants pour savoir comment les utiliser, je vais donc l'omettre. Configurer la version de test ouverte, la version de test fermée, la version de test interne

Ce que j'aimerais que vous gardiez à l'esprit dans cet article est

** La version de test interne peut être promue (publiée) en tant que version alpha, la version alpha peut être promue (publiée) en version bêta, la version bêta peut être promue (publiée) en version commerciale **

à propos de ça. C'est une image que vous pouvez monter d'un niveau à la fois. En outre, à ce stade, ** le code de version et le nom de version sont promus avec la même valeur. ** ** Eh bien, bien sûr, c'est naturel.

Cependant, il y a des moments où je me sens mal à l'aise lorsque j'utilise cette piste d'essai.

-Si la version est publiée sur une piste avec une hiérarchie supérieure, la version de piste inférieure peut ne pas être disponible en fonction du code de version.

En ce qui concerne les versions alpha et bêta, les notes suivantes sont également apparues dans la console Google Play.

Pour que les testeurs utilisent les APK alpha et bêta, le code de version de ce fichier APK doit être supérieur à celui du fichier APK commercial.

Cependant, cela ne peut pas être vu dans l'affichage initial. (Vous ne pouvez le voir qu'en appuyant sur ? Dans l'image ci-dessous)

Inversement, si vous publiez une version avec un code de version supérieur à la version téléchargée vers la version alpha ou bêta en tant que version commerciale, vous ne pourrez pas utiliser les versions alpha et bêta.

Ainsi, dans les cas où vous souhaitez tester des fonctionnalités qui sont encore dans le futur, il peut être judicieux de créer une version avec une certaine marge dans le code de la version. (Ce n'est pas si compliqué de le remonter même s'il ne peut plus être utilisé, mais lol)

-Est-ce que la construction téléchargée sur la piste de test interne continue de rester quel que soit le code de version des autres pistes?

Auparavant, comme les fonctionnalités des versions alpha et bêta, si une version avec un code de version supérieure était publiée sur une piste supérieure, la version de test interne ne serait pas disponible également. Cependant, il semble qu'il y ait eu un changement dans les spécifications du côté de Google, et maintenant seule la version de test interne reste même si la version avec le code de la version haute est publiée sur la piste supérieure.

En outre, même lorsque la version de test interne est promue vers la version alpha, la version de test interne continuera à rester et pourra être utilisée.

Immortel ...

En raison de cette spécification, il est possible d'entreprendre des actions telles que la promotion d'une version de test interne avec un code de version inférieur à la version du produit vers la version alpha (l'affichage de la version alpha a été immédiatement remplacé par la version du produit). Devenir).

pourquoi est-ce. Je suis tellement inquiète de ne pas pouvoir dormir la nuit. .. ..

Résumé

C'est plus long que prévu, mais l'essentiel est de gérer le code de la version, et il semble que vous puissiez gérer le nom de la version relativement librement. Avec cela, l'angoisse du travail de sortie est presque partie! Commençons l'année prochaine en effaçant ou en oubliant au maximum l'anxiété de cette année!

Si vous avez une mauvaise explication ou sentez que vous n'êtes pas satisfait, veuillez l'indiquer pour résoudre votre anxiété:

Merci beaucoup!