自Android 7.0开始，Android 框架开启了严格模式（StrictMode），禁止应用将file:///开头的Uri共享给其他的应用读写文件，否则会收到FileUriExposedException的异常。与此同时，Android框架提供了新的文件共享机制 — FileProvider。
但在日常开发中大家使用FileProvider的机会比较少，故其背后的工作原理应该很少有人知道。在上一篇文章《Android系统为什么要提供FileProvider机制》中已经为大家讲解了FileProvider的作用是为了加强应用之间共享文件的安全性。仔细观察会发现，通过FileProvide生成的Uri是以content://开头，不同于以往file://开头的Uri直接暴露文件的存储的路径，FileProvide生成的Uri会使用我们在<paths>中配置的[路径标签]的name属性替换真实的文件路径，有点类似掩码的机制，即使未经授权的外部App拿到了Uri也不知道文件的具体位置，更谈不上直接访问了，从而提高文件访问的安全性。
相信到了这里大家一定会好奇，FileProvider生成Uri的原理是什么？又是如何通过Uri提升文件安全的呢？带着这两个问题，我们一起来通过androidx版本中的FileProvider的源代码，一起探究一下FileProvider背后的机制和原理。
因为FileProvider比较不常用，相信有不少同学对如何配置FileProvider已经有点模糊了，为了方便大家理解下面的章节，我们先简单回顾一下FileProvide的配置方法。已经熟悉配置方法的同学可以跳过这一节直接看重点。
简单回顾如何配置FileProvider
提问：声明一个FileProvider一共分几步？答：三步，第一步先把冰箱门打开，第二步把大象放进去....
不好意思，串台了，重来！
第一步：在Manifest文件中添加
androidx.core.content.FileProvider；再设置android:authorities属性的值，可以自定义，通常是应用的包名加上.fileprovider后缀；设置android:exported属性的值为false，表示拒绝外部直接访问；设置
android:grantUriPermissions的属性为true，表示可以为文件赋予临时访问权限。示例如下：
...
...
...
...
第二步：在/res/xml文件夹下创建一个命名为file_paths.xml的路径配置文件（文件名可以自定义），在这个文件中创建
下面来看一下
另外还需要注意：在file_paths.xml文件中只能配置文件夹，不能配置单个文件；且一个[路径标签]中只能配置一个文件夹，不能配置多个文件夹。
最后一步：在第一步中定义的
android.support.FILE_PROVIDER_PATHS。示例如下：
...
...FileProvider生成Uri的过程
在第一节中我们回顾了在Manifest中声明FileProvider，本节咱们一起看一下FileProvider如何使用配置参数生成Uri。下面一起看一下如何使用FileProvider生成Uri：
File imagePath = new File(Context.getFilesDir(), "images");
File newFile = new File(imagePath, "default_image.jpg");
String authority = BuildConfig.APPLICATION_ID + ".fileprovider";
Uri contentUri = FileProvider.getUriForFile(context, authority, newFile);通过以上代码生成Uri：
content://com.mydomain.fileprovider/my_images/default_image.jpg，下面我们一起通过时序图来看一下关键方法
FileProvider.getUriForFile()调用的背后到底发生了什么：
FileProvider生成Uri的时序图
从以上时序图中我们可以很清晰地看到，最终负责生成Uri的是SimplePathStrategy类的getUriForFile方法，那么我们不禁要问：PackageManager、ProviderInfo和XmlResourceParser这三个类在其中又起了什么作用了呢？要回答这个问题就需要先说一下FileProvider生成Uri的三个步骤：
FileProvider生成Uri的三个步骤
1）从缓存中查找PathStrategy：
我们先来看一下
FileProvider.getUriForFile()的源代码：
public static Uri getUriForFile(@NonNull Context context, @NonNull String authority,
@NonNull File file) {
//调用getPathStrategy获取PathStrategy对象
final PathStrategy strategy = getPathStrategy(context, authority);
//调用PathStrategy生成Uri
return strategy.getUriForFile(file);
}从上面的源代码可以看到，
FileProvider.getUriForFile()是一个门面方法，最终负责生成Uri的是PathStrategy对象，接下来我们看一下
FileProvider.getPathStrategy()方法如何获取PathStrategy对象：
@GuardedBy("sCache")
private static HashMap sCache = new HashMap();
......
private static PathStrategy getPathStrategy(Context context, String authority) {
PathStrategy strat;
synchronized (sCache) {
//以authority为key从缓存中读取PathStrategy
strat = sCache.get(authority);
if (strat == null) {
try {
//如果缓存中没有找到PathStrategy，调用parsePathStrategy方法
//通过配置文件生成PathStrategy
strat = parsePathStrategy(context, authority);
} catch (IOException e) {
......
}
//将创建的PathStrategy方到缓存中
sCache.put(authority, strat);
}
}
return strat;
} 从上面的源代码可以看出，FileProvider使用HashMap实现了一个简单的缓存，通过传入的authority参数来存储不同的PathStrategy对象。进入getPathStrategy()方法，会先从缓存中查找PathStrategy，如果在缓存中没有，则会调用parsePathStrategy()方法创建一个，放到缓存中并使用。
2）读取Manifest配置创建PathStrategy：
我们再看一下parsePathStrategy()方法如何创建PathStrategy。
private static PathStrategy parsePathStrategy(Context context, String authority)
throws IOException, XmlPullParserException {
//使用传入的authority参数创建SimplePathStrategy对象
final SimplePathStrategy strat = new SimplePathStrategy(authority);
//使用传入的authority参数读取AndroidManifest.xml配置的信息
final ProviderInfo info = context.getPackageManager()
.resolveContentProvider(authority, PackageManager.GET_META_DATA);
......
//加载配置的file_paths.xml的数据
final XmlResourceParser in = info.loadXmlMetaData(
context.getPackageManager(), META_DATA_FILE_PROVIDER_PATHS);
......
int type;
while ((type = in.next()) != END_DOCUMENT) {
if (type == START_TAG) {
//获取配置的[路径标签]：、、
//、、、
//或
final String tag = in.getName();
//获取配置的name属性，即文件夹的别名
final String name = in.getAttributeValue(null, ATTR_NAME);
//获取配置的path属性，即文件夹的真实路径
String path = in.getAttributeValue(null, ATTR_PATH);
File target = null;
//使用else if语句将[路径标签]转换成对应的真实路径File对象
if (TAG_ROOT_PATH.equals(tag)) {
target = DEVICE_ROOT;
} else if (TAG_FILES_PATH.equals(tag)) {
......
}
//将文件夹的别名和真实路径添加到SimplePathStrategy对象中
//buildPath()方法用[路径标签]的路径和path属性生成一个File对象
if (target != null) {
strat.addRoot(name, buildPath(target, path));
}
}
}
return strat;
} 如上面源代码注释，parsePathStrategy()方法创建PathStrategy的逻辑也比较简单：
- 先创建一个SimplePathStrategy对象；
- 然后读取AndroidManifest中配置的file_paths.xml文件数据；
- 使用XmlResourceParser解析
下的[路径标签]后，转换成对应路径的File； - 通过addRoot()方法将[路径标签]和path路径添加到SimplePathStrategy对象中。
到了这里我们能看出来，SimplePathStrategy对象中维护了file_paths.xml中配置的各种路径，下面我们通过
SimplePathStrategy.addRoot()源代码看一下SimplePathStrategy是如何维护各种路径的：
private final HashMap mRoots = new HashMap();
......
void addRoot(String name, File root) {
if (TextUtils.isEmpty(name)) {
throw new IllegalArgumentException("Name must not be empty");
}
try {
// 转换为规范路径名的文件
// 例如：转换前文件路径 c:\users\..\program
// Canonical转换的路径：C:\program
root = root.getCanonicalFile();
} catch (IOException e) {
throw new IllegalArgumentException(
"Failed to resolve canonical path for " + root, e);
}
mRoots.put(name, root);
} 从上面的代码可以看到SimplePathStrategy也是使用HashMap做了一个简单的缓存，使用文件夹的name别名来存储不同的文件夹规范路径后的File。
3）PathStrategy生成Uri：
经过前两个步骤的数据准备，终于到了最后一步：
SimplePathStrategy.getUriForFile()：
@Override
public Uri getUriForFile(File file) {
String path;
try {
//获取共享文件的规范路径字符串
path = file.getCanonicalPath();
} catch (IOException e) {
throw new IllegalArgumentException("Failed to resolve canonical path for " + file);
}
// 遍历缓存的文件夹，找出最具体根路径
Map.Entry mostSpecific = null;
for (Map.Entry root : mRoots.entrySet()) {
final String rootPath = root.getValue().getPath();
if (path.startsWith(rootPath) && (mostSpecific == null
|| rootPath.length() > mostSpecific.getValue().getPath().length())) {
mostSpecific = root;
}
}
//如果没有找到根路径则抛出异常
if (mostSpecific == null) {
throw new IllegalArgumentException(
"Failed to find configured root that contains " + path);
}
// 去掉分享文件Path中的根路径
final String rootPath = mostSpecific.getValue().getPath();
if (rootPath.endsWith("/")) {
path = path.substring(rootPath.length());
} else {
path = path.substring(rootPath.length() + 1);
}
// 使用authority、根路径别名和去掉根路径的Path生成最终的Uri
path = Uri.encode(mostSpecific.getKey()) + '/' + Uri.encode(path, "/");
return new Uri.Builder().scheme("content")
.authority(mAuthority).encodedPath(path).build();
} 通过上面的源代码注释大家可以看到，Uri的生成的核心过程就是找到分享文件根路径的name别名的过程，然后Uri就能很轻松的构建出来了。
FileProvider通过Uri提升安全性
通过上面的源代码对FileProvider庖丁解牛，相信大家对FileProvider如何通过Uri提升安全性的问题都有了一定的认识。换个角度看，其实生成Uri的过程就是对文件路径进行加密的过程，使用的密钥就是我们在file_paths.xml文件中配置的路径name别名，这样及时外部应用拿到了文件的Uri也不知道文件具体的存储位置，所以就不能做到绕开授权直接文件了。
但是用逆向的思维来看也不是绝对安全的，如果我们想要破解一个应用生成的Uri对应的文件的绝对路径，只需要用apktool等逆向工具将file_paths.xml解压缩出来，根据file_paths.xml中的配置逆向解析Uri即可得到文件真正的路径了。
那么有没有更安全的方法来解决这个问题呢？在这里给大家提供2个解决思路，如果大家有更好的思路也欢迎在评论区留言：
- 将文件存储到应用的思路目录/data/data/<包名>目录下，这样除非在被Root的手机上，否则外部应用是无法直接读取的，但是一般受手机存储空间限制，在低配置的手机上无法存储比较大的文件。
- 实现自己的FileProvider，将file_paths.xml中的配置的“密钥”换一个使用对称加密处理并个地方存储，使用逆向难度比较大的NDK层加密生成加密后的Uri。
这些年Android也在从系统层面不断地提升自身的安全性，包括即将伴随着Android 11正式到来的分区存储（沙盒机制），能进一步地保证应用文件的安全性，后面我会单独的写一篇文章详细剖析安卓系统的分区存储（沙盒机制）。
针对FileProvider如何通过Uri提升安全性的问题今天就和大家讨论到这里，大家有任何问题欢迎在评论区留言。