聊一聊Android 6.0的運行時權限
Android 6.0,代號棉花糖,自發布伊始,其主要的特征運行時權限就很受關注。因為這一特征不僅改善了用戶對于應用的使用體驗,還使得應用開發者在實踐開發中需要做出改變。
沒有深入了解運行時權限的開發者通常會有很多疑問,比如什么是運行時權限,哪些是運行時的權限,我的應用是不是會在6.0系統上各種崩潰呢,如何才能支持運行時權限機制呢。本文講嘗試回答這一些問題,希望讀者閱讀完成之后,都能找到較為完美的答案。
權限一刀切
在6.0以前的系統,都是權限一刀切的處理方式, 只要用戶安裝,Manifest申請的權限都會被賦予,并且安裝后權限也撤銷不了 。
這種情況下,當我們從Google Play安裝一個應用,在安裝之前會得到這樣的權限提示信息。
當上述對話框彈出后,用戶只有兩種選擇:
- 我信任你,即使有敏感權限
- 你一個**應用,要這個權限干嘛,我還是不安裝了。
所以,這種一刀切的處理方式還是有弊端的,我們沒有辦法只允許某些權限或者拒絕某些權限。
棉花糖運行時權限
從棉花糖開始,Android系統引入了新的權限機制,即本文要講的運行時權限。
何為運行時權限呢?舉個栗子,以某個需要拍照的應用為例,當運行時權限生效時,其Camera權限不是在安裝后賦予,而是在應用運行的時候進行請求權限(比如當用戶按下”相機拍照“按鈕后)看到的效果則是這樣的
接下來,對于Camera權限的處理完全權交給用戶。是不是有點像蘋果系統的處理呢,不要說這是抄襲,暫且稱為師夷長技以制夷。
權限的分組
Android中有很多權限,但并非所有的權限都是敏感權限,于是6.0系統就對權限進行了分類,一般為下述幾類
- 正常(Normal Protection)權限
- 危險(Dangerous)權限
- 特殊(Particular)權限
- 其他權限(一般很少用到)
正常權限
正常權限具有如下的幾個特點
- 對用戶隱私沒有較大影響或者不會打來安全問題。
- 安裝后就賦予這些權限, 不需要顯示提醒用戶,用戶也不能取消這些權限 。
正常權限列表
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 INTERNET KILL_BACKGROUND_PROCESSES MODIFY_AUDIO_SETTINGS NFC READ_SYNC_SETTINGS READ_SYNC_STATS RECEIVE_BOOT_COMPLETED REORDER_TASKS REQUEST_INSTALL_PACKAGES SET_TIME_ZONE SET_WALLPAPER SET_WALLPAPER_HINTS TRANSMIT_IR USE_FINGERPRINT VIBRATE WAKE_LOCK WRITE_SYNC_SETTINGS SET_ALARM INSTALL_SHORTCUT UNINSTALL_SHORTCUT
</div>
上述的權限基本設計的是關于網絡,藍牙,時區,快捷方式等方面,只要在Manifest指定了這些權限,就會被授予,并且不能撤銷。
特殊權限
這里講特殊權限提前講一下,因為這個相對來說簡單一些。
特殊權限,顧名思義,就是一些特別敏感的權限,在Android系統中,主要由兩個
- SYSTEM_ALERT_WINDOW,設置懸浮窗,進行一些黑科技
- WRITE_SETTINGS 修改系統設置
關于上面兩個特殊權限的授權,做法是使用 startActivityForResult 啟動授權界面來完成。
請求SYSTEM_ALERT_WINDOW
private static final int REQUEST_CODE = 1; private void requestAlertWindowPermission() { Intent intent = new Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION); intent.setData(Uri.parse("package:" + getPackageName())); startActivityForResult(intent, REQUEST_CODE); } @Override protected void onActivityResult(int requestCode, int resultCode, Intent data) { super.onActivityResult(requestCode, resultCode, data); if (requestCode == REQUEST_CODE) { if (Settings.canDrawOverlays(this)) { Log.i(LOGTAG, "onActivityResult granted"); } } }
</div>
上述代碼需要注意的是
- 使用Action Settings.ACTION_MANAGE_OVERLAY_PERMISSION 啟動隱式Intent
- 使用 "package:" + getPackageName() 攜帶App的包名信息
- 使用 Settings.canDrawOverlays 方法判斷授權結果
請求WRITE_SETTINGS
private static final int REQUEST_CODE_WRITE_SETTINGS = 2; private void requestWriteSettings() { Intent intent = new Intent(Settings.ACTION_MANAGE_WRITE_SETTINGS); intent.setData(Uri.parse("package:" + getPackageName())); startActivityForResult(intent, REQUEST_CODE_WRITE_SETTINGS ); } @Override protected void onActivityResult(int requestCode, int resultCode, Intent data) { super.onActivityResult(requestCode, resultCode, data); if (requestCode == REQUEST_CODE_WRITE_SETTINGS) { if (Settings.System.canWrite(this)) { Log.i(LOGTAG, "onActivityResult write settings granted" ); } } }
</div>
上述代碼需要注意的是
- 使用Action Settings.ACTION_MANAGE_WRITE_SETTINGS 啟動隱式Intent
- 使用 "package:" + getPackageName() 攜帶App的包名信息
- 使用 Settings.System.canWrite 方法檢測授權結果
注意:關于這兩個特殊權限,一般不建議應用申請。
危險權限
危險權限實際上才是運行時權限主要處理的對象,這些權限可能引起隱私問題或者影響其他程序運行。Android中的危險權限可以歸為以下幾個分組:
- CALENDAR
- CAMERA
- CONTACTS
- LOCATION
- MICROPHONE
- PHONE
- SENSORS
- SMS
- STORAGE
各個權限分組與其具體的權限,可以參考下圖:
必須要支持運行時權限么
目前應用實際上是可以不需要支持運行時權限的,但是最終肯定還是需要支持的,只是時間問題而已。
想要不支持運行時權限機制很簡單,只需要將 targetSdkVersion 設置低于23就可以了,意思是告訴系統,我還沒有完全在API 23(6.0)上完全搞定,不要給我啟動新的特性。
不支持運行時權限會崩潰么
可能會,但不是那種一上來就噼里啪啦崩潰不斷的那種。
如果你的應用將 targetSdkVersion 設置低于23,那么在6.0的系統上不會為這個應用開啟運行時權限機制,即按照以前的一刀切方式處理。
然而有點糟糕的是
6.0系統提供了一個應用權限管理界面,界面長得是這樣的
既然是可以管理,用戶就能取消權限,當一個不支持運行時權限的應用某項權限被取消時
系統會彈出一個對話框提醒撤銷的危害,如果用戶執意撤銷,會帶來如下的反應
- 如果你的程序正在運行,則會被殺掉。
- 當你的應用再次運行時,可能出現崩潰
為什么會可能崩潰的,比如下面這段代碼
TelephonyManager telephonyManager = (TelephonyManager)getSystemService(Context.TELEPHONY_SERVICE); String deviceId = telephonyManager.getDeviceId(); if (deviceId.equals(mLastDeviceId)) {//This may cause NPE //do something }
</div>
如果用戶撤消了獲取DeviceId的權限,那么再次運行時,deviceId就是null,如果程序后續處理不當,就會出現崩潰。
該來的還得來
6.0的運行時權限,我們最終都是要支持的,通常我們需要使用如下的API
- int checkSelfPermission(String permission) 用來檢測應用是否已經具有權限
- void requestPermissions(String[] permissions, int requestCode) 進行請求單個或多個權限
- void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) 用戶對請求作出響應后的回調
以一個請求Camera權限為例
@Override public void onClick(View v) { if (!(checkSelfPermission(Manifest.permission.CAMERA) == PackageManager.PERMISSION_GRANTED)) { requestCameraPermission(); } } private static final int REQUEST_PERMISSION_CAMERA_CODE = 1; private void requestCameraPermission() { requestPermissions(new String[]{Manifest.permission.CAMERA}, REQUEST_PERMISSION_CAMERA_CODE); } @Override public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) { super.onRequestPermissionsResult(requestCode, permissions, grantResults); if (requestCode == REQUEST_PERMISSION_CAMERA_CODE) { int grantResult = grantResults[0]; boolean granted = grantResult == PackageManager.PERMISSION_GRANTED; Log.i(LOGTAG, "onRequestPermissionsResult granted=" + granted); } }
</div>
通常情況下,我們會得到這樣的一個對話框
當用戶選擇允許,我們就可以在onRequestPermissionsResult方法中進行響應的處理,比如打開攝像頭
當用戶拒絕,你的應用可能就開始危險了
當我們再次嘗試申請權限時,彈出的對話框和之前有點不一樣了,主要表現為多了一個checkbox。如下圖
當用戶勾選了”不再詢問“拒絕后,你的程序基本這個權限就Game Over了。
不過,你還有一絲希望,那就是再出現上述的對話框之前做一些說明信息,比如你使用這個權限的目的(一定要坦白)。
shouldShowRequestPermissionRationale這個API可以幫我們判斷接下來的對話框是否包含”不再詢問“選擇框。
一個標準的流程
if (!(checkSelfPermission(Manifest.permission.READ_CONTACTS) == PackageManager.PERMISSION_GRANTED)) { if (shouldShowRequestPermissionRationale(Manifest.permission.READ_CONTACTS)) { Toast.makeText(this, "Please grant the permission this time", Toast.LENGTH_LONG).show(); } requestReadContactsPermission(); } else { Log.i(LOGTAG, "onClick granted"); }
</div>
如何批量申請
批量申請權限很簡單,只需要字符串數組放置多個權限即可。如請求代碼
private static final int REQUEST_CODE = 1; private void requestMultiplePermissions() { String[] permissions = {Manifest.permission.WRITE_EXTERNAL_STORAGE, Manifest.permission.READ_PHONE_STATE}; requestPermissions(permissions, REQUEST_CODE); }
</div>
對應的界面效果是
注意:間隔較短的多個權限申請建議設置成單次多個權限申請形式,避免彈出多個對話框,造成不太好的視覺效果。
申請這么多權限豈不是很累
其實你不需要每個權限都去顯式申請,舉一個例子,如果你的應用授權了讀取聯系人的權限,那么你的應用也是被賦予了寫入聯系人的權限。因為讀取聯系人和寫入聯系人這兩個權限都屬于聯系人權限分組,所以一旦組內某個權限被允許,該組的其他權限也是被允許的。
注意事項
API問題
由于checkSelfPermission和requestPermissions從API 23才加入,低于23版本,需要在運行時判斷 或者使用Support Library v4中提供的方法
- ContextCompat.checkSelfPermission
- ActivityCompat.requestPermissions
- ActivityCompat.shouldShowRequestPermissionRationale
多系統問題
當我們支持了6.0必須也要支持4.4,5.0這些系統,所以需要在很多情況下,需要有兩套處理。比如Camera權限
if (isMarshmallow()) { requestPermission();//然后在回調中處理 } else { useCamera();//低于6.0直接使用Camera }
</div>
兩個權限
運行時權限對于應用影響比較大的權限有兩個,他們分別是
- READ_PHONE_STATE
- WRITE_EXTERNAL_STORAGE/READ_EXTERNAL_STORAGE
其中READ_PHONE_STATE用來獲取deviceID,即IMEI號碼。這是很多統計依賴計算設備唯一ID的參考。如果新的權限導致讀取不到,避免導致統計的異常。建議在完全支持運行時權限之前,將對應的值寫入到App本地數據中,對于新安裝的,可以采取其他策略減少對統計的影響。
WRITE_EXTERNAL_STORAGE/READ_EXTERNAL_STORAGE這兩個權限和外置存儲(即sdcard)有關,對于下載相關的應用這一點還是比較重要的,我們應該盡可能的說明和引導用戶授予該權限。
些許建議
- 不要使用多余的權限,新增權限時要慎重
- 使用Intent來替代某些權限,如撥打電話(和你的產品經理PK去吧)
- 對于使用權限獲取的某些值,比如deviceId,盡量本地存儲,下次訪問直接使用本地的數據值
- 注意,由于用戶可以撤銷某些權限,所以不要使用應用本地的標志位來記錄是否獲取到某權限。
注意
即使支持了運行時權限,也要在Manifest聲明,因為市場應用會根據這個信息和硬件設備進行匹配,決定你的應用是否在該設備上顯示。
是否支持運行時權限
個人覺得Marshmallow的運行時權限對于用戶來說絕對是一個好東西,但是目前想要支持需要做的事情還是比較多的。
對于一個有很多依賴的宿主應用,想要做到支持還是有一些工作量的,因為你的權限申請受制于依賴。
建議在短期內暫時可以不考慮支持該運行時權限機制,等時機成熟或者簡單易用的第三方庫完善之后再支持也未嘗不可。
來自: http://droidyue.com/blog/2016/01/17/understanding-marshmallow-runtime-permission/