安卓API Guide翻译 （官方）Device Compatibility 设备相容性1.2

 翻译不对的地方请大家指正。定期每两天更新一篇，欢迎关注。
1.2Device Compatibility
1.2设备相容性
 
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 正是为能够运行于各类设备而进行设计的，这些设备包括手机、平板电脑直至电视机。 对于一名开发人员而言，如此大范围的设备，能让你开发的应用程序的用户群体潜力巨大。 为了能在所有设备上成功运行，你的应用程序应该能够容许某些硬件差异，并提供灵活的用户界面来适应各种屏幕参数。
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 提供了一套动态应用程序框架，你可以用它在静态文件中给出可配置的 应用程序资源 （诸如对应各种屏幕尺寸的不同 XML Layout布局文件）。Android 会根据当前设备的配置载入相应的资源。 因此，通过预先设计加上一些应用程序资源，你可以只发布一个应用程序包（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.
不过，如果必要的话，你也可以设定应用程序的设备需求，并且可通过 Google Play Store 限定安装的设备类型。 本文解释了你如何对可访问应用程序的设备进行限制，以及如何为确保应用程序安装到合适的设备而进行准备。  


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 compatibility program 中给出，并且所有设备都必须通过兼容性测试包（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 Store 。 因此你尽可放心，从 Google Play Store 中安装应用程序的用户都是使用了 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 提供了丰富的特性，你的应用程序可以通过平台 API 来充分利用它们。 某些特性是基于硬件的（比如罗盘传感器），有些是基于软件的（比如 Widget），有些则依赖于平台版本。 因为并非所有设备都支持全部的特性，所以你可能要根据功能需求来控制应用程序对设备的适用范围。


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 支持尽可能多样的设备。 通过在运行时禁用某些可选功能，或者根据不同的配置提供替代资源（比如为各种屏幕尺寸对应不同的 Layout）， 大多数情况下你都可以做到这一点。 如果必要的话，你可以通过 Google Play Store 从以下几方面限制应用程序的适用范围：
? 设备配置
? 系统版本
? 屏幕参数
?
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 ，Widget 的特性 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.
如果必要的话，通过在 Manifest 文件的 < 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 requiredattribute 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();
}
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 的设备需求。通过将 < uses-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 操作系统版本，比如 Android 4.0 或 Android 4.4。 较高的版本往往会比低版本系统中新增一些 API。 为了便于识别当前可用的 API 集，每个平台的版本都会被定义一个 API 级别。 例如，Android 1.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.
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:
通过 manifest 标签 < uses-sdk > 及其 minSdkVersion 属性，你可以用 API 级别来声明应用程序可兼容的最低系统版本。
例如， Calendar Provider  API 是从 Android 4.0（API 级别 14）开始引入的。 如果没有此类 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 compitible with future versions of Android while using the documented Android APIs.
高版本的 Android 系统可以兼容较低版本 API 编译出来的应用程序，因此只要使用了公开的 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 theAlarmManager 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 的特性变化 中，使用 AlarmManager API 创建的 Alarm 提醒时间缺省将不再精确，这样系统可以批量处理 Alarm 以节省电力。 但是如果应用程序的目标 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:
不过，假如应用程序用到了最新版本的 API，但是主体功能却不需要使用， 你就应该在运行时检查 API 级别，并在 API 版本过低时平稳地降低对系统特性的需求。 在这种情况下，请把 minSdkVersion 设置为程序主体功能需要的最低版本，并将当前系统的版本 SDK_INT 与程序所需 API 级别对应的代码常量相比较，这些常量在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();
}
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 （超高）、 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.
默认情况下，应用程序要兼容所有的屏幕尺寸和密度，因为系统会根据实际的屏幕参数适时调整 UI 布局和图片资源。 不过，为了提供最佳的用户体验，你应该根据屏幕参数添加各种屏幕尺寸对应的 Layout ，以及为常见屏幕密度优化过的位图资源。


 


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.
除了考虑设备特性之外，可能还会由于商业或法律的原因来限制应用程序的适用范围。 例如，显示伦敦地铁时刻表的应用程序对于英国之外的用户就不怎么有用。 这种情况下， Google Play Store 向开发人员提供了相应过滤项，以便出于非技术因素对应用程序的适用范围进行控制， 这些因素可以是用户位置或无线运营商。
技术方面的兼容性过滤（比如硬件需求）都基于你的 APK 文件进行。 但非技术性因素（比如地理位置）的过滤则全由 Google Play 的开发人员界面来控制。