How does MTK platform locate the problem of drawing anomalies such as flower screen and interface confusion?

[DESCRIPTION]in the process of testing the function of the mobile phone, often encounter the probability of recurrence "screen painting, interface painting confusion, such as drawing abnormal problems," and the probability is very small; This kind of problem please do not submit eservice directly, but first ask testers and engineers to keep the test site, and then follow the steps of this FAQ to troubleshoot;usually your company submits the problem when the information provided is too little, can not directly locate the problem, and after the submission of eservice and then to take time to reproduce, as in the present situation of the recurrence problem, first follow the steps of the FAQ to do a preliminary troubleshooting and analysis. If you are having trouble analyzing the problem during the troubleshooting process, submit the results that have been investigated and the log of the data and replication issues that were generated during each step of the troubleshooting process to eservice. In this way we will be able to obtain more comprehensive information and then further analysis of the results of the previous investigation, otherwise, we still need your company to arrange for testers to take the time to reproduce, and then follow the steps to capture the information we need, which greatly reduces the efficiency of both sides, So this FAQ is to reduce the workload of both sides. is to display the relevant flowchart: [Solution]

in the following 3 large check steps, please follow each step of the operation to do the troubleshooting; If you have a location to a problem point, please write the troubleshooting process clearly when eservice, and provide the appropriate information to the eservice attachment, so that the MTK for further analysis.

1. Get the screen of the abnormal interface via the DDMS or GAT tool

[before Android 5.0 version] The DDMS method is as follows: Device-to-screen capture, click Screen Capture to capture the current frame of data that has been brushed onto the LCM, or through the screens capture feature of the DDMS tool in Eclipse, Click on the "Camera" icon on the operator panel.

= If the screen is OK, then the problem is in the LCM driver or timing, specific problems to be analyzed.

= = If the screen is not OK, then you need to go to the 2nd step to get and view the data in the framebuffer.

[Android 5.0 version and later]

The DDMS captured on the Android L version, not the OVL output, but the screen after the GPU composer.

To crawl OVL output, you can enter the following command

ADB shell

System/bin/lcdc_screen_cap/data/fb.bin

2. Get the data in Framebuffer

For Android 4.1 and later, crawl the data in framebuffer in the following ways:

Do the following first, then dump the framebuffer data

Enter the phone first settings->developer options->disable HW overlays

Then tick disable HW overlays

Crawl framebuffer data: adb shell cat/dev/graphics/fb0 >/data/fb.bin then push out fb.bin adb, view fb.bin by tool

= = If the screen of this step is OK, then the LCM controller does a overlay problem.

The register value needs to be typed (stored in the kernel log), and then the kernel log will be captured for further analysis.

The value of the print register:

Please print the LCM Controller register when the current brush screen, the Register Print command is as follows:

ADB shell

Echo REG:LCD>SYS/KERNEL/DEBUG/MTKFB

This command prints the register of the LCM controller to the kernel log.

Catch kernel log way: either open Mobile log, or alone with the ADB command to grab kernel log;

The way to grab kernel log with adb command is: adb shell cat/proc/kmsg > Kernel_log.txt

If the cause of the analysis is in this step, when encountering difficulties, please provide the captured data to the eservice attachment.

= = If the screen for this stepis not OK, then you need to go to the 3rd step and crawl the layerdump.

3, Grasping Layerdump

In the abnormal interface, the phone connected to the USB, the crawl Layerdump, the method of crawling according to the different versions of Android, the following will be listed in different versions of the Crawl method:

Android 4.0~4.4 version, which describes how to crawl layerdump in Windows and Linux environments, respectively

in a Windows system environment, the following Copy to the new text file, and then save the file as Sf_layerdump_all.bat

Keep the phone connected to the USB and under the abnormal interface, double click on the computer to execute the script (please execute under the Windows system), will generate a file under the path of the script Sf_layerdump_all

