android60許可權
『壹』 android 自定義的launcher在6.0後需要動態申請許可權
6.0許可權的基本知識，以下是需要單獨申請的許可權，共分為9組，每組只要有一個許可權申請成功了，就默認整組許可權都可以使用了。
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
以下是普通許可權，只需要在AndroidManifest.xml中申請即可。
android.permission.ACCESS_LOCATION_EXTRA_COMMANDS
android.permission.ACCESS_NETWORK_STATE
android.permission.ACCESS_NOTIFICATION_POLICY
android.permission.ACCESS_WIFI_STATE
android.permission.ACCESS_WIMAX_STATE
android.permission.BLUETOOTH
android.permission.BLUETOOTH_ADMIN
android.permission.BROADCAST_STICKY
android.permission.CHANGE_NETWORK_STATE
android.permission.CHANGE_WIFI_MULTICAST_STATE
android.permission.CHANGE_WIFI_STATE
android.permission.CHANGE_WIMAX_STATE
android.permission.DISABLE_KEYGUARD
android.permission.EXPAND_STATUS_BAR
android.permission.FLASHLIGHT
android.permission.GET_ACCOUNTS
android.permission.GET_PACKAGE_SIZE
android.permission.INTERNET
android.permission.KILL_BACKGROUND_PROCESSES
android.permission.MODIFY_AUDIO_SETTINGS
android.permission.NFC
android.permission.READ_SYNC_SETTINGS
android.permission.READ_SYNC_STATS
android.permission.RECEIVE_BOOT_COMPLETED
android.permission.REORDER_TASKS
android.permission.REQUEST_INSTALL_PACKAGES
android.permission.SET_TIME_ZONE
android.permission.SET_WALLPAPER
android.permission.SET_WALLPAPER_HINTS
android.permission.SUBSCRIBED_FEEDS_READ
android.permission.TRANSMIT_IR
android.permission.USE_FINGERPRINT
android.permission.VIBRATE
android.permission.WAKE_LOCK
android.permission.WRITE_SYNC_SETTINGS
com.android.alarm.permission.SET_ALARM
com.android.launcher.permission.INSTALL_SHORTCUT
com.android.launcher.permission.UNINSTALL_SHORTCUT
『貳』 Android6.0動態許可權申請步驟以及需要注意的一些坑
我的博客
我的博客：Android6.0動態許可權申請步驟以及需要注意的一些坑
因為工作需要，簡單研究了一下Android6.0許可權申請，在Google提供的sample的基礎上，寫了一個簡單的demo。算是自己的筆記吧，可能會比較混亂，主要是方便以後查看。後期有別的問題，隨時更新~
（1）checkSelfPermission：檢查是否擁有這個許可權
（2）requestPermissions：請求許可權，一般會彈出一個系統對話框，詢問用戶是否開啟這個許可權。
（3）：在允許詢問時返回true ； 在許可權通過 或者許可權被拒絕並且禁止詢問時返回false ，如果從來沒有詢問過，也是返回的false， 所以單純的使用去做什麼判斷，是沒用的。。。 所以說這個地方有坑，我的解決方法是，在回調裡面處理，如果用戶拒絕了這個許可權，則打開本應用信息界面，由用戶自己手動開啟這個許可權。
（4）每個應用都有自己的許可權管理界面，裡面有本應用申請的許可權以及各種狀態，即使用戶已經同意了你申請的許可權，他也隨時可以關閉
其實和申請一個許可權是一樣的，只是requestPermissions(final @NonNull Activity activity,
final @NonNull String[] permissions, final int requestCode),裡面的permissions給的參數多些而已。
『叄』 Android 的許可權管理是怎麼實現的
根據用戶的使用過程體驗，可以將 Android 涉及的許可權大致分為如下三類：
（1）Android 手機所有者許可權：自用戶購買 Android 手機後，用戶不需要輸入任何密碼，就具有安裝一般應用軟體、使用應用程序等的許可權；
（2）Android root 許可權：該許可權為 Android 系統的最高許可權，可以對所有系統中文件、數據進行任意操作。出廠時默認沒有該許可權，需要使用 z4Root 等軟體進行獲取，然而，並不鼓勵進行此操作，因為可能由此使用戶失去手機原廠保修的權益。同樣，如果將 Android 手機進行 root 許可權提升，則此後用戶不需要輸入任何密碼，都將能以 Android root 許可權來使用手機。
（3）Android 應用程序許可權：Android 提供了豐富的 SDK（Software development kit），開發人員可以根據其開發 Android 中的應用程序。而應用程序對 Android 系統資源的訪問需要有相應的訪問許可權，這個許可權就稱為 Android 應用程序許可權，它在應用程序設計時設定，在 Android 系統中初次安裝時即生效。值得注意的是：如果應用程序設計的許可權大於 Android 手機所有者許可權，則該應用程序無法運行。如：沒有獲取 Android root 許可權的手機無法運行 Root Explorer，因為運行該應用程序需要 Android root 許可權。
Android 系統許可權定義
Android 系統在 /system/core/private/android_filesystem_config.h 頭文件中對 Android 用戶 / 用戶組作了如下定義，且許可權均基於該用戶 / 用戶組設置。
在 Android 系統中，上述用戶 / 用戶組對文件的訪問遵循 Linux 系統的訪問控制原則，即根據長度為 10 個字元的許可權控制符來決定用戶 / 用戶組對文件的訪問許可權。該控制符的格式遵循下列規則：
第 1 個字元：表示一種特殊的文件類型。其中字元可為 d( 表示該文件是一個目錄 )、b( 表示該文件是一個系統設備，使用塊輸入 / 輸出與外界交互，通常為一個磁碟 )、c( 表示該文件是一個系統設備，使用連續的字元輸入 / 輸出與外界交互，如串口和聲音設備 )，「.」表示該文件是一個普通文件，沒有特殊屬性。
2 ～ 4 個字元：用來確定文件的用戶 (user) 許可權；
5 ～ 7 個字元：用來確定文件的組 (group) 許可權；
8 ～ 10 個字元：用來確定文件的其它用戶 (other user，既不是文件所有者，也不是組成員的用戶 ) 的許可權。
第 2、5、8 個字元是用來控制文件的讀許可權的，該位字元為 r 表示允許用戶、組成員或其它人可從該文件中讀取數據。短線「-」則表示不允許該成員讀取數據。
第 3、6、9 位的字元控制文件的寫許可權，該位若為 w 表示允許寫，若為「-」表示不允許寫。
第 4、7、10 位的字元用來控制文件的製造許可權，該位若為 x 表示允許執行，若為「-」表示不允許執行。
舉個例子，「drwxrwxr--2 rootroot40962 月 11 10:36 lu」表示的訪問控制許可權（黑色字體標明）為：因為 lu 的第 1 個位置的字元是 d，所以由此知道 lu 是一個目錄。第 2 至 4 位置上的屬性是 rwx，表示用戶 root 擁有許可權列表顯示 lu 中所有的文件、創建新文件或者刪除 lu 中現有的文件，或者將 lu 作為當前工作目錄。第 5 至 7 個位置上的許可權是 rwx，表示 root 組的成員擁有和 root 一樣的許可權。第 8 至 10 位上的許可權僅是 r--，表示不是 root 的用戶及不屬於 root 組的成員只有對 lu 目錄列表的許可權。這些用戶不能創建或者刪除 lu 中的文件、執行 junk 中的可執行文件，或者將 junk 作為他們的當前工作目錄。
Android 應用程序許可權申請
每個應用程序的 APK 包裡面都包含有一個 AndroidMainifest.xml 文件，該文件除了羅列應用程序運行時庫、運行依賴關系等之外，還會詳細地羅列出該應用程序所需的系統訪問。程序員在進行應用軟體開發時，需要通過設置該文件的 uses-permission 欄位來顯式地向 Android 系統申請訪問許可權。
『肆』 android 6.0許可權dialog不再顯示後怎麼設置
android 6.0許可權dialog不再顯示後，設置方法如下：
打開手機設置頁面。
向上滑動屏幕，找到應用程序。
點擊應用程序，進入應用程序設置界面。
點擊屏幕右上角的齒輪狀設置按鈕，進入配置應用界面。
點擊上方的應用許可權，進入應用許可權具體設置界面。
以位置許可權為例，點擊上圖的位置許可權，就列出了所有需要位置許可權的應用。
『伍』 聊聊Android6.0 以上系統許可權
一個新建的Android應用默認是沒有許可權的，這意味著它不能執行任何可能對用戶體驗有不利影響的操作或者訪問設備數據。為了使用受保護的功能，你必須包含一個或者多個標簽在你的app manifest中。
1、Android 6.0中許可權分為兩種，普通許可權和危險許可權（即運行時許可權，下面統稱運行時許可權）。
1.1普通許可權
如果你的應用manifest中只申明了普通許可權（也就是說，這些許可權對於用戶隱私和設備操作不會造成太多危險），系統會自動授予這些許可權。
1.2運行時許可權
如果你的應用manifest中聲明了運行時許可權（也就是說，這些許可權可能會影響用戶隱私和設備的普通操作），系統會明確的讓用戶決定是否授予這些許可權。系統請求用戶授予這些許可權的方式是由當前應用運行的系統版本來決定的。
1.2.1 Android6.0及以上的系統
如果你的設備運行的是Android6.0（API level 23）及以上的系統，並且你的應用的targetSdkVersion也是23或者更高，那麼應用向用戶請求這些許可權是實時的。這意味著用戶可以隨時取消 這些運行時許可權的授權。所以應用在每次需要用到這些運行時許可權的時候都需要去檢查是否還有這些許可權的授權。
1.2.2 Android 5.1及以下的系統
如果你的設備運行在Android5.1（API level 22）及以下的系統中，或者你的app的targetSdkVersion是22或者更低。系統會請求用戶在apk安裝的時候授予這些許可權。
如果你的應用更新的時候添加了一個許可權，系統會在用戶更新應用的時候請求用戶授予這個許可權 ， 一旦用戶安裝了這個應用，唯一可以取消授權的方式就是卸載掉這個應用。 注意這句話的意思，想一下如果app的targetSdkVersion是22或者以下，但是運行在Android6.0及以上的設備中會有什麼問題？後面會分析這個問題 。
常常來說一個授權失敗會拋出SecurityException，然而這並不是在 所有情況下都會發生。比如，發送一個廣播去檢查授權(SendBroadcast(Intent))，數據會被發送給所有接收者，但是當這個方法的請求返 回的時候，你不會收到任何一個因為授權失敗拋出的異常，其實在大多數情況下，授權失敗只會列印系統日誌。
1.3自動許可權調整
簡單的說，如果你的app targetSdkVersion是3，而你當前運行的系統版本是4，那麼在android version 4 中新添加的許可權會自動添加到你的app中。
比如 WRITE_EXTERNAL_STORAGE許可權是在api 4的時候添加的，而你的應用的targetSdkVersion是3，那麼這個許可權會自動添加到你的應用中。而且在官方商店上這個許可權也會列出來（盡管可能你並不需要這個許可權）。
所以建議經常更新你的targetSdkVersion到最新版本。
下面來回答上面的那個問題，如果app的targetSdkVersion是22或者以下，但是運行在android 6.0或以上版本的手機中，會發生什麼？
安裝過程中，會一起請求用戶授予所有 許可權，如果用戶拒絕，將不能安裝這個app，只有用戶全部同意這些授權，才能安裝這個應用，但是問題來了，安裝好了這個應用之後，android6.0以 上的系統中，用戶是可以去設置中取消授權的，而且是隨時都可以取消，所以很多運行時許可權可能也得不到，目前官方的做法是，如果用戶取消該項授權，那麼依賴 該項授權的方法的返回值為null，所以你的app可能會報空指針異常。以後是否會針對22以下的app做改變還不得而知，畢竟crash是很難讓人接受 的，但是crash是由用戶造成的，用戶應該也可以理解。
2、普通許可權和運行時許可權
系統許可權會被傳遞給兩種不同的保護級別，我們所知道這兩種最重要的保護級別就是普通許可權和運行時許可權。
2.1 普通許可權
普通許可權的覆蓋區域是在你的app需要訪問沙盒以外的數據和資源的時候，但是對用戶隱私和其他app的操作只有很少的影響，比如開啟手電筒的許可權。這個時候，系統會自動授權這些普通許可權。
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
2.2 運行時許可權
運行時許可權的覆蓋區域是你的app想要的數據和資源涉及用戶的隱私信息，或者是可能潛在的影響用戶的存儲數據或者其他app的操作。比如，請求獲取用戶聯系人信息的許可權。如果一個app申明了運行時許可權，用戶必須明確的授權這些許可權給app。
2.3 許可權組
所有的運行時許可權都屬於對應的許可權組，如果你的app運行在android6.0及以上系統，下面的規則都適用：
2.3.1 如果一個app在manifest中請求了一個運行時許可權，而且app還沒有得到這個運行時許可權所在的許可權組中的任何一個運行時許可權授權，那麼系統會彈出一個對話框，描述app想要訪問的運行時許可權的許可權組，這個對話框不會描述這個許可權組中某一個特定的許可權。比如，你的app想要請求READ_CONTACT許可權，對話框只會描述app想要請求設備的聯系人，如果用戶授權通過，系統會授予app所請求的該項許可權。
2.3.2 如果一個app在manifest中請求一個運行時許可權，並且這個app已經在相同的許可權組中有了另一個運行時許可權的授權，那麼系統不會彈出對話框，而是會立即授予app該項運行時許可權的授權。比如，一個app之前請求過一個READ_CONTACT的許可權並且被授權通過，之後又請求一個WRITE_CONTACT（在同一個許可權組）許可權，那麼系統會自動授予該許可權。
其實所有許可權（普通許可權、運行時許可權、用戶自定義許可權）都屬於特定的許可權組，但是只有運行時許可權的許可權組才會影響用戶體驗。
2.3.3運行時許可權組和許可權組列表
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是不能進行定製的）。不過需要注意的是，不要對許可權組過多的依賴，盡可能對每個危險許可權都進行正常流程的申請，因為在後期的版本中這個許可權組可能會產生變化。
3、相關API
3.1 在AndroidManifest文件中添加需要的許可權。
這個步驟和我們之前的開發並沒有什麼變化，試圖去申請一個沒有聲明的許可權可能會導致程序崩潰。
3.2 檢查許可權
if (ContextCompat.checkSelfPermission(thisActivity,
Manifest.permission.READ_CONTACTS)
!= PackageManager.PERMISSION_GRANTED) {
}else{
//
}
這里涉及到一個API，ContextCompat.checkSelfPermission，主要用於檢測某個許可權是否已經被授予，方法返回值為PackageManager.PERMISSION_DENIED或者PackageManager.PERMISSION_GRANTED。當返回DENIED就需要進行申請授權了
3.3 申請授權
ActivityCompat.requestPermissions(thisActivity,
new String[]{Manifest.permission.READ_CONTACTS},
MY_PERMISSIONS_REQUEST_READ_CONTACTS);
該方法是非同步的，第一個參數是Context；第二個參數是需要申請的許可權的字元串數組；第三個參數為requestCode，主要用於回調的時候檢測。可以從方法名requestPermissions以及第二個參數看出，是支持一次性申請多個許可權的，系統會通過對話框 逐一 詢問用戶是否授權。
3.4 處理許可權申請回調
@Override
(intrequestCode,
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;
}
}
}
ok，對於許可權的申請結果，首先驗證requestCode定位到你的申請，然後驗證grantResults對應於申請的結果，這里的數組對應於申請時的第二個許可權字元串數組。如果你同時申請兩個許可權，那麼grantResults的length就為2，分別記錄你兩個許可權的申請結果。如果申請成功，就可以做你的事情了！
那麼將上述幾個步驟結合到一起就是：
// Here, thisActivity is the current activity
if (ContextCompat.checkSelfPermission(thisActivity,
Manifest.permission.READ_CONTACTS)
!= PackageManager.PERMISSION_GRANTED) {
// Should we show an explanation?
if (ActivityCompat.(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.
}
}
謝幕，至此有關於android6.0 以上許可權相關的內容已經詳細講完了！