Crash on iOS after splash with GoogleVR plugin enabled

This is actually a copy of UE-42339 bug, which is marked as a duplicate of UE-41244.

But it seems, that UE-41244 is solved, because iOS applications don’t crash anymore (with 4.16.2) when you tap “Switch” button, or toggling between VR and Fullscreen mode (stereo on/off), and it is cool! (Actually it sometines crash, but maybe when I add additional plist data about Camera Use, it stops crashing, anyway, my application don’t crash after Switch button and toggling VR mode)

BUT! UE-42339 is a different and actual problem! Why it is marked as duplicated?

If you create shipping build for iOS with GoogleVR Plugin enabled, it will crash after spash. I tried different versions of engine: 4.15.3, 4.16.1, 4.16.2, 4.15-googlevr (source build), 4.16-googlevr (source build) and everytime the result is the same.

Building on Windows with remote Mac, directly on Mac, code project, blueprint-only project - everytime the same result.

I attach my runtime and crash logs from iOS shipping build, which crashes, and runtime log from development build, which runs okay.

To reproduce the issue, you must follow theese steps:

  1. Create a new project

  2. Enable Google VR plugin

  3. Restart project

  4. Build project

  5. Set build configuration to Shipping

  6. Package for iOS

  7. Install on to device (i used iPhone5S and iPhone6+)

  8. Open app on device

  9. Notice that the app closes immediately after slash screen appears

Expected: The app would open and enter in to VR mode

Result: App closes as soon as the default splash screen shows up

I attach runtime and crash logs from Shipping-builded application, which crashes, and one runtime log from Development-builded application, wich runs okay.

I found, that the error appears right after GoogleVR initialization:

shippingruntimelog.txt, [186 string]: Jul  6 10:18:55 iPhone-Daniil SpringBoard(KeyboardArbiter)[212] <Error>: HW kbd: Failed to set (null) as keyboard focus

and may cause a crash. Hope it will help in further investigation.

If somebody knows a workaround, I’ll appreciate for telling about it to me.

Hello Dan,

I’ve reproduced the issue that was originally reported and I also believe that it was mistakenly marked as a duplicate so I’m speaking with the person who did that to get it sorted out. I’ll let you know when I have more information.

Any progress with this issue?

I have someone looking into it but we are a little behind at the moment with the 4.17 previews and release.

Hello mister_dan,

I forgot to follow up here, but the bug report has been reopened. It is currently marked to be fixed in 4.17.1 but that is subject to change. Please feel free to follow the bug’s progress on the public bug tracker.

Hello, just installed 4.19 preview 3 and still this issue persist. We really need help on this respect, we found that this bug existed as we publish our iOS Google VR app to testflight. This is a showstopper as we are out of time, budget and patience from our client.
If this was a bug at the beginning of the developer cycle we could had circumvent it, but this bug it’s a suckerpunch on the finnal step.
Can we have at least some sort of workaround or eta so we could buy some time with our client?

Hello Darth, unfortunately I cannot provide immediate assistance but I can confirm that we have updated the bug report to reflect that this occurs in the 4.19 previews and that the priority of the issue is higher than most bugs.

I’m going to message the person who is assigned to this issue and see if they know of a workaround, as the reason for the issue seems to be fairly straight forward.

It’s possible that the workaround provided for another issue, could be helpful. Please try editing your .plist to include this:

<key>NSCameraUsageDescription</key>
<string>Used to scan QR code for Cardboard</string>

Ok, am testing that right now.

Should i replace that line for every NSCameraUsageDescription key in the plist? because i have that key like eight times.
link text

Thank you so much mister_dan. Do you know how to set up my app so it won’t be turned down because my development app runs around 350mb? I read your comment about changing with the iOS version.

Am going to check your solution to the white line, i managed to erase it from android hacking a lil bit some xml on the android vr plugin, as a test because it doesn’t break on android. But i haven’t be able to do the same on the iOS side.

Thanks Matthew. Let me know if we can be of any assistance.

The workaround now is to make a development build, than re-sign it with production certificate using IPP tool, with this trick you can upload the app, but with bigger size. I made my game this way, and now I’m just waiting for a fix. DevBuild runs without crashes.

There is an another issue with white line in the center of the screen don’t go away when you switch to not-VR mode. The workaround is to comment some lines in plugin - if someone needs any details - check my last answer here: GoogleVR layout visible if stereo is off on iOS - XR Development - Unreal Engine Forums

Nope, every attempt of fudging around with anything inside the ipa makes it unable to install on the iPhone.
If i change the ipa to .rar take out the .plist file, make a copy of it, edit and replace it via rar inside the ipa damage it.

If i replace the original Plist inside the ipa it works again.

The iphone knows somehow that the Plist was tinkered.

I used notepad, wordpat and a “plist editor” from the web. Even used Xcode to change the Plist and the Iphone wont install the app with the custom Plist.

Is there a way to do this?

Ok, you need to re-sign the ipa. Now it installs ok with the changed Plist but sadly it fails crashing after splash.
But know i know how to hack an ipa file. Am going to try inject it with the plist from a development build and try to customise a viable plist.
I have an ipa file with the Google VR plugin unchecked so i can make comparisons too.

I will soon post my findings on this.

Ok here are the comparisons between plist files.
Shipping Vs Develop both with Google VR turned on.

Shipping Vs Shipping one GVR on and the other off.

I see no big differences.!

Hello, is there any news around this issue? we tested editing the info.Plist and that didn’t work. We have a develop versión disguised as a shipping one working on testflight but we are not near the size to be approved for App Store. Let us know if there’s anything else we can help you with to resolve this.

Thanks.

Any new workarounds or ETA on a fix? This seems like a big issue

Hello, I apologize for the silence on this thread. While checking up on this, I checked the private comments on the bug report that I linked earlier in this thread and one of the comments mentioned the following:

“this crash is because the OS is asserting that you need to prompt the user for permissions before trying to use the camera for cardboard.”

Can you ensure that you are prompting for the app to request for permission to use the camera? According to them, this doesn’t exactly need a fix, but the documentation surrounding this needs to be updated to reflect this being the reason for the failure.

We are past that Matthew J, with the little information that you have provided us about that theory i made test and sent you the results. You did no follow up, and two months later you come again with the same Plist stuff.
Could you, at least, be more clearer about what to do? because our apps still crash on splash screen.

Hope we are not taking too much of your time.

I’ll continue looking into this to get more specifics, but I’ll make it clear that I do not have any sway in how this gets fixed or whether it gets fixed. From the information I have been given, there is no bug here and the permissions need to be requested from the user yourself to avoid this crash. Currently the bug only seems to still be open for the documentation team to add the information I provided to the documentation.

I’m going to try to ask Nick W, the person who left the note of “This is because the app needs permissions for the camera in the plist when deploying on iOS.” on the Public Bug Tracker, next week. I’ll let you know what I find out.