What is the analogy of the X Server on Android? 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?
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.