Cardboard apps crash on the Tango Tablet

[openforeveryone]

This app crashes after drawing ~20 frames on the Project Tango Development Kit Tablet NX-74751.
This crash seems to affect many apps based on this code.

I have recorded the log output here: https://gist.github.com/openforeveryone/d0eed34e05d97b4d2ca1#file-gistfile1-txt-L55

[smdol]

First, this message looks bad but is harmless:
D/HeadMountedDisplayManager(22547): Cardboard screen parameters file not found: java.io.FileNotFoundException: /storage/emulated/0/Cardboard/phone_params: open failed: ENOENT (No such file or directory)

The actual error occurred here:
F/art (22547): art/runtime/check_jni.cc:64] JNI DETECTED ERROR IN APPLICATION: java_object == null
F/art (22547): art/runtime/check_jni.cc:64] in call to GetObjectClass

There is some JNI code in the native layer that tries to get the display metrics (DPI, mainly). This error could mean that it does not have the correct application context or classloader.

[R1ck77]

Hi smdol, if it can be of any help, I'm pretty sure that the first message (the one related to the screen parameters file not found) is irrelevant: I get it on my devices all the time, and they work like a charm.

I think they are the byproduct of some kind of semi-hidden feature to configure the screen of the device along with the headset in the sdk, but it's not yet used or fully documented (I saw some hints about it in the APIs, though).

The second one, a segmentation fault is definitely the culprit. Weird it happens only on Tango boards (wild guess: some incomplete software implementation on the Os side? They are development devices after all...). Good luck with your issue (and cardboard or not, congratulations for your device. Quite some envy here :) ).

[openforeveryone]

Yes the first error, as I understand, is simply an exception thrown when trying to read the settings for the cardboard hardware and this happens on any device that has not scanned a cardboard barcode (or for which the file had been removed). This just causes cardboard SDK to use the default settings and carry on regardless.

The JNI error, which is clearly causing the crash, is indeed a little odd to only be happening on Tango. Will it be possible for you (once you to do the check that JNI requires and see if the object you have is null before calling GetObjectClass) to do something graceful here?

It is worth noting that the Tango Tablet does report a sensible DPI:

DisplayMetrics metrics = new DisplayMetrics();
getWindowManager().getDefaultDisplay().getMetrics(metrics);
 Log.i(TAG, "Screen Density: " + metrics.density);
 Log.i(TAG, "Screen Density DPI: " + metrics.densityDpi);

Prints:

Screen Density: 2.0
Screen Density DPI: 320

While I have enough experience working with JNI on Android to probably be able to fix this myself (or at least find a workaround) it is happening from within the binary blob libvrtoolkit.so within the SDK. So it looks like it will have to be fixed by yourself Smdol or someone else with access to the source code and preferably also to a Tango Tablet.

[smdol]

It definitely has to be fixed in house. At the very least, a few additional null-checks would be in order...

[R1ck77]

@openforeveryone nope. My device has the cardboard properly configured and the Cardboard screen parameter warning is still there in logcat.

Again, it's only a conjecture, but it might be searching for a file serialization of this

[smdol]

There are some JNI calls made way down in the native code layer of the SDK that need to reach back up into Java land. The code in question is doing the typical JNI sequence "get pointer to class Foo; ok, get pointer to method Bar; ok, call that method", and one of those "get pointer to..." calls is returning NULL for some reason. I know that the native layer of the SDK must have pointers to the application context and class loader given to it, or exactly that error will occur. (@R1ck77, yep, these JNI calls are trying to get profile data about the phone and viewer.) So the actual bug is not here, but earlier during initialization when these pointers should be getting passed to the native layer. Alternatively, there is some kind of context mismatch caused by mixing Tango and Cardboard at the Java level. Or I could be all wet and the problem is only vaguely related. I'll make sure some Java folks on the Cardboard team have seen this bug.

[openforeveryone]

I have just tested v0.6.0 with my Tango tablet and it would seem that this issue has now been resolved.