android 7.0之后版本 出现file:// URI引起的FileUriExposedException

在我们app版本更新的迭代几个版本之后发现这次这个版本在7.0的手机上下载新版本,无法安装,出现

怎么会这一次出现这个问题呢?? 原来是我们这次版本更新将targetSdk 变到了25 以前是23 所以在以前的版本更新是不会出现这个问题, 默认代码会兼容高于23的版本.所以解决的方法我们可以把build.gradle的targetSdk变回到23,但是这样 不是最好的解决办法 如果项目以后还是需要使用新的特性或者以后后面项目移交别人时 targetSDK还是会变到高版本的 第二种解决方法 从病根着手 是什么原因导致出现这个?原来是android 7.0 系统开始对文件访问又加了保护,这属于7.0的新特性  查看android 7.0 文档 

简而言之,就是7.0开始

Android不再允许在app中把file://Uri暴露给其他app，包括但不局限于通过Intent或ClipData 等方法。原因在于使用file://Uri会有一些风险，比如：

        文件是私有的，接收file://Uri的app无法访问该文件。

        在Android6.0之后引入运行时权限，如果接收file://Uri的app没有申请READ_EXTERNAL_STORAGE权限，在读取文件时会引发崩溃。

因此，google提供了FileProvider，使用它可以生成content://Uri来替代file://Uri解决方案首先,在AndroidManifest.xml中添加provider

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

其次,再values目录下创建xml资源文件目录,然后创建provider_paths文件

 最后修改代码

       String filePath = Config.downLoadPath + "/" + filebean.getFileName();
        File file = new File(filePath);
        if (!file.exists()) {
            throw new NullPointerException(
                    "The package cannot be found");
        }
        Intent install = new Intent(Intent.ACTION_VIEW);
        // 调用系统自带安装环境
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) {
            install.setFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION | Intent.FLAG_ACTIVITY_NEW_TASK);
//            install.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
            Uri contentUri = FileProvider.getUriForFile(this, getPackageName()+".fileprovider", file);
            install.setDataAndType(contentUri, "application/vnd.android.package-archive");
        } else {
            install.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
            install.setDataAndType(Uri.fromFile(file), "application/vnd.android.package-archive");
        }
        getApplicationContext().startActivity(install);

其中Config.downLoadPath是

/**
 * 文件下载地址
 */
public static String downLoadPath = Environment.getExternalStorageDirectory().getAbsolutePath() + "/downloads/";

fileBean.getFileName(),就是xxx.apk

注意这里

这里设置权限和启动模式最好放在一起,因为有时候会出现安装不成功是因为权限的问题. 这里,基本就可以实现版本更新了分析FileProvider使用content://Uri的优点：它可以控制共享文件的读写权限，只要调用Intent.setFlags()就可以设置对方app对共享文件的访问权限，并且该权限在对方app退出后自动失效。相比之下，使用file://Uri时只能通过修改文件系统的权限来实现访问控制，这样的话访问控制是它对所有 app都生效的，不能区分app。它可以隐藏共享文件的真实路径。定义FileProvider在AndroidManifest.xml的<application>节点中添加<provider>

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

android:authorities是用来标识provider的唯一标识，在同一部手机上一个"authority"串只能被一个app使用，冲突的话会导致app无法安装。我们可以利用manifest placeholders来保证authority的唯一性。android:exported必须设置成false，否则运行时会报错java.lang.SecurityException: Provider must not be exported。android:grantUriPermissions用来控制共享文件的访问权限，也可以在java代码中设置。指定路径和转换规则FileProvider会隐藏共享文件的真实路径，将它转换成content://Uri路径，因此，我们还需要设定转换的规则。android:resource="@xml/provider_paths"这个属性指定了规则所在的文件。<paths>中可以定义以下子节点
 

子节点	对应路径
files-path	Context.getFilesDir()
cache-path	Context.getCacheDir()
external-path	Environment.getExternalStorageDirectory()
external-files-path	Context.getExternalFilesDir(null)
external-cache-path	Context.getExternalCacheDir()

file://到content://的转换规则：

1.替换前缀：把file://替换成content://${android:authorities}。

2.匹配和替换遍历<paths>的子节点，找到最大能匹配上文件路径前缀的那个子节点。用path的值替换掉文件路径里所匹配的内容。

3.文件路径剩余的部分保持不变.