mavlink / MAVSDK-Java

MAVSDK client for Java.
76 stars 44 forks source link

Android app crashes with std::bad_cast on mavsdkServer.run("udp://:14550") #169

Open josephm28 opened 5 months ago

josephm28 commented 5 months ago

Hi!

I'm using mavsdk:2.0.1 and mavsdk-server:2.0.0 in my Android app. I finally have everything compiling, but when I call mavsdkServer.run("udp://:14550"), I get an app crash with

libc++abi  E  terminating with uncaught exception of type std::bad_cast: std::bad_cast
libc  A  Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 16094 (mavsdk-event-qu), pid 15871

I've also been intermittently dealing with

java_vm_ext.cc:591] JNI DETECTED ERROR IN APPLICATION: field operation on NULL object: 0x0
java_vm_ext.cc:591]     in call to GetObjectField
java_vm_ext.cc:591]     from java.lang.String java.lang.Runtime.nativeLoad(java.lang.String, java.lang.ClassLoader, java.lang.Class)

but right now the first error is where I'm stuck.

I did see https://github.com/mavlink/MAVSDK-Java/issues/70 which looks like a similar error at the end of the thread, but no resolution there.

Do you have any suggestions?

JonasVautherin commented 5 months ago

Hmm... could you maybe try the latest version 2.1.0? https://central.sonatype.com/search?q=mavsdk

josephm28 commented 5 months ago

Updated and I get the same two errors.

josephm28 commented 5 months ago

I can get the sample android app working correctly, but the mavsdk version is pretty old. I'm trying to update that as well to 2.1.0 to narrow down issues.

josephm28 commented 5 months ago

Here's a PR to update several pieces of the android-client, including the mavsdk 2.1.0 - https://github.com/mavlink/MAVSDK-Java/pull/170 seems to build and run okay (at least drone connection).

So now I'm wondering if there's some dependency issue in my app... but not sure what that would be.

JonasVautherin commented 5 months ago

@Sefibrah: Does 2.1.0 work for you? Just to have another data point

josephm28 commented 5 months ago

I'm also occasionally seeing this error, again pointing to some weird dependency issue?

java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "_ZNKSt6__ndk14__fs10filesystem4path10__filenameEv" referenced by "/data/app/~~8GsfdN9bL2Pf58nQvs0l8g==/com.dronedeploy.beta-tXNIZA4nw3M4Efvp3NFflw==/lib/arm64/libmavsdk_server.so"...
                                                                                                        at java.lang.Runtime.loadLibrary0(Runtime.java:1082)
                                                                                                        at java.lang.Runtime.loadLibrary0(Runtime.java:1003)
                                                                                                        at java.lang.System.loadLibrary(System.java:1661)
                                                                                                        at io.mavsdk.mavsdkserver.MavsdkServer.<clinit>(MavsdkServer.java:6)
JonasVautherin commented 5 months ago

Are you getting mavsdk from Maven or compiling it yourself?

josephm28 commented 5 months ago

I'm using Maven.

We also use the DJI SDK in the same app and I think I've traced the issue to com.secneo.sdk. To set up that SDK, you configure (e.g. setup)

class MyApplication : Application() {
    override fun attachBaseContext(base: Context?) {
        super.attachBaseContext(base)
        // before installation, please don't use MSDK
        com.secneo.sdk.Helper.install(this)
    }
    ...
}

If you remove com.secneo.sdk.Helper.install(this) there are no issues with the JNI or the MAVSDK and I get a connection to the drone. Of course, that means that the DJI SDK doesn't work... So at least I know a bit more about what's causing it, but still not sure why it's causing the JNI crashes.

Sefibrah commented 2 months ago

@Sefibrah: Does 2.1.0 work for you? Just to have another data point

The update to 2.1.0 provided me a successful run, as well as a successful mission upload. However, when I tried again the same thing 2-3 months later, I encountered this issue #178, so I am not certain what is going on.