I know well the desktop world of the Android and I am currently digging for, how does it work.

I think, because multiple processes (apps) can interact simultanously with the desktop, some central service (process) should exist to collect their change requests and unite them into an always consistent form (for example, if the content of a window changes while it is not visible, then the change should be invisible on the screen - until that window does not go into the front). Only this process has direct access to the frame buffer of the display (i.e. only it can directly change the pixels).

In the Linux/Unix world, this is being done by the X Server. The processes (apps) interact with the X Server on Unix sockets.

On Windows, as far I know, it is a kernel feature (thus, there is no specific process for that), and the processes interact with it on LPC (local procedure calls, windows-specific user space - kernel space communication mechanism).

On the net around, there is a huge mass of detailed documentation about the app-level interface, but nothing about this deeper internals.

How does it work on Android?

  • @alecxs First link: I think it is mostly unrelated to my question, and surely does not answer it. Second link: I think system_server is probably what I am looking for, although it is unclear, how does it access the display hardware, and how do the processes (apps) interact with it.
    – peterh
    Dec 15, 2020 at 14:01
  • @alecxs I am sorry but if you think that this answer has anything to do to this question, you probably do not understand this question. Btw, I don't think that this answer is an useful answer for this question. Thank you very much, but I know that a kernel is not a "platform" (the OP probably understands the set of Java libraries on "platform").
    – peterh
    Dec 15, 2020 at 14:18
  • 1
    @peterh-ReinstateMonica The question linked by alecxs mentions "Surface Flinger (Android's Display Server)" which is from my understanding the answer to your question. See for details: source.android.com/devices/graphics/…
    – Robert
    Dec 15, 2020 at 14:45
  • 1
    SurfaceFlinger is an init service, at least in recent Android releases; a native binary as well as a library. Check /system/bin, /system/lib, pgrep -a surfaceflinger, getprop init.svc.surfaceflinger on your device. Somewhat related: android.stackexchange.com/a/221749/218526. "How do processes (apps) interact with it?" is purely ROM / HAL development question, not suitable here. In short they use Android's/Linux's IPC mechanisms for communication. You may check official documentation for details. Dec 15, 2020 at 15:32

1 Answer 1


Summarizing the answers: display handling happens by the Surface Flinger, which is a service process started by the init scripts on boot.

Apps interact with the Surface Flinger over Linux/Android IPC mechanisms. The comment did not detail, how. Androids preference is binder and shared memory in most cases. Binder uses device files for process communication.

Surface Flinger communicates with the hardware over the vendor-provided HAL. Until Android 8, HAL was a set of shared libs in /lib/hw, provided by the vendors. Since Android 8, HAL is a set of system services (also processes started by the initialization). Legacy HALs in the form of shared libraries still do exist.

  • 2
    SurfaceFlinger communicates with vendor-provided HAL, not hardware. Dec 15, 2020 at 15:42
  • @IrfanLatif Tyvm!
    – peterh
    Dec 15, 2020 at 15:45
  • 1
    "HAL is a set of shared libs in /lib/hw". No. Binderized HALs introduced in Android 8 are not libraries but run as native daemons. Dec 15, 2020 at 15:52
  • @IrfanLatif Thanks! I inserted it into the answer, is it okay?
    – peterh
    Dec 15, 2020 at 17:47
  • 1
    Yes but not all HALs are daemons. Legacy HALs are still shared libraries. Dec 15, 2020 at 18:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .