聊一聊Android 6.0的運行時權限

jopen 8年前發布 | 58K 次閱讀 安卓開發 Android開發 移動開發

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/

 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!