2.1、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.
当你读到很多关于Android开发的内容时，你可能会遇到的各种情况的"兼容性"一词。有两种类型的兼容性：设备兼容性 和应用程序的兼容性。
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是一个开源工程，任何硬件设备制造商都能够构建一个运行Android操作系统的设备。然而，只有当它能够正确运行Android的运行环境编写的应用程序，设备才是"兼容Android的" 。在Android执行环境的具体细节由定义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的设备，才被包含在Google Play商店。所以，你可以放心，只有使用Android兼容设备的用户才能从Google Paly商店安装您的应用程序。
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.
但是，你需要考虑的是您的应用程序与每个潜在的设备配置是否兼容。因为Android运行在多种设备上，某些功能可能不适用于所有设备。例如，某些设备可能不包括罗盘传感器。如果你的应用程序的核心功能需要使用指南针传感器，那么你的应用程序是只与包括指南针传感器的设备兼容。
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.
你的应用可以通过平台使用Android支持多种特性的APIs。有些特性是基于硬件（如指南针传感器），有些是基于软件的（如应用程序窗口小部件），以及一些依赖于平台的版本。不是每个设备支持的所有特性，所以你可能需要控制你的应用程序的可用性，根据你的应用程序的所需的特性设备。
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:
为了让你的应用程序得到最大的用户群，你应该努力使单个APK，支持尽可能多的设备配置。在大多数情况下，您可以在运行时禁用可选功能，以及为不同的配置方案提供应用程序资源 （如为不同的屏幕大小提供不同的布局）。如果有必要，您可以通过Google Play商店基于以下设备特性限制您的应用程序对设备的可用性：
2.2.1、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、应用程序小部件的特性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>标签来限定：
<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.
Google Paly商店会比较你的应用程序所必须的以及用户的设备上可用的特性，以确定您的应用是否和用户的设备兼容。如果设备不能提供你的应用所需要的所有特性的话，用户就不能安装你的应用。
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"，然后在运行时所需要的检查设备特性。如果这个设备特性在当前设备上不可用，你应该优雅地去掉相应的应用程序的功能。比如所，你能够通过调用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.
有关所有你能够通过Google Play商店控制您的应用的可用性的过滤器的信息，可以参考 Google Play上的过滤器 文件。
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.
注意：一些 system permissions
隐含的需要一些设备特性必须可用。比如说：如果你的应用请求一个访问BLUETOOTH的权限，这隐含的必须具有 FEATURE_BLUETOOTH设备特性。你能够通过设置<uses-feature>标签的required属性为"false"来禁止没有蓝牙设备的机器过滤掉您的应用。
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平台，如Android 4.0或Android 4.4。每个后续的平台版本往往增加在以前的版本无法使用的新API。每个平台版本指定一个API级别来指出哪些是可用的APIs。举例来说，Android1.0的API级别是1和Android 4.4的API级别是19。
The API level allows you to declare the minimum version with which your app is compatible, using the <uses-sdk> manifest tag and its minSdkVersion attribute.
API级别允许你定义你的应用在哪一个最小的版本上时可用的，使用mianfest中的<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:
比如说， Calendar Provider APIS是在Android4.0(API级别是14)上增加的。如果你的应用程序不能没有这些函数，那么你能够像下面这样定义你的应用最低支持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的每个后续版本向以前版本的API平台构建的应用程序提供了兼容性，所以应该使你的应用程序使用的 Android API应该总是兼容Android的未来版本。
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属性不会阻止你的应用程序被安装在平台上比规定值高的版本上，但它是非常重要的，因为它表明该系统的应用程序是否应该继承在新版本中的行为变化。如果你不更新 targetSdkVersion到最新版本，当在最新版本上运行时，系统假设你的应用程序需要一些向后兼容的行为。例如，在Android 4.4中行为的变化后，现在在默认情况，创建alarms的AlarmManager API是不精确的，系统能批量应用alarms来保护系统电源，但系统会对你的应用程序保留以前的API的行为，如果你的目标的API级别比"19"低。
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:
但是，如果你的应用程序使用的一个较新的平台版本新增的API，但不要求他们为其主要功能，你应该在运行时检查API级别，如果API级别太低，应该适当的减少相应的功能。在这种情况下，设置minSdkVersion为可能的最低值，你的应用程序硬件检查当前本和相应的API级别的值：SDK_INT是你的SDK级别，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();
}
2.2.3、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:
Android运行在不同屏幕大小的设备上，从手机到平板电脑和电视。为了通过他们的屏幕类型分类设备，Android为每个设备定义了两种特性：屏幕尺寸（屏幕的物理尺寸）和屏幕像素密度（该像素在屏幕上的物理密度，称为DPI）。为了简化不同的配置，把他它们归纳成以下几种分类：
Four generalized sizes: small, normal, large, and xlarge.
四种广义的尺寸：small, normal, large以及xlarge.
And several generalized densities: mdpi (medium), hdpi (hdpi), xhdpi (extra high), xxhdpi (extra-extra high), and others.
和几个广义密度：mdpi (medium), hdpi (hdpi), xhdpi (extra high), xxhdpi (extra-extra high), 以及其它的
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.
默认情况下，您的应用程序应该兼容所有的屏幕尺寸和密度，因为系统会进行适当的调整，以便为每个屏幕设置必需的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.
有关如何为不同的屏幕创建替代资源，以及如何在必要时限制你的应用程序的某些屏幕尺寸的信息，请阅读支持不同的屏幕。
2.3、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.
除了根据设备特性限制你的应用程序的可用性，你可能需要根据商业原因或法律原因限制你的应用程序的可用性。例如，英国以外的用户不太可能用到一个用于伦敦地铁显示列车时刻表的应用程序。对于这种情况，Google Play商店提供了在开发者控制台，让您控制对于非技术原因您的应用程序的可用性，例如用户的语言环境或无线运营商过滤选项。
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文件信息。但过滤非技术原因（如地理区域）总是在Google Play开发者控制台处理。 | 
