Android Server Launcher as a self-started service on OSVR

[Bundenth]

Hello,

I've read in the forums and in some comments that there is a discussion to make the android server launcher a self started service that is part of an OSVR android application to avoid users having to configure and install the server separately -which I see as a major stopper for most users.

I have also seen the JointClientKit API that sort of would circumvent the need of having a separate server but reading the fine print this may not be the desired path for developers -more lag, inability to use async libraries etc.

Is the 'service route' being explored? If so, any idea when this will become available? To be honest, as a developer I see the need for starting a separate server a major issue with end users, particularly in android, where people won't be patient enough to install anything on top of their app.

In the meantime, is there any workaround to having the server running? Would you recommend using the JointClientKit API?

[Bundenth]

BTW I am mostly interested on having this as part of the OSVR Unity plugin, but if the android launcher becomes part of the main OSVR android build then I could rewire it myself I suppose.

[JeroMiya]

The JointClientKit API is currently designed as a kind of a developer test framework - it wasn't initially designed as something you'd make use of in production. Instead, production apps should use the auto-start API, which is more of a black box - the implementation details are hidden to an extent. The idea is that the auto-start API shields client developers from knowing whether the server is running in-process or in a system service, and what kind of VRPN transport is being used (TCP/IP, UDP, in-memory stream, etc...). Whereas the JointClientKit gives you more control over the in-process server and the VRPN connection - more than you'd need typically. But, in its current form, it's currently not thread safe. The client context and the server have to be in the same thread (the VRPN connection is an in-memory connection but it's not a thread-safe stream implementation currently), which is a non-starter for production apps - that's the source of the lag you mentioned.

You can still run the server in a separate thread however. Currently the OSVR-Core implementation on Android starts the server in a separate thread in-process on Android when you use the auto-start API. Theoretically there should not be any measurable lag difference between a server thread in the same process as the client, and a separate server process.

However, there is an on-going discussion on how OSVR auto-start should work on Android here:
OSVR/OSVR-Core#433

It's a long thread, but if you feel as I do that the separate app requirement is too onerous for most phone apps on the Play store, please add your feedback there. Your voice counts! :)

[Bundenth]

@JeroMiya: Thanks!

I am still getting my head around OSVR so apologies if some of the questions are dumb:

1. I understand I should probably stay away from JointClientKit API. You mentioned the auto-start API, but I am confused as to what are you referring to here. Do you mean the server can get auto-started when the client app is run? Or is this an auto client-server connection thing that relies on a server being up and running already?

2. I believe I got confused when you were talking about the JoinClientKit and then moved on to the official as-is behaviour. Following the documentation I currently can run a Unity android demo by installing, configuring and running a separate app that is the OSVR server. This is the core of my request, whether we can avoid doing so -as a developer I don't mind, but if users are forced to do anything remotely similar, we can say goodbye to them. Then you mention that OSVR Core in android starts the server in a separate thread -is this the separate OSVR server I configured and installed?.

3. From the post you linked I can see there are discussions on how to solve that problem -although I haven't spent enough time to understand fully what the two alternatives are! However I will add my two cents to it :)

Thanks again!

[JeroMiya]

The server auto-start API is part of the ClientKit here:
https://github.com/OSVR/OSVR-Core/blob/master/inc/osvr/ClientKit/ServerAutoStartC.h

It's a black box, and it's opt-in. You call osvrClientAttemptServerAutoStart() once at the beginning of your application, prior to creating any OSVR_ClientContext (or the C++ equivalent), then call osvrClientReleaseAutoStartedServer() when your app exits. I am thinking of adding a pause and resume API for better lifecycle management, but this is how it works now. There is no indication of failure on the auto-start API itself - failure can be determined by trying to create a client context and failing (check status API never returns success), or creating an interface and not getting a report.

On the PC, the auto-start API looks for the OSVR_SERVER_ROOT environment variable, and if it exists, attempts to launch osvr_server or osvr_server.exe process (depending on your platform) in that directory. On Android, the auto-start API launches an in-process server in a separate thread. This differs from the JointClientKit api in that it starts a real server instance, just in a thread of the same process instead of in a separate process. It also handles plugins differently - plugins are bundled with your app and loaded from the global symbol table. That way you don't need to copy them into your app's data directory or the SD card and manually load them from there.