Android的VersionCode和VersionName

定义

Android的版本可以在androidmainfest.xml中定义，主要有android:versionCode和android:versionName
Google为APK定义了两个关于版本属性：VersionCode和VersionName，他们有不同的用途。
VersionCode：对消费者不可见，仅用于应用市场、程序内部识别版本，判断新旧等用途。
android:versionCode:主要是用于版本升级所用，是INT类型的，第一个版本定义为1，以后递增，这样只要判断该值就能确定是否需要升级，该值不显示给用户。

VersionName：展示给消费者，消费者会通过它认知自己安装的版本，下文提到的版本号都是说VersionName。
android:versionName:这个是我们常说明的版本号，由三部分组成..,该值是个字符串，可以显示给用户。

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.xxx.xxx"
    android:versionCode="2"
    android:versionName="1.1">

读取manifest.xml

PackageManager pm = context.getPackageManager();//context为当前Activity上下文 
PackageInfo pi = pm.getPackageInfo(context.getPackageName(), 0);
version = pi.versionName;

同一个VersionName(版本号)，对应了多个VersionCode

这种情况很常见，比如说新版本发布之后，某个商店反馈说存在xxx问题，需要修复、定制等等操作，于是商务找工程师出了个新版本，考虑到是小版本升级，版本号没变化，但是VersionCode已经变了。

可能遇到的问题：如果这个新版只在部分商店上线，就会出现都是3.1版，A商店的版本其实比B商店的新。已经安装了新版本的用户，还会被提示升级，这时候用户会困扰，为什么我装了3.1还要升级到3.1？部分商店为了最新会抓包，导致渠道包流窜，影响运营监控和分析。
解决方案：a.版本号应该和VersionCode一起涨，而且一旦发布新版本，就在所有渠道上架新版。

发布了一个VersionCode错误的版本

有时候因为工程师不小心，发布了一个VersionCode过大的版本，比如1.1.1.20版本的VersionCode写成了111，而1.1.1.27版本的VersionCode写成了11127，但是后面发布1.1.2版希望延续旧的VersionCode，用112。

可能遇到的问题：1.1.1.27版的用户将无法获得1.1.2版本的升级，因为在程序看来1.1.1.27版本是比较新的，同时，已经使用了1.1.2版本的用户，可能会收到旧版本的升级提示，比并降级回旧版
解决方案：其实很简单，因为VersionCode对最终用户是不可见的，只要增加就好了，上文的例子，新版VersionCode直接取11200就齐活了。

发布了一个有Bug的版本

偶尔会遇到版本已经发布了，第二天突然发现，糟糕，有Bug，用户开始骂了！于是到各家市场要求退回旧版本。

可能遇到的问题：已经升级到有Bug版本的用户是无法回滚到旧版的，因此这样直接退回旧版本的方式对这些热心升级的用户是非常不负责任的。而且人肉召回的力度实在有限，这个有Bug的版本一定会流传的。
解决方案：最好是不要浪费时间退回旧版，赶紧修复Bug发个新版本(记得加VersionCode)，如果Bug比较棘手，暂时无法修复，只能退回旧版本，这时建议把旧版本的VersionCode改大一些后，提交新版本，这样可以保证所有用户都能下载/升级到一个相对可靠的版本。