Google Play 會利用應用程式資訊清單中宣告的 <uses-feature> 元素,篩除不符合應用程式硬體和軟體功能需求的裝置。

您可以透過指定應用程式需要的功能,讓 Google Play 僅對符合應用程式功能需求的使用者顯示應用程式,而不向所有使用者顯示。

如要瞭解 Google Play 如何運用功能做為篩選依據的重要資訊,請參閱「Google Play 和依功能篩選」一節。

語法:
<uses-feature
  android:name="string"
  android:required=["true" | "false"]
  android:glEsVersion="integer" />
包含於:
<manifest>
說明:

宣告應用程式使用的一項硬體或軟體功能。

<uses-feature> 宣告的目的是告知任何外部實體,應用程式依附的硬體和軟體功能組合。這個元素提供 required 屬性,可用來指定應用程式必須具有宣告的功能,否則無法正常運作,還是只是偏好使用,沒有該功能仍可正常運作。

由於功能支援機制可能因 Android 裝置而異,為了讓應用程式描述隨不同裝置而使用的功能,<uses-feature> 元素扮演相當重要的角色。

應用程式宣告的可用功能組合對應到 Android PackageManager 提供的功能常數組合。功能常數列於本文的「功能參考資料」一節中。

每項功能都必須在獨立的 <uses-feature> 元素中指定,因此,如果應用程式需要多項功能,會宣告多個 <uses-feature> 元素。舉例來說,如果應用程式需要同時使用裝置的藍牙和相機功能,會宣告這兩個元素:

<uses-feature android:name="android.hardware.bluetooth" android:required="true" />
<uses-feature android:name="android.hardware.camera.any" android:required="true" />

一般來說,您必須針對應用程式需要的所有功能宣告 <uses-feature> 元素。

宣告的 <uses-feature> 元素僅供參考,這意味著 Android 系統在安裝應用程式前,不會檢查裝置是否提供相應的功能支援。

不過,其他服務 (例如 Google Play) 和應用程式可能會檢查應用程式的 <uses-feature> 宣告,做為應用程式處理或互動過程的一部分。因此,請務必宣告應用程式使用的所有功能。

某些功能可能會提供特定屬性,可用來定義功能的版本,例如使用的 Open GL 版本 (使用 glEsVersion 宣告)。裝置具有或未提供的其他功能 (例如相機),則使用 name 屬性進行宣告。

雖然只有執行 API 級別 4 以上的裝置才能啟用 <uses-feature> 元素,但即使 minSdkVersion 為 3 以下,仍建議您為所有應用程式加入這些元素。搭載舊版平台的裝置會忽略該元素。

注意:宣告功能時,也請務必視需要要求權限。舉例來說,您必須先要求 CAMERA 權限,應用程式才能存取相機 API。透過要求權限,應用程式才能存取適當的硬體和軟體。宣告應用程式使用的功能有助確保裝置的相容性。

屬性:
android:name
以描述元字串的形式,指定應用程式使用的一項硬體或軟體功能。如需有效的屬性值清單,請參閱「硬體功能」和「軟體功能」章節。這些屬性值有大小寫之分。
android:required
布林值,指出應用程式是否需要 android:name 中指定的功能。
  • 為某項功能宣告 android:required="true",表示如果裝置沒有提供指定功能,應用程式便「無法正常運作,或未設計為可運作」
  • 為某項功能宣告 android:required="false",表示如果裝置有提供該功能,應用程式就會「使用該功能」,但可視需要「在沒有指定功能的情況下正常運作」

android:required 的預設值為 "true"

android:glEsVersion
應用程式需要的 OpenGL ES 版本。較高的 16 位元代表主要編號,較低的 16 位元代表次要編號。舉例來說,如要指定 OpenGL ES 2.0 版本,您必須將這個值設為「0x00020000」;如要指定 OpenGL ES 3.2,則應將這個值設為「0x00030002」。

應用程式應該在其資訊清單中最多指定一個 android:glEsVersion 屬性。如果指定多個 android:glEsVersion,系統會採用最高的數值,忽略所有其他值。

如果應用程式未指定 android:glEsVersion 屬性,系統會假設應用程式只需要 OpenGL ES 1.0,這是所有 Android 裝置都支援的版本。

應用程式會假設,如果平台支援指定的 OpenGL ES 版本,也應該支援所有較低的 OpenGL ES 版本。因此,如果應用程式同時需要 OpenGL ES 1.0 和 OpenGL ES 2.0 兩個版本,則應指定其需要 OpenGL ES 2.0。

能夠使用數個 OpenGL ES 版本的應用程式,只需指定其需要的 OpenGL ES 最低版本即可。這類應用程式可在執行階段檢查是否有可用的 OpenGL ES 較高版本。

如要進一步瞭解如何使用 OpenGL ES,包括如何在執行階段檢查支援的 OpenGL ES 版本,請參閱 OpenGL ES API 指南

導入版本:
API 級別 4
另請參閱:

Google Play 和依功能篩選

Google Play 會篩選向使用者顯示的應用程式,讓使用者只能查看及下載與其裝置相容的應用程式。應用程式篩選的方法之一是按功能相容性進行篩選。

