Android core analysis (15) --- detailed explanation of the input path of the android Input System

Android user event input path 1 General Principle of the input path key, the mouse from the collection to the final will be sent to the focus window, how to go through the path, it is a problem that needs to be considered in detail in the android GWES design scheme. Buttons, mouse, and other user message processing can be divided into different situations for determination: (1) whether user input should be delivered according to system conditions. For example, in the case of screenoff, when the key is a special key, wait (2) whether there is an interception listener (3) whether there is an input method for the key event (4) whether the focus end point (5) is the focus switch phase-by-phase is critical to the design of the input path. 1.1 General input path design this input path actually refers to the input path of the key message (msg_keydown, msg_keyup, msg_longpress), that is, the distance from the main active window to the focus window. The information input path is divided into two steps: Step 1) the window manager sends the information to the activity window step 2) the activity window transmits the message to the focus layer by layer through the default processing function. In this way, the application can process user input information in advance in the processing function of the activity view, so as to enhance the application's control over user information. The transfer path is completed through the default onxxx processing function of the view. Through the chain relationship of activeview-> focus, the first-level key messages, such as msg_keydown, msg_keyup, and msg_char, are transmitted to the focus window. At this time, the user presses the key to input and sends it to the input method window, which is processed by the Input Method Manager. After filtering, the results generated by the input method are placed in the focus view. 1.3 The overall process of the Input System is the data flow path of the android input system. messages are collected through the WM Input System thread and distributed to the Focus activity message queue. Then, messages are distributed through the message system. 2 Android input path description 2.1 Step 1: User Data Collection and preliminary determination keyinputq create an independent thread inputdevicereader in windowmangerservice and use the native function readevent to read data from the Linux driver to build a rawevent, put in the keyq message queue. Preprocessevent () @ KeyInptQ@KeyInputQueue.java this is the first blocker function prototype in the input system. Keyq reloads preprocessevent () @ windowmanagerservice. java. In this member function, perform the following operations: (1) Determine whether the user inputs wakeupscreen Based on the screen on and screen off states obtained by powermanager. (2) If you press the application switch button, the application is switched. (3) check whether the user input is shipped according to windowmanagerpolicy. 2.2 Step 2 message distribution level 1 inputdispatcherthread reads events from keyq, finds the focus window in window manager, and uses the mclient interface of the Focus window record to deliver events to the client. How to upload the keyevent object to the client: in the previous section (Window Management viewroot, Window Manager Proxy), we already know that when the Window Manager Proxy is created on the client and the Window Manager Service is added, an iwindow interface instance associated with the client viewroot is stored in the mclient member variable in windowstate. Through the iwindow aidl interface instance, the service can access the client information. iwindow is a bridge between the service and view. Let's look at the distribution process iwindow: dispatchkey (event) @ w @ ViewRoot@ViewRoot.java viewroot in client viewrootkeyevent. dispatchkey (event) @ viewroot. java Message> sendmessageattime (MSG) @ Handler@Handler.java so far we through the previous logoff, Handler detailed chapter analysis conclusions, we can know that the key message has been put into the application message queue. 2.3 Step 3: Use the message queue to distribute messages. In The logoff and handler sections, we analyze logoff. Loop () and call handlemesage .... Activitythread. Main () logoff. Loop () viewroot $ roothandler (). Dispatch () handlemessage... Wait Get = viewroot instance. In this case, handlemessage is the handlemessage function that is reloaded by viewroot. Handlermessage @ ViewRoot@ViewRoot.java deliverkeyevent if the input method exists, dispatchkey to the input method service. Otherwise, the deliverKeyEventToViewHierarchy@ViewRoot.java should emphasize that the interception of keyevent of the input method is not put into the Window Manager Service, but into the rootview of the client for processing. Step 4: Go to the focus to traverse the focus path. Distribution function call stack deliverKeyEventToViewHierarchy@ViewRoot.javamView.dispatchKeyEvent: mview is the top-level view corresponding to viewroot. If mview is a viewgroup, messages are sent to its mfocus. Mview. dispatchkeyevent @ viewgroup (viewroot @ root) event. Dispatch mfocus. dispatchkeyeevnet if the mfocu is still a viewgroup, this time the event is directed to the focus of the next layer until the mfocus is a view. Through this call, the focus path is traversed. At this point, the user event is passed to complete a paragraph. 2.5 Step 5: handle the event by default. If the event is not handled in the preceding focus view and is a key related to focus conversion, the focus is transferred to the next view.