* 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)
Considering the possibility of using epoll directly or perhaps mio in
the future instead of the ALooper wrapper API then this just removes
the FdEvent and Error enum values from PollEvent as a simplification
in case they could make it harder to keep compatibility in the future.
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)
Since f24606cc84 in android-ndk-rs then NativeWindow now implements
Clone and Drop which was technically a breaking change since it
changed the ownership contract for existing users of
NativeWindow::from_ptr().
We now use NativeWindow::clone_from_ptr() to account for the fact that
the window will be unconditionally _released() when NativeWindow gets
dropped.
This addresses a crash I was debugging with the Cpal and Oboe
examples which turned out to be nothing to do with the examples
themselves.
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
This reinstates support for notifying applications of new input events
without requiring them to always check for input as part of their
rendering updates. This makes it possible to build UI applications that
might only need to redraw in response to new input.
For now GameActivity doesn't emit this event but the plan is to also
add support for this in GameActivity.
Addresses: #4