Cheng pengzhiyuan |
Linux input subsystem review 1: Why should I review the linux input subsystem? This problem will be known later.
1. linux input subsystem device is based on the platform device MechanismSo first, let's review the device mechanism of the platform, and mainly review what we get later.
1. Apply for the master device number
2. CreateCdev-> Mount cdev to the system device hash list and generate inode nodes.
3. CreateDevice-> Associate the device with the newly generated inode node to provide interfaces for upper-layer calls.
2. register the input subsystem Device
1. Create a device class
2. Apply for the master device number
3. Create cdev-> Mount cdev to the system device hash linked list and generate inode nodes.
4. CreateInput_device-> Associate input_device with the newly generated inode node to provide interfaces for the event driver layer.
1. You can enter the event type to register a device.-> this will be used later]
2. You can enter the Event code to register a device.
3. Generate/dev/input_device
5. When input_device and input_hander match successfully
1. Generate/dev/input *
2. Upper-layer applications enable/dev/input through the master device number and enable/dev/input_device through the device number.
3. Some input subsystem Functions
1. read function-> read will be used later]
2. write function-> this function will be used later]
3. event function-> will be used after reporting events]
Questions to be considered in advance]
1. How does the Android event processing system capture input events?
2. How do Android upper-layer applications capture input events?
3. How does an Android upper-layer app capture input events and respond?
2. Start from starting an Android Program
1. Activity start process: onCreate ()-> onStart ()-> onResume ()-> Activity Running
Q1]: Why does the onStart () function do not directly run Ning and insert an onResume ()? What does the system do in onResume?
<A1>: In onResume (), the system creates a ViewRoot for the Activity!
Q2: What is the purpose of ViewRoot? What has it done?Answer this question later
3. Android event process from input to output
1. When the Activity is running, the user clicks the touch screen operation-> {Event generation}
1. If you click the touch screen, the touch screen driver will be called-> {Event Input}
Q3: What is the event transfer process? -> {Event transfer}
<A3>: All the steps below!
1. Android upper-layer applications call the JNI local method of the Framework layer-> {Event messages are transmitted to the JNI Layer}
1. Implement the JNI layer method, populate the local method ing table, and provide interfaces for upper-layer Android applications
2. Generate the so dynamic link library file and push it to the/system/lib directory of adb.
2. JNI local method call HAL Hardware Abstraction Layer: middleware) method-> {Event messages are transmitted to the HAL Layer}
1. The JNI layer obtains the HAL module instance by specifying the ID, and then calls the HAL layer function
2. Generate the so dynamic link library file and push it to the/system/lib/hw directory.
3. HAL enters the kernel layer through system calling write-> {Event messages are transmitted to the kernel}
1. copy_from_user () to obtain user-layer data
2. Call input_device.write-> {1.1.2 ):Event messages are transmitted to the driver layer}
Bytes ------------------------------------------------------------------------------------------
4. Enter the device driver to get the event and call the event function-> {1.1.3 )}
5. The event processing layer reports the event type-> {Event messages are transmitted to the kernel event processing layer.}
1. Call input_event (device, type, code, value)-> {type] will be used later}
6. At the event processing layer, the kernel will wake up the read function-> {1.1.1 ):Event messages are transmitted to the kernel layer}
1. Use copy_to_user () to pass kernel data to user space-> {Event message transmitted to user space}
Q4]: Who calls the read function?
7. event messages are captured by Android's event processing system-> {Event messages are transmitted to the Android event processing system.}
1. The Android event processing system sends the message to the Android Application layer.
Q5: How is event messages transmitted in the Android event processing system?
8. Obtain event messages from the Android upper layer, and respond to the corresponding callback function of the upper layer View according to event type 3.1.1.5.1: type.
9. Android UI Update-> {Event Response}
4. Now, the Framework knowledge used in the project has been introduced.
1. The Android event processing system acts as a black box and is skipped for the moment.
2. Project Introduction: Remote Control of TV bar
1. Client APK
1. Data collection-> {this data must be compatible with the Linux input subsystem in order to fool the system}
2. Data Transmission
2. Server APK-> {Implement two Virtual Devices: virtual keyboard devices and virtual mouse devices}
1. receive data
2. transfer data to a virtual device
3. Virtual Devices report events and cheat system input events
5. Analyze the Android event processing system
Q5: How is event messages transmitted in the Android event processing system?
<A5>: Check the Android event processing system.
1. Followed by 3.1.1.7,Event messages are transmitted to the Android event processing system.
2. When Android is started, the System service System Server initializes the Android window management service.WindowManagerService)
3. WMS service will initializeInputManagerInputManager is a C ++ class at the Framework layer. It is responsible for capturing and forwarding all input events.)
1. The InputManager constructor initializes the three most important classes in the event processing system.InputReader/InputDispatcher/EventHub)
2. Then initialize InputManagerInputManager. initialize () to generate two threads.InputReaderThread/InputDispatcherThread, Responsible for event capture and event forwarding respectively)
3.InputReaderThreadThread work-> {Solution 1: How does the Android event processing system capture input events?}
1. Call InputReader: loopOnce (). In the InputReader class, The logoff mechanism and cyclic operations have been implemented.
1. CallEventHub: GetEvent ()Function
1. Call the Epoll_wait () function
1. In the Epoll_wait () function, all the/dev/input devices will be read cyclically. Once an event is generated, it will be captured by this function.
Q6: How is the Android event processing system associated with the/dev/input device?
A6]: EventHub: Device <---->/dev/input, one-to-one correspondence
2. When an event occurs, the Android event processing system calls the read function-> {system call, and obtains the event message from the kernel layer}
Q4]: Who calls the read function?
<A4>: The read function is called by InputReader.
2. event messages read from the kernel layerInput_event) Save to RawEvent
2. Call the corresponding message converter according to the Event Type input_event.type)InputMapper)
1. The Android system currently supports five types of event message slide/trackball/multi-point touch/single point touch/keyboard)
3. InputReader: InputDevice: inputMapper converts a RawEvent event to a correspondingNotifyargs
1. InputMapper converts a RawEvent event to a corresponding Notifyargs class
2. Add yyargs to the InputRead: QueueListener: argsQueue queue.
4. CallInputReader: QueueListener: flush ()Function to process event messages in the queue
5. Call the Notifyargs: Y function to convert the event message to the corresponding EventEntry and then forward itInputDispatcher
1. Event preprocessing
1. Determine whether to discard the event message
1. Discard, then return directly
2. Do not discard
2. obtain the correspondingConnectionObject> next)
2. Add the corresponding EventEntry to the InputDispatcher: OutBoundQueue queue.
Q7]: How does one obtain the InputDispatcher instance in Notifyargs?
<A7>: When initializing the InputRead: QueueListener: argsQueue queue, the InputDispatcher object is passed.
6. Wake up InputDispatcher ::PollOnce() Function
4.InputDispatcherThreadThread work
1. Call InputDispatcher ::LoopOnce() In the InputDispatcher class, The logoff mechanism and cyclic operations are also implemented.
1. Call the pollOnce () function to poll the InputDispatcher: OutBoundQueue queue.
1. event messages in the queue
2. awakened by the policyargs: Policy () function
2. Call the corresponding InputDispatcher ::DispachFunction
1. Get the EventEntry object from the InputDispatcher: OutBoundQueue queue
2. convert an EventEntry object to a DispatchEntry object
3. Add the DispatchEntry object to the InputChannel: Connection: outboundQueue queue.
Q8]: Where does this InputChannel: Connection object come from? What is the purpose?
Q9: Now InputDispatcher gets the converted event message, which is about to be sent out, but where to send it?
<A9>: To solve this problem, you need to return to Q2]
4.Q2: what is the use of ViewRoot? What has it done?-> {Solution 2: How do Android upper-layer applications capture input events?}
<A2>: 1. First, ViewRoot is a Hander bound to the current Activity.
2.ViewRoot has an important role: to communicate with WMS and draw the entire GUI Window System
3. What have you done when creating ViewRoot? Now let's solve problem 2: How does an Android upper-layer application capture input events?
1. According to the previous analysis, Android event input comes from InputManager, so ViewRoot needs to communicate with InputManager.
Q10]: How does ViewRoot communicate with InputManager and obtain event messages?
<A10>: There is a shared memory between ViewRoot and InputManager.ShareMemory)
1. InputManager: InputDispatcher sends the last event message to the shared memory ShareMemory.
2. ViewRoot obtains the event message from the shared memory ShareMemory when the event message arrives.
Q11] 1. How does ViewRoot know the arrival of event messages?
<A11>: 1. The ViewRoot and InputManager communicate with each other to transmit messages.
1. After ViewRoot is created, twoInputChannelClass Object
1. One of the InputChannel objects is registered in NativeInputQueue and associated with ViewRoot.
Q12] what is the NativeInputQueue used?
<A12>: This NativeInputQueue is used by the Android system to maintain event reception. because at the same time, many activities are waiting for event input.
2. register another InputChannel object to the InputManager class object.
2. At the same time, we will apply for the shared memory used above.
3.The InputChannel class encapsulates information such as the channel Descriptor and shared memory descriptor.
1. An InputChannel class object is registered in ViewRoot and InputManager, and each has two channel descriptors.
1. Both InputChannel objects contain one read and one write descriptor.
2. Therefore, full-duplex communication is completed before ViewRoot and InputManager and will be used later]
Q13]: In Android, A ViewRoot object is created every time an Activity is created, so an InputChannel object is also created. How can the Android system differentiate these activities?
<A13>: Do you still remember Q8? Solve the two problems together:InputChannel: where does the Connection object come from? What is the purpose?
1. To differentiate different activities, the NativeInputQueue class defines a subclass.Connection
2. When registering an InputChannel object, a Connection object is created for each InputChannel object.
1. Therefore, each InputChannel in ViewRoot and InputChannel in InputManager contain a Connection object.
2. This Connection object identifies different activities
4. Now we can go back to Q9.
5.Q9: Now InputDispatcher gets the converted event message, which is about to be sent out, but where to send it?
<A9>: 1. From the analysis above, we know that the event message needs to be sent to ViewRoot.
1. Call InputChannel: Connection: inputPublisher.PublishMotionEventThe function sends event messages to the shared memory ShareMemory)
2. The InputChannel object sends a dispatch message to the write pipeline.
6. Now the job should be transferred to the ViewRoot side.
Q14]: There are many InputChannel objects in NativeInputQueue. Which InputChannel pipeline will receive the information?
<A14>: Do you still remember Q13? The InputChannel object of InputManager is registered after being created by ViewRoot.
1. Each registered InputChannel object contains a Connection object.
2. The Connection object of InputChannel object of InputManager <---> the Connection object of InputChannel object in NativeInputQueue is a one-to-one correspondence relationship.
3. The Connection object corresponding to the Connection object in InputDispatcher will receive the MPs queue information.
1. The Connection object of the corresponding InputChannel object receives the pipeline information
2. Call InputChannel: Connection ::InputConsumerGet event messages in shared memory ShareMemory)
3. InputChannel then sends a message to the write pipeline, indicating that the event has been obtained
4. Then, InputChannel in InputManager will receive a message from the pipeline and proceed to the next round of event processing.
7. Till now,The event message has been passed to the InputChannel object in NativeInputQueue.
1. According to the previous analysis, each InputChannel object in NativeInputQueue corresponds to an Activity.
2. The InputChannel object in NativeInputQueue is created after ViewRoot is created, that is, before the Activity is started.
Q15]: The event message obtained by the InputChannel object associated with the Activity. How can this problem be solved? Now let's answer question 3: How does the Android upper-layer app respond to the input events captured?
<A15>: Return to the position of the InputChannel object of ViewRoot, that is, Q11.
1. When the ViewRoot InputChannel object is registered with NativeInputQueue, three parameters must be registered.
1. One of the parameters is the InputHandler member variable of ViewRoot.
1.InputHandlerIt is the event processing function, that is, the so-called callback function.
2. The function of passing it is mainly to clarify the event processing function of the current ViewRoot.
3. When the InputChannel object obtains the event, it will call the InputHandler function of ViewRoot-{so far,Event messages are transmitted back to the Android Application layer.}
Q16]: What is this callback function?
<A17>: Most of the callback functions are implemented as abstract functions by the Android system.
1. In the remote Remote Control client of our TV bar, the corresponding method is rewritten to obtain the data we need, such as onScroll/onLongPress.
Mind Map
650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/140107/0Q6243F4-0.jpg "style =" border: 0px; "alt =" 05184226-2e8a6dd9aa7b4588a3c459223ce38b5 "/>
This article from the "Cheng Peng Zhiyuan" blog, please be sure to keep this source http://infohacker.blog.51cto.com/6751239/1348764