Proximity sensor on the Gear


I am wondering what exactly is happening when the proximity sensor detects that the helmet is worn or not in terms of an Unreal application. Is the oculus service just turning of the screen while the application keeps running in the background? That seems to be the case, because if I use the touch panel and then put on the helmet I can see the results of the input I entered while not wearing the helmet. But I am not sure if it is just the android inputs that are still coming trough but the application or service entered some kind of different state (like a pause or a hibernation), or if it is the whole application running and the screen is just off.

On the other hand, I wish to confirm that if there is any kind of pause or state changing in the application, we can detect and control this state, ej: go to a pause menu if you take of the helmet and disable touch events. Or if we can detect if the screen is off. Any way of detecting if the helmet is actually being used and make decisions based on that.

I thing it would be ideal if we could have access to the information of the proximity sensor, either directly as if it was one input more, or trough a state or function that ran automatically when the helmet was off (or the screen was off), even if we cannot see the sensor explicitly from within Unreal. If it is not currently possible, I would kindly ask to make a feature request, because I can think of many use cases where this would be extremely useful.

Does anyone have more information on this subject? Thank you very much.

I made further tests and I think I understand better what is going on:

First off, as soon as the sensor turns the screen off android inputs stop being received, so the touch panel becomes unresponsive. The unexpected behavior that I was seeing (the touch panel still working) was actually not happening, it was a mistake on my implementation that I misinterpreted.

Second, after you take off the helmet the application will keep running with the screen off for exactly ten seconds, after which it will pause. You can test this by setting a timer to print each seconds the minutes and seconds of the now function. Make note of the time and take the helmet off. You will see that after you put on the helmet again, the application kept printing the time for ten seconds after the moment you took off the helmet, and after that it stopped. There is a gap until you put it on again and the counting resumes.

I guess this is designed so that if you accidentally take your helmet off or you need to check something quick in the real world, you can put on the helmet again without breaking the flow of the action. If you took off the helmet for more than ten seconds, we can asume that you will be gone for long and the application should wait for you.

I dont know if this behavior is defined by the oculus service and it is applied to all apps without possibility to control it, or if it is implemented by unreal. I also don’t know if for unreal the game is paused (I doubt it) or the whole application just gets frozen by the service.

While I approve of this behavior, it would be interesting to be able to control the extension of time after which the game is paused, in case you want to pause after a shorter period for a fast paced game, for example. On the other hand, I don’t see this as an important issue and I am happy with it working the way it is.

As to detecting whether the helmet is not being worn, without being able to access the proximity sensor data (not possible as far as I know?), I am doing it by getting a timestamp each second, and then checking if the new timestamp is more than ten seconds away than the last. It works well enough for my purposes. In this case, I am trying to detect new users of an art installation, so I will reinitialize de app when this happens.

I hope this information is useful to somebody.