Pure rust native activity backend #35
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A first step towards replacing the android_native_app_glue code with a pure Rust implementation.
A literal port for now, with the intention of re-working into more idiomatic Rust code once we have a port of all the C code.
At this point the C code has been fully ported to Rust but it's not yet well integrated with the pre-existing Rust code and the port is not yet particularly idiomatic Rust code.
This is a fairly thorough re-working of all the code that was initially naively ported from android_native_app_glue.c to be more idiomatic Rust code (though by it's nature it still involves a lot of unsafe code) Most of the glue code now lives in src/native_activity/glue.rs as part of a NativeActivityGlue API The design as far as the threading model, IPC and synchronization goes is unchanged.
…for callbacks This adds a common `try_with_waitable_activity_ref` utility that handles upgrading the Weak reference associated with `ANativeActivity` whenever we get an activity callback. Previously we weren't converting the Weak reference back to a pointer before returning from the callback which would result in us dropping the Weak reference after the first callback.
This simplifies the tracking of saved state by simply using a Vec and only copying into a `malloc()` allocation when passing the saved state to `ANativeActivity`. This also ensures saved state persists (in Rust) between a `MainEvent::SaveState` event and a `Resume` event - otherwise the saved state would only be restored in the situation where `onCreate` is called again for a new process.
rib
force-pushed
the
pure-rust-native-activity
branch
from
ca78397
to
c3d115f
Compare
5 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This updates the native-activity backed to no longer be based on the
android_native_app_glue.ccode.The original C code provided a useful starting point because the
android_native_app_glueis well tested and its design has been proven but since this glue layer is anyway relatively small/simple it's also possible to support the same general IPC + JVM synchronization design with a glue layer that's written in pure Rust instead.This first ports the code from C to rust quite literally (i.e. non-idiomatic Rust code) followed by a significant re-iteration to make the code into a much more idiomatic Rust implementation.
This can also be considered a stepping stone towards enabling a third
RustActivitybackend (perhaps initially based on a vendored implementation ofANativeActivityorGameActivity) where we'd rather have a pure-Rust glue layer too.Although I've personally never thought it was a concern to initially use the original
android_native_app_glue.ccode directly (considering it has been well tested) others have taken issue with the fact that the backend wasn't pure Rust to the extent that this was distracting discussions. This work effectively follows up on my previous suggestion that we could always re-write the C code in Rust without it affecting the public API.