Philipp Wiesemann
I attached a patch for an incomplete implementation of the messagebox parts.
It was not tested on lots of devices yet and features a very fragile workaround to block the calling SDL thread while the dialog is handled on Android's UI thread. Although it works for testmessage.c I assume there are lot of situations were it may fail (standby, device rotation and other changes). Also not all flags and colors are implemented.
On the other hand most uses of the messagebox are to show an error on start and fragility (or working at all) may not matter there.
Sylvain
If you play with the TouchScreen with +3 fingers randomly / pressing simultaneously all fingers.
You triggers FINGER DOWN events, but not always all the associated FINGER UP events.
So, after a while SDL_GetNumFingers() can report a wrong number of fingers pressed !
The explanation is hidden there : http://developer.android.com/reference/android/view/MotionEvent.html
Each pointer has a unique id that is assigned when it first goes down (indicated by ACTION_DOWN or ACTION_POINTER_DOWN).
A pointer id remains valid until the pointer eventually goes up (indicated by ACTION_UP or ACTION_POINTER_UP) or when the gesture is canceled (indicated by ACTION_CANCEL).
in ACTION_CANCEL :
The current gesture has been aborted. You will not receive any more points in it. You should treat this as an up event, but not perform any action that you normally would.
Constant Value: 3 (0x00000003)
Lets Android take care of which is the primary pointer (the one acting as the
mouse in SDL), reorganized the Java side code as well to make it easier to
understand.
Thanks to Denis Bernard!
Also, changed the Android manifest so the app doesn't quit with orientation
changes, and made testgles.c exit properly on Android.
This bumps the build SDK level to 12 (up from 10). Runtime requirements remain
the same (at API level < 12 joystick support is disabled).
Also enables building SDL for armv7 and x86.
Denis Bernard
Background information: http://developer.android.com/reference/android/hardware/SensorEvent.html#values
Steps to reproduce: compile testjoystick.c as an android app (change screen size according to your device). While running the app, also run:
adb logcat -c; adb logcat -s 'SDL:*' 'SDL/APP:*'
When tilting the device left/right, the joystick moves in the opposite direction of what one would expect. Or at least, the behaviour is not consistent with the Y axis.
Also when the device sits on a table (obviously not moving), the Z axis value oscillates between -32000 and +32000 (by overflow):
I/SDL/APP ( 1994): Joystick 0 axis 2 value: 32511
I/SDL/APP ( 1994): Joystick 0 axis 2 value: 32575
I/SDL/APP ( 1994): Joystick 0 axis 2 value: 32383
I/SDL/APP ( 1994): Joystick 0 axis 2 value: -32386
I/SDL/APP ( 1994): Joystick 0 axis 2 value: -32450
I/SDL/APP ( 1994): Joystick 0 axis 2 value: -32578
This is caused by the accelerometer yielding a constant value around 9.81 for Z and feeding something like 0.9 to 1.1 to the joystick driver, resulting in the overflow.
Proposed fix in SDLActivity.java (swap X and subtract G from Z reading)
Denis Bernard
Background information: http://android-developers.blogspot.fr/2010/09/one-screen-turn-deserves-another.html and http://developer.android.com/reference/android/hardware/SensorEvent.html
Right now, the Android accelerometer event handler feeds raw accelerometer data to the SDL Joystick driver. The result is that for landscape-only applications, the axis need to be swapped if running on a portrait device (like a phone), and vice-versa: running a portrait only app on a landscape device like a tablet.
The purpose of this patch is to perform coordinate remapping of the accelerometer data before feeding it to the SDL joystick driver so that the X axis of the joystick is always aligned with the X axis of the display, same for the Y axis.
This has been tested on applications that support screen orientation changes as well as applications with fixed screen orientations, both on phones and tablets.
Denis Bernard
This patch to Android.mk adds support for static linking of libSDL for Android applications. A patched readme with static build instructions is also provided.
It does not break existing build environments setup according to the README-android.txt since the static library version will not be built in not required.
The static build uses the Android NDK module system (see docs/IMPORT-MODULE.html in the NDK folder and step 5 in the instructions below).
Instructions:
1. Copy the android-project directory wherever you want to keep your projects
and rename it to the name of your project.
2. Create a symlink to SDL/src/main/android/SDL_android_main.c as
<project>/jni/src/SDL_android_main.c
3. Rename <project>/jni/src/Android_static.mk to <project>/jni/src/Android.mk
(overwrite the existing one)
4. Edit <project>/jni/src/Android.mk to include your source files
5. create and export an environment variable named NDK_MODULE_PATH that points
to the parent directory of this SDL directory. e.g.:
export NDK_MODULE_PATH="$PWD"/..
6. Edit <project>/src/org/libsdl/app/SDLActivity.java and remove the call to
System.loadLibrary("SDL2") line 42.
7. Run 'ndk-build' (a script provided by the NDK). This compiles the C source
Although this requires an environment variable to be setup, it can be added once and for all to the main Android.mk of the project.
On Android available touch devices are now added with video initialization (like
the keyboard). This fixes SDL_GetNumTouchDevices() returning 0 before any touch
events happened although there is a touch screen available. The adding of touch
devices after a touch event was received is still active to allow connecting
devices later (if this is possible) and to provide a fallback if the new init
did not work somehow. For the implementation JNI was used and API level 9 is
required. There seems to be nothing in the Android NDK's input header (input.h)
to implement everything on C side without communication with Java side.
