The Android binderfs Filesystem

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

Mounting binderfs

Android binderfs can be mounted with:

mkdir /dev/binderfsmount -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 willonly be abinder-control device which serves as the request handler forbinderfs. Mounting another binderfs instance at a different location willcreate a new and separate instance from all other binderfs mounts. This isidentical to the behavior of e.g.devpts andtmpfs. The Androidbinderfs filesystem can be mounted in user namespaces.

Options

max

binderfs instances can be mounted with a limit on the number of binderdevices that can be allocated. Themax=<count> mount option serves asa per-instance limit. Ifmax=<count> is set then only<count> numberof binder devices can be allocated in this binderfs instance.

stats

Usingstats=global enables global binder statistics.stats=global is only available for a binderfs instance mounted in theinitial user namespace. An attempt to use the option to mount a binderfsinstance 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 besent through thebinder-control device node. A request is sent in the formof anioctl().

What a program needs to do is to open thebinder-control device node andsend aBINDER_CTL_ADD request to the kernel. Users of binderfs need totell the kernel which name the new binder device should get. By default a namecan only contain up toBINDERFS_MAX_NAME chars including the terminatingzero byte.

Once the request is made via anioctl() passing astructbinder_device with the name to the kernel it will allocate a new binderdevice and return the major and minor number of the new device in the struct(This is necessary because binderfs allocates a major device numberdynamically.). After theioctl() returns there will be a newbinder device located under /dev/binderfs with the chosen name.

Deleting binder Devices

Binderfs binder devices can be deleted viaunlink(). This meansthat therm() tool can be used to delete them. Note that thebinder-control device cannot be deleted since this would make the binderfsinstance unusable. Thebinder-control device will be deleted when thebinderfs instance is unmounted and all references to it have been dropped.

Binder features

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

Example:

cat /dev/binderfs/features/oneway_spam_detection1