java.leng.UnsatisfiedLinkError: Shared library "data/app/.../libkaldi_jni.so" already opened/loaded by ClassLoader ...

My issue comes a little complex which results from one of my repos. The demo works pretty well offline but, if I understood the code corrently, the model can only be initialized with a android activity class. This bring troubles when I need to use the model in a non-activity java class file, which is required in my repo. I am wondering if we can initialize the model inside a normal java class (non-activity)?

Actually, my repo contains a project that tries to load the voice assistant system apk non-activity components using DexClassLoader. The voice assistant system apk contains an activity and several non-activity java class files. This results in a conflict since the .so library cannot be loaded by more than one class loader. In the app’s activity class, the app load the kaldi_jni once; in the project mstorm, it loads a non-activity component which loads the kaldi_jni again. The two cannot run at the same time, and will produce the error saying that libkaldi_jni.so already loaded (mstorm loaded the component first, the voice assistant system app was launched later)

I tried to solve this problem by either specifying a static kaldi_recognizer in the activity java class and call it in the non-activity component, or initialize the kaldi_recognizer by writing a constructor for the activity java class and produce the error in the attached screen shot here

Any suggestions to work around this problem will also be appreciated.

[nshmyrev]

(i.e., native call is available in the wrapper, native call can system.loadlibrary are in the same java wrapper)

I have just pushed the update into vosk-api and corresponding vosk-android-demo update which should load jni inside vosk-android jar. See here:

https://github.com/alphacep/vosk-api/commit/38dbaa15ead20ad055bf88c43584e512579b5738

and other recent commits too.

It seems if the build.gradle in a model is set to be apply plugin: ‘com.android.library’, the java files in the src/java directory cannot import org.kaldi.Model. This stops me from using the Model wrapper inside a library model, however this is needed in my case. I am wondering if this is correct and if there are any methods to hack this around without much effort?

It is hard to guess what is going on in your case, you need to explain better and provide more details. I have no idea what is “inside a library model”.

If I can import and call the org.kaldi.Model wrapper without an aar but with only so files in main/src/jniLibs, it should also resolve my problem. Is there such an alternative?

You can do it too, I see no problem doing that.

[liuyibox]

Thanks @nshmyrev. This resolved my problem! Although I don’t know maven at all, but the bintray is always working.

alphacep/vosk-api@38dbaa1

and other recent commits too.