selinux 是如何导致开机进入recovery的

截取log的异常部分。

疑点1. 可以看出是某critical的service被kill了4次in 4min，从而触发系统自动进入recovery。

疑点2. 系统在访问部分节点时，没有权限？

撸一遍init.cpp的代码：

问题在以下这个函数

简单记录下：

此函数是init在等待ueventd冷启动完成，如果超时，init就直接启动了。

在ueventd里有很多设备节点创建及改变selinux context的操作，通过加log最终确定，

由于selinux变更context太过耗时，导致此函数超时。

于是在init启动后续service时，设备节点的context还没初始化完成就被别人初始化了一个错误的context。于是有了"疑点1"的异常

也导致了service的启动失败，由于context已经错了，所以service不断失败，从而导致重启进入recovery

而selinux初始化耗时的根本原因就是写在device/*/*.te里的各种selinux规则，由于通配符过多，selinux遍历时间太长而耗时.

通过优化sepolicy规则后，解决。

同时还有一点：android9之后，init等待的超时改为60s，也进一步降低了超时风险.