I am writing a C++ library to allow two Android applications to communicate and exchange data. The server-side appication is pure C++ too, with a small amount of Java to create a service/activity. Some of the shared data is best managed by AHardwareBuffer
objects, as according to the documentation they provide zero-copy/shared memory view of the underlying data.
Because of this, I was initially planning to use abstract Unix Domain Sockets, and then NDK's AHardwareBuffer_sendHandleToUnixSocket and AHardwareBuffer_recvHandleFromUnixSocket for the transfer. However I discovered recent Android security changes now deny Unix Domain Sockets for IPC. These deny my client application from connecting to the server's socket.
Then I started looking into Binder and AIDL as this seems to be the recommended way of doing IPC. However I cannot see how Binder could work with AHardwareBuffer.
I've thought about the following but am not sure which one to pursue further:
Create a pair of connected sockets on the server side, send one to the client over Binder (I've spotted AParcel_writeParcelFileDescriptor and its read counterpart in NdkBinder). However I am not sure whether SELinux will allow reads and writes from/to the socket in the untrusted app.
Using JNI to convert from AHardwareBuffer to a Java HardwareBuffer, and then using writeToParcel. NdkBinder then has AParcel_fromJavaParcel. However I don't see how that will work on the other side - nothing along the lines of
AParcel_toJavaParcel()
in the NDK or how to turn a Java Parcel back into a Java NativeBuffer. For the latter I was looking at readParcelable, but in general this method of going between Java and C++ seems very messy.Looking at the NdkBinder API, there's a bunch of
AParcel_read*
andAParcel_write*
functions, but the only ones that are remotely relevant are theParcelableArray
ones. But I cannot find online examples on how they can be used. Is a "parcelable" here ajobject
which corresponds to a type which implementsandroid.os.Parcelable
? If the Java APIs for Parcel.readParceableArray are the NDK's direct counterparts then this would suggest so. In this case I reckon this may be my best option. Also - if this method is viable, does it still preserve the zero-copy nature of the AHardwareBuffer transfer?