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. The
max=<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
Using
stats=globalenables global binder statistics.stats=globalis 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