-
Notifications
You must be signed in to change notification settings - Fork 111
Expose nicer JNI/NDK interface #238
Comments
I definitely think that exposing the JNI would be a good thing. In terms of api,
I have no strong opinions here, but my preference is either the first or third ways.
Why particularly do you need this? (As opposed to just writing it at the start of |
// android_native_app_glue.h
/**
* This is the function that is run on startup in the main thread
* For example, to hide the navigation bars.
*/
extern void android_startup(ANativeActivity* activity, int focused);
// android_native_app_glue.c
static void onWindowFocusChanged(ANativeActivity* activity, int focused) {
LOGV("WindowFocusChanged: %p -- %d\n", activity, focused);
android_app_write_cmd((struct android_app*)activity->instance,
focused ? APP_CMD_GAINED_FOCUS : APP_CMD_LOST_FOCUS);
android_startup(activity, focused);
} which I then define in my rust code as follows:
(The code already there is a rust translation of what @philip-alldredge suggested in #234) |
We'll need to keep in mind that the JNIEnv provided by ANativeActivity cannot be shared with other threads. To create one for another thread requires using JavaVM and attaching a thread to it. In @OptimisticPeach's case, code will need to be ran at startup and on subsequent window focus changes. That should be doable in main as long as something provides a way to get or crate a valid I think an high-level set of APIs that calls a closure with a a valid jni::JNIEnv would work well for most cases. Assuming that cost must be ran on the UI thread, there should be a way to run the closure on the UI thread using Activity.runOnUiThread. My feeling is that most of this should eventually be in |
I've been working on extern crate jni;
/// An `ANativeActivity *`
struct NativeActivity { ... }
impl NativeActivity {
// other methods ...
pub fn vm(&self) -> jni::JavaVM { ... }
} It's usable like |
Yes, this would most likely solve what I'm looking for. I'll try this as soon as possible. |
I believe this should have a simple answer and I'm just missing it, but how might I acquire a Trying to use some kind of |
Yes, this does require changes to android-rs-glue to provide access to these things. That's part of the plan of #228, which I'll rebase/fix once I feel like I think that ideally, you would get a |
That sounds wonderful, meaning that I can get a pointer to it from any thread! |
Yes, this does require changes to android-rs-glue to provide access to these things. That's part of the plan of #228, which I'll get to rebasing/fixing soon. The plan is that android_glue gives you a |
Currently it is difficult to interact with the JNI and NDK through rust. This issue is asking for:
This can be mostly covered by
android-ndk-rs
but a portion of it should probably be done here.This is closer to a goal than an issue.
The text was updated successfully, but these errors were encountered: