Android `RecreationAttempt` on Activity reopen

[SnowyCoder]

When an android app calls event_loop.exit() the application exits, but if the application is opened again without closing it in the "recent apps" the EventLoop creation will fail with a RecreationAttempt error.

Steps to reproduce

• clone https://github.com/SnowyCoder/winit-bug-reopen-example
• run in an android phone
• press back button
• reopen app

Reported error

called `Result::unwrap()` on an `Err` value: RecreationAttempt

Repo explaination

The repo linked in the "Steps to reproduce" section is a modified version of the one linked in the README android section.
I just updated the dependencies and linked BrowserBack to event_loop.exit() (that sems to be the logical key invoked when the android back button is pressed).

Comment

The general problem seems to be that android_main can be called more than once without unloading and reloading the native library (ex. if we use an application with two interacting activities, say LoginActivity and GameActivity).

[daxpedda]

See #2344 (comment), which points out how this can happen on Android.

But generally speaking this is the intended behavior by Winit, you just have to figure out how to avoid having to recreate the event loop.

Let us know if this solves your problem!

[SnowyCoder]

I read that conversation and it doesn't really say how to solve the issue, I've tried various approaches but haven't yet had success. Is there any example Android app that has this bug solved?

Here are my attempts:

1. First thread creates the event loop, saves it in a const and next threads use that loop.
   Cannot work since event loops cannot be shared across threads
2. Since that conversation talks about not creating the loop in the fake main function, create a common thread that manages the event loop and when a new invocation occurs it calls into the common thread
   Does not work since the new thread does not have an attached looper
3. Let the first thread create the event loop and keep it alive as a "common thread" like in the second approach, reusing that event loop for the next invocations.
   Since the main thread never exits the app stops responding (I'm blocking the UI thread?)

I think that the "best" approach would be to augment the second point, spawn a new common thread that manages the event loop and manually create a looper out of it. But it involves nasty low-level JNI calls and I'm not even sure if it would really work.
If we let android recreate its event loop once it exits is, to me, the most elegant option.
(tested it commenting the RecreationAttempt line, doesn't show any sign of error).

TL;DR: I tried, but I have no idea on how to get it working without recreating the event loop or calling JNI stuff.

[MarijnS95]

Per the linked comment, after previously muddling along with these issues in ndk-glue for a while, none of those design issues were addressed when android-activity was created 😩

Blindly recreating the loop when a new activity is created seems appalling. Consider activities to be analogous to Windows. Your scenario concerns "closing" one activity (I think) and then later having a new activity opened. However, it is also possible to have multiple activities opened at the same time.

Fwiw I think exiting the loop and returning out of android_main() causes your activity to be closed because of rust-mobile/android-activity#67 / rust-mobile/android-activity#81. Also notice that the callback function from Android here is called ANativeActivity_onCreate() which is not analogous to something called main(), yet pretends to be used as such.

---

We'll need to be more thoughtful how to handle that across the winit and android-activity bindings. You'll see the ANativeActivity_onCreate() callback in android-activity is already creating a thread to run your android_main() and the event loop in. That's likely the thread that will have to stay alive to process incoming window creation requests through ANativeActivity_onCreate(), until the process exits.

Then, we'll likely need a "New Window Created" event in winit to process this (and make the Window impl for Android a less-empty shell), and also improve the Suspended/Resumed events to operate per-surface (should be a 1:1 mapping with an activity) instead of just globally.

This means that creating a new window in winit will no longer do what you expect, and we'll have to craft some careful bindings around it.

[MarijnS95]

https://developer.android.com/guide/topics/manifest/activity-element#lmode may also be relevant here.

[mvvvv]

I'm experiencing this issue with OpenXR on the Meta Quest. Your thread explains well why Meta discourages exit by the application and asks to systematically use the "Meta" button which pauses and allows Resume or Quit.
My problem is that not all other platforms have this button.

[paulzhang5511]

#3948

[SolidTux]

I'm also running into this issue when trying to get deep links to work. There you are basically guaranteed to run into this problem.

[Rustacian]

It would be great if this could be solved for Windows apps as well.
Should I create a separate issue for it?

[kchibisov]

If you need to re-run loop, use API that does so, like run_on_demand.

[Johannes0021]

I ran into a similar problem where the Android MainEvent::Destroy event didn't properly exit the
event loop, preventing android_main() from returning.

With a workaround I managed to make android_main() return, but if the app wasn't swiped away
from recent apps, it leads to the issue described in this thread.

What worked for me was calling System.exit(0) via JNI to fully terminate the process.
Not sure if that's the recommended approach, but it solved the problem for me.

Related issue: #4303

#[no_mangle]
fn android_main(android_app: AndroidApp) {
    // Do winit stuff...

    let vm = unsafe { jni::JavaVM::from_raw(android_app.vm_as_ptr() as *mut jni::sys::JavaVM) }
        .expect("Failed to create JavaVM from raw pointer!");

    let mut env = vm.attach_current_thread()
        .expect("Failed to attach current thread to JavaVM!");

    let system_class = env.find_class("java/lang/System")
        .expect("Failed to find java/lang/System class!");

    env.call_static_method(system_class, "exit", "(I)V", &[jni::objects::JValue::Int(0)])
        .expect("Failed to call System.exit(0)!");
}