标签：
声明：
本文由Gordon翻译
欢迎转载，但请保留此声明
原文地址：http://developer.android.com/guide/practices/compatibility.html
Android可以运行在不同类型的设备上，从手机到平板以及电视都可以运行。这些不同的设备将为开发者提供大量的潜在用户。那么为了能够让你的应用在所有的设备上运行良好，你就需要接受一些特性的多样性以及提供一个不同屏幕配置的友好的用户接口。
为了达到这样的目的，Android提供了一个动态的框架。开发者只需要在此基础上提供一个包含不同配置应用资源的静态文件（比如不同的屏幕大小对应的不同的XML布局）。然后，Android就会根据不同的设备配置加载相应的资源文件。因此，只要一点有预见性的应用设计加上一些额外的应用资源，你就可以让你的应用只需要一个应用包（APK）就可以在不同的设备上运行良好。
当然，若是有必要，你可以指定你的应用性能需求，这样Google应用商店就可以控制哪些设备能够安装你的应用。本文将会讲解如何让你的应用控制使用的设备以及如何保证你的应用被合适的用户访问。更多的关于如何让应用适配不同的设备请阅读“Supporting Different Devices”章节。
在阅读Android开发手册的时候，你在不同的情况下将都会遇到“兼容性”这个词。总得来说，有两种类型的兼容性：设备的兼容性和应用的兼容性。
因为Android是一个开源的项目，任何硬件厂商都可以生产一个运行Android操作系统的设备。然而，只有当设备可以正确运行基于Android执行环境写的应用时，我们称之为“Android兼容的”。关于Android执行环境的细节方面是在“Android Compatibility program”中定义的，并且每个设备都需要通过兼容性测试（CTS）才能认为是可兼容的。
作为一个应用开发者，你不需要担心设备是否是Android兼容的，因为只有Android兼容的设备才能使用Google应用商店。所以，你可以认为那些从Google应用商店安装你的应用的用户使用的都是Android兼容的设备。
但是，你确实需要确定你的应用是否在各种设备配置下都是兼容的。因为Android在很多不同配置的设备上运行，不是所有的特性在任何设备都支持的。例如，一些设备就可能不支持罗盘传感器，假如你的应用要求一个罗盘传感器，那么你的应用就只和那些有罗盘传感器的设备兼容。
应用可以通过平台的API来使用Android支持的各种特性，一些特性是和硬件相关的（比如罗盘传感器），一些是和软件相关的（比如应用的小部件）以及一些是和平台版本相关的。不是所有的设备都支持所有的特性，所以你需要基于你应用的需求来控制对设备的兼容性。
为了让你的应用能够被最大限度地被用户使用，你需要努力让你的应用能够使用一个APK兼容尽可能多的设备。在大多数情况下，你可以通过在运行时禁止可选的特性以及对不同的配置提供可选的应用资源（比如对不同的屏幕大小使用不同的布局）来实现这样的目的。假如有必要，你可以通过Google应用商店基于以下的设备特性来决定是否可以安装你的应用：
为了能够根据设备的特性管理应用的兼容性，Android对那些不是在所有设备上都存在的硬件和软件特性定义了一个特性ID。比如，罗盘传感器的特性ID就是FEATURE_SENSOR_COMPASS以及应用小部件的特性ID就是FEATURE_APP_WIDGETS。
假如有必要，你可以在应用的Manifest文件中声明一个<uses-feature>元素，这样不支持这些特性的设备就不能安装你的应用。
举例来说，假如你的应用对没有罗盘传感器的设备不感兴趣，那你就可以像下面这样在manifest文件中声明一个罗盘传感器的需求：
<manifest ... > <uses-feature android:name="android.hardware.sensor.compass" android:required="true" /> ... </manifest>
Google应用商店会把你的应用的特性需求和用户设备的可用特性进行比较，然后来确定你的应用是否符合对应的设备。若是设备没有支持应用所需要的所有特性，则用户就不能安装你的应用。
当然，假如你的应用主要功能并不需要这样的设备特性，你就应当设置required属性为false，然后在应用运行的时候再检查对应的设备特性。若是设备不支持这些特性，就需要把相关的应用特性关闭。举例来说，你可以按如下所示来调用hasSystemFeature()函数查询设备是否支持对应的特性：
PackageManager pm = getPackageManager();
if (!pm.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)) {
// This device does not have a compass, turn off the compass feature
disableCompassFeature();
}
更多的关于使用Google应用商店来控制应用是否可用可以参考“Filters on Google Play”文档。
注意：一些系统权限和设备特性是相关的。比如，你的应用请求访问BLUETOOTH（蓝牙）的权限，这隐含的意思就是需求FEATRUE_BLUETOOTH的设备特性。你可以通过设置<uses-feature>中的required为”false”来防止把不支持蓝牙的设备过滤掉。更多的隐含请求的资讯请阅读“Permission that Imply Feature Requirements”。
不同的设备可能运行不通的Android平台版本，比如Android4.0,android4.4等。新的版本经常会加入一些之前版本不支持的新的API。为了说明哪些API是可用得，每一个平台版本都指定了一个API level。比如Android1.0是API level 1以及Android4.4是API level 19。
应用可以使用API level来声明兼容的最低版本，可以使用<uses-sdk>标签中的minSdkVersion属性。
例如，Calendar Provider API是在Android 4.0中加入的（API level 14）。假如你的应用没有这些API就不能工作，你就应当声明应用支持的最小版本是API level 14：
<manifest ... > <uses-sdk android:minSdkVersion="14" android:targetSdkVersion="19" /> ... </manifest>
minSdkVersion属性是应用所能兼容的最小版本，targetSdkVersion属性是应用已经优化过的最高版本。
所有的Android版本都是向前兼容的，所以高版本的应用应当都是支持旧版本的Android API的。
注意：targetSdkVersion并不阻止高于这个版本值的设备安装应用，但是这个值也是很重要的，因为它表明了你的应用是否继承了新的版本的行为变化。假如你没有更新targetSdkVersion的值到最新的版本，在最新版本上运行的系统就会认为你的应用需要一些先前兼容的特性。例如，在Android4.4的行为改变中，通过AlarmManager API创建的闹钟默认将不正确，这样系统就可以分批处理应用闹钟从而节省系统功耗。但是假如你的应用目标API level小于9，系统就会保持这个之前的API。
然而，当你的应用使用了最新的平台版本的API，但是主要功能中并没有使用这个API，你就应当在运行的时候检查API level，然后对于API level较低的时候进行一些处理。这种情况下，就设置minSdkVersion为主要功能的最低值就可以了，然后在代码中比较当前系统的版本，SDK_INT就是在Build.VERSION_CODES中定义的表示API level的宏。举例如下：
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();
}
Android会在不同屏幕大小的设备上运行，比如手机，平板和TV。为了通过屏幕的类型来分类设备，Android为每个设备定义了两个属性：屏幕大小（屏幕的物理大小）以及屏幕密度（屏幕像素的密度，称为DPI）。为了简化不同的配置，Android把他们分成了以下几类：
四个通用的大小值：小，中等，大和超大。
一些通用的密度值：mdpi(中等)，hdpi，xhdpi(特别高)，xxhdpi（特别特别高）以及别的。
默认来说，你的应用应当和所有的屏幕大小以及密度兼容，因为系统会根据屏幕对你的UI布局以及图片资源进行自适应的调整。然后，你需要根据不同的屏幕配置来加入不同的布局以及图片，这样用户才会有更好的体验。
更多的关于如何根据不同的屏幕配置来创建可选的资源，以及如何让你的应用使用不同的屏幕大小，可以参阅“Supporting Different Screen”章节。
除了设备属性导致的应用兼容性外，还有可能有商业和法律原因到指定的应用兼容性。比如一个显示伦敦地铁运行的时刻表的应用，可能对英国之外的地方是没有用得。这种情况下，Google应用商店在开发者界面提供了一些过滤的选项，让你可以不需要进行技术上的处理就能够控制应用的有效性，比如用户的地址或者无线载波。
技术上的兼容性的过滤总是基于APK文件的信息进行。而非技术性的过滤则是通过Google应用商店的开发者控制界面来进行过滤的。
紧接着你可以阅读下面的内容：
Providing Resources
它是关于Android应用如何把不同的应用资源和应用代码结合起来以及如何为不同的设备配置提供不同的资源。
Filters on Google Play
它是关于Google应用商店使用的不同方法来防止你的应用安装在不同设备上。
这些章节你也可能感兴趣：
它是关于Android应用如何把不同的应用资源和应用代码结合起来以及如何为不同的设备配置提供不同的资源。
Android API Guides –Device Compatibility
标签：
原文地址：http://blog.csdn.net/u011960402/article/details/47438803
