Is the knowledge behind android_native_app_glue.c documented in NDK guides?

[rnikander]

I'm working on using Rust for a native app. I tried using the android-activity crate but it appears they didn't expose MotionEvent history, which I need. So I went to look at the implementation of that crate, to see about rolling my own. It uses the ndk and ndk-sys crates (FFI wrappers of the NDK) and appears to implement a Rust version of this file: android_native_app_glue.c

That file seems to contain know-how that I don't see documented in the NDK Guides. For example, they create a new thread in ANativeActivity_onCreate and use that new thread for the native event loop. This is different from iOS where my Objective-C and Rust code all runs on the same "UI/main" thread. Is this kind of thing documented somewhere, or should I just try to learn from what's in android_native_app_glue.c?

[DanAlbert]

https://developer.android.com/games/agdk/game-activity is probably as close as it gets, since that's the successor to the file shipped in the NDK. We keep the one in the NDK around to avoid unnecessarily breaking builds (and even our NDK samples haven't all migrated to game activity yet), but any new feature development goes into GameActivity. I'd recommend that whatever Rust does follow the model of using their own AppCompatActivity subclass rather than using NativeActivity, for the same reasons explained on that page. NativeActivity looks good enough and simpler at first, but most developers found it pretty ill fit once their apps started needing more than the bare-bones provided by NativeActivity. For either implementation though, yeah, just reading through the code is probably the best you'll find. I'm not an expert in either but I've usually found the answers I need pretty quickly by just checking that source file.

For your specific question of why android_main runs on a separate thread unlike other platforms, that's because Android apps don't actually have a main() like other platforms (idk how iOS works, so maybe that's not true there either). native_app_glue does its best to pretend that Android apps have a main() entry point and that the event loop looks more like a Windows message loop, but that's not actually how the Android activity lifecycle works: https://developer.android.com/guide/components/activities/activity-lifecycle. If a new thread were not started, you'd never exit the onCreate() stage of the lifecycle.

Like I said I'm not an expert at this, but I think trying to hide that detail from the developer is probably a mistake. If I were writing native_app_glue from scratch I think it'd be a C++ class parallel to AppCompatActivity so the lifecycle behaviors are just as clear on both sides of the JNI boundary, and doing so would also get rid of that implicit extra thread. I suspect the low level crates in Rust should do that, and leave any attempts at presenting a consistent cross-platform app lifecycle model to a crate that sits on top of that.

[DanAlbert]

Just in case, I've sent this thread to someone that's more experienced on the framework side of this. The only reason I know anything at all is because I occasionally do maintenance work on the NDK samples, I'm otherwise mostly a Python developer. I'll let you know if he thinks my ideas are terrible 😆

[DanAlbert]

He confirmed everything I said, so give it a shot and lmk how it goes!

[rnikander]

For the more performance sensitive events there are NDK APIs for that which are separate from the activity lifecycle events. Choreographer, input

It appears that that "input" link has stuff for MotionEvent. That's one case I'm worried about, since I'm dragging a stylus across the screen quickly. Are you saying that in that case that NDK API will give a way to receive those events that avoids the JNI cost, which I would incur if I implemented Activity's onTouchEvent in Java and then called Rust?

The code for GameActivity, which I was just reading, seemed to have JNI code that simply forwarded Activity.onTouchEvent to the C/C++ world, copying the MotionEvent into an equivalent C struct and then into a buffer, so I'm not sure why it would do that if there were a faster way to receive and handle that event via this other API. (?)

Thanks again - the links and info above are very helpful.

[rnikander]

He confirmed everything I said, so give it a shot and lmk how it goes!

Will do. 👍

[DanAlbert]

It appears that that "input" link has stuff for MotionEvent. That's one case I'm worried about, since I'm dragging a stylus across the screen quickly. Are you saying that in that case that NDK API will give a way to receive those events that avoids the JNI cost, which I would incur if I implemented Activity's onTouchEvent in Java and then called Rust?

That's my understanding, yeah. You'd have to go digging through the OS's source to know for sure. The real answer is the same as it always is whenever performance is a concern: run the profiler and write benchmarks.

It looks like the Java API for gestures is more complete than the native one, so keep that in mind. The NDK has the low level tools that'll let you build your own code to recognize more complicated gestures, but Java has https://developer.android.com/develop/ui/views/touch-and-input/gestures/detector#detect-all-supported-gestures. You could reimplement that yourself in Rust, but I suspect the platform's already spending the time to recognize those gestures and send them to the app regardless of whether or not the app is listening, so ignoring it and doing it yourself may not even be better for perf than just coping with the JNI transition.

The code for GameActivity, which I was just reading, seemed to have JNI code that simply forwarded Activity.onTouchEvent to the C/C++ world, copying the MotionEvent into an equivalent C struct and then into a buffer, so I'm not sure why it would do that if there were a faster way to receive and handle that event via this other API. (?)

iirc one of the major motivations for replacing NativeActivity with GameActivity was specifically the problem that the old versions of NativeActivity that were still running on old phones weren't capable of handling some of the newer input stuff. Might be related. I wasn't closely involved and don't really know much about the input subsystems myself.

It could also be the case that GameActivity wanted to support OS versions older than whatever version added the equivalent input APIs to the NDK, and it was easier (or even just more consistent) to just always do that via JNI than having both JNI and NDK code paths. Most of the input APIs have been around for a long time though, so idk if that's actually a concern or not.

In either case, you can definitely still use the NDK input APIs and ignore the onTouchEvent from GameActivity if that fits your needs better. Like I said though, measure it.