Develop Reference

Should the renderingThread of a SurfaceView have the same life-cycle as the view or the activity?

When creating a SurfaceView it's normal to also create a separate thread to draw onto the surface. Is it better programming practice to have the thread be created and destroyed at the same time the activity is, or at the same time the surface is?
What are some of the advantages/pitfalls of either way?

The Activity and the View are created at essentially the same time. The Surface is created later, and that's what the SufaceHolder callbacks are for.
You can't render on the Surface before it exists or after it's destroyed, so there's no point in starting your rendering thread before then or leaving it running after. The tricky part is that the callbacks happen on the main UI thread (since that's where you set it up), so the surfaceDestroyed() callback could be called while your render thread is doing work.
EDIT:
Some notes about the SurfaceView / Activity lifecycle are included below. These are now part of the official Android documentation; see Appendix B in the System-Level Graphics doc. The original post is available below for historical purposes.
You can see examples of both approaches in Grafika. Approach #1 (create/destroy thread in onResume/onPause) can be seen in TextureFromCameraActivity, approach #2 (create/destroy thread in surfaceCreated/surfaceDestroyed) can be seen in HardwareScalerActivity and RecordFBOActivity.
A few thoughts about app life cycle and SurfaceView.
There are two somewhat independent things going on:
Application onCreate / onResume / onPause
Surface created / changed / destroyed
When the Activity starts, you get callbacks in this order:
onCreate
onResume
surfaceCreated
surfaceChanged
If you hit "back", you get:
onPause
surfaceDestroyed (called just before the Surface goes away)
If you rotate the screen, the Activity is torn down and recreated, so you get
the full cycle. (You can tell it's a "quick" restart by checking isFinishing().) It might be possible to start / stop an activity so quickly that surfaceCreated() might happen after onPause(), but I'm not sure about that.
If you tap the power button to blank the screen, however, you only get onPause() --
no surfaceDestroyed(). The Surface remains alive, and rendering can continue (you
even keep getting Choreographer events if you continue to request them). If you have
a lock screen that forces a specific orientation your Activity can get kicked, but
if not you can come out of screen-blank with the same Surface you had before.
This raises a fundamental question when using a separate renderer thread with
SurfaceView: should the lifespan of the thread be tied to the Surface or to the
Activity? The answer is: it depends on what you want to have happen when the screen
goes blank. There are two basic approaches: (1) start/stop the thread on Activity
start/stop; (2) start/stop the thread on Surface create/destroy.
#1 interacts well with the app lifecycle. We start the renderer thread in onResume() and
stop it in onPause(). It gets a bit awkward when creating and configuring the thread
because sometimes the Surface will already exist and sometimes it won't. We can't simply
forward the Surface callbacks to the thread, because they won't fire again if the
Surface already exists. So we need to query or cache the Surface state, and forward it
to the renderer thread. Note we have to be a little careful here passing objects between
threads -- best to pass the Surface or SurfaceHolder through a Handler message, rather
than just stuffing it into the thread, to avoid issues on multi-core systems (cf.
Android SMP Primer).
#2 has a certain appeal because the Surface and the renderer are logically intertwined.
We start the thread after the Surface has been created, which avoids the inter-thread
communication concerns. Surface created / changed messages are simply forwarded. We
need to make sure rendering stops when the screen goes blank, and resumes when it
un-blanks; this could be a simple matter of telling Choreographer to stop invoking the
frame draw callback. Our onResume() will need to resume the callbacks if and only if
the renderer thread is running. It may not be so trivial though -- if we animate based
on elapsed time between frames, we could have a very large gap when the next event
arrives, so an explicit pause/resume message may be desirable.
The above is primarily concerned with how the renderer thread is configured and whether
it's executing. A related concern is extracting state from the thread when the
Activity is killed (in onPause() or onSaveInstanceState()). Approach #1 will work
best for that, because once the renderer thread has been joined its state can be
accessed without synchronization primitives.

GLSurfaceView renderer, how to force surface re-creation?

I have a GLSurfaceView renderer and method onSurfaceCreated is called only once (basically only when activity is created or re-created).
I need to test behavior when EGL context is lost and surface is recreated during normal activity life cycle, however I am unable to put app into such situation no matter what I do.
Is there anything that I can do to simulate situation in which is onSurfaceCreated called again? How to make my app lose EGL context?
Edit: After a few days I noticed that the problem was gone and the app started to behave properly as said in specs:
public abstract void onSurfaceCreated (GL10 gl, EGLConfig config)
Called when the surface is created or recreated.
Called when the rendering thread starts and whenever the EGL context is lost.
The EGL context will typically be lost when the Android device awakes
after going to sleep
Before that, every time the device went to sleep, the activity was destroyed and recreated on awake which was preventing me to test if the code in OnSurfaceCreated worked well.
Now it behaves much better when sleep/awake occurs - it usually does not destroy the activity and just calls OnSurfaceCreated method which is the situation I was aiming for.

I'm not sure but the only thing that i can think of is to switch the GLSUrfaceView with a new one using the same GLSurfaceView.Renderer.
That should create a new EGL context and call the onSurfaceCreated() a second time.

According to the documentation, GLSurfaceView.Renderer.onSurfaceCreated is called when the surface is created or recreated.
Called when the rendering thread starts and whenever the EGL context is lost. The EGL context will typically be lost when the Android device awakes after going to sleep.
Have you tried locking your device's screen and unlocking it?

Maybe you can look at onScreenStateChanged method but it's available for API 16 or higher. If you mean "pausing and resuming the activity" by "normal activity life ciycle" maybe you can use onPause or onResume to track this.
What exactly do you want to do with onSurfaceCreated() ? You can force the rendering by requestRender() method of SurfaceView and do the necessary calculations inside onDrawFrame() of GLSurfaceView.Renderer

If your view is in a fragment, you can detach and re-attach the fragment.

Android: When is OpenGL context destroyed?

On android, the GLSurfaceView documentation says this:
A GLSurfaceView must be notified when the activity is paused and
resumed. GLSurfaceView clients are required to call onPause() when the
activity pauses and onResume() when the activity resumes. These calls
allow GLSurfaceView to pause and resume the rendering thread, and also
allow GLSurfaceView to release and recreate the OpenGL display.
So I'm supposed to do something like this in my activity:
public void onPause() {
myGlSurfaceView.onPause();
}
public void onResume() {
myGlSurfaceView.onResume();
}
I'm observing in my code that if I don't call onPause() and onResume() then the context is not lost when I press the home button, so I can switch between applications and then go back to my game and everything is working. What I see is that if I close the game using the back button then the screen is black when I open it again, but I can change the back button behaviour to totally close the game and avoid this problem.
So my question is: when is the OpenGL context destroyed? If I don't call onPause() and onResume() can I assume that it will never be destroyed?
EDIT:
I'm targeting Android 2.2, so setPreserveEGLContextOnPause() is not an option to me.

The OpenGL might be lost only after Actvity::onPause() is called, and only in this case. See the setPreserveEGLContextOnPause documentation :
Whether the EGL context is actually preserved or not depends upon whether the Android device that the program is running on can support an arbitrary number of EGL contexts or not. Devices that can only support a limited number of EGL contexts must release the EGL context in order to allow multiple applications to share the GPU.
[...] the EGL context [can be] released when the GLSurfaceView is paused, and recreated when the GLSurfaceView is resumed.
EDIT : The situation described in the documentation is valid on all Android version. Not matter you have access to setPreserveEGLContextOnPause
In my opinion, this is one major drawback is Android OGLES implementation : you can't be certain.
The documentation itself is vague (EGL Context Lost note) :
There are situations where the EGL rendering context will be lost. This typically happens when device wakes up after going to sleep
I noticed the same behavior as you about the Home and Back button. Calls are not exactly the sames (but can't remember them precisely).
The only way to be sure that the OpenGL context is available is to create all OpenGL resources in onSurfaceCreated
Note about setPreserveEGLContextOnPause. Once again, this documentation comment demonstrates the "random" behavior of context destruction :
If set to true, then the EGL context may be preserved when the GLSurfaceView is paused. [...]

setPreserveEGLContextOnPause is an option for you, you just have to implement the GlSurfaceView yourself.
See my answer here to a similar question:
Prevent onPause from trashing OpenGL Context

Losing OpenGL Textures in Android after a resume

My game is working correctly except in the case where I press the HOME button then resume. What needs to be done to use the textures again? I have tried calling onPause and onResume on the GLSurfaceView (when the activity's onPause and onResume are called).
Any ideas what I could be doing wrong?

If all else fails, reload the textures:
Pseudocode
for tex in textures:
if glIsTexture(tex.opengl_name) == false:
glGenTextures(1, &tex.opengl_name)
glBindTexture(tex.texture_target);
glTexImage(..., texture.image);

Even if you fixed your problem, just to give a bit of explanation that might help others.
Android does not guaranty to keep the OpenGL context alive when the activity is paused.
You have to recreate every OpenGL-resources on resume (texture in you case, but also VBOs etc etc).
Since API 11, you can ask kindly Android to keep the context, but there is no guaranty it would.

After trying:
do not call GLSurfaceView#onPause/onResume in Activity's onPause/onResume
call GLSurfaceView#onPause/onResume, but also set GLSurfaceView#setPreserveEGLContextOnPause(true)
Both of cases fix the HOME-resume-black-texture issue.
Guess Android implementation failed to re-create the EGL context when resume. Since onPause/onResume are required to call, should always set setPreserveEGLContextOnPause to true.

How to change content view from a GLSurfaceView?

I'm working on a small game and I'm having problems changing my Activity's content view when a GLSurfaceView is set, let me describe how the app works:
The app has only one Activity, it starts with a static view: setContentView(R.layout.main);, when the user sends a certain input using menus a GLSurfaceView is instantiated and set via setContentView(gameSession); (where gameSession is the class extending GLSurfaceView). The GLSurfaceView class then sets the Renderer on which the real application logic runs.
What happens now is that the game logic (ran inside the Renderer) is the one responsible for knowing when the game is over and the view should change back to R.layout.main, the Renderer then calls a synchronized method on the GLSurfaceView, which notifies the Activity to be changed (again with setContentView(R.layout.main);).
And here comes the problem, as soon as setContentView(R.layout.main); is called everything hangs, the GLSurfaceView is still there (just not getting updated anymore). I fear that I'm experiencing a deadlock, with the Activity waiting for the Renderer to be done before removing it.
I've been thinking on a few solutions but all of them bring other issues:
Having the GLSurfaceView or the Activity see if the game is over by polling a flag on the Renderer, but there is no loop on those classes, (and the onDraw on the GLSurfaceView is never called)
Using the queueEvent() method, but the Renderer class doesn't have it (and using GLSurfaceView.queueEvent() doesn't work because the Runnable remains of the Renderer thread)
Implementing some kind of message thread only to check for game end, but that sounds like a waste of resources.
Has any one of you experienced a similar issue? What's the best way to change your Activity's content view from a GLSurfaceView to something else if the logic for when to swap is on the Renderer?

You shouldn't be calling setContentView() multiple times.
You could instead use multiple activities, calling finish() on your game activity when you're done with it to return to the static view Activity.