5.6.2 Native GVR build won't work when built through Command Line

Unity Engine
1

I’ve got a project that supports GVR. Up until Unity’s native GVR integration we’ve had success automatically building the project for all platforms.

Building the project through default build commands the editor log leaves this as an output (last line specifically):

This is a follow up to Running 5.6.2 via Editor Command Line leaves out VR SDK's - Questions & Answers - Unity Discussions

I’ve had little luck finding anything to match the issue. I’m assuming it’s such an odd thing I’ve ran in to for it. We build our apps via command line on an automated build machine yet VR sdk’s aren’t attaching to the project via command line for this.

edit:
Some additional info -

2

What are you doing in your PerformAndroidBuild method?

As an example here is what I use internally and I have no issues:

using UnityEngine;
using System.Collections;
using UnityEditor;

public class BuildScript : MonoBehaviour {

    static void Android()
    {
        //PlayerSettings.VR.Google.daydreamOnly = true;

        BuildPipeline.BuildPlayer(new[] {"Assets/_SCENE.unity"}, "build_temp.apk", BuildTarget.Android,
            BuildOptions.AutoRunPlayer | BuildOptions.Development);
    }
}
3

We have a script that basically does that with scene/apk names assemblies based on Jenkins jobs. The only real difference is we use no BuildOptions.

I’ve just tried that code exact code (with different scene names) and I get the same issue. This project works perfectly fine built via the editor. Those errors I’ve quoted above still happen too (in the case of command line with your code).

Unity version is 5.6.2f1

4

What happens if you remove this

UnityEditorInternal.VR.VREditor.SetVREnabledOnTargetGroup(BuildTargetGroup.Android, true);
UnityEditorInternal.VR.VREditor.SetVREnabledDevicesOnTargetGroup(BuildTargetGroup.Android, new string[] { "Cardboard" });

and just manually add the device to the VR device list in PlayerSettings?

5

I’ve been testing without any of them today. Realised I wrote a seperate editor script to add the same things thinking it would work on that side. Looks like they were causing the issue for Android!

3153709--239781--Untitled.png

I think I’ve gone full circle here to the origin of this issue for us.

Basically all this started with the iOS builds. I tested various commands (such as the ones you’ve quoted above) to try get it to work. These are the calls made for the iOS build:

    static public void PerformIOSBuild()
    {
        MakePaths();
        //
        // Take the build number from the SVN revision number, and use it for the IOS build number
        PlayerSettings.iOS.buildNumber = System.Environment.GetEnvironmentVariable("SVN_REVISION");
        Debug.Log("IOS build version code is:" + PlayerSettings.iOS.buildNumber, null);

        BuildPipeline.BuildPlayer(m_scenes, m_finalPath, BuildTarget.iOS, BuildOptions.None);
    }

    static private void MakePaths()
    {
        // Generic parameters
        m_buildName = System.Environment.GetEnvironmentVariable("BUILD_NAME");  // Name of the final build file/package      
        m_jobName = System.Environment.GetEnvironmentVariable("JOB_NAME");      // Name of the job
        m_workspace = System.Environment.GetEnvironmentVariable("WORKSPACE");   // Workspace directory
        m_home = System.Environment.GetEnvironmentVariable("JENKINS_HOME");     // Jenkins home directory

        m_finalPath = m_workspace + "/" + m_jobName + "/";                      // Full path for the build, without the build name
        m_bundleID = System.Environment.GetEnvironmentVariable("BUNDLE_ID");            // Bundle ID, usually 'com.gaia.????'
        m_bundleVersion = System.Environment.GetEnvironmentVariable("BUNDLE_VERSION");  // Bundle version, usually '1.0.0'    

        //IOS Settings
        m_teamID = System.Environment.GetEnvironmentVariable("IOS_TEAM_ID");        // iOS Team ID      
        PlayerSettings.iOS.appleDeveloperTeamID = m_teamID;

        PlayerSettings.showUnitySplashScreen = false;
        PlayerSettings.productName = m_buildName;                   // Set Unity product name
        // PlayerSettings.bundleIdentifier = m_bundleID;               // Set Unity bundle identifier
        PlayerSettings.bundleVersion = m_bundleVersion;             // Set Unity bundle version

        PlayerSettings.SetApplicationIdentifier(BuildTargetGroup.iOS, m_bundleID);
        PlayerSettings.SetApplicationIdentifier(BuildTargetGroup.Standalone, m_bundleID);
        PlayerSettings.SetApplicationIdentifier(BuildTargetGroup.Android, m_bundleID);


        Debug.Log("Product name is :" + PlayerSettings.productName);
        Debug.Log("Bundle ID is :" + PlayerSettings.applicationIdentifier);
        Debug.Log("Bundle Version is :" + PlayerSettings.bundleVersion);
    }

I’ve double checked to make sure PlayerSettings do persist on project loadup. Cardboard as the device SDK for VR is there for iOS/Android.

6

What’s the problem you are having with the iOS builds? I don’t see anything in those scripts for setting VR state. Is that done explicitly through the UI for iOS?

7

The app doesn’t load with a stereoscopic view. VR is flagged through player settings.
3154045--239821--vr.png

If built in editor, I get the scene as intended. Stereoscopic view from Cardboard SDK kicks in.

8

So, we are talking specifically iOS here, right? If so, how are you building the Xcode workspace that Unity generates?

9

Yes - seems like Android was fine.

We use fastlane, the specific job for VR we have listed is:

desc "Create a VR build"
lane :deployBuildVR do
  cert({ development: true })
  sigh({ development: true, force: true })
  gym ({
      include_bitcode: false,
      export_method: "development",
      xcargs: "ENABLE_BITCODE=FALSE OTHER_LDFLAGS='-framework Security -framework GLKit -ObjC'",
      output_directory: "./xcode.build",
   })
  end
10

I have no idea about fastlane but here is a test that will tell you if it is fastlane: Open the .xcworkspace file Unit produced and build the app there. If success then deploys and make sure that VR is working. If that works then the problem is most likely your build system or its configuration.

11

Sorry about slow replies - testing out a few things for it. The .xcworkspace file is not successful when built by itself after running through command line.

If I build via the editor then build the .xcworkspace, it’s fine.

I can see that there are several things that aren’t linked/created in the Unity output for command line build. A lot of linker stuff isn’t in the version built via command line.

12

The .xcworkspace file is not successful when built by itself after running through command line.
Do you that mean that after running a command line build, opening the workspace in Xcode and building in Xcode fails?

I can see that there are several things that aren’t linked/created in the Unity output for command line build. A lot of linker stuff isn’t in the version built via command line.

This would seem to imply that the issue may be with your build system.

13

XCode doesn’t fail - the build just doesn’t have GVR functionality.

Apologies for the confusing route around this, I’ve been posting stuff and retrying everything.

I might have worked it out. We only commit Assets+ProjectSettings to SVN. This then gets intercepted by our build machine, checks it out/runs command line build etc.

I’ve just checked out the project on the Mac. Opened it in editor, closed it (so Library folder has been assembled). Built via command line - works.
If I check the project out and build it via command line, without opening in editor then it doesn’t work (GVR doesn’t link/isn’t present in build).

14

Yeah, I think the Library folder is important for building. It’s not important for transferring projects around but I think we do store build/project settings in there that will effect build. What you might want to try is opening the project using command line unity and then killing unity prior to running the rest of the build?

15

Didn’t expect the assembly of the Library to differ like that between command line and editor. At least we have a solution! It’s only been our VR projects that have been affected.

Thanks for the help!