Crate android_activity

A glue layer for building standalone, Rust applications on Android

This crate provides a “glue” layer for building native Rust applications on Android, supporting multiple Activity base classes. It’s comparable to android_native_app_glue.c for C/C++ applications.

Currently the crate supports two Activity base classes:

1. NativeActivity - Built in to Android, this doesn’t require compiling any Java or Kotlin code.
2. GameActivity - From the Android Game Development Kit, it has more sophisticated input handling support than NativeActivity. GameActivity is also based on the AndroidAppCompat class which can help with supporting a wider range of devices.

Standalone applications based on this crate need to be built as cdylib libraries, like:

[lib]
crate_type=["cdylib"]

and implement a #[no_mangle] android_main entry point like this:

#[no_mangle]
fn android_main(app: AndroidApp) {

}

Once your application’s Activity class has loaded and it calls onCreate then android-activity will spawn a dedicated thread to run your android_main function, separate from the Java thread that created the corresponding Activity.

AndroidApp provides an interface to query state for the application as well as monitor events, such as lifecycle and input events, that are marshalled between the Java thread that owns the Activity and the native thread that runs the android_main() code.

Main Thread Initialization

Before android_main() is called, the following application state is also initialized:

1. An I/O thread is spawned that will handle redirecting standard input and output to the Android log, visible via logcat.
2. A JavaVM and Activity instance will be associated with the ndk_context crate so that other, independent, Rust crates are able to find a JavaVM for making JNI calls.
3. The JavaVM will be attached to the native thread
4. A Looper is attached to the Rust native thread.

These are undone after android_main() returns