如果怀疑是sepolicy权限导致的问题，首先需要确认是否真的是权限导致的。
确认方法是：关闭SELinux，查看问题是否存在。
关闭SELinux的方法：
1、运行时关闭，重启失效：
adb shell setenforce 0
2、开机阶段关闭：
1）修改kernel cmdline：
androidboot.selinux=permissive
2）修改init代码：
selinux_is_enforcing函数返回false
SELinux常见问题-denied log
在kernel log、event log或main log中，搜索denied 关键字：
08-19 14:34:40.044160 1 1 E [ 27.054100].(1)[1:init]init: avc: denied { set } for property=sys.oppo.reboot pid=1608 uid=10013 gid=10013 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:system_prop:s0 tclass=property_service permissive=0
1、查看denied信息，显示platform_app domain无法对安全上下文u:object_r:system_prop:s0的属性进行设置操作；
2、在system/sepolicy/中找到platform_app domain的定义，一般在platform_app.te中即(domain名字).te中，查看是否有对应的neverallow以及是否与要添加的权限冲突；
3、查看vendor/oppo/sepolicy/common/目录是否有platform_app.te文件，如没有则新建该文件新建文件的命名规则是：以scontext的内容为名，添加对应的权限。
a）allow platform_app system_prop:property_service { set };
b）system_prop由文件安全上下文获取，property_service由tclass获取，对应的操作就不用说了。这里提一点，在system/sepolicy/te_macros中定义了相关操作的宏，可按需要查看。
4、remake system/sepolicy后再$OUT/obj/ ETC/sepolicy_intermediates/policy.conf文件中保存了临时生成的安全策略，可查看自己的修改是否已经生效。
SELinux常见问题-mls
有时发现如下的denied log：
07-13 10:03:38.042 5587 5587 W ndroid.incallui: type=1400 audit(0.0:4215): avc: denied { add_name } for name="Recordings" scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=0
在配置 allow platform_app system_data_file:dir add_name; 后，没有生效，这时候就是Mutil-Level Security（MLS）机制导致的操作被denied了。
配置：
type platform_app, domain, mlstrustedsubject; 即可
SELinux常见问题-ioctl
08-07 10:49:20.149 4795 4795 I iwpriv : type=1400 audit(0.0:3457): avc: denied { ioctl } for path="socket:[1607798]" dev="sockfs" ino=1607798 ioctlcmd=8bfc scontext=u:r:system_app:s0 tcontext=u:r:system_app:s0 tclass=udp_socket permissive=1
在setenfoce 0和配置allow system_app self:udp_socket ioctl; 后操作依然被denied，这是由于ioctl的控制在底层划分的更细，需要允许对应ioctlcmd操作。
具体方法为：
1、查找对应的ioctlcmd在ioctl_defines中的定义，如上文中的8bfc，对应的是SIOCIWFIRSTPRIV_1C
2、在对应的文件加入如下的配置：
allowxperm system_app self:udp_socket ioctl SIOCIWFIRSTPRIV_1C;
这样，在ioctl操作时，对应的ioctlcmd就会被允许了。
SELinux常见问题-新增app类型
当前系统中app的domain和文件类型默认的分配原则为：
1、platform签名 + share systemuid -> system_app + system_app_data_file；
2、platform签名 + 普通用户-> platform_app + app_data_file；
3、platform签名 + 特定用户 ： 如bluetooth，对应的domain为bluetooth + bluetooth_data_file
4、三方应用 -> untrusted_app + app_data_file
根据特性需求，需要新增app类型：
1、system/sepolicy/mac_permissions.xml
2、seapp_contexts
user=_app seinfo=theme name=com.nearme.themespace* domain=theme_app type=theme_app_data_file levelFrom=user
3、file.te
type theme_app_data_file, file_type, data_file_type;
4、theme_app.te
type theme_app, domain, mlstrustedsubject;
这样，签名是@THEME(定义在system/sepolicy/keys.conf文件)和包名是comthemespace的应用，domain是theme_app，对应的文件类型是theme_app_data_file
SELinux常见问题-新增、修改文件类型
如某些需求，需要新增文件类型，只允许特定的domain访问，如存放字体文件的目录，只允许主题应用写入和删除，其他domain只有读的权限。
1、file_contexts
/data/system/font(/.*)? u:object_r:font_data_file:s0
2、file.te
type font_data_file, file_type, data_file_type;
3、system/core/rootdir/init.rc
在restorecon_recursive /data之前加入：
mkdir /data/system/font 0777 system system
chmod 0777 /data/system/font
这样，adb shell ls -l -Z /data/system/font 查看到的就是上面配置的文件类型：
-rwxrwxrwx 1 u0_a18 u0_a18 u:object_r:font_data_file:s0:c512,c768 3553188 2017-08-19 16:40 Regular.ttf
SELinux常见问题-新增可执行程序和service
在/system/bin下新增可执行程序，以关键log的bin为例
1、file_contexts
/system/bin/criticallog u:object_r:criticallog_exec:s0
2、critical.te
type criticallog, domain;
type criticallog_exec, exec_type, file_type;
3、system/core/rootdir/init.rc
service criticallog /system/bin/criticallog
这样，init在启动这个criticallog service时，会根据对应的exec类型设置进程的domain，可以通过 adb shell ps –Z | grep criticallog 来确认：
u:r:criticallog:s0 system 484 1 17484 4220 binder_thr 72b6e2eaa8 S /system/bin/criticallog
SELinux常见问题-新增service、无对应的bin
在init.rc中新增service，但没有对应的bin，一般通过sh脚本启动一些功能。这类service，需要在配置rc时，加上seclabel操作，之后，init启动service时，就会根据这个关键字解析出对应的context。以screen_record service为例
1、system/core/rootdir/init.rc
service screen_record /system/bin/sh /autochmod.sh "screen_record”
…
seclabel u:r:screen_record:s0
2、screen_record.te
type screen_record, domain;
type screen_record_exec, exec_type, file_type;
init_daemon_domain(screen_record)
binder_use(screen_record)
allow screen_record shell_exec:file {read open execute_no_trans execute getattr entrypoint};
allow screen_record rootfs:lnk_file {getattr};
allow screen_record rootfs:file {read open};
allow screen_record system_file:file { read open execute_no_trans };
allow screen_record toolbox_exec:file { read open execute_no_trans execute getattr};
allow screen_record self:capability dac_override;
allow screen_record self:process execmem;
如上，新增service需要的默认权限在步骤2中，需要的时候拷贝、修改screen_record为对应的service即可。
SELinux常见问题-sepolicy-inject工具
常常有这样的困扰：selinux权限要加的太多，每次提示一条，都需要重新打包，很浪费时间！
现在有了sepolicy-inject工具，可以动态添加配置，不需要重复打包。
sepolicy-inject -s -t -c -p [,,,...] [-P ] [-o
以下的denied信息，就可以用sepolicy-inject工具动态配置好，最终打包一次就可以了。
01-01 08:01:57.902000 353 353 I auditd : type=1400 audit(0.0:2476): avc: denied { getattr } for comm="servicemanager" scontext=u:r:servicemanager:s0 tcontext=u:r:write_on:s0 tclass=process permissive=1
sepolicy-inject –s servicemanager –t write_on –c process –p getattr -l
由于权限的机制是有一个访问被阻止了，整个进程都会推出，因此每次可能只打印出一条denied信息，为了一次打印出尽量多的信息，可以adb shell setenforce 0之后执行，可以看到denied信息中最后permissive=1，只打印信息，不会阻止。这样就可以尽量多的得到denied信息了。
最终，所有sepolicy-inject动态添加的allow配置，都会记录在/data/seinfo.txt文件，配置完成后，将这个文件的内容复制到对应的TE文件即可。
] [-l|--load]