Android bug——Launcher 0x506导致花屏问题

现象描述：
在Android4.4中，概率极高会出现Launcher或者应用整个绘制成花屏、黑屏或者字体绘制成方块等问题，出现花屏问题的时候将会在hwui中打印0x506的错误。

分析：
通过log发现也只有hwui中出现0x506这个错误码，即hwui中当前绘图时使用的fbo是无效的。接着通过分析代码发现当前hwui中使用fbo的地方为LayerRenderer中，在LayerRenderer中使用到fbo的地方也就是当view中需要创建HardwareLayer的时候，将会调用LayerRenderer将view绘制的信息通过fbo保存在纹理中：
status_tLayerRenderer::prepareDirty(float left,
float top, float right,
float bottom,
       
bool opaque) {
    glBindFramebuffer(GL_FRAMEBUFFER,mLayer->getFbo());
    …………
    returnOpenGLRenderer::prepareDirty(dirty.left, dirty.top, dirty.right, dirty.bottom,opaque);
}
 
Layer*LayerRenderer::createLayer(uint32_t width,
uint32_t height, bool isOpaque) {
    Caches& caches = Caches::getInstance();
    GLuint fbo = caches.fboCache.get();
    …………
    caches.activeTexture(0);
    Layer* layer = caches.layerCache.get(width,height);
    …………
    layer->setFbo(fbo);
    …………
    GLuint previousFbo;
    glGetIntegerv(GL_FRAMEBUFFER_BINDING,(GLint*) &previousFbo);
 
    glBindFramebuffer(GL_FRAMEBUFFER,layer->getFbo());
    layer->bindTexture();
    …………
    glFramebufferTexture2D(GL_FRAMEBUFFER,GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D,
            layer->getTexture(),
0);
 
    glBindFramebuffer(GL_FRAMEBUFFER,previousFbo);
    return layer;
}
定位：
1. 在使用fbo绘图的时候加入打印，同时dump出当前的每个纹理，发现当前绑定到纹理时，纹理就是错误的，所以用了错误的纹理去作为fbo的纹理，导致最后出现了花屏的问题

2. 接着在当前创建fbo的时候，通过调用glCheckFramebufferStatus来查看，发现当前的fbo创建与绑定纹理都是正确的

3. 通过加入详细log发现当前出错是在LayerRenderer::prepareDirty，这时会先调用glBindFramebuffer，接着将会调用 glClear，也就是这时候去使用fbo的fb清除当前的颜色缓存的时候，当前的fb是不能访问的。接着在gpu中打印发现当前fbo绑定的纹理id对应的纹理是空的，这时候也就是产生了0x506绘图错误。

通过上述分析，得出的结论是，在创建fbo的时候是正确的，在使用fbo的时候就出错了，由于当绑定fbo出错了，还继续绘制，但是当合成的时候由于当前的fbo是无效的，但是却还继续去使用，其实也就是当前的纹理id在绑定fbo的时候这个纹理是无效的，但是在后续的绘图的时候，如果这个纹理id是被拿来绑定纹理了，那么就出现了花屏问题，如果仍然没有拿来绑定纹理，那么就是出现黑屏的问题。这也就是出现了0x506绘图错误的原因了，接着将分析为什么会出现在创建fbo的时候是正常的，在使用的时候却是无效的。

原因分析：
通过分析知道当前fbo的是用于view中作为HardwareLayer的时候使用，接着查看view.java代码发现，view中变量mHardwareLayer用于保存当前的fbo的信息，如果当前mHardwareLayer没有调用LayerRenderer的destroyLayer的时候，这个layer是不会被删除的：
  boolean
