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

Networking is unkillable now 🗿

100% uptime.

Even if you enable or disable Wi-Fi, data, or hotspot thousands of times,
no worries!

The Droidspaces daemon will perfectly handle everything in the background 🗿

Testing:

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