Re-export Axis from the ndk for native-activity

[fornwall]

Currently android_activity::input::Axis is always the enum defined by the android-activity crate.

This means that when native-activity is used, the below code does not currently compile, since the Pointer re-exported from the ndk expects an Axis also re-exported from the ndk:

let e: android_activity::input::MotionEvent = ...;
let pointer = motion_event.pointer_at_index(0);
let value = pointer.axis_value(android_activity::input::Axis::X);

[rib]

Ah, yep, awkward.

This is a bit fiddly because the input API specifically differs quite significantly between the game-activity and native-activity backends and we have repeatedly hit issues from trying to expose compatible APIs using different types.

For implementation convenience the native-activity backend used to more-directly expose all the ndk input types but this has repeatedly led to compatibility issues between the native-activity and game-activity backends where the game-activity types haven't matched the ndk API exactly or where downstream crates have just assumed they can use the ndk types and then not been compatible with the game-activity backend at all.

Ref: #107 and #92

Because of this I've generally tried to switch away from using any of the ndk crate types here unless they can also be used with the game-activity backend too and so I'm thinking we should probably instead double-down with consolidating input types and look at wrapping the Pointer type so we can hide the ndk Pointer as an implementation detail for the native-activity backend.

Pointer and PointersIter are essentially the last two ndk input types that are still exposed publicly.

In a similar way, Pointer::tool_type() still poses a portability hazard between the native-activity and game-activity backends.

[fornwall]

Thanks for sharing the info!

we should probably instead double-down with consolidating input types and look at wrapping the Pointer type so we can hide the ndk Pointer as an implementation detail for the native-activity backend.

Makes sense! Created #122 as an initial iteration on that, so closing this PR in favour of that one!