Open
Conversation
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 <robert@sixbynine.org>
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
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.
We are going to use a submodule so that it is easier to track and rebase our local changes onto new versions of android-games-sdk Signed-off-by: William Casarin <jb55@jb55.com>
Also includes our patches on top (branch android-activity-2.0.2). This is mainly to test to make sure everything is still working. We will switch to the android-activity-4.0.0 branch when we're done Signed-off-by: William Casarin <jb55@jb55.com>
Signed-off-by: William Casarin <jb55@jb55.com>
This replaces `copy-files` + `file_list.txt` (subjective simplification) This imports the SDK from commit 1b544f896646b29e798c5be0a151a488906797f7, from: https://github.com/rust-mobile/android-games-sdk/commits/android-activity-4.0.0
Signed-off-by: William Casarin <jb55@jb55.com>
For convenience, when updating to new GameActivity versions, this makes
it possible to build against the out-of-tree `android-games-sdk` repo.
This also updates `generate-bindings.sh` to point at $ANDROID_GAMES_SDK
if set.
E.g.
```
git clone git@github.com:rust-mobile/android-games-sdk.git \
--branch android-activity-4.0.0
export ANDROID_GAMES_SDK=$PWD/android-games-sdk
./generate-bindings.sh
cargo build --features=game-activity --target=aarch64-linux-android
```
Update the notes on how to update to new GameActivity releases
Update to GameActivity 4.0.0
Build-test documentation and fix broken doc samples
This reduces package size and notably prevents any bash files from landing on a users device.
…unning We see that some Android callbacks like `onStart()` deadlock, specifically when returning out of the main thread before running any event loop (but likely also whenever terminating the event loop), because they don't check if the thread is still even running and are otherwise guaranteed receive an `activity_state` update or other state change to unblock themselves. This is a followup to [#94] which only concerned itself with a deadlock caused by a destructor not running because that very object was kept alive to poll on the `destroyed` field that destructor was supposed to set, but its new `thread_state` can be reused to disable these condvar waits when the "sending" thread has disappeared. Separately, that PR mentions `Activity` recreates because of configuration changes which isn't supported anyway because `Activity` is still wrongly assumed to be a global singleton. [#94]: https://togithub.com/rust-mobile/android-activity/pull/94
…#163)" This reverts commit 51d05d4 for backwards compatibility with the existing `0.6` releases. For now, it's creating a lot of busy work having to always make this revert in order to test various topic branch changes with winit 0.30. Lets save this breaking change until we have more reasons to break semver compatibility (in itself this doesn't fix or enable any features, so we can live without it for now).
This imports the SDK from commit 8fa58b0e145ec28e726fa2b1c7e7a52af925ca35, from: https://github.com/rust-mobile/android-games-sdk/commits/android-activity-4.0.0 This includes one "notify android_main of editor actions" patch which will make it possible to forward editor actions and support IME Commit events in Winit) # notify android_main of editor actions This adds a pendingEditorActions member to android_app that is set via onEditorAction and the android_main thread is notified via notifyInput instead of re-instating APP_CMD_EDITOR_ACTION. The idea is that the android_main thread should check for android_app->pendingEditorActions whenever input events are polled/iterated. # FFI bindings update Also updates the FFI bindings via generate-bindings.sh
APP_CMD_SOFTWARE_KB_VIS_CHANGED in the GameActivity backend is intended for notifying the android_main thread that the soft keyboard visibility has changed. There's currently no Rust event / API for this, and so it wasn't being handled in poll_events but that was leading to a unreachable panic when GameActivity would send this APP_CMD when showing soft keyboards. We don't currently plan to expose any public API / event for this since it's based on monitoring IME insets and applications should instead be able to check insets after getting InsetsChanged events. For the sake of minimizing patches to the upstream GameActivity code this makes it so poll_events can ignore this APP_CMD as a NOOP.
This exposes IME actions via an InputEvent::TextAction event so that it's possible to recognise when text entry via an input method is finished. This adds a `TextInputAction` enum to represent the action key on a soft keyboard, such as "Done". For example, this makes it possible to emit Ime::Commit events in Winit.
This re-generates the FFI bindings with `--rust-target '1.85.0'`
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
14 participants
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.