merge upstream #1
Open
Conversation
This file contains hidden or 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
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
…ks by transitive dependency upgrades) (#164) * game_activity/ffi: Drop cfg for inexistant `target_arch = "armv7"` [Rust 1.80 from July 25th 2024] points out that `armv7` is not a known, valid value for the `target_arch` cfg variable. This is confirmed by the docs not listing it either: https://doc.rust-lang.org/reference/conditional-compilation.html#target_arch Hence drop this entirely, and rely purely on `target_arch = "arm"`. [Rust 1.80 from July 25th 2024]: https://blog.rust-lang.org/2024/07/25/Rust-1.80.0.html * Fix `unexpected-cfgs` by adding `api-level-30` feature and removing `test` Some code copied from the NDK carried over the respective `feature` `cfg` guards, without ever adding the feature to the `[features]` list in `Cargo.toml`. Now that Rust detects these mishaps, we can fix it by removing `test` (bindings don't seem to be run-tested) and reexpose `ConfigurationRef::screen_round()` which was behind a previously unsettable `feature = "api-level-30"`. Also remove `unsafe impl Send/Sync for ConfigurationRef` since the upstream `ndk` already declares `Configuration` to be `Send` and `Sync`, and `RwLock` and `Arc` carry that through. * native_activity: Fix clippy lints around `NativeActivityGlue` not `SendSync` and unwritten `redraw_needed` field * CI: Remove deprecated/unmaintained `actions-rs` toolchain setup The `actions-rs` containers haven't been maintained and updated for years and don't need to: GitHub's actions environment already comes fully loaded with a complete `stable` Rust installation with the standard tools (in this case `rustfmt`). Remove the remaining toolchain setup (which was already replaced with `hecrj/setup-rust-action` elsewhere) to get rid of ancient Node 12 deprecation warnings. * Bump dependency patch-versions to fix `-Zminimal-versions` and MSRV check Use `-Zminimal-versions` in our MSRV check. This not only ensures our minimum version bounds are actually solid and tested (even if they may be a bit conservative at times, i.e. we could allow older versions except for the crates that are bumped in this patch which were explicitly build-tested), it also allows us to use this as a base for the MSRV test, and preempt us from failing it whenever a (transitive!) dependency bumps its MSRV beyond ours in a *semver-compatible* release. * Elide redundant `impl` block lifetimes following stricter Rust 1.83 lint Rust now points out that `impl<'a> (Trait for) Struct<'a>` is superfluous whenever `'a` is not used anywhere else in the `impl` block.
There was a fix for the definition of the `stat` struct on Android in 1.73, and even though it's unlikely to affect many applications it still seems worthwhile to draw a line under this and ensure that all android-activity based applications will have that fix. Rust 1.73 was released October 2023, which is still well over a year old and very conservative. This updates `generate-bindings.sh` to pass `--rust-target 1.73.0` so we avoid generating bindings that require a more recent compiler. (This doesn't actually regenerate the bindings but does ensure that future updates will be constrained to generate code that is backwards compatible with 1.73.)
Since we expose `ndk` types in the public API it makes sense to re-export these APIs so users of android-activity can defer to these without needing to manually sync the versions for explicit dependencies.
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.