為判定應用程式的功能與指定使用者裝置的相容性,Google Play 會比較下列項目:

  • 應用程式需要的功能,如應用程式資訊清單中的 <uses-feature> 元素宣告的內容。
  • 裝置提供的硬體或軟體功能,如透過唯讀系統屬性回報的內容。

為了確保功能比較的準確性,Android 套件管理員會提供共用的功能常數組合,供應用程式和裝置用來宣告功能需求和支援機制。可用功能常數列於本文的「功能參考資料」一節以及 PackageManager 的類別文件中。

使用者啟動 Google Play 時,應用程式會呼叫 getSystemAvailableFeatures(),向套件管理員查詢裝置的可用功能清單。接著,為使用者建立工作階段時,Google 商店應用程式會將功能清單向上傳遞給 Google Play。

每次您將應用程式上傳到 Google Play 管理中心時,Google Play 都會掃描應用程式的資訊清單檔案。Google Play 會尋找 <uses-feature> 元素,並在某些情況下,將其與 <uses-sdk><uses-permission> 等其他元素一同進行評估。建立應用程式的必要功能組合後,Google Play 會在內部將該清單儲存為中繼資料,並與應用程式 APK 和應用程式版本建立關聯。

當使用者使用 Google Play 應用程式搜尋或瀏覽應用程式時,該服務會將每個應用程式所需的功能與使用者裝置上提供的功能進行比較。如果裝置能夠提供應用程式需要的所有功能,Google Play 就會向使用者顯示該應用程式,並允許下載。

如果裝置不支援任何必要功能,Google Play 會篩除該應用程式,讓使用者無法看到或下載。

由於您在 <uses-feature> 元素中宣告的功能會直接影響 Google Play 篩選應用程式的方式,請務必瞭解 Google Play 如何評估應用程式的資訊清單,以及如何建立必要功能組合。下列各節將提供更多資訊。

根據明確宣告的功能篩選

應用程式明確宣告的功能意即在 <uses-feature> 元素中宣告的功能。如果是針對 API 級別 5 以上進行編譯,可以在功能宣告中加入 android:required=["true" | "false"] 屬性。

這可讓您指定應用程式必須使用該功能,否則無法正常運作 ("true"),還是會在可用的情況下使用該功能,但沒有該功能也能正常運作 ("false")。

Google Play 以下列方式處理明確宣告的功能:

  • 如果功能已明確宣告為必要 (如以下範例所示),Google Play 會將該功能加入應用程式的必要功能清單,接著從未提供該功能的裝置篩除該應用程式,不向使用者顯示。
    <uses-feature android:name="android.hardware.camera.any" android:required="true" />
    
  • 如果功能已明確宣告為「非」必要 (如以下範例所示),Google Play「不會」將該功能加入必要功能清單。因此,在篩選應用程式時,Google Play 絕對不會考慮明確宣告為非必要的功能。即使裝置未提供宣告的功能,Google Play 仍會將該應用程式視為與裝置相容,並向使用者顯示該應用程式,除非有其他適用的篩選規則。
    <uses-feature android:name="android.hardware.camera" android:required="false" />
    
  • 如果功能已明確宣告,但沒有 android:required 屬性,Google Play 會假設該功能為必要功能,並對其設定篩選條件。

一般來說,如果應用程式設計為在 Android 1.6 以下版本執行,那麼 API 中就不會提供 android:required 屬性,因此 Google Play 會假設所有 <uses-feature> 宣告均為必要功能。

注意:只要明確宣告功能並加入 android:required="false" 屬性,即可有效防止 Google Play 根據特定功能進行篩選。

根據隱含功能篩選

「隱含」功能是指應用程式正常運作所需,但「並未」在資訊清單檔案 <uses-feature> 元素中宣告的功能。嚴格來說,最理想的情況是每個應用程式「一律」宣告其使用或需要的所有功能,且沒有宣告應用程式所用功能即視為錯誤。

不過,為了保護使用者和開發人員,Google Play 會尋找每個應用程式中的隱含功能,並為這些功能設定篩選條件,方法與明確宣告的功能相同。

應用程式需要特定功能但未進行宣告的原因如下:

  • 應用程式是針對舊版 Android 程式庫 (Android 1.5 以下版本) 編譯而成,無法使用 <uses-feature> 元素。
  • 開發人員誤認為所有裝置都會提供該項功能,因此不需要宣告。
  • 開發人員不慎遺漏該功能的宣告。
  • 開發人員已明確宣告該功能,但宣告無效。舉例來說,<uses-feature> 元素名稱拼字錯誤,或 android:name 屬性包含無法識別的字串值,都會導致功能宣告失效。

為因應上述情況,Google Play 會檢查資訊清單檔案中宣告的「其他元素」(特別是 <uses-permission> 元素),嘗試找出應用程式的隱含功能需求。

如果應用程式要求硬體相關權限,Google Play 會假設應用程式使用基礎硬體功能,因此即使沒有對應的 <uses-feature> 宣告,也會需要這些功能。對於這類權限,Google Play 會將基礎硬體功能加入其儲存的應用程式中繼資料,並設定篩選條件。

