当前位置：首页 > news >正文

安卓wakelock 学习

news 2026/5/12 7:10:14

1， wakelock 是什么

2，如何使用wakelock

3, 安卓系统中使用wakelock 的实例

4, 实际项目中wakelock 遇到的问题

1， wakelock 是什么

Wake Lock是一种锁的机制，只要有人拿着这个锁，系统就无法进入休眠，可以被用户态程序获取也可以被内核获得

2，如何使用wakelock

3, 安卓系统中使用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: -1
03-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 3061
03-09 18:37:18.073525 1320 1343 D interfaces.factoryInterface-V1-service: sar_get_static_calibration() 3.428000
03-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 SAR
03-09 18:34:26.480597 886 886 I ApFusion: batch: handle:2, flag:0,samplingPeriodNs:5000000 maxBatchReportLatencyNs:0
03-09 18:34:26.480764 1662 2667 I SensorService: >>> actuating h/w activate handle=0x3 enabled=1
03-09 18:34:26.480861 886 886 I ApFusion: enable, handle:2, en:1
03-09 18:34:26.480979 886 886 IAccelerometer: batch: handle:0, flag:0,samplingPeriodNs:5000000 maxBatchReportLatencyNs:0
03-09 18:34:26.482531 886 886 I Accelerometer: enable: handle:0, en:1
03-09 18:34:26.484313 886 886 I Magnetic: batch: handle:1, flag:0, samplingPeriodNs:20000000,maxBatchReportLatencyNs:0
03-09 18:34:26.486435 886 886 I Magnetic: enable: handle:1, en:1
03-09 18:34:26.495355 886 886 IAccelerometer: batch: handle:0, flag:0,samplingPeriodNs:4000000 maxBatchReportLatencyNs:0
03-09 18:34:26.495869 1662 3835 I SensorService: >>> actuating h/w activate handle=0x1 enabled=1
03-09 18:34:26.497299 1662 3835 I SensorService: >>> actuating h/w activate handle=0x2 enabled=1
03-09 18:34:26.498852 6068 6068 D MMIGroup MMIGroupApplication: onActivityStarted:com.factory.mmigroup.sensoritem.Sar@d92de74

根据上述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 给平台，等待平台解答。

查看全文

http://www.jsqmd.com/news/473758/