merge upstream #1
Open
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
game_activity: Fix `pointer_index()` always returning `0`
Calling Activity.finish() is what ensures the Activity will get gracefully destroyed, including calling the Activity's onDestroy method. Fixes: #67
I was trying to quickly get to the documentation of this crate and had the GitHub page open... but there was no link on the front-page: let's fix that.
README: Add badges to CI, crates.io, docs.rs and show the MSRV
Call Activity.finish() when android_main returns
Cargo complains:
warning: android-activity/Cargo.toml: unused manifest key: package.rust_version
Solve this by replacing the underscore with a hyphen.
cargo: Fix `rust_version` -> `rust-version` property typo
Release 0.4.2
Fix a deadlock that occurs when an activity is destroyed without process termination, such as when an activity is destroyed and recreated due to a configuration change. The deadlock occurs because `notify_destroyed` blocks until `destroyed` is set to `true`. This only occurs when `WaitableNativeActivityState` is dropped, but the `WaitableNativeActivityState` instance is the very thing being used to await for destruction, resulting in a deadlock. Instead of waiting for the `WaitableNativeActivityState` to be dropped we now wait until the native `android_main` thread has stopped. So we can tell the difference between the thread not running because it hasn't started or because it has finished (in case `android_main` returns immediately) this replaces the `running` boolean with a tri-state enum. Co-authored-by: Robert Bragg <[email protected]>
Fix deadlock on activity onDestroy
This ensures that any java Activity callbacks take into account the possibility that the `android_app` may have already been marked destroyed if `android_main` has returned - and so they mustn't block and wait for a thread that is no longer running.
…lock GameActivity PATH: fix deadlocks in java callbacks after app destroyed
Release 0.4.3
Give C symbols that need to be exported a `_C` suffix so that they can be linked into a Rust symbol with the correct name (Since we can't directly export from C/C++ with Rust+Cargo) See: rust-lang/rfcs#2771
The real `android_main` is going to be written in Rust and android-activity needs to handle its own initialization before calling the application's `android_main` and so the C/C++ code calls an intermediate `_rust_glue_entry` function.
This makes a small change to the C glue code for GameActivity to send looper wake ups when new input is received (only sending a single wake up, until the application next handles input). This makes it possible to recognise that new input is available and send an `InputAvailable` event to the application - consistent with how NativeActivity can deliver `InputAvailable` events. This addresses a significant feature disparity between GameActivity and NativeActivity that meant GameActivity was not practically usable for GUI applications that wouldn't want to render continuously like a game.
This ensures that any java Activity callbacks take into account the possibility that the `android_app` may have already been marked destroyed if `android_main` has returned - and so they mustn't block and wait for a thread that is no longer running.
Updated To Games-Activity 2.0.2
This exposes the button associated with a button press or release action.
Release 0.5.0
The `ndk` crate enables `raw-window-handle 0.6` by default (because of rust-mobile/ndk#434 (comment)) which might not be used by consumers of the `android-activity` crate at all, or might (still) be a mismatching version. Even if the `rwh_0x` features are additive, figuring that out leads to cryptic errors and it is best to turn off these defaults completely and leave it to the user to turn it back on in their own `[dependencies]` section if desired.
Name spawned threads to make things more clear during debugging and profiling.
When `read_line()` starts returning `Err` the current `if let Ok` condition ignores those, likely causing the `loop` to spin indefinitely while this function keeps returning errors. Note that we don't currently store the join handle for this thread anywhere, so won't see the error surface either (just like how the join handle for the main thread is never checked). Perhaps we should call `log::error!()` to make the user aware that their IO logging has mysteriously terminated.
…ad_line-error Stop log-forwarding thread on IO errors
Name spawned threads
README: Update crate version in `Cargo.toml` example
Although this crate has some examples that depend on the ndk, they aren't regular Cargo examples, they are completely standalone apps that depend on dev-dependencies.
Release 0.5.1
native-activity/input: OR with `EVENT_ACTION_MASK` when extracting action
This fixes CI builds with rust 0.68 because cargo ndk depends on cargo platform which depends on 0.70.
Release 0.5.2
cargo ndk will fail to build with 1.68 due to a toml_edit dep. Technically android-activity itself should still build with 1.68 but it's simpler to synchronize the `rust-version` with the minimum version that we actually test in CI (where we need to build cargo ndk)
The next breaking `ndk` release puts a lot of emphasis in improving `enum`s to finally be marked `non_exhaustive`, and carry possible future values in `__Unknown(i32)` variants. This removes the lossy conversions that previously required `android-activity` to redefine its types, which could all be removed again. The `repr()` types have also been updated, as `enum` constants in C are translated to `u32` by default in `bindgen` even though they're commonly passed as `int` to every API function that consumes them.
Avoids calling `std::slice::from_raw_parts` with a null `saved_state_in` pointer. Fixes: #153
Release 0.6.0
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.
No description provided.