{"action":"opened","issue":{"url":"https://api.github.com/repos/OSVR/OSVR-Core/issues/433","repository_url":"https://api.github.com/repos/OSVR/OSVR-Core","labels_url":"https://api.github.com/repos/OSVR/OSVR-Core/issues/433/labels{/name}","comments_url":"https://api.github.com/repos/OSVR/OSVR-Core/issues/433/comments","events_url":"https://api.github.com/repos/OSVR/OSVR-Core/issues/433/events","html_url":"https://github.com/OSVR/OSVR-Core/issues/433","id":154301676,"number":433,"title":"Discussion: OSVR on Android - server auto start vs shared service app","user":{"login":"JeroMiya","id":320332,"avatar_url":"https://avatars.githubusercontent.com/u/320332?v=3","gravatar_id":"","url":"https://api.github.com/users/JeroMiya","html_url":"https://github.com/JeroMiya","followers_url":"https://api.github.com/users/JeroMiya/followers","following_url":"https://api.github.com/users/JeroMiya/following{/other_user}","gists_url":"https://api.github.com/users/JeroMiya/gists{/gist_id}","starred_url":"https://api.github.com/users/JeroMiya/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/JeroMiya/subscriptions","organizations_url":"https://api.github.com/users/JeroMiya/orgs","repos_url":"https://api.github.com/users/JeroMiya/repos","events_url":"https://api.github.com/users/JeroMiya/events{/privacy}","received_events_url":"https://api.github.com/users/JeroMiya/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2016-05-11T17:43:35Z","updated_at":"2016-05-11T17:43:35Z","closed_at":null,"body":"Currently on Android, OSVR has an implementation of the server auto-start API that starts a server in-process with the client app. The server runs in its own thread. It does not require a java layer to initiate - the same C++ code on Android will work on PC/Mac/Linux.\r\n\r\nChase Cobb from Razer recently announced some work he's done on an OSVR service that handles the OSVR server:\r\nhttps://www.reddit.com/r/OSVR/comments/4iq4vz/osvr_android_update_02102016/\r\n\r\nThis issue is to discuss the two approaches and get community feedback, as well as to document decisions going forward. The current plan for OSVR on Android is for client apps to use the auto-start API as a black-box to ensure the server is running. The implementation would be to start the server in the same process (preferably using a memory stream instead of IP looback for the VRPN connection) in its own thread. The server would then look in a shared location, or use a binder, to access a shared server configuration if it exists, or fall back to a reasonable default configuration. The benefits to this approach are that the same C++ code works on Android as it does on PC/Mac/Linux. It also keeps client applications self-contained and stable - only optionally taking advantage of a shared configuration. It's more friendly to users, who are no longer required to download a separate app to get a VR app to work. It's more battery friendly - if you close an OSVR app, you can be sure that the server isn't still running in the background.\r\n\r\nThe shared service/app is the alternative. In this approach, the server runs as an Android service. It requires client apps to use a Java layer to initiate the connection to the server. OSVR apps depend on the OSVR app/service being installed to work, and must require the user to download the app if not already installed. The OSVR service app can be updated independently of client applications, which may break existing applications not tested on newer server versions. Depending on how the scheduler is tuned on a given Android device (they all differ in this regard), the background service may be punished if it takes up too much resources relative to the current foreground app, which may result in additional latency and hitches. The imaging plugin for Android cannot work with a shared service/app as it currently uses a special in-process-memory VRPN message type that only works when the server is in the same process as the client. The binder API is not intended for very large amounts of data, so the imager cannot be adapted to run over the binder interface.\r\n\r\nI am heavily leaning towards the original plan - the in-process server thread started by the auto-start API. Feel free to discuss."}}