The Android binderfs Filesystem — The Linux Kernel 6.14.0-gnu-rt3-parabola1-1-rt documentation

# The Android binderfs Filesystem

Android binderfs is a filesystem for the Android binder IPC mechanism. It allows to dynamically add and remove binder devices at runtime. Binder devices located in a new binderfs instance are independent of binder devices located in other binderfs instances. Mounting a new binderfs instance makes it possible to get a set of private binder devices.

## Mounting binderfs

Android binderfs can be mounted with:

    mkdir /dev/binderfs
    mount -t binder binder /dev/binderfs

at which point a new instance of binderfs will show up at `/dev/binderfs`. In a fresh instance of binderfs no binder devices will be present. There will only be a `binder-control` device which serves as the request handler for binderfs. Mounting another binderfs instance at a different location will create a new and separate instance from all other binderfs mounts. This is identical to the behavior of e.g. `devpts` and `tmpfs`. The Android binderfs filesystem can be mounted in user namespaces.

## Options

max

  binderfs instances can be mounted with a limit on the number of binder devices that can be allocated. The `max=<count>` mount option serves as a per-instance limit. If `max=<count>` is set then only `<count>` number of binder devices can be allocated in this binderfs instance.

stats

  Using `stats=global` enables global binder statistics. `stats=global` is only available for a binderfs instance mounted in the initial user namespace. An attempt to use the option to mount a binderfs instance in another user namespace will return a permission error.

## Allocating binder Devices

To allocate a new binder device in a binderfs instance a request needs to be sent through the `binder-control` device node. A request is sent in the form of an ioctl().

What a program needs to do is to open the `binder-control` device node and send a `BINDER_CTL_ADD` request to the kernel. Users of binderfs need to tell the kernel which name the new binder device should get. By default a name can only contain up to `BINDERFS_MAX_NAME` chars including the terminating zero byte.

Once the request is made via an ioctl() passing a `struct binder_device` with the name to the kernel it will allocate a new binder device and return the major and minor number of the new device in the struct (This is necessary because binderfs allocates a major device number dynamically.). After the ioctl() returns there will be a new binder device located under /dev/binderfs with the chosen name.

## Deleting binder Devices

Binderfs binder devices can be deleted via unlink(). This means that the rm() tool can be used to delete them. Note that the `binder-control` device cannot be deleted since this would make the binderfs instance unusable. The `binder-control` device will be deleted when the binderfs instance is unmounted and all references to it have been dropped.

## Binder features

Assuming an instance of binderfs has been mounted at `/dev/binderfs`, the features supported by the binder driver can be located under `/dev/binderfs/features/`. The presence of individual files can be tested to determine whether a particular feature is supported by the driver.

Example:

    cat /dev/binderfs/features/oneway_spam_detection
    1