[alexkcd]

The graphics stack in Android is badly designed. It is that way for historical reasons. Android used to do CPU-based blitting -- similar to other mobile platforms at the time: Symbian OS and Windows Pocket PC. Then the first iPhone launched & it became clear that GPU rendering was the way to go for mobile UI drawing.

Rather than rebuild the graphics stack from the ground around GPU rendering, GPU support was tacked on to the existing graphics stack. Resulting in this franken-architecture: http://source.android.com/devices/graphics/architecture.html

That guide has such gems as:

"Once upon a time this was done with software blitting to a hardware framebuffer (e.g. /dev/graphics/fb0), but those days are long gone."

"While this section uses SurfaceFlinger terminology, WindowManager uses the term window instead of layer…and uses layer to mean something else. (It can be argued that SurfaceFlinger should really be called LayerFlinger.)"

"Some things that work with Surfaces want a SurfaceHolder, notably SurfaceView. The original idea was that Surface represented the raw compositor-managed buffer, while SurfaceHolder was managed by the app and kept track of higher-level information like the dimensions and format. The Java-language definition mirrors the underlying native implementation. It's arguably no longer useful to split it this way, but it has long been part of the public API."

etc.

[yincrash]

For beginner use cases of the Android API, this isn't really a problem they would encounter.

[pawadu]

But that stuff is mostly relevant for manufacturers, not developers.