When loading libraries the `SDL.mContext` is still `null`. This results in
relinker code path in `SDL.loadLibrary(...)` always throwing a null exception
and fallbacking to system loader.
Fix it by passing the context explicitly.
(cherry picked from commit 6a2dd96ac7)
Custom theme file exists in project, but is not used by app, which is kinda unintuitive. Using it by default so people who not familiar with Android development won't spend lots of time troubleshooting.
https://developer.android.com/reference/android/content/ComponentCallbacks#onLowMemory()
> Preferably, you should implement ComponentCallbacks2#onTrimMemory from ComponentCallbacks2 [...].
> That API is available for API level 14 and higher, so you should only use this onLowMemory() method as a fallback for older versions.
Since the SDL3 min api level is 19, there's no need for `onLowMemory()` compat.
This does something a little weird, in that it doesn't care what
`__ANDROID_API__` is set to, but will attempt to dlopen the system
libraries, like we do for many other platform-specific pieces of SDL.
This allows us to a) not bump the minimum required Android version, which is
extremely ancient but otherwise still working, doing the right thing on old
and new hardware in the field, and b) not require the app to link against
more libraries than it previously did before the feature was available.
The downside is that it's a little messy, but it's okay for now, I think.
When converting normalized coordinates to pixel coordinates, the valid range is 0 to (width or height) - 1, and the pixel coordinate of width or height is past the edge of the window.
Fixes https://github.com/libsdl-org/SDL/issues/2913
I've added an additional patch that expands on the same basic idea as the first one; it makes SDLInputConnection and DummyEdit into public classes so that they can be overridden from the Xamarin end if their functionality needs to be extended. (In my case, I need to change the type of software keyboard that's displayed.)
Fixes https://github.com/libsdl-org/SDL/issues/2785
This patch adds a new createSDLMainRunnable() method to SDLActivity.
Currently, SDL on Android expects to find SDL_main somewhere in native code. When using SDL in a Xamarin application, however, what we really want to do is write our entrypoint in managed code. The easiest way to do this is to allow subclasses of SDLActivity to provide their own Runnable to the SDL thread, as in the attached patch.
Fixes https://github.com/libsdl-org/SDL/issues/2785
This involved moving an `#ifdef` out of SDL_audio.c for thread priority,
so the default ThreadInit now does the usual stuff for non-Android platforms,
the Android platforms provide an implementatin of ThreadInit with their
side of the `#ifdef` and other platforms that implement ThreadInit
incorporated the appropriate code...which is why WASAPI is touched in here.
The Android bits compile, but have not been tested, and there was some
reworkings in the Java bits, so this might need some further fixes still.
Also renamed SDL_GetDisplayOrientation() SDL_GetDisplayCurrentOrientation()
The natural orientation of the primary display is the frame of reference for accelerometer and gyro sensor readings.
C SDLmain() thread might have started (mSDLThread.start() called)
while the SDL_Init() might not have been called yet,
and so the previous QUIT event will be discarded by SDL_Init() and app is running, not exiting.
This is reprocible by adding instrumentation code in the SDLActivity.
And hopefully, this could fix an ANR, where SDLActivity is in WAITING state (in thread.join()):
at java.lang.Thread.join (Thread.java:1519)
at org.libsdl.app.SDLActivity.onDestroy (SDLActivity.java)
while SDLThread seems to be running
