Is android's motion event handling accurate?

Question

Bug

I have a weird bug in my piano app. Sometimes keys (and thus notes) hang. I did a lot of debugging and narrowed it down to what looks like androids inaccuracy of motion event handling:

 DEBUG/(2091): ACTION_DOWN A4
 DEBUG/(2091): KeyDown: A4
 DEBUG/(2091): ACTION_MOVE A4 => A4
 DEBUG/(2091): ACTION_MOVE ignoring
 DEBUG/(2091): ACTION_MOVE A4 => A4
 DEBUG/(2091): ACTION_MOVE ignoring
 DEBUG/(2091): ACTION_MOVE A4 => A4
 DEBUG/(2091): ACTION_MOVE ignoring
 DEBUG/(2091): ACTION_UP B4 //HOW CAN THIS BE????
 DEBUG/(2091): KeyUp: B4
 DEBUG/(2091): Stream is null, can't stop
 DEBUG/(2091): Hanging Note: A4 X=240-287 EventX=292 Y=117-200 EventY=164
 DEBUG/(2091): KeyUp Note:   B4 X=288-335 EventX=292 Y=117-200 EventY=164

Clearly it can be seen here that out of nowhere I suddenly have an ACTION_UP for another note. Shouldn't I definitely get a ACTION_MOVE first?

As shown in the end of the log, it's definitely not an error in region detection, since the ACTION_UP event is clearly in the B4 region.

Logging Implementation details

Every onTouchEvent() call is logged, so the log is accurate.

The relevant pseudo-code for the ACTION_MOVE logging is:

 Key oldKey = Key.get(event.getHistoricalX(), event.getHistoricalY());
 Key newKey = Key.get(event.getX(), event.getY());

Question

Is this normal behaviour for Android (the jumping in coordinates)?

Can a ACTION_UP just occur without any previous ACTION_MOVE towards it's coordinates?

What device is this on, and are you tracking multiple fingers? What is the breakdown of those log outputs? EventX is 292 in both of those lines, if I'm reading that correctly shouldn't that put both the "Hanging Note" and "KeyUp Note" coordinates in the B4 range? — adamp, Jun 06 '10 at 22:38
I haven't the slightest, but also curious. Does it work properly in the emulator and/or other devices? — Gerard, Apr 22 '12 at 22:51
@adamp. Looking back after a while, indeed the log output looks a bit suspicious, since it shows the same coordinates and a different note. However, I have moved on to recording the current pressed keys with pointer ids and releasing the correct one when a pointer is lifted. — Peterdk, Apr 22 '12 at 23:06

score 0 · Answer 1 · answered Jun 15 '12 at 16:19

I had a similar issue when I was trying to develop a simple shooter game on Android. The trick I used to solve this may not work if the problem is caused by the hardware, but it's worth a try anyhow.

The general idea is to have an array of "TouchEvents" and iterate through this array over time in a loop. This way, when the device registers multiple and/or simultaneous touch envents, they are stocked linearly in an array, but not handled on the spot. you make sure to handle them one after the other, removing any unsynchronized event to occur.

List<TouchEvent> touchEvents = game.getInput().getTouchEvents();
    int len = touchEvents.size();
    for(int i = 0; i < len; i++) {
        TouchEvent event = touchEvents.get(i);

        if(event.type == TouchEvent.TOUCH_DRAGGED || event.type == TouchEvent.TOUCH_DOWN) ...

Where : "game.getInput().getTouchEvents()" simply refers to a TouchEvent object and its methods such as getTouchEvent

That did the trick for me, I hope this helps somehow, good luck!

Is android's motion event handling accurate?

1 Answers1