Android power consumption (24) --- no standby analysis

How to determine what is preventing entry to suspend

The system does not enter suspend, the main reason is because the system has a lock.

Locks are generally divided into: APP takes the lock through PowerManager, and kernel wakelock.

1 Analyze the problem of upper-level lock holding:

At present, the log of PowerManagerService will not be opened by default, which can be modified by:

/frameworks/base/services/core/java/com/android/server/power/PowerManagerService.java

    private static final boolean DEBUG = true;
    private static final boolean DEBUG_SPEW = DEBUG && false;
change into:
    private static final boolean DEBUG = true;
    private static final boolean DEBUG_SPEW = true;
Open the upper log

Through syslog: search keyword: total_time= to determine the lock holding time.

PowerManagerService: releaseWakeLockInternal: lock=31602562 [*job*/DownloadManager:com.android.providers.downloads], flags=0x0, total_time=600051ms

Or use the regular expression: total_time=[\d]{4,}ms to filter out the locks that hold the lock for a long time.

PowerManagerService: releaseWakeLockInternal: lock=31602562 [*job*/DownloadManager:com.android.providers.downloads], flags=0x0, total_time=600051ms
PowerManagerService: releaseWakeLockInternal: lock=56317918 [*job*/DownloadManager:com.android.providers.downloads], flags=0x0, total_time=283062ms
PowerManagerService: releaseWakeLockInternal: lock=216012597 [AudioMix], flags=0x0, total_time=120003ms
PowerManagerService: releaseWakeLockInternal: lock=41036921 [AudioMix], flags=0x0, total_time=167984ms
PowerManagerService: releaseWakeLockInternal: lock=70859243 [GsmInboundSmsHandler], flags=0x0, total_time=3206ms
PowerManagerService: releaseWakeLockInternal: lock=242046348 [AudioMix], flags=0x0, total_time=122205ms


2 kernel lock

The kernel lock will not be printed out by default, it is usually acquired through the node after the standby is over:

adb shell  cat /sys/kernel/debug/wakeup_sources >  wakeup_sources.log

active_count: The number of times the wakeup source was activated.
event_count: The number of times the wakeup source was awakened.  Wakeup_count 
: The number of times the suspend was aborted  . It is the same (kernel monotonically increasing time).  total_time: the total active time of the corresponding wakeup source.  max_time: the longest time the corresponding wakeup source has been active continuously.  last_change: the time of the last wakeup source change (from lock to release or release) To hold the lock), the time unit is the same as the kernel log prefix time (kernel monotonically increasing time).  prevent_suspend_time: The total accumulated time corresponding to the wakeup source to prevent entering autosleep.





一般情况下:
如果是复现机,前面没有捉log,也没有dump log,只有一份wakeup_sources.log
可以看下prevent_suspend_time,一般时间越大越可能是阻止系统进入suspend的wakeup sources.

如果测试前后,都有捉 wakeup_sources.log 请对两份wakeup_sources.log的total time的差值.
差值时间跟灭屏的时间对得上,一般就是这个锁引起的问题.

把捉出来的wakeup_sources.log复制到excel表格中,比较好对齐,一个是比较好计算.

其中dispsys_wakelock total_time的时间有697614mS 也就是总共有697s.

 

或者在待机测试结束后通过命令:

adb bugreport > bugreport.txt

搜索关键:

底层的锁:
All kernel wake locks: 
Kernel Wake lock ttyC0 : 1h 33m 15s 668ms (3856 times) realtime 
Kernel Wake lock radio-interface: 1h 20m 56s 210ms (3995 times) realtime 
Kernel Wake lock ccci3_at : 1h 9m 43s 491ms (2932 times) realtime 
Kernel Wake lock ccci_fs : 1h 0m 52s 818ms (3432 times) realtime 
Kernel Wake lock ccci3_at2 : 41m 16s 938ms (2465 times) realtime

上层的锁:
All partial wake locks: 
Wake lock 1001 RILJ: 5m 29s 768ms (13118 times) realtime 
Wake lock 1000 *alarm*: 4m 7s 823ms (2330 times) realtime 
Wake lock 1000 ConnectivityService: 59s 513ms (1 times) realtime 
Wake lock u0a111 *alarm*: 50s 334ms (751 times) realtime 
Wake lock u0a111 WakerLock:999603354: 28s 655ms (125 times) realtime 
Wake lock 1000 NetworkStats: 11s 434ms (569 times) realtime


Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325430971&siteId=291194637