執行階段權限

在 Android 6.0 及更高版本中,Android 應用程式權限模型旨在使權限對使用者更易於理解、更有用且更安全。此模型將需要危險權限的 Android 應用程式(請參閱受影響的權限)從安裝時權限模型移至執行時間權限模型:

  • 安裝時權限

    Android 5.1 及更低版本)使用者在安裝或更新應用程式時向應用程式授予危險權限。設備製造商和運營商可以在不通知使用者的情況下預先安裝具有預先授予權限的應用程式。

  • 運行時權限

    ( Android 6.0 – 9 ) 使用者在應用程式運行時向應用程式授予危險權限。何時請求權限(例如當應用程式啟動或當使用者存取特定功能時)取決於應用程序,但使用者授予/拒絕對特定權限群組的應用程式存取權限。 OEM/運營商可以預先安裝應用程序,但不能預先授予權限,除非他們經過例外流程。 (請參閱創建例外。)

    ( Android 10 ) 使用者可以看到更高的透明度,並可以控制哪些應用程式具有活動識別 (AR) 運行時權限。執行時間權限對話方塊會提示使用者始終允許、使用時允許或拒絕權限。當作業系統升級到 Android 10 時,授予應用程式的權限將保留,但使用者可以進入「設定」並進行更改。

運行時權限可防止應用程式在未經使用者同意的情況下存取私有數據,並為應用程式提供額外的上下文和可見性,以了解應用程式正在尋求或已授予的權限類型。運行時模型鼓勵開發人員幫助使用者了解應用程式為何需要所請求的權限,並提供更大的透明度,以便使用者可以在授予或拒絕權限方面做出更好的決策。

受影響的權限

Android 6.0 及更高版本需要危險權限才能使用執行時間權限模型。危險權限是風險較高的權限(例如READ_CALENDAR ),它們授予請求應用程式對私有使用者資料的存取權或對裝置的控制權,這可能會對使用者產生負面影響。若要查看危險權限列表,請執行以下命令:

adb shell pm list permissions -g -d

Android 6.0 及更高版本不會改變正常權限的行為。這些都是非危險權限,包括普通權限、系統權限、簽署權限。普通權限是風險較低的權限(例如SET_WALLPAPER ),它授予請求應用程式對隔離應用程式層級功能的存取權限,同時對其他應用程式、系統或使用者造成的風險最小。與 Android 5.1 及更低版本一樣,系統在安裝時會自動向請求的應用程式授予正常權限,並且不會提示使用者進行批准。有關權限的詳細信息,請參閱<permission> 元素文件。

Android 10 中的硬限制和軟限制

除了危險之外,權限還可以是硬限製或軟限制的。無論哪種情況,受限權限也必須列入許可名單。非允許的硬限制的行為與非允許的軟限制不同:

  • 硬限制)應用程式無法被授予未列入許可名單的權限。
  • 軟限制)沒有列入許可名單的應用程式根據它們請求的特定權限運行。所請求權限的公共文件中描述了該行為。

安裝應用程式時,安裝程式(例如 Google Play 商店)可能會選擇不將應用程式的受限權限列入白名單。權限受平台限制,僅當應用程式符合平台政策的特殊標準時才可授予。硬限制權限類型的範例包括 SMS 和通話記錄權限。

允許列入許可名單發生在安裝期間,並且當

  • 在 Android 9 到 10 升級過程中已經安裝了一個應用程式。
  • 預授予權限或預安裝應用程式。
  • 已定義將權限列入白名單的角色需要權限。
  • 安裝程式(例如 Google Play 商店)將該權限標記為允許清單。

使用者無法手動將權限列入許可名單。

要求

運行時權限模型適用於所有應用程序,包括預先安裝的應用程式和作為設定過程的一部分交付到裝置的應用程式。應用軟體需求包括:

  • 運行時權限模型必須在所有運行 Android 6.0 及更高版本的裝置上保持一致。這是由 Android 相容性測試套件 (CTS) 測試強制執行的。
  • 應用程式必須在運行時提示使用者授予應用程式權限。有關詳細信息,請參閱更新應用程式。可以向預設應用程式和處理程序授予有限的例外,這些應用程式和處理程序提供對設備的預期操作至關重要的基本設備功能。 (例如,裝置用於處理ACTION_CALL的預設撥號器應用可能具有電話權限存取。)有關詳細信息,請參閱建立例外
  • 具有危險權限的預先載入應用程式必須針對 API 等級 23 並維護執行時間權限模型。即應用安裝時的UI流程不能偏離PermissionController的AOSP實現,使用者可以撤銷預先安裝應用的危險權限等等。
  • 無頭應用程式必須使用活動來請求權限或與具有必要權限的另一個應用程式共用 UID。有關詳細信息,請參閱無頭應用程式

權限遷移

更新至 Android 6.0 或更高版本後,授予 Android 5.x 上的應用程式的權限仍然有效,但使用者可以隨時撤銷這些權限。

在 Android 9 到 10 更新中,所有硬限制權限都會被列入白名單。有關實現前台/後台分離權限的詳細信息,請參閱Android 10 隱私更改,從請求後台位置開始。

