[GearVR] Crash on Input (except when Oculus GearVR Home is uninstalled)

@imperativity, sorry I missed your message from a couple weeks ago asking for feedback. I need to check to make sure this thing sends me emails.

The 10-2 app update didn't fix this issue. Please light a fire under whoever works on this.

Your team should be able to do the following to reproduce this error and troubleshoot it with their own code: 

Set up the GearVR quick start project
https://docs.unrealengine.com/en-us/Platforms/GearVR/QuickStart

Important: Give the project the same bundle ID as a published app that is in the library so that it overwrites that app.

The error doesn't seem to happen otherwise.

Run the game. For me it crashes with input both from the controller and the headset.

I did this with the Oculus UE4.18.3 build from source from github. I imagine that other UE4 builds would do the same thing based on this thread but haven't had time to test that theory.

As for the info you requested previously, the output to logcat before and after the section I provided contains plenty of log output from UE4 but none of it is related to the error, which doesn't appear to be triggered by a UE4 command. The log output I previously posted abruptly interrupts whatever else is going on and nothing before or after that gives me any clue as to what piece of UE4 code was running immediately before the crash.Since libUE4.so appears on step up the stack trace, it is somewhere but I'm not sure if I have the tools to make breakpoints or even understand what is going on at that machine code level. I am guessing that it is part of the Android message loop though that is in Engine/Runtime/Launch/Private/Android/AndroidEventManager.cpp. 

Thank you

We have verified again that we can reproduce the crash with a UE4 app using 1.17 release driver and that installing 1.18 release driver without any other changes makes the crash go away. We can then set debug.oculus.enablebreakpad 1 and the crash occurs with 1.18 driver. 

The fix we made to 1.18 involves changing the default behavior when the "debug.oculus.enablebreakpad" prop doesn't exist at all.

Prior to 1.18, if this system property did not exist we would default to treating it as if it were true, which would enable our crash handler.

In 1.18, if this system property doesn't exist we default to treating it as if it were false, which fully disables our crash handler. This is a relatively simple change and there is no other way for the crash handler to be initialized.

However, this means that once you "adb setprop debug.oculus.enablebreakpad 0", you've created that property and you cannot test the 1.18 default behavior until the phone reboots. If you "adb setprop debug.oculusenablebreakpad <any non-zero value>", crash reporting will be enabled again. Make sure you reboot the device before trying again to confirm if the 1.18 fix is working.

If you're seeing this crash, please try to verify using the following steps:

1) make sure that the debug.oculus.enablebreakpad does not exist at all on your device. Use the following command to do so:

adb shell "getprop | grep debug.oculus.enablebreakpad"

You should see no output. If you see:

[debug.oculus.enablebreakpad]: [1]

Or some other value instead if [1], then reboot the device and check again.

2) Verify that your device really has 1.18 installed. Updates are a tricky business -- it's very difficult for us to ensure every device gets updated in a timely manner without issuing a roadblock. It's entirely possible that your device has updated some components and not others.

To verify:
adb logcat -c

Run your application.

adb logcat -v threadtime -d > myapp.log

Load that myapp.log and search for "VRAPI VERSION". It should look similar to this:

10-09 16:46:33.057 18946 18962 I VrApi   : VRAPI VERSION = 1.1.18.0-0-0 <date> <time>  RELEASE

You can additionally go to Settings -> Apps -> Oculus System Driver -> Storage and see the version number of the installed driver there, but verifying it in the log when your app loads leaves absolutely no question.

If you still see the crash, then something even more unexpected is happening which we're not reproducing in our tests, and getting a full log of the crash could be immensely useful.

@aussiburgerVR

You should be able to remove that. I'm actually surprised that works at all. How are you calling an adb shell command from your app?

Once you remove it I would definitely verify that 1.18 is still working for your app using the steps above.

I am starting to think there may be two issues here -- one related to input and one related to bundle ID, so if you can respond back that 1.18 is working for you even with the adb command removed, that will give us some confidence that the 1.18 patch did indeed fix the issue for some developers.