Hi there, I am building and testing custom platform plugin based on the Anbox Platform SDK 1.17.0.
According to the link below, it seems that bidirectional communication between an Android app and a client is possible for Out-of-Band (OOB) Data when using the WebRTC platform.
I’m wondering if there are any specific items provided by the Anbox Platform SDK or alternative methods for enabling communication with an Android app on a custom platform.
Assuming that I cannot use anbox-webrtc-data-proxy, I have tried with the following two approaches.
I attempted to open a Unix domain socket for several paths on the platform and accessed them from the Android app, but it appears that the access is not successful.
For TCP sockets, I opened 23456 tcp port on platform, it seems that accessing is possible from the Android app using the assigned address:23456 of the container(192.168.x.x), rather than 127.0.0.1:23456.
I’m wondering if there are any specific items provided by the Anbox Platform SDK or alternative methods for enabling communication with an Android app on a custom platform.
The out-of-band data feature as described in the documentation you linked is only available when using the webrtc platform we provide with Anbox Cloud as it is tightly coupled with its internals.
Is there a specific reason you want to implement your own platform? Are you missing any features in the existing webrtc one?
I attempted to open a Unix domain socket for several paths on the platform and accessed them from the Android app, but it appears that the access is not successful.
You need to create a file based unix domain socket, abstract ones will not work. Both the Anbox and Android live in different IPC namespaces, so access abstract sockets of the other is not possible.
Once you have created a file based unix domain socket, you need to next get it bind mounted into the Android container. For that you can create a /var/lib/anbox/lxc-extra.conf inside the instance which allows you to add to the liblxc container Anbox creates for Android. Adding a bind mount for a unix socket on the Anbox side would look like
With that in place you will have a /dev/my.unix inside the Android container. However you need to ensure that the socket is created before the Android container is started by the Anbox runtime and stays alive for as long as the Android container is up.
The downside of this approach is that regular, non systems apps are not allowed to open the socket and you need to implement some kind of system service to make communication possible.
For TCP sockets, I opened 23456 tcp port on platform, it seems that accessing is possible from the Android app using the assigned address:23456 of the container(192.168.x.x), rather than 127.0.0.1:23456.
That is the simpler approach. As you correctly noted you need to communicate via the anbox0 bridge with the outer world, so simplest is if you bind to the bridge address on a port (e.g. 192.168.250.1:23456).
Let us know if there is anything else we can help with.
Thank you for your response.
I will try the method you suggested.
The out-of-band data feature as described in the documentation you linked is only available when using the webrtc platform we provide with Anbox Cloud as it is tightly coupled with its internals.
Is there a specific reason you want to implement your own platform? Are you missing any features in the existing webrtc one?
I wanted to use the webrtc platform that provides both performance and stability.
However, I thought that the anbox-stream-agent/anbox-stream-gateway/webrtc platform in Anbox Cloud’s streaming stack could not fully replace specific functionalities / business flow to our service (e.g., perform user authentication for our service within the platform, handling additional session /user information in gateway. etc.).
Therefore, I replaced the services corresponding to the agent and gateway with our own services. And I integrated communication capabilities with our service into the Android app added to the container, along with WebRTC functionality, for streaming.
However, the streaming performance fell short compared to the Anbox WebRTC platform. (using Nvidia GPU machines)
I speculated that one of the reasons for the lower performance could be the inability of the Android app to perform video hardware encoding. So, I thought that implementing video hardware encoding at the Linux layer include the Anbox Platform SDK and developing the communication capabilities between our service (agent or gateway) and the Android app would be necessary.
We specifically designed the different components (gateway, agent, webrtc platform) to not have to deal with user authentication or information as for everyone this will look different. The idea is that you implement such things on top. For example should a user never talk directly to the gateway API to create or join a streaming session. There needs to be a service put in front which handles user authentication and then talks in the background to the gateway to attach to existing sessions / create new ones.
I speculated that one of the reasons for the lower performance could be the inability of the Android app to perform video hardware encoding. So, I thought that implementing video hardware encoding at the Linux layer include the Anbox Platform SDK and developing the communication capabilities between our service (agent or gateway) and the Android app would be necessary.
Yes, Android side video encoding is currently not implemented and it will always perform slower for NVIDIA GPUs as there is no direct access possible to the actual driver from Android. All encoding happens in the optimal case on the Ubuntu side to ensure direct access to the GPU and drivers. For AMD and Intel GPUs this is different as in that case we have direct access to the GPU and drivers within Android, though we haven’t yet wired up encoding inside the Android framework for these.
Let us known if you need any further clarification or help.