安卓系统api 怎么保障兼容性（安卓API引导-设备兼容性）

安卓系统被设计运行于许多不同的设备上，从移动电话，到平板电脑和电视作为开发者，广泛的设备支持为你的应用提供了大量的潜在用户为了让你的应用成功地运行在所有设备上，它应该容许一些功能上的差异，并提供一个可以适应不同屏幕配置的灵活的界面，今天小编就来聊一聊关于安卓系统api 怎么保障兼容性?接下来我们就一起去研究一下吧!

安卓系统api 怎么保障兼容性

安卓系统被设计运行于许多不同的设备上，从移动电话，到平板电脑和电视。作为开发者，广泛的设备支持为你的应用提供了大量的潜在用户。为了让你的应用成功地运行在所有设备上，它应该容许一些功能上的差异，并提供一个可以适应不同屏幕配置的灵活的界面。

为了方便你朝这个目标努力，安卓系统提供了一个动态应用框架，让你可以从中在静态文件里提供特定配置的应用资源（如不同屏幕尺寸的XML布局）。然后，安卓系统会根据当前设备配置加载适当的资源。因此，若为应用设计预先计划（1）并提供一些额外的应用资源，你就可以发布一个为各种设备优化过界面的独立应用包（APK）。

但是，如果必要，你可以指定应用的功能需求，并控制让那些类型的设备可以从安卓商店中安装你的应用。这篇文档会告诉你如何控制那些设备可以访问你的应用，如何准备你的应用来保证他们到达正确的用户。更多关于如何让你的应用适应不同的设备的信息，请阅读支持不同设备。

“兼容性”是什么意思?

当你阅读更多关于安卓开发的信息时，可能会在各种情况里遇到“兼容性”一词。有两种“兼容性”类型：设备兼容性和应用兼容性。

因为安卓系统是一个开源项目，任何硬件厂商都可以创建一个可以运行安卓操作系统的设备。然而，只有当设备可以正确的运行为安卓运行环境所写的应用时，才表示它是“安卓兼容”的。安卓运行环境的具体细节都在安卓兼容程序中定义，要被认定为兼容的，每个设备都必须通过兼容性测试套件（CTS）。

作为应用开发者，你无需考虑设备是否安卓兼容的，应为只有安卓兼容的设备才会包含谷歌应用商店。所以，你可以放心，从安卓应用商店安装你应用的用户正使用的是安卓兼容的设备。

但是，你需要考虑的是你的应用是否能兼容每一个潜在的设备配置。因为安卓系统运行在多种设备配置上，某些功能不会在所有设备上都有效。例如，一些设备可能没有指南针传感器。如果你的应用的核心功能需要指南针传感器，那么它只能安装在拥有指南针传感器的设备上。

控制你的应用对设备的可用性

安卓系统支持很多种功能，你可以通过平台API来使用。有些功能是基于硬件的（如指南针传感器），有些是基于软件的（如应用窗口小部件），还有一些依赖于平台版本。不是每个设备都支持每一个功能，因此，你可能需要根据应用所需功能来控制应用对设备的可用性。

为了使你的应用尽量获得最大的用户群，应该努力使用单独的APK文件来支持尽可能多的设备配置（如为不同的屏幕尺寸使用不同的布局）。大多情况下，你可以通过在运行时禁用可选功能，为不同配置提供替换的应用资源来做到这点。但是，如何有必要，你可以从谷歌应用商店根据以下设备特性来限制对设备的可用性：

设备功能

为了根据设备功能管理应用可用性，安卓系统为每个可能不会在所有设备上都有效的硬件或软件的功能定义了功能ID。例如，指南针的功能ID FEATURE_SENSOR_COMPASS,应用窗口小部件的功能IDFEATURE_APP_WIDGETS。

如果有必要，你可以通过在应用清单中声明<user-feature>元素来阻止那些其设备没提供给定功能的用户安装你的应用。

例如，如果你的应用在没有指南针传感器的设备上是无用的，那么可以用如下清单标签来声明指南针传感器为required：

谷歌应用商店会比较你的应用所必需的功能和每个用户设备的有效功能来决定你的应用是否兼容每个设备。如果设备没有提供应用需要的所有必需功能，则用户不能安装你的应用。

但是，如果你的应用的主要功能不需要设备功能，你应该将required属性设为“false”，并在运行时检测设备功能。如果你的应用功能在当前设备上无效，要合理的取消相应的应用功能。例如，你可以像这样调用hasSystemFeature来查询功能是否有效：

<code>PackageManager pm = getPackageManager;if(!pm.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)){ // This device does not have a compass, turn off the compass feature disableCompassFeature;} </code>

更多关于所有可通过谷歌应用商店用来控制应用对于用户的可用性的信息，请看谷歌应用商店过滤器文档。

注意：一些系统权限隐含需要设备功能。例如，你的应用请求访问蓝牙的许可，这隐含需要FEATURE_BLUE_TOOTH的设备功能。你可以禁用基于这个功能的过滤器，通过在这个标签里设置required属性为"false"来让你的应用没有蓝牙也有效。更多关于隐含需求设备功能的信息，请阅读隐含设备功能需求。

平台版本

不同的设备可以运行不同版本的安卓平台，如安卓4.0 或安卓4.4。每个连续的平台版本通常会添加在以往版本中无法使用的新API。为了表明哪组API可以用，每个平台版本都指定了一个API级别。例如，安卓1.0 是API级别1，安卓4.4是API级别19。

API级别允许你使用<uses-sdk>清单标签，和它的minSdkVersion属性来声明应用兼容的最低版本。

例如，安卓4.0（安卓级别14）添加的日历提供者API，你应该像这样声明来表示应用支持的最低版本为API级别14：

minSdkVersion属性声明了应用兼容的最低版本，targetSdkVersion属性声明了你已为应用优化所用的最高版本。

每个后续的安卓系统版本都对使用以往平台版本构建的应用提供了兼容性，因此当使用已发布（2）的API时，你的应用应该总是与未来安卓系统版本相兼容。

注意：targetSdkVersions属性不会阻止应用安装到比指定版本更高的平台上，但它很重要，因为它表明了你的应用是否应该继承新版本的行为变化。如果你不更新targetSdkVersions到最新的版本，当应用运行在最新版本上时，系统会假定其需要向后兼容。例如，在安卓4.4版本的变更中，现在，默认情况下使用AlarmManagerAPI创建的警告是不准确的，所以系统可以成批处理应用警告来节省电量，但是如果你的目标API级别低于“19”系统会为应用保留以前API的行为。

但是，如果你的应用使用了最近平台版本的API，但主要功能并不需要，那么当API级别太低时，你应该在运行时检测API级别，并合理的取消相应的功能。这种情况下，为你的主要功能，把minSdkVersion设置成尽可能低的版本，然后比较当前系统版本SDK_INT与你想要检测的相应API级别的代码名称常量Build.VERSION_CODES。例如：

<code>if(Build.VERSION.SDK_INT <Build.VERSION_CODES.HONEYCOMB){ // Running on something older than API level 11, so disable // the drag/drop features that use ClipboardManager APIs disableDragAndDrop;} </code>