目前遇到的sensor功耗问题主要包括以下几类: 待机功耗：

• SSC子系统异常导致系统无法进入AOSD
• SSC子系统异常导致频繁唤醒AP
• SSC子系统的GPIO/PMIC配置错误导致系统漏电

运行功耗：

• SSC子系统的sensor工作模式异常，导致系统功耗增加
• Android上层服务未正常关闭sensorservice，导致系统功耗增加

在sensor在功耗问题的分析中，sensor自身工作行为所产生的耗电是非常小的，大多数功耗问题都是由SSC（Snapdragon Sensor Core）子系统异常或Android异常调用上层服务sensorservice引起。

不同类型的sensor功耗问题有不同的分析方法。以下是各种类型的一些通用分析方法sensor分析功耗问题.

1.首先要确认系统待机时是否存在SSC子系统无法进入sleep系统无法进入AOSD，可通过以下命令查看各个子系统的sleep count： 命令:

adb shell cat /sys/power/rpmh_stats/master_stats     

输出如下:

APSS Version:0x1 Sleep Count:0x2bf90 Sleep Last Entered At:0x48e7ec7af00 Sleep Last Exited At:0x48e7ecfe85e Sleep Accumulated Duration:0x42b29deb96a 

ADSP Version:0x1 Sleep Count:0xf17 Sleep Last Entered At:0x48a16986465 Sleep Last Exited At:0x48a16980931 Sleep Accumulated Duration:0x487a6e075f7 

CDSP Version:0x1 Sleep Count:0x55 Sleep Last Entered At:0x1f39e3aadeb Sleep Last Exited At:0x1f39e3a6d3b Sleep Accumulated Duration:0x48e5fed220c 

SLPI Version:0x1 Sleep Count:0x1e341a Sleep Last Entered At:0x48e7ed80b48 Sleep Last Exited At:0x48e7ed76c90 Sleep Accumulated Duration:0x473b8551197 

1.分析待机时的bugreport日志，通过以下内容log确认SSC子系统多次唤醒AP：

All wakeup reasons: Wakeup reason Abort:Last active Wakeup Source: SensorService_wakelock, handle processSensorService: 16m 50s 349ms (1025 times) realtime Wakeup reason Abort:Wakeup IRQ detected during suspend: 103qcom,glink-smem-native-xprt-dsps: 2m 7s 108ms (126 times) realtime 

2.确认是否为sensor的使用导致SSC子系统异常可采用以下方法disable AP子系统与SSC确认子系统的通信： 命令:

adb shell mv /vendor/lib64/libssc.so/vendor/lib64/libssc.so.bk adb shell mv /vendor/lib/libssc.so/vendor/lib/libssc.so.bk adb shell sync adb reboot 

3.若AP频繁唤醒是原因sensor使用造成的，通过下列命令找出系统灭屏时正在使用的sensor，并通过排除法确定AP唤醒的sensor 命令:

adb shell dumpsys sensorservice 

4.检查是否有上层服务。sensor配置错误Wakeup模式，导致AP例如：

Connection Number: 4 Operating Mode: NORMAL com.qualcomm.qti.internal.telephony.DynamicSarController | WakeLockRefCount 0 | uid 1001 | cache size 0 | max cache size 0 sar_detector Non-wakeup 0x0000001e | statu: active | pending flush events 0
SAR ADUX1050 Wakeup0x00000025 | status: active | pending flush events 0
Hall Effect Sensor 0x00000034 | status: active | pending flush events 0

在以上log中，由于modem服务将SAR sensor异常设置成了Wakeup模式，导致SAR sensor每隔1s就会频繁唤醒AP

5.若上层服务的sensor配置没有问题，但系统还是存在频繁的AP唤醒，就需要sensor team检查是否为SSC子系统在使用sensor时出现异常，导致AP频繁唤醒。

如：之前遇到的安装微信及QQ后，系统会频繁上报SSC中断，导致AP无法睡眠，经分析是由于微信及QQ同时使用了Non-wakeup pedometer，导致大量sensor中断产生。 但其本质原因是由于SensorHub问题导致Non-wakeup sensor会异常唤醒AP。

1.分析GPIO/PMIC的漏电问题是在系统已经成功进入AOSD以后，此时各个子系统都已成功进入sleep，故很难从各subsystem看出问题

2.这时最简单的办法就是通过Trace32来dump系统进入AOSD之前的GPIO/PMIC状态，检查各GPIO/PMIC是否存在漏电

3.但有时由于条件所限在无法使用Trace32工具的情况下，就需要对比出问题前后的两个版本，从regression的角度来找出漏电

1.sensor的工作模式异常导致的功耗问题主要出现在系统运行时，指可以使用interrupt mode的sensor被SSC子系统异常配置成了polling mode，导致功耗增大

2.分析方法主要是先通过dumpsys sensorservice找出系统使用了哪些sensor？再检查哪些sensor可以被配置成interrupt mode

3.若确认相应sensor可以工作在interrupt mode，却异常配成了polling mode，则找sensor team帮忙修正