Expand description
Abstractions for Rust access to Android state (native Java objects) managed by UI toolkits.
§Usage of this crate
This crate exists for two kinds of downstream users:
- The UI toolkit that exposes its key internal states that hold the current Android activity being displayed and the Java VM / JNI environment. Either the UI toolkit or the app itself should set these states on startup, either by using ndk-context or by activating a feature for a specific UI toolkit.
- The platform feature “middleware” crates that need to access the current activity and JNI environment from Rust code in order to interact with the Android platform.
§Supported UI toolkits
- Makepad: enable the
makepad
Cargo feature. - UI toolkits compatible with ndk-context: supported by default.
- Others coming soon! (in the meantime, see below)
§Usage of this crate for other UI toolkits
For any other UI toolkits that support ndk-context, you don’t need to enable any cargo features.
However, either your application code or the UI toolkit must manually initialize the Android context
owned by ndk-context, i.e., by invoking initialize_android_context()
.
Some UI toolkits automatically do this for you, typically via the ndk-glue crate.
Modules§
- Re-exports of low-level pointer types from the
jni-sys
crate.
Structs§
- FFI-compatible JNIEnv struct. You can safely use this as the JNIEnv argument to exported methods that will be called by java. This is where most of the magic happens. All methods on this object are wrappers around JNI functions, so the documentation on their behavior is still pretty applicable.
- Wrapper around [
sys::jobject
] that adds a lifetime to ensure that the underlying JNI pointer won’t be accessible to safe Rust code if the object reference is released. - The Java VM, providing Invocation API support.
Enums§
Functions§
- Invokes the given closure
f
with the current JNI environment and the current activity.