Eclipse中的"Build Target SDK"和AndroidManifest.xml中的android:targetSdkVersion之间的区别？

Question

当我将现有的Android项目导入Eclipse时,我被要求选择SDK构建目标作为该过程的一部分.

为什么我需要输入这些信息？这与android:targetSdkVersion/android:minSdkVersion指定的值AndroidManifest.xml有何不同？

例如,在Google IO示例应用程序中,其AndroidManifest说android:targetSdkVersion=11,但README表示Eclipse项目需要针对API级别13或更高级别,否则将发生编译错误.

Answer 1

android:minSdkVersion 在清单文件中意味着市场将过滤具有较低sdk的设备.

target=android-x在项目属性文件中意味着Eclipse不允许使用高于x的sdk中的方法或类.它将显示编译器错误.

您可以像这样使用它:在清单中提供最小版本 - 取决于您的应用程序关键功能.将相同的值设置为项目属性.然后,如果您想使用来自更高SDK的某些API - 在项目属性中提高值,并使用检查包装代码是否设备API可以执行此代码:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.ECLAIR_MR1)
{
    // here you can use APIs, that appears in Android 2.1
}

Answer 2

以下是每个属性的描述,它正是它控制的内容,以及如何使用它.

在AndroidManifest.xml:

• midSdkVersion:由Google Play电影市场使用.允许您的应用运行的最低API.运行早于此版本的Android的设备将无法安装您的应用.将此设置为您的代码可以支持的最低版本的android(即,它不使用比此更新的任何API调用,而不特别注意向后兼容性).当然,您应该在运行此版本的设备或模拟器上进行测试.

  Google提供了一个信息中心,为您提供使用每个版本的人数细分,这在确定是否可以停止支持每个版本时非常有用.

  注意:如果您使用的是任何android-support库,则不应使用支持库名称中指定的旧版本.例如,android-support-v4.jar不会在早于4的Android版本上运行.

• targetSdkVersion:在运行时由设备使用. 设备使用此选项来决定是否以向后兼容模式运行您的应用程序.例如,如果将此设置为10(Gingerbread)设备运行16(Jelly Bean)仍将使用Gingerbread的视觉样式为您的应用程序; 例如,它将有一个标题栏而不是一个操作栏.将此设置为您希望应用程序看起来像的最新版本的Android (您只能通过在较新版本上测试它来确定它是否看起来很好并且表现良好).

在project.propertiesEclipse中Project Build Target设置或设置:

• target:在编译时由您的计算机使用. 您的应用编译的Android版本.尝试使用比此更新的API功能将导致错误.您应该将此设置为相同,minSdkVersion除非您为了向后兼容而执行特殊操作(请参见下文),以便编译器可以防止您意外使用用户旧设备上不存在的功能(导致其崩溃).

  注意:您包含的库项目可能需要此值的最小值.例如,android-support-v7-appcompat包含.xml资源文件,res/layout-v14其中要求您针对API 14或更新版本进行编译.

关于向后兼容性的说明:

有一种情况project.properties应该高于minSdkVersion:当您想要使用更新的API功能时,但是包含特殊代码以实现向后兼容性以允许它在旧设备上运行.在这种情况下,您必须project.properties使用包含您使用的所有功能的最旧API进行匹配.

如果可能,请使用Android支持库来实现向后兼容性,因为它是传统的,经过良好测试的,易于使用,并且允许您project.properties独自离开.但是,有时支持库不能满足您的需求,在这种情况下,你将不得不使用的技术,如这个或这些

Answer 3

问题的核心是:项目清单中声明的​​targetSdkVersion值与Eclipse中项目的Project/Properties/Android对话框中选择的Project Build Target之间的关系是什么,它选择了应用程序的SDK级别编译？

minSdkVersion值会分散您的问题; 这必须小于或等于targetSdkVersion,但它与Project Build Target 没有直接关系.关系在targetSdkVersion和Project Build Target之间.

