Android开发文档标准翻译(03)一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.

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,布局对应不同屏幕尺寸)。Android会根据当前设备配置转载适当的资源。因此通过事先考虑在你的应用设置一些附加的应用资源,你会发布一个单一的应用包并且在不同的设备上提供一个最佳的用户体验。

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服务上安装你的应用。这个页面讲解了你如何控制哪种类型设备可以访问你的应用,并且如何准备你的应用确保它们获取最佳用户。有关于你如果在你的应用适配不同的设备的更多的信息,阅读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开发文档,在很多情况下你或许会遇到兼容性术语。有两种兼容性类型,设备兼容性和应用兼容性。


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兼容的设备才会放置到Goople Play Store。因此你可以确定客户从Google Play Store安装你的应用的设备是Androidj兼容的设备。


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来使用。一些特性依赖于硬件(例如像一个罗盘传感器),一些是依赖于软件(例如像应用部件),还有一些依赖于执行版本。不是所有的设备都支持任何特性,所以你可能需要控制你的应用所需要的特性是否在设备上有效。

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之支持不同的设备配置。在大多数情况下,你可以在运行时通过可选的特性为不同的配置提供提供应用资源(例如不同的布局对应不同的屏幕尺寸)。如果有必要的话，然而,你可以限制你的应用对设备的可用性,通过Coogle Play商提供的下面设备特性:


1.Device features
2.Platform version
3.Screen configuration

1.设备特性
2.平台版本
3.屏幕配置




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系统为每一种硬件或软件定义了feature 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.

如果有必要的话，你可以阻止用户安装你的应用当他们的设备不能够提供在你的应用程序的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标签声明需要的罗盘传感器:





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()：






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.

注意:一些系统权限(system permissions)隐含的需要设备特性的可用性。例如，如果你的应用需要访问蓝牙(BLUETOOTH)的权限，这就隐含的需要FEATURE_BLUETOOTH设备特性。你可以基于这个特性使过滤器不可用并且通过在<uses-feature>标签中设置required属性为”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版本，例如Android 4.0或Android 4.4。每一个新版本经常会加入在之前版本中并不可用的新的API。每一个版本会指定一个API级别(API level)以表明哪一个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.

API级别允许你定义你的应用能兼容的最小系统版本，通过使用manifest文件中<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)的API在Android 4.0(API level 14)系统中被加入。如果你的应用离开这些API就无法工作，你应当定义API level 14作为你的应用所能支持的最小版本，就像这下面这样：




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版本为应用程序提供与上一个版本的兼容性，这样你的应用程序应当总是使用有记录的Android 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属性并不是阻止你的应用安装在比你指定的版本高的版本上，但是它是重要的，因为它向系统说明了你的应用是否应该在新的版本中继承行为。如果你不升级targetSdkVersion到最新的版本，系统假定你的应用需要一些向后的兼容性当运行在最新的版本上时。例如，在Android 4.4中，使用AlarmManager来创建闹钟默认是不准确的，因为系统可以分批处理应用闹钟并节省系统电量，但是系统会为你的应用保留之前的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为最低的值以便使你的应用的主要功能可用，然后比较当前系统的版本(SDK_INT)是否与你需要的一致通过Build.VERSION_CODES代码。例如：





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)。为了简化不同的配置，Android系统概括了这些变异体到每一组中为了便于区分它们：



1.Four generalized sizes: small, normal, large, and xlarge.
2.And several generalized densities: mdpi (medium), hdpi (hdpi), xhdpi (extra high), xxhdpi (extra-extra high), and others.

1.四种概括的尺寸：small，normal，large和large
2.和一些概括的屏幕密度：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布局和图片资源针对每一种屏幕做了合适的调整。然而，你应当为用户不同的屏幕配置提供优化通过为不同的屏幕添加指定的布局并为一般密度的屏幕添加优化的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 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的开发者控制台来实现。