前言
对于 Android 7.0,提供了非常多的变化,不过和我们开发者关联最大的,或者说必须要适配的就是去除项目中传递 file://
类似格式的 Uri 了。
对于面向 Android 7.0 的应用,Android 框架执行的 StrictMode API 政策禁止在应用外部公开 file:// URI
, 如果一项包含文件 URI 的 intent 离开应用,则应用出现故障,并出现 FileUriExposedException 异常。
要应用间共享文件,您应发送一项 content:// URI
,并授予 URI
临时访问权限。进行此授权的最简单方式是使用 FileProvider 类。如需了解有关权限和共享文件的详细信息,请参阅 共享文件
FileProvider 实际上是 ContentProvider 的一个子类,它的作用也比较明显,file://Uri
不给用,那么换个 Uri 为 content://
来替代。
Provider 使用详解
我们先在 AndroidManifest
中进行注册
为什么要申明呢?当然是因为 FileProvider 是 ContentProvider 的子类啊。
FileProvider 只能为指定的目录中的文件生成内容 URI。要指定目录,就必须使用 <paths>
元素的子元素在 XML 中指定其存储区域和路径。
我们先创建一个名为 res/xml/filepaths.xml
的新文件
在 filepaths.xml
文件中,便可以指定文件存储的区域和路径。例如,以下路径元素告诉 FileProvider,你打算为私有文件区域的 images/ 子目录
请求内容 URI
<paths>
必须包含以下元素中一个或者多个子元素
在 paths
节点内部支持以下几个子节点,分别为:
子节点 | 含义 |
---|---|
<root-path> | 代表设备的根目录 new File("/") |
<files-path> | 代表 context.getFileDir() |
<cache-path> | 代表 context.getCacheDir() |
<external-path> | 代表 Environment.getExternalStorageDirectory() |
<external-files-path> | 代表 context.getExternalFilesDirs() |
<external-cache-path> | 代表 getExternalCacheDirs() |
每个节点都使用两个属性:
name
path
path
即为代表目录下的子目录,例如:
<external-path name="external" path="pics"/>
代表的目录即为:Environment.getExternalStorageDirectory()/pics
当这么声明以后,代码可以使用你所声明的当前文件夹以及其子文件夹
可能你会有疑问,为什么要写这么个 xml 文件,有啥用呢?
我们刚才说了,现在要使用 content://uri
替换 file://uri
,那么,content://
的 uri
如何定义呢?总不能使用文件路径吧,那不是骗自己么
所以,需要一个虚拟的路径对文件路径进行映射,所以需要编写个 xml
文件,通过 path
以及 xml
节点确定可访问的目录,通过 name
属性来映射真实的文件路径
写好 filepaths.xml
文件之后,要将此文件链接到 FileProvider
中,就必须添加一个 <meta-data>
元素作为定义 FileProvider
的 <provider>
元素的子元素。将 <meta-data>
元素的 android : name
属性设置为 android.support.FILE_PROVIDER_PATHS
, 将元素的 "android : resource"
属性设置为 @xml / filepaths
(注意不要指定 .xml 拓展名)。例如:
配置工作已经全部完成了,后面就需要将之前传递的 file://
替换成 FileProvoider
需要用到的 content://
,这就需要用到 FileProvider.getUriForFile()
方法了
可以看到 getUriForFile()
,需要传入 一个
authority 的参数,这正是我们前面在 AndroidManifest.xml
文件中配置的 android:authorities
参数
调用这个方法会自动得到一个 file://
转换成 content://
的一个 Uri 对象,可以供我们直接使用
当我们生成一个 content://
的 Uri 对象之后,其实还无法对其直接使用,还需要对这个 Uri 接收的 App 赋予对应的权限才可以。
这个授权的动作,提供了两种方式来授权:
① 通过 Context 的 grantUriPermission() 方法授权
Context 提供了两个方法
grantUriPermission(String toPackage, Uri uri, int modeFlags)
revokeUriPermission(Uri uri, int modeFlags);
可以看到 grantUriPermission() 方法需要传递一个包名,就是你给哪个应用授权,但是很多时候,比如分享,我们并不知道最终用户会选择哪个 app,所以我们可以这样:
根据 Intent 查询出所有符合的应用,都给他们授权,然后在不需要的时候通过 revokeUriPermission 移除权限。
② 配合 Intent.addFlags() 授权
既然这是一个 Intent 的 Flag,Intent 也提供了另外一种比较方便的授权方式,那就是使用 Intent.setFlags()
或者 Intent.addFlag
的方式
使用这种形式的授权,权限截止于该 App 所处的堆栈被销毁。也就是说,一旦授权,知道该 App 被完全退出,这段时间内,该 App 享有对此 Uri 指向的文件的对应权限,我们无法主动收回该权限了。
总结
Android 7.0 禁止在应用外部公开 file:// URI
,所以我们必须使用 content://
替代 file://
,这时主要需要 FileProvider 的支持,而因为 FileProvider 是 ContentProvider 的子类,所以需要在 AndroidManifest.xml
文件中进行注册,而又因为需要对真实的 filepath
进行映射,所以需要编写一个 xml 文档,用于描述可使用的文件夹目录,以及通过 name 去映射该文件夹目录。
当我们生成一个 content://
的 Uri 对象之后,还需要对这个 Uri 接收的 App 赋予对应的权限,到此本文的内容就基本结束了。
参考
http://blog.csdn.net/lmj623565791/article/details/72859156
http://www.jianshu.com/p/3879bb6ff0ed
https://developer.android.com/training/secure-file-sharing/index.html
与之相关
日
更
精
彩
微信号:code-xiaosheng
公众号
「code小生」
联系客服