FileProvider 是 Android N 系统提供的保障 app 间文件 (File) 传输安全的一个新特性。当我们的应用需要分享私有文件时（典型场景就是调用相机拍照），我们需要适配此特性，否则将会在 Android 7.0 以上系统触发安全机制（StrictMode），导致闪退。
FileProvider 是 ContentProvider 的子类，实现了 query() 和 delete() 方法，并使 insert() 和 update() 方法直接抛出异常。同时，新增了一个 public static 方法，getUriFromFile(File file),来让我们在应用中获取用于分享此 file 的 uri。FileProvider 类中还有一些用于解析文件路径的内部类和私有方法，此处不展开分析。
工作过程
Uri 是什么
Uri 类是 Android 对 Java 提供的 URI 类的一个扩展。简单来讲，Uri 对象是对一个资源文件（图片、音频等）的一个标识符（Identifier），通过这个对象，应用可以准确的找到对应的资源文件。Uri 主要分为三部分：scheme, authority 和 path。一个常见的 uri 示例如下："content://com.mydomain.fileprovider/image.jpg"，也就是 "{scheme}://{authority}/{path}"
应用根据文件获取 uri
拿我们使用相机为自己的应用提供照片为例，我们需要向启动相机的 intent 中加入存储相片的文件的 uri 信息，以供相机应用存储照片时使用。
在 7.0 以前的系统版本中，我们可以直接调用 Uri.fromFile(file) 来获取 file 的 uri，这个 uri 以 “file:///” 为首，且无时效性限制，接受到此 uri 的应用可以对它进行保存后，随时获取此 file。
而在 7.0 以后的系统版本中，我们只能通过前文提到的，FileProvider.getUriFromFile(file) 来提供一个以 “content://” 为首的 uri。这个 uri 有一定的时效性，其生命周期伴随着 intent 关联的组件（可以是 Activity，也可以是 Service）的生命周期结束而结束，所以很大程度上保障了开发者的应用私有文件的安全。
接收到 uri 的应用，通过 uri 获取具体文件
为此我特意找到了 5.1 和 7.0 系统的 Camera 源码，准备写一写两个系统对接受到的 Uri 处理方式的不同，然后发现...
两个系统的处理方式一毛一样！都是 getContentResolver().openOutputStream(mSaveUri),然后对这个输出流写数据。
心有不甘的我又打开了 ContentReslover 的源码，发现真正区别的代码是在这里：
** ①“file" 开头的uri，直接用 new File(uri.getPath()) 获取对应文件 **
** ②“content" 开头的uri，先找到对应的 Provider （这里就是 FileProvider），再调用unstableProvider.openAssetFile(mPackageName, uri, mode, remoteCancellationSignal) 获取对应文件**
适配教程
在 AndroidManifest 中定义 FileProvider
定义 FileProvider 的过程其实和定义 ContentProvider 的过程相差无几，只不过系统已经为我们构建好了 FileProvider 的具体代码，我们只需要在 AndroidManifest.xml 中来定义他们。
直接上代码：
<manifest>
...
<application>
...
<provider
android:name="android.support.v4.content.FileProvider"
android:authorities="com.mydomain.fileprovider"
android:exported="false"
android:grantUriPermissions="true">
<meta-data
android:name="android.support.FILE_PROVIDER_PATHS"
android:resource="@xml/file_paths"/>
</provider>
...
</application>
</manifest>
其中，需要自定义的有 android:authorities,用于标识属于你的应用的 FileProvider；还有 meta-data 标签内需要指定一个路径配置文件，android:resource。关于路径配置文件的相关定义在下节会给出。
在 xml 文件夹下定义路径配置文件
路径配置文件限制了 FileProvider 可以获取到你的应有私有目录下具体的子文件夹，比如说你的应用目录下有 imgs 和 docs 两个子文件夹，而你只希望向外分享图片，则可以将下面的 path 属性值设置为 path="imgs"。
一般我们在 res 文件夹下新建一个 xml 文件夹，然后新建一个 file_paths.xml 文件（文件夹名+文件名=上面 Mainfest 中定义的 meta-data 标签 的 resource 属性）。然后 file_paths.xml 中写入：
<?xml version="1.0" encoding="utf-8"?>
<paths>
<external-path name="my_images" path=""/>
<!-- 以下为各类标签汇总
<files-path name="name" path="path" />
<cache-path name="name" path="path"/>
<external-path name="name" path="path"/>
<external-files-path name="name" path="path"/>
<external-cache-path name="name" path="path"/>
-->
</paths>
其中，name 属性值用于组成最后生成的 uri 的一部分，所以这个属性可以任意定制。
而前面的标签名的不同则决定了文件夹位置的不同。
"files_path" 对应 Context.getFilesDir() 的路径，物理路径为：data/data/<application package>/files。
"cache-path" 对应 Context.getCacheDir()，物理路径为：/data/data/<application package>/cache。
"external-path"对应 Environment.getExternalStorageDirectory()。
"external-files-path" 对应Context.getExternalFilesDir(String)、Context.getExternalFilesDir(null)。
而 "external-cache-path" 对应的是 Context.getExternalCacheDir()。
path 属性就是第一段所提到的，当你的文件夹下有多个子文件夹，你只希望提供某一个文件夹的时候，可以在属性中填入相应的文件夹名。为空时，FileProvider 则可以为应用文件夹下的所有文件生成 uri。
获取 uri 并分享
当配置文件都完成了之后我们便可以方便的获取 uri了，具体代码如下：
File file = new File(Context.getFilesDir(), "default_image.jpg");
Uri contentUri = FileProvider.getUriForFile(getContext(), "com.mydomain.fileprovider", file);
这时候，你就可以获取到一个值为："content://com.mydomain.fileprovider/my_images/default_image.jpg" 的 uri了，其中 “com.mydomain.fileprovider/” 后的 "my_images" 就是前面路径配置文件中 name 属性指定的。再将 uri 传入 intent，设置临时权限，适配完成。
Intent intent = new Intent();
intent.setAction(MediaStore.ACTION_IMAGE_CAPTURE);
intent.putExtra(MediaStore.EXTRA_OUTPUT, contentUri);
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK | Intent.FLAG_GRANT_READ_URI_PERMISSION
| Intent.FLAG_GRANT_WRITE_URI_PERMISSION);
startActivityForResult(intent, requestCode);
当然，这只是对应 7.0 以上系统的代码截选，对应 7.0 以下系统的代码中，我们直接调用 Uri.fromFile(file) 获取 uri 即可。
总结
FileProvider 这个类其实在 Android 5.1 就已经加入到了 sdk 中，Android 7.0 开始强制开发者使用，可以看出，谷歌有意进一步提升安卓系统的安全性。在查阅资料的过程中，看到有评论“通过反射关闭 StrictMode 从而防止闪退”的“黑科技”（哭笑），从我个人使用的感觉上，适配这个新特性，并没有繁琐的操作，也没有性能的影响。作为一个还没入行的开发者，还是希望大家可以支持谷歌建设更好的生态，而不是自砸饭碗吧。
