设备兼容性
Android系统运行在许多不同类型的设备上，包括手机、平板以及机顶盒...，如此种类繁多的设备，也产生了巨大的潜在用户群。为了使开发的app能够在大部分的设备上成功运行，它应该具有一定的可变性和灵活性来适配不同类型的设备配置。
为了一步步朝目标挺进，Android提供了一个动态的app框架，开发者可以使用静态文件来配置app资源(不同的屏幕尺寸使用不同的XML布局)，从而基于当前设备加载合适的资源文件。所以，预先构思app设计和适配资源文件，才能在各种不同设备上发布一个具有良好用户体验的app应用。
尽管如此，如果有必要，你可以在Google商店指定安装app所具有的特性需求和设备类型。在这里，将描述如何控制不同设备访问app，确保app能在用户手中正常而完美的呈现。
“兼容性”表达的意思
我们在android开发的过程中，在不同的条件下会时不时的遇到“兼容性”问题，而兼容性一般分为两种类型：设备兼容和app兼容。因为android是一个开源的项目，任何硬件厂商在自己的设备上运行android操作系统。因此，android设备兼容的前提条件就是能在android可执行环境下运行app。
但是，作为一个app开发者，没有必要去在意一个设备是否是android兼容，因为只能android兼容的设备才能运行Google商店下载的app，所以我们只要保证app能正确而良好的为用户所用即可。
鉴于此，在app开发过程中需要考虑app兼容性在不同设备上如何配置。例如，有些设备没有指南针传感器，而app的核心恰恰需要这样的功能，那么app只能兼容具有指南针功能的设备。
控制app在设备上的应用
通过android平台API，可以配置app支持各种各样的特性，有些特性是基于硬件(例如指南针)的，有些是基于软件(例如app widgets)，而另一些则依赖android平台版本。当然，不是所有的设备都支持所有的特性，所以需要在开发app的过程中综合考虑app的使用场景。
为了扩大app的使用范围，我们的app应该尽可能的支持不同设备的不同特性，也就是能根据设备进行动态的选择性启用它们的功能特性。然而，在发布app到Google商店时，我们还是有必要对使用的app特性针对的设备进行限制。
设备特性
app可用性在一定程度上基于设备所具有的特性，Android定义了几乎所有硬件和软件的功能特性ID。例如，指南针特性ID是FEATURE_SENSOR_COMPASS而app widgets ID是FEATURE_APP_WIDGETS。
因此，我们在开发app的时候可以针对相应设备具有的特性功能进行限制性使用，在manifest文件中设置<users-feature>就可以实现这样的效果。例如，如果app在所使用的设备上缺少指南针传感器就不能使用指南针功能，那么需要在manifest中配置指南针相应的标示：
<manifest ... > <uses-feature android:name="android.hardware.sensor.compass" android:required="true" /> ... </manifest>
说明：Google商店会对当前设备所具有的功能特性和app需要的功能特性进行对比，如果app需要的功能特性而设备又不支持的情况下，用户将不能安装你的app。
尽管如此，有的时候为了能在app运行过程中选择性使用对应的功能，因此，在实现对应功能的时候我们需要检测设备是否具备这样的能力，使app可以选择性的执行，如下所示：
PackageManager pm = getPackageManager(); if (!pm.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)) { // This device does not have a compass, turn off the compass feature disableCompassFeature(); }
注意：有些系统权限的开启默认需要设备具有相应的功能特性。例如，如果你的app设置了权限访问BLUETOOTH，那么会默认使用FEATURE_BLUETOOTH设备特性，当然，你也能在不具备蓝牙功能的设备上使用<uses-feature> 标记禁用这一特性。
平台版本
不同的设备可能使用的android平台版本不一样，例如android4.0、4.4，每一个递增的平台版本上通常会添加一些新的API，为了便于区分Android平台与之对应API，每个平台版本都指定了对应的API级别，诸如Android1.0对应的API级别为1级、Android4.4对应的API级别为19之类。
在app的兼容性处理中，可以在manifest标识使用<uses-sdk>设置最小API版本和相关的属性。例如Calendar Provider APIs是Android4.0(API级别为14)才添加进去的，因此如果我们开发的app需要实现这样的功能，那么就需要将API的最低版本14，像下面这样设置即可：
<manifest ... > <uses-sdk android:minSdkVersion="14" android:targetSdkVersion="19" /> ... </manifest>
minSdkVersion属性用于申明app使用的最低SDK版本；当然也需要设置app使用的最高版本，我们使用targetSdkVersion来进行设置。每个后续版本的Android兼容了前一版本的Android API，我们在开发app的应该始终与后续版本进行兼容。
注意: targetSdkVersion属性并不能限制app安装在更高平台的设备上，但是它能指明你的app是否应该在新版本上继承相应行为上所做出的改变。如果你不更新targetSdkVersion属性到最新版本，系统就会假设在最新版本上运行时需要一些向后兼容的行为。例如，在行为变化到Android 4.4时，使用AlarmManager API创建的警报默认情况下是不准确的，此时系统将保留以前的API行为(targetSdkVersion低于“19”的情况下)。
尽管如此，如果app使用最新平台版本中添加的API，而主要功能却不需要这些API的时候，我们应该在运行时检查API级别(在API级别太低的时候，对其进行降级使用)。在这种情况下，需要将minSdkVersion设置为应用程序主要功能的最低值，然后将当前系统的版本SDK_INT与Build.VERSION_CODES常量进行比较。 例如：
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总结了这个群体的诸多变化：
1、屏幕大小泛化为：small、normal、large、xlarge
2、所有的密度泛化为：mdpi (medium)、hdpi (hdpi)、 xhdpi (extra high)、 xxhdpi (extra-extra high)以及其他
Android系统为每种屏幕的app UI布局提供了合适的适配方法和各种所需的图片资源，因此所开发的app应该默认兼容所有的屏幕尺寸和密度。尽管如此，在开发app的时候，我们还是需要优化用户体验和优化位图图片来适配各种屏幕密度的设备。
控制App的商业应用
除了app在基于设备上的可用性之外，还需要从app商业性和合法性方面考虑。例如，app在伦敦的地铁时刻表不能用于整个英国。对于这样的情况，由于非技术原因或无线运营商设置等决定的因素，Google商店提供了过滤选项的功能。
总之，对于技术因素的影响，可以在APK文件中进行基本信息的配置，过滤所需的选项；而对于非技术因素的影响，可以通过Google商店控制平台来进行配置，过滤app在不同场合的可用性。