add android support for api version 21+ #65

name1e5s · 2021-10-09T05:54:31Z

Since this PR, libc crate supports dl_iterate_phdr for android api version 21+. Hence gives us the ability to support android.

name1e5s · 2021-10-09T05:56:12Z

src/linux/mod.rs

@@ -27,6 +27,19 @@ type Phdr = libc::Elf32_Phdr;
 type Phdr = libc::Elf64_Phdr;

 const NT_GNU_BUILD_ID: u32 = 3;
+const PT_NULL: u32 = 0;


Sadly libc crate does not add these constants to android, we need to manually copy them here for now.

name1e5s · 2021-10-10T08:38:30Z

src/linux/mod.rs

@@ -273,6 +286,10 @@ impl<'a> SharedLibrary<'a> {
        F: FnMut(&Self) -> C,
        C: Into<IterationControl>,
    {
+        #[cfg(target_os = "android")]


dl_iterate_phdr on android under api 27(8.1) will pass a zero-filled dl_phdr_info struct before any real shared library info, we should ignore it.

philipc · 2021-10-11T02:30:04Z

src/linux/mod.rs

@@ -273,6 +286,10 @@ impl<'a> SharedLibrary<'a> {
        F: FnMut(&Self) -> C,
        C: Into<IterationControl>,
    {
+        if (*info).dlpi_phdr.is_null() {
+            return CONTINUE;
+        }


Do these null entries have valid values for the other fields (name and addr)? If so, what are they?

Result differs by android api version:

on android 8.0 and older the null entries does not contain any useful fields,

- on android 8.1 and android 9, the entry with a null dlpi_phdr contains the name of '/system/bin/linker' and its load address
- android 10+ won't return any null entries
The screenshots are the result of running example program at https://man7.org/linux/man-pages/man3/dl_iterate_phdr.3.html on devices of different android versions.

PS:
'/system/bin/linker' with base address on android 8.1:

May be we should create a SharedLibrary with no headers for this situation?

We could, but I'm happy to wait until someone needs it, since I don't see what use it is without the program headers.

src/linux/mod.rs

philipc

Thanks!

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#65 rust-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 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.

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#65 rust-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.

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#65 rust-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 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.

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#65 rust-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.

name1e5s commented Oct 9, 2021

View reviewed changes

add android support

9c0b2e8

name1e5s changed the title ~~add android support for api version 21+~~ WIP: add android support for api version 21+ Oct 9, 2021

yuhaixin.hx added 2 commits October 9, 2021 19:30

modify test for android platforms

1bacae3

fix test on android under api 27

6b80f01

name1e5s changed the title ~~WIP: add android support for api version 21+~~ add android support for api version 21+ Oct 10, 2021

name1e5s commented Oct 10, 2021

View reviewed changes

fix build on earlier versions of rust

fb55401

philipc reviewed Oct 11, 2021

View reviewed changes

philipc approved these changes Oct 11, 2021

View reviewed changes

philipc merged commit c5a0293 into gimli-rs:master Oct 11, 2021

philipc mentioned this pull request Oct 14, 2021

Support Android and iOS #66

Closed

MarijnS95 mentioned this pull request Jan 7, 2025

android: Set SDK/API level via version-suffxed --target triple rust-mobile/xbuild#209

Open

MarijnS95 mentioned this pull request Jan 7, 2025

Android backtraces don't work since gimli is used as the symbolizer rust-mobile/android-activity#54

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

add android support for api version 21+ #65

add android support for api version 21+ #65

name1e5s commented Oct 9, 2021

name1e5s Oct 9, 2021

name1e5s Oct 10, 2021

philipc Oct 11, 2021

name1e5s Oct 11, 2021

name1e5s Oct 11, 2021 •

edited

Loading

philipc Oct 11, 2021

philipc left a comment

add android support for api version 21+ #65

add android support for api version 21+ #65

Conversation

name1e5s commented Oct 9, 2021

name1e5s Oct 9, 2021

Choose a reason for hiding this comment

name1e5s Oct 10, 2021

Choose a reason for hiding this comment

philipc Oct 11, 2021

Choose a reason for hiding this comment

name1e5s Oct 11, 2021

Choose a reason for hiding this comment

name1e5s Oct 11, 2021 • edited Loading

Choose a reason for hiding this comment

philipc Oct 11, 2021

Choose a reason for hiding this comment

philipc left a comment

Choose a reason for hiding this comment

name1e5s Oct 11, 2021 •

edited

Loading