project-robius / robius-android-env

easy Rust access to Android state (native Java objects) managed by UI toolkits

robius-android-env

This crate provides easy 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:

1. 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 manually calling the set_vm() and set_activity_getter() functions.
2. 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: enable the ndk_context Cargo feature.
• Others coming soon! (in the meantime, see below)

Usage of this crate for other UI toolkits

⚠️ Note: for wider compatibility, you should prefer the ndk-context feature instead of what is described below.

For any other UI toolkits not listed above, you don't need to enable any cargo features. Instead, your application code must manually provide two key states:

• a reference to the current Android activity.
• a reference to the current Java VM instance (and JNI environment).

This can be achieved by doing the following:

• Provide an ActivityGetterFn callback by calling set_activity_getter().
• If the ActivityGetterFn cannot provide a low-level JNIEnv object, the application must also call the set_vm() function.

robius-android-env's Issues

Overlap with `ndk-context`?

The ecosystem already has a crate that serves the (as it seems) exact same purpose: https://crates.io/crates/ndk-context. Any reason that isn't used?

Besides, we made the wrong choice in ndk-context that an Activity is a global singleton, and it looks like this crate is making the same mistake.