This makes sure that the `AssetManager` we return from
`AndroidApp::asset_manager` can be retained with a static lifetime and
never become a wrapper for an invalid pointer.
The key change here is that we now return the Application AssetManager
(i.e. from Application.getAssets()) instead of the Activity
AssetManager.
Theoretically there could be some applications that could associate an
Activity AssetManager with unique resources but that's not expected to
be common (and at least no expected to affect anyone currently using
`AndroidApp::asset_manager`).
As part of the `APP_ONCE` initialization in `init_android_main_thread`
we now get a global reference to the Application AssetManager and get
the corresponding AAssetManager that we can trust will be valid for the
lifetime of the process since we leak the global reference.
Note: The Application `AssetManager` is logically a process-wide
resource and so the leaked global is just a technical formality to
ensure it can't be garbage collected, but that's assumed to be
redundant.
Note: If anyone _strictly_ needs the `Activity` `AssetManager` then they
could at least resort to calling `Activity.getAssets()` via JNI
manually, but perhaps we can later consider adding a separate
`AndroidApp::activity_asset_manager()` that will pair an `AAssetManager`
pointer with a JNI global reference to ensure the pointer remains valid.
Fixes#161
This makes it easy to schedule boxed closures to be run on the Java main
/ ui thread.
When the closure is run then:
- Any panic will be caught, so we don't unwind into the Looper and abort
the process
- The JVM will be attached (for JNI) and any exceptions that are thrown
will be caught and logged as errors.
- A JNI stack frame will be pushed and popped before running your closure
(so you don't have to worry about leaking local JNI references)
This bumps the jni dependency to 0.22.4 because that version adds a
`JCharSequence` binding that we use in the `Toast` example in the
documentation.
This makes it possible to register file descriptors that can wake up the
Java main / UI thread as well as callbacks that will run on the Java
main / UI thread.
Although it can be common to refer to this thread as the "main" thread,
we choose to explicitly refer to it as the "java main" thread thread in
the API to avoid confusion with the Rust thread that runs
"android_main".
Co-authored-by: Robert Bragg <robert@sixbynine.org>
This imports the SDK from commit
30b8bfcc9a12942d1268820e8a83d7643e99ee92, from:
https://github.com/rust-mobile/android-games-sdk/commits/android-activity-4.0.0
this includes these patches:
# PATCH: Add mainLooper to android_app
Track the Looper for the Java main/UI thread in the android_app.
This makes it possible to add file descriptors and callbacks to the Java
UI Looper from the android_main thread.
This needs to be initialized by the android_native_app_glue before
spawning the android_main thread because the looper needs to be
discovered via `ALooper_forThread` while still running on the Java main
thread (in the onCreate callback).
# PATCH: Enable Rust glue to hook into onCreate
This declares an extern `_rust_glue_on_create_hook` that is called from
`GameActivity` `onCreate` native method callback, before the
`android_main` thread is spawned.
This gives Rust code an opportunity to run code and initialize state
while still running on the Java main/UI thread.
For example, this could be used to initialize JNI bindings while we can
assume that the current thread has an associated ClassLoader that will
be able to find application classes.
It may also be a convenient place to make some initial JNI calls into
Android SDK APIs that can only be used from the Java main thread.
# Updated import-games-sdk.sh to remove symlinks
While updating the SDK the import script has been updated to remove any
symlinks which make it difficult to build android-activity from Git on
Windows.
Note: the symlinks were redundant based on how the include paths were
already configured in `build.rs`
Instead of initializing `ndk-context` with an `Activity` reference (for
the `android.context.Context` subclass) we now initialize with
an `android.app.Application` reference (also an
`android.context.Context` subclass).
The benefit of this is that we can strictly initialize `ndk-context`
once (via a `OnceLock`) so there's no risk of a panic in case an
application starts more than one Activity within the same process.
Fixes: #58Fixes: #228
This ensures we call `ALooper_acquire` before `create_waker()` wraps the
Looper pointer with `AndroidAppWaker` and it also ensures that
`::clone()` and `::drop()` call `ALooper_acquire()` and
`ALooper_release()` respectively.
Contrary to what the comment for the `looper` member said previously, it
was not safe to assume that the application's looper pointer had a
`'static` lifetime.
The looper pointer would only be valid up until `android_main` returns,
but unlike a traditional `main()` function an `android_main()` runs
with respect to an `Activity` lifecycle and not a process lifecycle.
It's technically possible for `android_main()` to return (at which point
any looper stored in `'static` storage would have previously become an
invalid pointer) and then JNI could be used to re-enter Rust and
potentially try and dereference that invalid pointer.
This adds a shared implementation of `AndroidAppWaker` to `src/waker.rs`
instead of having each backend implement `AndroidAppWaker`.
Fixes: #226
The `ALooper_pollAll` API is deprecated and considering that `poll_events`
never promised the behaviour of `pollAll` we simply change the
implementation to use `ALoooper_pollOnce` and assume the caller is going
to anyway be calling `poll_events` within its own loop.
Note: `pollOnce` can still deliver multiple callback events, and the
"once" effectively just refers to only calling `epoll_wait` at most
once.
Considering winit for example, this should have no effect since winit
will be calling `poll_events` in a loop with no assumption about how
concurrent events could potentially be batched.
Fixes: #170
This adds and documents the remaining `ImeOptions` (addressing TODO comment)
`ImeOptions` now has a getter/setter for the action, based on the
`TextInputAction` enum added in #216
There is also a separate `InputTypeClass` that lets you query the
mutually-exclusive type class bits from an `InputType`
This corresponds to the GameActivity_setImeEditorInfo function on
GameActivity. This is not supported on NativeActivity.
Signed-off-by: William Casarin <jb55@jb55.com>
The `cesu8` crate hasn't been updated for 10 years where as the
`simd_cesu8` crate is more actively maintained and is expected to have
better performance in all conditions:
<https://docs.rs/simd_cesu8/latest/simd_cesu8/#benchmarks>
This change is consistent with the `jni` crate which switched to using
`simd_cesu8` in the 0.22.2 release - so this avoids needing to build
two separate crates for mutf8 encoding.
This also addresses the current CI issue that comes from incorrectly
depending on `cesu8 = "1"` instead of `"1.1.0"` (which adds the
java/mutf8 APIs that we used). Previously this went unnoticed because
of the `jni` crate pulling in the correct minimum version.
This was replaced by `AttachConfig::thread_name` in jni 0.22.2, which
takes a `&JNIStr` and doesn't require an extra allocation for the name
to be mutf8 encoded.
This adds a common init_android_main_thread() utility that's called by
both backends in order to get the ClassLoader from the Activity and
associate that with the thread via `JThreadthread::set_context_class_loader`
(which jni 0.22 can use automatically when loading classes).
This change notably starts to use the `jni::bind_java_type!` macro for the
`KeyCharacterMap` and `InputDevice` Java SDK API bindings in
`src/input/sdk.rs` which is a nice simplification.
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.
Robert Bragg