舉例來說,如果應用程式要求 CAMERA 權限,Google Play 會假設應用程式需要使用後置鏡頭 (朝向外面),無論應用程式是否為 android.hardware.camera 宣告 <uses-feature> 元素。因此,Google Play 會篩除沒有後置鏡頭的裝置。

如果不想讓 Google Play 根據特定隱含功能篩選,請在 <uses-feature> 元素中明確宣告該項功能,並提供 android:required="false" 屬性。例如,如果不想根據 CAMERA 權限隱含的功能進行篩選,請宣告下列功能:

<uses-feature android:name="android.hardware.camera" android:required="false" />
<uses-feature android:name="android.hardware.camera.autofocus" android:required="false" />

注意:您在 <uses-permission> 元素中要求的權限會直接影響 Google Play 篩選應用程式的方式。「隱含功能需求的權限」一節會列出隱含功能需求,進而觸發篩選作業的完整權限組合。

藍牙功能的特殊處理方式

Google Play 在判斷藍牙的篩選時,會採用與上述範例稍微不同的規則。

如果應用程式在 <uses-permission> 元素中宣告了藍牙權限,但未在 <uses-feature> 元素中明確宣告藍牙功能,Google Play 會依據 <uses-sdk> 元素中指定的內容,檢查應用程式設計執行的 Android 平台版本。

如下表所示,只有在應用程式宣告其最低或目標平台為 Android 2.0 (API 級別 5) 以上版本時,Google Play 才會依據藍牙功能篩選。不過請注意,如果應用程式在 <uses-feature> 元素中明確宣告藍牙功能,Google Play 會套用一般篩選規則。

表 1. 對於要求藍牙權限但未在 <uses-feature> 元素中宣告藍牙功能的應用程式,Google Play 判斷藍牙功能需求的方式。

如果 minSdkVersion 為 ... targetSdkVersion 結果
<=4,或未宣告 <uses-sdk> <=4 Google Play「不會」根據裝置回報對 android.hardware.bluetooth 功能的支援情況,在任何裝置上篩除該應用程式。
<=4 >=5 Google Play 會在所有不支援 android.hardware.bluetooth 功能的裝置 (包括較舊的版本) 上篩除該應用程式。
>=5 >=5

下列範例根據 Google Play 處理藍牙功能的方式,說明不同的篩選效果。

在第一個範例中,設計在舊版 API 級別執行的應用程式宣告了藍牙權限,但未在 <uses-feature> 元素中宣告藍牙功能。
結果:Google Play 不會在任何裝置上篩除該應用程式。
<manifest ...>
    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
    <uses-sdk android:minSdkVersion="3" />
    ...
</manifest>
在第二個範例中,同一應用程式還宣告目標 API 級別為「5」。
結果:Google Play 現在假設這是必要功能,並會在未回報支援藍牙的所有裝置 (包括搭載舊版平台的裝置) 上篩除該應用程式。
<manifest ...>
    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
    <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
    ...
</manifest>
如下所示,同一個應用程式現已明確宣告藍牙功能。
結果:與先前範例相同,套用篩選功能。
<manifest ...>
    <uses-feature android:name="android.hardware.bluetooth" />
    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
    <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
    ...
</manifest>
最後,在以下情況中,同一個應用程式加入了 android:required="false" 屬性。
結果:Google Play 對所有裝置停用了根據藍牙功能支援情況進行的篩選作業。
<manifest ...>
    <uses-feature android:name="android.hardware.bluetooth" android:required="false" />
    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
    <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
    ...
</manifest>

測試應用程式需要的功能

您可以使用 Android SDK 提供的 aapt 工具,決定 Google Play 根據應用程式宣告的功能和權限,篩選應用程式的方式,方法是搭配 dump badging 指令執行 aapt。這樣可以讓 aapt 剖析應用程式的資訊清單,並套用 Google Play 所用的相同規則,判斷應用程式需要的功能。

如要使用這項工具,請按照下列步驟操作:

  1. 建構應用程式,並匯出為未簽署的 APK。如果您使用 Android Studio 進行開發,請使用 Gradle 建構應用程式,如下所示:
    1. 開啟專案,依序選取「Run」>「Edit Configurations」
    2. 選取「Run/Debug Configurations」視窗左上角附近的加號。
    3. 選取「Gradle」
    4. 在「Name」中輸入「Unsigned APK」。
    5. 從 「Gradle project」部分選擇您的模組。
    6. 在「Tasks」中輸入「assemble」。
    7. 選取「OK」即可完成新設定。
    8. 確認工具列中的「Unsigned APK」執行設定處於選取狀態,然後依序選取「Run」>「Run 'Unsigned APK'」
    您可以在 <ProjectName>/app/build/outputs/apk/ 目錄中找到未簽署的 APK。
  2. 如果 aapt 工具未出現在 PATH 中,請找出這項工具。如果您使用的是 SDK 工具 r8 以上版本,可以在 <SDK>/build-tools/<tools version number> 目錄中找到 aapt

    注意:您必須使用為最新可用的 Build-Tools 元件所提供的 aapt 版本。如果您沒有最新的 Build-Tools 元件,請透過 Android SDK Manager 下載。

  3. 使用下列語法執行 aapt
