Device Compatibility（设备兼容性）

文章转载禁止用于商业用途，且不能带有虚拟货币、积分、注册等附加条件。转载须注明出处莫高雷草原以及作者@JiongBull。

访问Android API指南目录索引查看全部翻译

设备兼容性

Android被设计成能在各种不同类型的设备上运行，比如手机、平板和电视。对于开发者而言，数量庞大的设备为你的应用提供了巨大潜在受众。为了让你的应用能成功的在这些设备上运行，你的应用应该能够容忍某些硬件特性的差异，并提供灵活的能适配不同屏幕配置的用户界面。

为了帮助你达到兼容的目标，Android提供了一套动态应用框架，你可以在静态文件配置相关的app resources（例如为不同尺寸的屏幕配置不同的XML布局文件）。Android然后会根据当前设备配置加载合适的资源。因此通过预先的设计再加上一些应用资源，你就能只发布一个应用程序包（APK）就能为各种设备提供最佳的用户体验。

然而，如果必要的话你可以指定应用的特征需求，并且控制从Google Play Store上可以安装你的应用的设备类型。本文讲解了如何控制访问你应用的设备类型，还有为确保应用安装到合适的设备上要做的准备。要了解更多关于如何使你的应用适配不同的设备，请参阅Supporting Different Devices。

“兼容性”的含义

---

随着你对Android开发的了解，你可能会在很多情况下遇到“兼容性”这个术语。兼容性分为两种类型：设备兼容性和应用兼容性。

因为Android是一个开源的项目，任何硬件制造商都可以制造能运行Android操作系统的设备。但是，只有能正常运行为Android可执行环境编写的应用的设备，才能被称为“Android兼容”的设备。Android可执行环境在Android compatibility program中有详细准确的定义，每种设备为了证明是兼容的必须通过兼容测试包（CTS）的测试。

作为应用开发者，你不需要担心设备是不是Android兼容的，因为只有设备兼容的设备才有Google Play Store。因此你尽管放心，从Google Play Store上安装应用的用户都是用的是Android兼容的设备。

不过，你还是需要考虑你的应用在所有可能设备配置上的应用兼容性。因为Android是运行在各种的设备配置上的，有些特性并不是在所有的设备上都是可用的。例如，某些设备可能不含有指南针传感器。如果你的应用的核心功能需要使用到指南针传感器，那么你的应用就只能和包含指南针传感器的设备兼容。

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

---

Android提供了各式各样的特性，你的应用可以利用平台的API来使用它们。有些特性是基于硬件的（例如指南针传感器），有些是基于软件的（例如应用小部件），还有一些是依赖平台版本的。并不是所有的设备都支持所有的特性，因此你需要基于你的应用的需求特性来控制你的应用对于设备的可用性。

要使你的应用能够尽可能多的获取用户基础，你应该只用一个apk支持尽可能多的设备配置。在大部分情况下，你可以通过在运行时取消一些可选特性，和为不同配置提供可替换的资源（providing app resources）来达到目的。然而，如果必要的话，你可以通过Google Play商店基于以下设备特征来限制你的应用对于设备的可用性：

• 设备特性（Device features）
• 平台版本（Platform version）
• 屏幕配置（Screen configuration）

设备特性

为了便于你基于设备特性来管理你的应用的可用性，Android为所有的硬件和软件特性都定义了特性ID，尽管那些特性并不一定在所有的设备中都是可用的。举例来说，传感器的特性ID是FEATURE_SENSOR_COMPASS，而应用小部件的特性ID是FEATURE_APP_WIDGETS。

如果必要的话，你可以在用户的设备不能提供你在应用的manifest file里用<uses-feature> 元素声明的特性时，阻止用户安装你的应用。

例如，如果你的应用在缺少指南针传感器的设备上没有意义，你可以使用下面的清单标签来声明需要指南针传感器：

<manifest ... >    <uses-feature android:name="android.hardware.sensor.compass"                  android:required="true" />    ...</manifest>

Google Play商店会把你的应用需要的特性与每个用户设备上可用的特性进行比较来决定你的应用是否兼容那些设备。如果该设备不能提供你的应用需要的所有特性，那么用户就不能安装你的应用。

然而，如果你的应用的核心功能对某些设备特性不是必须的，那么你应该把这些设备特性的required属性设置为”false”，并且在运行时才检查这些特备特性是否存在。如果应用需要的特性在当前设备上不可用，那么可以适当的禁用掉应用的相关功能。例如，你可以像这样通过调用hasSystemFeature()查询某些特性是否可用：

