Android API Guides - Device Compatibility

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.

安卓被设计用来行在不同类型的设备上，比如电话，平板，电视机等。对开发人员而言，设备的多样性也使你的应用程序拥有着大量的潜在用户。为了让应用程序能够完美地运行在各种各样的设备上，你就必须能应付一些功能特性的变化并提供一个灵巧的用户界面以适配不同的屏幕分辨率。

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 resources），比如为不同的屏幕分辨率指定不用的 XML 部署文件，然后安卓系统会根据当前设备的机能来加载合适的资源文件。因此，当你的应用程序安装包（Application PacKage,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（谷歌应用商店，国内用不了，用用豌豆荚就得了~~） 上下载安装你的应用。本章详细介绍了如何限制设备来获取你的应用程序，如何来筹备你的应用使得它们被合适的用户所获得。关于如果使你的应用适配不同的设备，你可以查阅 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 development（即 http://developer.android.com/，被墙了。）你可能会在各种各样的地方看到“兼容性（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 execution environment”）才能认为它是“兼容安卓（Android compatible）”的设备。关于“Android execution environment”的具体信息可以查看  Android compatibility program 。另外，每个设备都必须通过 Compatibility Test Suite (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 compatible）的，因为只由当该设备兼容安卓时才会内置 Google Play Store。所以你可以直接认为只要是能在Google Play Store上下载安装你的应用程序的设备都是兼容安卓的。

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.

你的应用程序通过 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:

为了尽可能地获得用户数，你应该努力使用一个 APK 来支持尽可能多的设备类型。在大多数情况下，你可以在运行时禁用掉可选的功能特性或者提供可替换的应用资源来自适应不同种类的设备（比如使用不同的layout文件来是被不同的屏幕大小）。当然，如果有必要的话，你可以根据下面三种设备属性来在 Google Play Store 里限制可以下载安装你的应用的设备类型

• 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.

为了让你能够根据设备的特性来确定该设备是否支持你的应用，安卓为所有的软硬件特性都进行了编号，不管当前设备时候拥有这种特性。举个栗子，方向传感器的特性编号是 FEATURE_SENSOR_COMPASS 而桌面小部件的特性编号是 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 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:

再举个栗子，如果你的应用在缺少方向传感器的设备上根本运行不了，那么你就可以像下面这个 mainfest 文件的部分代码那样声明安装该应用的设备必须要有方向传感器。

<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:

但如果某个设备特性对于你应用的核心功能而言并非不可或缺的话，那你就应该把 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 Store 下载使用应用的信息，请参阅 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.

注意：一些系统权限也可能会隐式地对设备特性有所要求。譬如说，如果你的应用申请使用蓝牙 BLUETOOTH 的权限，那在这同时也隐式地表明你的应用需要设备拥有蓝牙（ FEATURE_BLUETOOTH ）特性。你可以在 manifest 文件的 <uses-feature> 标签中将required 属性设置成“false”来禁用掉 Google Play Store 的下载安装限制，从而使得没有蓝牙的设备也能够下载安装你的应用。更多关于隐式的设备特性声明请查阅 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.

不同设备可能运行在不同版本的安卓平台上，比如安卓4.0或者安卓4.4。每个平台版本相对于上一个版本都可能新增一些旧版本所没有的 API。为了指明哪些 API 是可用的，每个安卓版本都有一个 API 级别（API level），比如安卓1.0对应的就是 API level 1 而安卓 4.4 对应的是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.

你可以在 manifest 文件中带有 minSdkVersion 属性的 <uses-sdk> 标签来声明你的应用所能兼容的最低的安卓版本。

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 相关的 API 是从安卓 4.0 （API level 14）开始才有的。如果你的应用没有这些 API 就无法运行，那你就应该下面这样来声明 API 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 属性声明了你能兼容的最低安卓平台版本而 targetSdkVersion 属性则声明了你优化你应用时所使用的最高版本。

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

每次安卓版本的更迭都兼容那些使用上一个版本的 API 开发编译的应用，因此，当你使用旧有的 API 来进行开发时也应该使用新版本的安卓来编译。（这个在使用 Android Studio 新建应用时也会有这个提示。）

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 属性并不会阻止你的应用被安装在更高级的平台版本上，但它依然是一个十分重要的属性，因为它向系统指明了你的应用是否需要继承新版本的特性改动。如果你不将这个属性改成最新的安卓版本，系统就会认为如果你的应用如果被执行在更高的平台上就需要进行向后兼容的操作。比如，在 behavior changes in Android 4.4 之中，使用 AlarmManager 创建的警报信息默认是不精确的，因而系统能够批量地进行进行报警来省电，但如果你的 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:

但，如果你的应用使用到了更高版本的API，而且也并非它的核心功能，那么你在程序运行过程中就需要校验 API level 以便当所在设备的平台版本过低时优雅地屏蔽掉相应的功能。在这种情况下，你应该根据应用的核心功能来尽可能地降低minSdkVersion 的值，并使用当前系统的版本（即SDK_INT）来与 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.
• 四种笼统的尺寸分类：small 小屏，normal 中屏，large 大屏，xlarge 炒鸡大的屏
• And several generalized densities: mdpi (medium), hdpi (hdpi), xhdpi (extra high), xxhdpi (extra-extra high), and others.
• 几种笼统的密度分类：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.

默认情况下，你的应用程序会兼容所有的大小和密度，因为系统会针对你的用户界面布局为每种屏幕映射相应的资源而做出适当的调整。但你自己也应该通过，添加针对不同屏幕的布局资源，或者为常见的屏幕密度提供优化好的 bitmap 图片等方式，来对每种不同的屏幕配置来优化用户体验。

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.

有关如何为不同的屏幕创建可替代的资源，或者在必要时，如何根据屏幕大小来限制你的应用的详细介绍，请点击传送门 Supporting Different Screens 。

Controlling Your App's Availability for Business Reasons 介于商业性考虑而对应用程序作限制

---

In addition to restricting your app's  based on device characteristics, it’s possible you may need to restrict yourapp’s availability for business or legal reasons. For instance, an app that displays train schedules for the London  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 Store 提供一个控制台来提供给开发人员（Google Play developer console）启用/禁用过滤选项的功能，允许开发人员出于非技术因素的考虑而阉割应用的功能，非技术因素指的是类似用户的所处位置或者无线运行商等等。（比如挂了VPN到米国就用不了虾米播放器了- - ）

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.

出于技术性因素而做出的限制（比如需要一个硬件组件如蓝牙、NFC等）通常根据APK文件中包含的限制信息来执行的，而因为非技术原因而做出的限制一般都是在 Google Play developer console 中进行的。