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

yangke.png

在運行時請求權限

從 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

喜歡的話、雙擊、評論、轉發,動一動你的小手讓更多的人知道,關注帥比~楊!

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 229,732評論 6 539
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 99,214評論 3 426
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 177,781評論 0 382
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,588評論 1 316
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 72,315評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,699評論 1 327
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,698評論 3 446
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,882評論 0 289
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,441評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 41,189評論 3 356
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,388評論 1 372
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,933評論 5 363
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,613評論 3 348
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 35,023評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,310評論 1 293
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 52,112評論 3 398
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,334評論 2 377

推薦閱讀更多精彩內容