my question described in Reddit…
how would you go about linking an external static native code library (i.e. containing Rust code, compiled by cargo) - which needs (presumably) to be called by the SDL2 framework , and which also must call SDL2 APIs - with C/C++ application code in an android build …
I gather that the android version of SDL2 uses it’s own Java stub, so you can’t just use a pure ‘native activity’ approach.
I can see how to compile a pure rust program for a native-activity based example… but not how to adapt the build process give by an SDL2/android native example
What would be the best way to drive such a build… hacking up an SDl2 example? writing a completely different custom makefile that would invoke bits of the NDK & other android tools , and Rust/Cargo to build rust code?
is SDL2 ever used with other AOT languages (eg go-lang?)
any advice or pointers welcome
As I mentioned in the other thread, there is no magic to
NativeActivity. It goes through Java via JNI just like SDL does (and
everybody else). This is how Android works (like it or not).
But that said, if you are just using SDL, then you can ignore the
Java/JNI stuff because SDL does that for you. Rust and pretty much all
languages can talk to the C-ABI.
As for build systems, you will be doing some hacking for Android.
For a reference, check out my Swift on Android talk. You are correctly
insightful that the process is similar with other AOT languages as
Rust. I show an example with SDL, but the talk is focused heavily on
the process of using the C-ABI to be the common communication platform
for everything. I also address JNI for dealing directly with Android
(when your library doesn’t do this for you. And I mention build
systems. (I modified CMake and Gradle/Groovy scripts.)
thanks for the link and reference…
I did manage to get this to work in the end (at least managing to prove to someone else that Rust works ok on android… I had it in the past aswell) i.e. by adding my Rust-generated native library to an SDL sample by hacking it’s makefile… but there’s so much black magic going on (e.g. i tried copying the sample somewhere else and it wouldn’t let me build it… something about how it generated it’s makefile).
Doable but so messy and hard to concentrate on the details when dealing with other platforms aswell. I can hardly remember the details… going back to it after some time away it’s difficult to even build again. Too many tools to keep track of 
I’d used pure native-activity in the past… my ideal would be to modify the stub to work directly with native-activity … but it’s too much effort just for me if it isn’t going to feed back into the community.
rust stuff is easier going through it’s own SDL-esque layer (“glutin”) but I wanted to keep my knowledge & approach centred on C/C++ native libraries with rust bindings. (since I may need to go back to C++ in other contexts)