Android support

[elBoberido]

Brief feature description

Supporting Android would increase our user base even more. It is also widely used in infotainments systems in the automotive world.

Detailed information

For now, this issue shall just act as a place where interesting information regarding the Android port can be gathered.

References

• Gradle - Plugin
• Rust JNI
• UniFFI - a multi-language bindings generator for Rust
  • might also be interesting for Python, Golang, C# and Swift
• Rust Android Gradle Plugin
  • another gradle plugin; this one is from Mozilla

[calvin2021y]

maybe first step just add termux tests case without JNI stuff, traits it like linux.

[journaux]

significant increase in user base - we'd look at adopting. please let us know how to help accelerate timeline (presuming the zero copy semantics maintained / better than binderfs)

[elfenpiff]

@journaux

significant increase in user base

I agree. We wish to work on this, but the core team is currently working on other customer-accelerated features like Python support, request-response, and blackboard pattern.

please let us know how to help accelerate timeline

Please look at the bottom of the main readme if you would like to have a contact to accelerate this feature as well.

Things that would help us as well would be documentation on how to set up a development environment with Rust for Android, with iceoryx2 as an example. This would provide us with the perfect starting point to start directly with the implementation. The lowest building blocks of iceoryx2 should already be compatible with android iceoryx2-pal-concurrency-sync.

(presuming the zero copy semantics maintained / better than binderfs)

Yes, zero-copy semantics would be maintained but it takes more effort than a platform like windows due to the sandbox nature of android. iceoryx2 requires direct access to lower system resources like shared memory, things which seem not be feasible with android - but I am not an android expert. See: https://developer.android.com/ndk/reference/group/memory#group___memory_1ga5bbfa70e48fcbc488a8cb8fa7657c878

Normally, multiple processes would open a shared memory with the same name, on android one process creates the shared memory and shares this shared memory via binder with the other processes. As soon as everyone has the shared memory handle, zero copy communication can start. So to get android running, we need to implement and add this as a subsystem to iceoryx2.

A port of iceoryx2 would have essentially two milestones:

1. it compiles on android and iceoryx2 can be used for intra-process communication
2. binder integration and iceoryx2 can be used for inter-process communication

iceoryx2 also provides a special optimization for intra-process. When you create a node like

let node = NodeBuilder::new().create<local::Service>()?; // local::Service instead of ipc::Service

then you use the process local optimized variant.

[elfenpiff]

@journaux Btw: this is the restriction we have to handle: https://stackoverflow.com/questions/53142275/can-i-share-memory-between-2-process-without-any-passing-in-android-ndk

[journaux]

agree w/ all the notes, came across iceoryx2 searching for an RPC over shared memory that works across windows/linux/android (each necessitate their own approach).

most IPC over shemem designs have brokerless discovery since memory regions are mapped via a common path / consistent hash, whereas android needs a central broker to maintain the lookup table of key -> file descriptor. for me, that's the largest change that needs to happen (i.e. separate, native activity to manage shmem index)

[zachary0101]

Any update on Android support?

[elfenpiff]

@zachary0101 somehow yes. We are working on getting the funding for it - a lot of people/companies are requesting it, but we are blocked until this is resolved. The actual implementation should take around 6 - 8 weeks.