About APK version update
Conclusion: Google defines two version attributes for APK: versioncode and versionname. They have different purposes.
- Versioncode: This code is invisible to consumers. It is used only for the application market, internal program version identification, and new and old application versions.
- Versionname: displays the version to the consumer. The consumer recognizes the version installed by himself. The version numbers mentioned below are versionname.
There are three solutions to common problems at the end.
- What if the same version number corresponds to multiple versioncodes?
- What should I do if I publish a version with a versioncode error?
- How can I change the bug of the released application back to the old version?
Then let's talk about the causes and consequences. When you use software and applications, you will be involved in the concept of a version, as we all know, such as Win XP, qq2012, and Xiaomi desktop 1.6. The reason for the release is that software products are constantly evolving and changing. The version concept helps consumers identify products of different periods. The versions displayed in front of consumers are usually different from those used by developers. During development, numbers are often used as signs. For example, 6.1.7600.16385 is actually the first official version of win 7, while the SP1 version of win 7 is 6.1.7601.17514, so that a long string of numbers is meaningless to consumers, therefore, we usually start a version that is easier to understand when releasing a product. In this article, we will call a version like win 7 for display as [versionname], 6.1.7601.17514 the version used for program identification is called [versioncode] in the early years, because the software was mainly responsible for its own distribution and upgrade, the version number was quite free and different families had different specifications. However, in recent years, with the rise of mobile devices, application stores such as app store have become the mainstream for centralized distribution. Taking the upgrade as an example, the app store will check the version of the app on the consumer's mobile phone and compare it with the latest version in the store. if the version in the store is newer, if the version on the consumer's mobile phone is old, the consumer will be reminded to upgrade. This involves how to identify new and old problems. For computers, the most reliable way to judge is numbers. numbers have many advantages: the program is easy to judge, the format is simple, the error is not easy, and the human eye is easy to identify. Therefore, Google requires every application to record the [versioncode] of the installation package in the APK installation package. As long as you get the APK file, you can know what the corresponding [versioncode] is, the app store determines the version based on the [versioncode. The larger the [versioncode] Number of the installation package, the more new it will be. In this way, developers only need to increase the number for each new version during the development process. For example, the first version of [versioncode] is 1 and the second version is 2. Because developers may generate multiple unpublished versions every day, this number increases rapidly. After a period of development, this number will become relatively large, such as 16385. At this time, such a number is not very recognizable to a consumer, for example, win 16385 and win 17514 have poor information communication effects, which is not conducive to product marketing. Therefore, Google also supports recording [versionname] In the AKP installation package. You can call it win 7 or win vista to meet market and communication requirements, in this way, [versionname] is not capable of comparing new and old versions. It is only used for display to consumers.
To sum up
- Versioncode: This code is invisible to consumers. It is used only for the application market, internal program version identification, and new and old application versions.
- Versionname: displays the version to the consumer. The consumer recognizes the version installed on the consumer. This is the general version number.
During the operation of the App Store, we found that some developers encountered some problems.
1. The same versionname (Version Number) corresponds to multiple versioncodes. This situation is very common. For example, after the new version is released, a store reports that there are XXX problems, which need to be fixed, customized, and so on. Therefore, the Business engineer has a new version, considering that it is a minor version upgrade, the version does not change, but the versioncode has changed.
- Possible problems: if this new version is only available in some stores, it will all appear in version 3.1. The version of shop a is actually newer than that of Shop B. If you have installed a new version, you will be prompted to upgrade it. At this time, the user will be troubled. Why should I upgrade the version from 3.1 to 3.1? Some stores capture packets for the latest, leading to channel package flooding, affecting operation monitoring and analysis.
- Solution: A. The version number should increase with versioncode. Once the new version is released, the new version will be available in all channels.
2. a version with incorrect versioncode is released. Sometimes an excessively large version of versioncode is released due to the engineer's carelessness. For example, versioncode of version 1.1.1.20 is written as version 111, while versioncode of version 1.1.1.27 is written as version 11127, however, later version 1.1.2 is released to continue the old versioncode, with version 112.
- Possible problems: Users of version 1.1.1.27 will not be able to upgrade version 1.1.2, because version 1.1.1.27 is relatively new in the program, and users who have already used version 1.1.2, you may receive an update prompt for the old version.
- Solution: it is actually very simple, because versioncode is invisible to end users, as long as it is added. In the above example, the new version of versioncode will be able to get 11200.
3. Released a version with bugs. Occasionally, the version has been released. The next day, the user suddenly finds that the version is bad and has bugs! As a result, the business personnel asked to return the old version to various markets.
- Possible problems: users who have upgraded to a bug cannot roll back to the old version. Therefore, returning the old version directly is very irresponsible for these enthusiastic users. In addition, the manual recall is limited, and the bug version will surely spread.
- Solution: Do not waste time returning the old version. Fix the bug and release a new version (remember to add versioncode). If the bug is tricky and cannot be fixed for the moment, you can only return the old version, we recommend that you increase the versioncode of the earlier version and submit the new version to ensure that all users can download/upgrade to a relatively reliable version.
The above are some suggestions for the Android Application version. I hope to help you.
Versioncode and versionname
