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
Anthony