is there a reason why SDL2 on android relies on a java stub, rather than just being a library designed to slot into a NativeActivity app… wouldn’t this simplify the build process and setup (i.e you could have a project which is entirely native code - just the sdl2 so and your main so )
(i figured there might be a reason like it needs certain events which aren’t exposed through NativeActivity? … or is it to streamline setting up bits of platform UI ? )
All Android apps must go through Java, which includes
NativeActivity. There is nothing special about NativeActivity. It is
implemented like SDL, where it goes through JNI to operate with the
proprietary Android/Java APIs needed to make an Android app work.
NativeActivity has a long history of not being terribly good and
neglected. Historically, it was never a built-in library in the
convenient, but something you would have to figure out how to build
into your own project & build system. Since there was no advantage to
using NativeActivity, most competent games and engines implemented
their own interface, like SDL.
the issue I’m having is it complicates matters elsewhere, i.e. i can’t just bring in a native SDL library to combine with my core application (itself compiled as a library by another language/toolchain - rust)… it would be simpler just to bring in the SDL library to a final build step to link it. rust+c+java vs rust+c
right but what I discovered is that ‘NativeActivity’ is sort of in-built, such that you can package a pure native library and the system will use NativeActivity to load it for you without having to have any Java in your app;
I just wondered if there was any specific support missing form NativeActivity that drove the choice to include a custom java stub in SDL2 on android
Opening a URL, sharing a screenshot, opening an ad, setting Google Play achievements / leaderboard. Plus many more things need to be done on the Java side. The stub already has something set up that you inherit from to do all of this by overriding without having to edit any SDL2 files. It works, don’t break/fix it.
Would it be possible via a #define or something to support 2 codepaths (pure native-activity vs current stub with extended support)…
I had considered trying to do this for myself but figured it’s too much effort if it isn’t shared (vs just suffering the messy build)
Does SDL2 already attempt to provide cross-platform wrappers for the behaviours you describe there , or do people usually stick to some mix of SDL & their own app side #ifdef’s for all that … they do sound a bit too specific and beyond the scope of SDL itself I guess.