温馨提示！由于新浪微博认证机制调整，您的新浪微博帐号绑定已过期，请重新绑定！&&|&&
LOFTER精选
网易考拉推荐
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
其实标签&uses-sdk&中指定的并不是我们使用的sdk的版本，也不是Android系统的版本，而是我们使用的Android平台的版本，即API level。API level是一个整数，它指的是我们使用的框架（Framework）的版本，也就是我们使用的sdk中的各个平台下的android.jar。但是这个API level又和Android系统的版本有着对应关系，并且每个系统都会在内部记录它所使用的API level。举例来说，我使用的手机系统是Android 2.3.3， 那么它就会在内部记录使用的API level为10。这个内部的API level可以让系统判定能不能安装一款app，这个问题会在下文中提及。
下面给出android系统版本，API level和版本代号之间的对应关系表。（该表来自谷歌官方文档：/guide/topics/manifest/uses-sdk-element.html#provisional）
由上表可以看出，android的系统版本和API level之间并不是一一对应的，比如Android 2.3，&Android 2.3.1，&Android 2.3.2对应API level 9， 而Android 2.3.3，&Android 2.3.4对应API level 10。API level是Android向开发者提供的一套Framework（android.jar）的代号，可能发布了新的系统版本，但是这一套接口并没有变化，所以就不必提供新的Framework开发包，所以API level也不必改变。由此可知Android系统版本和API level是多对一的关系。由于API level就是发布的android.jar（一套接口）的代号，所以API level和sdk中platforms目录中的各个android.jar是一一对应的。说白了，Android系统版本是给Android用户看的，而API level是给应用程序开发者看的。
什么是build target
build target并不存在于manifest文件中，而是存在于项目根目录中的project.properties文件中。如果使用Eclipse构建项目的话，那么每个项目的根目录下都会有一个project.properties文件，这个文件中的内容用于告诉构建系统，怎样构建这个项目。打开这个文件，除了注释之外，还有以下一行：
target=android-18
这句话就是指明build target，也就是根据哪个android平台构架这个项目。指明build target为android-18，就是使用sdk中platforms目录下android-18目录中的android.jar这个jar包编译项目。同样，这个android.jar会被加入到本项目的build path中。如下图：
每当修改了build target，就会将另一个android.jar加入到build path中替换原来的jar。将build target改成android-17后的效果如下图：
如果将build target 改成android-8，那么就会使用sdk中android-8下的android.jar编译项目，如果在Activity中调用ActionBar相关的Api，那么就会报错，因为ActionBar相关的Api是在API level 11中才加进来的。
一般情况下，应该使用最新的API level作为build target。这也是eclipse生成项目时的默认行为。
android:minSdkVersion
指明应用程序运行所需的最小API level。如果不指明的话，默认是1。也就是说该应用兼容所有的android版本。我们应该总是声明这个属性。
如果系统的API level低于android:minSdkVersion设定的值，那么android系统会阻止用户安装这个应用。下载将android:minSdkVersion设置为11， 并且将该应用安装在android 2.3的手机上（对应API level 9），在安装时会有如下提示：
提示手机API level的版本太低，安装失败。
如果指明了这个属性，并且在项目中使用了高于这个API level的API， 那么会在编译时报错。将build target设为最新的android-19，那么就会使用最新的android-19下的android.jar来编译项目。将minSdkVersion设置为8。在使用的android.jar中，肯定会有和ActionBar相关的API， 但是在项目中调用ActionBar API， 项目会报错。因为minSdkVersion指明的API level 8中不存在ActionBar相关的API。
调用Activity.getActionBar()和ActionBar.getHeight()方法需要API level 11， 但是指定的minSdkVersion为8，所以报错。由此可见，minSdkVersion不仅在程序安装时起作用，也会在项目构建时起作用。
如果没有设置minSdkVersion这个属性，那么默认是1。表明程序兼容所有的Android系统，能够在所有Android系统上运行。如果使用了高于API level 1 的API， 如ActionBar。那么在构建项目时，会提示和上面相同的错误，项目构建失败。
android:targetSdkVersion
标明应用程序目标API Level的一个整数。如果不设置，默认值和minSdkVersion相同。
这个属性通知系统，你已经针对这个指定的目标版本测试过你的程序，系统不必再使用兼容模式来让你的应用程序向前兼容这个目标版本。应用程序仍然能在低于targetSdkVersion的系统上运行。
由于Android不断向着更新的版本进化，一些行为甚至是外观可能会改变。然而，如果平台的API Level高于你的应用程序中的targetSdkVersion属性指定的值，系统会开启兼容行为来确保你的应用程序继续以期望的形式来运行。你可以通过指定targetSdkVersion来匹配运行程序的平台的 API level来禁用这种兼容性行为。举例来说，设置这个值为11或更高，当你的应用运行在Android3.0或更高的系统上时，系统会为你的应用使用新的默认主题（Holo主题），并且当运行在大屏幕的设备上时会禁用屏幕兼容模式（screen compatibility mode），因为支持了 API level 11就暗示了支持大屏幕。
根据你设置的targetSdkVersion 的值，系统会执行很多兼容行为。一些行为在对应平台版本的Build.VERSION_CODES中有讨论。为了让你的应用程序支持每个Android版本，你应当提高targetSdkVersion的值到最新的API level，然后在对应的平台上彻底的测试你的应用。
从上面的论述可知，targetSdkVersion这个属性是在程序运行时期起作用的，系统根据这个属性决定要不要以兼容模式运行这个程序。
一般情况下，应该将这个属性的值设置为最新的API level 值，这样的话可以利用新版本系统上的新特性。eclipse在生成项目时，默认将该值设置为最高，如果设置一个较低的值，会给出一个警告，如下图所示。
这个警告的意思是没有将targetSdkVersion的值设置为最高值，较新的系统会以兼容模式运行该程序。请考虑在新版本系统上测试程序并将targetSdkVersion设置为最新。更详细的信息请参考android.os.Build.VERSION_CODES 。
android:maxSdkVersion
标明可以运行你的应用的最高API Level版本。在Android1.5， 1.6， 2.0 和2.0.1，在安装应用或系统升级时，系统会检查这个值。在这两种情况下，如果应用设置的maxSdkVersion 值低于系统本身使用的API Level，系统将不会允许安装该应用。在系统升级后，新系统会重新校验这个值，如果新系统的API Level高于这个值，新系统会删除你的应用。在高于2.0.1的系统上，安装应用时不会再检验应用中设置的maxSdkVersion值，在系统升级后也不会重新校验这个值。但是在向用户展示可用的应用时，Google Play会继续使用这个属性进行过滤。
maxSdkVersion这个属性本来是在程序安装时和系统升级后起作用的。但是根据官方文档中的说明， 已经不再推荐使用这个属性。
经过测试，将maxSdkVersion的值设置成9，程序是可以安装在4.2的手机上的。说明这个值已经不再起作用。
&uses-sdk&&
droid:minSdkVersion="8"&&
&&&&android:targetSdkVersion="19"&&&
&&&&android:maxSdkVersion="9"/&&&
android:minSdkVersion="8"
android:targetSdkVersion="19"
android:maxSdkVersion="9"/&
阅读(3389)|
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
历史上的今天
在LOFTER的更多文章
loftPermalink:'',
id:'fks_',
blogTitle:'Android中build target，minSdkVersion，targetSdkVersion，maxSdkVersion概念区分',
blogAbstract:' \r\n本文参考了谷歌开发者文档：'
{list a as x}
{if x.moveFrom=='wap'}
{elseif x.moveFrom=='iphone'}
{elseif x.moveFrom=='android'}
{elseif x.moveFrom=='mobile'}
${a.selfIntro|escape}{if great260}${suplement}{/if}
{list a as x}
推荐过这篇日志的人：
{list a as x}
{if !!b&&b.length>0}
他们还推荐了：
{list b as y}
转载记录：
{list d as x}
{list a as x}
{list a as x}
{list a as x}
{list a as x}
{if x_index>4}{break}{/if}
${fn2(x.publishTime,'yyyy-MM-dd HH:mm:ss')}
{list a as x}
{if !!(blogDetail.preBlogPermalink)}
{if !!(blogDetail.nextBlogPermalink)}
{list a as x}
{if defined('newslist')&&newslist.length>0}
{list newslist as x}
{if x_index>7}{break}{/if}
{list a as x}
{var first_option =}
{list x.voteDetailList as voteToOption}
{if voteToOption==1}
{if first_option==false},{/if}&&“${b[voteToOption_index]}”&&
{if (x.role!="-1") },“我是${c[x.role]}”&&{/if}
&&&&&&&&${fn1(x.voteTime)}
{if x.userName==''}{/if}
网易公司版权所有&&
{list x.l as y}
{if defined('wl')}
{list wl as x}{/list}参考/guide/topics/manifest/uses-sdk-element.html
API Level 是一个整型值，表示Android发布的某个特定版本，新API Level相对于老API Level会增加以下内容：* 新增类、或者已有类中新增、修改、甚至删除的API* 新定义的xml tag* 新定义Intent* 新定义的Permission* 其它&API Level和版本有如下对应关系：Platform Version API LevelAndroid 3.0 11Android 2.3.3 10Android 2.3 9Android 2.2 8Android 2.1 7Android 2.0.1 6Android 2.0 5Android 1.6 4Android 1.5 3Android 1.1 2Android 1.0 1先说一下minSdkVersion的用处：新版本中public了老版本没有的接口，如果我写的一个App中用到了只有新版本才有的接口，肯定不能让它跑在老版本SDK上，不然会报错。 Android是如何保证这一点的？靠定义minSdkVersion来实现。 比如，如果我定义了&uses-sdk android:minSdkVersion="8" &... /&, 编译生成的apk是无法安装到Android 2.1(API Level 7)系统上的，系统会提示： ERROR: Application requires API version 8. Device API version is 7。AndroidManifest.xml中如果不写，缺省 minSdkVersion = 1， 表示程序至少能安装到，并且作者也希望它能跑到Android 1.0上。接下来说一下targetSdkVersion的用处：一般而言，新版本要兼容老版本，这就是为什么Android中很多接口即使过时了(deprecated)但还依然保留在新SDK中，所以绝大多数情况下，为老版本开发的应用可以运行在新版SDK上。但是也有一些例外，主要是以下三类问题：1. 老接口被删除或修改了（这种case有，但很少），本文不关注2. 同样的接口，但新老版本的实现有所不同。比如有一些API早期设计时考虑不周全，新版本做了改进。3. 即使不涉及任何接口调用，但由于物理设备的扩展，同样的apk需要在新版本上需要适配更多的物理设备，从而具备了新的特性对于第二类问题，指定targetSdkVersion为具体的某个API Level，则表示调用接口时只会调用该版本实现的API，而不是早期版本的API。对于第三类问题，就是这封信碰到情况，Google从开发Android 1.6 （API Level 4）开始意识到，程序运行时需要考虑到手机屏幕大小、分辨率不同。因此从1.6开始引入了针对多屏幕的支持，定义了不同屏幕尺寸与分辨率、密度的一个对应关系。注意到此前google只意识到会在中密度屏幕（mdpi）下开发，所以1.5以及以前版本的图片图标等资源、布局都是按照中密度屏幕设计的。
从Android 1.6开始，Google提供了多套资源（ldpi, mdpi, hdpi) 支持，对内置应用以及Framework的资源（比如控件），系统可以在编译时刻决定只打包某个特定密度的资源(定义在PRODUCT_LOCALES中，对N1,应该是PRODUCT_LOCALES := hdpi ...）。
对基于SDK开发的应用，eclipse缺省会打包所有密度的资源，在Android 1.6之后的版本上跑，会在运行时刻根据物理设备实际密度来选择对应密度的资源。
如果某个App中定义的targetSdkVersion &= 3, , 表示该App无法用到Android 1.6才有的多屏幕支持能力， 所以即使应用本身包含了hdpi,mdpi,ldpi资源，但运行到hdpi的物理设备上时只会去加载mdpi的资源，当然显示就不正常了。注意：如果App中也用到的系统级资源（比如控件），一般来说特定的物理设备只可能是hdpi,mdpi, ldpi (以后会有扩展，比如xdpi）中的一种，所以只会加载那唯一的一种dpi资源，因此显示系统控件本来不应该有任何问题。不过，如果Image没有优化，而是包含了所有资源，那么控件显示也会不正常 。
再回到正题上来，为什么eclipse下编译的程序运行起来和ubuntu下编译的显示效果不同？
在ubuntu下编译，系统认为你编译的是内置应用，内置应用在正常情况下不会被变态的人扒出来放到其他设备上去，所以不存在安装兼容性问题，minSdkVersion缺省就是当前物理设备的current sdk version。另外既然是内置应用，当然运行在当前物理设备上效果最好，所以targetSdkVersion缺省也是当前物理设备的current sdk version。这个在编译时刻打包apk时，build system首先检测这两个值有没有设置，没设置的话它会替你加上。&在eclipse下编译，系统认为你编译的是第三方应用，忘了写就是你的错了，minSdkVersion和targetSdkVersion缺省都是1，所以会出现上面说到的悲剧。结论：1. 对内置应用，不要自己去设置minSdkVersion和targetSdkVersion；2. 基于SDK开发的，根据自己的实际情况，一定要设置minSdkVersion和targetSdkVersion；3. 刚刚没说maxSdkVersion，我们别定义它，以后可能会OTA升级整个Android系统，定义了它对我们是个悲剧
阅读(...) 评论()44350人阅读
Android（22）
本文参考了谷歌开发者文档：/guide/topics/manifest/uses-sdk-element.html#provisional
如果开发的应用用户较多，那么必须保证应用在多个版本不同的设备上能够正确的运行。这就要求对各个版本比较熟悉，知道在什么版本中加入了什么新的功能或特性。但是Android的版本太多了，是个令人头疼的问题。如果想了解Android的版本差异，建议读一下Android开发者文档上相关的章节。
为了让你的应用程序指定可以运行的版本，Android的manifest文件中提供了&uses-sdk&标签。该标签中有三个属性，分别是minSdkVersion，targetSdkVersion，maxSdkVersion。这三个属性比较容易让人迷惑，我也是仔细读了谷歌的官方文档，才弄清楚这三个属性的意义。此外，在项目构建时，还有个概念叫build target，在本文中也会进行分析。
什么是API level
其实标签&uses-sdk&中指定的并不是我们使用的sdk的版本，也不是Android系统的版本，而是我们使用的Android平台的版本，即API level。API level是一个整数，它指的是我们使用的框架（Framework）的版本，也就是我们使用的sdk中的各个平台下的android.jar。但是这个API level又和Android系统的版本有着对应关系，并且每个系统都会在内部记录它所使用的API level。举例来说，我使用的手机系统是Android
2.3.3， 那么它就会在内部记录使用的API level为10。这个内部的API level可以让系统判定能不能安装一款app，这个问题会在下文中提及。
下面给出android系统版本，API level和版本代号之间的对应关系表。（该表来自谷歌官方文档：/guide/topics/manifest/uses-sdk-element.html#provisional）
由上表可以看出，android的系统版本和API level之间并不是一一对应的，比如Android 2.3，&Android 2.3.1，&Android 2.3.2对应API level 9， 而Android 2.3.3，&Android 2.3.4对应API level 10。API level是Android向开发者提供的一套Framework（android.jar）的代号，可能发布了新的系统版本，但是这一套接口并没有变化，所以就不必提供新的Framework开发包，所以API
level也不必改变。由此可知Android系统版本和API level是多对一的关系。由于API level就是发布的android.jar（一套接口）的代号，所以API level和sdk中platforms目录中的各个android.jar是一一对应的。说白了，Android系统版本是给Android用户看的，而API level是给应用程序开发者看的。
什么是build target
build target并不存在于manifest文件中，而是存在于项目根目录中的project.properties文件中。如果使用Eclipse构建项目的话，那么每个项目的根目录下都会有一个project.properties文件，这个文件中的内容用于告诉构建系统，怎样构建这个项目。打开这个文件，除了注释之外，还有以下一行：
target=android-18
这句话就是指明build target，也就是根据哪个android平台构架这个项目。指明build target为android-18，就是使用sdk中platforms目录下android-18目录中的android.jar这个jar包编译项目。同样，这个android.jar会被加入到本项目的build path中。如下图：
每当修改了build target，就会将另一个android.jar加入到build path中替换原来的jar。将build target改成android-17后的效果如下图：
如果将build target 改成android-8，那么就会使用sdk中android-8下的android.jar编译项目，如果在Activity中调用ActionBar相关的Api，那么就会报错，因为ActionBar相关的Api是在API level 11中才加进来的。
一般情况下，应该使用最新的API level作为build target。这也是eclipse生成项目时的默认行为。
android:minSdkVersion
指明应用程序运行所需的最小API level。如果不指明的话，默认是1。也就是说该应用兼容所有的android版本。我们应该总是声明这个属性。
如果系统的API level低于android:minSdkVersion设定的值，那么android系统会阻止用户安装这个应用。下载将android:minSdkVersion设置为11， 并且将该应用安装在android 2.3的手机上（对应API level 9），在安装时会有如下提示：
提示手机API level的版本太低，安装失败。
如果指明了这个属性，并且在项目中使用了高于这个API level的API， 那么会在编译时报错。将build target设为最新的android-19，那么就会使用最新的android-19下的android.jar来编译项目。将minSdkVersion设置为8。在使用的android.jar中，肯定会有和ActionBar相关的API， 但是在项目中调用ActionBar
API， 项目会报错。因为minSdkVersion指明的API level 8中不存在ActionBar相关的API。
调用Activity.getActionBar()和ActionBar.getHeight()方法需要API level 11， 但是指定的minSdkVersion为8，所以报错。由此可见，minSdkVersion不仅在程序安装时起作用，也会在项目构建时起作用。
如果没有设置minSdkVersion这个属性，那么默认是1。表明程序兼容所有的Android系统，能够在所有Android系统上运行。如果使用了高于API level 1 的API， 如ActionBar。那么在构建项目时，会提示和上面相同的错误，项目构建失败。
android:targetSdkVersion
标明应用程序目标API Level的一个整数。如果不设置，默认值和minSdkVersion相同。
这个属性通知系统，你已经针对这个指定的目标版本测试过你的程序，系统不必再使用兼容模式来让你的应用程序向前兼容这个目标版本。应用程序仍然能在低于targetSdkVersion的系统上运行。
由于Android不断向着更新的版本进化，一些行为甚至是外观可能会改变。然而，如果平台的API Level高于你的应用程序中的targetSdkVersion属性指定的值，系统会开启兼容行为来确保你的应用程序继续以期望的形式来运行。你可以通过指定targetSdkVersion来匹配运行程序的平台的 API level来禁用这种兼容性行为。举例来说，设置这个值为11或更高，当你的应用运行在Android3.0或更高的系统上时，系统会为你的应用使用新的默认主题（Holo主题），并且当运行在大屏幕的设备上时会禁用屏幕兼容模式（screen
compatibility mode），因为支持了 API level 11就暗示了支持大屏幕。
根据你设置的targetSdkVersion 的值，系统会执行很多兼容行为。一些行为在对应平台版本的Build.VERSION_CODES中有讨论。
为了让你的应用程序支持每个Android版本，你应当提高targetSdkVersion的值到最新的API level，然后在对应的平台上彻底的测试你的应用。
从上面的论述可知，targetSdkVersion这个属性是在程序运行时期起作用的，系统根据这个属性决定要不要以兼容模式运行这个程序。
一般情况下，应该将这个属性的值设置为最新的API level 值，这样的话可以利用新版本系统上的新特性。eclipse在生成项目时，默认将该值设置为最高，如果设置一个较低的值，会给出一个警告，如下图所示。
这个警告的意思是没有将targetSdkVersion的值设置为最高值，较新的系统会以兼容模式运行该程序。请考虑在新版本系统上测试程序并将targetSdkVersion设置为最新。更详细的信息请参考android.os.Build.VERSION_CODES 。
android:maxSdkVersion
标明可以运行你的应用的最高API Level版本。
在Android1.5， 1.6， 2.0 和2.0.1，在安装应用或系统升级时，系统会检查这个值。在这两种情况下，如果应用设置的maxSdkVersion 值低于系统本身使用的API Level，系统将不会允许安装该应用。在系统升级后，新系统会重新校验这个值，如果新系统的API Level高于这个值，新系统会删除你的应用。
在高于2.0.1的系统上，安装应用时不会再检验应用中设置的maxSdkVersion值，在系统升级后也不会重新校验这个值。但是在向用户展示可用的应用时，Google Play会继续使用这个属性进行过滤。
maxSdkVersion这个属性本来是在程序安装时和系统升级后起作用的。但是根据官方文档中的说明， 已经不再推荐使用这个属性。
经过测试，将maxSdkVersion的值设置成9，程序是可以安装在4.2的手机上的。说明这个值已经不再起作用。
android:minSdkVersion=&8&
android:targetSdkVersion=&19&
android:maxSdkVersion=&9&/&
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：638382次
积分：6445
积分：6445
排名：第3933名
原创：61篇
评论：733条
文章：19篇
阅读：251953
(1)(3)(4)(3)(9)(14)(7)(9)(4)(7)(4)(2)(2)
(window.slotbydup = window.slotbydup || []).push({
id: '4740881',
container: s,
size: '200,200',
display: 'inlay-fix'你的位置： >
> 新手的第一个Android项目该如何选择targetSdkVersion
新手的第一个项目或许没有认真考虑过如何选择的问题，也或许还有一部分像TeachCourse一样的开发者，积累一些工作经验后才回头来思考这个问题。那么该如何选择一个targetSdkVersion的属性值？一个属性值为23的targetSdkVersion表示什么含义？那么API 24和Android 7.0又是什么关系？为什么API 19开发的Android项目可以在Android 7.0系统的手机上运行，反之Android 4.x系统的手机可以运行API 24开发的Android项目？最后，正确理解compileSdkVersion、和targetSdkVersion三者之间的关系。
一、认识targetSdkVersion
targetSdkVersion即目标软件开发版本，在创建每一个Android项目的时候都需要选择targetSdkVersion和minSdkVersion，一个targetSdkVersion的属性值表示创建的Android项目使用哪个API版本，一个API版本使用一个整型数字表示，API的全称是Application Programming Interface，即应用程序编程接口，API 19对应的编程接口和API 23定义的编程接口存在差别，因为使用整型数字表示targetSdkVersion的属性值，容易记忆和便于比较它们之间的大小，高版本API编程接口可以兼容低版本API编程接口，反之则不行。
需要区别Android 7.0和API 24之间的关系，Android 7.0定义的手机系统的版本，该系统的版本对外开放的应用程序接口被定义为API 24，如果开发者想要在开发的APP中使用Android 7.0系统提供的功能，这些功能包括：多窗口支持、通知显示变更、JIT/AOT编译、快速的应用安装路径等等，那么新手在创建的Android项目的时候就需要选择API 24的应用程序接口。
不知道开发者也没有注意到，为什么API 19开发的Android项目可以在Android 7.0系统的手机上运行，反之Android 4.x系统的手机可以运行API 24开发的Android项目，它们运行的效果是否一样呢？如果是Android 7.0系统运行API 24开发的应用程序，效果又是怎么样？这就让TeachCourse联想到了API 23开发的应用程序在低于Android 6.0系统上运行时，如果权限被禁用后，会提示如下图：
但是，如果API 23开发的应用程序在高于或等于Android 6.0系统的手机上运行时需要自己定义打印上述Toast，下面是完整的运行时权限申请的代码：
private static final int REQUEST_CODE_PERMISSION=0x112;
private void initPermission() {
int flag= ActivityCompat.checkSelfPermission(this, Manifest.permission.CAMERA);
if(PackageManager.PERMISSION_GRANTED!=flag){
ActivityCompat.requestPermissions(this,new String[]{Manifest.permission.CAMERA}, REQUEST_CODE_PERMISSION);
alterImageNew();
public void onRequestPermissionsResult(int requestCode, @NonNull String[] permissions, @NonNull int[] grantResults) {
super.onRequestPermissionsResult(requestCode, permissions, grantResults);
if (REQUEST_CODE_PERMISSION==requestCode){
switch (grantResults[0]){
case PackageManager.PERMISSION_DENIED:
boolean isSecondRequest=ActivityCompat.shouldShowRequestPermissionRationale(this,Manifest.permission.CAMERA);
if(isSecondRequest)
ActivityCompat.requestPermissions(this,new String[]{Manifest.permission.CAMERA},REQUEST_CODE_PERMISSION);
Toast.makeText(this, "拍照权限被禁用，请在权限管理修改", Toast.LENGTH_SHORT).show();
case PackageManager.PERMISSION_GRANTED:
alterImageNew();
如果需要显示类似于上面图片显示的Toast提示，开发者需要在onRequestPermissionResult回调方法中，打印拍照权限被禁用，请在权限管理修改这句话，在使用API 23应用程序编程接口开发的APP中都可以反复复制上面代码，仅将CAMERA替换成定义的权限参数，将alterImageNew()替换成拥有权限后要执行的代码。
举这个例子的目的，想要说明为什么在API 23版本开发的APP在低于Android 6.0系统不会执行上述代码的原因。
高版本的API定义了一些的编程接口，但是通常不需要开发者考虑是否高版本API开发的APP在低版本的Android系统的兼容性问题，API和Android系统是两个不一样的概念，API属于应用层的东西，Android系统属于底层的东西，开发者想要显示底层的演示效果，就需要使用API来完成，如果想要不同的演示效果，又需要考虑选择哪个版本的API，也就是文章的标题提到的：如何选择targetSdkVersion属性值的问题。
二、如何选择targetSdkVersion
一个Android系统，对外提供一套API，如何选择targetSdkVersion取决于应用程序需要实现的功能，如果你的应用程序使用API 7就可以实现的功能，可以不用考虑使用API 24，使用低版本API的其中一个好处，可以让更多的Android系统运行的效果保持一致，即兼容性更好，打个比方：API 7开发的APP可能兼容98%以上的Android手机，而API 24开发的APP可能兼容仅有60%，所谓的不兼容并不是无法正常运行，而是在不同Android系统的手机运行的效果差异比较大，会让用户感觉难以接受；使用低版本API的其中一个不足，显示的效果比较OUT，提供的可用的接口或类比较少，本来一句代码可以完成的功能（封装的类或接口），需要自己花一天琢磨写很多的代码，也就是有高版本API的其中一个原因，提供更多的或封装好的应用程序接口让开发者使用。
同时，高版本API会针对低版本存在的问题进行改进和完善，摈弃一下不用的类或接口，新增一些方法或属性，如果你使用的方法是在某个API被另一个方法代替的话，你可能就得在代码中区分APP是运行在哪个版本的Android系统，一个很典型的例子：WebChromeClient的onShowFileChooser()方法和openFileChooser()方法，如果你的targetSdkVersion小于19，在处理WebView上传表单的数据的时候就需要重写openFileChooser方法；如果你的targetSdkVersion大于或等于19，你就必须同时重写onShowFileChooser和openFileChooser两个方法，openFileChooser方法在Android 4.0以下系统被回调，另一则在Android 4.0以上系统被回调。这是高低版本API摈弃或新增一些类和方法时需要注意的其中一个问题。
了解并学习Android 4.x、Android 5.x、Android 6.x或Android 7.x系统的特性，重点掌握不同系统同一个功能的实现方式，即行为变更，特点：变更的行为在当前系统或更高系统版本中被支持，一个简单的例子：Android 7.0系统其中的一个行为变更是权限更改，尝试传递file:// URI 的方式写入本地文件或读取本地文件，使用API 24开发的APP将会触发 FileUriExposedException异常，请求拍照并保存到本地的正确的写法，如下：
* 调用系统相机
private void goToTakePhoto() {
String state = Environment.getExternalStorageState();
if (Environment.MEDIA_MOUNTED.equals(state)) {
File file = new File(mSDCardPath, System.currentTimeMillis() + ".jpg");
/**Android 7.0以上的方式**/
Uri contentUri = getUriForFile(this, getString(R.string.install_apk_path), file);
grantUriPermission(getPackageName(), contentUri, Intent.FLAG_GRANT_WRITE_URI_PERMISSION);
Intent intent = new Intent(MediaStore.ACTION_IMAGE_CAPTURE);
intent.putExtra(MediaStore.EXTRA_OUTPUT, contentUri);
/**Android 7.0以前的方式**/
intent.putExtra(MediaStore.EXTRA_OUTPUT, Uri.fromFile(file));
startActivityForResult(intent, RESULT_CAPTURE_IMAGE);
Toast.makeText(this, "sdcard不存在", Toast.LENGTH_SHORT).show();
想要查看完整的例子，文章后面附上源码，可以下载测试。本来已经代码可以实现的拍照功能，API 24开发的APP在Android 7.0以上系统需要至少四个步骤：
在AndroidManifest.xml文件中定义一个FileProvider
指定写入或读取本地文件的目录
生成完整的URI
请求授予URI权限
实现手机拍照并保存本地功能
三、关于minSdkVersion和compileSdkVersion
minSdkVersion定义应用程序支持的最低API版本，最低版本设置为API 11，目标版本设置为API 24，那么应用程序调用使用API 14提供的方法时，Android Studio或Eclipse开发工具将提醒开发者引用一个未定义的方法，使用该方法需要将minSdkVersion设置为API 14以上，如下图：
继续在上述代码，造成的结果大于或等于Android 4.0的系统可以正常执行，小于Android 4.0的系统将在运行时尝试访问不可用的 API 时发生崩溃。
compileSdkVersion定义应用程序编译选择哪个Android SDK版本，通常compileSDKVersion属性值被设置为最新的API版本，例如：25，改变compileSDKVersion的属性值不会影响Android系统运行行为，比如说，将属性值设置为25，targetSdkVersion属性值为23，代码如下：
compileSdkVersion 25
buildToolsVersion "25.0.2"
defaultConfig {
applicationId "cn.teachcourse.demos"
minSdkVersion 11
targetSdkVersion 23
versionCode 1
versionName "1.0"
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
开发的应用程序在Android 7.0系统运行，不会以Android 7.0新增的行为运行，决定Android系统行为的仍然是targetSDKVersion，那么compileSDKVersion有什么用呢？选择最新的API版本，在编译的时候检查代码的错误和警告，提示开发者修改和优化，因为通常在Android项目中会引入第三方的支持库，支持库使用了23.1.1版本，compileSdkVersion的属性值至少为23.0.0，新版本的支持库的发布紧跟着对应的Android系统平台，能够更好的兼容。
四、targetSdkVersion、minSdkVersion和CompileSdkVersion之间的关系
记住一点：Android系统平台的行为变更，只有targetSdkVersion的属性值被设置为大于或等于该系统平台的API版本时，才会生效；compileSdkVersion属于Android编译项目时其中的一项配置，主要区别是compileSDKVersion在不会被打包的APK文件中，targetSdkVersion和minSdkVersion将被打包到APK文件中，具体可以解压APK文件后，查看AndroidManifest.xml文件，如下图：
你会发现在使用Android Studio开发工具时，手动修改AndroidManifest.xml的属性值，使用Gradle构建后，将会被忽略，最终生成的是build.gradle配置文件指定的属性值。它们之间的关系如下：
minSdkVersion &= targetSdkVersion &= compileSdkVersion
参考资料：
Demo已上传GitHub，路径nougat\WriteToReadActivity.java
转载请注明： &
与本文相关的文章}