Android Google官方文档解析之——Device Compatibility

　　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被设计成在许多不同设备上运行，从手机到平板和电视。作为一个开发者，设备的范围为你的App提供了一个巨大的潜在使用者。为了你的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布局)。Android然后会基于当前设备外形加载适当的资源。所以随着对你app的预先设计和一些额外的app资源，你可以发布一个应用程序包(APK),然后可以在不同的设备上提供最佳的用户体验。
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.
　　然而如果有必要，你也能指定你的app的特性支持，控制有哪些设备可以从Google Play商店安装你的应用。这个页面给你解释了如何控制不同的设备是否可以使用你的应用程序，还有在你的app中如何准备来保证应用可以被正确的设备使用。想查看更多关于怎样使你的应用适用于不同的设备的信息，请查看Supporting Different Devices。

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开发的文档，你在各种各样的情况下很有可能遭遇到"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是一个开源项目，任何的硬件制造厂商都可以制造运行Android操作系统的设备。而只要一个设备能正确的运行Android运行环境中的应用都是"Android兼容的"。Android运行环境的准确细节被Android兼容程序定义，还有每一个设备必须通过兼容性测试确保它被认为是兼容的。
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兼容的，因为在Google Play商店中只有Android兼容的设备存在。所以你可以放心从Google Play商店中安装你应用的都是一个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.
　　然而，你需要考虑的是你的应用是否在每一个可能设备上兼容。因为Android运行在很广的设备外形范围中，一些特性不一定在所有设备上都是可用的。例如一些设备可能没有指南针传感器。如果你的应用核心功能需要使用指南针，那么你的应用智能兼容在有指南针的设备上。

Controlling Your App's Availability to Devices

　　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:

• Device features
• Platform version
• Screen configuration

　　为应用程序实现最大可能的用户基础，你需要只用一个安装程序支持竟可能多的设备配置。在大部分情况下，你可以通过在运行时取消一些可选特性，为不同的配置提供替代的app资源(比如为不同的屏幕尺寸提供不同的布局)来实现它。然而，如果有必要，你可以通过基于以下设备特征，限制你的应用可用性：

• 设备特征
• 平台版本
• 屏幕外形

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为所有的硬件和软件特征定义了特征IDs，那些特征不一定在所有设备中都是可用的。例如指南针的feature ID是FEATURE_SENSOR_COMPASS,应用小工具的feature 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标签：

<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 Play Store比较你应用需要的特性和用户设备可用的特性来决定你的应用是否在设备上兼容。如果设备没有提供所有你应用需要的特性那么用户就不能安装你的应用。
　　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:
　　然而，如果你的应用主要功能不需要设备特性，你应该设置需要的属性为"false"然后在运行时检查设备特性。如果应用特性在当前设备上不可用，优雅的降低相应的应用特性。例如你可以查询是否某个特性是可用的通过调用hasSystemtFeature()像这样：

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 Store来控制app对于用户的可用性，请看Filters on 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.
　　注意：一些系统权限隐含需要设备特性的可用性支持。比如，如果你的app需要蓝牙的使用权限，者隐含了需要FEATURE_BLUETOOTH的设备特性。你可以将这个特性设置为不可用，然后使你的app在没有蓝牙的设备上也可用，通过设置<uses-feature>标签中需要的属性为"false"。查看更多关于隐含设备特性，请查看Permissions that Imply Feature Requirements。

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平台，例如Android4.0或是Android4.4。每一个连续的平台版本经常添加新的APIs而前一个版本并不支持。指出哪一个APIs集合是可用的，每一个平台版本指定了一个API等级。例如，Android1.0是API等级1，而Android4.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等级允许你定义你应用兼容最小的版本，使用<uses-sdk>mainfest标签和他的"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 level 14)时加入的。如果你的应用在没有那些APIs的情况下不能使用，那么你应该定义APIs level 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"属性定义了你的app兼容的最小版本，而"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 compitible with future versions of Android while using the documented Android APIs.
　　每一个连续的Android版本提供了应用兼容性，因为是用前一个平台版本的APIs构造的，所以你的应用程序通过使用已经确定的Android APIs总是能被未来的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"属性并不能阻止你的应用被安装在高于给定版本值的平台上，但是它很重要，因为它向系统表明了你的app是否能继承新版本的行为改变。如果你没有更新"targetSdkVersion"到最新的版本，系统假设你的应用在运行在最新版本下时需要一些向后的兼容行为。例如，在Android4.4版本的行为改变中，闹钟通过AlarmManager APIs创建，而现在却改为了默认，所以系统可以分批处理闹钟而保护系统电量，但是如果你的target API level是低于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:
　　然而，如果你的应用用了比较新的平台版本APIs但是在主要功能中并不需要，当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将各种情况形成组的概念，确保他们很容易被识别：

• 四个广义的尺寸：small,normal,large,还有xlarge
• 还有几个广义的密度：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.

　　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与所有的屏幕尺寸和密度相兼容，因为系统会在必要的时候为每个屏幕适当的调整你的UI布局和图像资源。然而，你应当为每个屏幕配置最大化用户体验通过为不同的屏幕尺寸和添加专门的布局还有为相同的屏幕网线数设置最优的二进制图像。
　　关于如何创建供选择的不同屏幕和当必要的时候如何限制确定的屏幕的信息，请阅读Supporting Different Screens.

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.

　　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.

　　此外，基于设备配置限制你的应用的可用性，很有可能你需要为商业或是法律原因限制你的应用的可用性。例如，一个应用展示伦敦地铁列车时刻表的app是不大可能对在英国之外的用户有用的。在这种情况下，Google Play Store在开发控制台中提供了过滤选项，允许你为非技术原因比如用户的地址或是无线载体控制应用的可用性。
　　为技术兼容性(比如需要硬件组件)的过滤总是基于包含在APK文件中的信息。但是过滤非技术性的原因(例如地理位置)总是在Google Play 的开发者控制台中操作。