经过仔细考虑(你必须自己判断我是否有这个权利),我得出结论,targetSdkVersion和Project Build Target应始终设置为相同的API级别.我的推理分为两部分.

**首先,我认为Project Build Target永远不应低于targetSdkVersion:

当您将targetSdkVersion设置为某个API级别时,通常这样做是为了使用首先在该级别可用的某些API功能.您可能决定支持版本回到较早的minSdkVersion,并检测缺少早期版本中不可用的targetSdkVersion功能,并编写支持早期版本的备用代码,但您设置targetSdkVersion 的原因是获取对该API级别仅提供的功能的访问权限.

由于您显然想要访问最初在targetSdkVersion API级别引入的某些功能,因此您可以将Project Build Target设置为与targetSdkVersion中指定的API级别相同.否则,您要编译的API将不包含API功能,这是您将targetSdkVersion设置为所选级别的原因.

所以,显然,您不希望将Project Build Target设置为低于 targetSdkVersion.但是你想要把它设置得更高吗？这让我们得出了论证的第二部分:

**其次,我认为项目构建目标永远不应高于targetSdkVersion:

您不希望选择高于targetSdkVersion的Project Build Target,因为这可能意味着您可能无意中使用了Build Target的SDK提供的某些功能,这些功能在您声明的targetSdkVersion级别不可用,并且您确实使用了这些功能,如果您的应用程序是在早期(比构建目标)Android版本中运行的话,它们将无法使用,因此您的应用可能会因此崩溃.

现在,如果您的应用程序承诺自己检测这些缺失的功能并处理它们的缺失,那么这将证明将targetSdkLevel设置为Project Build Target的级别是正确的,因为这正是targetSdkLevel(您承诺检测)的含义处理你的targetSdkLevel上但不存在于你的minSdkLevel中的任何API特性,所以如果你这样做,那么就没有理由不将你的targetSdkLevel设置为你在代码中支持的最高级别(即,达到项目构建目标的水平).

[好吧,我刚刚找到一个"原因"来将Project Build Level设置为高于targetSdkLevel.API级别16及更高版本的默认软键盘是错误的(其退格键无法正常工作),因此我将targetSdkLevel向下移动到15以使该键盘消失.我本可以将我的项目构建目标更改为15,但我没有这样做,因为我想要最新的代码,理论上最近通常会"改进"并因此"更好".这可能是迷信的.尽管有这个例外,上述论点通常都是有效的.]

在这方面,我要注意官方文档声明:"在开发应用程序时,您需要选择要编译应用程序的平台版本.通常,您应该尽可能地编译应用程序您的应用程序可以支持的平台版本."

http://developer.android.com/guide/topics/manifest/uses-sdk-element.html

这似乎表明你应该编译一个等于minSdkVersion而不是targetSdkVersion的Project Build Target,这与我上面提到的相反.我已经列出了支持targetSdkVersion的原因,而不是这个.具体来说,如果您尝试使用targetSdkVersion中存在但不存在于minSdkVersion中的功能,那么如果您正在编译minSdkVersion,您将如何能够这样做？当然,你的应用程序将运行在的minSdkVersion,因为你会被用于测试这些功能的可用性(例如,通过反射),但你不会有那些漂亮的新API元素不断,即使您的应用程序在运行最新Android的版本,如果你编译SDK的minSdkVersion级别.

因此,项目构建目标应始终与targetSdkVersion相同; 这是我的论点.我找不到任何明确阐述这种关系的材料,所以上面是由我推断的,并没有得到任何权威来源的支持,事实上,官方来源的上述引用似乎与我的立场相矛盾; 因此鼓励和期望评论.

Answer 4

每个 android 版本都分配给 android:targetSdkVersion。高版本的项目无法在低版本的模拟器上运行，但反之亦然。确保您的sdk已更新并尝试将项目更改为相应版本