They were not needed internally since the switch to the common EGL backend.
Thanks to the SDL mailing list for pointing out that the functions seem unused.
This lets SDL-based apps respond to "Open With" commands properly, as they
can now obtain the requested path via a standard SDL dropfile event.
This is only checked on startup, so apps don't get drop events at any other
time, even if Android supports that, but this is still a definite
improvement.
Fixes Bugzilla #2762.
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.
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.
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.
Alexey Petruchik
Although SDL_android.h is not intended to be included by client code sometimes it needed. For example you need JNIEnv pointer to make JNI calls to modified SDLActivity.java (video playback, facebook integration, in-apps). It seems a bit weird to write:
extern "C" {
#include "SDL_android.h"
}
in my AndroidJNI.cpp file.
