Out-of-the-box GPU acceleration for Mali devices using virglrenderer

CI testing:

https://github.com/ravindu644/Droidspaces-OSS/actions/runs/22533326363

Steps to reproduce:

1. Download the artifact from the CI link and install the APK.

2. Edit the container configuration using app to enable X11 and start the container.

3. Open Termux and run:

virgl_test_server_android &

4. Then run:

termux-x11 :0

(Note: :0 is the display number)

5. Enter the container and set the display:

export DISPLAY=:0

6. Set the virgl driver:

export GALLIUM_DRIVER=virgl

7. Run glxgears and check if it works in Termux-X11.

Note: You'll need to manually install packages in both the container and Termux (not mentioned here).

@Droidspaces

Droidspaces v4.6.0 has been released..!

What's new ? 👀

[ App ]

- Android users now have a universal method to create a bridge between Termux and Container for a single-tap Termux:X11/virgl setup.
- Fixed hanging in the systemd services menu in the Android app.
- Added a new legend in the systemd menu called 'static'.
- Refined the bind mount file picker for a smoother experience.
- Added a new option to define environment variables in the container configuration menu.

[ Backend ]

- In Linux Desktop, no bridge is needed - host's /tmp/.X11-unix folder is now mounted directly to the container's /tmp/.X11-unix.
- Fixed Kernel panics on the host when using --hw-access in Linux Desktop due to mounting wrong GPU nodes.
- Added an option to define environment variables when booting a container in both the backend and the Android app.
- Removed the 16 bind mount max limit from both backend and the Android app.

Github Release: https://github.com/ravindu644/Droidspaces-OSS/releases/tag/v4.6.0

@Droidspaces

Re-uploaded due to a bug in the bind mount logic, where the mounts never got mounted during a container restart because of my aggressive resource cleanup to prevent memory leaks.

🔴 MUST FOLLOW THESE EXACT STEPS:

1. Before installing, stop all your containers.
2. Install the APK and update the backend.
3. Reboot your phone.

New feature: Self-recovery

Implemented at the backend level.

If the backend detects that the PID files, environment variables, container config file, or mountpoints have been deleted,

The backend will automatically restore the exact files that were deleted to their original locations.

Additionally,

You can now place containers anywhere.

For example, the rootfs.img can be inside your internal storage.

The backend will automatically create the necessary configuration inside /data/local/Droidspaces/Containers, and the app will automatically pick it up.

This means,

You no longer need to use the app for installation.

v4.7.2 pre-release is out:

https://github.com/ravindu644/Droidspaces-OSS/releases/tag/v4.7.2-pre-release

It passed my “surface-level tests” 🗿

I know some guy with a wonky setup will still report bugs.

But in this release, the metadata is immutable - even if it gets nuked by Android, by you, or by some race condition I haven’t found lurking in the backend - no worries..!

The metadata will auto-heal within 3 ms, and you won’t even notice a thing.

TL;DR: This release hardens security more:

1. Metadata will never get corrupted or nuked.
2. No ghost containers allowed - even if the metadata is nuked or N/A, we scan the entire /proc within 3 milliseconds to catch any “lost” containers.
3. Nothing will be lost - nothing can escape.

@Droidspaces

v4.7.3 is released with a critical bug fix!

https://github.com/ravindu644/Droidspaces-OSS/releases/tag/v4.7.3

I worked 4 days straight figuring out why PID files were getting nuked when "Run at Boot" was enabled. I even hardened the security, preventing users from running 2 containers with the same name, and ensured all metadata could be recovered even if /data ceased to exist, etc. (This added more complexity to the project-but ultimately helped in a good way, lol).

Only to realize…

The issue wasn’t in the backend at all.

It was in the app.

We had 2 different "Run at Boot" implementations: one in the app and one in the Magisk module.

Both did the same thing. The Magisk module "Run at Boot" feature was a later addition to the app, and I forgot to remove the old implementation.

This caused the bug, and it went unnoticed for 4 months!

Which is insane...

@Droidspaces

APK for testing..

if any issues, drop the log file from /data/local/Droidspaces/Logs/<name>/log

Example:

Fix network isolation in modern systemd on Droidspaces

( Android Only )

01. Enter the container's root shell and delete these files:

rm -f /etc/systemd/network/10-wifi.network
rm -f /etc/systemd/network/20-mobile.network
rm -f /etc/systemd/network/30-other.network

02. Create an override systemd-networkd config to keep our static IPv4 address:

mkdir -p /etc/systemd/network

cat > /etc/systemd/network/99-unmanaged.network << 'EOF'
[Match]
Name=*

[Link]
Unmanaged=yes
EOF

03. Mask the useless systemd-networkd-wait-online service:

ln -sf /dev/null /etc/systemd/system/systemd-networkd-wait-online.service

Done !

@Droidspaces

Droidspaces v5.0.0-pre-release !

🪵 What's new?

https://github.com/ravindu644/Droidspaces-OSS/releases/tag/v5.0.0-pre-release

[ App ]

- app: implemented NAT/HOST/NONE Network modes to the container configuration menu
- add network isolation configuration requirements to the Droidspaces kernel configurations

[ Backend ]

- net: implement full network isolation with NAT, bridgeless fallback, and Android routing 
- fix: Configure systemd-networkd to unmanage all network interfaces, preventing DHCP conflicts with Droidspaces' static IP setup
- mask systemd-networkd-wait-online.service and make udevadm trigger non-critical in udev-trigger.service
- fix: Apply interactive terminal check for foreground mode only to interactive commands like start, restart, or enter
- Add --reset command-line option to clear container configuration while preserving name and rootfs paths
- Implement a centralized logging engine with internal functions, container-specific file logging, and refactored logging macros
- Cache cgroup mount points, optimize mountinfo parsing, ensure correct PTY allocation in new PID namespaces, and prevent terminal I/O blocking
-  Add check_ns function to verify network namespace support and integrate it into network mode validation
- Add live kernel probes for bridge and veth support to check NAT networking capability

Notes:

- For existing modern systemd containers like Ubuntu 25.04, Fedora, and Arch, you must apply this fix to make NAT mode work - new containers will be automatically fixed upon installation in the app.

- Kernel configurations required for NAT mode have been updated. Please get the new configurations from the app.

@Droidspaces

Demonstration of our isolated networking: it works perfectly even when switching between 3 different networks 🗿

M21 -> Mobile Data -> M14

It doesn’t even feel it.. 🗣

No more IP nuking by containers..!

I implemented a simple DHCP server that can provide up to 65K IPs at once if the user runs 65K containers simultaneously..🗿

No need to edit any container files.

It just works..

Droidspaces v5.1.0-pre-release is here..!

https://github.com/ravindu644/Droidspaces-OSS/releases/tag/v5.1.0-pre-release

What's new..?

[ Backend ]

net: replace static RTNETLINK IP assignment with embedded DHCP server

THIS MUST FIX ALL OF THE NETWORKING ISSUE IN THE NAT MODE - NO FILES EDIT NEEDED.

If you did this thing before, please revert it.

@Droidspaces