正所谓软件出错不可怕，出错不报错就可怕了。只要看到日志中有报错信息都是有迹可循的。
继Android KK 4.4 版本后，Google 默认启用了SELinux, 并会把SELinux 审查异常打印在kernel log 或者 android log(L版本)中，对应的关键字是: "avc: denied" 或者"avc: denied"
1.问题现象：
为了防止大家赖得放大图片我把报错信息再贴出来。avc.txt
avc: denied { create } for name="hsdi_tmp" scontext=u:r:system_app:s0 tcontext=u:object_r:protect_f_data_file:s0 tclass=dir permissive=0
avc: denied { create } for name="hsdi_tmp" scontext=u:r:system_app:s0 tcontext=u:object_r:protect_f_data_file:s0 tclass=dir permissive=0
avc: denied { create } for name="hsdi_tmp" scontext=u:r:system_app:s0 tcontext=u:object_r:protect_f_data_file:s0 tclass=dir permissive=0
avc: denied { create } for name="hsdi_tmp" scontext=u:r:system_app:s0 tcontext=u:object_r:protect_f_data_file:s0 tclass=dir permissive=0
avc: denied { create } for name="hsdi_tmp" scontext=u:r:system_app:s0 tcontext=u:object_r:protect_f_data_file:s0 tclass=dir permissive=0
avc: denied { create } for name="hsdi_tmp" scontext=u:r:system_app:s0 tcontext=u:object_r:protect_f_data_file:s0 tclass=dir permissive=0
avc: denied { create } for name="hsdi_tmp" scontext=u:r:system_app:s0 tcontext=u:object_r:protect_f_data_file:s0 tclass=dir permissive=0
avc: denied { create } for name="hsdi_tmp" scontext=u:r:system_app:s0 tcontext=u:object_r:protect_f_data_file:s0 tclass=dir permissive=0
avc: denied { create } for name="hsdi_tmp" scontext=u:r:system_app:s0 tcontext=u:object_r:protect_f_data_file:s0 tclass=dir permissive=0
这里有一个小技巧，有用则取之，无用嘛那就自动略过。
首先是查看kernel日志
adb shell
dmesg
查看整个kernel 日志
logcat | grep avc
或者
dmesg | grep avc
这两个是通过对kernel 日志过滤一遍把avc关键字给打印出来。
当然了你也可以直接打印到某个文件里面去。
dmesg | grep avc >d:\kernel.txt
如果觉得自己的APK出错的原因是因为android5.0的权限问题可以使用以下命令暂时的使权限检测系统失效
setenforce 0
但是目前系统必须是有root权限的系统。而且这个使权限失灵的属性重启之后就会还原的。
如果执行完这个命令之后你的应用已经不报错了，那恭喜你 你已经找到了问题所在。
2.解决方案：
首先将我们的报错avc日志拷出来做成一个avc.txt放在Ubuntu系统下面在终端中运行以下命令生成的avc.te文件就是我们的解决方法了。
Audit2allow –i avc.txt >avc.te
avc.txt
avc: denied { create } for name="hsdi_tmp" scontext=u:r:system_app:s0 tcontext=u:object_r:protect_f_data_file:s0 tclass=dir permissive=0
avc: denied { create } for name="hsdi_tmp" scontext=u:r:system_app:s0 tcontext=u:object_r:protect_f_data_file:s0 tclass=dir permissive=0
avc: denied { create } for name="hsdi_tmp" scontext=u:r:system_app:s0 tcontext=u:object_r:protect_f_data_file:s0 tclass=dir permissive=0
avc: denied { create } for name="hsdi_tmp" scontext=u:r:system_app:s0 tcontext=u:object_r:protect_f_data_file:s0 tclass=dir permissive=0
avc: denied { create } for name="hsdi_tmp" scontext=u:r:system_app:s0 tcontext=u:object_r:protect_f_data_file:s0 tclass=dir permissive=0
avc: denied { create } for name="hsdi_tmp" scontext=u:r:system_app:s0 tcontext=u:object_r:protect_f_data_file:s0 tclass=dir permissive=0
avc: denied { create } for name="hsdi_tmp" scontext=u:r:system_app:s0 tcontext=u:object_r:protect_f_data_file:s0 tclass=dir permissive=0
avc: denied { create } for name="hsdi_tmp" scontext=u:r:system_app:s0 tcontext=u:object_r:protect_f_data_file:s0 tclass=dir permissive=0
avc: denied { create } for name="hsdi_tmp" scontext=u:r:system_app:s0 tcontext=u:object_r:protect_f_data_file:s0 tclass=dir permissive=0
运行Audit2allow 工具之后得到的avc.te文件
avc.te
#============= system_app ==============
allow system_app protect_f_data_file:dir create;
前面的#============= system_app ==============
就是在告诉你在那个文件里面，你可以找到你们系统真正起作用的system_app.te文件是那个目录的。然后在文件的末尾处添加里面的那句话
allow system_app protect_f_data_file:dir create;
注意 这个权限问题是要一个个慢慢来的，也就是说你这个权限加了 等会你运行进去还有可能出现其他的权限问题。这就需要大家要有耐心慢慢的去一个个加好。
有的时候权限明明加进去了却还是报相同的错误 这个时候你就得检查你是否加对地方了。
把你编译的这个文件拷贝出来
out/target/product/angler/obj/ETC/sepolicy.recovery_intermediates/policy_recovery.conf
看看你加的权限究竟有没有在这里面能找得到。
我只能帮你到这了。