三、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存儲的信息能夠防止你的應用程序被安裝在不一樣的設備。