Develop>API Guides>Introduction>Device Compatibility 中文翻译

最新推荐文章于 2020-09-20 09:26:11 发布

pingfangx

最新推荐文章于 2020-09-20 09:26:11 发布

阅读量570

点赞数

分类专栏： Android

Android 专栏收录该内容

17 篇文章 1 订阅

订阅专栏

平方Ｘ翻译说明：
仅供参考，对正确性概不负责，翻译不对的欢迎指正，勿喷。

译于20160725，原文《Device Compatibility》

设备兼容性

安卓可以在许多不同的设备上运行，从手机到平板、电视等等。作为开发者，设备的使用范围为你的应用提供了巨大潜力的用户。为了让你的应用在这些设备上都能运行，就应该容忍一些功能的变异，并提供一些灵活的用户界面以适应不同的屏幕配置。
为了方便完成这个目标，Android提供一个动态的应用框架，使你可以在静态文件（比如不同屏幕大小的不同的XML布局文件）中提供特定的应用程序资源。所以，提前考虑到你的应用的设计和一些额外的程序资源，你就可以发布一个应用包，就可以为不同的设备提供优化的用户体验。
然而，如果有必要的话，你可以指定你的应用的功能需求以此控制哪些设备才可以从谷歌应用商店安装你的应用。本页说明了如何控制哪些设备可以使用你的应用以及怎么准备你的应用以确何它们提供给正确的用户。有关如何让应用适配不同时的设置，可以阅读《Supporting Different Devices》

什么是兼容性？

当你阅读了更多安卓开发文档发，你可能会在很多地方遇到“兼容性”这个词。它有两个兼容性的意思，设备兼容性和应用兼容性。
由于安卓是一个开源项目，任何硬件厂商都可以建立一个运行安卓操作系统的设备。只有当一个设备可以正确地运行为安卓运行环境编写的应用时，它才可以称之为“Android compatible（译注：安卓兼容的）”。安卓运行环境的确切细节由安卓兼容性程序（译注：Android compatibility program）确定，并且每一个设备都必须通过兼容性测试套件（CTS）才可以被认为是兼容的。

为不同设备控制应用的可用性

通过安卓平台的API，你的应用可以支持多种功能。一些功能是基于硬件的（比如罗盘传感器），一些是基于软件的（比如窗口小部件），还有一些是基于安卓平台版本的。并不是所有的设备都支持所有的功能，所以你可能需要根据应用所需的功能来控制应用的可用性。
为了覆盖最大的用户群，你要努力用一个APK来适配尽可能多的设备配置。为了实现这个目标，大多数情况下，你可以在运行时禁用可选的功能，并且为不同时的配置提供可选的资源文件（比如为不同尺寸的屏幕提供不同的布局）。然而，如果有必要，你可以通过谷歌应用商店，用以下的设备属性来限制应用的可用性：

设备功能
平台版本
屏幕配置

设备功能

为了能够基于设备功能管理应用的可用性，安卓为任何不可能在所有设备上使用的硬件功能或软件功能，都定义了功能ID。比如，罗盘传感器的功能ID是FEATURE_SENSOR_COMPASS，窗体小部件的功能ID是FEATURE_APP_WIDGETS.
如果有必要，你可以在应用的清单文件中用<uses-feature>元素来申明一个功能，以此来阻止没有这个功能的设备安装你的应用。
比如，如果你的应用不考虑缺少罗盘传感器的设备，你可以用下面的清单标签来申明罗盘传感器是必须的：

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

谷歌应用商店会比较你的app声明的每一个必须的功能，在用户设备上是否可用以此来确定你的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();
}

有关通过谷歌应用商店来控制应用可用性的所有过滤条件，详见《 Filters on Google Play》。

平台版本

平同的设备可能运行在不同的安卓平台上，比如安卓4.0或者安卓4.1。每一个连续的平台版本，通常会添加一些之前的版本没有的API。为了表明这组API可用，每一个平台版本都申明一个API级别。比如安卓1.0是API级别1，安卓4.4是API级别19。
通过API级别，你可以使用<uses-sdk>清单标签和它的minSdkVersion属性来声明你的应用兼容的最低版本。
比如Calendar Provider API是安卓4.0（API级别14）添加的，如果你的应用必须依赖这些API，你应该声明你的应用最低支持版本是14，像这样：

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

minSdkVersion 属性申明了你的app兼容的最低版本，targetSdkVersion属性申明你优化你的app支持的最高版本。
安卓后续的版本会用之前版本的API构建的应用提供兼容性，所以当你使用标准的（译注：documented ）API文档来开发应用时，你的应用对未来的安卓版本总能保持兼容性。

注：targetSdkVersion 属性不会阻止你的应用被安装到比指明的版本更高版本的设备上，但它也很重要，应为它向系统指明你的app是否继承新版本的行为变化。如果不更新targetSdkVersion 到最新的版本，系统会假定你的app在最新版本上运行时会需要一些向后兼容的行为。比如，在安卓4.4的行为变化中，使用AlarmManager API创建的alarm在默认情况下不精确，这样系统可以批量处理应用的alarm以省电。但系统会保留以前的API行为，如果你的的目标API低于19.

然而，如果你的应用使用更新的平台添加的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();
}

屏幕配置

安卓运行在各种尺寸的设上，从手机到平板、电视等。为了根据设备的屏幕类型进行分类，安卓为每个设备定义了2个特征：屏幕大小（屏幕的物理尺寸）和屏幕密度（屏幕在相素上物理密度，被称为DPI）。为了简化不同的配置，安卓将各种不同归纳为组，以便确认：

4种归纳的尺寸：small, normal, large, 和xlarge
和一些归纳的密度：mdpi (中等的), hdpi (高的), xhdpi (非常高的), xxhdpi (非常非常高的)等等。

默认情况下你的app兼容所有屏幕大小和密度，因为对每一种屏幕，系统会在必要时适当地调整UI布局和图片资源。然而，你应该通过为不同的屏幕配置添加不同时的布局和为常见的屏幕密度提供优化的位图图像，以此来提升用户体验。
有关如何为不同的屏幕创建可选的资源文件和如何在必要时限制app使用在特定的屏幕尺寸上，详见：《Supporting Different Screens》。

出于商业原因控制app的可用性

如了根据设备的特征限制应用的可用性，你可能需要限制你的应用的可用性同于商业原因或法律原因。比如，显示伦敦地铁的列车时刻表的应用不大可能用于英国以外的用户（译注：那出国旅游的呢……）。对于这种情况，谷歌应用商店允许在开发者控制台控制app的可用性，由于非技术的原因，比如用户的区域、无线运行商等。
过滤技术兼容性（比如需要硬件组件）总是基于APK文件内的信息。但过滤非技术兼容性（比如地理区域）总是在谷歌应用商店的开发者控制台处理。