首先:请上层应用确认,目前手机按键上对应的LED灯叫什么名字。因为我们的驱动中以及PCB中对这三个灯的命名为 led-keyboard。而上层对灯的分类比较多了:
参考:hardware/libhardware/include/hardware/lights.h
39 #define LIGHT_ID_BACKLIGHT "backlight"
40 #define LIGHT_ID_KEYBOARD "keyboard"
41 #define LIGHT_ID_BUTTONS "buttons"
42 #define LIGHT_ID_BATTERY "battery"
43 #define LIGHT_ID_NOTIFICATIONS "notifications"
44 #define LIGHT_ID_ATTENTION "attention"
45 #define LIGHT_ID_FLASHLED "flashled"
驱动中把这几个灯叫什么无关紧要,反正在HAL层中我们需要重新去映射他们,在这里我只是想说明,千万不要光看名字去对号入坐,因为没人去保证他们的一致性,入乡随俗才是正道!
果然上层多这几个LED的名字是light_buttons。
记住一点,任何时候都不要让上层适应底层!上层说这是buttons light,那我们就要说,这是对的。然后我们悄悄地把自己的keyboard light 穿个写着buttons light的马甲!
在确认了HAL层工作正常后,一直怀疑上层的调用逻辑可能存在问题,再和上层同事一同调查后认为,上层原生逻辑没有问题, 今天测试人员说这个bug解决了。疑惑,最后跟踪kernel的最新提交发现在kernel仓库的新提交中early suspend 功能被打开(以前一 直是关闭状态),而驱动kernel/drivers/leds/leds-XXXX- kb.c在earlysuspend时会关闭这三个灯。因此,从用户角度看,这三个灯好像OK了。这样的流程类似于将背光灯和这几个LED灯捆绑在了一 起。因为进入early suspend时总会关闭背光和这几个LED。现在就用这样的逻辑吧。因为既然google在上层没有动作,那一定有他的道理。google可能真的认为背光和buttons light就应该被绑在一起吧。