Droidspaces

Implemented resource isolation and resource virtualization After this change, you'll be able to limit how much RAM a container can allocate, how many CPU cores a container can have, and the process limit a container can reach. That means a bad container can never kill the host! :) Also, it spoofs CPU, RAM, Uptime, Load AVG, and other metrics to match our resource limitations. Huge thanks to maazm7d for this patch!

Arch Linux Rootfs: (GKI kernels only) https://github.com/Droidspaces/Droidspaces-rootfs-builder/releases/download/v20260515-130323/Arch-Minimal-Kernel-5.x-and-up-Droidspaces-rootfs-aarch64-20260515-v20260515-130323.tar.xz

Nuked the old release and re-released it under the same release tag with the HW access gate 👍

This is it. From now on, if someone says "Droidspaces broke my XYZ," "Droidspaces caused kernel panics when using HW access mode," or "I lost my job because of Droidspaces because the alarm app failed while using HW access," the issue will be instantly closed. The container is yours. You control it, not me.

Starting from v6.1.0, we stopped masking systemd-udevd and systemd-udev-trigger in post-extract-fixes.sh, and only allowed udevd to access 5 subsystems. ( usb, block, input, tty, net ) this is the exact feature that finally allowed real hardware access. before this, --hw-access was a placebo. your /dev/sd* block devices did not even exist, even in hw-access mode, and your container had broken hardware access support. hardware existed, but most of the container processes were not able to see it. That's why nothing bad was happened. now, with the udev relaxation, your container acts like a real linux machine. it sees sdcards, usb drives, inputs, network hardware, and block devices properly in --hw-access mode. here is the reality: Droidspaces just fires up init and manages the environment. it does not do anything apart from that. when you use hw access, the container might own the hardware during boot. If a droidspaces container takes control of the pogo pin keyboard, android is left with nothing. so if your keyboard works perfectly inside the container but is "broken" in android, congratulations. That is not a bug. that is the container doing exactly what you told it to do. Stop blaming droidspaces because you do not understand how linux works. If you enable hw access and things go sideways, you signed up for it. The documentation literally has a giant red caution bar warning you about bricking your device and wiping your entire partition table. Your choices: 1. use gpu access only if you are not ready for this 2. go back to masking systemd-udevd and systemd-udev-trigger and enjoy "dumb hardware access" 3. use hw access only when necessary and accept that with great power comes the responsibility of not crying when your container steals your hardware from android read the docs and understand how linux works. your choice.

Droidspaces v6.1.5 has been released! 🥳 What's new? - Added full NixOS support, resolving all related issues. - Added support for riscv64 binaries. - Miscellaneous UI improvements, such as fixing UI overlaps with the keyboard and resolving the blank container page that appeared for several seconds during app initialization when many containers were installed. - Fixed a bug related to mounting rootfs images caused by long container names. - Implemented fast-shutdown support, allowing containers to stop within seconds. This has been tested across Ubuntu, Debian-based systemd distributions, Alpine, Gentoo, Devuan, Void, Nix, Busybox, Slackware, and others. Full changelog and downloads: https://github.com/ravindu644/Droidspaces-OSS/releases/tag/v6.1.5 @Droidspaces

Power of Droidspaces 🗿 You can even nuke the entire app. Your containers will still run in the background 😏 @Droidspaces

> Released v6.1.0 after around 3 weeks of intense testing. > Though the release is stable, > I released it > and instantly found 2 different bugs related to the UI and the container name length validation in the app's UI, which is meant to reject long container names.

Droidspaces v6.1.0 has been released! 🥳 - New UI for the app - Enhanced security - A lot of bug fixes 105 changes since the last release 🌛 Full changelog and downloads: https://github.com/ravindu644/Droidspaces-OSS/releases/tag/v6.1.0 @Droidspaces

Since we are one step away from the next release, we have to fix the untranslated strings that exist in already translated languages. As the "Get Started" page that appears only on fresh installs has been redesigned, it introduced a few new strings that haven't been translated yet, except for Chinese. So, if someone installs Droidspaces for the first time, the start page would appear fully in English, while the rest appears in their native language. We have to fix this :) Your contribution is appreciated: https://hosted.weblate.org/engage/droidspaces/

The next version of Droidspaces will be released today, only if there are no critical bugs or weird issues you guys are facing in the latest CI build: https://t.me/DroidspacesCI/258?single It's hella stable, with a new UI, Ubuntu 26.04 support, systemd-udevd support without messing up Android, enhanced security, and more!

Refined the Features and Options sections :) Droidspaces container with all the possible features enabled 😁

If you are maintaining a kernel with Droidspaces support, you can now add your kernel to our "Community-supported Android devices" section in the documentation. This list helps users identify second hand phones that work for self hosting as an alternative to buying an expensive Raspberry Pi. By contributing your device details, you provide a clear path for others to flash the correct firmware and turn their hardware into servers. Documentation link: https://github.com/ravindu644/Droidspaces-OSS/blob/main/Documentation/community-supported-devices.md Let's build this resource together to help the community repurpose spare devices for the greater good.

If you are maintaining a kernel with Droidspaces support, you can now add your kernel to our "Community-supported Android devices" section in the documentation. This list helps users identify second hand phones that work for self hosting as an alternative to buying an expensive Raspberry Pi. By contributing your device details, you provide a clear path for others to flash the correct firmware and turn their hardware into servers. Documentation link: https://github.com/ravindu644/Droidspaces-OSS/blob/main/Documentation/community-supported-devices.md Let's build this resource together to help the community repurpose spare devices for the greater good.

DroidSpaces vs. Termux+LXC Duct Tape 🗿 Testing the limits of containerization on a literal potato: Device: Galaxy A16 5G Chipset: MediaTek Dimensity 6100+ The "Duct Tape" Method (Termux + LXC) 🤡 - Setup: 6,999,999 manual changes, cgroup nightmares, and GPG errors. - Boot Time: 732ms (Userspace) - Status: Fragile. White logs. One RAM spike away from being killed by Android. The Native Execution (DroidSpaces) 💪🏽 - Setup: Native integration, zero manual mounting. - Boot Time: 423ms (Userspace) - Nearly 2x FASTER. - Status: Clean Green [ OK ] logs. Running as a persistent system daemon. - Pure Cgroupv2 The numbers don't lie. Even on a budget Dimensity chip, DroidSpaces hits graphical.target in under half a second 🙃

LET HIM COOK #meme

We reached 800 stars today :) I hope we can reach 1K stars this month :) https://github.com/ravindu644/Droidspaces-OSS Thank you so much for your support!

I'm going to deprecate support for XFCE tarballs. Users have the full ability to manually install anything they want. Is this a good choice? Or, you guys can contribute to https://github.com/ravindu644/Droidspaces-rootfs-builder to add support for your favorite distros and desktop environments.