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

自從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，它的寓意是你已經拒絕了一次，結果又彈出個授權框，你需要給我一個解釋，為什麼要授權，也就是說對多次授權這個許可權做出解釋，以便用戶知道為什麼必須授權了才能夠完成他操作。

下麵，來看看它的使用：