Suggestion on how to use shared memory in Android platform

[Tuhin Sengupta]

Hello,

  I am working for a product company, where we are trying to build an application which has the following layers:-

1. Presentation Layer (Developed using Java - Android App facing the user)

2. Client Layer - biz logic and client to the Server layer below - C/C++ 

3. Server Layer - mainly a single file database manager (our own database) and communication manager for internet communication - C/C++

Now, we are doing various experiments to find the best way to achieve intra-process communication in these three layers - layers 2 and 3 are straight forward, they are talking natively using C/C++ classes/methods/functions. We are mainly looking for a way to communicate between Layer 1(Java) and Layer 2(C/C++). One obvious choice is JNI. But JNI comes with lots of overhead - the data conversions/serialization being one of them. Secondly, our database going to store large objects and using JNI to pass objects between them are not really an option. 

Therefore we are exploring the option to share data through Android kernel - named pipe, shared memory etc. - where we can handle raw data. We found the share memory has very limited suport (POSIX standards not implemented). We also tried using file-backed mmap() - there the problem is it very unreliable.

Keeping in mind that we will be supporting Android API level 21 onwards (Lollipop), what is the best way forward for this architecture?

Regards,

Tuhin Sengupta

[Shahriar Vaghar]

Use hardware buffer

https://medium.com/@spencerfricke/android-ahardwarebuffer-shared-memory-over-unix-domain-sockets-7b27b1271b36

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/0c98e6f6-1ac4-49ae-bd6e-cec25720a0e0%40googlegroups.com.

[Glenn Kasten]

NDK supports binder for IPC.

The Java APIs for binder are at

https://developer.android.com/reference/android/os/Binder

The NDK-specific APIs for binder are at

https://developer.android.com/ndk/reference/group/ndk-binder

 

All available NDK APIs are at

https://developer.android.com/ndk/guides/stable_apis

To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk+unsubscribe@googlegroups.com.

[Phil Burk]

> One obvious choice is JNI. But JNI comes with lots of overhead - the data conversions/serialization being one of them.

You could pass a ByteBuffer object through JNI. The byte array is accessible from both Java and C.

Then you can manage your own serialization.

https://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html

Phil Burk

[Alex Cohn]

On Thursday, February 6, 2020 at 9:55:44 PM UTC+2, Phil Burk wrote:

> One obvious choice is JNI. But JNI comes with lots of overhead - the data conversions/serialization being one of them.

You could pass a ByteBuffer object through JNI. The byte array is accessible from both Java and C.

Then you can manage your own serialization.

https://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html

Phil Burk

 

The array-backed ByteBuffer has no advantages over arrays at all, while access to direct ByteBuffer is rather inefficient in Java. I would recommend ByteBuffer (direct) as a a container primarily read/written in C, but "managed" in a sense in Java.

On the other hand, access to primitive arrays in Android JNI is quit efficient. I have never came across the situation where GetPrimitiveArrayCritical() would result in copying the values on the C side. Note that shared memory between Java and C also requires same serialization as JNI with ByteBuffers.

BR,

Alex Cohn