Android 功耗问题debug处理(主要是睡眠时“大”电流问题的debug方法示例)
2016-11-11 11:39
375 查看
1. 在手机进入sleep后,被上层apk唤醒的debug方法
请抓取相应的待机的mobilelog,
从kernel_log中分析,
如果log中可以查找到
wake up by RTC
请在相应的main_log中查找关键字
Alarm triggering, 其后面对应的type 0, type 2所对应的APk就是唤醒系统的唤醒源,
例如:
从log 上看,问题是由于系统被alarm type 为0 & 2 的APK唤醒,分别为com.android.phone&com.google.android.gsf
01-03 13:47:52.018 653 699 V AlarmManager: Native set alarm :Alarm{41e4d570 type 2 com.android.phone}
01-03 13:47:59.056 653 699 V AlarmManager: Native set alarm :Alarm{42041000 type 2 com.google.android.gsf}
01-03 13:48:52.076 653 699 V AlarmManager: Native set alarm :Alarm{421dec08 type 2 com.android.phone}
01-03 13:48:58.264 653 699 V AlarmManager: Native set alarm :Alarm{41c04b80 type 0 com.google.android.gsf}
01-03 13:48:58.358 653 885 V AlarmManager: Native set alarm :Alarm{42007638 type 0 com.google.android.gsf}
01-03 13:48:59.090 653 699 V AlarmManager: Native set alarm :Alarm{41d47db8 type 2 com.google.android.gsf}
而release wakelock后(系统还是awake state),也会看到com.dewav.timewidget去要带有wakelock的clock, 请您去掉看看
01-03 13:49:00.355 1015 1015 V AppWidgetContext: package name: com.dewav.timewidget
01-03 13:49:00.355 1015 1015 V AppWidgetContext: context permission not changed
01-03 13:49:01.168 653 699 V AlarmManager: Native set alarm :Alarm{41e02628 type 2 com.android.phone}
2. 而对于一些与modem相关的debug,需要结合kernel log/ radio log/net log/modem log来结合分析
在kernel中发现被唤醒的时间点,可以通过以下方式将kernel log和上层的时间点联系起来,在kernel log中搜索UTC(可能
在客户端抓取的话,需要时区转换)
在kernel中搜索CPU WAKE UP关键字,可以找到对应的时间点,在结合上图经过转换后,得到上层的时间。
若是在kernel log中发现,而main log中没有发现异常
<4>[ 281.333369]-(0)[5:kworker/u:0][PCM WAKEUP NORMAL]CPU WAKE UP BY: CCIF
<5>[ 281.333369]-(0)[5:kworker/u:0][Power/Sleep] slp_abort_cnt:0,slp_normal_cnt:12
<7>[ 281.333702] (0)[5:kworker/u:0]enable(1), count(1) res=0
<7>[ 281.334564] (0)[5:kworker/u:0]enable(0), count(0) res=0
<4>[ 281.334574] (0)[5:kworker/u:0]usb save current success
<7>[ 281.335210] (0)[5:kworker/u:0]enable(0), count(0) res=1
<6>[ 281.335505]-(0)[5:kworker/u:0][Power/Kernel]:ws activate-> ccci_modem1
其中CPU WAKE UP BY: CCIF以及ws activate->ccci_modem1后,可以尝试查看radiolog中以及netlog中是否有对应时间点的
URC上报或者IP报收发。这两种case都会引起AP唤醒。
请抓取相应的待机的mobilelog,
从kernel_log中分析,
如果log中可以查找到
wake up by RTC
请在相应的main_log中查找关键字
Alarm triggering, 其后面对应的type 0, type 2所对应的APk就是唤醒系统的唤醒源,
例如:
从log 上看,问题是由于系统被alarm type 为0 & 2 的APK唤醒,分别为com.android.phone&com.google.android.gsf
01-03 13:47:52.018 653 699 V AlarmManager: Native set alarm :Alarm{41e4d570 type 2 com.android.phone}
01-03 13:47:59.056 653 699 V AlarmManager: Native set alarm :Alarm{42041000 type 2 com.google.android.gsf}
01-03 13:48:52.076 653 699 V AlarmManager: Native set alarm :Alarm{421dec08 type 2 com.android.phone}
01-03 13:48:58.264 653 699 V AlarmManager: Native set alarm :Alarm{41c04b80 type 0 com.google.android.gsf}
01-03 13:48:58.358 653 885 V AlarmManager: Native set alarm :Alarm{42007638 type 0 com.google.android.gsf}
01-03 13:48:59.090 653 699 V AlarmManager: Native set alarm :Alarm{41d47db8 type 2 com.google.android.gsf}
而release wakelock后(系统还是awake state),也会看到com.dewav.timewidget去要带有wakelock的clock, 请您去掉看看
01-03 13:49:00.355 1015 1015 V AppWidgetContext: package name: com.dewav.timewidget
01-03 13:49:00.355 1015 1015 V AppWidgetContext: context permission not changed
01-03 13:49:01.168 653 699 V AlarmManager: Native set alarm :Alarm{41e02628 type 2 com.android.phone}
2. 而对于一些与modem相关的debug,需要结合kernel log/ radio log/net log/modem log来结合分析
在kernel中发现被唤醒的时间点,可以通过以下方式将kernel log和上层的时间点联系起来,在kernel log中搜索UTC(可能
在客户端抓取的话,需要时区转换)
在kernel中搜索CPU WAKE UP关键字,可以找到对应的时间点,在结合上图经过转换后,得到上层的时间。
若是在kernel log中发现,而main log中没有发现异常
<4>[ 281.333369]-(0)[5:kworker/u:0][PCM WAKEUP NORMAL]CPU WAKE UP BY: CCIF
<5>[ 281.333369]-(0)[5:kworker/u:0][Power/Sleep] slp_abort_cnt:0,slp_normal_cnt:12
<7>[ 281.333702] (0)[5:kworker/u:0]enable(1), count(1) res=0
<7>[ 281.334564] (0)[5:kworker/u:0]enable(0), count(0) res=0
<4>[ 281.334574] (0)[5:kworker/u:0]usb save current success
<7>[ 281.335210] (0)[5:kworker/u:0]enable(0), count(0) res=1
<6>[ 281.335505]-(0)[5:kworker/u:0][Power/Kernel]:ws activate-> ccci_modem1
其中CPU WAKE UP BY: CCIF以及ws activate->ccci_modem1后,可以尝试查看radiolog中以及netlog中是否有对应时间点的
URC上报或者IP报收发。这两种case都会引起AP唤醒。
相关文章推荐
- 有关Android Debug source not found问题的一些解决方法:
- Android 异步获取网络图片并处理导致内存溢出问题解决方法
- Android下Toolbar+SearchView程序崩溃闪退问题解决方法及示例
- Android 异步获取网络图片并处理导致内存溢出问题解决方法
- 最快学习百度地图android开发的方法探讨--从官方例子开始之问题处理-例子分割
- Android开发时处理闪退问题的方法
- 简单处理Android 65536方法越界问题
- Android 图片OutOfMemory异常bitmap size exceeds VM budget的原因及解决方法 主要介绍Android图片oom问题的原因及解决方法,顺带提及Dalvik h
- linux android memory相关问题的一些debug方法
- 关于android视频播放显示区域不正常的问题,一些处理方法
- android RecycleView 嵌套问题切换页面跳动问题、嵌套展开显示不全问题处理方法
- Android 关于处理手机屏幕自适应时,用到的主要方法
- android 图片处理OOM问题处理方法
- android 针对于GridView中的getView方法的bug,使用本地缓存来处理图片显示的问题
- Android ANR问题介绍和处理方法
- Android NavigationBar问题处理的方法
- Android模拟器访问本地IIS冲突问题处理方法
- android工具类中自定义监听处理异步方法问题
- phongap+ jquery + asp.net +android,我把我遇到的问题和处理方法的连接总结一下
- Android 异步获取网络图片并处理导致内存溢出问题解决方法