`android-activity` should initialize `ndk-context` with an `android.app.Application` as the `Context`

[rib]

In order for Rust library crates like app_dirs2 or webbrower to be able to support Android without being tied to any specific Rust Android framework they need some minimal application state that lets them use JNI to interact with the Android Java SDK.

The current solution for this is the ndk-context crate that has a frozen "1.0" API that Rust library crates wanting to use JNI can rely on to get access to a JavaVM pointer and an android.content.Context reference.

It's then up to crates like android-activity or other Rust Android frameworks to initialize ndk-context on behalf of these library crates.

Currently android-activity satisfies this by providing a reference to the current Activity as the Context reference.

A big problem with this choice is that it implies that we need to re-initialize this state if the application ever tries to start more than one Activity, which can lead to a panic: #58

..but the ndk-context documentation specifically does not guarantee that the context reference will be for an Activity:

A handle to an android.content.Context. In most cases this will be a ptr to an Activity, but this isn’t guaranteed.

and in practice, if we look at the requirements of app_dirs2 and webbrowser we can see that neither of these actually require an Activity - they really do only need a Context reference.

(skimming the dependants of ndk-context, I would guess that app_dirs2 and webbrowser are probably the two main library use cases that we really don't want to break)

In order to avoid ever needing to re-initialize ndk-context I think we should update android-activity so that it does a one-time initialization of ndk-context with an android.app.Application reference instead of an Activity reference.

Applications based on android-activity that really need a reference to the Activity can instead get this via AndroidApp::activity_as_ptr() and other frameworks for Rust Android applications probably have their own more suitable way of giving access to any Activity they have.

[rib]

An issue with this is that startActivity() from an Application Context doesn't behave the same as from an Activity and so the webbrowser crate (which supports opening links on Android) effectively assumes that ndk-context provides a reference to an Activity :(

For the webbrowser crate to be able to open URLs via an Application context it would need to add the FLAG_ACTIVITY_NEW_TASK the the Intent before calling Application.startActivity

E.g. I found this patch worked:

diff --git a/src/android.rs b/src/android.rs
index 8c9c130..a3fff51 100644
--- a/src/android.rs
+++ b/src/android.rs
@@ -84,6 +84,18 @@ fn open_browser_default(url: &str, options: &BrowserOptions) -> Result<()> {
     )
     .map_err(|_| Error::new(ErrorKind::Other, "Failed to initialize intent"))?;

+    // Add FLAG_ACTIVITY_NEW_TASK flag
+    let flag_activity_new_task = env
+        .get_static_field(&intent_class, "FLAG_ACTIVITY_NEW_TASK", "I")
+        .map_err(|_| Error::new(ErrorKind::NotFound, "Failed to get FLAG_ACTIVITY_NEW_TASK"))?;
+    env.call_method(
+        &intent,
+        "addFlags",
+        "(I)Landroid/content/Intent;",
+        &[flag_activity_new_task.borrow()],
+    )
+    .map_err(|_| Error::new(ErrorKind::Other, "Failed to add flags to intent"))?;
+
     // Start the intent activity.
     env.call_method(
         &activity,

Technically this may also affect application UX because the back button might behave differently if the browser opens in a separate task.

..but considering that ndk-context explicitly does not promise that it provides an Activity reference it could be well justified that the webbrowser crate should consider doing this in order to avoid assuming that ndk-context is associated with an Activity.

[rib]

Technically this may also affect application UX because the back button might behave differently if the browser opens in a separate task.

..but considering that ndk-context explicitly does not promise that it provides an Activity reference it could be well justified that the webbrowser crate should consider doing this in order to avoid assuming that ndk-context is associated with an Activity.

Actually, I think this is a non-issue because for the common use case that the webbrowser crate is designed for then http/https urls are going to anyway open up in a separate browser application (and the distinction between opening in the same task as the Activity vs starting a new task will be irrelevant).

The distinction will only matter in the case of opening deep links / application-specific urls, and even then you would have to be attempting to open such a url from the application itself. At this point you're in a pretty narrow, android-specific use case and there's no way to guess which behaviour you might even want.

At some point it would also be possible to add a webbrowser::BrowserOptions method that could specify an Activity reference if some application specifically needed to open a url within the task associated with a specific Activity and relying on a global/static Activity from ndk-context is certainly not a good solution for that use case.

[rib]

For reference here, I've opened an upstream PR for the webbrowser crate to try and ensure it can handle non-Activity references coming from the ndk-context API: amodm/webbrowser-rs#111