android中的“min SDK, target SDK and compile with”有什么区别？
当我尝试制作一个新的Android应用程序项目时出现的“最小SDK，目标SDK和编译”有什么区别！像这样……
最小 SDK：API 14 目标 SDK：API 17 编译方式：API 14
我的选择好不好？？或者我应该选择哪些？ 抱歉，我试着放一张照片，但我不能...
【问题讨论】：
简单地说，
Minimun SDK : API 14
是指您的应用程序只能在 api 级别 14 ie.(ICS 4.0) 或更高版本的手机上运行。您的应用程序将无法在姜饼和 froyo 等早期版本的 android 上运行。
目标 SDK：API 17
指的是您要为其构建的 android 版本，在您的情况下是 Jellybean。建议尽可能保持最新，即（api 20 Kitkat at current context）。
编译方式：API 14
指的是你正在测试的安卓版本。使用 api 14 编译意味着您将在 ICS 上测试您的应用。
您也可以观看此视频：
【讨论】：
android:minSdkVersion
一个整数，指定应用程序运行所需的最低 API 级别。如果系统的 API Level 低于此属性中指定的值，Android 系统将阻止用户安装应用程序。您应该始终声明此属性。
android:targetSdkVersion
一个整数，指定应用程序所针对的 API 级别。如果未设置，则默认值等于提供给 minSdkVersion 的值。 此属性通知系统您已针对目标版本进行了测试，并且系统不应启用任何兼容性行为以保持您的应用程序与目标版本的前向兼容性。该应用程序仍然能够在旧版本上运行（低至 minSdkVersion）。
随着 Android 随着每个新版本的发展，某些行为甚至外观可能会发生变化。但是，如果平台的 API 级别高于您应用的 targetSdkVersion 声明的版本，系统可能会启用兼容性行为，以确保您的应用继续按照您期望的方式运行。您可以通过指定 targetSdkVersion 以匹配其运行平台的 API 级别来禁用此类兼容性行为。例如，将此值设置为“11”或更高允许系统在 Android 3.0 或更高版本上运行时将新的默认主题 (Holo) 应用到您的应用程序，并且还可以在大屏幕上运行时禁用屏幕兼容模式（因为支持 API 11 级隐式支持更大的屏幕）。
系统可能会根据您为此属性设置的值启用许多兼容性行为。 Build.VERSION_CODES 参考中的相应平台版本描述了其中一些行为。
要在每个 Android 版本中维护您的应用程序，您应该增加此属性的值以匹配最新的 API 级别，然后在相应的平台版本上彻底测试您的应用程序。 引入：API 级别 4
android:maxSdkVersion
一个整数，指定应用程序设计运行的最高 API 级别。 在 Android 1.5、1.6、2.0 和 2.0.1 中，系统会在安装应用程序以及在系统更新后重新验证应用程序时检查此属性的值。在任何一种情况下，如果应用程序的 maxSdkVersion 属性低于系统本身使用的 API 级别，那么系统将不允许安装应用程序。在系统更新后重新验证的情况下，这实际上会从设备中删除您的应用程序。
请通过此链接了解更多详情
http://developer.android.com/guide/topics/manifest/uses-sdk-element.html
【讨论】：
尽量保持简单，我可以用以下方式解释这三个术语：
最低要求 SDK： 显示您希望应用支持的最低 android 版本的设备。例如，如果您在下拉列表中选择 API 11：Honey Comb。这将表明您的应用将不支持/不会在任何 android 版本低于 Honey Comb 的 android 设备上运行。
目标 SDK： 这应该始终保持在尽可能高的位置，因为它告诉您一直针对或测试您的应用程序的最高 android 版本。所以，如果你保留你的 minReqSDK>> 11 (honey comb) 和 targetSDK>> 21 (Lollipop)，这表明你的应用程序将在从 Honeycomb 到 Lollipop 的所有 android 版本上运行，而没有兼容性问题，因为你已经设置了目标 SDK> > 21棒棒糖版。
编译方式：这与android支持任何设备无关。您可以选择使用 SDK 管理器安装的任何 android 版本来编译和运行您的应用程序以用于开发目的。
在你的情况下： 最小 SDK 版本：14 目标SDK：17 编译：14
您的设备将支持所有 api 级别 14（冰淇淋三明治）到 api 级别 17（果冻豆 4.2）的 android 版本。而且您一直在使用 api level 14 (ICS) 来编译和运行您的应用程序以进行开发。
希望这会有所帮助。
【讨论】：
简而言之，这里是声明与 minSDK 不同的 targetSDK 的目的：这意味着您使用的功能来自比您的最低级别更高级别的 SDK，但您已确保向后兼容性 。换句话说，假设您想使用最近才引入的功能，但它对您的应用程序并不重要。然后，您可以将 targetSDK 设置为引入此新功能的版本，并将最低版本设置为更低的版本，以便所有人仍然可以使用您的应用。
举个例子，假设您正在编写一个广泛使用手势检测的应用。但是，可以通过手势识别的每个命令也可以通过按钮或菜单来完成。在这种情况下，手势是“很酷的额外”，但不是必需的。因此，您可以将目标 sdk 设置为 7（引入 GestureDetection 库时为“Eclair”），并将 minimumSDK 设置为 3 级（“Cupcake”），这样即使手机非常老旧的人也可以使用您的应用程序。您所要做的就是确保您的应用在尝试使用手势库之前检查了它运行的 Android 版本，以避免在它不存在时尝试使用它。 （诚然，这是一个过时的例子，因为几乎没有人还拥有 v1.5 手机，但曾经有一段时间保持与 v1.5 的兼容性非常重要。）
再举一个例子，如果您想使用 Gingerbread 或 Honeycomb 的功能，可以使用它。有些人会很快得到更新，但许多其他人，尤其是旧硬件，可能会一直坚持使用 Eclair，直到他们购买新设备。这将使您可以使用一些很酷的新功能，但不会排除您可能的部分市场。
Android developer's blog 有一篇非常好的文章关于如何使用此功能，特别是如何设计我上面提到的“使用前检查该功能是否存在”代码。
致 OP：我写这篇文章主要是为了让将来偶然发现这个问题的人受益，因为我知道很久以前就有人问过你的问题。 here is the Post
【讨论】：
android:minSdkVersion 一个整数，指定应用程序运行所需的最低 API 级别。如果系统的 API Level 低于此属性中指定的值，Android 系统将阻止用户安装应用程序。您应该始终声明此属性。 注意：如果您不声明此属性，系统会假定默认值为“1”，表示您的应用程序兼容所有版本的Android。如果您的应用程序不兼容所有版本（例如，它使用 API 级别 3 中引入的 API）并且您没有声明正确的 minSdkVersion，那么当安装在 API 级别低于 3 的系统上时，应用程序将在运行期间崩溃尝试访问不可用的 API 时的运行时。因此，请务必在 minSdkVersion 属性中声明适当的 API 级别。
android:targetSdkVersion 一个整数，指定应用程序所针对的 API 级别。如果未设置，则默认值等于提供给 minSdkVersion 的值。 此属性通知系统您已针对目标版本进行了测试，并且系统不应启用任何兼容性行为来保持您的应用程序与目标版本的前向兼容性。该应用程序仍然能够在旧版本上运行（低至 minSdkVersion）。
随着 Android 随着每个新版本的发展，某些行为甚至外观可能会发生变化。但是，如果平台的 API 级别高于您应用的 targetSdkVersion 声明的版本，系统可能会启用兼容性行为，以确保您的应用继续按照您期望的方式运行。您可以通过指定 targetSdkVersion 以匹配其运行平台的 API 级别来禁用此类兼容性行为。例如，将此值设置为“11”或更高允许系统在 Android 3.0 或更高版本上运行时将新的默认主题 (Holo) 应用到您的应用程序，并且还可以在大屏幕上运行时禁用屏幕兼容模式（因为支持 API 11 级隐式支持更大的屏幕）。
系统可能会根据您为此属性设置的值启用许多兼容性行为。 Build.VERSION_CODES 参考中的相应平台版本描述了其中一些行为。
要与每个 Android 版本一起维护您的应用程序，您应该增加此属性的值以匹配最新的 API 级别，然后在相应的平台版本上彻底测试您的应用程序。
引入：API 级别 4
android:maxSdkVersion 一个整数，指定应用程序设计运行的最大 API 级别。 在 Android 1.5、1.6、2.0 和 2.0.1 中，系统会在安装应用程序以及在系统更新后重新验证应用程序时检查此属性的值。在任何一种情况下，如果应用程序的 maxSdkVersion 属性低于系统本身使用的 API 级别，那么系统将不允许安装应用程序。在系统更新后重新验证的情况下，这实际上会从设备中删除您的应用程序。
为了说明此属性在系统更新后如何影响您的应用程序，请考虑以下示例：
在其清单中声明 maxSdkVersion="5" 的应用程序已在 Google Play 上发布。设备运行 Android 1.6（API 级别 4）的用户下载并安装应用程序。几周后，用户会收到 Android 2.0（API 级别 5）的无线系统更新。安装更新后，系统会检查应用程序的 maxSdkVersion 并成功重新验证。应用程序正常运行。但是，一段时间后，该设备收到了另一个系统更新，这次是 Android 2.0.1（API 级别 6）。更新后，系统无法再重新验证应用程序，因为系统自身的 API 级别 (6) 现在高于应用程序支持的最大值 (5)。系统会阻止用户看到该应用程序，实际上是将其从设备中删除。
警告：不建议声明此属性。首先，无需将属性设置为阻止将应用程序部署到新版本 Android 平台上的方法，因为它们已发布。根据设计，该平台的新版本完全向后兼容。您的应用程序应该在新版本上正常工作，前提是它只使用标准 API 并遵循开发最佳实践。其次，请注意，在某些情况下，声明该属性可能会导致您的应用程序在系统更新到更高的 API 级别后从用户的设备中删除。大多数可能安装您的应用程序的设备都会通过无线方式定期接收系统更新，因此您应该在设置此属性之前考虑它们对您的应用程序的影响。
引入：API 级别 4
Android 的未来版本（Android 2.0.1 之后）将不再在安装或重新验证期间检查或强制执行 maxSdkVersion 属性。但是，在向用户提供可供下载的应用程序时，Google Play 将继续使用该属性作为过滤器。
查看更多，点击这里：use sdk
【讨论】：