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.
The functionality found in egui_winit_platform and egui_wgpu_backend is
now available in the upstream egui-winit and egui-wgpu crates
respectively.
This has simplified the example itself and also removed the dependency
on epi.
The example is now based on egui 0.18 (was previously 0.17)
Since the upstream egui-winit/wgpu crates were generally assuming that
the graphics context and surface can be initialized immediately this
currently builds against a branch that aims to upstream changes that
remove these assumptions:
https://github.com/rib/egui/tree/android-deferred-winit-wgpu
Ref: https://github.com/emilk/egui/pull/1634
Robert Bragg