Cardboard Sample has stopped on start

[googlevr]

Cardboard Sample has stopped on start

[MoxorTheOne]

You're not guiving any info to help you.
Were is the stack trace? witch device, OS version.
does the https://play.google.com/store/apps/details?id=com.google.samples.apps.cardboarddemo&hl=en
works, did you modify somethig?

[redpotatojae]

Sorry, I was not specific enough.
I have also tried to get the demo app from Google Play and it ran fine on my phone (https://play.google.com/store/apps/details?id=com.google.samples.apps.cardboarddemo&hl=en).
I got the source code and imported into eclipse and I tried to run the sample code on my phone.
I did not modify anything except adding a Source "MainActivity/java" and adding a libraries "cardboard.jar"

fyi, My device is Galaxy s3 4.4.2 running.

[n1cholson]

The sample treasurehunt app is exiting for me, too. The error I see in the debugger is: "Surface size 1280x670 does not match the expected screen size of 1280x720. Rendering is disabled. The tag for this message is "CardboardView". The device is a Note II and it has a 1280x720 screen.

I don't see that error message in the treasurehunt source so I expect it's being generated by the cardboard library.

By the way, most of the demo apps (tour guide, youtube) in the Cardboard App work fine but the Windy Day demo doesn't crashes.

Anyone know what's going wrong?

[n1cholson]

I've traced the problem to a function in cardboard.jar's CardboardView.java file.
It appears that there are some inconsistencies when checking screen width and height as discussed here: http://stackoverflow.com/questions/10991194/android-displaymetrics-returns-incorrect-screen-size-in-pixels-on-ics

I'm considering some workarounds. One possible approach is to override the .jar file's function. Not certain how to do that in java but I gather that it's possible. Another approach would be to rebuild the .jar with a fix that gets around the screen height bug. Another work around would be to just move all the cardboard .jar code into the app, but this requires a fair amount of editing.

Here's the source. Line 586.1021 is where the problem occurs.
/* 580: / public void onSurfaceChanged(GL10 gl, int width, int height)
/ 581: / {
/ 582:1015 / if (this.mShuttingDown) {
/ 583:1016 / return;
/ 584: / }
/ 585:1020 / ScreenParams screen = this.mHmd.getScreen();
/ 586:1021 / if ((width != screen.getWidth()) || (height != screen.getHeight()))
/ 587: / {
/ 588:1022 / if (!this.mInvalidSurfaceSize)
/ 589: / {
/ 590:1023 / GLES20.glClear(16384);
/ 591:1024 / Log.w("CardboardView", "Surface size " + width + "x" + height + " does not match the expected screen size " + screen.getWidth() + "x" + screen.getHeight() + ". Rendering is disabled.");
/ 592: / }
/ 593:1030 / this.mInvalidSurfaceSize = true;
/ 594: / }
/ 595: / else
/ 596: / {
/ 597:1032 / this.mInvalidSurfaceSize = false;
/ 598: / }
/ 599:1037 / this.mRenderer.onSurfaceChanged(width, height);
/ 600: / }
/ 601: */

[edwardthefma]

Hopefully this will get fixed soon

[n1cholson]

I've managed to build my own version of cardboard.jar and patched it to ignore the error. Still having other OpenGL draw problems but now will be able to debug. I'll share the fix when it's working.

[n1cholson]

The fix for the first error is described here:
https://developer.android.com/training/system-ui/status.html
and requires a simple change to the manifest. It disables the status bar when in full screen mode.

There is still another part of the sample app that is causing a GL error of 1280 which translates to a bad enum value. This occurs between the first and second draw frames.

[kofiav]

Has anyone else been able to come up with a workaround for this issue? It is very frustrating. Is this a legitimate issue affecting all Android devices or is it one that can be avoided by only using certain Android devices?

[kofiav]

@n1cholson

I know you commented over a month ago, but were you able to find a complete fix?

[n1cholson]

@kofiav
I've stopped working on it for now due to other priorities. It appears that there are only a couple of errors in cardboard which I managed to fix but I was having some difficulty reassembling cardboard.jar such that it would properly expose the sensor components.

I'm more than a little concerned that the authors are noticeably absent from the forum and don't seem to be interested in providing any support. Perhaps this was just a demo for Google I/O and that they've no intention of supporting it further. If so, they should really let everyone know.

Looking at what's going on in this emerging market, it looks like the library that developers will settle on will be produced by Samsung or Oculus Rift. I'm particularly interested in the possibilities of the Samsung Note 4 and the Gear VR headset.

It's clear from working with cardboard that a 1-bit button as an input device is woefully inadequate for navigating 3D spaces. Schemes that involve looking at your feet to move forward aren't the answer. I experimented with hooking up a bluetooth game controller, and that feels like a good solution.

If I get time I make work on the cardboard.jar a little bit more but it may be wasted effort if the authors have abandoned it.

[kofiav]

@n1cholson

Thank you for responding. Unfortunately I have to use Cardboard for a project so it is critical that I identify and fix any issues present. I too am concerned that the authors are not providing support and aren't being very responsive. The idea for Cardboard was that it would be a black-box that would allow developers to defer all the extra work required to render a stereoscopic projection to the library. If we have to take time to investigate the library itself, then the project has already failed to meet one of its goals. What a bummer.

Navigating a 3D environment with a magnet only is indeed limiting. It looks to me like it would be possible to move along the z-axis by utilizing the smartphone's sensors but I do not know how feasible this is. In any case, I suppose I have no choice but to construct a functional copy of the jar before I can move on. Thank you for notifying us of the screen size issue. I will update you and anyone else on this thread if I make any progress.

[Shirokuroneko]

If you are extending a CardboardActivity it should be setting fullscreen mode for you on creation. What device and API level are you using?

[kofiav]

Device: Nexus 5
API Level: (target: 18) (min: 18)

The app starts on fullscreen mode with no issues, but no rendering occurs. The reason, as n1cholson so eloquently stated is:

"Surface size ????x1080 does not match the expected screen size of 1920x1080. Rendering is disabled"

I should say that the Cardboard Sample Code runs fine for me. It's only when I tried using the Google Cardboard library for my own personal and quite separate project that I encountered this issue.

[kchodorow]

A hacky way around this that worked for me:

// Get the CardboardView.
CardboardView view = (CardboardView) findViewById(R.id.cardboard_view);
view.setRenderer(this);
setCardboardView(view);

// Manually set the screen size.
Display display = getWindowManager().getDefaultDisplay();
ScreenParams params = new ScreenParams(display);
params.setWidth(/* desired width */);
params.setHeight(/* desired height */);
view.updateScreenParams(params);

[3spin-dev]

We had the same issue with the Galaxy S2. The Nexus 5 worked fine out of the box.

[flankechen]

@kchodorow
but what width and hight to set? in
params.setWidth(/* desired width /);
params.setHeight(/ desired height */);

I have a device with resolution 1980*1080 with no on screen navigation bar. and it render two strange "small" view on the screen.

10-28 16:14:55.012: D/OpenGLRenderer(9162): Enabling debug mode 0
10-28 16:14:55.042: I/MainActivity(9162): onSurfaceCreated
10-28 16:14:55.052: W/CardboardView(9162): Surface size 1920x1005 does not match the expected screen size 1920x1080. Rendering is disabled.
10-28 16:14:55.052: I/MainActivity(9162): onSurfaceChanged
10-28 16:14:55.052: I/MainActivity(9162): surfaceWidht960
10-28 16:14:55.052: I/MainActivity(9162): surfaceHeight1005
10-28 16:14:55.112: V/RenderScript(9162): Application requested CPU execution
10-28 16:14:55.112: V/RenderScript(9162): 0x7733da88 Launching thread(s), CPUs 4
10-28 16:14:55.132: E/ffi_jank(9162): timespan = 64.74047
10-28 16:14:55.182: E/ffi_jank(9162): timespan = 32.909218
10-28 16:14:55.212: I/MainActivity(9162): onSurfaceChanged
10-28 16:14:55.212: I/MainActivity(9162): surfaceWidht960
10-28 16:14:55.212: I/MainActivity(9162): surfaceHeight1080

that's strange, height change in these two renderer onsufaceChanged()

[KopierKatze]

This issue bugs me as well. On my Nexus 4, the resolution should be 1280x768. Logcat reports 1196x718. The app starts normally and works, but the Views for the left and right eye are very small.
I tried manually setting the size of the cardboardView in onCreate and i tempered with the topMargin in CardboardOverlayEyeView, since it is 256. So far, i haven't seen any changes in the Layout.
kchodorow's solution didn't work for me.
Does anyone have another solution?

[polymesh]

I am getting the same "surface...does not match the screen size" error on a TF201 (Transformer Prime) which is 1280x800 but for some reason it is only able to get 1280x752. I don't expect people to use a cardboard app on their tablet, but I do expect it to work on a variety of devices. This is concerning...

Works fine for my Nexus4.

[polymesh]

Now that I think about it, the TF201 has a bar at the bottom (software buttons) which cannot be hidden and annoyingly takes up screen real estate. So it seems like whatever CardboardActivity is doing to get the width and height of the device is not getting the USABLE width and height. I remember I had to account for this in a previous app. Looking at my code, I got my dimensions from EGL, I think there is something equivalent that can be called on the view.

I can now verify that I get rendering happening after doing this (discovered by kchodorow):

// Manually set the screen size.
Display display = getWindowManager().getDefaultDisplay();
ScreenParams params = new ScreenParams(display);
params.setWidth(/* desired USABLE width /);
params.setHeight(/ desired USABLE height */);
view.updateScreenParams(params);

note the "USABLE" addition above. I misunderstood the purpose of calling updateScreenParams(), it is not to give the actual dimensions of your screen, but the usable dimensions so it matches the drawing surface determined by the cardboard API (it should be getting the usable width/height from EGL internally me thinks).

Now having said this, my eyes currently render side by side, don't take up full real estate, and the contents are rendered sideways... but those are different problems. For the orientation problem, here's something else this API should be doing (accounting for different device accelerometer orientations):
http://stackoverflow.com/questions/5877780/orientation-from-android-accelerometer

[jitsuCM]

Follow these to make sure everything goes fine:

1. Download and install cardboard app from the playstore. It creates some data that the lib would want to read later.
2. Make sure you have the following two options in your manifest:
   <activity
   [...]
   android:screenOrientation="landscape"
   android:theme="@style/FullscreenTheme" >

Otherwise it will nag you about the mismatched screen size.

[nathanmartz]

Closing super old thread.