呆呆大虾Android开发-API指南-设备兼容性
Device Compatibility
英文原文：http://developer.android.com/guide/practices/compatibility.html
采集日期：2014-5-4
搬迁自原博客：http://blog.sina.com.cn/s/blog_48d491300101h5cj.html
Android 正是为能够在运行于各类设备而进行设计的，这些设备包括手机、平板电脑直至电视机。 对于一名开发人员而言，如此大范围的设备能让应用程序的用户群体潜力巨大。 为了能在所有设备上成功运行，你的应用程序应该能够容许某些硬件差异，并提供灵活的用户界面来适应各种屏幕参数。
为了帮助你获得兼容性，Android 提供了一套动态应用程序框架，你可以用它在静态文件中给出可配置的 应用程序资源 （诸如对应各种屏幕尺寸的不同 XML Layout）。Android 会根据当前设备的配置载入相应的资源。 因此，通过预先设计加上一些应用程序资源，你可以只发布一个应用程序包（APK）就能为各种设备提供优化过的用户体验。
不过，如果必要的话，你也可以设定应用程序的设备需求，并且控制可通过 Google Play Store 安装的设备类型。 本文解释了你如何对可访问应用程序的设备进行控制，以及如何为确保应用程序安装到合适的受众而进行准备。 关于如何让应用程序适应各种不同的设备，详情请参阅 支持各种设备。
“兼容性”的含义
随着对 Android 开发的深入了解，你可能会在各种情况下碰到“兼容性”这个名词。 兼容性分为两种：设备兼容性和应用程序兼容性。
因为 Android 是一个开源的项目，任何硬件制造商都能制造出某种运行 Android 操作系统的设备。 但是，只有能正常运行为 Android 可执行环境编写的程序，才是“Android 兼容”的设备。 对于 Android 可执行环境的准确定义，在 Android compatibility program 中给出，并且所有设备都必须通过兼容性测试包（CTS）的测试。
作为开发人员，你不必担心设备是否为 Android 兼容的，因为只有 Android 兼容的设备才会包含 Google Play Store 。 因此你尽可放心，从 Google Play Store 中安装应用程序的用户都是使用了 Android 兼容的设备。
不过，你还是需要考虑在所有可能设备配置上的应用程序兼容性。 因为可能运行 Android 的设备配置众多，某些特性并不是所有的设备都能提供。 例如，某些设备可能不包含罗盘（传感器）。 如果核心功能需要使用罗盘，那么应用程序就只能适用于那些带有罗盘的设备。
掌控应用程序的设备兼容性
Android 提供了丰富的特性，你的应用程序可以通过平台 API 来充分利用它们。 某些特性是基于硬件的（比如罗盘传感器），有些是基于软件的（比如 Widget），有些则依赖于平台版本。 因为并非所有设备都支持全部的特性，所以你可能要根据功能需求来控制应用程序对设备的适用范围。
为了让应用程序赢取尽可能多的用户群，你应该使用一个 APK 支持尽可能多样的设备。 通过在运行时禁用某些可选功能，或者根据不同的配置提供替代资源（比如为各种屏幕尺寸对应不同的 Layout）， 大多数情况下你都可以做到这一点。 如果必要的话，你可以通过 Google Play Store 从以下几方面限制应用程序的适用范围：
设备配置
为了能够根据设备配置控制应用程序的适用范围， Android 为每个不一定所有设备都能支持的硬件或软件特性都定义了一个
特性 ID。 例如，罗盘传感器的特性 ID 是FEATURE_SENSOR_COMPASS
，Widget 的特性 ID 是
FEATURE_APP_WIDGETS。
如果必要的话，通过在
Manifest 文件的
< uses-feature >
元素中进行声明，你可以阻止用户在不提供给定特性的设备上安装应用程序。
例如，如果你的应用程序在缺少罗盘传感器的设备上无法使用，你就可以用以下 manifest 标签将罗盘传感器声明为必需项：
<manifest ... > <uses-feature android:name="android.hardware.sensor.compass" android:required="true" /> ... </manifest>
Google Play Store 将会把应用程序的需求和用户设备的配置进行比较，以确定应用程序的兼容性。 如果设备无法满足全部的需求，用户就无法安装你的应用程序。
不过，如果应用程序的主要功能并不是必需某个设备配置，你就应该将 required 属性设为"false"，并且在运行时自行检查设备配置的可用性。 如果当前设备不提供应用程序所需的配置，请平稳地对相关需求进行降级。 例如，你可以通过如下调用 hasSystemFeature() 查询可用的配置：
1 PackageManager pm = getPackageManager(); 2 if (!pm.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)) { 3 // This device does not have a compass, turn off the compass feature 4 disableCompassFeature(); 5 }
关于 Google Play Store 上可用于控制应用程序可用性的全部过滤器，请参阅文档 Google Play 上的过滤器 。
注意：某些 系统权限 隐含了对某个设备配置的需求。例如，假如应用程序请求了对 蓝牙 的访问权限，那么就隐含了对 FEATURE_BLUETOOTH 的设备需求。通过将 < uses-feature > 标签中的 required 属性设为"false"，你可以关闭与之相关的过滤，这样在没有蓝牙的设备上也可以使用此应用程序。 关于对设备配置隐含需求的更多信息，请参阅 隐含了设备配置需求的权限。
平台版本
不同的设备可能运行不同的 Android 平台版本，比如 Android 4.0 或 Android 4.4。 较高的版本往往会在低版本系统中新增一些 API。 为了便于识别当前可用的 API 集，每个平台的版本都会被定义一个 API 级别。 例如，Android 1.0 是 API 级别1，Android 4.4 是 API 级别19。
通过 manifest 标签 < uses-sdk > 及其 minSdkVersion 属性，你可以用 API 级别来声明应用程序可兼容的最低系统版本。
例如， Calendar Provider API API 是从 Android 4.0（API 级别 14）开始引入的。 如果没有此类 API 应用程序就无法正常使用了，你就应该把最小支持版本声明为 API 级别14：
<manifest ... > <uses-sdk android:minSdkVersion="14" android:targetSdkVersion="19" /> ... </manifest>
minSdkVersion 属性声明了应用程序可兼容的最低系统版本， targetSdkVersion 属性则声明了应用程序已优化过的最高系统版本。
高版本的 Android 系统可以兼容较低版本 API 编译出来的应用程序，因此只要使用了公开的 API，应用程序就应该可与未来的 Android 版本兼容。
注意： targetSdkVersion 属性并不能阻止应用程序在更高版本的平台上安装，但是系统可以通过它得知应用程序是否会适用较高版本的特性变动，因此它非常重要。 如果你没有把 targetSdkVersion 修改为最新的版本，如果在最新版本的平台上运行时，系统会假定应用程序还是需要用到某些向后兼容的特性。 例如，在 Android 4.4 的特性变化 中，使用 AlarmManager API 创建的 Alarm 提醒时间缺省将不再精确，这样系统可以批量处理 Alarm 以节省电力。 但是如果应用程序的目标 API 级别小于 19，则系统仍然会沿用之前的 API 特性。
不过，假如应用程序用到了最新版本的 API，但是主体功能却不需要使用， 你就应该在运行时检查 API 级别，并在 API 版本过低时平稳地降低对系统特性的需求。 在这种情况下，请把 minSdkVersion 设置为程序主体功能需要的最低版本，并将当前系统的版本 SDK_INT 与程序所需 API 级别对应的代码常量相比较，这些常量在 Build.VERSION_CODES 中给出。 例如：
1 if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) { 2 // Running on something older than API level 11, so disable 3 // the drag/drop features that use ClipboardManager APIs 4 disableDragAndDrop(); 5 }
屏幕参数
Android 可以在各种尺寸的设备上运行，从手机、平板电脑到电视机。 为了将这些设备的屏幕进行归类，Android 定义了两类参数：屏幕尺寸（物理尺寸）和屏幕密度（显示点阵的物理密度，被称为DPI）。 为了简化对各种配置的描述， Android 把这些参数概括为几种，这也便于使用时对号入座：
- 尺寸归纳为四种： small 、normal 、large 和 xlarge。
- 屏幕密度归纳为： mdpi （medium）、 hdpi （hdpi）、 xhdpi （超高）、 xxhdpi （超超高）等等。
默认情况下，应用程序要兼容所有的屏幕尺寸和密度，因为系统会根据实际的屏幕参数适时调整 UI 布局和图片资源。 不过，为了提供最佳的用户体验，你应该根据屏幕参数添加各种屏幕尺寸对应的 Layout ，以及为常见屏幕密度优化过的位图资源。
关于为各类屏幕创建替代资源，及必要时将应用程序的适用范围限定为某些尺寸的屏幕，详情请参阅 支持各种屏幕。
掌控应用程序的商业兼容性
除了考虑设备参数之外，可能还会由于商业或法律的原因来限制应用程序的适用范围。 例如，显示伦敦地铁时刻表的应用程序对于英国之外的用户就不怎么有用。 这种情况下， Google Play Store 向开发人员提供了相应过滤项，以便出于非技术因素对应用程序的适用范围进行控制， 这些因素可以是用户位置或无线运营商。
技术方面的兼容性过滤（比如硬件需求）都基于你的 APK 文件进行。 但非技术性因素（比如地理位置）的过滤则全由 Google Play 的开发人员界面来控制。
