原文：http://developer.android.com/guide/practices/compatibility.html

Android 設計為可以在非常多不同種類的裝置上執行，像是手機、平版或是電視。作為開發人員，你的 APP 有很大範圍、不同裝置的潛在用戶。為了讓你的 APP 可以成功的在各種裝置上執行，他應該要能相容一些功能差異，並提供能適應不同螢幕配置的靈活 UI。

為了方便你朝著這個目標努力，Android 提供一個動態 APP framework 讓你可以提供特定配置的靜態 APP Resources（像是為不同螢幕尺寸撰寫不同的 XML layouts），然後 Android 會基於目前裝置的配置來讀取適合的 Resources。因此設計你的 APP 時配合一些預先規劃與額外的 APP Resources 你可以發佈能針對多樣化裝置優化使用者經驗的單一 APK。

如果有必要的話你可以具體說明 APP 的功能需求來控制哪種裝置可以在 Google Play 商店中安裝你的 APP。這裡會解釋如何讓你控制哪種裝置可以存取你的 APP、如何讓你的 APP 讓正確範圍的使用者看到。更多關於如何讓 APP 調整成適合不同的裝置請閱讀 Supporting Different Devices。

What Does “Compatibility” Mean?

當你閱讀更多關於 Android 開發的東西，你可能會在各種情況中遇到相容性一詞，有兩種相容性：裝置相容性 和 APP 相容性。

因為 Android 是一個 Open source 專案，任何生產者都可以製造執行 Android OS 的裝置，只有在他可以執行為 Android 執行環境撰寫的 APP 時這個裝置才符合 Android 相容性。關於確切的詳情，Android 執行環境是由 Android Compatibility Program 定義，每個裝置必須通過 Compatibility Test Suite（CTS）的測試才能視為有相容性。

至於 APP 開發者，你不需要擔心裝置是否符合相容性，因為只有和 Android 相容的裝置會有 Google Play Store。所以你可以放心，從 Google Play 商店中安裝你的 APP 的就是使用與 Android 相容的裝置。

然而，你不需要考慮你的 APP 是否和各種配置的潛在的裝置是有相容性的，因為 Android 執行在各式各樣的裝置配置上，有些功能不會每個裝置都有，像是一些裝置可能沒有電子羅盤。如果你的 APP 主要功能需要使用電子羅盤，你的 APP 只對擁有電子羅盤的裝置有相容性。

Controlling Your App’s Availability to Devices

APP 可以透過 Playform APIs 來利用 Android 支援的各種功能，有些功能是基於硬體的（像是電子羅盤），有些是基於軟體的（像是 APP Widgets），還有些有需求平台版本。並非所有裝置都支援所有功能，所以你可能需要基於 APP 需求的功能去控制你的 APP 可用性。

為了幫你的 APP 取得更多的潛在用戶，你需要盡可能的讓你的單一 APK 檔可以支援更多的裝置配置，在大多情況下，你可以在執行期讓一些可選功能失效，並且提供具有不同配置的 APP Resources（像是為不同螢幕尺寸準備不同的 layouts）。如果有必要你可以依據下面這些裝置特性，透過 Google Play 商店限制 APP 的可用性：

• Device features（裝置功能）
• Platform version（平台版本）
• Screen configuration（畫面配置）

Device features

為了讓你管理基於裝置功能的 APP 可用性，Android 幫所有硬體與軟體功能定義了可能不適用於所有裝置的 feature ID，例如電子羅盤的 feature ID 為 FEATURE_SENSOR_COMPASS，APP Widgets 的是 FEATURE_APP_WIDGETS。

如果必要的話，當使用者的裝置沒有提供你 APP 的 manifest 檔案中 <uses-feature> 裡宣告的功能，你可以不讓使用者安裝。

例如你的 APP 最於沒有電子羅盤的裝置是無意義的，你可以在 manifest 中宣告電子羅盤為 required 像這樣：

<manifest ... >
    <uses-feature android:name="android.hardware.sensor.compass"
                  android:required="true" />
    ...
</manifest>

Google Play Store 會比較使用者裝置有沒有提供 APP 需求的功能來確認你的 APP 是否相容於每個裝置。如果裝置沒有提供所有 APP 要求的功能，使用者就不能安裝這個 APP。

如果你的 APP 的主要功能不需要要求裝置功能，你應該把 required 屬性社為 false 並且在執行期檢查裝置提供的功能，如果 APP 的某些功能在裝置上是不可用的，可以適當的將 APP 的功能減少。例如你可以呼叫 hasSystemFeature() 來查詢功能是否可用：