$ aapt dump badging <path_to_exported_.apk>

以下是前述第二個藍牙範例的指令輸出範例:

$ ./aapt dump badging BTExample.apk
package: name='com.example.android.btexample' versionCode='' versionName=''
uses-permission:'android.permission.BLUETOOTH_ADMIN'
uses-feature:'android.hardware.bluetooth'
sdkVersion:'3'
targetSdkVersion:'5'
application: label='BT Example' icon='res/drawable/app_bt_ex.png'
launchable activity name='com.example.android.btexample.MyActivity'label='' icon=''
uses-feature:'android.hardware.touchscreen'
main
supports-screens: 'small' 'normal' 'large'
locales: '--_--'
densities: '160'

功能參考資料

下列各節針對硬體功能、軟體功能以及隱含特定功能需求的權限組合提供參考資訊。

硬體功能

本節介紹最新平台版本支援的硬體功能。如要指明應用程式使用或需要特定硬體功能,請在 android:name 屬性中宣告相應的值 (以 "android.hardware" 開頭)。每次宣告一項硬體功能,都需要使用一個獨立的 <uses-feature> 元素。

音訊硬體功能

android.hardware.audio.low_latency
應用程式使用裝置的低延遲音訊管道,從而縮短處理音訊輸入或輸出時的延隔和延遲時間。
android.hardware.audio.output
應用程式使用裝置的喇叭、耳機插孔、藍牙串流功能或其他類似的機制來傳輸音訊。
android.hardware.audio.pro
應用程式使用裝置的高階音訊功能與效能功能。
android.hardware.microphone
應用程式使用裝置的麥克風來錄音。

藍牙硬體功能

android.hardware.bluetooth
應用程式使用裝置的藍牙功能,通常用於與其他支援藍牙的裝置通訊。
android.hardware.bluetooth_le
應用程式使用裝置的藍牙低功耗無線電功能。

相機硬體功能

注意:為了防止 Google Play 對應用程式進行不必要的篩選,如果應用程式可在沒有某項相機功能的情況下正常運作,請針對所有這類相機功能加入 android:required="false"。否則,Google Play 會假設這是必要功能,禁止不支援該項功能的裝置存取應用程式。

大螢幕支援

有些大螢幕裝置不支援部分相機功能。Chromebook 通常沒有提供後置 (朝向外面) 鏡頭、自動對焦或閃光燈,但備有前置 (面向使用者) 鏡頭,且經常會連接外部相機。

如要提供基本相機支援功能,讓應用程式盡可能適用於最多裝置,請將下列相機功能設定加入應用程式資訊清單:

<uses-feature android:name="android.hardware.camera.any" android:required="false" />
<uses-feature android:name="android.hardware.camera" android:required="false" />
<uses-feature android:name="android.hardware.camera.autofocus" android:required="false" />
<uses-feature android:name="android.hardware.camera.flash" android:required="false" />

您可以根據應用程式的用途調整功能設定。但是,如要讓應用程式適用於最多裝置,建議您一律加入 required 屬性,明確指定某項功能是否必要。

功能清單
android.hardware.camera.any

應用程式使用裝置的其中一個鏡頭,或裝置連接的外部相機。如果應用程式不「需要」朝向外面的後置鏡頭或面向使用者的前置鏡頭,請使用這項功能分別取代 android.hardware.cameraandroid.hardware.camera.front

CAMERA 權限隱含應用程式也會使用 android.hardware.camera 的意味。除非您使用 android:required="false" 宣告 android.hardware.camera,否則系統會將後置鏡頭視為必要功能。

android.hardware.camera

應用程式使用裝置的後置 (朝向外面) 鏡頭。

注意:Chromebook 等只有前置 (面向使用者) 鏡頭的裝置不支援這項功能。如果應用程式可以使用任何朝向的鏡頭,請使用 android.hardware.camera.any

注意: CAMERA 權限隱含後置鏡頭為必要功能的意味。如要確保 Google Play 能在應用程式資訊清單包含 CAMERA 權限時進行正確篩選,請明確指定應用程式使用 camera 功能,並指明是否必要,例如:
<uses-feature android:name="android.hardware.camera" android:required="false" />

android.hardware.camera.front

應用程式使用裝置的前置 (面向使用者) 鏡頭。

CAMERA 權限隱含應用程式也會使用 android.hardware.camera 的意味。除非您使用 android:required="false" 宣告 android.hardware.camera,否則系統會將後置鏡頭視為必要功能。

注意:如果應用程式使用 android.hardware.camera.front,但未使用 android.required="false" 明確宣告 android.hardware.camera,則 Google Play 會篩除 Chromebook 等沒有後置鏡頭的裝置。如果應用程式支援只有前置鏡頭的裝置,請使用 android.required="false" 宣告 android.hardware.camera,避免發生不必要的篩選。

