Bevy cannot run in the background on Android

[NiklasEi]

Bevy version

main (b61397e) and latest release (0.11.2)

What you did

Run the android example on a real device (Samsung Galaxy S10+). Now press the home button to minimize the app, then open it back up.

What went wrong

The App quits (at least logs do not indicate a crash) and will start from the beginning when reopened.

Additional information

This is a known problem (see some general discussion about life cycle handling in #86), but I couldn't find an open issue for it.

[griffi-gh]

Android destroys all active gl/vulkan surfaces when an app is suspended.
To fix this issue Suspended and Resumed winit events need to be handled properly, suspending rendering pipeline (Or fully blocking the evnt loop? which is much easier to implement and makes a lot of sense) on Suspended and replacing the target surface with a new one on Resumed.

[griffi-gh]

at the moment this is handled by just closing the app whenever it's suspended

bevy/crates/bevy_winit/src/lib.rs

Lines 663 to 674 in b88ff15

	event::Event::Suspended => {
	runner_state.is_active = false;
	#[cfg(target_os = "android")]
	{
	// Android sending this event invalidates all render surfaces.
	// TODO
	// Upon resume, check if the new render surfaces are compatible with the
	// existing render device. If not (which should basically never happen),
	// then try to rebuild the renderer.
	*control_flow = ControlFlow::Exit;
	}
	}

this is not a bug but rather an unimplemented feature.

[alice-i-cecile]

Summarizing some investigation into this: it appears to require fixes upstream in winit.

Bevy needs to receive and handle both the pause and stop event from Android, but winit does not forward this to us.

Related issues: rust-windowing/winit#2736, rust-windowing/winit#2337

[griffi-gh]

Summarizing some investigation into this: it appears to require fixes upstream in winit.

Bevy needs to receive and handle both the pause and stop event from Android, but winit does not forward this to us.

Related issues: rust-windowing/winit#2736, rust-windowing/winit#2337

Why is stop evt required to fix this if surface gets destroyed after pause?

[JMS55]

@mockersf is this issue complete? If not, what's left?

[alice-i-cecile]

I believe this is finished: feel free to open new issues for remaining problems.

[mockersf]

It's not complete at all, we're unable to run in background