You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
android: Set SDK/API level via version-suffxed --target triple
We haven't set the SDK/API level via the `__ANDROID_API__` define for
a very long time and so far got away with it. However, while debugging
why `backtrace` (and by extension Rust `std` which reuses that crate)
wasn't generating symbolicated stacktraces in `panic_log`, and why
`findshlibs` wasn't providing the list of loaded libraries to `sentry`,
we found that both rely on expanding the `__ANDROID_API__` define
via compiling a small C file via `cc` to make the code conditional on
SDK/API >= 21:
gimli-rs/findshlibs#65rust-lang/backtrace-rs#415
(It would have been lovely if these crates emitted a `cargo:warning`
when the define wasn't set at all, indicating an "incomplete"
cross-compiler setup, and/or looked at the runtime Android API version
via something like rust-mobile/ndk#479.)
Note that `backtrace 0.3.74` / Rust 1.82
(rust-lang/rust@0763a3a) no longer rely on
this because Rust 1.82 bumped the minimum SDK/API level to 21:
rust-lang/backtrace-rs#656
We could set this define directly, or rely on `clang` to set it
for us by appending the SDK/API level to the target triple, of
the form `<arch>-linux-android<sdk level>`. The latter is more
common. Keep in mind that the `cc` crate adds an unversioned
`--target=<arch>-linux-android` to the command line arguments as well,
but clang seems to deduplicate them (or look at the latter `--target`
which contains our version).
Note that this effectively reverts
rust-mobile@32efed6 because
we must now always pass the SDK level via the triple again, even if the
host also happens to be Android with the same architecture.
0 commit comments