Android Google官方文檔解析之——Device Compatibility

標籤：android   des   style   blog   color   使用   

　　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 featuredisableCompassFeature();}

　　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 APIsdisableDragAndDrop();}

 

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 的開發人員控制台中操作。