自從Android6.0釋出以來，在許可權上做出了很大的變動，不再是之前的只要在manifest設定就可以任意獲取許可權，而是更加的注重使用者的隱私和體驗，不會再強迫使用者因拒絕不該擁有的許可權而導致的無法安裝的事情，也不會再不徵求使用者授權的情況下，就可以任意的訪問使用者隱私，而且即使在授權之後也可以及時的更改許可權。這就是6.0版本做出的更擁護和注重使用者的一大體現。

一、認知

今天我們就來學習下Android6.0的許可權管理。

Android6.0系統把許可權分為兩個級別：

一個是Normal Permissions，即普通許可權，這類許可權不會潛藏有侵害使用者隱私和安全的問題，比如，訪問網路的許可權，訪問WIFI的許可權等；

另一類是Dangerous Permissions，即危險許可權，這類許可權會直接的威脅到使用者的安全和隱私問題，比如說訪問簡訊，相簿等許可權。

但是到底哪些是普通許可權和危險許可權呢，這裡給出分類，大家在使用時以便參考。

1、Normal Permissions （普通許可權）

• ACCESS_LOCATION_EXTRA_COMMANDS
• ACCESS_NETWORK_STATE
• ACCESS_NOTIFICATION_POLICY
• ACCESS_WIFI_STATE
• BLUETOOTH
• BLUETOOTH_ADMIN
• BROADCAST_STICKY
• CHANGE_NETWORK_STATE
• CHANGE_WIFI_MULTICAST_STATE
• CHANGE_WIFI_STATE
• DISABLE_KEYGUARD
• EXPAND_STATUS_BAR
• GET_PACKAGE_SIZE
• INSTALL_SHORTCUT
• INTERNET
• KILL_BACKGROUND_PROCESSES
• MODIFY_AUDIO_SETTINGS
• NFC
• READ_SYNC_SETTINGS
• READ_SYNC_STATS
• RECEIVE_BOOT_COMPLETED
• REORDER_TASKS
• REQUEST_IGNORE_BATTERY_OPTIMIZATIONS
• REQUEST_INSTALL_PACKAGES
• SET_ALARM
• SET_TIME_ZONE
• SET_WALLPAPER
• SET_WALLPAPER_HINTS
• TRANSMIT_IR
• UNINSTALL_SHORTCUT
• USE_FINGERPRINT
• VIBRATE
• WAKE_LOCK
• WRITE_SYNC_SETTINGS

使用以上許可權是不會威脅到使用者安全的，所以這類許可權是可以直接的在manifest裡面直接的使用，而且在安裝後也會直接的生效了。

2、Dangerous Permissions （危險許可權）

• SMS（簡訊）
  • SEND_SMS
  • RECEIVE_SMS
  • READ_SMS
  • RECEIVE_WAP_PUSH
  • RECEIVE_MMS
• STORAGE（儲存卡）
  • READ_EXTERNAL_STORAGE
  • WRITE_EXTERNAL_STORAGE
• CONTACTS（聯絡人）
  • READ_CONTACTS
  • WRITE_CONTACTS
  • GET_ACCOUNTS
• PHONE（手機）
  • READ_PHONE_STATE
  • CALL_PHONE
  • READ_CALL_LOG
  • WRITE_CALL_LOG
  • ADD_VOICEMAIL
  • USE_SIP
  • PROCESS_OUTGOING_CALLS
• CALENDAR（日曆）
  • READ_CALENDAR
  • WRITE_CALENDAR
• CAMERA（相機）
  • CAMERA
• LOCATION（位置）
  • ACCESS_FINE_LOCATION
  • ACCESS_COARSE_LOCATION
• SENSORS（感測器）
  • BODY_SENSORS
• MICROPHONE（麥克風）
  • RECORD_AUDIO

