According to current winit's event handling implementation details there is no way directly hook Android's pause/resume events which can be used to create/destroy surface.

To get it work we need solve at least two issues.

1. Create context after window actually created.
   This happens when we get WindowCreated event from ndk-glue.
   In winit this event corresponds to Resumed event.
2. Manage creating and destroying rendering surface.
   This should be done when we get Resume/Suspend events from ndk-glue.
   Winit currently missing corresponding events.

For now I see the next possible solutions:

1. Change winit API by introducing additional event: WindowEvent::Created related to corresponding event from ndk-glue.
   This event should be place for actual context initialization. On other platforms this event can be triggered synchronous when window created. In this case Resume/Suspend events may corresponds to Android`s one and can be used to manage rendering surface.
2. Override needed (low-level) callbacks directly in NativeActivity at runtime.
   In that case the main function should be called after WindowCreated event actually received (which requires ndk-glue changes or additional wrapper for it). This solution does not require winit API changes but looks too dirty for me and possibly may have less obvious flaws.

cc @dvc94ch, @goddessfreya, @VZout, @francesca64

Here we go, some running example based on your changes:

https://github.com/Kaiser1989/rust-android-example

Change winit API by introducing additional event: WindowEvent::Created related to corresponding event from ndk-glue.
This event should be place for actual context initialization. On other platforms this event can be triggered synchronous when window created. In this case Resume/Suspend events may corresponds to Android`s one and can be used to manage rendering surface.

Those were removed because @goddessfreya and me came to the conclusion that glutin didn't need to know about those after the improvements to glutin 0.23. I'd still like to see those happen as it makes integrating with for example libflutter_engine.so in flutter-rs much more natural and less error prone. But it looks like no one is willing to update the macos/windows backends :/

Also I don't have the time to work on this stuff at the moment, as due to instability of flutter-rs/winit on desktop platforms and lack of support for mobile platforms we decided to go with "regular" flutter and are using ffi to integrate our rust code into the ui.