分享bug历程：无法进recovery

现象：机台无法进recovery，长按power key也无法进系统

recovery没有成功启动，misc分区的内容自然不会被清除，下次开机仍会进recovery，导致无法开机

查看log发现recovery进程反复被signal 13 kill掉（signal 13 broken pipe管道破裂，通常是读端已关闭连接导致管道内容无法被读取）。其间有selinux报关于logfile的读写错误，于是做以下实验：

①将所有关于asdf log读写的部分code都注释掉    =》可以进recovery

②二分法查找导致fail的code

③找到后发现其实现函数果然有关于管道读写的内容，父进程将输入log写人管道，子进程读取管道内容并重定向到asdf的log中。但是打开asdf log文件失败，于是关闭管道。

打开失败是因为有selinux在挡

error log:

(CPU:4-pid:1:init) init: Starting service 'recovery'...
[   13.370392] (CPU:4-pid:1:init) dpNotify: D+ Notify called. Rerun_APSD
[   13.375095] (CPU:6-pid:439:recovery) audit: type=1400 audit(3592.749:6): avc:  denied  { search } for  pid=439 comm="recovery" name="recovery" dev="mmcblk0p39" ino=16 scontext=u:r:recovery:s0 tcontext=u:object_r:log_file:s0 tclass=dir permissive=0
[   13.397789] (CPU:4-pid:212:wk:asus_sdp_de) SMBCHG: rerun_apsd: Waiting on rising usbin uv
[   13.398464] (CPU:6-pid:1:init) init: Starting service 'adbd'...
[   13.406343] (CPU:6-pid:441:usb ffs open) read descriptors
[   13.406358] (CPU:6-pid:441:usb ffs open) read strings
[   13.412828] (CPU:6-pid:438:recovery) EXT4-fs (mmcblk0p20): mounted filesystem with ordered data mode. Opts: barrier=1,data=ordered
[   13.415229] (CPU:6-pid:438:recovery) recovery (438) used greatest stack depth: 10992 bytes left
[   13.415430] (CPU:7-pid:1:init) init: Service 'recovery' (pid 438) killed by signal 13
[   13.415448] (CPU:7-pid:1:init) init: Service 'recovery' (pid 438) killing any children in process group

④But此问题是不是必发，为什么有的机台挡而有的机台不挡呢？

根据selinux问题去看两者asdf的selinux上下文，发现针对recovery目录的file contexts不同：

u:object_r:unlabeled:s0 asdf/recovery 

u:object_r:log_file:s0  asdf/recovery 

若将/asdf/recovery目录删掉，在Android O中重启进recovery时会再次创建这个目录，创建后其contexts便是log_file；

                                                而Android N中创建后其contexts为unlabeled

查看差异发现Android O中对asdf目录有统一定义：/asdf(/.*)?                     u:object_r:log_file:s0；

而Android N中对asdf没有定义故创建出便是unlabeled

所有发现问题复制手法：N的机台在没有进过recovery的情况下直接通过UL/FOTA升级O，之后进recovery，然后回退N；如此asdf/recovery便是log_file类型

⑤解决办法：

单独定义/asdf/recovery的contexts为unlabeled，在recovery的rc文件中使/asdf/recovery递归继承其contexts