input: Replace open-coded types with ndk::event definitions

[MarijnS95]

As documented in // XXX comments, and discussed before, the copy-pasted input types exist because the ndk crate "wasn't set up" to allow changes to enums in a non-semver-breaking way (in particular, they were not marked #[non_exhaustive]). This issue was not reported upstream, and it took me to use android-activity before realizing so and fixing it in rust-mobile/ndk#459. Also, after comparing the copy-paste here against the ndk types, no new variants were ever added, completely defeating the purpose (even though new types were added to the ustream headers and will be added to te ndk crate).

Hence, remove all the open-coded types again and reexport them from the ndk crate. Upstream not only made all enums #[non_exhaustive], but also fixes the repr types to not use the u32 default for untyped enum constants, but in most cases i32 when all function signatures take a signed argument.

[MarijnS95]

Will rebase this as soon as #164 is in!

[rib]

Thanks for looking at this, I think in general this seems reasonable to do at this point.

Originally, a notable part of the purpose for these types was just to provide types that could be shared between the GameActivity and NativeActivity backend.

There have repeatedly been issues with directly exposing ndk input types in the android-activity API due to differences between GameActivity and NativeActivity and so I've generally been cautious about going back to exposing them. E.g. for a while the Winit Android backend wouldn't work with the game-activity backend because of stuff like this: https://github.com/rust-windowing/winit/blob/918430979f8219648daade44796c00893e42fdd8/src/platform_impl/android/mod.rs#L404

Since the input API is so central to the android-activity crate then in the past it's also been convenient to not be too tightly coupled to the ndk crate here, so I could make input API changes without being blocked on there being a new ndk release.

Maybe if there are some missing variants it's a good time to look at using shared types from the ndk crate if they can now be shared across both backends.

I think the main thing that seems to be missing atm are some CHANGELOG notes about the breaking changes. For completeness that should probably include a note about the repr changes

[MarijnS95]

There have repeatedly been issues with directly exposing ndk input types in the android-activity API due to differences between GameActivity and NativeActivity

We discussed this before, and as highlighted in this PR that those compatibility issues weren't brought up "upstream" at the ndk crate before, nor really seem to exist when I put the effort in comparing these enums to replace them. If anything the ndk already has more variants for some enums, and has a change scheduled to add anything that's still missing.

E.g. for a while the Winit Android backend wouldn't work with the game-activity backend because of stuff like this: https://github.com/rust-windowing/winit/blob/918430979f8219648daade44796c00893e42fdd8/src/platform_impl/android/mod.rs#L404

We've since fixed that, which is specifically why this PR is open now so I don't think it's fair to dredge that back up.

Since the input API is so central to the android-activity crate then in the past it's also been convenient to not be too tightly coupled to the ndk crate here, so I could make input API changes without being blocked on there being a new ndk release.

Again, there are little to no differences at this time. I'm keeping the structs on your side and only replacing the enums and bitflags anyway.

Maybe if there are some missing variants it's a good time to look at using shared types from the ndk crate if they can now be shared across both backends.

That's exactly what this PR did :)

I think the main thing that seems to be missing atm are some CHANGELOG notes about the breaking changes. For completeness that should probably include a note about the repr changes

Fixed.

[rib]

Thanks for looking at all of this - it looks good to me!

[rib]

I'm having nagging second thoughts that we shouldn't have merged this as a breaking change :/

This change means we can't make a release of android-activity that will be compatible with winit 0.30.x

Knowing how long Winit's major release cycles can be that doesn't seem ideal

[MarijnS95]

@rib sure that makes sense, at first it seemed we wouldn't really make that many changes before a breaking winit major release would be cut.

This however means PRs like #193 need to be excluded as well since winit is still on MSRV 1.70. How about we instead create a release-0.6 branch that tracks the nonbreaking changes we could put into a patch release? We can easily backport just the necessary features there, without stalling breaking improvements.