Maintenance status

[djc]

It looks like there hasn't been much work done on this crate for the last year or so.

Are there still maintainers around who have time to review PRs, or should folks use other crates?

[djc]

@rib it looks like you have permissions here. For Hickory DNS, it would be great if we could get a an alternative ndk_context::try_android_context() that yields a Result instead of panicking. If I submit a PR, could you get it merged and released?

[rib]

Hey @djc, ndk-context is actually in another repo here: https://github.com/rust-mobile/ndk-context and I think @dvc94ch is currently the only person that can publish changes. @MarijnS95 did ask about enabling shared access in the past here: rust-mobile/ndk-context#2 but there hasn't been a response.

But, yeah, this issue of not being able to gracefully check whether ndk-context is initialized is a long-standing design issue unfortunately. There are even a few PRs already open that have looked at addressing this: https://github.com/rust-mobile/ndk-context/pulls

I guess the original assumption here was that, if you're running some code on Android then there would be some kind of application framework that you're using (e.g. android-activity or wry) and that would be the thing that would ensure ndk-context is initialised before your code could run.

Considering other issues with ndk-context we had been considering creating a replacement crate under the jni-rs organisation to replace ndk-context: jni-rs/jni-rs#421 but never got around to this.

(To some extent though, the original motivation for wanting a replacement crate has diminished (at least from my pov) since android-activity now initializes ndk-context with an Application reference (instead of an Activity reference): rust-mobile/android-activity#228)

On the off chance that you see the notification @dvc94ch, is there perhaps a chance that you could give myself and/or @MarijnS95 / https://crates.io/teams/github:rust-mobile:publishers joint ownership of ndk-context on crates.io so we can look at making a release with an API like try_android_context()?

Since it looks like rust-windowing is technically still a joint owner for the ndk-context crate, maybe @MarijnS95 does actually also have permission to publish. Unfortunately though, I think @MarijnS95 may also currently be taking a break from maintaining Rust crates: rust-mobile/android-activity#95 (comment)

[dvc94ch]

you mentioned wanting to remove the context so that all that remains is the jni pointer, because each activity is its own context? how will you get the context in the future?

[rib]

Ah, hey @dvc94ch!

I don't recall exactly, but I think the initial idea was to:

1. separate the concerns, so there could be some jni-rs crate that would only provide access to a JNIEnv pointer (not Android specific).
2. and then either have another crate for sharing an Android Context reference or encourage library crates to move to a config/init model like Winit where they need to be explicitly given the Android state they need instead of depending on global static state.

At the time of considering jni-rs/jni-rs#421 then android-activity was initializing ndk-context with an Activity reference and we had since realized that that was a big mistake because it really doesn't match Android's application programming model to be assuming that there's always one Activity that can be shared via global static. This was leading to issues with trying to run more than one android_main via android-activity which would try to re-initialize ndk-context with a new Activity reference.

For applications that are based on android-activity then the recommended way to acquire a reference to the Activity would now be to get the activity from the AndroidApp that is passed to android_main (which is essentially run off the back of an onCreate for a single Activity). This was no global state is used.

Since rust-mobile/android-activity#228 I do tend to think it's probably still generally useful to continue having a crate like ndk-context that can give access to the Application Context, considering that all Android apps have an Application (even apps that just run a Service) and it can be safely treated as a global static singleton.

It's good that ndk-context never actually promised that the context was an Activity, even though a number of crates had started to make this assumption.

In retrospect I wonder if ndk-context should have specified that the Context would always be an Application reference and it would be initialized more like a OnceLock where it would be either be in an un-initialized state or it would be initialized and then guaranteed to never be changed afterwards. This is effectively how we try to treat it from android-activity now, where we wrap ndk-context initialization with a OnceLock so it will only ever be initialized once (https://github.com/rust-mobile/android-activity/pull/229/changes#diff-45f471af850e20c82d7fa80b3248a1ca0be8df53d3f2950f95b0a3ade881e674R148)