Weird/UB ndk APIs found by removing NIHisms in android-activity
#478
Milestone
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
android-activityopen-codes a lot ofndk-provided API, directly on top of native functions and symbols fromndk-sys. While attempting to remove most of it to simplify and clear up the implementation with safer Rust, I found that thendkcould do some things quite a bit better, even if only by documenting expectations. Perhaps this is why certain things were open-coded in the first place, besides being ported from raw C code.Since the
ndkcrate is quite old by now, and has seen a lot of "Just Make it Work™", things like lifetime management and correctness when it comes to safety/UB have not always been kept in mind while writing bindings. Instead of creating a lot of separate issues (or PRs) right now, I am using this issue as a public scratch-pad to keep track of questions and ideas that need to tracked and looked into later.NativeActivityreturns&Paths from raw pointers: could these ever benull()/None?NativeActivity::asset_manager()has no lifetime: this should be bound to&selfor is it "Application-global"?InputQueuehas no lifetime and noDrop/Clone: document its lifetime guarantees and return borrows where necessary?Its lifetime is tied to the
onInputQueueDestroyedcallback whose docs describe that:ForeignLooper(and various other structures, see Unify lifetime handling forNativeWindowandHardwareBuffer#309) cannot be created without lifetime management, i.e. to temporarily borrow/handle the pointer safely while it is valid inside a callback.For lack of
unsafe fn borrow_from_ptr(NonNull...) -> &'unknown Self(impossible to write in Rust anyway), it seems most convenient to calllet looper = ManuallyDrop::new(ForeignLooper::from_ptr(looper));now.The text was updated successfully, but these errors were encountered: