Android應用權限簡要介紹

• 1. 一個Android應用默認情況下是不擁有任何權限的, 一個應用是沒有權利去進行一些可能會造成不好影響的操作的. 這些不好的影響可能是對其它應用,操作系統(tǒng),或者是用戶.如果應用需要一些額外的能力,則它需要在AndroidManifest.xml中靜態(tài)地聲明相應的權限.
     如果應用沒有在manifest中聲明權限, 卻使用了相應的功能, 在調用到相應功能的時候, 將會拋出異常.
     比如程序要發(fā)送一個請求,卻忘記加Internet權限, 那么在發(fā)送這個請求的時候程序就會拋出異常,一般不會catch這個異常,所以程序直接就崩潰了:
     Caused by: java.lang.SecurityException: Permission denied (missing INTERNET permission?)
     Android 6.0開始, 一部分比較危險的權限需要在程序運行時顯式彈框,請求用戶授權.
     至于什么時候彈這個框,由應用程序自己決定.
     對于其他權限,認為不是很危險,所以仍然保持原來的做法,在用戶安裝應用程序時就予以授權.

Permission的保護等級

permission的保護等級通過protectionLevel屬性設置, 共有4種: normal,dangerous,signature,signatureOrSystem.
簽名相關的比較不常用, 剩下的兩種是normal和dangerous
總結下來就是: 所有的權限仍然在manifest中靜態(tài)聲明, normal權限的在安裝的時候自動授權, 而dangerous的權限需要應用明確地請求用戶授權.
Dangerous Permissions:

Table 1. Dangerous permissions and permission groups.

可以總結為:
1.所有的權限都在manifest中聲明.
2.如果(1)你的app的targetSdkVersion是23及以上,并且(2)app運行在Android 6.0及以上的設備,危險權限必須動態(tài)請求.
當權限被拒絕,app理應還是能夠使用的,只不過權限相關的部分功能不能用.
3.上一條中的兩個條件(1)(2)沒有同時滿足,即屬于其他情況, 所有權限在安裝時請求,如果用戶不接受,則不安裝.

特別注意這種情況: 舊應用新系統(tǒng).
如果targetSdkVersion小于23,即被認為是Android 6.0發(fā)布之前開發(fā)的應用, 還沒有兼容6.0.
這種應用即便是被裝在Android 6.0的機器上,也是采用原來的安裝即授予權限邏輯, 所有權限在應用安裝時全部被授權.
在Android 6.0的設備上安裝targetSdkVersion小于23的應用之后, 可以在應用的設置中查看,發(fā)現(xiàn)所有的dangerous權限狀態(tài)都是打開.

Permission group
所有的權限都有自己的permission group.
系統(tǒng)彈框請求某一個permission時也是只說明了它的類別,當用戶同意,系統(tǒng)會給予它該條permission.(只有這一條).
但是如果app已經(jīng)有了該group下的另一條permission,系統(tǒng)將會自動授予權限(也即請求權限的callback直接返回),這過程中不與用戶交互.

動態(tài)權限請求的實現(xiàn)

原文: https://developer.android.com/training/permissions/requesting.html

因為權限動態(tài)檢查相關的API是Android 6.0才加入的, 所以minSdkVersion不是23時,推薦使用SupportLibrary來實現(xiàn),好處是: 程序里不必加if來判斷當前設備的版本.

1.檢查權限狀態(tài)

如果執(zhí)行的操作需要一個dangerous permission, 那么每次在執(zhí)行操作的地方都必須check你是否有這個permission, 因為用戶可以在應用設置里隨意地更改授權情況, 所以必須每次在使用前都檢查是否有權限.

檢查權限的方法: ContextCompat.checkSelfPermission()兩個參數(shù)分別是Context和權限名.

返回值是:PERMISSION_GRANTED if you have the permission, or PERMISSION_DENIED if not.

比如:

if (PackageManager.PERMISSION_GRANTED== ContextCompat.checkSelfPermission(
MainActivity.this, Manifest.permission.READ_CONTACTS)) { 
    //has permission, do operation directly
    ContactsUtils.readPhoneContacts(this);
    Log.i(DEBUG_TAG, "user has the permission already!");
    } else { 
      //do not have permission
}

2.動態(tài)請求權限

