MTK平臺如何定位顯示花屏和界面錯亂等繪制異常的問題

[DESCRIPTION]

在測試手機各項功能過程中，經常會遇到機率幾率性復現“熒幕畫花了，界面畫錯亂了等繪制異常問題”，而且機率幾率還非常小；

這類問題請不要直接提交eService，而是先請測試人員及工程師保留住測試現場，然后根據此條FAQ的步驟進行排查；

?

通常貴司提交問題的時候所提供的資料太少，無法直接定位問題，與其提交了eService之后再又去花時間復現，不如在復現問題的當下，就先按照FAQ的步驟做一個初步排查和分析。

如果在排查過程中，分析問題遇到困難，再將已經排查的結果以及排查過程中每一步所生成的資料和復現問題的log一并提交到eService。

?

這樣的話我們就能獲得較全面的資料并接著之前的排查結果做進一步分析，不然的話，我們還是需要貴司安排測試人員再花時間去復現，然后按照步驟抓取我們需要的資料，這大大降低了雙方的工作效率，所以這條FAQ就是為了減少雙方的工作量。

?

下圖是顯示相關的流程圖：

?

[SOLUTION]

在如下3個大的check步驟中，請分別按照每一步的操作來進行排查；如果貴司有定位到某一個問題點，請在提eService時，將問題排查過程寫清楚，并提供相應的資料到eService附件中，以便MTK做進一步分析。

?

1.通過DDMS或GAT tool獲取異常界面的熒幕截圖

[Android 5.0版本之前]DDMS 截圖方法如下：Device --> Screen capture，點擊Screen capture，就能抓到當前刷到LCM 屏上的那幀數據,或者通過Eclipse中的DDMS工具的screen capture功能，點擊操作面板上的“照相機”圖標即可。

=>如果熒幕截圖是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繪制的問題；

?

[DESCRIPTION]

在遇到界面顯示異常等問題的時候，需要排查界面異常是由哪個處理過程所引起的，畫面顯示的過程，大致上可以分為：

1、上層app定義view 大小、位置，和畫面對應的layout；

2、View system處理view的這些內容，計算view tree的大小、位置、處理view的繪制邏輯；

3、native framework處理繪圖指令，未開啟硬件加速繪制時，是使用Skia圖形庫來執行繪圖指令；如果開啟了硬件加速，則是GPU來執行繪圖指令

?

當前這個FAQ就是要提供方法來抓取View hierarchy，排查第1、2這兩個步驟是否出現問題

[SOLUTION]

抓取方法是：

1、將手機用usb連接至電腦，確保手機軟體版本是eng load，或者userdebug load，才可以抓View hierarchy，如果是user load，且沒有打開對應的debug權限，則不可以抓；

?

2、打開Android sdk提供的Android Debug Monitor工具或Eclipse，進入DDMS這個視圖界面；

?

3、打開Devices顯示界面，在Devices的進程列表上方的那一排button中，找到最右邊的button，將滑鼠懸浮在button上方，顯示的文字是"Dump View Hierarchy for UI Automator"；

?

4、在復現了畫面顯示異常的界面，保持畫面不動，點擊第3步中的那個button開始dump，完了之后系統會自動打開所dump到的文件，文件名是dump_xxx.uix，xxx通常是一串數字；

?

5、將滑鼠移到文件名上，會懸浮顯示出此文件的存放 folder 名稱及路徑，folder 命名格式為: uiautomatorviewer_xxxxx，xxxxx也是一串數字，將此folder打包提供給我們分析即可；

?

如果是自己分析該文件，那么直接在已經打開了的文件中，檢視異常位置處的view的狀態和內容是否正確即可，將滑鼠移動到view的位置時，view會被紅色虛線框highligh出來，右邊的內容列表中會顯示出該view的各項內容。