# How to know when Android OpenGL Context has been preserved?

I am implementing a pause menu for my game in Android.

If the activity pauses and then resumes, it loses the OpenGL context. However, if you use setPreserveEGLContextOnPause(true) it MAY preserve the context if the device supports it.

How can I check if the context has been preserved or not?

If you require specific behavior, your best option is to use a plain SurfaceView rather than a GLSurfaceView.

GLSurfaceView is just a SurfaceView subclass that handles threading and EGL context management. You can find multiple examples of GLES use with plain SurfaceViews in Grafika, including some handy classes for working with EGL.

When OpenGL ES was first introduced into Android, the device could only have one EGL context at a time. Not one per app, one per device. This is why GLSurfaceView is so aggressive about releasing the context. It's still a good idea to release the context and any associated resources when an app is kicked into the background, since you don't know how long it will be there, and it's good practice to play nice with other apps.

In any event, you can tell if your context was preserved by trying to use something in it. If the attempt succeeds, you can assume you've still got the same context.

There's some notes for older versions of Android in this question, though some of the answers are a bit dodgy.

• I tried to do it, just to resume the GLSurfaceView but it doesnt work, OpenGL variables got the same value but at the time to draw it doesnt draw anything – D4rWiNS May 6 '16 at 7:17
• Do you know if there is a way to force Android into using one context per device again? My app, extremely light on resources, still sees occasional GL_OUT_OF_MEMORY which must be caused by other apps competing for resources. – Bram Aug 15 '19 at 17:55
• Bear in mind that GLES has a limited number of error codes, and sometimes reports "out of memory" for situations other than running out of memory. See e.g. the answers to stackoverflow.com/q/6287545/294248 for some examples. Check for errors after every call to identify which specific operation is failing, then put that call under a microscope. – fadden Aug 15 '19 at 20:14