General

Out of Memory in GLSurfaceView on resume

The Symptom

After publishing WordMix with the OpenGL accelerated 2D game view (using GLSurfaceView), I received weird crash reports from some devices, mostly out of memory from within the GL context:

android.opengl.GLException: out of memory
 at android.opengl.GLErrorWrapper.checkError(GLErrorWrapper.java:62)
 at android.opengl.GLErrorWrapper.glGenTextures(GLErrorWrapper.java:350)
 at [...]

From the very limited information the Google Play Developer Console gives me about crash reports, I assumed it only affects devices running Android version 3. Modifying the code only caused the out of memory exception to be thrown at random other places, even at GL10.glClear(…)!

I also found out, the crash only happens when the user finishes a subactivity that would leave to the activity containing the GLSurfaceView. Users were complaining about the crash happening before starting a second game, which puzzled me, because all my rendering code seemed to be working fine on all devices running Android 4. Everything worked fine without the GLSurfaceView as well.

Looking that the source code for GLSurfaceView, nothing interesting was changed between Android 3.2 to Android 4, so the GLSurfaceView was hardly to blame, but more the hardware, drivers or specific OpenGL implementation.

The problem

The actual problem was very hard to track down and took me several hours and was particularly hard because I did not have an Android 3 tablet for debugging:

Up to Android 2.3, views were drawn in software and later composited using the hardware. Android 3 introduced an alternative hardware accelerated drawing engine for everything that uses Canvas classes. This alternative render path is disabled by default in Android 3 and supposedly enabled by default in Android 4 (previous blog post).

When I found out, that the Samsung Galaxy S2 does not enable hardware acceleration by default, I did set

<application android:hardwareAccelerated="true" ...>

in the AndroidManifest.xml for all activities that should support hardware acceleration. Using hardware acceleration for the activity with the anyway hardware accelerated GLSurfaceView did not make much of a difference. But accelerating the results or preferences activity, for example, gave a nice performance boost on my SGS2.

It turns out that the crash happens in Android, when an activity, that contains a GLSurfaceView, is paused for a fullscreen activity, that is hardware accelerated. When that hardware accelerated activity is finished, the underlying GLSurfaceView is screwed up, throwing out of memory exceptions, even though the GL context is completely reinitialized correctly.

The solution

Yes, I should have tested more the effects of hardwareAccelerated=”true”.

Leaving that attribute entirely unset is recommended for Android 3, especially when you use a GLSurfaceView, and should not hurt Android 4 devices as well. Setting a reasonable default value is then up to the manufacturers.

Summary

  • If you use a GLSurfaceView in an activity
  • and suspend that activity by starting another fullscreen activity
  • and that activity is hardwareAccelerated by setting so in the AndroidManifest.xml
  • and you target Android 3 devices
  • expect weird behaviour like out-of-memory exceptions

Welcome to fragmentation. Just let hardwareAccelerated be unset.