Consider either re-exporting `ndk` crate or encapsulating the `ndk` crate API
rib opened this issue · 0 comments
Similar to how the Winit crate re-exports the android-activity API it could make sense for this crate to re-export the ndk crate's API so that downstream crates don't need to have an explicit ndk dependency in their Cargo.toml whose version needs to be synchronized with android-activity in case they want to use types (like AssetManager and NativeWindow that are exposed in the public API for android-activity)
(In the case the we re-export the ndk crate that would only really be convenient if the Winit crate were to also do the same, and forward the ndk API from android-activity)
Alternatively the ndk API could be fully encapsulated as an internal implementation detail by defining our own new types for the Asset Manager and Native Window.