蓝牙log
A. 配置logcat + btsnoop
//logcat with all trace levels to 6
1.Turn off bluetooth
2.adb root and adb remount
3.adb shell “sed -i ‘s/=2/=6/g’ /etc/bluetooth/bt_stack.conf”
//btsnoop
1.Turn off bluetooth
2.adb shell setprop persist.bluetooth.btsnoopenable true (O/P) and adb shell setprop persist.bluetooth.btsnooplogmode full(Q)
3.Turn on bluetooth
在拨号盘输入×#×#5959#×#× 开始抓BT log
复现问题后再次输入×#×#5959#×#×停止抓取BT log并生成bugreport log。(生成的是bugreport log，存储在/sdcard/MIUI/debug_log/文件夹下)
暗码操作抓取log
开Diag口 ##717717##
抓modemlog：##995995##
ap bugreport: ##284##(事后)
wifi 事后log：##9434##
BT: ##959##
GPS: ##477477##
暗码输入后开始抓log，再输一遍就停止
Android系统中，printk输出的日志信息保存在/proc/kmsg中，要查看/proc/kmsg的内容
内核中有个参数用来控制是否将printk打印的字符串输出到控制台（屏幕或者/sys/log/syslog日志文件）
cat /proc/sys/kernel/printk 6 4 1 7
第一个6表示级别高于（小于）6的消息才会被输出到控制台，第二个4表示如果调用printk时没有指定消息级别（宏）则消息的级别为4，第三个1表示接受的最高（最小）级别是1，第四个7表示系统启动时第一个6原来的初值是7。
因此，如果你发现在控制台上看不到你程序中某些printk的输出，请使用echo 8 > /proc/sys/kernel/printk来解决。
#define MTS_NAME "microtek usb (rev " MTS_VERSION "): "
#define MTS_WARNING(x…)
printk( KERN_WARNING MTS_NAME x )
#define MTS_ERROR(x…)
printk( KERN_ERR MTS_NAME x )
#define MTS_INT_ERROR(x…)
MTS_ERROR(x)
#define MTS_MESSAGE(x…)
printk( KERN_INFO MTS_NAME x )
在Kernel code中我们经常可以看见封装log方式的代码，这是有助于我们更好的管理代码。
如何抓取Ramdump？
使用adb手动触发一个KE：
ASUS_X00ID:/ # echo c > proc/sysrq-trigger
1、确认手机处于dump模式
手机是处于黑屏状态，并且充电指示灯闪烁，PC设备管理器有Diag端口出现（如右图），说明手机进入dump模式。
打开工具QPSTConfig，工具会自动抓取ramdump（如右上图），进度条走完，说明ramdump抓取完毕，抓取完毕后手机会自动重启。需要注意的是对于反复crash的手机，在抓取ramdump完毕之后需要拔出USB，否则工具会反复自动抓取。
3、ramdump存放的目录可以在工具QPSTConfig的菜单栏直接跳转“Help Open Log File Directory Sahara Port_COM24”。 Port_COM24文件夹中就是抓取的ramdump；注意ramdump文件夹命名是根据具体COM口来命名的，并不是固定的。
4、ramdump的总大小跟手机ram大小相同；压缩后提供给开发人员或者高通分析；
使用QCAP解析ramdump
高通提供了一个网站QCAP（Qualcomm® Crash Analysis Portal），用于解析ramdump，生成QCAPReport；使用个人高通账号登陆https://cap.qti.qualcomm.com；QCAPReport有助于开发人员和高通分析crash的原因；对于crash的高通case通常需要将ramdump和QCAPReport上传，便于高通分析定位问题；
需要注意的是QCAP网站需要JAVA支持，并且需要使用高版本的火狐浏览器或者是IE 11浏览器，Chrome浏览器不行；
使用ramdump-parser脚本解析ramdump
参考微博：http://blog.csdn.net/forever_2015/article/details/70185313
高通参考文档：80-P7139-5A introduction_to_linux_ramdump_parser.pdf
按照上述文档建立脚本环境，执行脚本可以解析ramdump，初步分析问题原因
有一种异常的情况：无法连ADB，串口log也没有，重启又可能破坏异常现象或者低概率无法复现，比如说定屏的情况，该如何是好？
高通提供了一种PS_HOLD短地的方式进入dump模式，从而抓取ramdump提供分析；具体做法如下：
1、找硬件确认ps_hold测试点，或者自行查找原理图
2、打开QPSTConfig工具，USB连接PC和手机
3、使用镊子短接ps_hold和GND，要特别注意短地时间要在200ms以内，也就是点一下地就好了，不能一直短地，这样会直接使手机重启；
相关dump信息
adb shell screenrecord /sdcard/demo.mp4 （如果能录制出视频且视频正常播放说明上层送到overlayer 的数据没有问题，如果无法录制出来，说明上层数据有问题）
adb logcat -b all > logcat.txt (有时可能缓存较多，抓大约三分钟左右)
adb shell dumpsys activity > activity.txt（查看当时activity的状态）
adb shell dumpsys window > window.txt（查看当时系统窗口的状态）
adb shell dumpsys SurfaceFlinger >surfaceflinger.txt (查看当时的SurfaceFlinger的buffer&layer状态)
adb shell debuggerd -b <surfaceflinger_pid> > debuggerd_surfaceflinger.txt （抓取SurfaceFlinger的当时的线程堆栈信息）
同时另一台对比机也播放一样的视频，抓取一样的log
高通modem log抓取用什么工具 ？
测试之前adb重置一下电池统计，拔掉adb后再测试，重置电池统计的adb命令：
adb shell dumpsys batterystats --enable full-wake-history
adb shell dumpsys batterystats --reset
find ./ -name “*.cpp” | xargs grep “readbrightness”
耗电相关笔记
KERNEL LOG (logcat -b kernel -v threadtime -v printable -v uid -d *:v)
battery_level
查看kernel_log，查找到关键字Chip_pm_enter，如果有此关键字，就可以找到系统进入睡眠的时间和次数
在kernel_log里面查找关键字“wake up by”的时候，会有很多个，但是要查找chip_pm_enter下面最近的wake up by，才能真正查看唤醒源。
acquireWakeLockInternal
releaseWakeLockInternal
持锁时间超过1000ms以上的就要开始关注
wakeup alarm唤醒源
system.out：[socket][**] connection
1 手机长期处于信号极差的环境中，导致耗电增加。
建议用户再网络信号良好的环境中使用。非系统问题。
Phone signal levels: (log 关键字)
none 2h 44m 18s 914ms (19.0%) 84x
poor 6m 55s 237ms (0.8%) 93x
moderate 4h 3m 43s 709ms (28.1%) 390x
good 6h 12m 52s 457ms (43.0%) 318x
2 耗电正常，夜间待机一晚上好定1%。白天正长使用耗电66%。非问题
3没有提供log,无法分析。
从分析的20多份log和其他同事处理C6 的用户反馈功耗问题来看，耗电较多的情况有以下几个原因：
1.用户信号较弱，需要频繁搜网导致功耗增大很多；
----用户到信号良好的环境下使用在观察耗电情况
2.用户运行了相机、视频通话、游戏等功耗较大的应用，导致耗电很快；
----用户注意使用此类应用功耗会增大，正常现象
3.三方app问题（hotstar、应用双开）导致持锁时间过长，系统无法休眠，待机电流过高功耗增大；
----用户使用此类app后，及时关闭此类应用即可解决
4.用户在使用部分三方app时会调用GPS定位、相机等功耗较大操作导致用户感觉耗电快；
----某些三方app行为，正常现象
5.wifi连接成功，但实际上无法进行正常数据交互或信号较弱，导致某些app更新服务启动，此服务长时间唤醒cpu进行retry联网更新，耗电较多；
----需用户连接正常可用且信号良好的wifi即可解决
1 亮屏使用每小时耗电在10%以内 ----2.0 可视化工具可以很方便看亮灭屏状态和对应的耗电量
2 灭屏待机耗电每小时在1%以内 ---- 同上（如果有camera、video game 等，放宽标准）
3 无异常持锁情况 ----bugreport中搜索：All kernel wake locks、 All partial wake locks:，除
PowerManagerService.WakeLock外，其他持锁超过30分钟的都要关注一下。
息屏待机耗电多：
息屏待机耗电主要和一下几种因素相关：
a 当前所处的网络信号是否稳定？
网络信号差一方面会导致射频功耗升高，另一方面也会导致数据丢包、重传概率加大。 还会出现由于网络来回切换导致RIL_ACK_WL持锁时间过长导致功耗升高。
b wifi 是否稳定？
wifi 不稳定一方面会出现wifi自身会频繁的扫描、连接、断开 动作，导致耗电增加。另外一方面，如果wifi 不稳定，大量的连接，断开会不断唤醒系统服务和三方应用服务。这块也会导致功耗升高。
c 异常持锁。Modem 、wifi、三方应用、系统服务等都有可能出现长时间持锁导致手机无法休眠，待机功耗高问题。
