Solution for Android5.0 systemui ANR black screen

In this paper, we talk about the problem of black screen caused by android5.0l Systemui ANR

First, the phenomenon of problems

The phenomenon that the user sees visually is black screen. StatusBar, Navigationbar and wallpaper disappear when something goes wrong. Most occur after the Fota reboot, with a low probability of occurrence.

platform:msm8916

Android version: 5.0.2L

Buildtype:user

System software version: Va6v+l5v0

System RAM:1GB

Reference machine Behavior:

1, 5.0L NEXUS4 and 5.1L NEXUS5 did not reproduce the problem.

Ii. Solutions

Through a preliminary analysis, in-depth analysis (specific analysis process, key code and log will be attached below) we clearly know the cause of the problem:

1, the boot initialization process needs to obtain camera related parameters, the acquisition process will be opened in the API level camera (user invisible form open) and quickly shut down

2, in the open process will open a thermal deamon thread for thermal related processing, and then close will wait for this thermal deamon thread exit

3. When this thread is opened, it performs a thermal-related processing asynchronously, and waits for the result to return, executing in a multithreaded asynchronous manner

In the current code execution state there is a certain probability (very small, only when the boot or restart of this process) occurred because of the scheduling reason for the first execution of the Closecamera operation and first delete the asynchronous processing of the results of the list, and then wait for thermal deamon thread exit, resulting in thermal The list of asynchronous processing results when Deamon is awakened has been deleted and a deadlock occurs. Once the knot is produced, the Systemui will ANR, then the StatusBar and Navigationbar attached to Systemui and Imagewallpaper will be blocked, and once the systemui process is killed, these components will disappear, Create a black screen phenomenon.

For the root cause of the above problem, we give the following solutions:

1, the revision of the Code processing order

Closecamera executes m_thermaladapter.deinit wait thermal Deamon thread completes the result processing exit and returns, then free all pending API results because m_ Thermaladapter.deinit will rely on the pending API results, which is also followed by the initialization and initialization of the stack principle, that is, opencamera when the last initialization is dependent on others, but not to be relied on by others, so Closecamera to initialize the last initialization in Opencamera, according to the stack of the way the principle of processing.

2, program-related specific code and log

The above is a deadlock when the lock corresponding to the log and the corresponding code and call stack, through the red Line to circle the part we can see the problem when the key call relationship and state, but also gives the code processing order is problematic.

3, the final Plan code modification

Iii. preliminary analysis of the problem

Taking a typical trace and log in the case of a Idol347 problem, the main thread block of Systemui was found to be in a binder call to Cameraservice, resulting in systemui

Subsequent events timeout cause ANR, the main thread of the specific trace is as follows:

Then continue to trace the Cameraservice's service-side trace and discover that the binder thread in the/system/bin/mediaserver processing Cameraservice is block too, Then trace the use of call stacks and mutexes for each thread in trace, discovering that the addlistener that handles calls to Cameraservice is blocked because the other binder thread takes the lock first, It then registers the thermal callback in the course of the occupation, but the registration process requires another lock, but the lock is taken up by the third thread while the thermal callback is logged, and another thread is added, Therefore, the entire dependency ring needs another thread to exit to solve, from the current problem phenomenon, this thread is not too fast exit, so caused the ANR and black screen problem.

Through a preliminary analysis of the problems we found:

Does it take a lock to join another thread, or is this state justified?

The relationship between the specific call stack and the lock in the code is as follows:

Iv. in-depth analysis of issues

After we have initially identified the first problem point and created 1 questions, we continue to analyze it in depth to find the root cause of the answer and the problem.

1, whether the need to occupy the situation of the lock to join another thread, or is this state reasonable?

Further analysis and review of the code found that another thread of the join could not exit quickly because it waits for another condition to be satisfied when executing callback, and the specific logical invocation relationship is as follows:

Another reason why the condition is not satisfied:

During the boot initialization process, you need to obtain the camera parameters, the process will be opened in the API level camera (user invisible form open) and then quickly shut down, in the process of opening a thermal deamon thread for thermal-related processing, Then the shutdown will wait for the thermal Deamon thread to exit, but when the thread is opened, it will perform a thermal-related processing asynchronously and wait for the result to return, because it is a multithreaded asynchronous process with a certain probability (very little) in the current code execution state. A closecamera operation was performed for the reason of the dispatch, and the linked list of the results of the asynchronous processing was deleted, and then the thermal Deamon thread exited, causing the list of the results of the asynchronous processing thermal Deamon to be awakened to have been deleted and the deadlock occurred.

Once the knot is produced, the Systemui will ANR, then the StatusBar and Navigationbar attached to Systemui and Imagewallpaper will be blocked, and once the systemui process is killed, these components will disappear, Create a black screen phenomenon.

V. Other relevant issues

Why did most of this happen after the FOTA upgrade?

Because this problem occurs when starting or restarting, and only this process can have a very small probability trigger. And Fota will automatically restart, so there is the probability of triggering this problem, because the user in peacetime use rarely restart, so the probability is not high.