Question

I do not understand the differences between when a user locks the screen (using the top screen lock button) and immediately returns to the application vs. when the user presses the home button and then immediately returns to the application.

It seems that all the same calls are being made. From my observations:

Called when home button or screen lock are pressed: onPause -> onStop

Called when application is pressed after home button or screen lock is re-pressed: onRestart -> onStart -> onResume

My individual problem:

This is particularly causing me greif because I am recreating a SurfaceView and a GLSurfaceView to a FrameLayout upon onResume, however, depending on the button pressed, the ordering of the elements is getting changed. I have the following code in my onResume:

cameraPreviewArea = (FrameLayout) findViewById(id.camera_preview);
cameraPreviewArea.addView(glView, glLayout);
cameraPreviewArea.addView(camprevSurfaceView, new LayoutParams(LayoutParams.FILL_PARENT, LayoutParams.FILL_PARENT));

This has the effect of displaying my glSurfaceView on top in the following situations: the first time the app has launched, and when the app is being resumed from being screen-locked and then screen-unlocked. However, upon pressing the home button, and then reopening the application, the SurfaceView is being placed ON TOP of the glSurfaceView!

If I switch the addView calls as follows, the opposite situations will occur. I could fix this with some boolean flag, but it it unclear where I would set the boolean because of my uncertainty as to the difference between a screen lock/unlock and the home button. Also, I do not want to solve the problem in this manner anyway because it seems hacky and lacks any real understanding of the problem.

Thank you in advance!

Answer 1

This specific situation – using two surfaceViews and specifying their Z order within a window – does not seem to currently be supported by Android. This thread over at the android developer group shares the following information:

Multiple active overlapping surface views, of any sort, are not
currently supported by the framework. You may get them to work, but
it is mostly due to luck — the view hierarchy does not define the
Z-ordering of those surfaces, nor try to ensure they are Z-ordered in
any particular way, so this may change for whatever reason.

Well… there you go!

…But for anyone attempting this I found a workaround: make your camera preview size a tiny 1×1 square. This will allow you to display both simultaneously (because a camera preview must be visible in order for the preview to continue) and ignore the pesky SurfaceView issues that the cameraPreview presents you with. I believe there is a better solution using strictly one GLSurfaceView, but it is not compatible below 3.0.