PackageManager pm = getPackageManager();
if (!pm.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)) {
    // This device does not have a compass, turn off the compass feature
    disableCompassFeature();
}

關於可用於控制使用者能不能透過 Google Play Store 安裝你的 APP 的篩選器的所有資訊，請看 Filters on Google Play 文件。

Note：有些 system permissions 需要裝置功能可用才能用，像是如果 APP 要求使用 BLUETOOTH 的 permission，也一定會需求 FEATURE_BLUETOOTH 裝置功能。
你可以來關閉篩選器讓 APP 能在沒有藍芽的裝置使用，在 <uses-feature> 標籤中 把 required 的設定改為 false 即可。更多關於裝置功能需求的資訊請閱讀 Permissions that Imply Feature Requirements。

Platform version

不同的裝置可能會執行不同版本的 Android Platform，像是 Android 4.0 或 Android 4.4。每個後續的平台版本通常會新增一些先前版本不能用的 APIs。為了要指示哪些 APIs 是可用的，每個平台版本會定義一個 API level。例如 Android 1.0 是 API level 1，Android 4.4 是 API level 19。

API level 允許你宣告 APP 相容的最低版本，在<uses-sdk> manifest 標籤中加入 minSdkVersion 屬性。

例如，Calendar Provider APIs 是在 Android 4.0（API level 14）新增的，如果你的 APP 需要使用這個 APIs 來提供功能，你必須將 API level 14 宣告為 APP 的最低支援版本，像這樣：

<manifest ... >
    <uses-sdk android:minSdkVersion="14" android:targetSdkVersion="19" />
    ...
</manifest>

minSdkVersion 屬性宣告 APP 相容的最低版本，targetSdkVersion 屬性宣告 APP 經過你優化的最高版本。當你使用 Android APIs 的文件，Android 為使用以前平台版本 APIs 的 APP 提供了後續版本的相容性，所以你的 APP 總是能相容未來版本的 Android。

Note：targetSdkVersion 屬性不會阻止你的 APP 在更高平台版本的裝置上安裝，但還是很重要，因為他指示系統你的 APP 是否應該從更新的版本繼承改變過的行為，如果你沒有將 targetSdkVersion 更新到最新的版本，系統會假設你的 APP 在最新版本執行時需要向下相容一些行為。例如 Android 4.4 改變的行為中，Alarms 由 AlarmManager APIs 建立的，目前 Alarms 是不精確的，因為系統會批次的做警告來節省電力，但如果你的 APP target API level 小於 19，系統還是會保留先前 API 的行為。

然而，如果你的 APP 使用較新平台版本新增的 APIs ，但不是用在核心功能上，你可以在執行期檢查 API level，當 API level 太低時來適當的減少這個功能。在這個情況下為你的核心功能盡可能的設定 minSdkVersion 為最低值，然後比較目前系統的版本—Build.VERSION.SDK_INT與 Build.VERSION_CODE.版本代號 是不是符合你想檢查的 API level，例如：

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 執行在很多種不同尺寸的裝置，從手機、平板到電視。為了用螢幕尺寸去分類裝置，Android 為每個裝置定義了兩個特性：screen size（螢幕的物理尺寸）和 screen density（螢幕上像素的物理密度，叫做 DPI, Dot per inch）。為了更簡單的設定不同的配置，Android 概括的把他們分類，讓他們更容易被標記：

• 尺寸：small, normal, large, xlarge
• 密度：mdpi (medium), hdpi (high), xhdpi (extra high), xxhdpi (extra-extra high), other

你的 APP 預設會相容所有螢幕尺寸和密度，因為系統會為你的 UI layout 對每種螢幕進行適當的調整，並為每種螢幕選擇使用適當的 Image resources。然而，你必須為不同的螢幕尺寸加入專門的 layouts 還有為不同的螢幕密度提供優化的點陣圖來為每種螢幕配置優化使用者經驗。

更多關於如何為不同的螢幕建立替代 Resources 還有如何在特定的螢幕尺寸限制你的 APP，請閱讀 Supporting Different Screens。

Controlling Your App’s Availability for Business Reasons

你可能會需要為了商業或法律的因素去限制 APP 的可用性，例如一個顯示倫敦火車時刻表的 APP 對英國以外的用戶不太有用，在這種情況下，Google Play 商店在開發者的控制台中提供過濾選項，允許你非技術性的去控制 APP 可用性，像是使用者的地區或電信商。

技術相容性的篩選（像是需求某個硬體元件）的資訊總是包含在你的 APK 檔案中，但是非技術相容性（像是地理位置）總是由 Google Play 開發者控制台來管理。