Google has defined two version attributes for the APK: Versioncode and Versionname, which have different uses.
Versioncode: not visible to consumers, only for the application of the market, the internal identification version of the program, to determine the use of new and old.
Versionname: Show to consumers, consumers will be aware of their own installed version, the version numbers mentioned below are said to be versionname.
At the end there are three common problem solving solutions
The same version number that corresponds to multiple versioncode what to do
What if I publish a version of the Versioncode error?
Issued to the application has a bug to change back to the old version, how to do?
And talk about the causes and consequences.
Everyone in the use of software and applications, will involve the concept of version, we all know, such as Win xp,qq2012, Xiaomi desktop 1.6. There is a version, mainly because the software products have been developing and changing. The concept of a version can help consumers identify products at different times.
The version that is displayed in front of the consumer is usually different from the one used within the developer. Development often uses numbers as a sign, such as 6.1.7600.16385, which is actually the version number of the first official version of Win 7, and win 7 The SP1 version number is 6.1.7601.17514, so a long string of numbers doesn't make sense to consumers, so it's usually easier to understand when a product is released. In the following section, the version of Win 7 for display is called [versionname],6.1.7601.17514, which is a version of the program ID called [Versioncode].
Early because the software is mainly responsible for their own distribution, upgrade, and so on, so the version number is quite free, each family has different specifications. But in recent years mobile devices have risen, and app stores such as App Store have been centrally distributed into the mainstream. To upgrade, for example, the store will be responsible for checking the version of the app on the consumer's phone and comparing it with the latest version in the store, if the version in the store is newer and the version on the consumer's phone is older, it will remind the consumer to upgrade.
This involves how to identify new and old problems.
For the computer, the most reliable way of judging is the number, the number has many advantages: The program is easy to judge, simple format is not error prone, easy to identify the naked eye. So Google requires each app to record this installation package in the APK installation package [Versioncode], as long as you get the APK file, you can know its corresponding [Versioncode] is how much, the App store will use this [Versioncode] prevail, To determine the version. The larger the [Versioncode] number of the installation package, the more new. So developers in the development process, each of the new version as long as a little more this number can be. For example, the first version of [Versioncode] is 1, the second version is 2. Because developers may produce multiple, unpublished versions every day, this number will grow quickly.
After a period of development, this number will become larger, such as 16385, at this time for a consumer, such a number is not very recognizable, such as win 16385 and win 17514 in the transmission of information is not good effect, not conducive to product marketing. So Google also support in the AKP installation package record [Versionname], you can call Win 7, Win Vista no problem, can meet the market, communication needs, so [versionname] actually does not have the ability to compare new and old version, Just to show it to the consumer.
Sum up
Versioncode: not visible to consumers, only for the application of the market, the internal identification version of the program, to determine the use of new and old.
Versionname: Show to consumers that consumers will recognize the version they have installed. In general, the version number we're talking about is this.
During our operations, we found that some of the developers encountered some problems.
1, the same versionname (version number), corresponding to a plurality of versioncode
This is very common, for example, after the release of the new version, a store feedback that there is a XXX problem, need to repair, customization, and so on, so the business to find a new version of the engineer, considering the minor version of the upgrade, the version number has not changed, but Versioncode has changed.
Possible problems: If this new version is only available in some stores, it will appear as 3.1, and a store version is actually newer than the B store. Already installed a new version of the user, will also be prompted to upgrade, this time users will be troubled, why I installed 3.1 and upgrade to 3.1? Some stores in order to catch up with the latest package, resulting in the channel package flows, affecting operational monitoring and analysis.
Solution: A. The version number should go up with Versioncode, and once the new version is released, it will be available in all channels.
2, published a versioncode wrong version
Sometimes because the engineer accidentally, released a Versioncode too large version, For example 1.1.1.20 version of Versioncode written in 111, and 1.1.1.27 version of Versioncode written 11127, but later released 1.1.2 version want to continue the old Versioncode, with 112.
Possible issues: Users of version 1.1.1.27 will not be able to get the 1.1.2 version of the upgrade, because in the program it appears that 1.1.1.27 version is relatively new, at the same time, already using 1.1.2 version of the user, may receive an older version of the upgrade hint, than and downgrade back to the previous version
Solution: Actually very simple, because versioncode is not visible to the end user, as long as the increase is good, the above example, the new version of Versioncode directly take 11200 to live.
3, released a bug version, good catch the urgent
Occasionally encounter version has been released, the next day suddenly found, bad, there are bugs, the user began to scold! So the business students to the market request back to the old version.
Possible issues: Users who have been upgraded to a bug version cannot be rolled back to the previous version, so it is very irresponsible for these enthusiastic users to revert to the old versions directly. And the strength of human recall is limited, this bug version will be circulated.
Solution: It is best not to waste time to return to the old version, quickly fix the bug to send a new version (remember add Versioncode), if the bug is tricky, temporarily unable to repair, can only return the old version, it is recommended to change the old version of Versioncode, submit a new version, This ensures that all users will be able to download/upgrade to a relatively reliable version.
These are some suggestions for Android app versions. Hope to be of help to everyone.
