Android 6.0 運行時權限解析-[Android_YangKe]

在運行時請求權限

從 Android 6.0(API 級別 23)開始,用戶開始在應用運行時向其授予權限,而不是在應用安裝時授予。此方法可以簡化應用安裝過程,因爲用戶在安裝或更新應用時不需要授予權限。它還讓用戶可以對應用的功能進行更多控制;例如,用戶可以選擇爲相機應用提供相機訪問權限,而不提供設備位置的訪問權限。用戶可以隨時進入應用的“Settings”屏幕調用權限。

系統權限分爲兩類:正常權限和危險權限:

  • 正常權限不會直接給用戶隱私權帶來風險。如果您的應用在其清單中列出了正常權限,系統將自動授予該權限。

  • 危險權限會授予應用訪問用戶機密數據的權限。如果您的應用在其清單中列出了正常權限,系統將自動授予該權限。如果您列出了危險權限,則用戶必須明確批准您的應用使用這些權限。

權限組

所有危險的 Android 系統權限都屬於權限組。如果設備運行的是 Android 6.0(API 級別 23),並且應用的targetSdkVersion 23 或更高版本,則當用戶請求危險權限時系統會發生以下行爲:
* 如果應用請求其清單中列出的危險權限,而應用目前在權限組中沒有任何權限,則系統會向用戶顯示一個對話框,描述應用要訪問的權限組。對話框不描述該組內的具體權限。例如,如果應用請求READ_CONTACTS 權限,系統對話框只說明該應用需要訪問設備的聯繫信息。如果用戶批准,系統將嚮應用授予其請求的權限。
* 如果應用請求其清單中列出的危險權限,而應用在同一權限組中已有另一項危險權限,則系統會立即授予該權限,而無需與用戶進行任何交互。例如,如果某應用已經請求並且被授予了READ_CONTACTS權限,然後它又請求WRITE_CONTACTS,系統將立即授予該權限。

任何權限都可屬於一個權限組,包括正常權限和應用定義的權限。但權限組僅當權限危險時才影響用戶體驗。可以忽略正常權限的權限組。

危險權限和權限組

權限組 權限
CALENDAR READ_CALENDAR
WRITE_CALENDAR
CAMERA CAMERA
CONTANCTS WRITE_CONTANCTS
READ_CONTANCTS
GET_ACCOUNTS
LOCATION ACCESS_FINE_LOCATION
ACCESS_COARSE_LOCATION
MICROPHONE RECORD_AUDIO
PHONE READ_PHONE_STATE
CALL_PHONE
READ_CALL_LOG
WRITE_CALL_LOG
ADD_VOICEMAIL
USE_SIP
PROCESS_OUTGOING_CALLS
SENSORS BODY_SENSORS
SMS SEND_SMS
RECEIVE_SMS
READ_SMS
RECEIVE_WAP_PUSH
RECEIVE_MMS
STORAGE READ_EXTERNAL_STORAGE
WRITE_EXTERNAL_STORAGE

檢查權限

如果您的應用需要危險權限,則每次執行需要這一權限的操作時您都必須檢查自己是否具有該權限。用戶始終可以自由調用此權限,因此,即使應用昨天使用了相機,它不能假設自己今天仍具有該權限。
要檢查您是否具有某項權限,請調用ContextCompat.checkSelfPermission()方法。例如,以下代碼段顯示瞭如何檢查 Activity 是否具有在日曆中進行寫入的權限:

// Assume thisActivity is the current activity
int permissionCheck = ContextCompat.checkSelfPermission(thisActivity,Manifest.permission.WRITE_CALENDAR);

如果應用具有此權限,方法將返回PackageManager.PERMISSION_GRANTED,並且應用可以繼續操作。如果應用不具有此權限,方法將返回PERMISSION_DENIED,且應用必須明確向用戶要求權限。

請求權限


如果您的應用需要應用清單中列出的危險權限,那麼,它必須要求用戶授予該權限。Android 爲您提供了多種權限請求方式。調用這些方法將顯示一個標準的 Android 對話框,不過,您不能對它們進行自定義。

解釋應用爲什麼需要權限

在某些情況下,您可能需要幫助用戶瞭解您的應用爲什麼需要某項權限。例如,如果用戶啓動一個攝影應用,用戶對應用要求使用相機的權限可能不會感到吃驚,但用戶可能無法理解爲什麼此應用想要訪問用戶的位置或聯繫人。在請求權限之前,不妨爲用戶提供一個解釋。請記住,您不需要通過解釋來說服用戶;如果您提供太多解釋,用戶可能發現應用令人失望並將其移除。

您可以採用的一個方法是僅在用戶已拒絕某項權限請求時提供解釋。如果用戶繼續嘗試使用需要某項權限的功能,但繼續拒絕權限請求,則可能表明用戶不理解應用爲什麼需要此權限才能提供相關功能。對於這種情況,比較好的做法是顯示解釋。

爲了幫助查找用戶可能需要解釋的情形,Android 提供了一個實用程序方法,即shouldShowRequestPermissionRationale()。如果應用之前請求過此權限但用戶拒絕了請求,此方法將返回true。

