Created attachment 593 [details]
Android multitouch + thread protection

Created attachment 594 [details]
Android multitouch + thread protection

The previous patch was messed out, sorry. Here is the right one.

Created attachment 595 [details]
Patch for Android multitouch + thread protection

New clean patch with everything working (sorry for the two first, which were messed up)

Thank you very much for your patch for SDL 1.3!

Do you give me permission to release your code with SDL 1.3 and future
versions of SDL under both the LGPL and a closed-source commercial
license?

(In reply to comment #4)
> Thank you very much for your patch for SDL 1.3!
> 
> Do you give me permission to release your code with SDL 1.3 and future
> versions of SDL under both the LGPL and a closed-source commercial
> license?

Yes of course, if you give me the permission to use your library under LGPL for our commercial Android application

Of course, as long as you comply with the LGPL license by dynamically linking, etc.

A few comments:

I noticed you updated the android target from android-4 (1.6) to android-7.  This breaks compatibility with older Android phones.  Was this intentional?

Your patch to attach and detach threads from the VM adds some overhead to the SDL calls.  What was the problem you were fixing by doing this?

Thanks!

The multitouch APIs are only available since API level 5 (Android 2.1). You can downgrade the target to this (I should have done it). For older versions, the old code with mouse pointers will still work and is still available, developers will need to make a few changes in the java code if they need to support Android 1.6.

The thread attachment code doesn't add any overhead, since it's only called for when the calling thread is different from the main SDL thread. With the current code, it would crash, as the JNI environmemnt cannot be accessed from other threads. Moreover, it could be released from the main thread and this would also lead to a crash.
For more info, check this out:
http://www.google.fr/url?sa=t&source=web&cd=1&ved=0CBgQFjAA&url=http%3A%2F%2Fandroid.wooyd.org%2FJNIExample%2Ffiles%2FJNIExample.pdf&rct=j&q=android%20jni%20attachcurrentthread&ei=ZZR0TZyiCIaMswb2qZSEDg&usg=AFQjCNHwjbm09fLt2PAgFYDRjSKlL3mQTA&sig2=N7PRNFcRbEuoqhSWOdmNfA&cad=rja

API level 5 is android 2.0, forgive my mistake.

In the multi-touch code, any touch up will send touch up for all current touches.  Is that intentional?

"The thread attachment code doesn't add any overhead, since it's only called for
when the calling thread is different from the main SDL thread."

Can any number of threads be attached to the VM?  If so, is there any reason to call this after each time you attach?
mJVM->DetachCurrentThread();

Thanks!

(In reply to comment #10)
> In the multi-touch code, any touch up will send touch up for all current
> touches.  Is that intentional?

Nope. Maybe there's a bug in my code.

> "The thread attachment code doesn't add any overhead, since it's only called
> for
> when the calling thread is different from the main SDL thread."
> 
> Can any number of threads be attached to the VM?  If so, is there any reason to
> call this after each time you attach?
> mJVM->DetachCurrentThread();

You need to detach any attached thread before it ends. How can you detach it anywhere else ?

You could keep track of attached threads add maybe add code to the SDL thread cleanup to take care of it.

What is the original case that you were trying to solve?

Well, that's possible, but you can use threads that are not SDL threads, right? In that case the app would crash when the thread ends.
I need to call a SDL function that triggered Android code from a separate thread, and my app crashed, since the JNI environment is not available for other threads.

I don't think there's a need to modify the patch (except if there's a bug in the multitouch handling code). So I suggest that you add it to the trunk, as there is still a crash that can occur in the current android code. Maybe somebody could make changes later if the fix is faulty.

Multitouch for Android is now fully functional, there's a threading issue with RWops that's being dealt with in bug #1422

*** This bug has been marked as a duplicate of bug 1422 ***