The reason to use a client-server system like this is to allow producing and compositing a surface in two different processes.
Since eglSwapBuffers calls Let us introduce two important functions that a client needs to call on its ANativeWindow::dequeueBuffer to acquire and queueBuffer* dequeueBuffer acquires a new buffer and ANativeWindow::for the client to draw to;* queueBuffer lets the client indicate that it has finished drawing to return the a buffer implicitly, and queues it (e.g. for compositing). Since eglSwapBuffers internally calls dequeueBuffer and queueBuffer, this system removes the need for manual management of GraphicBuffer's as we are currently doing in our B2G code. the user can avoid to create several textures and manage them directly. The other useful feature of implement it in this way is that most BSP vendor provided graphics profilers(e.g. Adreno profiler from QCOM, PerfHUD ES from nVidia) that recognize the eglSwapBuffers call as frame boundary to collect frame based GL information from driver to help developement and performance tuning. SurfaceTexture is a unified buffer management mechanism on Android, which you can setup it to run in different mode: sync/async, single/multiple buffer by simple function call which make SurfaceTexture be used everywhere in Android: Codec/Camera configure it to have serveral buffer (based on hardware, 9 for camera preview in Unagi) run asynchronously, Layer rendering configure it to have 2~3 buffer (based on BSP) run synchronously. And since its flexbility, you can encode a OpenGL rendered surface on-the-fly by using SurfaceMediaSource (which implement ISurfaceTexture) which is the core of Google Miracast.
SurfaceTexture is the server-side class. SurfaceTextureClient is the client-side class. Both store an array of GraphicBuffers, called mSlots. The GraphicBuffer objects are separate instances in SurfaceTexture and in SurfaceTextureClient, but the underlying gralloc buffer handles are the same. The mechanism here is the client side issues a SurfaceTextureClient::dequeueBuffer call to get a new buffer to paint to. If there are not already enough buffers, and the number of buffers is not over the limit (32), it sends an IPC message that results in a call to SurfaceTexture::dequeueBuffer which allocates the GraphicBuffer. And after buffer allocation, the client side will send an IPC message that results in a call to SurfaceTexture::requestBuffer to get the gralloc buffer handle serialized over IPC back to it, and construct a GraphicBuffer around this handle, and cache it into its own mSlots. The mSlots arrays on both sides mirror each other, so that the two sides can refer to GraphicBuffers by index.
