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.
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.
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:
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.
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.
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