Most of the examples weren't strictly just demonstrating how to use the
android-activity API - rather they demonstrated using other libraries
in conjunction with android-activity.
Most of the examples have now been split into a standalone repository
under: https://github.com/rust-mobile/rust-android-examples
The na-mainloop and agdk-mainloop examples have been kept here since
they can be built against the local/in-tree version of android-activity
and are useful to keep for CI purposes.
This also runs `cargo update` for the na-mainloop and agdk-mainloop.
This updates the *-winit-wgpu examples to use `log::info!` instead of `trace!`
and sets the log level to `Info`
The examples now also print info about and Winit Window events.
This makes them more practical to use to see how Winit events
are delivered without lots of tracing spam from dependency crates.
- Updates deps
- Some README updates considering the Winit backend based on
android-activity has been merged upstream
- runs cargo fmt over examples
- Top-level Cargo.toml simply excludes "examples" instead of
listing each sub-directory separately
This example shows how to draw a triangle with GL[ES via the Glutin
crate (the app works on desktop and Android) and on Android it
demonstrates how to re-create the applications surface state when
it is paused and resumed.
The Renderer code and some utilities are from the upstream Glutin example.
The winit based examples no longer have an explicit dependency on
android-activity and they instead consume the `android-activity` API via
the Winit crate so there's no need to keep the versions synchronized.
The callback given to `AndroidApp::input_events()` is now expected to return
`InputStatus::Handled` or `InputStatus::Unhandled`.
When running with NativeActivity then if we know an input event hasn't been
handled we can notify the InputQueue which may result in fallback
handling.
Although the status is currently ignored with the GameActivity backend.
Since this is a breaking change that also affects the current Winit
backend this updates the winit based examples to stick with the 0.3
release of android-activity for now.
Fixes: #31
The latest branches for Winit (which update the Android backend to
use android-activity) now depend on the android-activity 0.2
release which broke the patching assumption for the Winit examples.
(they were patching based on the git url not crates.io)
It was also noticed that the latest android-activity-0.27 branch
isn't compatible with Egui currently because the (badly named) branch
is based on Winit master and there was recently a breaking API change
adding new window events which breaks Egui.
A note about the badly name branches has been added to the Cargo.toml
files for the Winit examples (they can't currently be fixes since
the -0.27 branch is part of a pull request).
For reference here:
- "android-activity" is based on Winit 0.27 (required for Egui compatibility)
- "android-activity-0.27" is based on Winit master
This patch adds Cargo.lock files for the Winit examples.
Fixes: #22
* Since we can rely on `Resumed` events for all platforms with Winit 0.27
we can remove the alternative `NewEvents` path for initializing state.
* Removes some unnecessary abstraction for the app state.
* Bumps agdk-egui to egui 0.19 (Winit 0.27)
This provides an API to access `Configuration` state for the application
without having to make deep copies of the large `Configuration` struct.
This should avoid the need for Winit to create a global static copy of
the Configuration whenever it changes - and instead it can just get
a `ConfigurationRef` which will always reflect the latest config for
the application.
Fixes: #5
In Winit then we ideally want to be able to associate a cloned reference to
the AndroidApp with the `Window` and `MonitorHandle` types (since that's the
most practical way to access the native_window and config state for the
application) but for that `AndroidApp` needs to be Send + Sync
I was mistaken recently, thinking that cpal's dev-dependency on ndk-glue
was somehow being inherited by the example. Actually the real issue was
that cpal 0.13.5 has a regular _dependency_ on ndk-glue, which is a much
simpler explanation for why we were seeing a crash.
This updates the example to just use the master branch of cpal, which we'll
need until there is a new release of cpal.
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).
When a wake up is received and we recognise that new input is available
then an `InputAvailable` event is sent 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.
Addresses #4
Based on the android example that's in the cpal repo, this test plays
a 440hz sine wave and is based on GameActivity
Note: this requires a workaround branch for cpal that comments out
a dev-dependency on ndk-glue that cpal has for its android example.
This is needed because Cargo is spuriously propagating this dev
dependency outside of the cpal package (which leads to a crash)
This fixes build errors about not specifying either of the
"native-activity" or "game-activity" features.
The issue came about because the in-tree examples want to
build against the in-tree version of android-activity located
with a relative `path = ` but these particular examples
depend on Winit which would resolve a second implementation
of android-activity, via a github url - where Cargo will treat
them as completely different crates.
"native-activity" builds were recently broken by bb8eeb705c which
this patch fixes.
The na-mainloop example has also been updated to verify this by
reducing the fake "render" timeout and also triggering a fake
render when an InputAvailable event is received.
Fixes: #12
android_main() now takes an `app: AndroidApp` argument and has an
extern "Rust" ABI instead of "C" ABI.
This should help make it possible to run multiple native Activities in a
single process.
This leaves the InputBuffer abstraction as an implementation detail
and just exposes an API like this for processing input:
app.input_events(|event| {
// handle event
});
The main consideration here was to have an API that could also be
supported via NativeActivity to keep open the possibility of a standard
Android 'glue' API.
Robert Bragg