標籤:
原文地址:Device Compatibility
Android設計於運行在多種不同類型的裝置上,從手機、平板到電視。作為一名開發人員,裝置的涵蓋範圍為你的app提供了廣大的潛在使用者。為了讓你的app能在這些裝置上成功運行,它應該容許一些特性差異,並提供靈活的UI來適配不同的螢幕配置。
為了促進你的努力能達到目標,Android提供了Live App架構,可以讓你在靜態檔案中放入指定配置的應用資源(比如對應不同螢幕尺寸的XML布局檔案)。Android會根據當前的裝置配置來載入適當的資源。所以,預先想好你的應用設計和額外的應用資源,你就發行就緒出單個應用程式套件(apk),為多裝置提供最佳化的使用者體驗。
如果必要的話,你也可以指定app的特性需求,控制哪些類型的裝置可以從Google Play Store(市集)上安裝你的app。這篇文會向你說明如何控制哪些裝置可以使用你的app,讓你的app到達正確的使用者手中。更多關於適配不同裝置的資訊,請閱讀支援不同裝置。
"相容性"意味著什嗎?
隨著你閱讀更多關於Android開發的資料,你會在多種情況下遇到“相容性”這個術語。有兩種類型的“相容性”:“裝置相容性”和“應用相容性”。
因為Android是一個開源項目,任何硬體廠商都可以開發出運行Android作業系統的裝置。只有當裝置能夠正確運行針對於Android執行環境開發的app,才算是“相容Android”。Android執行環境的確切細節,由Android相容計劃定義,每個裝置必須通過“相容性測試套裝”(CTS)才能被視為相容。
作為一名應用開發人員,你不必擔心裝置是否相容Android,因為只有相容Android的裝置才會有Google Play Store。所以你大可放心,從Google Play Store上安裝你的app的使用者使用的是相容Android的裝置。
然而,你確實需要考慮你的app是否相容各種潛在的裝置配置。由於Android運行在各種裝置配置上,有些特性並不是在所有裝置上都可用。舉個例子,有些裝置可能不包含指南針感應器。如果你的app的核心功能要求使用指南針感應器,那麼你的app只相容具有指南針感應器的裝置。
控制app在裝置上的可用性
Android支援廣泛的特性,你的app可以利用平台的API獲得它們。有些特性是基於硬體的(比如指南針感應器),有些是基於軟體的(比如應用小工具),而有些是依賴於平台版本。不是每一種裝置都支援每一種特性,所以你可能需要根據app要求的特性,來控制你的app對裝置的可用性。
為了讓app達到最大的使用者基礎,你要努力讓單個apk來支援儘可能多的裝置配置。在大多數情況下,你可以通過在運行時禁用某些特性,為不同配置(比如對應不同螢幕尺寸的布局)提供可替換的應用資源來達到目的。然而如果必要的話,你可以根據以下裝置特點來限制設app在裝置上的可用性:
裝置特性
為了讓你能基於裝置特性來管理app的可用性,Android為可能停用硬體或軟體特性定義了“特性ID”。舉個例子,指南針感應器的特性ID是FEATURE_SENSOR_COMPASS,而應用小工具的特性ID是FEATURE_APP_WIDGETS。
如果必要的話,你可以通過在app的manifest檔案的<uses-feature>元素中聲明,來避免使用者的裝置不提供該項特性時仍安裝應用。
舉個例子,如果你的app對於沒有指南針感應器的裝置沒有意義的話,你可以在下面的manifest標籤中聲明要求指南針感應器:
<manifest ... > <uses-feature android:name="android.hardware.sensor.compass" android:required="true" /> ...</manifest>
Google Play Store會比較你的app要求的特性和每個使用者的裝置的可用特性,來決定你的應用是否和裝置相容。如果裝置沒有提供app要求的全部特性,使用者則安裝不了你的app。
但是,如果app的主要功能並不要求裝置特性,你應該把"required"屬性設成"false",並在運行時檢查裝置特性。如果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();}
關於你能夠控制使用者對app可用性的過濾條件資訊,請看文檔Google Play的過濾。
注意:有些系統許可權會隱式地要求裝置特性的可用性。舉個例子,如果app申請了訪問藍芽的許可權,就隱式地要求有FEATURE_BLUETOOTH的裝置特性。你可以通過在<uses-feature>標籤中設定require屬性為false,來禁止基於這個特性的過濾條件,讓app可以用於沒有藍芽的裝置。關於隱式要求裝置特性的更多資訊,請讀暗示要求特性的許可權。
平台版本
不同裝置可能運行不同版本的Android平台,如Android4.0或Android4.4。每個連續的平台版本往往會增加上一個版本停用新API。為了表明哪組API是可用的,每個平台版本指定了API層級。舉個例子,Android1.0是API層級1而Android4.4是API層級19.
API層級允許你聲明app可相容的最低版本,通過使用<uses-sdk>的manifest標籤和其minSdkVersion屬性。
舉個例子,API Calendar Provider在Android4.0(API層級14)加入。如果app不能沒有這些API,你應該聲明API層級14作為app的最低支援版本:
<manifest ... > <uses-sdk android:minSdkVersion="14" android:targetSdkVersion="19" /> ...</manifest>
minSdkVersion屬性聲明了app相容的最低版本,targetVersion屬性聲明了app最佳化對應的最高版本。
每一個連續的Android版本提供了為使用上一個版本API編譯的app提供了相容性,所以你的app使用文檔的Android API,就可以一直相容未來的Android版本。
注意:targetVersion屬性不能避免你的app安裝在高於指定的版本上,但重要的是它向系統資料表明了app是否要繼承更新版本的行為改動。如果你不更新targetVersion到最新版本,當運行在最新版本的時候,系統會假設你的app要求一些先後相容的行為。舉個例子,在Android4.4的行為變動中,由AlarmManager API建立的鬧鐘現在已經不精確了,所以系統能夠批處理應用鬧鐘和儲存系統電量,但是如果你的目標API層級低於19,系統會為你的app保留以前的API行為。
但是,如果你的app使用了更早前平台版本的API,但是沒有為其主要功能申請,你應該在運行時檢查API層級,當API層級太低的時候優雅地不使用對應的特性。在這個案例中,為了app的主要功能儘可能設定最低的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();}
螢幕配置
Android運行在不同尺寸的裝置上,從手機、平板到電視。為了按它們的螢幕類型分類,Android為各個裝置定義了兩種特點:螢幕尺寸(螢幕的物理尺寸)和螢幕密度(螢幕上像素的物理密度,被稱為DPI)。為了簡化不同配置,Android把它們歸納進各個組使它們更容易對應:
四種通用的尺寸:小,正常,大,特大
幾種通用的密度:mdpi,hdpi,xhdpi,xxhdpi以及其他
預設地,你的app會相容所有螢幕尺寸和密度,因為系統會根據你的UI布局和映像資源為每個螢幕做出必要的合適調整。然而,你應該通過為不同螢幕尺寸增加特定布局和為常見的螢幕密度最佳化位元影像映像,為每個螢幕配置最佳化使用者體驗。
更多關於如何為不同螢幕建立替代資源,以及如何在必要情況下限制app到某些螢幕尺寸的資訊,請讀支援不同螢幕。
因為商業原因而控制應用的可用性
除了根據裝置特點來限制你的app可用性,有可能你還需要因為商業或者法律原因限制app的可用性。舉個例子,展示倫敦地鐵行程的app不太可能在英國以外的地區有用。因為這類情況,Google Play Store在開發人員控制台提供了過濾選項,允許你由於非技術原因(比如使用者所處的地區或無線電訊廠商)來控制app的可用性。
技術類相容性(比如要求硬體組件)的過濾條件通常是基於你的apk檔案中包含的資訊。但非技術類原因(比如地理地區)的過濾條件通常在Google Play開發人員控制台上處理。
[Android文檔翻譯]裝置相容性