編輯:關於android開發
android的權限系統一直是首要的安全概念,因為這些權限只在安裝的時候被詢問一次。一旦安裝了,app可以在用戶毫不知曉的情況下訪問權限內的所有東西,而且一般用戶安裝的時候很少會去仔細看權限列表,更不會去深入了解這些權限可能帶來的相關危害。但是在android 6.0 Marshmallow版本之後,系統不會在軟件安裝的時候就賦予該app所有其申請的權限,對於一些危險級別的權限,app需要在運行時一個一個詢問用戶授予權限。
那麼問題來了,是不是所有以前發布的app都會出現問題呢?答案是不會,只有那些targetSdkVersion 設置為23及以上的應用才會出現異常,在使用危險權限的時候系統必須要獲得用戶的同意才能使用,要不然應用就會崩潰,出現類似下面的錯誤。
java.lang.SecurityException: Permission Denial...
所以targetSdkVersion如果沒有設置為23版本或者以上,系統還是會使用舊規則:在安裝的時候賦予該app所申請的所有權限。所以app當然可以和以前一樣正常使用了,但是還有一點需要注意的是6.0的系統裡面,用戶可以手動將該app的權限關閉,在 App info裡面Permissions下邊,可以關閉某個權限。如果以前的老應用申請的權限被用戶手動關閉了,不會拋出異常,不會崩潰,只不過調用那些被用戶禁止權限的api接口返回值都為null或者0,所以我們只需要做一下判空操作就可以了,這是需要注意的。
現在對於新版本的權限變更應該有了基本的認識,那麼,是不是所有權限都需要去進行特殊處理呢?當然不是,只有那些危險級別的權限才需要,可參考官網。
http://developer.android.com/training/permissions/requesting.html
http://developer.android.com/guide/topics/security/permissions.html#normal-dangerous
所以仔細去看看自己的app,對照列表,如果有需要申請其中的一個權限,就需要進行特殊操作。還有一個比較人性的地方就是如果同一組的任何一個權限被授權了,其他權限也自動被授權。例如,一旦WRITE_EXTERNAL_STORAGE被授權了,app也有READ_EXTERNAL_STORAGE權限了。
在Android M的api中,我們可以通過checkSelfPermission檢測軟件是否有某一項權限,以及使用requestPermissions去請求一組權限。
int hasWriteContactsPermission = checkSelfPermission(Manifest.permission.WRITE_EXTERNAL_STORAGE); if (hasWriteContactsPermission != PackageManager.PERMISSION_GRANTED) { requestPermissions(new String[] {Manifest.permission.WRITE_EXTERNAL_STORAGE}, CODE_FOR_WRITE_PERMISSION); return; }
以上的代碼塊展示了檢測軟件是否有寫文件的權限,如果沒有寫文件的權限,則通過requestPermissions去向用戶發起請求權限的流程。向用戶發起請求之後,請求完成,會有相對應的回調方法,通知軟件用戶是否授予了權限。通過在Activity或者Fragment中重寫onRequestPermissionsResult方法。
@Override public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) { if (requestCode == CODE_FOR_WRITE_PERMISSION){ if (permissions[0].equals(Manifest.permission.WRITE_EXTERNAL_STORAGE) && grantResults[0] == PackageManager.PERMISSION_GRANTED){ // 用戶同意寫文件 } else { // 用戶不同意,自行處理即可 } } }
如果用戶一旦拒絕過某權限的授權。下一次彈框時,用戶會有一個“不再提醒(Never ask again)”的選項的來防止app以後繼續請求授權。
如果這個選項在拒絕授權前被用戶勾選了。下次為這個權限請求requestPermissions時,對話框就不彈出來了,系統會直接回調onRequestPermissionsResult函數,回調結果為最後一次用戶的選擇。所以為了應對這種情況,系統提供了一個shouldShowRequestPermissionRationale()函數,這個函數的作用是幫助開發者找到需要向用戶額外解釋權限的情況。
注意:第二次請求權限時,才會有“不再提醒”的選項,如果用戶一直拒絕,並沒有選擇“不再提醒”的選項,下次請求權限時,會繼續有“不再提醒”的選項,並且shouldShowRequestPermissionRationale()也會一直返回true。
所以利用這個函數我們可以進行相應的優化,針對shouldShowRequestPermissionRationale函數返回false的處理有兩種方法:
處理方法已經有了,修改一下代碼,這裡以第二種方案來處理:
@Override public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) { if (requestCode == CODE_FOR_WRITE_PERMISSION){ if (permissions[0].equals(Manifest.permission.WRITE_EXTERNAL_STORAGE) &&grantResults[0] == PackageManager.PERMISSION_GRANTED){ // 用戶同意 } else { // 用戶不同意,向用戶展示該權限作用 if (!shouldShowRequestPermissionRationale(this, Manifest.permission.WRITE_EXTERNAL_STORAGE)) { showPermissionDialog();return; } } } }
當勾選不再提醒,並且拒絕之後,彈出dialog,提醒用戶該權限的重要性
以上的代碼在6.0版本上使用沒有問題,但是在之前就有問題了,最簡單粗暴的解決方法可能就是利用Build.VERSION.SDK_INT >= 23這個判斷語句來判斷了,方便的是SDK 23的v4包加入了專門類進行相關的處理:
// 使用兼容庫就無需判斷系統版本 int hasWriteContactsPermission = ContextCompat.checkSelfPermission(getApplication(), Manifest.permission.WRITE_EXTERNAL_STORAGE); if (hasWriteContactsPermission == PackageManager.PERMISSION_GRANTED) { } // 需要彈出dialog讓用戶手動賦予權限 else { ActivityCompat.requestPermissions(Acivity.this, new String[]{Manifest.permission.WRITE_EXTERNAL_STORAGE}, CODE_FOR_WRITE_PERMISSION); }
onRequestPermissionsResult函數不變。後兩個方法,我們也可以在Fragment中使用,用v13兼容包:FragmentCompat.requestPermissions() 和 FragmentCompat.shouldShowRequestPermissionRationale()和activity效果一樣。
當然了有時候需要多個權限,可以用上面方法一次請求多個權限。當然最重要的是不要忘了為每個權限檢查“不再提醒”的設置。
List<String> permissionsNeeded = new ArrayList<String>(); permissionsNeeded.add(Manifest.permission.ACCESS_FINE_LOCATION); permissionsNeeded.add(Manifest.permission.READ_CONTACTS); permissionsNeeded.add(Manifest.permission.WRITE_CONTACTS); requestPermissions(permissionsNeeded.toArray(new String[permissionsList.size()]), CODE_FOR_MULTIPLE_PERMISSION);
最後在onRequestPermissionsResult函數中一個個處理返回結果即可。
當然早就有第三方庫來幫忙做這些事情了:
Github上的開源項目 PermissionHelper,PermissionsDispatcher,EasyPermissions。
如果APP正在運行中,用戶進入設置-應用程序頁面去手動撤銷該APP權限,會出現什麼情況呢?系統又會接著彈出權限請求對話框。
新運行時權限已經在棉花糖中被使用了。我們沒有退路。我們現在唯一能做的就是保證app適配新權限模型。欣慰的是只有少數權限需要運行時權限模型。大多數常用的權限,例如,網絡訪問,屬於Normal Permission 在安裝時自動會授權,當然你要聲明,以後無需檢查。因此,只有少部分代碼你需要修改。
兩個建議:
1.嚴肅對待新權限模型。
2.如果你代碼沒支持新權限,不要設置targetSdkVersion 23 。尤其是當你在Studio新建工程時,不要忘了修改!
說一下代碼修改。這是大事,如果代碼結構被設計的不夠好,你需要一些很蛋疼的重構。每個app都要被修正。如上所說,我們沒的選擇。列出所有你需要請求權限的全部情形,如果A被授權,B被拒絕,會發生什麼,針對每一個情況認真處理。
Android Demo手機獲取驗證碼 注冊很多app或者網絡賬戶的時候,經常需要手機獲取驗證碼,來完成注冊,那時年少,只是覺得手機獲取驗證碼這件事兒很好玩,並沒有關心太
Android技巧1:啟動屏+新功能左右導航 前言 很長一段時間沒寫博客了,再不寫點東西真說不過去,把工作上的一些有價值的東西整理出來分享,在當下還有點時效性,不然遲早會
Android編程: 界面組成、事件監聽器,android監聽器學習知識:界面組成、事件監聽器 ====界面組成==== 1.用戶界面的基本組件叫做View,都是繼承an
android不同的按鈕一起點擊崩潰解決,android一起public class ButtonUtils { private static long last