标签：
原文地址：Device Compatibility
Android设计于运行在多种不同类型的设备上，从手机、平板到电视。作为一名开发者，设备的涵盖范围为你的app提供了广大的潜在用户。为了让你的app能在这些设备上成功运行，它应该容许一些特性差异，并提供灵活的UI来适配不同的屏幕配置。
为了促进你的努力能达到目标，Android提供了动态应用框架，可以让你在静态文件中放入指定配置的应用资源（比如对应不同屏幕尺寸的XML布局文件）。Android会根据当前的设备配置来加载适当的资源。所以，预先想好你的应用设计和额外的应用资源，你就可以发布出单个应用包（apk），为多设备提供优化的用户体验。
如果必要的话，你也可以指定app的特性需求，控制哪些类型的设备可以从Google Play Store（应用商店）上安装你的app。这篇文会向你说明如何控制哪些设备可以使用你的app，让你的app到达正确的用户手中。更多关于适配不同设备的信息，请阅读支持不同设备。
"兼容性"意味着什么？
随着你阅读更多关于Android开发的资料，你会在多种情况下遇到“兼容性”这个术语。有两种类型的“兼容性”：“设备兼容性”和“应用兼容性”。
因为Android是一个开源项目，任何硬件厂商都可以开发出运行Android操作系统的设备。只有当设备能够正确运行针对于Android执行环境开发的app，才算是“兼容Android”。Android执行环境的确切细节，由Android兼容计划定义，每个设备必须通过“兼容性测试套装”（CTS）才能被视为兼容。
作为一名应用开发者，你不必担心设备是否兼容Android，因为只有兼容Android的设备才会有Google Play Store。所以你大可放心，从Google Play Store上安装你的app的用户使用的是兼容Android的设备。
然而，你确实需要考虑你的app是否兼容各种潜在的设备配置。由于Android运行在各种设备配置上，有些特性并不是在所有设备上都可用。举个例子，有些设备可能不包含指南针传感器。如果你的app的核心功能要求使用指南针传感器，那么你的app只兼容具有指南针传感器的设备。
控制app在设备上的可用性
Android支持广泛的特性，你的app可以利用平台的API获得它们。有些特性是基于硬件的（比如指南针传感器），有些是基于软件的（比如应用小组件），而有些是依赖于平台版本。不是每一种设备都支持每一种特性，所以你可能需要根据app要求的特性，来控制你的app对设备的可用性。
为了让app达到最大的用户基础，你要努力让单个apk来支持尽可能多的设备配置。在大多数情况下，你可以通过在运行时禁用某些特性，为不同配置（比如对应不同屏幕尺寸的布局）提供可替换的应用资源来达到目的。然而如果必要的话，你可以根据以下设备特点来限制设app在设备上的可用性：
设备特性
为了让你能基于设备特性来管理app的可用性，Android为可能不可用的硬件或软件特性定义了“特性ID”。举个例子，指南针传感器的特性ID是FEATURE_SENSOR_COMPASS，而应用小组件的特性ID是FEATURE_APP_WIDGETS。
如果必要的话，你可以通过在app的manifest文件的<uses-feature>元素中声明，来避免用户的设备不提供该项特性时仍安装应用。
举个例子，如果你的app对于没有指南针传感器的设备没有意义的话，你可以在下面的manifest标签中声明要求指南针传感器：
<manifest ... > <uses-feature android:name="android.hardware.sensor.compass" android:required="true" /> ... </manifest>
Google Play Store会比较你的app要求的特性和每个用户的设备的可用特性，来决定你的应用是否和设备兼容。如果设备没有提供app要求的全部特性，用户则安装不了你的app。
但是，如果app的主要功能并不要求设备特性，你应该把"required"属性设成"false"，并在运行时检查设备特性。如果app特性在当前设备上不可用，那么优雅地不使用对应的特性。举个例子，你可以通过调用hasSystemFeature()来查询特性是否可用：
PackageManager pm = getPackageManager(); if (!pm.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)) { // This device does not have a compass, turn off the compass feature disableCompassFeature(); }
关于你能够控制用户对app可用性的过滤条件信息，请看文档Google Play的过滤。
注意：有些系统权限会隐式地要求设备特性的可用性。举个例子，如果app申请了访问蓝牙的权限，就隐式地要求有FEATURE_BLUETOOTH的设备特性。你可以通过在<uses-feature>标签中设置require属性为false，来禁止基于这个特性的过滤条件，让app可以用于没有蓝牙的设备。关于隐式要求设备特性的更多信息，请读暗示要求特性的权限。
平台版本
不同设备可能运行不同版本的Android平台，如Android4.0或Android4.4。每个连续的平台版本往往会增加上一个版本不可用的新API。为了表明哪组API是可用的，每个平台版本指定了API级别。举个例子，Android1.0是API级别1而Android4.4是API级别19.
API级别允许你声明app可兼容的最低版本，通过使用<uses-sdk>的manifest标签和其minSdkVersion属性。
举个例子，API Calendar Provider在Android4.0（API级别14）加入。如果app不能没有这些API，你应该声明API级别14作为app的最低支持版本：
<manifest ... > <uses-sdk android:minSdkVersion="14" android:targetSdkVersion="19" /> ... </manifest>
minSdkVersion属性声明了app兼容的最低版本，targetVersion属性声明了app优化对应的最高版本。
每一个连续的Android版本提供了为使用上一个版本API编译的app提供了兼容性，所以你的app使用文档的Android API，就可以一直兼容未来的Android版本。
注意：targetVersion属性不能避免你的app安装在高于指定的版本上，但重要的是它向系统表明了app是否要继承更新版本的行为改动。如果你不更新targetVersion到最新版本，当运行在最新版本的时候，系统会假设你的app要求一些先后兼容的行为。举个例子，在Android4.4的行为变动中，由AlarmManager API创建的闹钟现在已经不精确了，所以系统能够批处理应用闹钟和保存系统电量，但是如果你的目标API级别低于19，系统会为你的app保留以前的API行为。
但是，如果你的app使用了更早前平台版本的API，但是没有为其主要功能申请，你应该在运行时检查API级别，当API级别太低的时候优雅地不使用对应的特性。在这个案例中，为了app的主要功能尽可能设置最低的minSdkVersion，然后比较当前的系统版本（SDK_INT）和Build.VERSION_CODES中你想要检查的对应API级别的常量。举个例子：
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运行在不同尺寸的设备上，从手机、平板到电视。为了按它们的屏幕类型分类，Android为各个设备定义了两种特点：屏幕尺寸（屏幕的物理尺寸）和屏幕密度（屏幕上像素的物理密度，被称为DPI）。为了简化不同配置，Android把它们归纳进各个组使它们更容易对应：
四种通用的尺寸：小，正常，大，特大
几种通用的密度：mdpi，hdpi，xhdpi，xxhdpi以及其他
默认地，你的app会兼容所有屏幕尺寸和密度，因为系统会根据你的UI布局和图像资源为每个屏幕做出必要的合适调整。然而，你应该通过为不同屏幕尺寸增加特定布局和为常见的屏幕密度优化位图图像，为每个屏幕配置优化用户体验。
更多关于如何为不同屏幕创建替代资源，以及如何在必要情况下限制app到某些屏幕尺寸的信息，请读支持不同屏幕。
因为商业原因而控制应用的可用性
除了根据设备特点来限制你的app可用性，有可能你还需要因为商业或者法律原因限制app的可用性。举个例子，展示伦敦地铁行程的app不太可能在英国以外的地区有用。因为这类情况，Google Play Store在开发者控制台提供了过滤选项，允许你由于非技术原因（比如用户所处的区域或无线运营商）来控制app的可用性。
技术类兼容性（比如要求硬件组件）的过滤条件通常是基于你的apk文件中包含的信息。但非技术类原因（比如地理区域）的过滤条件通常在Google Play开发者控制台上处理。
标签：
原文地址：http://www.cnblogs.com/jacobchen/p/4220215.html
