[JAVA] The story of the release work of the application that Google does not tell

I'm working on a release, and I'm always worried, so I'd like to summarize the version code and version name specifications.

Perhaps Android advanced users will not run into these problems by automating the release flow or utilizing CI / CD tools, but this time it is for the purpose of understanding the specifications of GooglePlayConsole. I'm not going to touch on those high-skilled parts, I'm going to write it for beginners to intermediates: santa_tone1:

1. Publish the APK / AAB file of the created application to the store

If you want to publish the app to users, upload the build file created in the place where [Release Management]-> [App Release] page of GooglePlayConsole says Product version track and publish it. If you do, you can release it. スクリーンショット 2018-12-22 16.56.10.png

If it is the first release, I think it can be released without any problems.

In the above image, the version code is 1 and the version name is 1.0. This is linked to versionCode and versionName set in ʻapp / build.gradle`.

By the way, the first time you run into a problem (have anxiety) is when you want to upgrade the product version of the app.

2. I want to update the published commercial version of the app

The retail app should be updated for a variety of reasons. At that time, if you try to publish the APK / AAB file without thinking about anything, the following problems may occur. スクリーンショット 2018-12-22 16.59.04.png

You are angry that you should change the version code to something other than 1. The build with version code 1 has already been used when the app was first published. You can't upload multiple build files with the same version code. Now let's change ʻapp / build.gradle` to change the version code.

.... However, how should the value be changed at this time? For example, wouldn't this question arise?

――Since the version code is a number, is it OK to increment it for the time being? -Is it okay to use a large number if it does not overlap with the existing version code? --What is System.currentTimeMillis () in Java? ――Is it okay if "another version code" is lower than the existing version code? ――Is it okay if the version names are the same?

Let's solve each one.

-Since the version code is a number, is it OK to increment it for the time being?

When updating the app, incrementing is OK at any time. If you increment it, no one should be unhappy.

・ Is it okay to use a large number if it does not overlap with the existing version code?

In u2020 / JakeWharton, I saw this description. It may be helpful!

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}"
    }
}

By the way, versionCode seems to cause a build error if it is a number with 10 digits or more. It also warned me that the number was set too large, so don't use an extraordinary number. In that sense, it's dangerous to use the value of System.currentTimeMillis (): joy:

・ Is it okay if "another version code" is lower than the existing version code?

If you try to publish a build file with a version code lower than the released retail version code, the upload will succeed if the build file has a version code that has never been uploaded to Google Play Console. .. However, the publication will not be successful. I get the following error: スクリーンショット 2018-12-22 17.56.43.png In other words

** Version code is higher than existing retail version = Users can upgrade the target app from the store **

It seems to be a specification. Even if you publish a version with a low version code, it will not affect existing users at all, so it is useless to do it. Even when installing an app from Deploygate, if you want to use an app with a lower version code than the installed app, you need to uninstall it once.

・ Is it okay if the version names are the same?

The default versionName is 1.0, so it looks like you need to increase it along with the version code. Regarding the version name, it seems that the same as the existing one is okay. It cannot be a factor in deciding whether to update on Google Play Console. For example, ** If the version code is the same as the existing product version, but the version name is different, the build file cannot be updated as the product version. ** It seems that the version code is especially important on the Google Play Console side.

What's more, the version name can be changed on Google Play Console before and after the release, so what is it for? .. .. In addition, the version name does not have to be a number as it can be specified as a string. In the extreme, you can set anything: no_mouth:

The set value seems to be reflected in the following current version part displayed on the app details screen of the store. スクリーンショット 2018-12-22 18.24.37.png

Now, let's follow the version code and version name specifications, including the beta version and the internal test version!

3. I want to utilize the manual app test before publication

There are four ways to publish apps that developers can use.

--Product version truck (Product version) --Open Track (Beta) --Closed track (alpha version) --Internal test version track (internal test version)

It has become. It is enough to refer to the following links for how to use each, so I will omit it. Set up open test version, closed test version, internal test version

What I would like you to keep in mind in this article is

** Internal test version can be promoted (released) as alpha version, alpha version can be promoted (released) to beta version, beta version can be promoted (released) to commercial version **

about it. It is an image that you can go up one level at a time. Also, at this time, ** version code and version name are promoted with the same value. ** ** Well, of course, it's natural.

