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?
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.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.