Eventhub analysis and source code demonstration in the android input event Process

The input event process of android2.3 is significantly different from that of previous versions. Here we will perform a detailed analysis and finally put the Demo code used for analysis here:

Http://code.google.com/p/flying-on-android/

The following analysis is based on these source code. You can download the source code and view the document. In the source code, you only need to pay attention to the flyingevent class. If you only want to see the demo result, you can directly put the flying in the package to the/system/bin directory of the machine for execution. After opening logcat, you can see the demo output. When running the program, there will be a vision on the machine screen, which is normal, because this program was originally used to display surfaceflinger, this time to demonstrate eventhub slightly changed. You only need to pay attention to the flyingevent. cpp file.

You can also compile the demo program by yourself using the source code. You only need to put the decompressed flying folder under the/frameworks/base/cmds/directory, and then switch to the flying directory to use mm for compilation.

 

First, let's give a general introduction to the entire process and then make a key analysis. The input event process involves the following files:

/Frameworks/base/services/Java/COM/Android/Server/windowmanagerservice. Java

/Frameworks/base/services/Java/COM/Android/Server/inputmanager. Java

/Frameworks/base/services/JNI/com_android_server_inputmanager.cpp

/Frameworks/base/libs/UI/inputreader. cpp

/Frameworks/base/libs/UI/inputdispatcher. cpp

/Frameworks/base/libs/UI/eventhub. cpp

Windowmanagerservice. java and inputmanager. java provides Windows Services to Android, eventhub. CPP is mainly used to read rawevent from the device file, while inputreader. CPP and inputdispatcher. CPP is the Interconnection layer between them.

 

Their relationship is: windowmanagerservice enables a thread-driven inputreader to continuously read events from device files under the/dev/input/directory through the interface provided by inputmanager, then, it is distributed to the Client Connected to the windowmanagerservice through inputdispatcher.

Inputreader reads rawevent from the device file. before handing it over to inputdispatcher for distribution, it must convert and classify rawevent into keyevent, motionevent, and trackevent types. This article focuses on the rawevent splitting process, so our focus is on eventhub. cpp. In addition, to simplify the analysis process, my analysis only focuses on touch screen events. It shows how rawevent is split into application-layer user event motionevent.

 

Before reading the analysis below, we 'd better download the source code from the address mentioned above and refer to flyingevent. cpp in it.

 

The entire process is roughly divided into several steps:

1. initialization.

First, create an eventhub instance: meventhub (New eventhub ),

Next, enable a thread to read and process rawevent from the device file through meventhub:

While (1 ){

Rawevent event;

Meventhub-> getevent (& event );

Process (event );

}

Eventhub does some things during initialization,

1. Each time you search for the current input device, a device_added event is generated. When you read such a rawevent, inputreader records the device.

2. If you find the keyboard, the keyboard layout file is loaded. After loading, an event of the finished_device_scan type is generated. In this way, when the driver reads the user's buttons from the back end, it will find the ing key value in the loaded keyboard layout file and encapsulate it into a keyevent and return it to the user.

 

Ii. After eventhub Initialization is complete, wait for user input. The thread is blocked at meventhub-> getevent (& event) until a user event is generated.

When an event is generated, it is passed to process for processing.

 

Iii. Event splitting

Flyingevent. process mainly calls the flyingevent. Consume method to process user events. Only touch events are analyzed here. Touch events can be divided into three types: down, move, and up.

The down-type touch event requires four rawevent tasks. The first is the X coordinate (abs_x), the second is the Y coordinate (abs_y), and the third is the direction (abs_pressure) (When 0 is up, when 1 is down, so here it should be 1), and the fourth is the end mark (syn_report ).

The Touch event of the move type requires three rawevents to complete. The first is the X coordinate, the second is the Y coordinate, and the third is the end mark.

The up-type touch event requires two rawevent events to complete. The first one indicates the direction (0 indicates the up event, and 1 indicates the down event. Therefore, it should be 0 ), the fourth is the end mark.

You may have noticed that the Up event has no coordinate information, and its coordinate information is down (when there is no move) or the last move (a move event is generated between Down and up) the event coordinates are the same.

 

From the flyingevent. Consume method, each event will eventually generate a touchevent, call printtouchevent for printing, and finally store it in eventbuffer.

 

 

References

Li xianjing's "android input event process", but the Android version is old.

Http://blog.csdn.net/absurd/archive/2009/05/17/4195363.aspx