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.
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 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
This reverts commit 51d05d48c8 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).
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
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
```
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>
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>
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.
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.)
* 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.
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.
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)
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.
Alex Touchet