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.

安卓被设计为能够运行在很多不同的设备类型，从手机到平板和电视。作为一个开发者，如此广的设备范围为你的应用提供了数量巨大的潜在受众。为了让你的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.

为了方便你向这个目标努力，安卓提供了经典应用框架，在静态文件里，可以让你提供特殊配置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.

然而，如果有必要的话，你可以指定你的app的特征需求并管理那一个类型的设备可以从google play商店上安装你的app。这一页解释了你怎样才能管理哪些设备可以访问你的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.

因为安卓是一个开源项目，任何硬件厂商都可以搭建一个运行安卓操作系统的设备。是的，只有一个设备可以正确的运行为安卓执行环境编写的应用时它才是“兼容安卓”的。安卓执行环境的具体细节是由安卓兼容程序定义的。想要被认定是兼容的，那么每个设备都必须通过兼容性测试（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.

作为一个应用开发者，你不需要当心设备是否兼容安卓，因为只有兼容安卓的设备会被收录至Google Play 商店。所以你可以放心，所有在Google Play商店安装你的应用的用户使用的都是兼容安卓的设备。

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.

然而，你需要考虑你的应用是否兼容每一种可能的设备配置。因为 安卓运行的设备范围很广，一些设备也许没有包含指南针传感器，而你的应用却只能运行在带有指南针传感器的设备上。

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.

通过利用APIs平台，安卓可以使你的应用支持各种特性。一些特性是基于硬件的（比如指南针传感器），一些是基于软件的（就像app部件），还有一些是取决于平台版本。不会存在每个设备支持所有的特性的情况，所以，你可能需要管理你的应用的基于设备的特征的有效性。

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:

为了让你的app应用于尽可能多的用户，你应该争取使用一个APK去支持尽可能多的设备配置。大多数情况下，你可以在运行时关闭特性设置，为不同的设备配置提供合适的app资源（就像为不同的屏幕分辨率提供不同的布局）。然而，如果必要的话，你可以基于以下设备特征限制你的应用的在 Google Play商店对一些设备的有效性：

Device features

Platform version

Screen configuration

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.

为了管理你的app的基于设备特性的有效性，安卓为并不能在所有设备上有效的硬件和软件特性定义了特性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.

如果有必要，当他们的设备没有提供在在你的app的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商店将你的app需求的特性和每一个用户设备的特性的有效性做比较来决定你的app是否兼容每一个设备。如果设备不提供你的app需要的所有特性，这个用户就不能安装你的app。

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:

然而,如果你的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();
}

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 tag. For more information about implicitly required device features, read Permissions that Imply Feature Requirements.

一些系统权限有一些暗含的设备特征有效性需求，例如，如果你的应用需要一个BLUETOOTH权限，这就暗含着需要FEATURE_BLUETOOTH 设备特性。你可以通过设置< use-feature>标签把required属性设为“false”来关闭基于这个特征的过滤器，使你的app可用于没有蓝牙的设备上。

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.

不同的设备可能运行不然的安卓平台版本，例如安卓4.0和安卓4.4.每一个新的平台版本通常会增加一些在以往版本无效的新API.为了指出哪些API是有效的，每个平台版本都指定了一个API等级.例如，安卓1.0的API等级是1，安卓4.4的API等级是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.

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:

API等级允许你声明应用兼容的最低的安卓版本，使用< uses-sdk> manifest 标签和它的minSdkVersion 属性。

例如，日历提供器API在安卓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.

每个后续版本的安卓都为之前的平台版本提供兼容性构建，所以如果你使用安卓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 属性并不能阻止你的应用安装到比它指定的版本更高的平台上，但是它还是很重要，因为它为系统指明了你的app是否应该继承一个新版本的行为变化。如果你不更新targetSdkVersion 到最新版本，当运行在最新版本的时候系统就会假设你的应用需要一些向后兼容行为。例如，在Android 4.4的行为变化，使用默认的的AlarmManager API创建闹钟现在不再精确，而且系统会批量处理闹钟来节省电量，但是如果你的目标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等级，然后合理的精简相关的特性。然后对比当前系统的版本，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:

安卓运行在各种尺寸的设备上，从手机到平板还有电视。为了通过屏幕类型来标识这些设备，安卓为每个设备定义了两个特点：屏幕尺寸（屏幕的物理尺寸）和屏幕密度（屏幕像素的物理密度，被称为DPI）。为了简化不用的配置，安卓把这些类型概括为一个组使他们更容易的被定位：

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.

四种广义的尺寸：small，normal，large，和x’large。

一些广义的密度：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布局和图片资源。然而，你应该通过为不同的屏幕尺寸增加专门的布局，为常见的屏幕密度提供最佳的位图来优化用户体验。

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是不大可能用于英国以外的用户的。对于这种情况，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 开发者控制台提交的。