- 原文链接 : Permissions – Part 1
- 原文作者 : Mark Allison
- 译文出自 : 开发技术前线 www.devtf.cn
- 转载声明: 本译文已授权开发者头条享有独家转载权，未经允许，不得转载!
- 译者 : shenyansycn
- 校对者:
- 状态 : 翻译中
在Marshmallow（棉花糖，Android6.0版本）中Android添加了一个新的权限模块，需要开发者在授权的时候做一些不同的处理。在这里系列文章中，我们从技术角度看下如何处理请求的权限和如何提供流畅的用户体验。
在我们开始前需要指出的是，App需要的权限集中下以下两部分：
- App的操作核心－没有这些核心权限，App不能正确的运行；
- 不是必须的权限。
例如，一个相机App，CAMERA权限是核心功能的一部分 － 不能处理任何图片的相机App是没用的。然而，这里有额外的功能，比如，标记图片所在的位置会需要ACCESS_FINE_LOCATION权限，这是一个非常好的功能，但App没有这个权限也可以运行。
我们的系列文章是以一个应用开始的，有两个权限是我们无论如何都需要使用的：RECORD_AUDIO 和 MODIFY_AUDIO_SETTINGS。为了获得这些权限，我们需要在Mainfest文件中声明它们：
AndroidManifest.xml
<?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>从Android Api 1.0版本开始，这就是标准的权限声明方法。然而，当把targetSdkVersion设置为23或更高，我们就需要在运行时请求需要的权限。这真的是重要的，因为已经有很多这样的例子了，开发者无意的设置targetSdkVersion为最新版本，然后正常运行的时候奔溃了，因为在运行时他们没有实现请求权限所必需的代码。更多问题中的一个是，当你一旦发布一个面向API23或更高的应用到GooglePlay上时，你不能再次发布一个面向低版本的APK。
另一个值得提到的事情是有一些专门用于运行时权限请求处理的库。这些库在质量和实用性都是有差异的，但是我认为使用这样的库前有必要了解底层实现原理，否则你会被问题搞死，因为你不知道你选择的库实际上都做了什么。这是这个系列文章的主要目的。
我们实际需要的两个权限分为两个不同的类别：RECORD_AUDIO是一个需要特别注意的危险权限，MODIFY_AUDIO_SETTINGS是一标准权限。一个危险的权限可能会影响用户安全或隐私。而一个需要访问App的外部资源的标准权限，对于用户隐私来说基本没有风险。标准权限会被系统自动授权，而危险权限在运行时需要用户明确的授权。
我们首先需要做的事情是判断我们需要的权限是否已经被授权了。在API 23 Context中新添加了一些方法用于检测是否特殊的权限已经被授予。然而，一般都是用ContextCompat替代Context，包括你自己的API-level检测：
PermissionChecker.java
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。我添加了更进一步逻辑判断，检测是否没有被授予任何所需要的权限。
需要重复说的是这里的ContextCompat为我们做了什么。在Marshmallow之前不支持新的运行时授权的设备上，checkSelfPermission()方法总是返回PackageManger.PERMISSION_GRANTED－在比较老的OS层这个权限被默认授予，所以在Manifest文件中声明后，我们仅用这一个方法调用可以在所有的OS层都工作，并且我们在代码中不必写任何API-level的检测。
以防万一你会疑惑我为什么为这个单独创建了一个类，因为过一会我需要在App中的所有Activity都用这个检测，所以把检测逻辑从Activity中分离出来会使我们有更少重复的代码和提高可维护性。
因此在Activiy中使用这个我们仅用Activity所需要的权限列表做为参数的调用即可：
MainActivity.java
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();
}
.
.
.
}
}实际上这是相当简单的。
这个可以原样运行在Marshamllow（Android6.0）之前的设备上：
但是，在Marshmallow（Android6.0）和之后的版本对于任何丢失的权限我们还没有处理－我们仅是显示了一个Snackbar：
下一章，我们更会进行更复杂的请求丢失的权限处理。
这篇文章的源码在 这里
© 2016, Mark Allison. All rights reserved.