SurfaceView: Don't destroy Surface while Stopped.
We instead just want to leave it floating, and let it's lifetime be controlled by the parent surface. This way it can take part in animations. Normally the WindowManager handles this by calling detachChildren but it seems sometimes stop arrives before the window manager is even clued in. Rather than bringing ActivityManager in to the detach children dance...this seemed more appropriate and very similar to the behavior before SV->SurfaceControl port. Bug: 37922210 Test: Manual from bug + Launch chrome a bunch Change-Id: Iee4fb0078a6e8dfd4c7acdb0107f8edd3a995634
This commit is contained in:
@@ -678,9 +678,16 @@ public class SurfaceView extends View implements ViewRootImpl.WindowStoppedCallb
|
||||
} finally {
|
||||
mIsCreating = false;
|
||||
if (mSurfaceControl != null && !mSurfaceCreated) {
|
||||
mSurfaceControl.destroy();
|
||||
mSurface.release();
|
||||
mSurfaceControl = null;
|
||||
// If we are not in the stopped state, then the destruction of the Surface
|
||||
// represents a visual change we need to display, and we should go ahead
|
||||
// and destroy the SurfaceControl. However if we are in the stopped state,
|
||||
// we can just leave the Surface around so it can be a part of animations,
|
||||
// and we let the life-time be tied to the parent surface.
|
||||
if (!mWindowStopped) {
|
||||
mSurfaceControl.destroy();
|
||||
mSurfaceControl = null;
|
||||
}
|
||||
}
|
||||
}
|
||||
} catch (Exception ex) {
|
||||
|
||||
Reference in New Issue
Block a user