聊一聊 Android 6.0 的運行時權限

阿新 • • 發佈：2017-10-27

con alert 打電話 target 告訴分享 ttf alt toast

權限一刀切
棉花糖運行時權限
權限的分組
正常權限
- 正常權限列表
特殊權限
- 請求SYSTEM_ALERT_WINDOW
- 請求WRITE_SETTINGS
危險權限
必須要支持運行時權限麽
不支持運行時權限會崩潰麽
- 然而有點糟糕的是
該來的還得來
- 一個標準的流程
- 如何批量申請
- 申請這麽多權限豈不是很累
註意事項
- API問題
- 多系統問題
兩個權限
些許建議
註意

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

上述的權限基本設計的是關於網絡，藍牙，時區，快捷方式等方面，只要在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");
        }
    }
}

上述代碼需要註意的是

使用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" );
        }
    }
}

上述代碼需要註意的是

使用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
}

如果用戶撤消了獲取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);
        }
    }

通常情況下，我們會得到這樣的一個對話框

技術分享

當用戶選擇允許，我們就可以在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");
}

如何批量申請

批量申請權限很簡單，只需要字符串數組放置多個權限即可。如請求代碼

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);
}

對應的界面效果是
技術分享

註意：間隔較短的多個權限申請建議設置成單次多個權限申請形式，避免彈出多個對話框，造成不太好的視覺效果。

申請這麽多權限豈不是很累

其實你不需要每個權限都去顯式申請，舉一個例子，如果你的應用授權了讀取聯系人的權限，那麽你的應用也是被賦予了寫入聯系人的權限。因為讀取聯系人和寫入聯系人這兩個權限都屬於聯系人權限分組，所以一旦組內某個權限被允許，該組的其他權限也是被允許的。

註意事項

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
}

兩個權限

運行時權限對於應用影響比較大的權限有兩個，他們分別是

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的運行時權限對於用戶來說絕對是一個好東西，但是目前想要支持需要做的事情還是比較多的。

對於一個有很多依賴的宿主應用，想要做到支持還是有一些工作量的，因為你的權限申請受制於依賴。

建議在短期內暫時可以不考慮支持該運行時權限機制,等時機成熟或者簡單易用的第三方庫完善之後再支持也未嘗不可。

聊一聊 Android 6.0 的運行時權限

聊一聊 Android 6.0 的運行時權限

權限一刀切

棉花糖運行時權限

權限的分組

正常權限

正常權限列表

特殊權限

請求SYSTEM_ALERT_WINDOW

請求WRITE_SETTINGS

危險權限

必須要支持運行時權限麽

不支持運行時權限會崩潰麽

然而有點糟糕的是

該來的還得來

一個標準的流程

如何批量申請

申請這麽多權限豈不是很累

註意事項

API問題

多系統問題

兩個權限

些許建議

註意

相關推薦