安卓FileProvider是如何通过Uri提升文件安全的？

自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文件中添加<provider>标签，设置android:name属性的值为androidx.core.content.FileProvider；再设置android:authorities属性的值，可以自定义，通常是应用的包名加上.fileprovider后缀；设置android:exported属性的值为false，表示拒绝外部直接访问；设置android:grantUriPermissions的属性为true，表示可以为文件赋予临时访问权限。示例如下：

<manifest>
    ...
    <application>
        ...
        <provider
            android:name="androidx.core.content.FileProvider"
            android:authorities="${applicationId}.fileprovider"
            android:exported="false"
            android:grantUriPermissions="true">
            ...
        </provider>
        ...
    </application>
</manifest>

第二步：在/res/xml文件夹下创建一个命名为file_paths.xml的路径配置文件（文件名可以自定义），在这个文件中创建<paths>根结点，并在该节点下配置共享的文件夹，示例配置如下：

<?xml version="1.0" encoding="utf-8"?>
<paths xmlns:android="http://schemas.android.com/apk/res/android">
    <files-path name="my_images" path="images/"/>
    ...
</paths>

<paths>可以包含一个或多个子节点，支持<root-path>、<files-path>、<cache-path>、<external-path>、<external-files-path>、<external-cache-path>和<external-media-path> 七种[路径标签]，相同的标签可以出现多次来表示同一个父路径下的多个文件夹，在每种标签中，name属性是这个文件夹的别名，path属性是这个文件夹的真实路径名称，如前面所述，在生成Uri的时使用name别名来替换path中的真实路径，这样可以保护文件夹的真实路径不外泄。

下面来看一下<paths>标签支持的七种标签以及其对应的目录：

<paths>
    <!-- 对应的路径：File("/") -->
    <root-path name="root" path="my_root/" />
    <!-- 对应的路径：Context#getFilesDir() -->
    <files-path name="internal_files" path="my_internal_files/" />
    <!-- 对应的路径：Context#getCacheDir() -->
    <cache-path name="internal_cache" path="my_internal_cache/" />
    <!-- 对应的路径：Environment#getExternalStorageDirectory() -->
    <external-path name="external" path="my_external/" />
    <!-- 对应的路径：Context#getExternalFilesDirs(context, null) -->
    <external-files-path name="external_files" path="my_external_files/" />
    <!-- 对应的路径：Context#getExternalCacheDirs(context) -->
    <external-cache-path name="external_cache" path="my_external_cache/" />
    <!-- 对应的路径：Context#getExternalMediaDirs() -->
    <external-media-path name="external_media" path="my_external_media/" />
</paths>

另外还需要注意：在file_paths.xml文件中只能配置文件夹，不能配置单个文件；且一个[路径标签]中只能配置一个文件夹，不能配置多个文件夹。

最后一步：在第一步中定义的<provider>标签下使用<meta-data>标签引用这个配置，需要注意的是标签<meta-data>中的android:name属性必须是android.support.FILE_PROVIDER_PATHS。示例如下：

...
<provider
    android:name="androidx.core.content.FileProvider"
    android:authorities="${applicationId}.fileprovider"
    android:exported="false"
    android:grantUriPermissions="true">
    <meta-data
        android:name="android.support.FILE_PROVIDER_PATHS"
        android:resource="@xml/file_paths"/>
</provider>
...

二. 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 = "com.mydomain.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<String, PathStrategy> sCache = new HashMap<String, PathStrategy>();
......
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配置的<provider>信息
    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) {
            //获取配置的[路径标签]：<root-path>、<files-path>、
            //<cache-path>、<external-path>、<external-files-path>、
            //<external-cache-path>或<external-media-path>
            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的逻辑也比较简单：

  1. 先创建一个SimplePathStrategy对象；
  2. 然后读取AndroidManifest中配置的file_paths.xml文件数据；
  3. 使用XmlResourceParser解析<paths>下的[路径标签]后，转换成对应路径的File；
  4. 通过addRoot()方法将[路径标签]和path路径添加到SimplePathStrategy对象中。

到了这里我们能看出来，SimplePathStrategy对象中维护了file_paths.xml中配置的各种路径，下面我们通过SimplePathStrategy.addRoot()源代码看一下SimplePathStrategy是如何维护各种路径的：

private final HashMap<String, File> mRoots = new HashMap<String, File>();
......
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<String, File> mostSpecific = null;
    for (Map.Entry<String, File> 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个解决思路，如果大家有更好的思路也欢迎在评论区留言：

  1. 将文件存储到应用的思路目录/data/data/<包名>目录下，这样除非在被Root的手机上，否则外部应用是无法直接读取的，但是一般受手机存储空间限制，在低配置的手机上无法存储比较大的文件。
  2. 实现自己的FileProvider，将file_paths.xml中的配置的“密钥”换一个使用对称加密处理并个地方存储，使用逆向难度比较大的NDK层加密生成加密后的Uri。

这些年Android也在从系统层面不断地提升自身的安全性，包括即将伴随着Android 11正式到来的分区存储（沙盒机制），能进一步地保证应用文件的安全性，后面我会单独的写一篇文章详细剖析安卓系统的分区存储（沙盒机制）。
针对FileProvider如何通过Uri提升安全性的问题今天就和大家讨论到这里，大家有任何问题欢迎在评论区留言。

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 216,142评论 6赞 498
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 92,298评论 3赞 392
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 162,068评论 0赞 351
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 58,081评论 1赞 291
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 67,099评论 6赞 388
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 51,071评论 1赞 295
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 39,990评论 3赞 417
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 38,832评论 0赞 273
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 45,274评论 1赞 310
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,488评论 2赞 331
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,649评论 1赞 347
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 35,378评论 5赞 343
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 40,979评论 3赞 325
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,625评论 0赞 21
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,796评论 1赞 268
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 47,643评论 2赞 368
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 44,545评论 2赞 352