Screen capture event flow of Android source code analysis

In today's article, we mainly talk about the screen capture event processing process in Android system. Students who have used Android system mobile phones should know that the screen capture event will be triggered when the general Android mobile phone presses the volume reduction button and the power button (if the domestic customized machine is modified, it will not be considered here). So how is the screenshot event triggered here? After triggering, how does the Android system realize the screen capture operation? With these two questions, we begin our source code reading process.

We know that the screen capture event here is triggered by our key operation, so we need to start from the key trigger module of Android system. Since we operate the volume reduction key and power key on different app pages, the screen capture processing of the system will be triggered, so the key trigger logic here should be the global key processing logic of Android system.

In the Android system, because each Android interface is an activity, and the display of the interface is realized through the window object, each window object is actually an instance of phonewindow, and each phonewindow object is a phonewindowmanager object. When we perform key operations on the activity interface, Before distributing the key processing operations to the app, the dispatchunhandledkey method in phonewindowmanager will be called back. This method is mainly used to perform the operations before the current app processes the keys. Let's take a look at the implementation of this method.

Here we focus on the interceptFallback method that is called in the lower part of the body. By calling this method, we will send the processing key to the method. We will continue to see the implementation logic of the method.

Then we see that in the interceptfallback method, we call the interceptkeybeforequeuing method. Through reading, we know that this method mainly implements the processing flow of screen capture keys. So let's continue to see the processing of the interceptkeybeforequeuing method:

It can be found that we first judge whether the current system has been booted. If it has not been booted, all key operations will fail. If the boot is completed, follow-up operations will be performed. Here, we only focus on the processing events of the combination of volume reduction key and power key. In addition, I would like to say that the home key events, menu key events, process list key events, etc. of Android system are implemented here. We will introduce this aspect in the follow-up.

Back to our interceptkeybeforequeuing method, when I press the volume reduction button, I go back to: case keyevent.keycode_ VOLUME_ Mute branch and execute corresponding logic, and then judge whether the user has pressed the power key at the same time. If the power key is pressed at the same time, execute:

It can be found that the interceptscreenshotchord method here is the beginning when the system is ready to perform the screen capture operation. Let's continue to look at the implementation of the interceptscreenshotchord method.

In the method body, we will eventually send a delayed asynchronous message to request screen capture. Here, if the current input box is open, the delay time is the closing time of the input box plus the key timeout configured by the system. If the current input box is not open, it is directly the key timeout processing time configured by the system, Take a look at the implementation of the getscreenshotchordlongpressdelay method.

Returning to our interceptscreenshotchord method, after sending an asynchronous message, the system will eventually be executed by the run method of the runnable object we sent. Here, for the logic of asynchronous messages, please refer to: Android source code analysis (2) C > asynchronous message mechanism

Let's take a look at the implementation of the run method of mscreen shotrunnable of runnable type:

Well, no other operations are performed in the method body, but the takescreenshot method is called directly. Let's continue to look at the implementation of the takescreenshot method.

It can be found that a TakeScreenshotService object was created through the reflection mechanism and then called bindServiceAsUser, which created the TakeScreenshotService service and sent an asynchronous message after the service was created. OK, let's take a look at the implementation logic of takescreenshotservice.

It can be found that there is a handler member variable in the definition of takescreenshotservice class, and we send back an asynchronous message when starting takescreenshowservice. In this way, we will execute the handlemessage method of mhandler, and then in the handlemessage method, we create a globalscreenshow object, and then execute the takescreenshot method. OK, Continue to look at the execution logic of the takescreenshot method.

You can see whether the last two parameters are visible: statusbarvisible and navbarvisible. These two parameters are passed in the phonewindowmanager.takescreenshot method:

Visible: if mstatusbar is visible, the passed statusbarvisible is true; if mnavigationbar is visible, the passed navbarvisible is true. Then we judge whether nstatusbar and mnavigation bar are visible during screen capture. If they are visible, the screen capture will also be taken. Go back to our takeScreenshot method and call it:

Method. Look at the notes. Here is the specific operation of the screenshot event. Then I'll take a look at the specific implementation of the surfacecontrol.screenshot method. In addition, it should be noted that a bitmap object is returned after the screenshot. In fact, children familiar with the Android drawing mechanism should know all the things that can be displayed in Android, They are all bitmap objects in memory.

Well, what is called here is the nativescreen shot method, which is a native method. The specific implementation is in the JNI layer. I won't introduce it too much here. Continue to return to our takescreenshot method. After calling the screenshot method screenshot, judge whether the screenshot is successful:

If the bitmap object of the screen capture is empty after the screen capture, it is judged that the screen capture fails, and the notifyscreenshoterror method is called to send the notification notification of the screen capture failure.

Then continue to look at the takescreenshot method to determine whether the screenshot image needs to be rotated. If necessary, rotate the image:

At the end of the takescreenshot method, if the screen capture is successful, we call:

Start the screenshot animation. OK, let's see the realization of the animation effect:

Well, after some column operations, we have realized the animation effect after the screenshot. We don't analyze the animation effect for the time being. Let's take a look at what we have done after the animation effect? Remember, in general, we will receive a screenshot notification after screenshot? This should also be implemented in the onanimationend method of its animatorlisteneradapter, that is, after the animation execution is completed, let's take a look at the implementation of its savescreenshotinworkerthread method:

Well, the main logic here is to construct a saveimageinbackgroundtask object. It seems that the notification of successful screen capture should be implemented here. Let's take a look at the implementation logic of the saveimageinbackgroundtask construction method:

It can be found that the paparazzi creates a notificationbuilder object behind the construction method, and then sends a screenshot of a successful notification,

In this way, we will receive the notification after the screenshot animation.

Summary:

Handle key events that app cannot handle in the dispatchunhandledkey method of phonewindowmanager, including the combination of volume reduction key and power key

Start the takescreenshotservice service through a series of calls and perform the screen capture operation through it.

The specific screenshot code is implemented in the native layer.

During the screen capture operation, if the screen capture fails, the notification of screen capture failure will be sent directly.

After the screen capture, if the screen capture is successful, the animation of the screen capture will be executed first, and the notification of successful screen capture will be sent after the animation effect is executed

The above is the whole content of this article. I hope it will be helpful to your study, and I hope you can support programming tips.