app升级是每一个android应用的标配了，大部分应用都会有升级提醒和apk下载安装(如果系统允许静默安装估计就没有提醒这段了)。

   以前的升级是自己写http下载或者通过系统提供的DownloadManager进行下载。无意间发现bugly提供下载更新服务而且免费（后来又提供了热更新），就乐呵呵的接入了sdk，毕竟是大厂的东西，值得信赖。开始用的时候用的很稳定（估计是手机厂商还没用上牛轧糖），后来就有人反应更新失败，一直提示安装，开始有些不相信直接让用户卸载重装（还好用户是公司自己人，是外人的话那就有卸载无安装了）。

    检查问题的时候也看了一下bugly的接入指南，加入了android7.0的适配。开始觉得7.0的用户还少而且我的编译版本是5.0就没做适配。当最近更新反应更新失败的用户比较多时就仔细查了一下问题。也看了一下鹅厂工程师的博客（）。原来这是由于Android7.0执行了“StrictMode API 政策禁”的原因。" StrictMode API 政策" 是指禁止向你的应用外公开 file:// URI。 如果一项包含文件 file:// URI类型 的 Intent 离开你的应用，应用失败，并出现 FileUriExposedException 异常。


以前更新通过隐式调用系统安装程序


Intent i = new Intent(Intent.ACTION_VIEW);


i.setDataAndType(Uri.fromFile(file), "application/vnd.android.package-archive");


i.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);


context.startActivity(i);



    这段代码是通过intent设置数据和类型，然后通过context在新的task中启动安装apk的程序。 
我们看到intent设置数据时，传递的是一个Uri，这个在API<24是没有问题的，但在Android N已经禁止你对外公开file://URI.所以我们SDK的问题就出自Uri.fromFile(file)获取uri的时候。


    Android N已经给出明确解决方案，如果你的程序需要在应用间共享文件，您应发送一项 content://URI，并授予 URI 临时访问权限。进行此授权的最简单方式是使用 FileProvider类。

   首先在AndroidManifest中注册FileProvider 
   代码示例：


<provider  


android:name="android.support.v4.content.FileProvider"


android:authorities="com.bugly.upgrade.demo.fileProvider"


android:exported="false"


android:grantUriPermissions="true">


<meta-data   


android:name="android.support.FILE_PROVIDER_PATHS"


android:resource="@xml/provider_paths"/>


</provider>


这里要注意一下，FileProvider是support-v4包里面的，所以在你的程序必须要引入support-v4包。 
我们可以看到在provider中需要配置相应的meta-data，这个是共享文件的路径，在res目录下新建xml文件夹并新建对应的xml文件（如下面的provider_paths)，如下所示：


<?xml version="1.0" encoding="utf-8"?>


<paths xmlns:android="http://schemas.android.com/apk/res/android">


<!-- /storage/emulated/0/Download/-->


<external-path name="beta_external_apk" path="Download/"/>


<!--/storage/emulated/0/Android/data/-->


<external-path name="beta_external_apk2" path="Android/data//"/>


</paths>


  name表示一个URI路径段，path表示指定要分享路径的子目录。这样系统安装程序就能访问下载的apk文件了。

 由于手里没有7.0的设备在优测上租个设备（还好有一个小时的试用）测试了一下，完美解决。谷歌系统升级竟然不向下兼容，这也是个坑。