Skip to main content

Android UI Internal : Pipeline of View's Touch Event Handling

This article aims to give you a big picture regarding how the touch event is handled in Android.  Simply speaking , we are trying to answer the question: when I press a button in an app , how the touch event is dispatched to that button and how can I handle it? 

A picture is worth a thousand words. Therefore,  I come up with the one below. The left diagram is what we see as a normal user ; the right one illustrates how the views are organized as a tree ; the bottom one describes the pipeline of event dispatching and handling, from Input module down to the individual focused view.

view hierarchy and touch event handling pipeline
I wish the diagram is self explaining, and I'd stress a few key points:

1. DecroView is created by the framework for each Activity and it contains the status bar , navigation bar and your content view. It is the root view that added to the WindowManager.

2. The touch event is dispatched from top to bottom but handled from bottom to top. The event is dispatched by calling dispatchTouchEvent and handled by onTouchEvent. 

3. Child view take precedence over parent view in handling event. Only if the child view does not consume the event, parent view can have a chance to handle it. In diagram above , if steps 6 return false, contenview will call its owner onTouchEvent, that is step 7.  See ViewGroup::dispatchTouchEvent() below.

4. To handle a touch event, you have two ways : either thru Event Listener (setOnTouchListener) or Event Handler (onTouchEvent). Be aware that Event Listener is called before Event Handler, if Event Listener returns true, Event Handle won't be called, so you risk losing other translated events (onClick, onLongClick) handled in the default Event Handler.  see View::dispatchTouchEvent() below.

5. If none of the views in the content view hierarchy handles the touchEvent, Activity::onTouchEvent will have a chance to handle it. see Activity::dispatchTouchEvent() below.

Below are implementation of dispatchTouchEvent in View, Activity and ViewGroup.  Code are pruned for simplicity.

loading code..

To reiterate what we talked, I captured the stacks when the button was touched. From this call stack we can confirm the touch event dispatched from the window -> activity -> viewGroup.dispatchTouchEvent -> view.dispatchTouchEvent ->view.onTouchEvent as we described previously. Then the call stack will wind back.

event handling call stack
In addition to the pipeline we talked above, Android framework also has some optimization in ViewGroup's dispatchTouchEvent in order to deliver the touch event more efficiently. For example , if a DOWN event is deliver to Button 2 , Button 2 will be set as current deliver target, following events until next DOWN will be delivered to Button 2 directly without doing hit test on all his children. Besides, ViewGroup has a chance to intercept the touch events before dispatching them to his children. 

I hope this introduction will make you more confident when dealing with the touch event in Android.
For more information, check out following links: Android Guide UI EventMaster Android Touch SystemAndroid Training Gestures.

Check out other articles in Android UI Internal series 

Popular posts from this blog

Android Security: An Overview Of Application Sandbox

The Problem : Define a  policy  to control how various  clients  can  access  different  resources . A  solution: Each  resource  has an  owner  and belongs to a  group . Each  client  has an  owner  but can belongs to multiple  groups . Each  resource  has a  mode  stating the  access permissions  allowed for its  owner ,  group  members and others, respectively. In the context of operating system, or Linux specifically, the  resources  can be files, sockets, etc; the  clients  are actually processes; and we have three  access permissions :read, write and execute.

Android Security: A walk-through of SELinux

In  DAC , each process has an owner and belong to one or several groups, and each resource will be assigned different access permission for its owner and group members. It is useful and simple. The problem is once a program gain root privileged, it can do anything. It has only three permissions which you can control, which is very coarse. SELinux is to fix that. It is much fine-grained. It has lots of permissions defined for different type of resources. It is based on the principle of default denial. We need to write rules explicitly state what a process, or a type of process (called domain in SELinux), are allowed to do. That means even root processes are contained. A malicious process belongs to no domain actually end up can do nothing at all. This is a great enhancement to the DAC based security module, and hence the name Security-Enhanced Linux, aka SELinux.

Java Collections Framework Cheat Sheet

Java Collections Framework (JCF) implements the  Abstract Data Type   for Java platform. Every serious Java programmer should familiar himself on this topic and be able to choose the right class for a specific need.  A thorough introduction to JCF is not the target of this small article and to achieve  that goal you can start with  this excellent tutorial  .