destroyLayer(boolean valid) {
       
if (mHardwareLayer != null) {
            AttachInfo info = mAttachInfo;
           
if (info != null && info.mHardwareRenderer !=
null &&
                   info.mHardwareRenderer.isEnabled() &&
                    (valid ||info.mHardwareRenderer.validate())) {
 
                info.mHardwareRenderer.cancelLayerUpdate(mHardwareLayer);
                mHardwareLayer.destroy();
                mHardwareLayer =
null;
 
                invalidate(true);
                invalidateParentCaches();
            }
           
return true;
        }
       
return false;
    }
问题也就是由于当OpenGL上下文被删除的时候（这也是通过打印log发现在使用fbo之前已经将OpenGL上下文删除过，又重新创建新的上下文了），当前的mHardwareLayer没有调用destroyLayer来将当前的layer删除，这样就导致下次进入的时候直接使用了上次的mHardwareLayer，这样就出现了使用了上次的fbo的id，但是这个id却没调用glFramebufferTexture2D来绑定对应的纹理。（有个细节需要注意：如果没有生成fbo的id，直接调用glBindFramebuffer这个函数是会直接将指定的id拿来使用的，如果不存在就创建，这是标准规定的，这也是问题出现的原因）接着将分析为什么在OpenGL上下文删除的时候，没有将对应的mHardwareLayer删除的原因。
view中删除mHardwareLayer是在destroyLayer中，这边在删除的时候会去判断一些条件，重要的是当前的info.mHardwareRenderer.isEnabled()，如果当前的硬件加速是不可用的就不删除，通过打印log，发现当前出错的时候，确实当前的硬件加速是不可用的，这也就导致了mHardwareLayer资源没删除。

接着查看代码发现当硬件加速不可用的时候，调用是在HardwareRenderer.java中的destroy的时候会将当前的surface删除的时候，通过打印堆栈发现当调用destroy的时候就是当surface无效的时候，也就是正常现象。但是这时候如果刚好遇上了内存吃紧的情况，则将会调用WindowManagerGlobal.java的startTrimMemory，这函数将会调用view的destroyHardwareResources来进行每个view的资源的释放，这时候就没法将mHardwareLayer的资源进行释放了。
public
void startTrimMemory(int level) {
       
if (HardwareRenderer.isAvailable()) {
           
if (level >= ComponentCallbacks2.TRIM_MEMORY_COMPLETE
                    || (level >=ComponentCallbacks2.TRIM_MEMORY_MODERATE
                            &&!ActivityManager.isHighEndGfx())) {
               
synchronized (mLock) {
                   
for (int i = mRoots.size() -
1; i >= 0; --i) {
                       mRoots.get(i).destroyHardwareResources();
                    }
                }
                mNeedsEglTerminate =
true;
               HardwareRenderer.startTrimMemory(ComponentCallbacks2.TRIM_MEMORY_COMPLETE);
               
return;
            }
           HardwareRenderer.startTrimMemory(level);
        }
    }
修改方案：
当在destroyLayer的时候判断如果当前的硬件加速不可用的时候就调用，mHardwareRenderer的safelyRun来删除mHardwareLayer的资源：
diff --gita/core/java/android/view/View.java b/core/java/android/view/View.java
index d212786..239c235
100644
---a/core/java/android/view/View.java
+++b/core/java/android/view/View.java
@@ -13152,6 +13152,23 @@
public class View
implements Drawable.Callback,KeyEvent.Callback,
 
                 invalidate(true);
                 invalidateParentCaches();
+            }
else if (info !=
null&& info.mHardwareRenderer !=
null) {
+                // If fallinto this path, means the hardware render has
+                // alreadybeen disabled. Destroy it in a safely context
+                // toavoid random UI corruption
+                info.mHardwareRenderer.safelyRun(new Runnable() {
+                    @Override
+                   
public void
run() {
+                       mHardwareLayer.destroy();
+                        mHardwareLayer =
null;
+
+                       
if (mDisplayList != null) {
+                           mDisplayList.reset();
+                        }
+                        invalidate(true);
+                       invalidateParentCaches();
+                    }
+                });
             }
            
return true;
         }