Android input subsystem

Linux input subsystem review 1: Why should I review the linux input subsystem? This problem will be known later. 1. the device of the linux input subsystem is based on the platform device mechanism. Therefore, let's first review the platform device mechanism, mainly looking back at what we will get later. 1. apply for the master device number 2. create cdev-> Mount cdev to the system device hash linked list and generate inode Node 3. create a device-> 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 class2. apply for the master device number 3. create cdev-> Mount cdev to the system device hash linked list and generate inode node 4. create input_device-> associate input_device with the newly generated inode node to provide interface 1 for the event driver layer. you can enter an event type for a registered device.> [this will be used later] 2. you can enter the Event code for a registered device. generate/dev/input_device 5. when input_device and input_hander match successfully, 1. generate/dev/inpu T * 2. upper-layer applications enable/dev/input through the master device number and/dev/input_device 3 through the device number. input subsystem function 1. read function-> read [used later] 2. write function-> write [used later] 3. event function-> report events [used later] [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. starting from starting an Android program 1. activity start process: onCreate ()-> onStart ()-> onResume ()-> Activity Running [Q1]: Why does onStart () not directly run Ning, to insert an onResume (), what does the system do in onResume? <A1>: In onResume (), the system creates a ViewRoot for this Activity! [Q2]: What is the purpose of ViewRoot? What has it done? 3. android event process from input to output 1. when the Activity is running, the user clicks the touch screen operation-> {event generation} 1. when you click the touch screen, the touch screen driver will be called-> {event input} [Q3]: Event transfer process? -> {Event transfer} <A3>: all the steps below! 1. android upper-layer applications call the JNI local method at the Framework layer-> {event messages are transmitted to the JNI layer} 1. implements the JNI layer method, fills in the local method ing table, and provides interfaces for upper-layer Android applications. generate so dynamic link library file, adb push to/system/lib directory 2. JNI local method call HAL layer (Hardware Abstraction Layer: middleware) method-> {event message transmitted to HAL layer} 1. the JNI layer obtains the HAL module instance by specifying the ID, and then calls the HAL layer function 2. generate so dynamic link library file, adb push to/system/lib/hw directory 3. HAL enters the kernel layer through the system call write-> {event message passed to the kernel} 1. copy_from_user () to obtain user-layer data 2. call input_device.write-> {(1.1.2): The event message is sent to the driver layer }------------------------------------------------- ----------------------------------------- 4. enter the device driver to obtain the event and call the event function-> {(1.1.3)} 5. event Processing Layer reports events by event type-> {event messages are transferred to kernel event processing layer} 1. call input_event (device, type, code, value)-> {[type] will be used later} 6. to the event processing layer, the kernel will wake up the read function-> {(1.1.1): The event message is sent to the kernel layer} 1. use copy_to_user () to pass kernel data to user space-> {event message to user space} [Q4]: Who calls the read function? 7. event messages are captured by Android's event processing system-> {event messages are delivered to Android event processing system} 1. android event processing system sends this message to the Android Application Layer [Q5]: How is the event message transmitted in the Android event processing system? 8. the Android upper layer obtains event messages and responds to the upper layer View callback function 9 According to event type (3.1.1.5.1: type. android UI Update-> {Event Response} 4. so far, the Framework knowledge used in the project has been introduced. the Android event processing system acts as a black box and is skipped for the moment. 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. transmit data to a virtual device 3. virtual Devices report events and cheat system input events. analysis of Android event processing system [Q5]: How is event messages transmitted in Android event processing system? <A5>: Check the Android event processing system. 1. next to 3.1.1.7, the event message is sent to the Android event processing system. 2. when Android is started, System Server initializes Android Window Management Service (WindowManagerService) 3. WMS initializes InputManager (InputManager is a C ++ class at the Framework layer and is responsible for capturing and forwarding all input events. in the InputManager constructor, three most important classes in the event processing system will be initialized (InputReader/InputDispatcher/EventHub) 2. then initialize InputManager (InputManager. initialize () generates two threads (InputReaderThread/InputDispatcherThread, responsible for event capture and event forwarding respectively) 3. inputReaderThr Ead thread work-> {solving problem 1: How does the Android event processing system capture input events?} 1. call InputReader: loopOnce (). In the InputReader class, you have implemented the logoff mechanism and operated cyclically. 1. call EventHub: getEvent () function 1. call the Epoll_wait () function 1. in the Epoll_wait () function, all the/dev/input devices are read cyclically. Once an event is generated, the function captures [Q6 ]: how is the Android event processing system associated with the/dev/input Device [A6]: EventHub: Device <---->/dev/input, one-to-one ing Relationship 2. when an event occurs, the Android event processing system calls the read function> {system call to obtain the event message from the kernel layer} [Q4]: Who calls the read function? <A4>: The read function is called by InputReader. save the event message (input_event) read from the kernel layer to RawEvent. call the corresponding message converter (InputMapper) according to the event type (input_event.type) 1. android currently supports five types of event messages (slide cover, trackball, multi-touch, single-touch, and keyboard. inputReader: InputDevice: inputMapper converts a RawEvent event to the corresponding Notifyargs 1. inputMapper converts a RawEvent event to the corresponding Notifyargs Class 2. add yyargs to the InputRead: QueueListener: argsQueue queue. call the InputReader: QueueListener: flush () function to process event messages in the queue. call the policyargs: policy function, Convert the event message to the corresponding EventEntry and pass it to InputDispatcher 1. event preprocessing 1. determine whether to discard the event Message 1. 2. do not discard 2. get the Connection object corresponding to the current Activity-> (This will be discussed later) 2. add the corresponding EventEntry to the InputDispatcher: OutBoundQueue queue [Q7]: How to obtain the InputDispatcher instance in Notifyargs <A7>: When initializing the InputRead: QueueListener: argsQueue queue, passed the InputDispatcher object. 6. wake up InputDispatcher: pollOnce () function 4. inputDispatcherThread thread operation 1. call InputDispatcher: loopOnce (). In the InputDispatcher class, Similarly, the logoff mechanism is implemented. call the pollOnce () function to poll InputDispatcher: OutBoundQueue queue 1. event messages exist in the queue. 2. awakened by the policyargs: Policy () function 2. call the corresponding InputDispatcher: dispach function 1. get EventEntry object from InputDispatcher: OutBoundQueue queue 2. convert EventEntry object to 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? <A9>: To solve this problem, you need to go back 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. viewRoot has an important role: to communicate with WMS, complete the drawing of the entire GUI Window System 3. what did ViewRoot do when it was created? 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 get event messages? <A10>: there is a shared memory (sharemory) between ViewRoot and InputManager. inputManager: InputDispatcher sends the last event message to the shared memory (ShareMemory. when ViewRoot knows that an event message arrives, it obtains the event message [Q11] from the shared memory (ShareMemory. how does ViewRoot know that event messages have arrived? <A11>: 1. viewRoot and InputManager communicate with each other to transmit messages. after ViewRoot is created, two InputChannel class objects are created. one of the InputChannel objects is registered in NativeInputQueue and associated with ViewRoot [Q12]. What is 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. another InputChannel object is registered to the InputManager class object. 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 the shared memory descriptor. an InputChannel class object is registered in ViewRoot and InputManager, and each has two MPs channel descriptors. both InputChannel objects contain one read and one write descriptor. therefore, the full-duplex communication is completed before ViewRoot and InputManager [used later] [Q13]: In Android, A ViewRoot is created for every Activity created, therefore, an InputChannel object will also be created. How can the Android system differentiate these activities? <A13>: Do you still remember [Q8] to solve the two problems together: InputChannel: where does the Connection object come from? What is the purpose? 1. to distinguish different activities, the NativeInputQueue class defines a subclass Connection 2. when registering an InputChannel object, each InputChannel object creates a Connection object. therefore, each InputChannel in ViewRoot and InputChannel in InputManager contain a Connection object. this Connection object identifies different activities 4. now we can go back to [Q9. [Q9]: Now InputDispatcher gets the converted event message, which is about to be sent out, but where? <A9>: 1. from the above analysis, we know that the event message needs to be sent to ViewRoot 1. call InputChannel: Connection: inputPublisher. the publishMotionEvent function sends event messages to the shared memory (ShareMemory. the InputChannel object sends a dispatch message to the write pipeline. 6. now it's time to move to ViewRoot [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. each registered InputChannel object contains a Connection object. the Connection object of InputChannel object of InputManager <---> the Connection object of InputChannel object in NativeInputQueue is a one-to-one correspondence relationship. 3. therefore, the Connection object corresponding to the Connection object in InputDispatcher will receive pipeline information 1. the Connection object of the corresponding InputChannel object receives the pipeline information 2. call InputChannel: Connection: inputConsumer to get the event message in the shared memory (ShareMemory. inputChannel then sends a message to the write pipeline, Indicates that this event has been obtained 4. then InputChannel in InputManager will receive a message from the MPs queue, and then proceed to the next round of event processing. so far, the event message has been passed to the InputChannel object in NativeInputQueue. according to the previous analysis, every InputChannel object in NativeInputQueue corresponds to an Activity 2. 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 [Q11] When the InputChannel object of ViewRoot is registered. when the ViewRoot InputChannel object is registered with NativeInputQueue, three parameters 1 must be registered. one parameter is the member variable InputHandler 1 of ViewRoot. inputHandler 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. after the InputChannel object obtains the event, it calls the InputHandler function of ViewRoot-{so far, and the event message is passed back to the Android Application Layer} [Q16 ]: what is this callback function? <A17>: This callback function is mostly implemented as an abstract function by the Android system. 1. on the client of our TV bar remote control, we have rewritten the corresponding method to obtain the data we need, such as onScroll/onLongPress.