Our current approach-du-jure uses callback handles in combination with channels to let the ffi code trigger a real rust future's completion. This has worked reasonably well, but I'm sure we'll experiment with a few other patterns.
We don't specifically interface with Java Futures (no particular reason other than it hasn't seemed necessary to add that complexity), but that would be a pretty cool library to build on top of the existing Rust jni crate.
One thing I'd like to pass by the Rust community is our internal "teleporter" that allows you to borrow an object mutably on one thread and then "teleport" an immutable ref to that object to any other thread using only a u64 handle (with obviously huge unsafe flags). This has been very handy for some of our async ffi work.
I'm hoping to get a few more Rustaceans onboard (aggressively hiring!) over the next few months so we can focus more deeply on some of these interesting problems.
Instead of doing JNI calls, send Android messages between NDK and Framework threads.
There is the setup of MessageHandler on both sides, but long term they are more productive than JNI boilerplate.
One example would be SDL, although they use a mix of JNI and messages (search for SDLCommandHandler).
http://hg.libsdl.org/SDL/file/abb47c384db3/android-project/a...
http://hg.libsdl.org/SDL/file/abb47c384db3/src/core/android/...
EDIT: Sorry forgot about the C side (counterpart is Android_JNI_SendMessage).
Would love to see a blog post (or better yet, library!) for this - sounds interesting!