1. Issue interpreted by CQA:
CQA interpreted this issue as every RenderPass seen in Android Graphics Analyzer should have a call to glInvalidateFramebuffer. The devices that reproduces this issue were PowerVR GPU devices. I see the first misconception that you must call glInvalidateFramebuffer to prevent loading memory at the start of the RenderPass if the Framebuffer contents will be overwritten anyway. That is not true, both glInvalidateFramebuffer and Clear commands prevent tile read from memory. On Tile-based renderers clears at the start of the RenderPass are free, since they can just initialize the tile memory to a given clear value. [source](https://developer.arm.com/documentation/102479/0100/Efficient-Render-Passes), [source2](https://developer.arm.com/documentation/101897/0301/Fragment-shading/Efficient-render-passes-with-OpenGL-ES?lang=en)

In our core engine settings we have PowerVR GPUs blacklisted from using glInvalidateFramebuffer. I don't know the reasons for it, but must likely PowerVR has performance or general issues with this when using as a hint to prevent restoring Framebuffer contents at the start of a RP.

Do note that glInvalidateFramebuffer is just a hint to the driver, that the contents of the Framebuffer can be discarded.

2. Android Blit Type Never
The main misconception is what this option does. It should be pretty clear what this does from our documentation [source](https://docs.unity3d.com/ScriptReference/AndroidBlitType.html). This option simply lets you control whether the default rendering uses an intermediate Framebuffer for rendering. This is useful because it avoids various bugs with compositors, hardware scalers, allows switching MSAA at runtime, multi-display, allows read access to backbuffer and etc.
Of course there's the added performance impact of an extra blit operation.

3. In either of these modes, does our implementation avoid writing tile memory back to main memory?
Our engine always tries to make sure we avoid unnecessary read/writes to memory. We even have API to manually control rendering buffer memory loading and storing https://docs.unity3d.com/ScriptReference/Rendering.RenderBufferLoadAction.html. Android Blit Type Never makes sure we directly render to the backbuffer and avoid any additional blit operations that would be used for various compatibility reasons with Android Blit Type Always.

Some platforms may still fallback to Android Blit Type Always behaviour due to some driver or compatibility issues that we want to work around.