一體化

整合 Android 6.0 及更高版本的應用程式執行時間權限模型時,您必須更新預先安裝的應用程式才能使用新模型。您也可以為作為核心功能的預設處理程序/提供者的應用程式定義例外,定義自訂權限,並自訂PermissionController應用程式中使用的主題。

更新應用程式

系統映像上的應用程式和預先安裝的應用程式不會自動預先授予權限。我們鼓勵您與預先安裝應用程式開發人員(OEM、營運商和第三方)合作,根據開發人員指南進行所需的應用程式修改。具體來說,您必須確保修改預先安裝應用程序,以避免用戶撤銷權限時出現當機和其他問題。

預先載入的應用程式

在 Android 9 及更低版本中,使用危險權限的預載應用程式必須針對 API 等級 23 或更高版本,並維護 Android 6.0 及更高版本的 AOSP 權限模型。例如,應用程式安裝期間的 UI 流程不得偏離PermissionController的 AOSP 實作。使用者甚至可以撤銷預先安裝應用程式的危險權限。

在 Android 6.0 到 9 中,一些權限是在安裝流程中授予的。但是,從 10 開始,安裝流程(由Package Installer應用程式執行)是與權限授予(在Permission Controller應用程式中)分開的功能。

無頭應用程式

只有活動可以請求權限。服務無法直接請求權限。

  • 在 Android 5.1 及更早版本中,無頭應用程式可以在安裝時請求權限,或者如果它們是在不使用 Activity 的情況下預先安裝的。
  • 在 Android 6.0 及更高版本中,無頭應用程式必須使用以下方法之一來請求權限:
    • 新增一個活動來請求權限。 (這是首選方法。)
    • 與具有必要權限的其他應用程式共用 UID。只有當您需要平台將多個 APK 作為單一應用程式處理時,才使用此方法。

目標是避免使用者對脫離上下文的權限請求感到困惑。

自訂 PackageInstaller UI

如果需要,您可以透過更新 PackageInstaller 使用的預設裝置主題( Theme.DeviceDefault.SettingsTheme.DeviceDefault.Light.Dialog.NoActionBar )來自訂 Permissions UI主題。但是,由於一致性對於應用程式開發人員至關重要,因此您無法自訂權限 UI 何時出現的放置、位置和規則。

要包含其他語言的字串,請將字串貢獻給 AOSP。

創建例外

您可以使用 PackageManager 中的DefaultPermissionGrantPolicy.java類別向作為核心作業系統功能的預設處理程序或提供者的應用程式預先授予權限。例子:

ACTION_CALL (Dialer) Default
Phone, Contacts, SMS, Microphone
SMS_DELIVER_ACTION (SMS/MMS) Default
Phone, Contacts, SMS

定義自訂權限

您可以將自訂權限和群組定義為正常危險,並將 OEM/運營商特定的權限新增至現有權限群組,就像在 Android 5.x 及更早版本中一樣。

在Android 6.0及更高版本中,如果新增新的危險權限,則必須以與其他危險權限相同的方式處理它(在應用程式執行時請求並由使用者撤銷)。具體來說:

  • 您可以為目前群組新增權限,但無法修改危險權限和危險權限群組的 AOSP 對應。 (換句話說,您無法從一個群組中刪除權限並將其分配給另一個群組)。
  • 您可以在裝置上安裝的應用程式中新增的權限群組,但無法在平台清單中新增的權限群組。

測試權限

Android 包含相容性測試套件 (CTS) 測試,用於驗證個別權限是否已對應到正確的群組。通過這些測試是 Android 6.0 及更高版本 CTS 相容性的要求。

撤銷權限

在 Android 13 及更高版本中,您可以使用Context.revokeSelfPermissionsOnKill()撤銷自己授予的執行時間權限。撤銷是非同步發生的,並且在安全且不會中斷使用者的情況下被觸發。當觸發撤銷時,所有在呼叫 UID 中執行的進程都將被終止。

重要的是要了解撤銷單一權限可能不會反映在設定 UI 中,該 UI 按群組處理權限。通常,只要授予某個權限群組中的至少一項權限,該權限群組就會顯示為已授予。如果確保使用者能夠確認設定中的撤銷對您很重要,請確保撤銷權限群組中的每個權限。若要了解哪些權限屬於某個群組,您可以使用PackageManager.getGroupOfPlatformPermissionPackageManager.getPlatformPermissionsForGroup

當系統撤銷所要求的權限時,如果尚未授予對應的前台權限,則系統也會撤銷對應的後台權限。

只要進程保留在前台,就不會觸發撤銷,但也可以透過手動終止目前 uid 中執行的所有進程(例如使用System.exit()立即觸發撤銷。不過,建議讓系統決定何時觸發它。

權限撤銷生效後,您可以再次要求,系統會提示使用者同意或拒絕該要求。無法請求先前被使用者拒絕的權限。雖然我們鼓勵您撤銷目前持有但不再需要的權限,但您應注意不要在撤銷生效之前通知使用者有關撤銷的資訊。