Android官方文档阅读之旅——Device Compatibility-CSDN博客

Android官方文档阅读之旅——Device Compatibility

原文地址：http://developer.android.com/guide/practices/compatibility.html

Android is designed to run on many different types of devices, from phones to tablets and televisions. As a developer, the range of devices provides a huge potential audience for your app. In order for your app to be successful on all these devices, it should tolerate some feature variability and provide a flexible user interface that adapts to different screen configurations.

Android系统被设计可在多种不同类型设备上运行，兼容的设备从手机到平板电脑再到智能电视可谓是千差万别。对于开发者而言，Android所支持的多种机型可为你的APP提供一个潜在的巨大客户群。为了让你的应用能兼容这些设备，它应该包含一些可变性特征，并提供一个灵活的，可适配不同类型屏幕的用户界面。

To facilitate your effort toward that goal, Android provides a dynamic app framework in which you can provide configuration-specific app resources in static files (such as different XML layouts for different screen sizes). Android then loads the appropriate resources based on the current device configuration. So with some forethought to your app design and some additional app resources, you can publish a single application package (APK) that provides an optimized user experience on a variety of devices.

为了帮助你达到这个目的，Android提供了一种动态的APP框架。在这个框架中，你可在静态文件里提供针对具体机型配置的APP资源（如针对不同屏幕大小的不同XML布局文件）。系统将会根据当前运行的机型加载合适的资源。所以凭借你在设计APP上的一些筹划以及一些附带的APP资源，你就可以仅发布一个单独的安装包，这个包就足以对不同机型提供更佳的用户体验了。

If necessary, however, you can specify your app’s feature requirements and control which types of devices can install your app from Google Play Store. This page explains how you can control which devices have access to your apps, and how to prepare your apps to make sure they reach the right audience. For more information about how you can make your app adapt to different devices, read Supporting Different Devices.

不过，如果必要，你也可以为你的应用指定运行要求，控制哪些类型的设备可以从GP上安装它。本章节将向你说明如何为你的应用进行设备控制以及如何确定目标客户群。关于更多APP兼容性的问题，请参阅《支持不同设备》一文。

What Does “Compatibility” Mean? 什么是“兼容性”

As you read more about Android development, you’ll probably encounter the term “compatibility” in various situations. There are two types of compatibility: device compatibility and app compatibility.

当你读更多安卓开发方面的东西，你也许就会在很多种场合下遇见“兼容性”这个词条。兼容性包含两方面的含义：设备兼容性和应用兼容性

Because Android is an open source project, any hardware manufacturer can build a device that runs the Android operating system. Yet, a device is “Android compatible” only if it can correctly run apps written for the Android execution environment. The exact details of the Android execution environment are defined by the Android compatibility program and each device must pass the Compatibility Test Suite (CTS) in order to be considered compatible.

由于Android的开源，任何硬件厂商都可以制造一个跑安卓系统的设备。然而，一个设备是“兼容安卓”的，当且仅当它可以正确运行为安卓运行环境而设计的应用。安卓运行环境的具体细节是由安卓兼容性测试程序定义的。每个设备都必须通过兼容性测试（CTS）以达到兼容性要求。

As an app developer, you don’t need to worry about whether a device is Android compatible, because only devices that are Android compatible include Google Play Store. So you can rest assured that users who install your app from Google Play Store are using an Android compatible device.

作为一个应用开发人员，你无须担心哪种设备是兼容Android的，因为只有支持Android的设备才有GP商店。所以你可以放心地确定那些从GP上安装了你的应用的人使用的都是支持Android的设备。

However, you do need to consider whether your app is compatible with each potential device configuration. Because Android runs on a wide range of device configurations, some features are not available on all devices. For example, some devices may not include a compass sensor. If your app’s core functionality requires the use of a compass sensor, then your app is compatible only with devices that include a compass sensor.

