Skip to main content

Android UI Internal: The Design of SurfaceFlinger , Design Pattern's perspective

This slide was for a training I conducted around a year ago for our internal team and I feel more people might find it useful, especially those who also works in Android graphic framework.

Android native graphic system, with SurfaceFinger sitting in the center, is rather sophisticated and it takes time to fully appreciate how all pieces working together. Despite of the complexity, I often marvel at the elegance of the whole architecture design. To active this elegance,  design patterns play a critical role.

In this presentation, I introduced several design patterns: Observer, Proxy, Command Pattern, Thread Pool, Producer-Consumer, and Active Object. The first three are introduced in GOF classic . The last three are concurrent patterns and you may want to goole a little bit.  Furthermore, I illustrated how SurfaceFlinger utilized and evolved those pattens to build a larger architecture to meet the requirements needed by graphic system. I also explained the sequence of how an update in user application trigged the composition of SurfaceFlinger - a user case that links every pieces together.

I wish you find it useful.

Popular posts from this blog

Android Security: An Overview Of Application Sandbox

The Problem : Define a  policy  to control how various  clients  can  access  different  resources . A  solution: Each  resource  has an  owner  and belongs to a  group . Each  client  has an  owner  but can belongs to multiple  groups . Each  resource  has a  mode  stating the  access permissions  allowed for its  owner ,  group  members and others, respectively. In the context of operating system, or Linux specifically, the  resources  can be files, sockets, etc; the  clients  are actually processes; and we have three  access permissions :read, write and execute.

Android Camera2 API Explained

Compared with the old camera API, the Camera2 API introduced in the L is a lot more complex: more than ten classes are involved, calls (almost always) are asynchronized, plus lots of capture controls and meta data that you feel confused about.

Android Security: A walk-through of SELinux

In  DAC , each process has an owner and belong to one or several groups, and each resource will be assigned different access permission for its owner and group members. It is useful and simple. The problem is once a program gain root privileged, it can do anything. It has only three permissions which you can control, which is very coarse. SELinux is to fix that. It is much fine-grained. It has lots of permissions defined for different type of resources. It is based on the principle of default denial. We need to write rules explicitly state what a process, or a type of process (called domain in SELinux), are allowed to do. That means even root processes are contained. A malicious process belongs to no domain actually end up can do nothing at all. This is a great enhancement to the DAC based security module, and hence the name Security-Enhanced Linux, aka SELinux.