注:如果用戶在過去拒絕了權限請求,並在權限請求系統對話框中選擇了 Don’t ask again 選項,此方法將返回 false。

請求您需要的權限

如果應用尚無所需的權限,則應用必須調用一個requestPermissions() 方法,以請求適當的權限。應用將傳遞其所需的權限,以及您指定用於識別此權限請求的整型請求代碼。此方法異步運行:它會立即返回,並且在用戶響應對話框之後,系統會使用結果調用應用的回調方法,將應用傳遞的相同請求代碼傳遞到requestPermissions()。

以下代碼可以檢查應用是否具備讀取用戶聯繫人的權限,並根據需要請求該權限:

// Here, thisActivity is the current activity
if (ContextCompat.checkSelfPermission(thisActivity,
            Manifest.permission.READ_CONTACTS)
    != PackageManager.PERMISSION_GRANTED) {

// Should we show an explanation?
if (ActivityCompat.shouldShowRequestPermissionRationale(thisActivity,
        Manifest.permission.READ_CONTACTS)) {

    // Show an expanation to the user *asynchronously* -- don't block
    // this thread waiting for the user's response! After the user
    // sees the explanation, try again to request the permission.

} else {

    // No explanation needed, we can request the permission.

    ActivityCompat.requestPermissions(thisActivity,
            new String[]{Manifest.permission.READ_CONTACTS},
            MY_PERMISSIONS_REQUEST_READ_CONTACTS);

    // MY_PERMISSIONS_REQUEST_READ_CONTACTS is an
    // app-defined int constant. The callback method gets the
    // result of the request.
   }
}

:當您的應用調用requestPermissions()時,系統將向用戶顯示一個標準對話框。您的應用無法配置或更改此對話框。如果您需要爲用戶提供任何信息或解釋,您應在調用requestPermissions()之前進行,如解釋應用爲什麼需要權限中所述。

處理權限請求響應

當應用請求權限時,系統將向用戶顯示一個對話框。當用戶響應時,系統將調用應用的onRequestPermissionsResult()方法,向其傳遞用戶響應。您的應用必須替換該方法,以瞭解是否已獲得相應權限。回調會將您傳遞的相同請求代碼傳遞給requestPermissions()。例如,如果應用請求READ_CONTACTS訪問權限,則它可能採用以下回調方法:

@Override
public void onRequestPermissionsResult(int requestCode,
    String permissions[], int[] grantResults) {
    switch (requestCode) {
    case MY_PERMISSIONS_REQUEST_READ_CONTACTS: {
        // If request is cancelled, the result arrays are empty.
        if (grantResults.length > 0
            && grantResults[0] == PackageManager.PERMISSION_GRANTED) {

            // permission was granted, yay! Do the
            // contacts-related task you need to do.

        } else {

            // permission denied, boo! Disable the
            // functionality that depends on this permission.
        }
        return;
    }

    // other 'case' lines to check for other
    // permissions this app might request
   }
}

系統顯示的對話框說明了您的應用需要訪問的權限組;它不會列出具體權限。例如,如果您請求READ_CONTACTS權限,系統對話框只顯示您的應用需要訪問設備的聯繫人。用戶只需要爲每個權限組授予一次權限。如果您的應用請求該組中的任何其他權限(已在您的應用清單中列出),系統將自動授予應用這些權限。當您請求此權限時,系統會調用您的onRequestPermissionsResult()回調方法,並傳遞PERMISSION_GRANTED,如果用戶已通過系統對話框明確同意您的權限請求,系統將採用相同方式操作。

注:您的應用仍需要明確請求其需要的每項權限,即使用戶已嚮應用授予該權限組中的其他權限。此外,權限分組在將來的 Android 版本中可能會發生變化。您的代碼不應依賴特定權限屬於或不屬於相同組這種假設。

例如,假設您在應用清單中列出了READ_CONTACTS
和WRITE_CONTACTS。如果您請求READ_CONTACTS且用戶授予了此權限,那麼,當您請求WRITE_CONTACTS時,系統將立即授予您該權限,不會與用戶交互。

如果用戶拒絕了某項權限請求,您的應用應採取適當的操作。例如,您的應用可能顯示一個對話框,解釋它爲什麼無法執行用戶已經請求但需要該權限的操作。
當系統要求用戶授予權限時,用戶可以選擇指示系統不再要求提供該權限。這種情況下,無論應用在什麼時候使用requestPermissions()再次要求該權限,系統都會立即拒絕此請求。系統會調用您的onRequestPermissionsResult()回調方法,並傳遞PERMISSION_DENIED,如果用戶再次明確拒絕了您的請求,系統將採用相同方式操作。這意味着當您調用requestPermissions()時,您不能假設已經發生與用戶的任何直接交互。

最好的學習網站:https://developer.android.com/training/permissions

喜歡的話、雙擊、評論、轉發,動一動你的小手讓更多的人知道,關注帥比~楊! 第一時間更新地址:歡迎關注簡書“Android_YangKe”

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章