-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crashes on re-launch #58
Comments
That is because neither |
@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 Are you just trying open, then close and then re-open one application based on a single Activity using Currently android-activity calls Just trying to think of how your app might not be cleanly exiting from As an experiment maybe you could build against a local patched version of android_activity that adds some 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 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 |
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 |
Yeah we can probably look at opening PRs for projects depending on 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 |
I see it as two separate issues:
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. |
|
Fwiw we had one issue on |
Sorry for the late reply! Having this crate be the source of the Seems complex to explicitly pass the context around, unless there's some big benefits to it. The way |
For reference here, I've just opened #61 which adds APIs that make it possible to get the
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 Dealing with breaking API changes with |
Taking a quick look at 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 That would avoid the need to resort to I'm currently just a bit unsure about exposing |
I think that's a solid plan Passing an Maybe something like |
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 |
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 |
Right, yes, I forgot to mention the |
I think if you only need the global application context you may already be able to access that just via a I would guess that crates are more likely to need the |
So for this are you imagining keeping something like |
The issue at the moment with |
Yeah, if we're trying to come up with a pattern for crates like It seems like the |
Okay we can get static access to the
Perhaps, I'm only familiar with
That seems like a necessity unless this is associated with an entire process at once and can be retrieved
I'm all for explicitly passing it ( |
Quick testing shows that at least |
I don't think so no. The generic mechanism JNI provides is the ability to export a Having a crate like |
I suppose that makes sense, directory constants are generally app centric. On the other hand I'd guess that enabling something like |
yep, this sounds like it'd be a pretty nice approach, that could avoid needing I have some nagging concern about exposing the If the The |
Yup, I expected/hoped for that.
That could mostly go straight to an
Fair enough, so we'd keep |
"ndk-context" does end up being a pretty terrible name for the crate if we remove the |
Yes and yes :) |
I wonder if it'd make sense to create a tiny replacement under the Not exactly related but Being able to share the |
And that |
When my app is relaunched I see:
After some digging around it looks like that line of code in
idk-context
is called in this crate'sonCreate
. Should we check to see if there is already a context created beforehand? (if that function is supposed to be called after a suspend)The text was updated successfully, but these errors were encountered: