Robert Bragg

Yeah, personally here I feel like it's reasonable to document how the IDs remain valid so long as the class isn't unloaded which I think is too high level of...

> PS: I do appreciate the long issue text, as a fellow poster of such issues/comments :D hehe, thanks 👍 > I very much agree that Android is a bit...

> That won't work with applications requiring RawWindowHandle. Since it would mean that it could invalidate and everything should be recreated. Not sure something like that makes sense for other...

Cool, thanks, yeah I'm not exactly sure what the ideal next steps here should be atm. Since I was thinking there might still be an interest in maintaining support for...

> I'd like to not require additional Java code for pure native applications, or at the very least have that option available with `winit`. When the user requires Java interop...

I think when it comes to using the C/C++ glue code from Google I tend to see that as an implementation detail. With the initial game-activity/native-activity crates I wrote then...

> I think we can address both issues by inventing a common API between the four implementations (Rusty glue, and C/C++ layer, for both `NativeActivity` and `GameActivity`), as you proposed....

For reference I've just rebased the `android-activity` branch on winit master

For reference I opened an [issue](https://github.com/rib/android-activity/issues/4) to track the need to support input event notifications in `android-activity` and have [made a first pass](https://github.com/rib/android-activity/tree/input-available-events) at adding the support for `InputAvailable` events...

> Looks like we may be missing `screenLayout`: > > https://github.com/rust-windowing/android-ndk-rs/blob/dc38fcbf688a0a0e7a378a18f7b2cf4c095ccf92/ndk-build/src/manifest.rs#L324-L326 > > (At least on my phone setting the app to be a freefloating window recreates a new `Activity`...