关于这个毛茸茸的小错误
最新在开发一个新的 APP ,自己手动写了版本更新,测试发现,覆盖安装的时候,在 Android 7.0 系统上出现解析包错误。
报错信息:
核心报错信息:
java.lang.SecurityException: Permission Denial:
opening provider android.support.v4.content.FileProvider from ProcessRecord{cc3ad2316425:
com.android.packageinstaller/u0a21} (pid=16425, uid=10021) that is not exported from uid 10340
- 1
- 2
- 3
关于安装失败,案发地点的代码:
/*******************错误版***************************/
/**
* 安装 apk 文件
* @param apkFile apk 文件
*/
private void installApk(File apkFile){
Intent intent = new Intent(Intent.ACTION_VIEW);
Uri apkUri = null;
//判断版本是否是 7.0 及 7.0 以上
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) {
apkUri = FileProvider.getUriForFile(getActivity(), BuildConfig.APPLICATION_ID + ".fileProvider", apkFile);
//添加这一句表示对目标应用临时授权该Uri所代表的文件
intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);
} else {
apkUri = Uri.fromFile(apkFile);
}
//由于没有在Activity环境下启动Activity,所以设置下面的标签
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
intent.setDataAndType(apkUri,
"application/vnd.android.package-archive");
startActivity(intent);
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
当发现是 7.0 系统上才会出现的问题之后,再联系报错信息,很容易就想到 FileProvider 的权限问题,然而并没有什么用,我还是不知道怎么回事。对比之前实现的版本更新的代码,定位到 intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
这句代码,当把这句话放在前面,就是正常的。
/**
* 安装 apk 文件
* @param apkFile apk 文件
*/
private void installApk(File apkFile){
Intent intent = new Intent(Intent.ACTION_VIEW);
//放在此处
//由于没有在Activity环境下启动Activity,所以设置下面的标签
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
Uri apkUri = null;
//判断版本是否是 7.0 及 7.0 以上
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) {
apkUri = FileProvider.getUriForFile(getActivity(), BuildConfig.APPLICATION_ID + ".fileProvider", apkFile);
//添加这一句表示对目标应用临时授权该Uri所代表的文件
intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);
} else {
apkUri = Uri.fromFile(apkFile);
}
intent.setDataAndType(apkUri,
"application/vnd.android.package-archive");
startActivity(intent);
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
错误原因
看一下核心报错
java.lang.SecurityException: Permission Denial: opening provider android.support.v4.content.FileProvider from ProcessRecord{cc3ad23 16425:com.android.packageinstaller/u0a21} (pid=16425, uid=10021) that is not exported from uid 10340
这个是权限不足的提示,Android 7.0 之后通过 FileProvider 共享文件,因为 exported为 false,所以需要给目标应用,授予临时权限,加上 Intent.FLAG_GRANT_READ_URI_PERMISSION 参数。
很明显,我已经加了,但是很不幸,我们在添加之后, intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK)
把添加的给替换掉了,因此实际上还是未给权限。
这是因为对 setFlags() 和 addFlags() 认知不清,错误使用导致的,最后,将 setFlags()操作放在 addFlags() 之前解决了这个问题。
intent.setFlags() 和 intent.addFlags() 的区别
setFlags():为intent 设置特殊的标志,会覆盖 intent 已经设置的所有标志。
public Intent setFlags(int flags) {
mFlags = flags;
return this;
}
- 1
- 2
- 3
- 4
- 5
addFlags():为intent 添加特殊的标志,不会覆盖,只会追加。
public Intent addFlags(int flags) {
mFlags |= flags;
return this;
}
- 1
- 2
- 3
- 4
- 5
拓展知识补充
Android 7.0 行为变更,通过 FileProvider 在应用中共享文件
Android 7.0 除了提供诸多新特性和功能外,还对系统和 API 行为做出了各种变更。其中有一条,对日常开发的适配影响是非常大的,传递软件包网域外的 file:// URI 可能给接收器留下无法访问的路径。因此,尝试传递 file:// URI 会触发 FileUriExposedException。解决方法是使用 FileProvider 将 file:// URI 转换为 content:// URI 。
FileProvider 的使用方法网上有很多,这里不多说了,附上 Google 官方文档 FileProvider
Intent.FLAG_GRANT_READ_URI_PERMISSION & android:grantUriPermissions & context.grantUriPermission()三者的区别
刚开始用 FileProvider 的时候,并不是很懂它,只是 copy & paste,所以对这三个 grantUriPermissions 很是傻傻分不清楚。遇到这么问题专门去查了一下。
android:grantUriPermissions
这个是定义在 FileProvider 中的属性,作用是允许对 ContentProvider 通信的目标应用临时授权。
这个属性默认是 false,但是要求必须设置为 true,否则直接报错 java.lang.SecurityException: Provider must grant uri permissions
我们可以在 FileProvider 源码中看到对这个值的限制:
public void attachInfo(Context context, ProviderInfo info) {
super.attachInfo(context, info);
if(info.exported) {
throw new SecurityException("Provider must not be exported");
} else if(!info.grantUriPermissions) {
throw new SecurityException("Provider must grant uri permissions");
} else {
this.mStrategy = getPathStrategy(context, info.authority);
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
Intent.FLAG_GRANT_READ_URI_PERMISSION
这个是 Intent 的一个 Flag 值,会临时授予目标引用对所传递 Uri 的临时访问权限。
这个临时访问权限在setResult()数据接收方 Activity 还在栈中时,都是有效的,如果弹出了,临时访问权限自动取消。
通过 addFlags()
和setFlags()
两种方式添加:
//addFlags()方式
intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);
//setFlags()方式
intent.setFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);
- 1
- 2
- 3
- 4
- 5
- 6
context.grantUriPermission()
这个方法和使用 intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)
可以任选其一,因为它们的效果是一样的,都是对目标引用临时授权。
区别在于 context.grantUriPermission()的临时访问权限不会在数据接收页面关闭时自动取消,只有手动调用 revokeUriPermission() 或者整个应用重新启动,才会失效。
grantUriPermission(String toPackage, Uri uri,@Intent.GrantUriMode int modeFlags)需要传递三个参数:
参数名称 | 参数含义 |
---|---|
toPackage | 你想要授权的目标应用,记住是目标应用 |
uri | 传递的 Uri |
modeFlags | 需要的临时授予的权限们 |
使用方法:
//判断版本是否是 7.0 及 7.0 以上
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) {
apkUri = FileProvider.getUriForFile(getActivity(), BuildConfig.APPLICATION_ID + ".fileProvider", apkFile);
//设置 intent 目标应用类型和传递的数据,这句要放在查询之前
intent.setDataAndType(apkUri,
"application/vnd.android.package-archive");
//查询所有符合 intent 跳转目标应用类型的应用
List<ResolveInfo> resInfoList = getActivity().getPackageManager().queryIntentActivities(intent, PackageManager.MATCH_DEFAULT_ONLY);
//然后全部授权
for (ResolveInfo resolveInfo : resInfoList) {
String packageName = resolveInfo.activityInfo.packageName;
getActivity().grantUriPermission(packageName, apkUri, Intent.FLAG_GRANT_WRITE_URI_PERMISSION | Intent.FLAG_GRANT_READ_URI_PERMISSION);
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
特别注意的地方:
我第一次测试使用这个方法的时候,报错了,报错信息是
java.lang.SecurityException: Permission Denial:
opening provider android.support.v4.content.FileProvider from ProcessRecord{cc3ad2316425:
com.android.packageinstaller/u0a21} (pid=16425, uid=10021) that is not exported from uid 10340
- 1
- 2
- 3
原因是我非常蠢地把 intent.setDataAndType() 放在了查询后面,所以 queryIntentActivities 没查到 com.android.packageinstaller
这个应用,也就没授权,大家使用的时候要注意顺序。
Intent.FLAG_ACTIVITY_NEW_TASK 的意义
Intent 的意思是意图,大白话翻译过来就是,定义即将要发生的动作。 使用 Intent ,可以在 Activity(前台页面), BroadcastReceiver(广播) 和 background Service (后台服务)之间做数据传递和其他交互。Flag 是 Intent 中扮演是辅助者的的角色,作用是添加相应的配置,让不同组件之间的交互更加方便。Android 也为 Intent 提供了很多 Flag, Intent 可以通过 setFlags() 或 addFlags() 添加一个或者多个 Flag,两个方法的区别上面说过了,这里就不啰嗦了。
Intent.FLAG_ACTIVITY_NEW_TASK 的含义是开启一个新的任务栈来装载目标页面。以这种方式启动activity,相当于目标 Activity 的 launchMode 属性设置 “singleTask” 。
注意如果试图从非 Activity 的非正常途径,比如从一个 Receiver 中启动一个 Activity,则 Intent 必须要添加 FLAG_ACTIVITY_NEW_TASK 标记。
如果是从 Activity 中跳转到 Activity ,会有以下效果。
写了一个小 Demo 测试,在 MainActivity 中通过 Intent 打开 SecondActivty,Intent 设置 FLAG_ACTIVITY_NEW_TASK。
Intent intent = new Intent(MainActivity.this,SecondActivity.class);
intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
- 1
- 2
- 3
- 4
测试结果如下:
1.如果 SecondActivity 在 AndroidManifest.xml 没有设置 Task Affinity,创建的 SecondActivity 的栈和 MainActivity 的栈一样。
2.如果 SecondActivity 在 AndroidManifest.xml 设置 Task Affinity 属性,SecondActivty 才会创建在一个新栈中。
Task Affinity 属性导致表现不同的原因是,当使用 singleTask 方式启动一个Activity 时, 系统首先会查找有没有 Task Affinity 相同的栈存在,如果有存在,直接压入栈,没有则会重新创建。当没有设置时,默认 Task Affinity 是 packageName,所有的 Activity 的 Task Affinity 都一样,于是表现和 Standard Mode 没有区别。
写在最后
遇到这个问题,觉得很奇怪,有点解释不通,其实归根结底也是自己太菜了而已,很对东西都不知道,copy & paste 在日常工作中是常态,但终究不是学习之道,功能实现完还是要回来找到真正原因才会安心,也能查漏补缺。
与诸君共勉,加油。
转载请注明出处:
未经允许不得转载:lxfamn » Android-7.0系统安装异常之解析包错误Permission Denial: