Easy pit of package name, signature, channel, and version number at Android development

This article summarizes some of the considerations that are easy to overlook in Android development:

First, carefully select the package name

The package name is equivalent to the name registered in the account book, and is the field used by the system to differentiate between different applications. Duplicate package names are considered to be the same application and cannot be installed in a single system at the same time. In general, the package name suggests using a domain name reverse order. For example, the website domain name of pea pod is www.wandoujia.com, so the package name of a series of Android apps of Pea pod is com.wandoujia.***. This conventional approach minimizes the "hit name" accident.

Case One

a developer of a mobile ERP client that uses Adobe's tools while developing an app, and also references Adobe's official tutorials to name the app air. The generic package name, such as Main, is the same as another game. So, in the process of upgrading and washing in vain has created chaos ... So the name to be cautious Ah!

Case Two

There is also a developer who, for some reason, uses the same package name for several different applications. So "com.hexin.qs.app.android" this package name, corresponding to the "Shen versus Securities", "Citic Jian Investment mobile Securities", "Joint inquiry securities mobile phone Stock" and several other completely different applications. The result is that users cannot install these apps on their phones at the same time, and they can easily upgrade from one app to another during the upgrade process. So, you can't give several children the same name!

二、一款 app should only have one signature

The signature file is equivalent to the developer's "identity card", we usually have only one ID in life, then the same in the mobile phone, the signature should be unique. And because the encryption mechanism of the signature makes it almost impossible to copy and forge the signature, the "Pea Wash in vain" is also one of the most important criteria for judging whether the official version of the signature. If an app uses a different signature, it may not be possible for the user to upgrade the app because the Android system will be able to upgrade the app in a different way than the signature. If the user chooses to force the upgrade, because the signature is different, it is necessary to uninstall the old version before installing the new version, then there are local application data, game records and so on will be directly lost.

Case One

It's like we accidentally lose our ID card, and the developer accidentally loses the signature file. We have encountered four or five examples of similar cases, developers find the door to request a replacement signature, the original is because the engineer left the signature documents taken away, the boss will not come back, had to put the original signature is also all changed again. So keep your signature file safe!

Case Two

we have counted, the online game "My name MT" in the major markets a total of 48 different signatures. According to the developer of "I'm MT," they distinguish different channels by different signatures, and the number of signatures that have been released is difficult to count. So many different signature files, in addition to their own management is very troublesome, but also to the user's upgrade process has brought trouble, accidentally upgraded to a different version of the signature, the game records are all lost. The purpose of the Android signature mechanism is to verify that the application has been changed, rather than to differentiate you from the channel. So what is the normal way to differentiate channels? Take a look at the next article.

Iii. using an XML configuration file to differentiate channels

In general, we use Meta-data in the Android manifest file to differentiate channels. For example:

after each formal package is complete, modify the Android:value, and then repackage to generate a new channel package, so:

don't use signatures to differentiate channels!

Iv. correctly fill in the version number in Android applications, there are two parameters associated with the version number. Where the version name represents the revision names, is the string, and version code represents the revision number, which is the integer number. In general, the user intuitively see version Name, so this should be filled with the shape of "4.15.1" such as the number. The parameters that are really used to determine the old version of the new version are versions Code. When the first version of the app is released, version Code should fill in 1, and then increment each time it is published, so that you can tell the market how much your app is updated in a canonical format. Some developers in version code is very casual, this version of the release of the wedding anniversary, so with the wife's birthday as version code, the next release is not very good luck, so use their lucky number as version code ... As a result, the user appears to have installed the latest 2.2.0 version from the official website, but the major markets have reminded "upgrade to 2.1.3 Version", the more the upgrade version number is smaller. The above four small things, although all relatively trivial, and there is no technical content, but it is a lot of beginners Android developers easy to ignore the problem. I hope this article can help the vast number of developers, in writing good applications at the same time, to avoid these "pits" to bring unnecessary losses to the application.

Reference: http://www.apkbus.com/forum.php?mod=viewthread&tid=122037

Easy pit Point (RPM) for package name, signature, channel, and version number at Android development