危險許可權和普通許可權也有區別，普通許可權是單條的許可權，而危險許可權是以組展示的，也就是說，當你接受一個危險許可權時，不但但接受的是介面上展示的這一個許可權，而是它所在這個組裡面的其他所有訪問許可權也將會被自動獲取許可權，比如，一旦WRITE_CONTACTS被授權了，App也有READ_CONTACTS和GET_ACCOUNTS的許可權了。
值得注意的是，這類許可權也是需要在manifest中註冊的。

ok，光說不練不是我們的風格，我們寫東西都是基於自己遇到的問題，然後認真的學習後才記錄下來的。一方面鞏固自己的知識，另一方面也希望能幫助他人提供一點解決方案。

二、實戰

實戰部分分為幾種情況，因為根據我們的目標SDK版本和Android真機版本的不同會有不同的情景，針對普通許可權大家都熟悉，就不介紹了，下面一一介紹危險許可權的使用情景：

在介紹使用情景之前，先看下我的開發和真機的Android版本。

我們這裡以讀取簡訊息為例講解整個許可權的使用：

1、沒有訪問許可權的情況下：

首先我們先來設計下佈局，如下：

看下程式碼，很簡單，就直接讀取短息：

然後，點選介面上的“讀取收件箱中的簡訊”，相信大家都會知道發生什麼情況，果然不出意外的程式直接崩潰了，打下日誌：

日誌中很清晰的告訴我們，這個異常是因為沒有許可權而造成的，那麼我們就直接給它加上讀取簡訊的許可權來看看吧。

2、在manifest中新增了許可權：

在manifest中加了對讀取簡訊的許可權，你應該很高興的等待著總共有多少條簡訊出現在我們的介面上，但是，事實很讓人崩潰：

再次出現了沒有許可權的異常，這是為什麼呢？

這裡我們先不解決這個問題，先來想象一種實際的情況，假如你現有的APP裡面有很多使用到了危險許可權，有時候你並完全清楚到底在哪裡使用了，但是你的目標版本又是像我的版本一樣指向了6.0，而有可能使用者的手機是6.0以上的版本，那麼這時候你的APP就有可能會出現這種，那麼在你還沒查清楚有哪些地方使用了危險許可權是，該怎麼解決呢？

那麼你可以這麼解決：

修改你build.gradle 中的 targetSdkVersion 目標版本號：

然後手機版本還是6.0以上，來看看結果：

可以了，哈哈，你很高興，確實是可以了。

那麼聰明的你或許意識到什麼了，是的，以版本23，也就是android6.0位分割線，我們可以得出一個小結論：

當targetSdkVersion >= 23，且真機版本 >= 23時，即使在manifest中新增了相應的危險許可權，在沒有做相應的處理時（至於怎麼處理後面會講），還時會出現限權的異常，這時manifest中的危險許可權並沒有起作用，但是還必須宣告。

當targetSdkVersion < 23，且真機版本 >= 23時，我們並沒有做任何的相關處理，就得到了想要的訪問許可權，這說明在manifest中申請的危險許可權起作用了。

我們在來看另外一種情況，就是，假如我的手機比較舊，還沒更新6.0的系統，這種情況下又該是什麼情況呢？

這次我們用個4.4.4版本的模擬機

目標targetSdkVersion 為21 來看看結果：

也是可以的，0條資訊是因為我的模擬機上沒簡訊，這個數字多少和我們沒有關係。假如targetSdkVersion 為23呢，來看看結果：

很清晰的看出，我們又得到了正確的結果。

由此我們也得到了一個小結論：

當我們的真機系統版本 < 23時，不管我們的targetSdkVersion 值是否大於23，都不會影響我們在manifest裡面申請的許可權，也就是說這時候真機的系統版本在起著主導作用。

由上面的幾條結論，我們應該很清晰的知道了訪問許可權在真機中的使用狀況，但是我們的手機在升級，版本也會越來越高，因此我們現在的應用不可能一直只支援低版本的使用也不考慮兼顧高版本。所以現在APP許可權升級是必然的趨勢。

那麼現在回來解決上面遺留的問題，當真機和目標版本都大於6.0時出現的許可權異常我們該怎麼解決呢？

