ndk
ndk copied to clipboard
rust-mobile
vendor NativeActivity
I suspect that this would be a good first step for doing things like #128 and decoupling cargo-apk from any NativeActivity limitations.
cc @canndrew
I don't think this needs to be done. You can create a subclass of NativeActivity in Java and then add any extra Java hooks you need from there (including writing a NativeService subclass and calling native/rust-implemented methods from it). You can then call RegisterNatives from Rust to register native methods with Dalvik, and use JNI to call any Java methods you want (most likely the methods you call from JNI will be helper methods you add to your NativeActivity subclass, and then you'll call on into the Android class library from there).
The alternative to doing this would be to make a plain JNI library, define a new method for forwarding input events and setting up a GL context, and write new code to cover a lot of what the NDK already does. There are definitely places in Android where you might want to do that (like anywhere you can't have an Activity), but for most use cases the current Rust NDK bindings are probably easiest and involve making the least new code ;).
You can create a subclass of NativeActivity in Java and then add any extra Java hooks you need from there (including writing a NativeService subclass and calling native/rust-implemented methods from it).
I guess that makes sense. But cargo-apk would still need this subclass and support for compiling and including this subclass in the final apk right?
Yeah, cargo-apk doesn't know how to build Java bits, so I've been copying the shared objects it builds into a traditional Android project built with gradle (so I discard the APK built with cargo-apk, and I'd disable building the APK and manifest if I could). This way I can also use the Android tools to edit the Java code.
Yes, so the goal would be that you don't have to do that. That's what I'm suggesting in this issue. You can use cargo apk check to create just the so's.