One thing I’ll add from recent experience (although grain of salt, our app is stuck on ndk r10e for the time being) – backtrace-sys, openssl-sys, and a few other crates were pretty gnarly to convince to build using the old NDK toolchains – I’m assuming it’s easier on newer ones with CMake, but passing all of the correct configuration wasn’t very straightforward in my case. I based our integration heavily on https://lliwynd.blogspot.com/2018/05/rust-for-android-games-using-sdl2.html, with some changes.
Overall, though, there are a few things I learned that might prove useful to others:
CARGO_TARGET_I686_LINUX_ANDROID_LINKER=... is much more version-control-friendly than
.cargo/config values, at least for us (we have scripts to populate the correct env vars with absolute paths per dev machine, rather than everyone having to do it themselves)
- piggybacking on the android cross-compilation configuration was the only reliable way I found for being able to correctly configure & build a number of crates which build their own C or C++ code
- NDK libs and host-machine unit tests (think robolectric) are a bit rough. I used conditional compilation to separate out the JNI interface from Android-specific interfaces (logging right now) so that I can compile for the host OS and still include the JNI lib in unit tests
- I am going to update our NDK soon, come hell or high water
I was planning to write a blog post whenever this actually ships, but I saw this here and thought a quick brain-dump might be helpful to someone passing through.
We have a slightly quirky monorepo setup, so some of the paths might be confusing, but here’s a gist with the Android.mk and gradle changes I’ve used to make it work for our builds.