This is the intended behavior. There are basically five actions you need to care about. For all of them, you can mask out ACTION_MASK to just look at the action part.
These three are all you need to care about if you aren't interesting in multitouch: 1. ACTION_DOWN, the existing standard action for the first press. 2. ACTION_MOVE, any change in state that doesn't involve a finger going up or down. 3. ACTION_UP, the existing standard action for the last release. And if you want to keep track of addition fingers going down, you want these: 4. ACTION_POINTER_DOWN, when an addition pointer goes down. The pointer ID mask tells you the new identifier for this pointer. 5. ACTION_POINTER_UP, when a pointer goes up by there are still active pointers. The pointer ID mask tells you the identifier for this pointer. Note that it was deliberate to keep the actions for the first and last pointer different from the other pointers, both for backwards compatibility and the fact that the majority of code doesn't care about multitouch. Now that the 2.0 source is available, here are some example uses of the API: http://android.git.kernel.org/?p=platform/development.git;a=blob;f=apps/Development/src/com/android/development/PointerLocation.java;h=38b4af2dcd97625e6fef2c1bddcb9362a127352e;hb=eclair <http://android.git.kernel.org/?p=platform/development.git;a=blob;f=apps/Development/src/com/android/development/PointerLocation.java;h=38b4af2dcd97625e6fef2c1bddcb9362a127352e;hb=eclair> http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=core/java/android/inputmethodservice/KeyboardView.java;h=0f7ef22f93fbc0e928257738cb369189698ad2f8;hb=eclair <http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=core/java/android/inputmethodservice/KeyboardView.java;h=0f7ef22f93fbc0e928257738cb369189698ad2f8;hb=eclair> On Sun, Nov 15, 2009 at 1:41 PM, davemac <davemac...@gmail.com> wrote: > I think I've got this figured out. Almost. With multi-touch support, > getAction() can return a compound value representing the pointerID in > the second byte and the action value in the first byte. For example, > if two fingers are down, and pointerID 1 is lifted (i.e., finger 2), > getAction() returns a value of 262 (0x100 or 256 to represent > pointerID 1, and 6 to represent up for a compound value of 0x106 or > 262). I'm curious why it was done this way instead of using 0 for down > and 1 for up, even when pointers are involved. Things get a little > weird because of the differences. Here's an example (note I'm using a > Motorola Droid phone here so this may behave differently on other > devices): > > Press finger 1 to the screen (action value of 0) > finger 1 gets pointerID 0, no problem, pointerID is 0, down is 0 > Press finger 2 to the screen (action value of 261) > finger 2 gets pointerID 1, a little weird, could have been 256 > instead? > Lift finger 1 from the screen (action value of 6) > finger 2 is still pointerID 1, action could still have been 1? > Lift finger 2 from the screen (action value of 1) > finger 2 is still pointerID 1, but the action value is not 262 or > 257 it's 1 > > It would seem I can't use the bitmasks reliably in all cases. If I > always inspect the action value for the pointerID and the action > value, I get messed up at the end because pointerID has vanished. And > 0 seems to be equivalent to 5, and 1 to 6. > > Is this something you'd consider a bug or is this how it's supposed to > work? Should we expect it to continue to work this way? > > Thanks for your help. > > - dave > > On Oct 27, 4:28 pm, Dianne Hackborn <hack...@android.com> wrote: > > On Tue, Oct 27, 2009 at 2:02 PM, MrChaz <mrchazmob...@googlemail.com> > wrote: > > > > > Thanks for the info, > > > > > Wouldn't this > > > Finger 1 up: MotionEvent ACTION_POINTER_1_UP with one pointer, whose > > > ID is > > > 1. > > > need to be ID of 0? Or am I mis-understanding the purpose of the UP > > > action? > > > > Good point. Actually my example was not very good because at the places > > where there is an up transition, the last position of the pointer going > up > > is included in the event stream -- so in all of these, you would receive > > both 0 and 1. It is in the following move event that you will only get > the > > information for the pointers that are currently down. > > > > -- > > Dianne Hackborn > > Android framework engineer > > hack...@android.com > > > > Note: please don't send private questions to me, as I don't have time to > > provide private support, and so won't reply to such e-mails. All such > > questions should be posted on public forums, where I and others can see > and > > answer them. > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