android.hardware.camera.external

應用程式與使用者為裝置連接的外部相機進行通訊。這項功能並不保證應用程式可以使用外部相機。

CAMERA 權限隱含應用程式也會使用 android.hardware.camera 的意味。除非您使用 android:required="false" 宣告 android.hardware.camera,否則系統會將後置鏡頭視為必要功能。

android.hardware.camera.autofocus

應用程式使用裝置相機支援的自動對焦功能。

注意:CAMERA 權限隱含自動對焦為必要功能的意味。如要確保 Google Play 能在應用程式資訊清單包含 CAMERA 權限時進行正確篩選,請明確指定應用程式使用自動對焦功能,並指明是否必要,例如:
<uses-feature android:name="android.hardware.camera.autofocus" android:required="false" />

android.hardware.camera.flash

應用程式使用裝置相機支援的閃光燈功能。

android.hardware.camera.capability.manual_post_processing

應用程式使用裝置相機支援的 MANUAL_POST_PROCESSING 功能。

這項功能可讓應用程式覆寫相機的自動白平衡功能。請使用 TRANSFORM_MATRIXandroid.colorCorrection.transformandroid.colorCorrection.gainsandroid.colorCorrection.mode

android.hardware.camera.capability.manual_sensor

應用程式使用裝置相機支援的 MANUAL_SENSOR 功能。

這項功能隱含自動曝光鎖定 (android.control.aeLock) 的支援機制,可讓相機的曝光時間和感光度維持在特定值。

android.hardware.camera.capability.raw

應用程式使用裝置相機支援的 RAW 功能。

這項功能隱含裝置可儲存 DNG (原始) 檔案的意味。裝置的相機會提供應用程式直接處理原始圖像所需的 DNG 相關中繼資料。

android.hardware.camera.level.full
應用程式使用裝置至少一個鏡頭提供的 FULL 等級拍照支援。FULL 支援包括連拍功能、影格控制及手動後製處理控制功能。詳情請參閱 INFO_SUPPORTED_HARDWARE_LEVEL_FULL 相關說明。

裝置 UI 硬體功能

android.hardware.type.automotive

應用程式設計為在車輛內的一組螢幕上顯示 UI。使用者透過硬體按鈕、觸控、旋轉控制器和類似滑鼠的介面與應用程式互動。車輛的螢幕通常會顯示在中央主控台或車輛的儀表板上。這類螢幕的尺寸和解析度通常有限。

注意:由於使用者是在駕車時使用這類應用程式 UI,應用程式必須盡量避免讓駕駛人分心。

android.hardware.type.television

(已淘汰,請改用 android.software.leanback。)

應用程式設計為在電視上顯示 UI。這項功能將「電視」定義為一般客廳電視體驗:應用程式顯示在大螢幕上、使用者坐在遠處,主要輸入形式是類似於 D-Pad 的裝置,而不是滑鼠、指標或觸控裝置。

android.hardware.type.watch
應用程式設計為在智慧手錶上顯示 UI。使用者會將手錶戴在身上 (例如手腕處)。使用者非常近距離地與裝置互動。

指紋辨識硬體功能

android.hardware.fingerprint
應用程式使用裝置的生物特徵辨識硬體讀取指紋。

遊戲手把硬體功能

android.hardware.gamepad
應用程式會從裝置本身或已連結的遊戲手把擷取遊戲控制器的輸入內容。

紅外線硬體功能

android.hardware.consumerir
應用程式使用裝置的紅外線 (IR) 功能,通常用於與其他消費性 IR 裝置進行通訊。

定位硬體功能

android.hardware.location
應用程式使用裝置的一或多項功能來確定位置,例如 GPS 定位、網路訂位或行動數據定位。
android.hardware.location.gps

應用程式使用透過裝置的全球定位系統 (GPS) 接收器取得的精確位置座標。

使用此功能,即表示應用程式會使用 android.hardware.location 功能,除非使用屬性 android:required="false" 宣告這項父功能。

android.hardware.location.network

應用程式使用裝置支援的網路型地理位置系統取得粗略的位置座標。

使用此功能,即表示應用程式會使用 android.hardware.location 功能,除非使用屬性 android:required="false" 宣告這項父功能。

NFC 硬體功能

android.hardware.nfc
應用程式使用裝置的近距離無線通訊 (NFC) 無線電功能。
android.hardware.nfc.hce

應用程式使用裝置上代管的 NFC 卡模擬功能。

OpenGL ES 硬體功能

android.hardware.opengles.aep
應用程式使用裝置上安裝的 OpenGL ES Android 擴充套件

感應器硬體功能

