Analysis of black screen problem caused by Systemui ANR android5.0l

<span id="Label3"></p><br><span style="font-size:24px;"><span style="font-size:24px;"> <span style="color:rgb(0, 176, 80);">first,</span> The <span style="color:rgb(0, 176, 80);">problem</span> <span style="color:rgb(0, 176, 80);">phenomenon</span> </span></span><p><p><span style="font-size:14px;">1, the user intuitively see the phenomenon is a black screen.</span></p></p><p><p><span style="font-size:14px;">2, when the problem statusbar, Navigationbar and wallpaper disappear.</span></p></p><p><p><span style="font-size:14px;">3, most of the occurrence after the Fota restarts, the probability is very low.</span></p></p><p><p><span style="font-size:14px;"></span></p></p><p><p><span style="font-size:14px;">platform:msm8916</span></p></p><p><p><span style="font-size:14px;">Android Version: 5.0.2L</span></p></p><p><p><span style="font-size:14px;">Buildtype:user</span></p></p><p><p><span style="font-size:14px;">System software version: Va6v+l5v0</span></p></p><p><p><span style="font-size:14px;">System RAM:1GB</span></p></p><p><p><span style="font-size:14px;"><br></span></p></p><p><p><span style="font-size:14px;"><span style="color:rgb(0, 112, 192);">Reference Machine</span> <span style="color:rgb(0, 112, 192);">behavior:</span></span></p></p><p><p><span style="font-size:14px;"><span style="color:rgb(0, 112, 192);">1, 5.0L of N</span> <span style="color:rgb(0, 112, 192);">EXUS4</span> <span style="color:rgb(0, 112, 192);">and 5.1L of n</span> <span style="color:rgb(0, 112, 192);">EXUS5</span> <span style="color:rgb(0, 112, 192);">not even</span> <span style="color:rgb(0, 112, 192);">reproduce this problem</span> <span style="color:rgb(0, 112, 192);">. </span></span></p></p><p><p><span style="font-size:14px;"><span style="color:rgb(0, 112, 192);"><br></span></span></p></p><span style="font-size:24px;"><span style="font-size:24px;"> <span style="color:rgb(0, 176, 80);">second,</span> the <span style="color:rgb(0, 176, 80);">solution</span> <span style="color:rgb(0, 176, 80);"></span> </span></span><p><p><span style="font-size:14px;">Through preliminary analysis, in-depth analysis ( <span style="color:rgb(0, 112, 192);">specific</span> <span style="color:rgb(0, 112, 192);">analysis</span> <span style="color:rgb(0, 112, 192);">process,</span> <span style="color:rgb(0, 112, 192);">key code</span> <span style="color:rgb(0, 112, 192);">and</span> <span style="color:rgb(0, 112, 192);">log</span> <span style="color:rgb(0, 112, 192);">are</span> <span style="color:rgb(0, 112, 192);">attached below</span> We know exactly why the problem occurred:</span></p></p><p><p><span style="font-size:14px;"><span style="color:rgb(0, 112, 192);">1.</span> The parameters of the camera need to be acquired during power-on <span style="color:rgb(0, 112, 192);">initialization, the camera is opened at the API level during the acquisition process (the user is not visible) and then quickly shuts down</span></span></p></p><p><p><span style="font-size:14px;"><span style="color:rgb(0, 112, 192);">2.</span> During the <span style="color:rgb(0, 112, 192);">open process, a thermal Deamon thread is opened for thermal related processing, and then it waits for the thermal deamon thread to exit when it shuts down</span> .</span></p></p><p><p><span style="font-size:14px;"><span style="color:rgb(0, 112, 192);">3.</span> <span style="color:rgb(0, 112, 192);">When this thread is turned on, it performs a thermal-related processing asynchronously, waits for the result to be returned, executes</span> <span style="color:rgb(0, 112, 192);">the way is</span> <span style="color:rgb(0, 112, 192);">Multithreading Asynchronous Processing</span></span></p></p><p><span style="font-size:14px;"><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">there is a certain probability in the execution state of the current code (very small,</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">This process is only available when booting or rebooting.</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">) occurs when the Closecamera operation is performed for the reason of the dispatch and the linked list of asynchronous processing results is deleted, and then waits for the thermal Deamon thread to exit, which causes the linked list of the asynchronous processing results to be deleted when the thermal Deamon is Awakened. Once</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">the knot produces,</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">S</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">Ystemui</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">it will be anr,</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">then</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">attached to S</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">Ystemui</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">of the</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">StatusBar and navigationbar, and the Imagewallpaper Metropolis</span> .</span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">was</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">Blocking</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">, once S</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">Ystemui</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">Process</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">was</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">K</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">ill, These components will disappear, creating a black screen Phenomenon. </span></span></span></p><p><p><span style="font-size:14px;"><span style="color:rgb(0, 112, 192);"><br></span></span></p></p><p><p><span style="font-size:14px;">For the root cause of the above problems, we give the following solutions:</span></p></p><p><p><span style="font-size:14px;"><strong><span style="color:rgb(0, 176, 80);">1.</span> <span style="color:rgb(0, 176, 80);">Fix Code</span> <span style="color:rgb(0, 176, 80);">of the</span> <span style="color:rgb(0, 176, 80);">Processing Order</span></strong></span></p></p><p><p><span style="font-size:14px;">Closecamera executes M_thermaladapter.deinit waits for thermal deamon thread to exit and return the result processing complete, and then free all pending API results because m_ Thermaladapter.deinit relies on the pending API results, which is also followed by the initialization and anti-initialization of the stack principle, that is, the last initialization of the Opencamera is dependent on others, but not by others, therefore, the Closecamera need to be initialized at Opencamera when the final initialization, according to the principle of the stack processing.</span></p></p><p><p><span style="font-size:14px;"><strong><span style="color:rgb(0, 176, 80);">2.</span> <span style="color:rgb(0, 176, 80);">program-related</span> <span style="color:rgb(0, 176, 80);">the specific code and log</span></strong></span></p></p><p><p></p></p><p><p></p></p><p><p></p></p><p><p></p></p><p><p><span style="font-size:14px;">The above is a deadlock when the lock corresponding to the log and the corresponding code and call stack, through the red line around the part we can see the problem when the key call relationship and state, but also the code to deal with the order of the problem place.</span></p></p><p><p><span style="font-size:14px;"><strong><span style="color:rgb(0, 176, 80);">3.</span> <span style="color:rgb(0, 176, 80);">The final scenario</span> <span style="color:rgb(0, 176, 80);">Code</span> <span style="color:rgb(0, 176, 80);">Modify</span></strong></span></p></p><p><p><span style="color:rgb(0, 176, 80);"></span></p></p><p><p><span style="color:rgb(0, 176, 80);"><br></span></p></p><span style="font-size:24px;"><span style="font-size:24px;"> <span style="color: rgb(0, 176, 80);">three,</span> The <span style="color: rgb(0, 176, 80);">preliminary analysis</span> </span> of the problem</span><p><p><span style="font-size:14px;">To Idol347 a typical trace and log in the case of a problem, the main thread of Systemui was found to be in a binder call to cameraservice, resulting in systemui</span></p></p><p><p><span style="font-size:14px;">The following event timeout causes the anr, the specific trace of the main thread is as Follows:</span></p></p><p><p></p></p><p><p><span style="font-size:14px;">Then continue to trace the Cameraservice service side trace, found/system/bin/mediaserver in the processing Cameraservice binder thread is also block, It then traces the use of the call stacks and mutexes for each thread in the trace, and discovers that the binderthread of the addlistener that processed the call Cameraservice is blocked because the <span style="color:rgb(255, 0, 0);">other binder thread takes the lock first</span> , and then registers the thermal callback during the take-up process, but the registration process takes another lock, but the lock is occupied by the third thread when it logs off the thermal callback and joins another thread, therefore, the entire dependency ring needs another thread exit to solve, from the current problem phenomenon, the thread will not quit too soon, resulting in the ANR and black screen problems.</span></p></p><p><p><span style="font-size:14px;">Through a preliminary analysis of the problems we found:</span></p></p><p><p><span style="color:rgb(0, 112, 192);"><span style="font-size:14px;">Is it necessary to use a lock to join another thread, or is this a reasonable state?</span></span></p></p><p><p></p></p><p><p><span style="color:rgb(255, 0, 0);"><span style="font-size:14px;">The relationship between the specific call stack and the lock in the code is as Follows:</span></span></p></p><p><p></p></p><p><p></p></p><p><p></p></p><p><p></p></p><p><p></p></p><p><p></p></p><p><p></p></p><p><p></p></p><p><p></p></p><p><p></p></p><span style="font-size:24px;"><span style="font-size:24px;"> <span style="color:rgb(0, 176, 80);">iv.</span> in- <span style="color:rgb(0, 176, 80);">Depth Analysis</span> of <span style="color:rgb(0, 176, 80);">issues</span> </span></span><p><p><span style="font-size:14px;">After we initially identified the first problem point, we also produced 1 questions, and then we went on to analyze it in order to find the root cause of the answer and the Problem.</span></p></p><p><p><span style="font-size:14px;"><span style="color:rgb(0, 112, 192);">1.</span> <span style="color:rgb(0, 112, 192);">is it necessary to use a lock to join another thread, or is this a reasonable state? </span></span></p></p><p><p><span style="font-size:14px;">By further analyzing and viewing the code discovery, the other thread of the join cannot exit quickly because it waits for the other condition to be satisfied when executing callback, and the specific logical call relationship is as Follows:</span></p></p><p><p></p></p><p><p></p></p><p><p></p></p><p><p></p></p><p><p><span style="font-size:14px;">Another reason why the condition is not satisfied:</span></p></p><p><span style="font-size:14px;"><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">during boot initialization, you need to obtain</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">Camera</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">parameters, the process of obtaining the</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">API</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">Level Open</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">Camera</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">(the User is not visible in the form of open) and then quickly close, during the opening process will open a</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">Thermal Deamon</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">thread to</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">Thermal</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">related processing and then shutting down will wait for this</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">Thermal Deamon</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">thread exits, But it executes asynchronously when the thread is Opened.</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">Thermal</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">related processing, and waiting for the results to be returned, due to the asynchronous processing of multithreading, there is a certain probability (very small) in the execution state of the current code, which is executed first because of the scheduling Reason.</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">Closecamera</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">and then deletes the linked list of asynchronous processing results and waits for</span> the</span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">Thermal Deamon</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">thread exits, which causes</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">Thermal Deamon</span></span><span style="color:rgb(0, 112, 192);"><span style="color:rgb(0, 112, 192);">The linked list of asynchronous processing results is deleted and the deadlock occurs when it is Awakened. </span></span></span></p><p><p> <span style="font-size:14px;"><span style="color:rgb (0, 112, 192);"> once </span> <span style="color:rgb (0, 112, 192);"> Knot generation, </span> <span style="color:rgb (0, 192);">s </span> <span style="color:rgb (0, 192);">ystemui </span> <span style="color:rgb (0, 112, 192);" it will be anr, < span> <span style="color:rgb (0, 112, 192);"> then </span> <span style="color:rgb (0, 112, 192);"> attached to S </span> <span style="color:rgb (0, 192); >ystemui </span> <span style= " color:rgb (0, 112, 192);" < span> <span style="color:rgb (0, 192); >statusbar and Navigationbar and Imagewallpaper will </span> <span style=" color:rgb (0, 112, 192); "> was </span> <span style="color:rgb (0, 112, 192);"> blocked </span> <span style="color:rgb (0, 112, 192);"> once s </span> <span style="color:rgb (0, 112, 192); >ystemui </span> <span style= " color:rgb (0, 112, 192);"> process </span> <span style="color:rgb (0, 112, 192);"> </span> Span style= "color:rgb (0, 112, 192); >k </span> </span></span></p></p><span style="font-size:24px;"><span style="font-size:24px;"> <span style="color:rgb(0, 176, 80);">v.</span> <span style="color:rgb(0, 176, 80);">other</span> <span style="color:rgb(0, 176, 80);">related issues</span> </span></span><p><p><span style="font-size:14px;">First Question: <span style="color:rgb(0, 176, 80);">Why does the majority occur</span> after <span style="color:rgb(0, 176, 80);">the</span> <span style="color:rgb(0, 176, 80);">fota upgrade</span> <span style="color:rgb(0, 176, 80);">? </span></span></p></p><p><p><span style="font-size:14px;"><span style="color:rgb(0, 112, 192);">Analysis: because</span> <span style="color:rgb(0, 112, 192);">This problem occurs when you start or restart, and this is the only</span> <span style="color:rgb(0, 112, 192);">a</span> <span style="color:rgb(0, 112, 192);">process will not</span> <span style="color:rgb(0, 112, 192);">have a</span> <span style="color:rgb(0, 112, 192);">very small probability trigger</span> <span style="color:rgb(0, 112, 192);">. And after Fota</span> <span style="color:rgb(0, 112, 192);">will</span> <span style="color:rgb(0, 112, 192);">automatically</span> restart <span style="color:rgb(0, 112, 192);">, so</span> <span style="color:rgb(0, 112, 192);"></span> <span style="color:rgb(0, 112, 192);">There is a probability of triggering this problem, because the user usually in the use of rarely restarted, so the probability is not high</span> <span style="color:rgb(0, 112, 192);">. </span></span></p></p><p><p><br></p></p><p><p><span style="font-size:14px;"><strong>Analyzed by Vincent.song from SWD2 Framework Team.</strong></span></p></p><p><p><span style="color:rgb(0, 0, 255);"><span style="font-size:14px;"><strong>[email protected]</strong></span></span></p></p><p><p><span style="font-size:14px;"><strong>201505221140</strong></span></p></p><br> <p style="font-size:12px;"><p style="font-size:12px;">Copyright Notice: This article for Bo Master original article, without Bo Master permission not Reproduced.</p></p> <p><p>Analysis of black screen problem caused by Systemui ANR android5.0l</p></p></span>