=>如果屏幕截图是ok的，那么问题点就在LCM driver或timing，具体问题要具体分析。

=>如果屏幕截图not ok，那么你需要进入第2步去获取并查看FrameBuffer中的数据。

[Android 5.0版本及以后]

Android L版本上抓取到的DDMS截图，不是ovl output，而是GPU composer之后的画面。

若要抓取ovl output，可以输入如下命令

adb shell

system/bin/lcdc_screen_cap  /data/fb.bin

2.获取FrameBuffer中的数据

对于android 4.1及以后的版本，通过如下方法抓取FrameBuffer中的数据：

先做如下操作，再dump framebuffer数据

先进入手机中Settings->Developer options->Disable HW overlays

再勾选Disable HW overlays

抓取framebuffer 数据： adb shell cat /dev/graphics/fb0  > /data/fb.bin 然后将fb.bin adb push出来，通过工具查看fb.bin

=>如果此步骤的屏幕截图是ok，那说明是LCM controller做overlay时出了问题。

需要把寄存器值打出来(保存在kernel log中)，再抓kernel log做进一步分析

打印寄存器的值：

请在当前刷屏时，将LCM controller寄存器打印出来，寄存器打印命令如下：

adb shell

echo reg:lcd>sys/kernel/debug/mtkfb

这条命令会将LCM controller的寄存器打印到kernel log中

抓kernel log的方式：要么开启mobile log，要么单独用adb命令抓取kernel log；

用adb命令抓取kernel log的方法是：adb shell cat /proc/kmsg > kernel_log.txt

如果分析问题原因是出在这一步，遇到困难时，请将抓取的资料都提供到eService附件中。

=>如果此步骤的屏幕截图not ok，那么就需要进入第3步，抓取layerdump。

3、抓取layerdump

在异常界面下，手机连接usb，执行抓取layerdump，抓取的方法根据android的版本不同而不同，下面会分别列出不同版本的抓取方法：

android 4.0~4.4的版本，分别介绍在windows环境下和linux 环境下如何抓取layerdump

在Windows系统环境下，将如下内容copy到新建文本文件中，然后保存文件为SF_layerdump_all.bat

保持手机连接usb并且在异常界面下，在电脑端双击鼠标执行该脚本(请在Windows系统下执行)，就会在脚本所在路径下生成一个文件SF_layerdump_all

将SF_layerdump_all和复现问题的mobile log一并提供到eService附件中。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

SET raw=%1 SET layerdump=%2

IF "%raw%"=="" SET raw=0 IF "%layerdump%"=="" SET layerdump=-1

adb shell setprop debug.sf.layerdump.raw %raw% adb shell setprop debug.sf.layerdump %layerdump% adb shell dumpsys SurfaceFlinger > SF_layerdump_all.log adb shell mkdir /data/SF_dump adb shell mv /data/*.png /data/SF_dump adb shell mv /data/*.i420 /data/SF_dump adb shell mv /data/*.yv12 /data/SF_dump adb shell mv /data/*.RGBA /data/SF_dump adb shell mv /data/*.RGB565 /data/SF_dump rmdir /S /Q SF_layerdump_all md SF_layerdump_all move SF_layerdump_all.log  SF_layerdump_all adb pull /data/SF_dump SF_layerdump_all/ adb shell rm /data/SF_dump/*

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

注意：如果异常画面是动态的，不是那种静止不动的画面，那么可以尝试多执行几次layerdump，尽量争取能抓到发生问题时的画面的layerdump

如果不方便在Windows系统下抓取layerdump，那么就在linux系统的Terminal 下，按照如下步骤执行下面的指令:

在复现问题前，下如下这条命令，做设置并打开layerdump的开关：

adb shell setprop debug.sf.layerdump.raw 1

adb shell setprop debug.sf.layerdump -1

在即将开始复现问题前，先将下面的指令准备好，在复现问题的画面，敲回车执行这条命令，就是做layerdump的动作，

如果复现问题的画面是动态的，请多下几次这条命令，尽量把复现问题的画面dump下来

adb shell dumpsys SurfaceFlinger >SF_layerdump_all.log

执行了上面的第3条命令之后，会在手机的/data/SF_dump目录下生成一些xxx.png或*.i420,*.yv12,*.RGBA,*.RGB565等文件，请把data/SF_dump这个目录pull出来提供给我们，还有SF_layerdump_all.log文件也一并需要提供。

android 5.0及以后的版本，在windows环境下如何抓取layerdump

在Windows系统环境下

若异常画面是静态稳定的，将如下内容copy到新建文本文件中，然后保存文件为SF_bqdump_L.bat

@echo off

adb shell rm /data/SF_dump/* adb shell setprop debug.bq.dump "@surface"

adb shell "dumpsys SurfaceFlinger" > SF_bqdump_all.log

adb shell setprop debug.bq.dump ""

rmdir /S /Q SF_bqdump_all md SF_bqdump_all move SF_bqdump_all.log SF_bqdump_all adb pull /data/SF_dump SF_bqdump_all/ adb shell rm /data/SF_dump/*

echo "Please view dump files in folder ‘SF_bqdump_all‘" pause

若异常画面是一闪而过的，则需用如下脚本dump画面刷新过程的几十帧画面，下面是设置30帧：SF_cont_bqdump_L_30.bat

复现问题后，双击执行下面的脚本，接着按命令行提示“按电脑任意键继续”，然后等几秒钟，系统会自动dump复现过程的所有帧到指定目录

@echo off

adb shell rm /data/SF_dump/*

:: Modified this line to set surface count,default is 30 adb shell setprop debug.bq.dump "@surface#30"

adb shell "dumpsys SurfaceFlinger > /dev/null"

pause

adb shell setprop debug.bq.dump "@surface"

adb shell "dumpsys SurfaceFlinger" > SF_bqdump_all.log

adb shell setprop debug.bq.dump ""

rmdir /S /Q SF_bqdump_all md SF_bqdump_all move SF_bqdump_all.log SF_bqdump_all adb pull /data/SF_dump SF_bqdump_all/ adb shell rm /data/SF_dump/*

echo "Please view dump files in folder ‘SF_bqdump_all‘" pause

注意：抓取到layerdump后，请将layerdump的所生成的文件SF_layerdump_all(在Linux环境下就是手机的data/SF_dump目录和SF_layerdump_all.log文件)和复现问题的mobile log一并提交到eService上来。

抓到layerdump之后，根据layerdump的结果，再做下一步分析；

如果layerdump看到的目标画面not ok，则参考如下FAQ做进一步确认，看是app本身的问题还是UI framework绘制的问题；