PackageManager pm = getPackageManager();if (!pm.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)) {    // 该设备没有指南针，关闭指南针特性disableCompassFeature();}

在Google Play商店里，你可以使用过滤器来控制你的应用对于用户的可用性，更多关于过滤器的信息，请参阅Filters on Google Play文档。

注意：某些系统权限（system permissions）隐含了对某些设备特性的需求。例如，如果你的应用需要访问蓝牙（BLUETOOTH）的权限，那么这就隐含了对FEATURE_BLUETOOTH的设备特性的需求。你可以通过将<uses-feature>标签中的required属性设置为”false”来关闭与之相关的过滤，这样就能让你的应用在没有蓝牙的设备上也能使用了。更多关于隐含设备特性的信息，请参阅Permissions that Imply Feature Requirements。

平台版本

不同的设备可能运行不同版本的Android平台，比如Android 4.0或Android 4.4。每个新版本往往会添加一些新的API，它们在低版本中是不可用的。为了标识哪些API集是可用的，每个平台的版本都会指定一个API级别（API level）。例如，Andoid 1.0是API级别1，Android 4.4是API级别19。

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

例如，Calendar ProviderAPI是从Android 4.0（API级别14）开始引入的。如果你的应用没有这些API就不能正常工作的话，那么你就应该像这样声明应用支持的最低版本为API级别14：

<manifest ... >    <uses-sdk android:minSdkVersion="14" android:targetSdkVersion="19" />    ...</manifest>

minSdkVersion属性声明了应用可兼容的最低系统版本，targetSdkVersion属性声明应用针对优化过的最高系统版本。

每个高版本的Android系统都可以兼容使用低版本API编译出来的应用，因此只要明确使用了Android API，应用都会与未来的版本的Android兼容。

注意：targetSdkVersion属性虽然并不能阻止应用在系统版本比该属性指定的值更高的平台上安装，但是它非常重要，因为系统可以通过它确定应用是否适用高版本的特性变化。如果你还没有把targetSdkVersion更新为最新的版本，那么系统会假定应用运行在最新版本的系统上时还是需要用到某些向后兼容的特性。例如，在behavior changes in Android 4.4中，使用AlarmManagerAPI创建的闹钟默认是不精准的，这样系统可以批量处理应用闹钟以便节省电力，但是如果应用的目标API级别小于“19”，那么系统会为应用继续沿用之前的API特性。

不过，如果应用使用到了最新版本才引入的API，但是主要功能却不需要使用它们，你应该在运行时检查API级别，并在API级别过低时适当的降低相应的特性需求。在这种情况下，把minSdkVersion设置为应用主要功能所需要得最低版本，然后将当前系统的版本SDK_INT与在Build.VERSION_CODES中定义的代表API级别的常量进行比较。例如：

if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {    // 运行在API级别11以前，所以禁用使用了ClipboardManagerAPI的拖/拽功能    disableDragAndDrop();}

屏幕配置

Android可以运行在不同尺寸的设备上，从手机、平板到电视。为了通过设备的屏幕类型对设备进行归类，Android为每种设备定义了两种特性：屏幕尺寸（屏幕的物理尺寸）和屏幕密度（屏幕上像素的物理密度，也被称作DPI）。为了简化对各种配置的描述，Android把这些特性归纳为几种预定的类别，以便更容易匹配：

• 四种归纳的尺寸：small、normal、large和xlarge。
• 一些归纳的屏幕密度：mdpi (中等)、hdpi (高)、xhdpi (极高)、 xxhdpi (极其高)和其他。

默认情况下，应用会兼容所有的屏幕尺寸和屏幕密度的，因为系统会针对各种屏幕适当的调整UI布局和图片资源。然而，为了优化用户体验，你应该根据屏幕尺寸添加适当的布局资源，以及为常用的屏幕密度添加优化过的位图资源。

更多关于如何为不同屏幕创建可替换资源的信息，以及如何限定应用适用于某些屏幕尺寸的信息，请参阅Supporting Different Screens。

根据商业原因控制应用的适用范围

---

除了根据设备特性限制应用的适用范围，你可能还会因为商业或法律的原因来限制应用的适用范围。例如，显示伦敦地铁时刻表的应用就不可能对英国以外地区的用户有用。在这种情况下，Google Play商店在开发者控制中心提供了过滤选项，以便针对非技术因素控制应用的适用范围，例如用户位置和无线运营商。

技术方面的兼容性过滤（例如硬件组件的需求）都是由包含在APK文件中的信息控制的。但是非技术方面的过滤（比如地理位置）都是由Google Play开发者控制台控制的。

继续阅读：

Providing Resources

关于Android应用如何由与代码分离的应用资源构建起来的信息，包括如何为指定设备配置提供可替换资源。

Filters on Google Play

关于Google Play商店阻止应用安装再不同设备上的不同方式的信息。

还可能感兴趣：

System Permissions

介绍Android如何通过授权系统限制应用访问某些API，应用只有在用户同意授权后才能使用那些API。