4

I updated our app to Google Play Services rev 17, this required changing our app's 3D activity from Activity to FragmentActivity. We also now call GoogleApiClient.connect() much earlier than we used to because google recommends calling GoogleApiClient.connect() from the activity's onStart().

This has caused a serious regression: now a fresh install crashes about 30% of the time on a Nexus 7 on launch. The crash logs NvRmChannelSubmit: NvError_IoctlFailed followed by endless other NvRmChannelSubmit errors which I believe just indicates a messed up opengl driver state.

This is a completely new bug, nothing changed in our app other than:

  • activity changed from Activity to android.support.v4.app.FragmentActivity
  • GPS init UI now triggers earlier because we call connect() from onStart()
  • updated to GPS rev 17 (which had a lot of changes, but hopefully nothing touching opengl!)

One theory I have is the GPS connect UI and/or the underlying change to FragmentActivity is affecting the window while the app is launching and interfering with opengl driver init. But I have no proof that is cause, and if that is the cause I have no idea how to fix it.

Has anyone else seen opengl driver issues related to either the GPS connect UI flow or FragmentActivity?

mwk
  • 1,959
  • 1
  • 14
  • 22

1 Answers1

4

Problem fixed.

I confirmed the opengl crash is caused by calling GoogleApiClient.connect() from our Activity's onStart() method while opengl is initializating: if I defer the call to connect() until after the first OpenGL frame is rendered the bug is fixed.

Conclusions:

  • Google's recommends calling connect() from Activity onStart(), but that is not safe for an opengl app. It crashes the opengl driver on a Nexus 7 running 4.3 if the connect() calls triggers other GPS UI flow e.g. for user account selection
  • Deferring the connect() call was a straight forward work-around for us, but be careful because if you still use Activity onStop() to call GoogleApiClient.disconnect() as we do, there is no longer a guarantee that connect() will have been called before disconnect(). I have not seen any problems with GPS internal state if this occurs, but Google's sample code maintains a fair bit of state related to error handling, that code may require changes to work.

I never did determine the exact root cause of the opengl crash. It could be that the older GPS connect method would also have caused the same crash if we had called it from onStart (our prior implementation called it later). It is also possible the crash is not directly related to GPS at all, but is just a general opengl driver vs. window manager problem when using FragmentActivity to overlay UI during opengl initialization.

mwk
  • 1,959
  • 1
  • 14
  • 22