I'm curious about the display device on Android. I know that on Linux, device devices are represented as /dev/fbX, which "fb" stands for FrameBuffer. I also heard that Android uses FrameBuffer as well

in Android it’s /dev/graphics/fbX, usually /dev/graphics/fb0

Kaustav - Introduction to the Android framebuffer


Android relies on the standard frame buffer device (/dev/fb0 or /dev/graphics/fb0) and driver as described in the linux/fb.h kernel header file.

Display Drivers | Android Open Source

However, on my device, which is OnePlus 7 Pro running Lineage OS, I could not find anything related to that. I even cannot find any device nodes called *fb* under /dev. However, I heard that someone has some devices with fb, and their other devices don't.

I'm just curious, why? Where is the display device on Android?

  • Android's hardware implementation is totally vendor specific. There's no standardization. Many OEMs don't expose standard Linux interfaces in /dev, /sys, /proc, /config etc. Many syscalls don't work either. Instead OEM's closed-source HALs interact with hardware through different IPC's particularly Binders. Commented Jan 7, 2021 at 16:51
  • @IrfanLatif Thanks! This helped a lot. Commented Jan 7, 2021 at 22:05

1 Answer 1


I had a lot of similar questions until I asked them here. The essence of the infos you get over this post is these:

  • No android app handles directly /dev/fb0, does it exist or not. Instead, they are communicating with the system process named "Surface Flinger", which is the analogy of the X server on the Linuxes.
  • This communication happens with Binder, which is an android-specific localhost-only RPC protocol similar to the unix pipes.
  • Not even the Surface Flinger can see the /dev/fb0 directly. Instead, it talks to the HAL (hardware abstraction layer). Until Android 8, the HAL was a set of shared libraries in /lib/hw. Since Android8, also the HAL is a set of system services talking over binder with the Surface Flinger (although legacy shared lib HALs are still possible).
  • Direct display access happens in the HAL library (service) responsible for that.

HAL libs (services) are developed by the phone vendor. Ha can develop a /dev/fb0 driver and use a hal capable to handle it, but he can also develop any custom method. In the second case, you won't have a /dev/fb0 in the kernel.

Furthermore, and it is already a linux-specific thing: /dev does not need to have all the device files existing on your system. Commonly it is so, but it is not a requirement. (On most Linux distros, the software named udev automatizes this task, but Android does not use it.) /dev has device files, on a Linux you can see that they start by a c (character device file) or b (block device file) in the ls -l output, and also on Android:

crw-rw---- 1 root video 29, 0   Dec 10 09:08 /dev/fb0
brw-rw---- 1 root disk   8, 0   Dec 11 07:21 /dev/sda
-rwxr-xr-x 1 root root  1302248 Apr 18  2019 /bin/bash

/dev/fb0 is a character device file, /dev/sda is a block device file, while /bin/bash is an ordinary file and not a device.

You can create device files with the mknod tool, but note: it requires root.

It is quite possible that /dev/fb0 is created elsewhere on your system, maybe on a location which is hidden behind same userspace-only mounts or so. It is also possible that fb0 is not created at all, despite that its driver is compiled into the kernel.

We can check, which device files are compiled into the kernel, in the procfs file /proc/devices. It should contain the line

Character devices:
29 fb          

This procfs file is practically always readable also as a user. If it does not exist, then your HAL responsible for the display communicates over some other way with the kernel.

If it exists, then you can create the framebuffer device by a command

mknod /dev/fb0 c 29 0

as root. (Actually you can always create it as root, but if the line above does not exist in /proc/devices, then it won't be usable.)

P.s. in LineageOS, my experiences are far the best by compiling an userdebug image. It did not slow my system at all, but all the rooting, adb things worked in it very correctly.

  • Hmm, I tried to mknod and it successfully created the device node, but when I tried to access it using cat or whatever tools, it shows like No such device. Commented Jan 10, 2021 at 23:35
  • Is the char dev 29 in /proc/devices?
    – peterh
    Commented Jan 11, 2021 at 0:04
  • Yes. cat /proc/devices | grep fb outputs 29 fb Commented Jan 11, 2021 at 0:40
  • Then the device exists, so the open/read/write/close calls are handled by the driver. This driver returns -ENODEV, this can have many reasons and I think none of them is fair. You should get somewhere the kernel configuration of the vendor and check, which driver is it.
    – peterh
    Commented Jan 11, 2021 at 0:53
  • 1
    @YuutaW Find somehow the HAL and debug it. It will be probably hard. | Btw, afaik X11 on Linux does not use fb0 generally, it uses only the KMS (kernel mode setting) API.
    – peterh
    Commented Jan 11, 2021 at 0:55

You must log in to answer this question.

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