The mobile log of Sf_layerdump_all and recurrence issues is provided to the eservice attachment.

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

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 SURFACEF Linger > 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/*

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

Note: If the abnormal screen is dynamic, not the kind of static picture, then you can try to do more than a few layerdump, try to catch the picture when the problem occurs layerdump

If it is inconvenient to crawl layerdump under the Windows system, then under the terminal of the Linux system, follow the instructions below:

Before reproducing the problem, follow this command to set and open the Layerdump switch:

ADB shell SetProp Debug.sf.layerdump.raw 1

ADB Shell SetProp debug.sf.layerdump-1

Before starting to reproduce the problem, the following instructions are prepared, in the image of the recurrence problem, hit enter to execute this command, is to do layerdump action,

If the picture of the recurring problem is dynamic, please take this command several times, and try to dump the image of the recurring problem

adb shell Dumpsys Surfaceflinger >sf_layerdump_all.log

After executing the 3rd command above, some xxx.png or *.i420,*.yv12,* are generated in the/data/sf_dump directory of the phone. rgba,*. RGB565 and other documents, please pull out data/sf_dump this directory to provide to us, as well as Sf_layerdump_all.log file also need to provide.

Android 5.0 and later versions, how to crawl layerdump in Windows environments

In a Windows system environment

If the exception screen is static and stable, copy the following to the new text file and save the file as 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 the dump files in folder ' Sf_bqdump_all '" Pause

If the abnormal screen is a flash , then you need the following script dump screen refresh process of dozens of frames, the following is set 30 frame: Sf_cont_bqdump_l_30.bat

After you reproduce the problem, double-click Execute the following script, then press the command line prompt "Press any key to continue", and then wait a few seconds, the system will automatically dump all the frames of the process to the specified directory

@echo off

ADB Shell rm/data/sf_dump/*

:: Modified This line to set surface Count,default is the 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 the dump files in folder ' Sf_bqdump_all '" Pause

Note: After crawling to layerdump, please layerdump the generated file Sf_layerdump_all (in Linux environment is the Data/sf_dump directory and Sf_layerdump_all.log file of the phone) and reproduce the problem of mobile log is submitted to EService.

After catching Layerdump, according to Layerdump results, then do the next step analysis;

If Layerdump See the target screen is not OK, then refer to the following FAQ for further confirmation, see whether the app itself is the problem or UI framework drawing problems;

[DESCRIPTION]In the face of the interface display anomalies and other issues, you need to troubleshoot the interface is caused by the processing process, the screen display process, can be broadly divided into: 1, the upper-level app defines the view size, location, and the screen corresponding to the LAYOUT;2, view system processing These properties of view, Calculates the size and position of the view tree, and the rendering logic of the view, 3. The native framework handles drawing instructions, and when hardware accelerated drawing is not turned on, the drawing instructions are executed using the Skia graphics library, and if hardware acceleration is turned on, the GPU executes the drawing instructions The current FAQ is to provide a way to crawl the view hierarchy, troubleshooting 1th, 2, whether there are problems with the two steps[Solution]The Crawl method is:1, the mobile phone with a USB connection to the computer, to ensure that the mobile phone software version is ENG load, or userdebug load, can grasp the view hierarchy, if it is user load, and does not open the corresponding debug permissions, you can not grasp;2, open the Android SDK provided by the Android Debug Monitor tool or Eclipse, enter DDMS this view interface; 3. Open the Devices display interface, in the row button above the devices process list, find the rightmost button, hover the mouse over the button, and the text is "Dump View Hierarchy for UI" Automator ";4, in the reappearance of the screen display abnormal interface, to keep the screen does not move, click the 3rd step in the button to start the dump, after the system will automatically open the dump to the file, the file name is Dump_xxx.uix,xxx is usually a string of numbers;5, move the mouse to the file name, will hover to display the file folder name and path, folder naming format: Uiautomatorviewer_xxxxx,xxxxx is also a string of numbers, the folder will be packaged to provide us with analysis; If you analyze the file yourself, then directly in the file that has been opened, see the status and properties of the view at the exception location is correct, when you move the mouse to the location of the view, the view is highligh out by the red dashed box, the property list on the right shows the view's properties.

How does MTK platform locate the problem of drawing anomalies such as flower screen and interface confusion?