Expose JavaVM and Activity reference that can be used to make JNI calls

[rib]

So that we can port crates away from the ndk-context crate we should expose the JavaVM and Android Activity reference needed for applications to use JNI to also call Java/Kotlin APIs from their native code.

One reason why we want to deprecate the ndk-context crate is that it relies on global static state for sharing the Activity reference which makes it impossible to support applications that may have more than one native activity running in the same process.

[MarijnS95]

@rib is the intent to have "random" crates (app_dirs2 comes to mind) take an AndroidApp to extract these and suddenly be locked in to android-activity version cadence, or rather pass the "untyped" *mut c_void directly (via the user of both crates) in a builder pattern as suggested in #58 (comment)?

[rib]

@rib is the intent to have "random" crates (app_dirs2 comes to mind) take an AndroidApp to extract these and suddenly be locked in to android-activity version cadence, or rather pass the "untyped" *mut c_void directly (via the user of both crates) in a builder pattern as suggested in #58 (comment)?

Ideally I think crates like app_dirs2 probably shouldn't depend on the android-activity crate (that could actually create a versioning nightmare, similar to how lots of crates used to depend on ndk-glue before ndk-context existed - since there can only be one version of android-activity linked into an application)

Instead it should either be possible to initialize app_dirs2 based on the raw pointers or based on the jni types &JavaVM and &JObject (ideally both, to give users flexibility with where they acquire the JNI pointers from)

This way it's the application that glues these things together and they can decide whether they will e.g. use android-activity or maybe just JNI_OnLoad or ndk-context etc

[MarijnS95]

since there can only be one version of android-activity linked into an application

At least explicitly passing app: AndroidApp will result in a compiler error as the two types come from different versions of the same crate (or the exported symbol will clash) instead of vague runtime errors we used to get before introducing ndk-context. But yes, you wouldn't want every crate needing the VM/Activity depend on the "entrypoint" android-activity crate.

ideally both, to give users flexibility with where they acquire the JNI pointers from

Sounds good, it already uses the jni crate internally after all.

This way it's the application that glues these things together and they can decide whether they will e.g. use android-activity or maybe just JNI_OnLoad or ndk-context etc

Yup that is exactly my suggestion, specifically regarding "android"-targeted apps that might as well run within Termux but not have access to the Context/Activity (nor any JNI/NDK APIs). That is also a downside; more manual labour for crates that used to "work out of the box" (if sometimes giving unexpected results).