Android library does not support native C linking about porcupine

[kenarsa]

That seems to be the expected behavior as shared objects are exporting functions with JNI signature. Does that make sense?

[pabloxid]

Maybe... but why do not expose C functions directly, as you do in Windows, Linux, raspberry, etc.?
You can do both things, as many android libraries do, like opencv for example.

[kenarsa]

This is just how Android build system works by default. We didn't get any request for alternatives. What is your use case?

[pabloxid]

I'm working on a project in which there is an Android application with a native part in a shared library. It's an embedded system and we need maximum performance. We want to integrate a voice command, but, by the way code is organized, audio and video parts are developed in C/C++. On the other hand, I think that it's more efficient to directly access the C API than to use the JNI interface, in this case.

[kenarsa]

OK. Yeah, you might get some extra efficiency there. But it is minimal in this case as processing is done all in C and moving audio data around is fairly lite compared to image/video due to much smaller size.

I made a task to look into if we can expose extra functions in the shared object for v1.5 release. That would be the preferred solution.

In the meantime, the library is accessible from Java through JNI.

[pabloxid]

Thank you.

For now, can you send me a compiled version to try? I'll confirm if it works.

[kenarsa]

We have a task for it in our queue. I will update you when we start working on it.

[rtumelty]

+1 to this request - I have been struggling to get Porcupine working in Unity for Android, as it expects developers to be using Java. Unity uses Mono (C#) or IL2CPP (C++) frameworks, which experience segmentation faults whenever I try to call the init function. It would be much more straightforward to interact directly with the Porcupine library.

[kenarsa]

@rtumelty why not build against the shared object for Linux/Mac/Windows?

[rtumelty]

I am building for Android devices with ARMv7 and ARM64 architectures. x86/64 libraries won't work for the platform.

[pabloxid]

I notice that v1.5 is already out. Is this issue solved with that release?

[kenarsa]

We didn't get to this feature. But we will be working on it. It is being tracked here as well #115. There are few candidate solutions and we are in the decision-making process.

[pabloxid]

In fact, I don't understand why this issue occurs and why it's so difficult to fix it out.

The library is written in C, so the C API functions are there anyway. How is it possible to "hide" them? I include the .h header, so my code just compiles. Then the linker should find the functions there in the library, because the functions are there for sure, aren't they? That's very strange.

What I asked you by mail, since I actually work for a company that has bought or will buy a license, is that, in the meantime, simply take the source code you used for, say, the Linux library, and build it using NDK. I think that would be enough as a temporary solution for us. We don't need the JNI API, if the C API just works.

Thank you.

[kenarsa]

The Android binding is designed to be used via a Java interface and using the lib from C is not supported currently. There are use cases that would benefit from using the lib on Android directly from C. This is NOT supported yet. I do appreciate your input. But it is a decision on the Picovoice side if we want to support it when to prioritize it, and how to get it done.

[kenarsa]

we decided that we won't offer static libs for android. our offering for Android will be limited to shared objects and JNI interface.