Changes

That's in fact the right way (the only way) to hold on to a gralloc buffer in a given process. But since gralloc buffers are shared across multiple processes, and GraphicBufferobjects only exist in one process, a different type of object has to be actually shared and reference-counted across processes. That is the notion of a gralloc buffer ''handle''.

Since sp object So when a gralloc buffer is allocated on stack of shared between two processes, each process that share it. The undering has its own GraphicBuffer object with its own refcount; these are sharing the same underlying gralloc buffer ''handle must be refcounted otherwise the refcount goes wrong when it shared across process''. The trick is when GraphicBuffer going shared sharing happens by processes, the IPC code of Android will call calling GraphicBuffer::flatten to serialize the GraphicBuffer object, and call GraphicBuffer::unflatten to deserialize it. And GraphicBuffer::unflatten will call mBufferMapper.registerBuffer to make sure ensure that the undering underlying buffer handle is refcounted correctly.

And when When a GraphicBuffer 's refcount goes to zero, GraphicBuffer::~GraphicBuffer will incurred, and it the destructor will call free_handle which call mBufferMapper.unregisterBuffer. So the undering buffer , which will not released untill all decrement the GraphicBuffer got released and refcount of the undering gralloc buffer ''handle refcount goes to zero''.

The usage flag is some kind of hint for performance optimization. When you use SW flags, it may just disable all possible optimize optimizations there. Since CPU usually cache data into registerregisters, when we want to lock the buffer for read/write, it have to maintain the cache for correct data. However, other hardware that can use GraphicBuffer on Android e.g. Codec, Camera, GPU do not cache data. It locks/unlocks the buffer in a faster fashion.