然而，你需要考虑的是，面对任何可能系统配置，你的APP是否能够兼容。因为Android运行在各式各样的设备中，一些系统特性是无法支持所有设备的。例如，有的机器就没有罗盘传感器。如果你的应用的核心功能需要使用罗盘传感器，那么你的这个应用就仅能兼容那些有这个传感器的设备了。

Controlling Your App’s Availability to Devices 控制你的APP对于设备的兼容性

Android supports a variety of features your app can leverage through platform APIs. Some features are hardware-based (such as a compass sensor), some are software-based (such as app widgets), and some are dependent on the platform version. Not every device supports every feature, so you may need to control your app’s availability to devices based on your app’s required features.

通过调用框架的API，你的应用可以利用一系列的系统支持的特性。一些特性是基于硬件的（例如罗盘传感器），一些则是基于软件的（如应用小控件），而还有一些则是基于平台版本的。并非所有的设备都能支持所有的特性，所以你可能需要根据你应用的运行需求确定支持设备的类型。

To achieve the largest user-base possible for your app, you should strive to support as many device configurations as possible using a single APK. In most situations, you can do so by disabling optional features at runtime and providing app resources with alternatives for different configurations (such as different layouts for different screen sizes). If necessary, however, you can restrict your app’s availability to devices through Google Play Store based on the following device characteristics:

Device features
Platform version
Screen configuration

为了让你的应用能获得最大的客户群体，你应该通过使用一个APK支持尽可能多的设备。在绝大多数情况下，你可以通过在运行时动态关掉一些可选特性，以及为不同设备提供可调换的应用资源（如不同屏幕下的不同布局资源）做到这点。然而，如果必要，你也可以在GP上通过如下的设备特性限制你应用可以支持哪些设备：

设备特性
系统版本
屏幕配置

Device features 设备特性

In order for you to manage your app’s availability based on device features, Android defines feature IDs for any hardware or software feature that may not be available on all devices. For instance, the feature ID for the compass sensor is FEATURE_SENSOR_COMPASS and the feature ID for app widgets is FEATURE_APP_WIDGETS.

为了能够让你基于设备特性管理应用的设备兼容性问题，Android为那些可能无法支撑所有设备的软硬件特性定义了特性ID。例如，罗盘传感器的特性ID就是“FEATURE_SENSOR_COMPASS”，APP 控件特性ID是“FEATURE_APP_WIDGETS”。

If necessary, you can prevent users from installing your app when their devices don’t provide a given feature by declaring it with a<uses-feature> element in your app’s manifest file.