android.hardware.sensor.accelerometer
應用程式使用裝置加速計的動作判讀資料,偵測裝置目前的螢幕方向。舉例來說,應用程式可利用加速計判讀資料,判斷切換直向和橫向螢幕方向的時間。
android.hardware.sensor.ambient_temperature
應用程式使用裝置的周邊 (環境) 溫度感應器。舉例來說,天氣應用程式可以報告室內或室外溫度。
android.hardware.sensor.barometer
應用程式使用裝置的氣壓計。舉例來說,天氣應用程式可以回報氣壓。
android.hardware.sensor.compass
應用程式使用裝置的磁力儀 (指南針)。舉例來說,導航應用程式可以顯示使用者目前面朝的方向。
android.hardware.sensor.gyroscope
應用程式使用裝置的陀螺儀偵測旋轉和扭轉,建立一個六軸定向系統。透過這個感應器,應用程式可以順暢偵測是否需要切換直向和橫向螢幕方向。
android.hardware.sensor.hifi_sensors
應用程式使用裝置的高精確度 (Hi-Fi) 感應器。舉例來說,遊戲應用程式可以偵測使用者的高精確度動作。
android.hardware.sensor.heartrate
應用程式使用裝置的心率監測器。舉例來說,健身應用程式可以報告使用者心率隨時間變化的趨勢。
android.hardware.sensor.heartrate.ecg
應用程式使用裝置的心電圖 (ECG) 心率感應器。舉例來說,健身應用程式可以報告更詳細的使用者心率相關資訊。
android.hardware.sensor.light
應用程式使用裝置的光度感應器。舉例來說,應用程式可以根據環境亮度條件,顯示兩種色彩配置中的一種。
android.hardware.sensor.proximity
應用程式使用裝置的鄰近感應器。舉例來說,電話應用程式可在偵測到使用者手持裝置貼近身體時關閉螢幕。
android.hardware.sensor.relative_humidity
應用程式使用裝置的相對濕度感應器。舉例來說,天氣應用程式可利用濕度計算並報告目前的露點。
android.hardware.sensor.stepcounter
應用程式使用裝置的計步器。舉例來說,健身應用程式可以報告使用者需要走多少步,才能達成每日步數目標。
android.hardware.sensor.stepdetector
應用程式使用裝置的計步偵測器。舉例來說,健身應用程式可以利用每步的時間間隔,推測使用者正在進行的運動類型。

螢幕硬體功能

android.hardware.screen.landscape
android.hardware.screen.portrait

應用程式要求裝置使用直向或橫向螢幕方向。如果應用程式同時支援這兩種螢幕方向,則不必宣告這兩項功能。

舉例來說,如果應用程式需要直向螢幕方向,請宣告以下功能,只讓支援直向螢幕方向 (固定或透過使用者選擇) 的裝置執行應用程式:

<uses-feature android:name="android.hardware.screen.portrait" />

根據預設,系統會假設這兩種螢幕方向皆非必要,因此應用程式可以安裝在支援一種或兩種螢幕方向的裝置上。但是,如果應用程式的任何活動使用 android:screenOrientation 屬性,要求以特定螢幕方向執行,則這項宣告暗示應用程式需要該螢幕方向。

舉例來說,如果您使用 "landscape""reverseLandscape""sensorLandscape" 宣告 android:screenOrientation,則應用程式僅適用於支援橫向螢幕方向的裝置。

最佳做法是,使用 <uses-feature> 元素宣告對此螢幕方向的需求。如果您使用 android:screenOrientation but don't actually require it, you can disable the requirement by declaring the orientation with a <uses-feature> element and include android:required="false". 宣告活動的螢幕方向,但實際上並非必要,建議您使用 <uses-feature> 元素宣告螢幕方向並加入 android:required="false",即可停用該需求。

For backward compatibility, any device running Android 3.1 (API level 12) or lower supports both landscape and portrait orientations.

Telephony hardware features

android.hardware.telephony
The app uses the device's telephony features, such as telephony radio with data communication services.
android.hardware.telephony.cdma

The app uses the Code Division Multiple Access (CDMA) telephony radio system.

By using this feature, an app implies that it also uses the android.hardware.telephony feature, unless this parent feature is declared with android:required="false".

android.hardware.telephony.gsm

The app uses the Global System for Mobile Communications (GSM) telephony radio system.

By using this feature, an app implies that it also uses the android.hardware.telephony feature, unless this parent feature is declared with android:required="false".

Touchscreen hardware features

android.hardware.faketouch

The app uses basic touch interaction events, such as tapping and dragging.

When declared as required, this feature indicates that the app is compatible with a device only if that device has an emulated "fake touch" touchscreen or has an actual touchscreen.

A device that offers a fake touch interface provides a user input system that emulates a subset of a touchscreen's capabilities. For example, a mouse or remote control might drive an on-screen cursor.

If your app requires basic point and click interaction and doesn't work with only a D-pad controller, declare this feature. Because this is the minimum level of touch interaction, you can also use an app that declares this feature on devices that offer more complex touch interfaces.

Apps require the android.hardware.faketouch feature by default. If you want your app to be limited to devices that only have a touchscreen, you must explicitly declare that touchscreen is required as follows:

<uses-feature android:name="android.hardware.touchscreen"
    android:required="true" />

All apps that don't explicitly require android.hardware.touchscreen, as shown in the following example, also work on devices with android.hardware.faketouch.

<uses-feature android:name="android.hardware.touchscreen" android:required="false" />
android.hardware.faketouch.multitouch.distinct

