目录1 wakelock 是什么2如何使用wakelock3, 安卓系统中使用wakelock 的实例4, 实际项目中wakelock 遇到的问题1 wakelock 是什么Wake Lock是一种锁的机制只要有人拿着这个锁系统就无法进入休眠可以被用户态程序获取也可以被内核获得2如何使用wakelock3, 安卓系统中使用wakelock 的实例应用层使用wakelock 实例Android 使用wakelock示例_mob649e816138f5的技术博客_51CTO博客内核层wakelock 介绍Linux休眠唤醒之wakelock机制-CSDN博客Android应用申请wakelock示例 android wakelock 无效_lgmyxbjfu的技术博客_51CTO博客注意wakelock 使用一定要先设置权限。4, 实际项目中wakelock 遇到的问题1、客户MMI 测试sar sensor 校准app 层增加一个45度判断逻辑发现点击校准后app 命令无法下发到hal 层去执行校准逻辑返回err.具体报错03-09 18:37:18.072678 1320 1343 E HWMLIB : sar_start_static_calibration: enable cali err: -103-09 18:37:18.072848 1320 1343 E interfaces.factoryInterface-V1-service: sar_start_static_calibration error.03-09 18:37:18.073049 1320 1343 D HWMLIB : [RD] 3.4280 5.6140 3.0610 3428 5614 306103-09 18:37:18.073525 1320 1343 D interfaces.factoryInterface-V1-service: sar_get_static_calibration() 3.42800003-09 18:37:18.073734 1662 1885 WSensorService: Failed to write wake lock handled针对上述问题分析对app 层sar 校准开始前代码逻辑分析。根据客户反馈为了防止校准误操作客户应用层做了一个45度判断逻辑去掉这个逻辑后就可以通过adb 命令正常校准。根据推理问题出在45度角度判断地方。于是对这部分代码进行分析如下目前怀疑问题点wakelock 持锁超时后释放后向唤醒锁队列中写入输wakeevent报错导致1 地磁驱动问题2加速度驱动问题Debug 方法目前根据上层log 查看流程03-09 18:34:26.479404 6068 6068 D MMIGroup Sar-ap: Find test capsense: sx937x SAR03-09 18:34:26.480597 886 886 I ApFusion: batch: handle:2, flag:0,samplingPeriodNs:5000000 maxBatchReportLatencyNs:003-09 18:34:26.480764 1662 2667 I SensorService: actuating h/w activate handle0x3 enabled103-09 18:34:26.480861 886 886 I ApFusion: enable, handle:2, en:103-09 18:34:26.480979 886 886 IAccelerometer: batch: handle:0, flag:0,samplingPeriodNs:5000000 maxBatchReportLatencyNs:003-09 18:34:26.482531 886 886 I Accelerometer: enable: handle:0, en:103-09 18:34:26.484313 886 886 I Magnetic: batch: handle:1, flag:0, samplingPeriodNs:20000000,maxBatchReportLatencyNs:003-09 18:34:26.486435 886 886 I Magnetic: enable: handle:1, en:103-09 18:34:26.495355 886 886 IAccelerometer: batch: handle:0, flag:0,samplingPeriodNs:4000000 maxBatchReportLatencyNs:003-09 18:34:26.495869 1662 3835 I SensorService: actuating h/w activate handle0x1 enabled103-09 18:34:26.497299 1662 3835 I SensorService: actuating h/w activate handle0x2 enabled103-09 18:34:26.498852 6068 6068 D MMIGroup MMIGroupApplication: onActivityStarted:com.factory.mmigroup.sensoritem.Sard92de74根据上述log 我们可以看到设置加速的batch 设置两次第一次是5ms 第二次是4ms, 于是对应scp 中的log 查看发现会出现20ms的samplerate且加速度数据上报速率也是很混乱和设置的sample rate 完全不匹配。行134908: [263.481]sensorRateAcc rate:51200, latency:20000000行 134916: [263.481]sensorRateAcc rate:51200, latency:20000000行 137011: [264.055]sensorRateAcc rate:409600, latency:3999744行 137019: [264.055]sensorRateAcc rate:409600, latency:3999744行 138207: [272.531]sensorRateAcc rate:51200, latency:20000000行 138221: [272.532]sensorRateAcc rate:51200, latency:20000000行 139484: [272.720]sensorRateAcc rate:204800, latency:4999168行 139494: [272.721]sensorRateAcc rate:204800, latency:4999168行 149989: [279.311]sensorRateAcc rate:51200, latency:20000000行 150009: [279.312]sensorRateAcc rate:51200, latency:20000000行 151117: [279.638]sensorRateAcc rate:204800, latency:4999168行 151135: [279.638]sensorRateAcc rate:204800, latency:4999168行 159468: [283.646]sensorRateAcc rate:51200, latency:20000000行 159510: [283.653]sensorRateAcc rate:51200, latency:20000000行 188323: [289.540]sensorRateAcc rate:204800, latency:4999168行 188341: [289.541]sensorRateAcc rate:204800, latency:4999168行 188453: [289.551]sensorRateAcc rate:409600, latency:3999744加速度数据行 93307: [242.971]mir3da ReportData_xyz[-4.261254, -1.493458, 9.030869].行 93311: [242.971]mir3da ReportData_xyz[-4.385757, -1.455149, 9.107486].行 93315: [242.971]mir3da ReportData_xyz[-5.218969, -1.416841, 9.155372].行 93375: [242.979]mir3da ReportData_xyz[-5.324317, -1.388109, 9.203258].行 93419: [243.092]mir3da ReportData_xyz[-2.738487, -1.857390, 5.870409].行 93423: [243.092]mir3da ReportData_xyz[-2.824682, -1.943584, 6.607850].行 93427: [243.092]mir3da ReportData_xyz[-2.930030, -2.020201, 6.665312].行 93431: [243.092]mir3da ReportData_xyz[-3.734511, -2.106396, 6.703621].行 93553: [243.152]mir3da ReportData_xyz[-0.449549, -5.142352, 6.789815].行 93557: [243.152]mir3da ReportData_xyz[-0.449549, -5.180660, 6.770661].行 93561: [243.152]mir3da ReportData_xyz[-0.449549, -5.209392, 6.770661].行 93565: [243.152]mir3da ReportData_xyz[-0.478280, -5.238123, 6.780238].行 93637: [243.160]mir3da ReportData_xyz[-0.526166, -5.238123, 6.799393].行 93641: [243.161]mir3da ReportData_xyz[-0.583629, -5.238123, 6.799393].行 93673: [243.192]mir3da ReportData_xyz[-2.815104, -4.797574, 7.5000401 evtdata:2行 93705: [243.252]mir3da ReportData_xyz[-1.129526, -6.T行 93741: [243.292]mir3da ReportData_xyz[-1.397686, -6.990741, 7.431484].行 93745: [243.292]mir3da ReportData_xyz[-1.378532, -6.990741, 7.421907].行 93749: [243.292]mir3da ReportData_xyz[-1.378532, -6.981164, 7.421907].行 93753: [243.292]mir3da ReportData_xyz[-1.368955, -6.962010, 7.421907].行 93845: [243.352]mir3da ReportData_xyz[-1.493458, -3.887745, 7.364444].行 93849: [243.352]mir3da ReportData_xyz[-1.493458, -3.859014, 7.335713].行 93853: [243.352]mir3da ReportData_xyz[-1.483881, -3.830282, 7.306982].行 93857: [243.352]mir3da ReportData_xyz[-1.483881, -3.801551, 7.287827].行 93929: [243.361]mir3da ReportData_xyz[-1.455149, -3.782397, 7.239942].根据上述对加速度数据分析方法同样对地磁数据也做了分析发现地磁也有类似的问题于是又进一步对该问题进确认通过Qsensortest.apk 把加速度和地磁数据分别设置为200ms 和 50ms 发现加速度数据上报的速率也是混乱的和app设置的完全不匹配地磁则没有问题。于是根据推理可能是加速度问题导致地磁驱动数据上报速率混乱。验证方法交叉验证把sar 校准可以测pass 的手机的加速度芯片换到测测试fail的手机上验证多次测试发现可以测pass.但关于Failed to write wake lock handled这个报错仍然存在的测pass log 地磁数据上报速率大部分一直但也有不一致的。目前虽然sar 正常校准pass 了目前怀疑这个时间戳可能是Failed to write wake lock handled报错的原因已提case 给平台等待平台解答。