当用户的设备不具有给定特性时，如果必要，你就可以阻止这些用户安装你的应用。为此，你需要在你应用的清单文件中声明` <uses-feature>这个元素。

For example, if your app does not make sense on a device that lacks a compass sensor, you can declare the compass sensor as required with the following manifest tag:

例如，如果你的应用必须运行在具有罗盘传感器的设备上时，那么你就可以在如下的清单文件标签中声明此传感器为必须：

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

Google Play Store compares the features your app requires to the features available on each user’s device to determine whether your app is compatible with each device. If the device does not provide all the features your app requires, the user cannot install your app.

GP将会把你应用的需求特性和用户手机所具有的特性做对比，从而决定你的应用能兼容哪些设备。如果这台设备无法提供你应用所需的所有特性，那么用户是不能够安装它的。

However, if your app’s primary functionality does not require a device feature, you should set the required attribute to “false” and check for the device feature at runtime. If the app feature is not available on the current device, gracefully degrade the corresponding app feature. For example, you can query whether a feature is available by calling hasSystemFeature() like this:

不过，如果你的应用的主要功能并不必须需要某种设备特性，你应该将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();
}

For information about all the filters you can use to control the availability of your app to users through Google Play Store, see the Filters on Google Play document.

GP中提供了一些过滤手段帮助你控制你应用的设备兼容性。关于所有的这些过滤手段的更多信息，参考“GP的过滤器”相关文档。

Note: Some system permissions implicitly require the availability of a device feature. For example, if your app requests permission to access to BLUETOOTH, this implicitly requires the FEATURE_BLUETOOTH device feature. You can disable filtering based on this feature and make your app available to devices without Bluetooth by setting the required attribute to “false” in the <uses-feature>tag. For more information about implicitly required device features, read Permissions that Imply Feature Requirements.

注意：一些系统权限对某些设备特性具有隐形的需求。例如，如果你的应用需要使用蓝牙的权限，那么你的应用就隐式地需要“FEATURE_BLUETOOTH”这个设备特性。你可以关闭对此特性的过滤手段，并让你的应用能够跑在没有蓝牙的手机上。为此你需要把<user-feature>标签中的required属性置为false。关于设备特性隐式需求的更多信息，参阅“具有隐式设备特性需求的权限”一文。

Platform Version 平台版本

Different devices may run different versions of the Android platform, such as Android 4.0 or Android 4.4. Each successive platform version often adds new APIs not available in the previous version. To indicate which set of APIs are available, each platform version specifies an API level. For instance, Android 1.0 is API level 1 and Android 4.4 is API level 19.

不同设备也许运行着不同版本的Android系统，例如4.0 或者 4.4。每个后继版本往往添加了之前版本所不具有的新API。为了表明哪些API是可获取的，每种系统平台都赋予了一个API级别。例如，Android 1.0 就是API level1，4.4 就是 API level 19。

The API level allows you to declare the minimum version with which your app is compatible, using the manifest tag and its minSdkVersion attribute.

API级别允许你应用声明兼容的最小系统版本。为此你需要使用<uses-sdk>清单文件标签中的minSdkVersion属性。

For example, the Calendar Provider APIs were added in Android 4.0 (API level 14). If your app cannot function without these APIs, you should declare API level 14 as your app’s minimum supported version like this:

例如，CalenderProvider这个API从4.0（API级别14）中加入的。如果你的APP离开此API就无法正常运行，那么你就应该像这样声明API级别为14，并将其设为可支持的最小级别。

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

The minSdkVersion attribute declares the minimum version with which your app is compatible and the targetSdkVersion attribute declares the highest version on which you’ve optimized your app.

这个minSdkVersion声明了此应用兼容的最小版本。targetSdkVersion声明了你对应用进行优化时所在的最高版本。

Each successive version of Android provides compatibility for apps that were built using the APIs from previous platform versions, so your app should always be compatible with future versions of Android while using the documented Android APIs.

每个后继的Android版本都可以兼容建立于老版本的APP。所以你的应用在使用官方文档提供的API情况下，总是可以向前兼容的。

Note: The targetSdkVersion attribute does not prevent your app from being installed on platform versions that are higher than the specified value, but it is important because it indicates to the system whether your app should inherit behavior changes in newer versions. If you don’t update the targetSdkVersion to the latest version, the system assumes that your app requires some backward-compatibility behaviors when running on the latest version. For example, among the behavior changes in Android 4.4, alarms created with the AlarmManager APIs are now inexact by default so the system can batch app alarms and preserve system power, but the system will retain the previous API behavior for your app if your target API level is lower than “19”.

注意：这个targetSdkVersion属性并不阻止具有高于此值的系统设备安装它。但是这个值依旧十分重要，因为它指明了系统是否需要继承新版本中系统对行为的改变。如果你不将此属性值更新到最新版本，那么系统就会假定当你的应用运行在最新版本系统中时，则需要一些向后兼容的行为。例如，在Android 4.4 的行为变化中，闹铃曾经是由AlarmManager API创建的，但现在并非如此。现在的系统可以对闹铃进行批量管理，这样就会更加节约电量。但是I如果你的应用的目标API级别小于19的话，系统依然会为你保留之前的API。

However, if your app uses APIs added in a more recent platform version, but does not require them for its primary functionality, you should check the API level at runtime and gracefully degrade the corresponding features when the API level is too low. In this case, set the minSdkVersion to the lowest value possible for your app’s primary functionality, then compare the current system’s version, SDK_INT, to one the codename constants in Build.VERSION_CODES that corresponds to the API level you want to check. For example:

然而，如果你的APP使用了较高版本系统提供的API，但是并非核心功能所必须，那么你就需要在运行时动态检查API级别。如果当前系统版本过低，就应该酌情关闭一些相关的功能。鉴于此，你就应该在保证你应用核心功能正常运行的情况下尽量的将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();
}

Screen configuration 屏幕配置

Android runs on devices of various sizes, from phones to tablets and TVs. In order to categorize devices by their screen type, Android defines two characteristics for each device: screen size (the physical size of the screen) and screen density (the physical density of the pixels on the screen, known as DPI). To simplify the different configurations, Android generalizes these variants into groups that make them easier to target:

Four generalized sizes: small, normal, large, and xlarge.
And several generalized densities: mdpi (medium), hdpi (hdpi), xhdpi (extra high), xxhdpi (extra-extra high), and others.

Android系统运行在从手机，到平板再到智能电视的多种尺寸的设备上。为了根据屏幕类型对设备进行分类，Android为每种设备定义了两种特性：屏幕大小（屏幕的物理尺寸）以及屏幕密度（屏幕的物理像素密度，即DPI）。为了简化屏幕配置上的差异，Android将这些差异进行归类，方便了对设备的分类：

四种大概的屏幕尺寸：小，正常，大，超大
以及几种大概的屏幕密度：mdpi,hdpi,xhdpi,xxhdpi以及其他

By default, your app is compatible with all screen sizes and densities, because the system makes the appropriate adjustments to your UI layout and image resources as necessary for each screen. However, you should optimize the user experience for each screen configuration by adding specialized layouts for different screen sizes and optimized bitmap images for common screen densities.

默认情况下，你的APP应该可以兼容所有不同尺寸不同密度的大小。因为系统会对你的UI布局以及图片资源进行必要的恰当调整。然而，你应该为了提升用户体验做些额外的工作。你需要为不同尺寸屏幕添加有针对性的布局文件，并为常见的几种屏幕密度优化图片资源。

For information about how to create alternative resources for different screens and how to restrict your app to certain screen sizes when necessary, read Supporting Different Screens.

关于更多如何为不同屏幕创建可替代资源，以及在必要时如何针对特定屏幕对APP进行一些限制的更多信息，请参阅“兼容多种屏幕”部分。

Controlling Your App’s Availability for Business Reasons 根据商业原因限制你应用的用户范围

In addition to restricting your app’s availability based on device characteristics, it’s possible you may need to restrict your app’s availability for business or legal reasons. For instance, an app that displays train schedules for the London Underground is unlikely to be useful to users outside the United Kingdom. For this type of situation, Google Play Store provides filtering options in the developer console that allow you to control your app’s availability for non-technical reasons such as the user’s locale or wireless carrier.

除了根据设备特性限制你应用的用户范围，那么你也可能需要根据商业情况以及法律问题对你的APP进行限制。例如，一个用于显示伦敦地铁时刻表的APP就不可能适用于英国以外的地区。对于这种情况，GP在开发者控制台提供了几种过滤选项，允许你为你的应用为非技术问题（如用户的所在地或者无线载波的状态）作出安装限制。

Filtering for technical compatibility (such as required hardware components) is always based on information contained within your APK file. But filtering for non-technical reasons (such as geographic locale) is always handled in the Google Play developer console.

由于技术的兼容性而对你应用进行安装限制都是基于包含在APK文件中的信息进行的。但是对于非技术问题作出的限制，总是由GP的开发者控制台处理的。

由于笔者水平有限，内容仅供参考，如有翻译不当之处，欢迎指正