However, there are times when I feel uneasy when using this test track.

-If the build is published to a track with a higher hierarchy, the lower track build may not be usable depending on the version code.

Regarding the alpha and beta builds, the following annotations have also appeared in the Google Play Console.

For testers to use alpha and beta APKs, the APK version code must be higher than the retail APK.

However, this cannot be seen in the initial display. (You can see it only by pressing ? In the image below)

Conversely, if you publish a build with a higher version code than the build uploaded to the alpha or beta version as a commercial version, you will not be able to use the alpha and beta builds. スクリーンショット 2018-12-22 19.54.51.png

So, in cases where you want to test features that are still in the future, it may be a good idea to create a build with some margin in the version code. (It's not such a hassle to raise it again even if it can no longer be used, but lol)

-Does the build uploaded to the internal test track continue to remain regardless of the version code of other tracks?

Previously, similar to the features of the alpha and beta versions, if a build with a high version code was published to a higher track, the internal test version would not be available as well. However, it seems that there was a change in the specifications on the Google side, and now only the internal test version remains even if the build with the high version code is released on the upper track.

Also, even when the internal test version is promoted to the alpha version, the internal test version will continue to remain and can be used.

Immortal ...

Due to this specification, it is possible to take actions such as promoting an internal test build with a lower version code than the product version to the alpha version (the display of the alpha version was immediately replaced with the product version). Become).

why is it. I'm so worried that I can't sleep at night. .. ..

Summary

It's longer than expected, but the main thing is managing the version code, and it seems that you can manage the version name relatively freely. With this, the anxiety of release work is almost gone! Let's start next year by erasing or forgetting this year's anxiety as much as possible!

If you have a wrong explanation or feel that you are not satisfied, please point out to resolve your anxiety: bow_tone2:

Thank you very much!

Recommended Posts

The story of the release work of the application that Google does not tell
About the problem that the python version of Google App Engine does not mesh
The story that yapf did not work in vscode
Grep so that grep does not appear at the time of grep
The story that `while queue` did not work in python
The story of remounting the application server
The story that the version of python 3.7.7 was not adapted to Heroku
The story of creating a site that lists the release dates of books
The story that 2D list replacement did not work in python
The story of developing a web application that automatically generates catchphrases [MeCab]
After installing php7.2, the php command does not work
Example of what to do when the sample script does not work (OpenCV-Python)
A story that sometimes does not work if pip is up to date
A story that reduces the effort of operation / maintenance
[systemd] How to deal with the problem that fancontrol does not work after suspending
Deep Learning! The story of the data itself that is read when it does not follow after handwritten number recognition
The story of sys.path.append ()
The story that the return value of tape.gradient () was None
A story that analyzed the delivery of Nico Nama.
The story that sendmail that can be executed in the terminal did not work with cron
The story of debugging in the local environment because the compilation did not work with Read the Docs
A story that pyenv is stuck because the python execution command PATH does not pass
[Python] Tensorflow 2.0 did not support Python 3.8, so the story of downgrading Python
The story of creating a database using the Google Analytics API
The story of building Zabbix 4.4
[Apache] The story of prefork
The story of exclude / include that Serverless Framework beginners misunderstood (did not understand) in beginner Pythonista
The story of not being able to run pygame with pycharm
A story that struggled to handle the Python package of PocketSphinx
Solution when background-cover of Linux version VS Code does not work
The problem that the version of Vue CLI did not go up
When the program pip installed on Mac / Marvericks does not work
The story of making a module that skips mail with python
An error that does not work as expected when calling the tkinter module in a text editor
The story of Python and the story of NaN
The story of participating in AtCoder
Problem that discord.py does not break
LocateCenterOnScreen does not work on PyAutoGui
The story of the "hole" in the file
The story of writing a program
A story that visualizes the present of Qiita with Qiita API + Elasticsearch + Kibana
Note that the Google Maps Android API GoogleMap.getProjection is not a singleton
(Under investigation) USB camera that does not work with WebRTC on RPi4
Check items when the imported python module does not work as expected
Processing when the key input of Python pygame does not go well.
The story of making a package that speeds up the operation of Juman (Juman ++) & KNP
The story of creating Botonyan that returns the contents of Google Docs in response to a specific keyword on Slack