[Android官方API閱讀]___

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.

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.

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.

由於Android是一個開源項目，任何一個硬件廠商均可以構建一個設備來運行Android操做系統. 而後，一個設備被稱做是「Android兼容的」，只是由於那些在Android執行環境下編寫的app能在設備上運行. 每個設備爲了考慮兼容性必須經過兼容性測試套件的測試

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.

而做爲一個app開發者，你不須要考慮設備是不是Android兼容的，由於只要包含Google Play Store的設備就是Android兼容的. 因此你能夠放心，用戶必定會使用一個Android兼容的設備從Google Play Store上安裝你的app.

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.

不過你須要考慮的是：你的app是否在潛在的不一樣配置的設備上的保持了兼容性. 由於Android系統運行在一個普遍不一樣配置的設備上，一些特性不是在全部設備上都存在. 例如，一些設備可能不會包含指南針傳感器. 若是你的app的一些核心功能須要用到指南針傳感器，而你的app只能在那些包含了指南針傳感器的設備上運行才能是兼容的.

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提供了不少很豐富的功能，讓你的app能夠經過平臺API來利用. 一些功能是基於硬件的，而另外一些功能則基於軟件的，還有一些功能則是依賴於平臺的版本. 不是每個設備都支持每個功能，因此你能夠根據你app的功能需求來控制一些設備上你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 Store的下列設備屬性來限制你的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.

爲了能讓你管理app在一些設備功能上的可用性，Android給一些硬件或軟件的功能定義了一些功能id，但不會在全部設備上都存在.

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>元素中聲明一個功能，來防止一些沒有該功能的設備的用戶來安裝該app

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 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會根據你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相關的功能.

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.

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申請了進入藍牙的權限，這樣隱式的須要設備上的藍牙功能. 你能夠設置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.

不一樣的設備能夠能運行着不一樣版本的Android平臺. 每個連續性版本的平臺都常常在新版本中增長前一個版本中沒有的一些新API. 爲了指出哪一個API是可用的，每個平臺版本都指定一個API等級.

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.

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在Android4.0(API等級爲14)的時候加入的. 那麼若是你的app不能使用或實現這些功能時， 你須要聲明一下你的API等級爲14來座位你app的最小sdk版本.

<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兼容性的最小API等級，而targetSdkVersion 屬性則聲明瞭你app使用的最高API等級

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都使用前一個版本的平臺API爲app提供了兼容性，因此你的app應該當讓兼容在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 屬性不會阻止你的app安裝在比你指定的平臺版本還要高的平臺上，可是這個屬性很重要，由於它向系統表名了你的app在一些新版本上是否能夠繼承一些行爲變化. 若是你不更新targetSdkVersion 屬性到最新版本，系統會假設你的app在最新的版本中須要一些向後兼容性的行爲. 例如，在 behavior changes in Android 4.4 之中，alarms會使用AlarmManager的API來建立而如今已經做爲了默認，這樣系統能夠批量的管理alarms來位系統保存電量，可是系統將會爲你的APP保留前一個版本的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的等級而且當API等級比較低的時候適當的下降相關的功能. 在這樣的案例中，設置minSdkVersion 屬性到你app核心功能所須要的最低版本， 而後與系統版本對比.

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

&middot;         Four generalized sizes: small, normal, large, and xlarge.

&middot;         And several generalized densities: mdpi (medium), hdpi (hdpi), xhdpi (extra high), xxhdpi (extra-extra high), and others.

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.

默認的狀況下，你的app會兼容各類屏幕尺寸和屏幕密度的，由於系統會爲你的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.

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在不一樣設備上的可以使用性，能夠限制你app的商用或者法律緣由的可用性. 對於這一類型的狀況Google Play Store提供了開發者控制檯提供一些過濾選項來容許你在一些爲非技術緣由上來控制該app的可用性.

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 Store上的一些開發者控制檯裏了