Figure

Hi 刚哥

■ 分析过程
02-03 03:05:57.189 806 8132 D sound_trigger_hw: handle_screen_status_change: screen off
02-03 03:06:05.798 806 8132 D sound_trigger_hw: handle_screen_status_change: screen on
->MTBF最后一次屏幕操作测试，正常

02-03 03:06:10.011 1220 1220 I PowerManagerService: Powering off display group due to power_button (groupId= 0, uid= 1000)...
02-03 03:06:10.011 1220 1220 I PowerManagerService: Going to sleep due to power_button (uid 1000)...
02-03 03:06:10.206 806 8132 D sound_trigger_hw: handle_screen_status_change: screen off
->收到power事件，熄灭屏幕

02-03 03:06:20 ->这个时间点, 获取当前的屏幕唤醒状态，并判断是否符合上次屏幕操作测试的结果，不符合则异常，由于03:06:10再次改变了状态，因此判断为异常

结合上述分析
1.根据MTBF脚本的逻辑，改变屏幕状态后2秒会获取屏幕的状态并判断是否异常，但是问题发生时，间隔15秒才判断，如果是状态变更2秒后就判断状态，则没有问题
2.屏幕是由于power键, 正常熄灭的

对于 03:06:10收到的power事件 是从哪儿来的 有如下可能原因
因为没有操作过实体power键，只有下面两种原因
①.power键，这个本身我们控制中心 有个熄屏的按钮 如果你们脚本有模拟点击的话，会达到这种效果
②.脚本的power事件传递，出现异常

■ 下一步计划
根据上述分析
1.根据MTBF脚本的逻辑，改变屏幕状态后2秒会获取屏幕的状态并判断是否异常，但是问题发生时，间隔15秒才判断，如果是状态变更2秒后就判断状态，则没有问题
-> 需要确认脚本本身是否运行异常
2.屏幕是由于power键, 正常熄灭的
①.power键，这个本身我们控制中心 有个熄屏的按钮 如果你们脚本有模拟点击的话，会达到这种效果
②.脚本本身运行出现异常
->无论是①还是②，都需要优化脚本操作

请确认，感谢

经讨论检查——仍然使用power键来唤醒。其长时间运行后，命令下发响应过慢，可能与python的缓存机制有关。使用将log重定向方式运行脚本，跑了16H，其命令下发比原发相比不会太慢，也没有复现该问题

后续继续跟踪，若再出现该问题，重新激活分析原因。
现在将其关闭