三、1、Introduction(入门)：二、Device Compatibility(设备兼容性)

时间 2020-09-14

标签 introduction 入门 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. html

Android被设计运行于多种不一样类型的设备之上，包括手机、平板电脑和电视等。做为一个开发者，这个设备返回为您的应用提供了巨大的潜在受众。为了让你的应用可以成功的在全部设备上运行，它就应该能容忍一些功能的变化而且提供适应不一样屏幕配置的灵活的用户界面。 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. app

为了方便您的朝着这个目标努力，Android提供了一个动态的应用程序框架——你能够经过提供配置特定应用程序资源的静态文件（如不一样的XML布局不一样的屏幕尺寸）。而后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. less

若是有必要，你能够指定你的应用程序的功能需求和控制哪些类型的设备能够从Google Play商店安装你的应用程序。本页说明如何控制哪些设备能够访问您的应用程序，以及如何准备你的应用程序，以确保他们到达正确的受众。有关如何使你的应用程序适应不一样设备的更多信息，请阅读支持不一样的设备。dom

IN THIS DOCUMENT

What Does "Compatibility" Mean? ide

Controlling Your App's Availability to Devices 函数

Device features 布局

Platform version 测试

Screen configuration

Controlling Your App's Availability for Business Reasons

在本文档中

另请参阅

Google Play上的过滤在

提供资源

Android的兼容性

2.一、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运行在多种设备上，某些功能可能不适用于全部设备。例如，某些设备可能不包括罗盘传感器。若是你的应用程序的核心功能须要使用指南针传感器，那么你的应用程序是只与包括指南针传感器的设备兼容。

2.二、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:

为了让你的应用程序获得最大的用户群，你应该努力使单个APK，支持尽量多的设备配置。在大多数状况下，您能够在运行时禁用可选功能，以及为不一样的配置方案提供应用程序资源（如为不一样的屏幕大小提供不一样的布局）。若是有必要，您能够经过Google Play商店基于如下设备特性限制您的应用程序对设备的可用性：

2.2.一、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"来禁止没有蓝牙设备的机器过滤掉您的应用。

2.2.二、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级别来指出哪些是可用的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.三、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.三、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开发者控制台处理。

CONTINUE READING ABOUT:

Providing Resources

Information about how Android apps are structured to separate app resources from the app code, including how you can provide alternative resources for specific device configurations.

Filters on Google Play

Information about the different ways that Google Play Store can prevent your app from being installed on different devices.

继续阅读相关内容：

提供资源

有关如何在Android应用程序的结构中，如何把资源从应用程序代码中分离出来，包括如何能够为特定的设备配置提供替代资源的信息。

Google Play上的过滤

有关不一样的方式，Google Play存储的信息能够防止你的应用程序被安装在不一样的设备。