-
上下文定义
标准的label取名方式是需要被遵守的，因为很多宏里面就直接用了。。
hwservice_contexts
这里标注的是使用
hwbinder的服务通信的接口标准的label取名方式是以
_hwservice结尾hwbinder是框架与供应商内容之间的ipc通信模块同理，还有个
vndbinder，是供应商内容之间的ipc通信模块Android 8 之后，原先的
binder只适用于框架内通信service_contexts
这里记录的是注册/寻找 binder service 的时候的key
对应到的是ServiceManager.addService(String name, IBinder service)publishBinderService(String name, IBinder service)ServiceManager.getService(String name)
中的name标准的label取名方式是以
_service结尾file_contexts / genfs_contexts
它们都是用来指定文件的上下文标签
一般来说，file_contexts用来指定那些inode能够保存上下文信息的文件系统 的 文件上下文
比如system和vendor分区
这些上下文被应用的时机是打包生成镜像的时候genfs_contexts则一般用来记录诸如/sys、/proc这样的没有inode的文件系统的 上下文信息genfs_contexts被应用的时机是在开机时但是，有一种特殊情况，那就是由于
genfs_contexts并不支持正则匹配，因此某些需要正则匹配的/sys或者/proc内容依然会被放到file_contexts中，这些内容的应用时机也是在开机时标准的label取名方式：
- 可执行文件 以
_exec结尾 - 其它文件，按需 或 按照
system/sepolicy中的某些已经type的东西进行定义
宏定义
hal_attribute(<hal_name>)
用来定义三个
attribute
分别是hal_<hal_name>hal_<hal_name>_clienthal_<hal_name>_server但是在device tree中直接使用这个宏会导致大规模的neverallow错误，第三方有个workaround
https://review.lineageos.org/c/LineageOS/android_device_lineage_sepolicy/+/286541
暂时还不明白原理hal_client_domain(, <hal_type>)
将
<domain>定义为<hal_type>_clienthal_server_domain(, <hal_type>)
将
<domain>定义为<hal_type>_serverdomain_auto_trans(, , )
当
<olddomain>执行label为<type>的文件时，自动转换进程的domain为<newdomain>init_daemon_domain()
这是对上面那个宏的进一步封装
当init进程（domain为init的进程）执行被label为<domain>_exec的文件时，自动转换进程domain为<domain>这是非常常用且重要的一个宏，在为新的可执行文件配置sepolicy的时候必然会用到
从这里可以看出按照标准进行命名的重要性了吧
- 可执行文件 以
-
binder_use / vndbinder_use / hwbinder_use ()
允许
<domain>使用不同种类的binder如果一个服务需要使用binder进行通信（包括向对应service manager注册服务），则需要进行此声明
注意：对于使用
hwbinder的服务，如果已经为其定义了hal_server_domain或hal_client_domain，则无需再声明hwbinder_use，原因是上述两个宏会自动将<domain>标注为halserverdomain，从而间接获得hwbinder的使用权限binder_call(, )
允许
<clientdomain>向<serverdomain>发起binder IPC通信add_hwservice(, )
允许
<domain>向hwservice manager注册<service>接口<service>接口的具体信息定义在hwservice_contexts中它会自动生成
neverallow规则，不再允许别的服务注册这一接口hal_attribute_hwservice(, )
这是对上面那个宏的进一步封装
它调用add_hwservice(<attribute>_server, <service>)
并允许<attribute>_client向hwservice manager搜索这个服务
它会自动生成neverallow规则，不再允许非_server或_client的domain注册或查找服务说白了，允许服务端增加服务接口，允许客户端查找获取服务
很显然，它是需要与
hal_attribute、hal_client_domain、hal_server_domain配合使用的又是一个规范命名的重要性？ -
流程
常见的，套路？
一般可执行文件
- 创建两个
type。一个作为可执行文件执行时的domain，另一个则是给可执行文件的本体使用（<domain>_exec） - 在
file_contexts中，为可执行文件本体打上<domain>_exec的type - 使用
init_daemon_domain来实现执行可执行文件时自动切换domain（否则所有的scontext都会为init） - 根据其所需权限，为其撰写规则
HIDL HAL
- HAL本身是可执行文件，因此在可执行文件的基础上进行
- 配置
hwservice_contexts，声明HAL的接口 - 额外声明
hal_attribute，即hal本体、_server和_client的attribute - 使用
hal_server_domain将上述“一般可执行文件”中的domain定义为server - 将使用HAL的对象定义为
hal_client_domain - 使用
add_hwservice允许server增加服务 - 使用
binder_call允许server和client之间进行通信 - link: https://blog.xzr.moe/archives/111/
- 创建两个