The app tracks two or more distinct "fingers" on a fake touch interface. This is a superset of the android.hardware.faketouch feature. When declared as required, this feature indicates that the app is compatible with a device only if that device emulates distinct tracking of two or more fingers or has an actual touchscreen.

Unlike the distinct multitouch defined by android.hardware.touchscreen.multitouch.distinct, input devices that support distinct multitouch with a fake touch interface don't support all two-finger gestures, because the input is transformed to cursor movement on the screen. That is, single-finger gestures on such a device move a cursor, two-finger swipes cause single-finger touch events to occur, and other two-finger gestures trigger the corresponding two-finger touch events.

A device that provides a two-finger touch trackpad for cursor movement can support this feature.

android.hardware.faketouch.multitouch.jazzhand

The app tracks five or more distinct "fingers" on a fake touch interface. This is a superset of the android.hardware.faketouch feature. When declared as required, this feature indicates that the app is compatible with a device only if that device emulates distinct tracking of five or more fingers or has an actual touchscreen.

Unlike the distinct multitouch defined by android.hardware.touchscreen.multitouch.jazzhand, input devices that support jazzhand multitouch with a fake touch interface don't support all five-finger gestures, because the input is transformed to cursor movement on the screen. That is, single-finger gestures on such a device move a cursor, multi-finger gestures cause single-finger touch events to occur, and other multi-finger gestures trigger the corresponding multi-finger touch events.

A device that provides a five-finger touch trackpad for cursor movement can support this feature.

android.hardware.touchscreen

The app uses the device's touchscreen capabilities for gestures that are more interactive than basic touch events, such as a fling. This is a superset of the android.hardware.faketouch feature.

By default, all apps require this feature and therefore aren't available to devices that provide only an emulated "fake touch" interface. You can make your app available on devices that provide a fake touch interface, or even on devices that provide only a D-pad controller, by explicitly declaring that a touchscreen is not required using android.hardware.touchscreen with android:required="false". Add this declaration if your app uses, but doesn't require, a real touchscreen interface. All apps that don't explicitly require android.hardware.touchscreen also work on devices with android.hardware.faketouch.

If your app in fact requires a touch interface, such as to perform more advanced touch gestures like flings, then you don't need to declare any touch interface features, because they're required by default. However, it's best if you explicitly declare all features that your app uses.

If you require more complex touch interaction, such as multi-finger gestures, declare that your app uses advanced touchscreen features.

android.hardware.touchscreen.multitouch

The app uses the device's basic two-point multitouch capabilities, such as for pinch gestures, but the app doesn't need to track touches independently. This is a superset of the android.hardware.touchscreen feature.

By using this feature, an app implies that it also uses the android.hardware.touchscreen feature, unless this parent feature is declared with android:required="false".

android.hardware.touchscreen.multitouch.distinct

The app uses the device's advanced multitouch capabilities for tracking two or more points independently. This feature is a superset of the android.hardware.touchscreen.multitouch feature.

By using this feature, an app implies that it also uses the android.hardware.touchscreen.multitouch feature, unless this parent feature is declared with android:required="false".

android.hardware.touchscreen.multitouch.jazzhand

The app uses the device's advanced multitouch capabilities for tracking five or more points independently. This feature is a superset of the android.hardware.touchscreen.multitouch feature.

By using this feature, an app implies that it also uses the android.hardware.touchscreen.multitouch feature, unless this parent feature is declared with android:required="false".

USB hardware features

android.hardware.usb.accessory
The app behaves as a USB device and connects to USB hosts.
android.hardware.usb.host
The app uses the USB accessories that are connected to the device. The device serves as the USB host.

Vulkan hardware features

android.hardware.vulkan.compute
The app uses Vulkan compute features. This feature indicates that the app requires the hardware-accelerated Vulkan implementation. The feature version indicates which level of optional compute features the app requires beyond the Vulkan 1.0 requirements. For example, if your app requires Vulkan compute level 0 support, declare the following feature:
<uses-feature
    android:name="android.hardware.vulkan.compute"
    android:version="0"
    android:required="true" />
For more details about the feature version, see FEATURE_VULKAN_HARDWARE_COMPUTE.
android.hardware.vulkan.level
The app uses Vulkan level features. This feature indicates that the app requires the hardware-accelerated Vulkan implementation. The feature version indicates which level of optional hardware features the app requires. For example, if your app requires Vulkan hardware level 0 support, declare the following feature:
<uses-feature
    android:name="android.hardware.vulkan.level"
    android:version="0"
    android:required="true" />
For more information about the feature version, see FEATURE_VULKAN_HARDWARE_LEVEL.
android.hardware.vulkan.version
The app uses Vulkan. This feature indicates that the app requires the hardware-accelerated Vulkan implementation. The feature version indicates the minimum version of Vulkan API support the app requires. For example, if your app requires Vulkan 1.0 support, declare the following feature:
<uses-feature
    android:name="android.hardware.vulkan.version"
    android:version="0x400003"
    android:required="true" />
For more details about the feature version, see FEATURE_VULKAN_HARDWARE_VERSION.

Wi-Fi hardware features