主要分為三個步驟：

1：檢查是否擁有許可權

2：假如沒有許可權，則申請許可權

3：處理許可權回撥

下面我們分別來看看這幾個步驟。

1：檢查是否擁有許可權

檢查是否已擁有了許可權，可以使用ContextCompat.checkSelfPermission(Context context, String permission);

checkSelfPermission方法中有兩個引數，分別是上下文，以及所申請的許可權。

如果有許可權，請讓它直接去讀取簡訊資訊。如果沒有許可權則去申請。

2：申請許可權

申請許可權則是使用：

public static void requestPermissions(final Activity activity,final String[] permissions, final int requestCode) {}

requestPermissions方法中需要三個引數，當前的activity，所申請的許可權，可以是多個，最後就是請求碼，既然有請求碼說明它會有一個回撥，也就是我們下面要講的處理回撥。

3：處理許可權回撥

處理許可權回撥，需要在Activity中重寫onRequestPermissionsResult方法：

然後在方法內判斷使用者是授權了該許可權組還是拒絕授權，如果授權則就去獲取簡訊資訊，否則，在這裡我只是顯示了一個toast提示框。

這裡再次說明下，許可權組內只要有一個被授權，其他的許可權也就有了許可權，這也是為什麼直接使用grantResults[0] == PackageManager.PERMISSION_GRANTED的原因。

ok,下面來具體的介面顯示：

我們可以看到，當我們第一次點選讀取簡訊時，它會先檢查該應用是否有許可權，如果沒有，就去申請，這裡在介面上對應的就是顯示一個授權的對話方塊，第一次我們選擇了拒絕授權，然後在回撥裡面就會對應先列印了我們的一個toast消失提醒我們拒絕了授權，但是當我們再次需要讀取簡訊時，它還會去申請授權，這時我們允許授權，然後我們就看到了，在顯示簡訊條數的TextView顯示了簡訊的條數。（這裡0條是因為的用的模擬器沒有簡訊，這不是重點。）

值得提醒的事，當我們第一次選擇拒絕授權時，當再次點選讀取簡訊時，這時在授權對話方塊中會多一個“不再提醒”的提示，當我們在拒絕了授權，並選擇不再提醒時，那麼會出現什麼情況呢？請看演示：

當多次拒絕並選擇不提提醒，那麼下次再去讀取就不會在去申請授權，而是直接在回撥中說明使用者已拒絕授權。

那麼這時候假如使用者出於某種需要必須得給應用授權該怎麼做呢，其實很簡單，在回撥中，提醒使用者去“設定”裡面手動給應用授權，或是發個廣播開啟設定介面等等都可，這裡和我顯示的提醒“許可權已被拒絕”基本一樣，只需在稍微優化即可，這裡不在演示。

其實到這裡已經差不多講完，但是，有一個方法我們可以留一下，那就是shouldShowRequestPermissionRationale，這個方法預設返回false，但當使用者在上一次已經拒絕過這個許可權申請時，再次需要申請該許可權時，就會返回ture，它的寓意是你已經拒絕了一次，結果又彈出個授權框，你需要給我一個解釋，為什麼要授權，也就是說對多次授權這個許可權做出解釋，以便使用者知道為什麼必須授權了才能夠完成他操作。

下面，來看看它的使用：

我這裡就簡單的彈出個對話方塊，說明下為什麼要用這個許可權，然後再次去呼叫這個申請的許可權的方法了，大家可以同回撥的方法一起封裝下，可以更好的應用。

看下介面操作：

講到這裡基本差不地講完了，這裡只是講了單個申請許可權，多個一起也是可以的，大家可以自己試試，基本是一樣的操作，另外在說明一點，可能我們一個應用裡，需要多出的使用到危險許可權，這樣就造成我們需要多次重寫一樣的程式碼，很不便利，所以網上也就出現了很多關於許可權框架的開原始碼，大家可以自行的使用。