如果上面權限檢查的結果是DENIED, 那么就需要顯式地向用戶請求這個權限了.

Android提供了幾個方法來動態(tài)請求權限, 調用這些方法會顯示出一個標準的Dialog, 這個Dialog目前是不能被定制的.

2.1有時候可能需要解釋為什么需要這個權限

有時候你可能會需要跟用戶解釋一下權限的用途.

注意不是每條權限都需要解釋,顯而易見的那種可以不解釋,太多的解釋會降低用戶體驗.

一種方式是,當用戶拒絕過這個權限,但是又用到了這個功能, 那么很可能用戶不是很明白為什么app需要這個權限, 這時候就可以先向用戶解釋一下.

為了發(fā)現(xiàn)這種用戶可能需要解釋的情形, Android提供了一個工具類方法: shouldShowRequestPermissionRationale()

如果app之前請求過該權限,被用戶拒絕, 這個方法就會返回true.

如果用戶之前拒絕權限的時候勾選了對話框中”Don’t ask again”的選項,那么這個方法會返回false.

如果設備策略禁止應用擁有這條權限, 這個方法也返回false.

注意具體解釋原因的這個dialog需要自己實現(xiàn), 系統(tǒng)沒有提供.

2.2請求權限

請求權限的方法是: requestPermissions() 傳入一個Activity, 一個permission名字的數(shù)組, 和一個整型的request code.

這個方法是異步的,它會立即返回, 當用戶和dialog交互完成之后,系統(tǒng)會調用回調方法,傳回用戶的選擇結果和對應的request code.

代碼:

if (PackageManager.PERMISSION_GRANTED == ContextCompat.checkSelfP
ermission(MainActivity.this, Manifest.permission.READ_CONTACTS)) { 
//has permission, do operation directly
    ContactsUtils.readPhoneContacts(this);
    Log.i(DEBUG_TAG, "user has the permission already!");
} else { 
    //do not have permission
    Log.i(DEBUG_TAG, "user do not have this permission!");
   // Should we show an explanation?
      if (ActivityCompat.shouldShowRequestPermissionRationale(MainActivit
        y.this, Manifest.permission.READ_CONTACTS)) { 
// Show an explanation 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.
       Log.i(DEBUG_TAG, "we should explain why we need this permission!");
    } else {
     // No explanation needed, we can request the permission.
        Log.i(DEBUG_TAG, "==request the permission==");

        ActivityCompat.requestPermissions(MainActivity.this, 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.
 }
}  

這個對話框是系統(tǒng)的,不能自定義.

經(jīng)驗證, 請求權限對話框中的”Don’t ask again”的選項, 只有該條權限之前的狀態(tài)是Denied的時候,才會出現(xiàn).

以前從未授權(即第一次彈框), 或者之前的狀態(tài)是Granted(當然這種情況一般不會彈框詢問), 出現(xiàn)的彈框都是不帶該不再詢問的選項的.

2.3處理請求權限的響應

當用戶對請求權限的dialog做出響應之后,系統(tǒng)會調用onRequestPermissionsResult() 方法,傳回用戶的響應.

這個回調中request code即為調用requestPermissions()時傳入的參數(shù),是app自定義的一個整型值.

如果請求取消,返回的數(shù)組將會為空.

代碼:

@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.
                ContactsUtils.readPhoneContacts(this);
                Log.i(DEBUG_TAG, "user granted the permission!");

            } else { // permission denied, boo! Disable the 
                // functionality that depends on this permission.
                Log.i(DEBUG_TAG, "user denied the permission!");
            } return;
        } // other 'case' lines to check for other 
// permissions this app might request
 }
}

系統(tǒng)自動回調的情況:

有一些情形下,調用

1.自動授權: 如果用戶已經(jīng)允許了permission group中的一條A權限,那么當下次調用requestPermissions()方法請求同一個group中的B權限時, 系統(tǒng)會直接調用onRequestPermissionsResult()` 回調方法, 并傳回PERMISSION_GRANTED的結果.

2.自動拒絕: 如果用戶選擇了不再詢問此條權限,那么app再次調用requestPermissions()方法來請求同一條權限的時候,系統(tǒng)會直接調用onRequestPermissionsResult()回調,返回PERMISSION_DENIED.