android.hardware.wifi
The app uses 802.11 networking (Wi-Fi) features on the device.
android.hardware.wifi.direct
The app uses the Wi-Fi Direct networking features on the device.

Software features

This section presents the software features supported by the most current platform release. To indicate that your app uses or requires a software feature, declare the corresponding value, beginning with "android.software", in an android:name attribute. Each time you declare a software feature, use a separate <uses-feature> element.

Communication software features

android.software.sip
The app uses Session Initiation Protocol (SIP) services. By using SIP, the app can support internet telephony operations, such as video conferencing and instant messaging.
android.software.sip.voip

The app uses SIP-based Voice Over Internet Protocol (VoIP) services. By using VoIP, the app can support real-time internet telephony operations, such as two-way video conferencing.

By using this feature, an app implies that it also uses the android.software.sip feature, unless this parent feature is declared with android:required="false".

android.software.webview
The app displays content from the internet.

Custom input software features

android.software.input_methods
The app uses a new input method, which the developer defines in an InputMethodService.

Device management software features

android.software.backup
The app includes logic to handle a backup and restore operation.
android.software.device_admin
The app uses device administrators to enforce a device policy.
android.software.managed_users
The app supports secondary users and managed profiles.
android.software.securely_removes_users
The app can permanently remove users and their associated data.
android.software.verified_boot
The app includes logic to handle results from the device's verified boot feature, which detects whether the device's configuration changes during a restart operation.

Media software features

android.software.midi
The app connects to musical instruments or outputs sound using the Musical Instrument Digital Interface (MIDI) protocol.
android.software.print
The app includes commands for printing documents displayed on the device.
android.software.leanback
The app is designed to run on Android TV devices.
android.software.live_tv
The app streams live television programs.

Screen interface software features

android.software.app_widgets
The app uses or provides App Widgets and is intended only for devices that include a Home screen or similar location where users can embed App Widgets.
android.software.home_screen
The app behaves as a replacement to the device's Home screen.
android.software.live_wallpaper
The app uses or provides wallpapers that include animation.

Permissions that imply feature requirements

Some hardware and software feature constants are made available to applications after the corresponding API. Because of this, some apps might use the API before they can declare that they require the API using the <uses-feature> system.

To prevent those apps from being made available unintentionally, Google Play assumes that certain hardware-related permissions indicate that the underlying hardware features are required by default. For instance, applications that use Bluetooth must request the BLUETOOTH permission in a <uses-permission> element.

For legacy apps, Google Play assumes that the permission declaration means that the underlying android.hardware.bluetooth feature is required by the application and sets up filtering based on that feature. Table 2 lists permissions that imply feature requirements equivalent to those declared in <uses-feature> elements.

<uses-feature> declarations, including any declared android:required attribute, always take precedence over features implied by the permissions in table 2. For any of these permissions, you can disable filtering based on the implied feature by explicitly declaring the feature in a <uses-feature> element with the required attribute set to false.

For example, to disable filtering based on the CAMERA permission, add the following <uses-feature> declarations to the manifest file:

<uses-feature android:name="android.hardware.camera" android:required="false" />
<uses-feature android:name="android.hardware.camera.autofocus" android:required="false" />

Caution: If your app targets Android 5.0 (API level 21) or higher and uses the ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION permission to receive location updates from the network or a GPS, respectively, you must also explicitly declare that your app uses the android.hardware.location.network or android.hardware.location.gps hardware features.

Table 2. Device permissions that imply device hardware use.

Category Permission Implied feature requirement
Bluetooth BLUETOOTH android.hardware.bluetooth

See Special handling for Bluetooth feature for details.

BLUETOOTH_ADMIN android.hardware.bluetooth
Camera CAMERA android.hardware.camera
android.hardware.camera.autofocus
Location ACCESS_MOCK_LOCATION android.hardware.location
ACCESS_LOCATION_EXTRA_COMMANDS android.hardware.location
INSTALL_LOCATION_PROVIDER android.hardware.location
ACCESS_COARSE_LOCATION

android.hardware.location

android.hardware.location.network (Only when target API level is 20 or lower.)

ACCESS_FINE_LOCATION

android.hardware.location

android.hardware.location.gps (Only when target API level is 20 or lower.)

Microphone RECORD_AUDIO android.hardware.microphone
Telephony CALL_PHONE android.hardware.telephony
CALL_PRIVILEGED android.hardware.telephony
MODIFY_PHONE_STATE android.hardware.telephony
PROCESS_OUTGOING_CALLS android.hardware.telephony
READ_SMS android.hardware.telephony
RECEIVE_SMS android.hardware.telephony
RECEIVE_MMS android.hardware.telephony
RECEIVE_WAP_PUSH android.hardware.telephony
SEND_SMS android.hardware.telephony
WRITE_APN_SETTINGS android.hardware.telephony
WRITE_SMS android.hardware.telephony
Wi-Fi ACCESS_WIFI_STATE android.hardware.wifi
CHANGE_WIFI_STATE android.hardware.wifi
CHANGE_WIFI_MULTICAST_STATE android.hardware.wifi