Does setting SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH make a difference?

SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH doesn't affect the bug, but...

Digging deeper I found that a SDL_MOUSEMOTION event is generated on right mouse button down and up, before application prematurely terminates, but not SDL_MOUSEBUTTONUP or SDL_MOUSEBUTTONDOWN.

Two Android mouse buttons were not mapped to SDL mouse buttons. This might have been the reason that there was a motion event without a button event.

The mapping was added here:
https://hg.libsdl.org/SDL/rev/0052384f717f

Thanks - that's a good patch. Tried it but no change, still only movement events and no button events.

Just to clarify: the same physical mouse right button will work on some platforms (4.3), but causes this bug on others (4.1.1 & 4.2.2).

Just to add more thoughts to the pot:

The physical right mouse button behaviour in non-SDL2 apps behave like pressing the back button across all versions of Android that I have tested. So if I were to guess, it might be something changed in the API at level 18 that SDL is missing. I would need to test on more versions to shed more light though.

I've found the problem. I'm completely new to bugzilla, Mercurial and Java, so bare with me please.

On API level <14 the only mouse button according to the activity is a left mouse button. The kernel invokes onBackPressed() when the right mouse button is pressed.  SDL2 doesn't catch this in any way, hence the application closing prematurely. There is no way to intercept this in SDL2.

The solution is to add:

@Override
public void onBackPressed() {
/* generate a fake right mouse button event here ?*/
}

to SDLActivity.java.

I've tested it and it stops the app from closing prematurely. As far as I can tell, the only time OnBackPressed() will be called is when the right mouse button is pressed, so it's safe to assume this and generate a fake right mouse button event. In all other cases, it seems all the mouse buttons and back buttons are caught correctly by SDL2 and converted into the corresponding events.

Would someone be able to confirm and action this change?

Ryan: if you're listening, would this affect this fixme in SDLActivity.java? "FIXME: dump this SDK check after 2.0.4 ships and require API14.".

Android's MotionEvent documentation has a note that the system may send KEYCODE_BACK events for BUTTON_BACK.

It would make sense that in this case the KeyEvent would be of SOURCE_MOUSE instead of SOURCE_KEYBOARD. The method onKey() in class SDLSurface (in "SDLActivity.java") would get the event but ignore it because it is not of SOURCE_KEYBOARD. It would return "false" and the event would therefore be handled by the system. And the system calls onBackPressed() by default.

This would mean that not handling a KEYCODE_BACK event would be the actual fault.

Yes, temporarily changed onKey() to return true, which stops the app closing on right mouse button.

So, what's the best way to fix this?

Maybe a "translation" of the key event into a mouse event could be added in onKey().

Something like (does not compile):

        if ((event.getSource() & InputDevice.SOURCE_MOUSE) != 0) {
            // On some devices key events are sent for mouse BUTTON_BACK/FORWARD
            int action = event.getAction();
            int mouseButton = -1;
            if (keyCode == KeyEvent.KEYCODE_BACK) {
                mouseButton = MotionEvent.BUTTON_BACK;
            } else if (keyCode == KeyEvent.KEYCODE_FORWARD) {
                mouseButton = MotionEvent.BUTTON_FORWARD;
            }
            int mouseAction = -1;
            if (action == KeyEvent.ACTION_DOWN) {
                mouseAction = MotionEvent.ACTION_DOWN;
            } else if (action == KeyEvent.ACTION_UP) {
                mouseAction = MotionEvent.ACTION_UP;
            }
            if ((mouseButton != -1) && (mouseAction != -1)) {
                SDLActivity.onNativeMouse(mouseButton, mouseAction, ...);
                return true; // because event was handled
            }
        }

"SDL_androidmouse.c" would need to be adapted to handle an event without mouse coordinates.

There is another problem with the current implementation which maybe should be fixed first (to prevent some work). It was written as if it would get the number of a button from the Java side but actually it gets the state of all buttons. That is why it should not work if more than one button is pressed at once.

For the workaround here, this information is not available. Only if BUTTON_BACK or BUTTON_FORWARD was pressed. So the implementation needs to be fixed to provide the state of the remaining buttons (though the workaround might not be needed on devices where pressing more than on button actually works :).

Philipp, I came across the same problems when attempting to hash my own fix. For now, I'm calling my own fake right mouse button NDK C function from onBackPressed().

What usually happens now? Does someone volunteer to make a patch? I don't have the authority; I'm completely new here.

(In reply to Anthony from comment #11)
> What usually happens now? Does someone volunteer to make a patch? I don't
> have the authority; I'm completely new here.

If someone makes a patch, post it right here with the "Add an attachment" link and we'll see what the best route to getting it into SDL is from there (it might be good and we apply it right away, it might need little changes, etc).

--ryan.

The simple fix was added here:
https://hg.libsdl.org/SDL/rev/d710a7a66aa5

It should fix finishing the Activity on the devices with API 16 and 17 (said to be the ones with the problem) and the right mouse button should do nothing now.

To improve this and get mouse events from key events, the handling of multiple buttons should be fixed first (I think, see above :).

Created attachment 2365 [details]
patch for multiple buttons at the same time not working

The attached patch may fix the mouse events and state if more than one button was pressed at the same time.

This limitation was already noted in bug 1666 and there seem to have been no complaints since then (which could mean that the functionality is not used or somehow not broken at all).

I did not (can not) test this patch (but it compiles and also could work if I understood the documentation correctly).

There was no new Bugzilla entry created for this patch because I think that it is related enough to bug 3227 here.

This patch is added, and the original bug should be fixed.
https://hg.libsdl.org/SDL/rev/11c69137bfd5

Please let me know if the original bug needs more work!

Hi again guys, I'm back after 2 years unable to use the Android build until recently, so I'm able to report on this bug now. 

No crash / force close = good!

No right mouse button events being generated on 2 of the 3 physical devices I've tested:

4.2.2 (Api 17) no mouse event.
6.0.1 (Api 23) mouse event - this is my Cyanogen modded phone if that makes a differece. 
7.0 (Api 24) no mouse event.

Left click mouse events and movements come through as normal though.