有关minSdkVersion和targetSdkVersion

只要手机当前版本满足minSdk都可以进行安装，假设4.4手机安装5.0targetSdk的apk，依然可以进行安装只是没有一些5.0效果，如果不做兼容性判断处理会导致报错，v4包就有部分向下兼容的控件。比如4.4和以上的侵入式状态栏写法不一样，就需要判断版本。

1举一个例子：假如你想给你的app加入大量的手势操作（sdk 7才引入的），然而这些手势操作可以被Button啊或menu等代替，在这种情况下，手势操作就是一个额外的加分功能，而不是一个必须的功能，因此你就需要把targetSDK设置为7，把minSDK设置为3（这是举个例子，现在没人还在用这么老的设备了）这样即使是使用老设备的用户也可以用你的app了。然后你所要做的就是要在代码里判断版本，如果是大于等于7的版本中就使用手势操作，小于7的版本中就使用button等代替，这样使用了新手机的用户就可以体验到你app中酷炫的新功能了。

2另外一个例子：如果你想给你的项目加入Android 5.0的Material Design，有一些用户可能会升级到5.0而使用到你的新特性，而有一部分用户的手机硬件太老，不支持升级到5.0，除非他们换新手机，那么你就要为他们进行向下兼容，不至于损失这部分用户，这样你的targetSDK设置为21，minSDK可以设置为8

-------------------------------------------------------------------------------------------------------------------------------

minSdkVersion与maxSdkVersion比较容易理解，就是在安装程序的时候，如果目标设备的API版本小于minSdkVersion，或者大于maxSdkVersion，程序将无法安装（这一点必须注意，如果你的程序希望给2.1用，而且没有用高级的api，请设定尽量低的版本）。一般来说没有必要设置maxSdkVersion，android自身平台具有向下兼容性。

targetSdkVersion相对复杂一些，如果设置了此属性，那么在程序执行时，如果目标设备的API版本正好等于此数值，他会告诉Android平台：此程序在此版本已经经过充分测，没有问题。不必为此程序开启兼容性检查判断的工作了。也就是说，如果targetSdkVersion与目标设备的API版本相同时，运行效率可能会高一些。这里就出现了刚才的问题，如果你为低版本的sdk软件设置了高版本的target，号称适应4.x，系统自然不会帮你检查兼容性，4.x取消了屏幕下方的menu键，也就出现了这个问题。所以要注意，target不是说你能支持的版本，是你的目标版本。

这也带来了另一个必须说的问题，就是比如说，使用了targetSdkVersion这个SDK版本中的一个特性，但是这个特性在低版本中是不支持的，那么在低版本的API设备上运行程序时，可能会报错：java.lang.VerifyError，我今天也刚刚遇到用户反馈的这个问题，现在通过具体了解这个问题也有了更加清晰的认识。这个错误也就是说，此属性不会帮你解决兼容性的测试问题。因此你至少需要在minSdkVersion这个版本上将程序完整的跑一遍来确定兼容性是没有问题的。

在default.properties中的target是指在编译的时候使用哪个版本的API进行编译。