Runtime Permission.

http://blog.csdn.net/lmj623565791/article/details/50709663；
本文出自:【張鴻洋的博客】

 

1、概述

隨着Android 6.0發佈以及普及，咱們開發者所要應對的主要就是新版本SDK帶來的一些變化，首先關注的就是權限機制的變化。對於6.0的幾個主要的變化，查看查看官網的這篇文章http://developer.android.com/intl/zh-cn/about/versions/marshmallow/android-6.0-changes.html，其中固然包含Runtime Permissions。

ok，本篇文章目的之一就是對運行時權限處理的一個介紹，以及對目前權限相關的庫的一些瞭解。

固然很是推薦閱讀官網權限相關文章：

• Working with System Permissions
• Permissions Best Practices

本文也是在上述文章基礎上理解、實驗以及封裝。

2、運行時權限的變化及特色

對於6.0如下的權限及在安裝的時候，根據權限聲明產生一個權限列表，用戶只有在贊成以後才能完成app的安裝，形成了咱們想要使用某個app，就要默默忍受其一些沒必要要的權限（好比是個app都要訪問通信錄、短信等）。而在6.0之後，咱們能夠直接安裝，當app須要咱們授予不恰當的權限的時候，咱們能夠予以拒絕（好比：單機的象棋對戰，請求訪問任何權限，我都是不一樣意的）。固然你也能夠在設置界面對每一個app的權限進行查看，以及對單個權限進行受權或者解除受權。

新的權限機制更好的保護了用戶的隱私，Google將權限分爲兩類，一類是Normal Permissions，這類權限通常不涉及用戶隱私，是不須要用戶進行受權的，好比手機震動、訪問網絡等；另外一類是Dangerous Permission，通常是涉及到用戶隱私的，須要用戶進行受權，好比讀取sdcard、訪問通信錄等。

 

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_INSTALL_PACKAGES SET_ALARM SET_TIME_ZONE SET_WALLPAPER SET_WALLPAPER_HINTS TRANSMIT_IR UNINSTALL_SHORTCUT USE_FINGERPRINT VIBRATE WAKE_LOCK WRITE_SYNC_SETTINGS

• Dangerous Permissions:

group:android.permission-group.CONTACTS permission:android.permission.WRITE_CONTACTS permission:android.permission.GET_ACCOUNTS permission:android.permission.READ_CONTACTS group:android.permission-group.PHONE permission:android.permission.READ_CALL_LOG permission:android.permission.READ_PHONE_STATE permission:android.permission.CALL_PHONE permission:android.permission.WRITE_CALL_LOG permission:android.permission.USE_SIP permission:android.permission.PROCESS_OUTGOING_CALLS permission:com.android.voicemail.permission.ADD_VOICEMAIL group:android.permission-group.CALENDAR permission:android.permission.READ_CALENDAR permission:android.permission.WRITE_CALENDAR group:android.permission-group.CAMERA permission:android.permission.CAMERA group:android.permission-group.SENSORS permission:android.permission.BODY_SENSORS group:android.permission-group.LOCATION permission:android.permission.ACCESS_FINE_LOCATION permission:android.permission.ACCESS_COARSE_LOCATION group:android.permission-group.STORAGE permission:android.permission.READ_EXTERNAL_STORAGE permission:android.permission.WRITE_EXTERNAL_STORAGE group:android.permission-group.MICROPHONE permission:android.permission.RECORD_AUDIO group:android.permission-group.SMS permission:android.permission.READ_SMS permission:android.permission.RECEIVE_WAP_PUSH permission:android.permission.RECEIVE_MMS permission:android.permission.RECEIVE_SMS permission:android.permission.SEND_SMS
permission:android.permission.READ_CELL_BROADCASTS 

 

能夠經過adb shell pm list permissions -d -g進行查看。

看到上面的dangerous permissions，會發現一個問題，好像危險權限都是一組一組的，恩，沒錯，的確是這樣的，

那麼有個問題：分組對咱們的權限機制有什麼影響嗎？

的確是有影響的，若是app運行在android 6.x的機器上，對於受權機制是這樣的。若是你申請某個危險的權限，假設你的app早已被用戶受權了同一組的某個危險權限，那麼系統會當即受權，而不須要用戶去點擊受權。好比你的app對READ_CONTACTS已經受權了，當你的app申請WRITE_CONTACTS時，系統會直接受權經過。此外，對於申請時彈出的dialog上面的文本說明也是對整個權限組的說明，而不是單個權限（ps:這個dialog是不能進行定製的）。

不過須要注意的是，不要對權限組過多的依賴，儘量對每一個危險權限都進行正常流程的申請，由於在後期的版本中這個權限組可能會產生變化。