Android: `request_redraw()` blocks `send_event()`

[Rodrigodd]

In android, Window::request_redraw() can block UserEvents send by EvenLoopProxy::send_event to reach the event loop callback.

I think this happens because of the way that request_redraw is injected in the Looper. In request_redraw the request is store in the static INTERNAL_EVENT, and the Looper is wakened:

winit/src/platform_impl/android/mod.rs

Lines 676 to 679 in 4dd2b66

	pub fn request_redraw(&self) {
	*INTERNAL_EVENT.write().unwrap() = Some(InternalEvent::RedrawRequested);
	ForeignLooper::for_thread().unwrap().wake();
	}

And in Poll::Wake, the request is injected in the Looper, taking priority over EventSource::User:

winit/src/platform_impl/android/mod.rs

Lines 220 to 226 in 4dd2b66

	Poll::Wake => Some(
	INTERNAL_EVENT
	.write()
	.unwrap()
	.take()
	.map_or(EventSource::User, EventSource::Internal),
	),

And send_event also wakes up the Looper:

winit/src/platform_impl/android/mod.rs

Lines 583 to 587 in 4dd2b66

	pub fn send_event(&self, event: T) -> Result<(), event_loop::EventLoopClosed<T>> {
	self.queue.lock().unwrap().push_back(event);
	self.looper.wake();
	Ok(())
	}

This means that if both calls to loop.wake() creates a single Poll::Wake, request_event will always be blocking send_event (as happens in my device).

Reproducing the issue

I can reproduce this bug by adding the following example to the examples folder: https://gist.github.com/Rodrigodd/379a24ea39c6bead98a8b5dad5e0753e

And running in android, as instructed in the README.md.

// add this to Cargo.toml
[[example]]
name = "android_send_event_block"
crate-type = ["cdylib"]

cargo apk run --example android_send_event_block
adb logcat RustStdoutStderr:D *:S

Reproducible on Android 11.

[rib]

For reference, I recently updated the winit Android backend to support a different glue layer that I've been working on and as part of that I re-worked how redraws were queued since I was also concerned with the current approach.

Here's a link to what I did there: https://github.com/rib/winit/blob/8adc3fe461ce78202b4464bfb9bddebd505721c4/src/platform_impl/android/mod.rs#L255

Actually I wonder if a similar pattern could also be adopted in other backends, since I e.g. saw that the X backend uses and mpsc queue for redraw requests which doesn't really seem appropriate for something that needs to act more like a flag.

I think that solution could potentially be ported across to the current backend and might fix this issue.