如何用不一樣的方式來處理安卓的權限管理？

時間 2019-11-16

原文原文鏈接

隨着 Marshmallow 的發佈，安卓增長了一種新的權限管理模式，要求開發者們採用一種不一樣的方式來處理安卓的權限管理。在本系列文章中，咱們將會從技術角度和如何提供流暢用戶體驗的角度來探討權限問題的處理方法。（#Permissions – Part 1）html

在深刻探討以前，必須先說明一點：一個 app 須要的權限實際分爲如下兩種：app 操做的核心權限——若是沒有這些核心權限，應用程序就沒法正確運行；以及輔助功能所需的權限。舉個例子，對於一個拍照 app 來講，CAMERA 權限是核心功能的一部分——不能拍照的拍照 app 徹底沒用。不過，還有一些額外功能，例如爲照片標記拍攝地點（須要開啓ACCESS_FINE_LOCATION），可是沒有這些功能 app 也能夠正常使用。android

接下來的系列文章中，咱們將要以某個 app 爲例展開討論，可是要想正常使用，須要開啓兩個權限： RECORD_AUDIO 和 MODIFY_AUDIO_SETTINGS。爲了得到這些權限，咱們必須按照常規在 Manifest 中聲明：git

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
  xmlns:tools="http://schemas.android.com/tools"
  package="com.stylingandroid.permissions">
 
  <uses-permission android:name="android.permission.RECORD_AUDIO" />
  <uses-permission android:name="android.permission.MODIFY_AUDIO_SETTINGS" />
 
  <application
    android:allowBackup="false"
    android:fullBackupContent="false"
    android:icon="@mipmap/ic_launcher"
    android:label="@string/app_name"
    android:supportsRtl="true"
    android:theme="@style/AppTheme.NoActionBar"
    tools:ignore="GoogleAppIndexingWarning">
 
    <activity android:name=".MainActivity" />
 
    <activity
      android:name=".PermissionsActivity"
      android:label="@string/title_activity_permissions"
      android:theme="@style/AppTheme.NoActionBar">
      <intent-filter>
        <action android:name="android.intent.action.MAIN" />
 
        <category android:name="android.intent.category.LAUNCHER" />
      </intent-filter>
    </activity>
  </application>
 
</manifest>

這是從 API 1就開始執行的安卓權限聲明的標準操做。可是，一旦咱們指定 targetSdkVersion 23 或其後版本，咱們還須要請求開放運行時所需的權限。這一點很是重要，由於已經有不少失敗案例，開發者直接將 targetSdkVersion 更新到最新版本，卻發現他們的 app 老是崩潰，這是由於他們沒有實現請求運行時所需權限的代碼。若是你在Google Play 應用商店發佈了基於 API 23 或以後版本的 app，以後你就沒法用基於更低版本開發的 APK 替換此 app，這就成了大問題。github

另外在這裏須要說明的是，如今已經有不少庫能夠簡化運行權限的請求流程。它們的效果和用處各不相同，可是筆者以爲關鍵是在使用以前，先理解基本流程，不然就會由於不瞭解所選庫的實際功能而出現問題。這也是促成本系列文章的主要緣由。安全

咱們請求的兩個權限實際上屬於不一樣的類別：RECORD_AUDIO 被看作是一個高風險的權限，MODIFY_AUDIO_SETTINGS 則被看作是低風險的權限。高風險權限指的是那些可能危害安全或隱私的權限；而低風險權限指的是須要訪問 app 域之外的資源，可是對用戶的隱私幾乎沒有危害。低風險權限將會被系統自動批准使用，而高風險權限則須要運行時用戶明確受權。性能優化

在這個流程中，首先要作的是肯定咱們是否已經得到所需權限。在 API 23 中，Context 增長了一些新方法來檢驗是否已經得到某項權限。可是，使用 ContextCompat 老是比直接使用 Context、而且進行 API 層面的檢查更好：網絡

class PermissionsChecker {
    private final Context context;
 
    public PermissionsChecker(Context context) {
        this.context = context;
    }
 
    public boolean lacksPermissions(String... permissions) {
        for (String permission : permissions) {
            if (lacksPermission(permission)) {
                return true;
            }
        }
        return false;
    }
 
    private boolean lacksPermission(String permission) {
        return ContextCompat.checkSelfPermission(context, permission) == PackageManager.PERMISSION_DENIED;
    }
 
}

這點其實很簡單——ContextCompat#checkSelfPermission 方法的做用不言自明，它會返回 PackageManager.PERMISSION_DENIED 或者 PackageManager.PERMISSION_GRANTED。筆者還增長了更進一步的邏輯，可用於檢查一個 app 是否已經得到所需權限。app

這裏有必要重申 ContextCompat 的做用。在未升級到 Marshmallow系統、不支持新的運行權限管理模式的設備上運行 checkSelfPermission() 方法時，總會返回 PackageManger.PERMISSION_GRANTED——在舊的操做系統中，權限已經獲得隱式受權，所以咱們只須要經過 Manifest 聲明，就能實現適用於全部操做系統的方法，也不須要在代碼中寫入任何 API 層面的特定檢查。ide

以防你不明白爲何筆者要專門講解這個問題，緣由是以後咱們要在 app 內的全部 Activity 中進行這些檢查。所以，若是可以將邏輯檢查與 Activity 區別開來，就能減小重複，提升代碼的可維護性。性能

要想在 Activity 中實際使用該方法，咱們只需用 Activity 所需的權限列表來調用之：

public class MainActivity extends AppCompatActivity {
    private static final String[] PERMISSIONS = new String[] {Manifest.permission.RECORD_AUDIO, Manifest.permission.MODIFY_AUDIO_SETTINGS};
 
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
 
        PermissionsChecker checker = new PermissionsChecker(this);
 
        if (checker.lacksPermissions(PERMISSIONS)) {
            Snackbar.make(toolbar, R.string.no_permissions, Snackbar.LENGTH_INDEFINITE).show();
        }
    .
    .
    .
    }
    }

這一點其實很是直白。

這在未升級到 Marshmallow 系統的設備上一樣適用：