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.
When `read_line()` starts returning `Err` the current `if let Ok`
condition ignores those, likely causing the `loop` to spin indefinitely
while this function keeps returning errors.
Note that we don't currently store the join handle for this thread
anywhere, so won't see the error surface either (just like how the join
handle for the main thread is never checked). Perhaps we should call
`log::error!()` to make the user aware that their IO logging has
mysteriously terminated.
The `ndk` crate enables `raw-window-handle 0.6` by default (because of
https://github.com/rust-mobile/ndk/pull/434#issuecomment-1752089087)
which might not be used by consumers of the `android-activity` crate
at all, or might (still) be a mismatching version. Even if the `rwh_0x`
features are additive, figuring that out leads to cryptic errors and it
is best to turn off these defaults completely and leave it to the user
to turn it back on in their own `[dependencies]` section if desired.
This adds a `#[doc(hidden)]` `__Unknown(u32)` variant to the various
enums to keep them extensible without requiring API breaks.
We need to consider that most enums that are based on Android SDK enums
may be extended across different versions of Android (i.e. effectively
at runtime) or extended in new versions of `android-activity` when we
pull in the latest NDK/SDK constants.
In particular in the case that there is some unknown variant we at least
want to be able to preserve the integer value to allow the values to be
either passed back into the SDK (it doesn't always matter whether we
know the semantics of a variant at compile time) or passed on to
something downstream that could be independently updated to know the
semantics.
We don't want it to be an API break to extend these enums in future
releases of `android-activity`.
It's not enough to rely on `#[non-exhaustive]` because that only really
helps when adding new variants in sync with android-activity releases.
On the other hand we also can't rely on a catch-all `Unknown(u32)` that
only really helps with unknown variants seen at runtime. (If code were
to have an exhaustive match that would include matching on `Unknown(_)`
values then they wouldn't be compatible with new versions of
android-activity that would promote unknown values to known ones).
What we aim for instead is to have a hidden catch-all variant that is
considered (practically) unmatchable so code is forced to have a
`unknown => {}` catch-all pattern match that will cover unknown variants
either in the form of Rust variants added in future versions or in the
form of an `__Unknown(u32)` integer that represents an unknown variant
seen at runtime.
Any `unknown => {}` pattern match can rely on `IntoPrimitive` to convert
the `unknown` variant to the integer that comes from the Android SDK in
case that values needs to be passed on, even without knowing it's
semantic meaning at compile time.
Instead of adding an `__Unknown(u32)` variant to the `Class` enum though
this enum has been removed in favour of adding methods like
`is_button_class()` and `is_pointer_class()` to the `Source` type, since
the class flags aren't guaranteed to be mutually exclusive and since
they are an attribute of the `Source`.
This removes some reliance `try_into().unwrap()` that was put in place
anticipating that we would support `into()` via `num_enum`, once we
could update our rust-version.
When the input file descriptor of the `pipe()` is `dup2()`'d into
`stdin` and `stdout` it is effectively copied, leaving the original file
descriptor open and leaking at the end of these statements. Only the
output file descriptor has its ownership transferred to `File` and will
be cleaned up properly.
This should cause the reading end to read EOF and return zero bytes when
`stdin` and `stdout` is open, rather than remaining open "indefinitely"
(barring the whole process being taken down) as there will always be
that one file descriptor referencing the input end of the pipe.
- Lets us build with cargo ndk 3+
- Lets us remove suppression for false-negative clippy warning about unsafe
blocks in unsafe functions
- 1.68.0 notably also builds the standard library with a newer r25 NDK
toolchain which avoid the need for awkward libgcc workarounds, so it's
anyway a desirable baseline for Android projects.
Some of the dates were wrong from copy&pasting, there was no changelog
entry for adding `InputEvent::TextEvent`, and the release date for
0.5.0-beta.0/1 was missing.
Robert Bragg