Description
There is a fundamental incompatibility between the current Redroid Docker images (versions 10 through 15) and modern Linux kernels that provide the binder driver via the binderfs filesystem instead of the legacy /dev/binder character device. This prevents Redroid from running on systems like a Raspberry Pi 5 with a modern, custom-compiled kernel.
Environment:
- Hardware: Raspberry Pi 5 (8GB)
- Host OS: Ubuntu Server 22.04 LTS (arm64)
- Kernel: Custom-compiled Linux kernel (based on 6.8) with
CONFIG_ANDROID_BINDERFS=y enabled. The legacy CONFIG_ANDROID_BINDER_DEVICES is unset.
- Docker: Docker Engine 27.0.3
Problem Encountered:
After successfully compiling a stable custom kernel that includes the modern binderfs driver, all attempts to run Redroid fail during the container's boot process.
- When the host's
/dev/binderfs directory is mapped to /dev/binder inside the container (-v /dev/binderfs:/dev/binder:rw), the container's services fail to start.
- The
logcat from inside the container shows a repeating, fatal error for all core Android services:
F ProcessState: Binder driver '/dev/binder' could not be opened. Terminating.
W ProcessState: Opening '/dev/binder' failed: Is a directory
This definitively proves that the Redroid services are hard-coded to open /dev/binder as a character device file and are not compatible with the binderfs filesystem, which presents it as a directory.
Supporting Evidence:
The official remote-android/redroid-modules repository itself points to this architectural shift. The README states:
"If use custom kernel (5.0+), you can enable binderfs and ashmem configs; So the kernel modules in this repo are not needed any more."
This confirms that modern kernels should use binderfs. However, the Redroid images have not been updated to support it, creating this incompatibility for users who are correctly following modern kernel configuration practices.
Feature Request:
Could support for the modern binderfs system be added to Redroid?
As modern Linux kernels move towards binderfs as the standard, and since the legacy binder_linux module can be unstable on some ARM hardware (as it caused kernel panics on this Raspberry Pi 5), supporting binderfs directly would significantly improve Redroid's compatibility and future-proof the project.
This would likely involve updating the Android init process and core services within the Redroid image to detect and use the /dev/binderfs directory correctly if the legacy /dev/binder file is not present. This is the approach successfully used by other projects like Waydroid.
Thank you for your consideration. This would be a major benefit for users on modern embedded and ARM-based systems.
Description
There is a fundamental incompatibility between the current Redroid Docker images (versions 10 through 15) and modern Linux kernels that provide the binder driver via the
binderfsfilesystem instead of the legacy/dev/bindercharacter device. This prevents Redroid from running on systems like a Raspberry Pi 5 with a modern, custom-compiled kernel.Environment:
CONFIG_ANDROID_BINDERFS=yenabled. The legacyCONFIG_ANDROID_BINDER_DEVICESis unset.Problem Encountered:
After successfully compiling a stable custom kernel that includes the modern
binderfsdriver, all attempts to run Redroid fail during the container's boot process./dev/binderfsdirectory is mapped to/dev/binderinside the container (-v /dev/binderfs:/dev/binder:rw), the container's services fail to start.logcatfrom inside the container shows a repeating, fatal error for all core Android services:This definitively proves that the Redroid services are hard-coded to open
/dev/binderas a character device file and are not compatible with thebinderfsfilesystem, which presents it as a directory.Supporting Evidence:
The official
remote-android/redroid-modulesrepository itself points to this architectural shift. The README states:This confirms that modern kernels should use binderfs. However, the Redroid images have not been updated to support it, creating this incompatibility for users who are correctly following modern kernel configuration practices.
Feature Request:
Could support for the modern
binderfssystem be added to Redroid?As modern Linux kernels move towards
binderfsas the standard, and since the legacybinder_linuxmodule can be unstable on some ARM hardware (as it caused kernel panics on this Raspberry Pi 5), supportingbinderfsdirectly would significantly improve Redroid's compatibility and future-proof the project.This would likely involve updating the Android
initprocess and core services within the Redroid image to detect and use the/dev/binderfsdirectory correctly if the legacy/dev/binderfile is not present. This is the approach successfully used by other projects like Waydroid.Thank you for your consideration. This would be a major benefit for users on modern embedded and ARM-based systems.