cannot locate symbol "AConfiguration_getScreenRound"

[drkstr101]

Hello,

I am having a bit of trouble linking your ffi bindings with my own, and was hoping to get some feedback on where I can start working on the problem. Everything works as expected until I do this: let app = unsafe { AndroidApp::from_ptr(state) };, which throws the following runtime exception.

java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "AConfiguration_getScreenRound" 

It could be related to this issue, which was fixed in NDK r22, which isn't out yet. I am on r21, while your bindings were generated with r20. Do you have plans to update your bindings for the new LTS release, or should I just target r20 in my own ffi bindings? This may possibly be completly unrelated. I'm kinda stabbing in the dark here.

Cheers, and thank you for your time!

[dvc94ch]

looks like you're not linking against libandroid.so. That issue should be fixed in #13

[dvc94ch]

I've not had that issue, so I'm not sure there's something wrong with the bindings...

[drkstr101]

Yup, I was missing this in my build.rs

println!("cargo:rustc-link-lib=log");
println!("cargo:rustc-link-lib=android");

Thanks for pointing me in the right direction!

[drkstr101]

cc @dvc94ch

Well this is strange. I thought it was my build process for compiling android_native_app_glue, so I updated it to manually call out to the LLVM build toolchain. As far as I can tell the symbols are being linked correctly.

nm -gDC target/aarch64-linux-android/debug/libnative_app.so | grep AConfiguration_getScreen               
             U AConfiguration_getScreenHeightDp
             U AConfiguration_getScreenLong
             U AConfiguration_getScreenRound
             U AConfiguration_getScreenSize
             U AConfiguration_getScreenWidthDp

Here is the rustc command that compiled native_app.

rustc --crate-name native_app native_app/src/lib.rs \
    --error-format=json \
    --json=diagnostic-rendered-ansi \
    --crate-type staticlib \
    --crate-type dylib \
    --emit=dep-info,link \
    -C debuginfo=2 \
    -C metadata=dd2ed58ae3dc50e8 \
    --out-dir /CartoonifyIt/target/aarch64-linux-android/debug/deps \
    --target aarch64-linux-android \
    -C ar=/ndk/20.1.5948944/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android-ar \
    -C linker=/CartoonifyIt/build/linker-wrapper/linker-wrapper.sh \
    -C incremental=/CartoonifyIt/target/aarch64-linux-android/debug/incremental \
    -L dependency=/CartoonifyIt/target/aarch64-linux-android/debug/deps \
    -L dependency=/CartoonifyIt/target/debug/deps \
    --extern android_ndk=/CartoonifyIt/target/aarch64-linux-android/debug/deps/libandroid_ndk-c531b0396b463b42.rlib \
    --extern android_ndk_sys=/CartoonifyIt/target/aarch64-linux-android/debug/deps/libandroid_ndk_sys-29a37abb54e8dbf9.rlib \
    --extern jni=/CartoonifyIt/target/aarch64-linux-android/debug/deps/libjni-a3b596afb28e13d5.rlib \
    -L native=/CartoonifyIt/target/aarch64-linux-android/debug/build/native_app-24a9175d5e174c92/out \
    -l static=android_native_app_glue \
    -l log \
    -l android \
    -L native=/CartoonifyIt/target/aarch64-linux-android/debug/build/backtrace-sys-ba9a5a7b85f037f8/out

And yet I am still getting cannot locate symbol "AConfiguration_getScreenRound" at runtime. Any idea what's going on here? I'm now at a loss where to go next.

PS: Sorry to bother you with my own personal issues, you just seemed like a good person to ask.

edit

I just realized that nm is actually reporting the symbols as undefined, so I guess I still have some more work to do.

[dvc94ch]

Hard to tell. You're not using cargo-apk so I don't know. This seems weird:
-C linker=/CartoonifyIt/build/linker-wrapper/linker-wrapper.sh

[dvc94ch]

Did it work before you added camera support?

[drkstr101]

Yup, the challenge is building without cargo-apk it seems. The rust-android-gradle plugin seems to provide better hybrid app support, but doesn't provide any injected glue code. I also can't seem to run cargo-apk without downgrading my openssl, which is a rabbit whole I didn't want to go down.

I was initially making headway with camera support using the texture-view example, but this is a slightly different setup for the main activity thread, and doesn't require anroid_native_app_glue to work.

The problem started when I attempted to switch to the basic example since it has functionality for taking photos, which I wanted to test. This example uses android_native_app_glue to implement the main thread natively, and so I will need to compile it myself to implement the example in rust.

This is where I've been stuck the past few days. And everything was going so smoothly up to this point. I may just scrap the basic example for now and just focus on the capture feed (aka texture-view). The structure of the application should be irreverent to the api regardless.

Thoughts?

[dvc94ch]

Well you should be testing things individually. So the code should work before and after your changes.

[drkstr101]

Unfortunately, I can't even get a simple "Hello, World!" up and running using the android_native_app_glue, so I have nothing to compare it to. I think I will just focus on the texture-view example for the time being, as this will drop the dependency on android_ndk crate and allow me to focus on a more pure* api for ndk_camera.

[drkstr101]

crate_type = ["staticlib", "cdylib"] turned out to be the magic bullet. I was originally using dylib, which does not statically link external symbols.

[blaind]

Stumbled upon this in a following case:

• Setting bevy (https://github.com/bevyengine/bevy/) as a dynamic plugin (crate-type = ["dylib"])
• Having a device (Oculus Quest 2) which has API level 29 -> AConfiguration_getScreenRound is only present in API level 30 and hence system-provided libandroid.so doesn't provide this symbol

Getting device API level

ANDROID_SDK_ROOT/platform-tools/adb shell getprop ro.build.version.sdk
29

Not sure how to solve this yet. My current guess is this is caused because the symbols usages have been baked into FFI (https://github.com/mb64/android-ndk-rs/tree/master/android-ndk-sys/src)) - maybe these should be generated when compiling based on the desired target level?