Android applications silently fail without explicit internet permissions.

[chase-cobb]

Because of the nature of the OSVR server client applications on Android require internet permissions.

If users don't explicitly enable internet permissions their applications will silently fail. This can be remedied by creating a minimal manifest.xml with the correct uses-permission tag in Assets->Plugins->Android. Unity will automatically merge the manifest files when building.

[VRguy]

Can also be remedied by what's sometimes called a combined server which is
a server linked with the client.

On Fri, Apr 1, 2016, 4:31 PM Chase Cobb [email protected] wrote:

Because of the nature of the OSVR server client applications on Android
require internet permissions.

If users don't explicitly enable internet permissions their applications
will silently fail. This can be remedied by creating a minimal manifest.xml
with the correct uses-permission tag in Assets->Plugins->Android. Unity
will automatically merge the manifest files when building.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#148

[chase-cobb]

That is definitely a solution, with it's own set of pros/cons. The manifest is a simple change that will 100% fix the issue with the normal server model. This also has no negative impact on a combined server approach.

One of the larger concerns with forcing the server to be bundled would be developer overhead. When new features roll into the server developers would be forced to recompile.

This server as a service approach is more consistent with our existing architectural direction.

[JeroMiya]

Many application sandbox environments, particularly on mobile, force us to make some concessions, however the OSVR architecture still allows for a good deal of flexibility. Our approach for mobile devices (or any sandboxed app model) will be a hybrid one. On one hand, the server auto-start API will launch a server thread in the same process with a set of default plugins. Typically, these plugins will be based on operating system level abstractions (for example, the Android sensor APIs), and thus will be suitably universal across devices, and will be relatively stable.

On the other hand, OSVR uses a distributed architecture, and allows you to connect to devices on external servers via the external devices configuration section. Or, even to connect to a server running on the device. Where permitted by the mobile OS, the server configuration should be shared among all apps on that OS. This allows a great deal of flexibility - for example, it would allow mobile apps to take advantage of hand tracking devices connected to a PC on a local network, even when that device has no native support for the mobile OS.

[chase-cobb]

Is there a JNI interface for the server, or does the client always communicate with the server via localhost/network protocol?

We can follow-up offline with architectural discussion if needed.