Android Google官方文檔解析之——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被設計成在許多不一樣設備上運行，從手機到平板和電視。做爲一個開發者，設備的範圍爲你的App提供了一個巨大的潛在使用者。爲了你的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.
　　爲了促進你的努力走向目標，Android提供了一個動態的app框架，你能夠在靜態的文件中提供特有配置的app資源(例如爲不一樣屏幕尺寸提供不一樣的XML佈局)。Android而後會基於當前設備外形加載適當的資源。因此隨着對你app的預先設計和一些額外的app資源，你能夠發佈一個應用程序包(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.
　　然而若是有必要，你也能指定你的app的特性支持，控制有哪些設備能夠從Google Play商店安裝你的應用。這個頁面給你解釋瞭如何控制不一樣的設備是否可使用你的應用程序，還有在你的app中如何準備來保證應用能夠被正確的設備使用。想查看更多關於怎樣使你的應用適用於不一樣的設備的信息，請查看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開發的文檔，你在各類各樣的狀況下頗有可能遭遇到"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是一個開源項目，任何的硬件製造廠商均可以製造運行Android操做系統的設備。而只要一個設備能正確的運行Android運行環境中的應用都是"Android兼容的"。Android運行環境的準確細節被Android兼容程序定義，還有每個設備必須經過兼容性測試確保它被認爲是兼容的。
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兼容的，由於在Google Play商店中只有Android兼容的設備存在。因此你能夠放心從Google Play商店中安裝你應用的都是一個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提供了各類各樣的特性，你能夠利用平臺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:

• Device features
• Platform version
• Screen configuration

　　爲應用程序實現最大可能的用戶基礎，你須要只用一個安裝程序支持竟可能多的設備配置。在大部分狀況下，你能夠經過在運行時取消一些可選特性，爲不一樣的配置提供替代的app資源(好比爲不一樣的屏幕尺寸提供不一樣的佈局)來實現它。然而，若是有必要，你能夠經過基於如下設備特徵，限制你的應用可用性：

• 設備特徵
• 平臺版本
• 屏幕外形

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爲全部的硬件和軟件特徵定義了特徵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.
　　若是有必要，當用戶的設備不提供你應用程序的清單文件中<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 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:
　　然而，若是你的應用主要功能不須要設備特性，你應該設置須要的屬性爲"false"而後在運行時檢查設備特性。若是應用特性在當前設備上不可用，優雅的下降相應的應用特性。例如你能夠查詢是否某個特性是可用的經過調用hasSystemtFeature()像這樣：

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來控制app對於用戶的可用性，請看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.
　　注意：一些系統權限隱含須要設備特性的可用性支持。好比，若是你的app須要藍牙的使用權限，者隱含了須要FEATURE_BLUETOOTH的設備特性。你能夠將這個特性設置爲不可用，而後使你的app在沒有藍牙的設備上也可用，經過設置<uses-feature>標籤中須要的屬性爲"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平臺，例如Android4.0或是Android4.4。每個連續的平臺版本常常添加新的APIs而前一個版本並不支持。指出哪個APIs集合是可用的，每個平臺版本指定了一個API等級。例如，Android1.0是API等級1，而Android4.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等級容許你定義你應用兼容最小的版本，使用<uses-sdk>mainfest標籤和他的"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 level 14)時加入的。若是你的應用在沒有那些APIs的狀況下不能使用，那麼你應該定義APIs 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"屬性定義了你的app兼容的最小版本，而"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版本提供了應用兼容性，由於是用前一個平臺版本的APIs構造的，因此你的應用程序經過使用已經肯定的Android APIs老是能被將來的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"屬性並不能阻止你的應用被安裝在高於給定版本值的平臺上，可是它很重要，由於它向系統代表了你的app是否能繼承新版本的行爲改變。若是你沒有更新"targetSdkVersion"到最新的版本，系統假設你的應用在運行在最新版本下時須要一些向後的兼容行爲。例如，在Android4.4版本的行爲改變中，鬧鐘經過AlarmManager APIs建立，而如今卻改成了默認，因此係統能夠分批處理鬧鐘而保護系統電量，可是若是你的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:
　　然而，若是你的應用用了比較新的平臺版本APIs可是在主要功能中並不須要，當API等級過低的時候，你應該在運行時檢查API等級而後平滑的下降適當的特性。既然這樣，爲你的應用主要功能設置"minSdkVersion"到最低值，而後與當前系統的版本比較，"SDK_INT",爲一個在"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();
}

 

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

　　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.

　　默認來講，你的app與全部的屏幕尺寸和密度相兼容，由於系統會在必要的時候爲每一個屏幕適當的調整你的UI佈局和圖像資源。然而，你應當爲每一個屏幕配置最大化用戶體驗經過爲不一樣的屏幕尺寸和添加專門的佈局還有爲相同的屏幕網線數設置最優的二進制圖像。
　　關於如何建立供選擇的不一樣屏幕和當必要的時候如何限制肯定的屏幕的信息，請閱讀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.

　　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.

　　此外，基於設備配置限制你的應用的可用性，頗有可能你須要爲商業或是法律緣由限制你的應用的可用性。例如，一個應用展現倫敦地鐵列車時刻表的app是不大可能對在英國以外的用戶有用的。在這種狀況下，Google Play Store在開發控制檯中提供了過濾選項，容許你爲非技術緣由好比用戶的地址或是無線載體控制應用的可用性。 　　爲技術兼容性(好比須要硬件組件)的過濾老是基於包含在APK文件中的信息。可是過濾非技術性的緣由(例如地理位置)老是在Google Play 的開發者控制檯中操做。