Crashes on re-launch

[matthunz]

When my app is relaunched I see:

01-15 01:03:27.582 22941 23008 I RustStdoutStderr: thread '<unnamed>' panicked at
'assertion failed: previous.is_none()', /Users/matt/.cargo/registry/src/github.com-1ecc6299db9ec823/ndk-context-0.1.1/src/lib.rs:87:5

After some digging around it looks like that line of code in idk-context is called in this crate's onCreate. Should we check to see if there is already a context created beforehand? (if that function is supposed to be called after a suspend)

[MarijnS95]

That is because neither ndk-glue nor android-activity support multiple activities, the design of ndk-context just doesn't work for that.

[rib]

@matthunz, do you know if your app tries to create multiple native Activities at the same time? I'd guess you aren't trying to do that because I'd also guess in that case that you wouldn't be able to launch the app even once.

As @MarijnS95 mentions, it's not possible to run multiple native Activities in the same process with the current ndk-context design, but maybe you can clarify a bit what you mean by "re-launch" here?

Are you just trying open, then close and then re-open one application based on a single Activity using android-activity - that's certainly supposed to work.

Currently android-activity calls ndk_context::release_android_context() after your native android_main() function returns which should usually mean that restarting that Activity in the same process would be ok if the first one exited cleanly.

Just trying to think of how your app might not be cleanly exiting from android_main() (and therefore not clearing the context pointers) - does your app maybe override panic handling and then exit with a panic? That's one possible way I could see how the context pointers might not be cleared properly.

As an experiment maybe you could build against a local patched version of android_activity that adds some println debugging here to check whether you see the context state get cleared before it panics.

It looks like we can't currently guard against this outside of ndk-context because if we read the context and it hasn't been set that will also panic: https://github.com/rust-mobile/ndk-context/blob/0eb252bf2306f6ca477430a35e88298e634c0b24/ndk-context/src/lib.rs#L84

That's pretty awkward to fix too because it's conceptually an infallible api that doesn't return an Option or Result.

The longer term idea had been that we should aim to depreciate the use of ndk-context and middleware libraries would need to have a way to be explicitly initialised with jvm/activity pointers on Android.

A good step toward this would probably be for android-activity to expose it's own AndroidApp APIs for accessing the jvm and Activity pointers that can be used for JNI.

[MarijnS95]

FWIW for me an app is relaunched when changing how it is shown, e.g. changing to freeform window or split-screen mode.

@rib looking at https://crates.io/crates/ndk-context/reverse_dependencies there are only a handful of apps making use of this, we might still stand a chance to back out of ndk-context and propose this "explicitly pass your AndroidApp object" API as PRs to them (and ndk-context might host the shared struct/helpers/documentation for this)?

[rib]

@rib looking at https://crates.io/crates/ndk-context/reverse_dependencies there are only a handful of apps making use of this

Yeah we can probably look at opening PRs for projects depending on ndk-context currently.

I briefly started looking at adding APIs to android-activity to expose the jvm pointer and activity object pointer and hopefully I can get around to finishing that soonish too.

[MarijnS95]

I briefly started looking at adding APIs to android-activity to expose the jvm pointer and activity object pointer and hopefully I can get around to finishing that soonish too.

Cool! That'd only be the start of this though, right? We probably don't want to make any crate depend on the full android-activity only for context pointer types, a wrapper in ndk-context seems most trivial. When we get rid of statics I also don't mind having dependencies on NDK/JNI crates again for better type safety (though that may pose additional strain on propagating updates through the ecosystem...).

[rib]

I see it as two separate issues:

1. middleware libs, e.g egui or winit or some random crate for permissions or file open dialog etc should stop using ndk-context and should instead provide a way to be explicitly initialised on Android with a vm pointer and activity pointer. (So in this way they dont care where these come from and they also dont necessarily care if they are being used as part of a standalone Rust app or as part of an embedded library that might be loaded from a Java app)

2. android-activity should provide some way to get the vm and activity pointers, for apps that happen to use android-activity.

There are also some other thoughts I have about making it easier to access the correct classLoader when using JNI in standalone apps which are kind of related.

Other kinds of frameworks, not based on android-activity will also need some way to access the same pointers.

[MarijnS95]

1. Yes. I don't mind whether or not we provide a standard crate to wrap or type the VM and Activity (or base Context, or both) pointers;
2. That's what you'll be implementing, right?

[MarijnS95]

Fwiw we had one issue on app_dirs2 where someone combined a compiled utility for <arch>-linux-android and expected it to run under Termux using XDG env vars. This however initially triggered the cfg logic to read Java pointers from ndk-context, but has now been worked around by looking for the respective Linuxy env vars before even trying to read the VM/context pointers; we could make that explicit with this builder-like pattern.

[matthunz]

Sorry for the late reply!
Thanks so much for the info on this, I think I understand what's going wrong now.

Having this crate be the source of the JNIEnv would be a great solution for outside crates that work with android. For example I've been working on android-intent and it would be great to have a way to get the current env or VM to make ndk calls.

Seems complex to explicitly pass the context around, unless there's some big benefits to it. The way ndk-context does this implicitly with a static variable does seem simpler

[rib]

For reference here, I've just opened #61 which adds APIs that make it possible to get the JavaVM and Activity pointers directly from an AndroidApp without necessarily using ndk-context.

Seems complex to explicitly pass the context around, unless there's some big benefits to it. The way ndk-context does this implicitly with a static variable does seem simpler

Yeah it's a bit of an awkward one. Its certainly convenient to just have a global static but that also makes it impossible to track more than one Activity per process which is something that Android supports generally.

We could potentially investigate whether we could update ndk-context to track state via thread-local storage so that it's possible to track multiple activities, and then the main limitation would be that the ndk-context would only be accessible (by default at least) from the android_main() thread.

Dealing with breaking API changes with ndk-context will also be "fun" if go that route, since we will need to ensure each incompatible version gets initialized properly from android-activity.

[rib]

Taking a quick look at android-intent linked above, and seeing the with_current_env API reminds me that I'd been thinking that if I were to add more ergonomic integration with the jni crate to android-activity that it could be good to add something similar to AndroidApp - basically a utility for using JNIEnv::with_local_frame() something like:

let result = app.jni_with_local_frame(|env| {
    Intent::new(env, Action::Send)
            .with_type("text/plain")
            .with_extra(Extra::Text, "Hello World!")
            .into_chooser()
            .start_activity()
});

Maybe the closure could also be passed the Activity reference as a &JObject

That would avoid the need to resort to unsafe to make JNI calls.

I'm currently just a bit unsure about exposing jni types via the android-activity crate since it's an unstable API and we'd need to sync releases which might be fiddly to deal with.

[matthunz]

I think that's a solid plan

Passing an AndroidApp through an app might be cumbersome but I see what you're saying about what to do with multiple activities. If there's a simple way to just grab the current activity in a closure that would be super simple to use.

Maybe something like AndroidApp::with_env with a struct that wraps references to Activity and Vm, so this crate's API could be stable, could work

[MarijnS95]

One of my ideas:

For some crates the base application context might just be enough, which we could still safely store in a process-wide static (after the first Activity was started). TLS is complicated as you're stuck with the main thread that spawned that Activity instance; any other thread would have to be explicitly associated at which point it might be desirable to just make it explicit in code as suggested above.

[matthunz]

Oh that's interesting I would like something like that. I think I understand what you're saying with multiple activities having to access their current env with TLS or a static would be really complicated as well. Having a shared base application context sounds great but I hope it's possible to get the Vm or JNIEnv that way as well