Command line executable panicks when using ndk-glue / NativeActivity Code

[szsoftware]

Hi there,
following scenario:
An executable compiled with android/termux framework/toolchain panicks with code that points to some Activity logic.

thread 'main' panicked at 'called Option::unwrap() on a None value', /home/builder/.cargo/registry/src/github.com-1ecc6299db9ec823/ndk-glue-0.2.1/src/lib.rs:42:39

Of course there is a NPE since there is no gui application, respectively Activity/Looper involved (the executable is called from adb-shell or via System.exec("myRustExecutable someInput") ).

So several questions: How can I compile the whole thing to hunt down the error, so I can patch that call out?
How can I otherwise omit/circumvent this piece of gui code?

If I only had a full stacktrace, I would look into the calling code, but I have no idea when the ndk calls ndk-glue.
Due to this massive crosscompiling toolchain involved I have no clue how to debug anything.

Thanks for your help!

[MarijnS95]

Of course there is a NPE since there is no gui application, respectively Activity/Looper involved (the executable is called from adb-shell or via System.exec("myRustExecutable someInput") ).

If you are not compiling an Android app - that is inherently forced to use NativeActivity - but a simple binary to be executed you don't need android-ndk-rs at all 🎉

with code that points to some Activity logic.

if you however need access to Android Activity logic, circumvent ndk-glue and use the ndk crate directly: assuming the app you're calling this from with System.exec("myRustExecutable someInput") is passing the Context that you might need.

Just use cargo build to get a normal binary that can be executed, without any ndk_glue::main macro on fn main.

Cargo will automatically compile it for your target architecture which is inherently the correct one on Termux, but when cross-compiling on a host, be sure to compile to the aarch64-linux-android (or arm-linux-androideabi on 32-bit devices) triple by passing --target <target triple> to cargo build. All available target architectures are listed here.

You can install these targets with rustup target add <target triple>. Again, this is only necessary when cross-compiling from a host, and is inferred when ran directly from Termux.

[MarijnS95]

If I only had a full stacktrace, I would look into the calling code, but I have no idea when the ndk calls ndk-glue.
Due to this massive crosscompiling toolchain involved I have no clue how to debug anything.

For what it's worth, even without stacktrace this is relatively easy to debug. The error includes all necessary information: src/lib.rs:42 in the ndk-glue crate on version 0.2.1:

https://github.com/rust-windowing/android-ndk-rs/blob/7d36455f8b850ce716debcef551f86fc7fa9ecaf/ndk-glue/src/lib.rs#L41-L43

Which is only ever assigned once, when the native activity is set up:

https://github.com/rust-windowing/android-ndk-rs/blob/7d36455f8b850ce716debcef551f86fc7fa9ecaf/ndk-glue/src/lib.rs#L140

To answer your question, nothing calls calls fn native_activity() (except the jni_audio example project).

[MarijnS95]

@szsoftware Any extra context that we can use to help you resolve this issue? Inclined to close otherwise.

[szsoftware]

Hi there!

Thanks for the reminder. I will push my investigation on this issue on highest priority, since I'm urging for any developments regarding this issue/battlefield (tectonic on Android).

[MarijnS95]

Closing due to inactivity. Feel free to reopen if more information is available.

[Babber]

Dear All,
I have found this thread because I am trying to run tectonic in Termux and it also returns this error message:
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /home/builder/.cargo/registry/src/github.com-1ecc6299db9ec823/ndk-glue-0.3.0/src/lib.rs:54:39
Is there any way to fix this? Is there any reasonable workaround?

[pkgw]

If anyone can get a full backtrace of the Tectonic crash that is causing this panic, I think that would still be helpful for solving the reported problem — although my impression is that it's unlikely to represent a bug in this repo. I don't know Android at all, but it sounds like maybe some aspect of Tectonic's dependency tree is turning on stuff that is expecting it to have GUI features, when it doesn't? I feel like maybe we need to add a default-features = false somewhere in our Cargo.toml files.

[MarijnS95]

@pkgw That observation is entirely correct. As replied in tectonic-typesetting/tectonic#926 (comment) this is most likely caused by a transitive dependency assuming an Android app - started through ndk-glue (and hopefully later ndk-context) - triggered by cfg!(target_os = "android") code which is how Termux compiles their Rust code, despite having to function as if it's a "normal" desktop/commandline binary.

We'd have to come up with a more global/accepted solution for this, even though Termux appears to be one of the only/few bits of software that wouldn't want their code to be assuming / defaulting to Android App behaviour.