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

Starting from v6.1.0, we stopped masking systemd-udevd and systemd-udev-trigger in post-extract-fixes.sh, and 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.

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.

Edit:

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

Arch Linux Rootfs:

( Kernel 5.10+ only )

https://github.com/Droidspaces/Droidspaces-rootfs-builder/releases/latest

Droidspaces Official rootfs release 🎉

Supported distros:
├── 01. Ubuntu 22.04
│   ├── Minimal
│   └── Base
├── 02. Ubuntu 24.04
│   ├── Minimal
│   ├── Base
│   └── XFCE
├── 03. Debian 13
│   ├── XFCE
│   ├── Minimal
│   └── Base
├── 04. Arch Linux
│   ├── Minimal
│   └── Base
└── 05. Alpine Linux
    ├── Minimal
    └── Base

🟢 Downloads:

https://github.com/Droidspaces/Droidspaces-rootfs-builder/releases/latest

📝 Notes:

XFCE releases do not have built-in Turnip support for compatibility with newer Adreno GPUs.

That means you have to manually install Mesa from https://github.com/lfdevs/mesa-for-android-container

Testing 🎉:

https://t.me/DroidspacesCI/348?single

Added native binfmt_misc support to the official rootfs tarballs

That means, in our official Debian and Ubuntu rootfs tarballs, you can run any binary from foreign architectures like x86_64 natively using QEMU, just as you would run a native binary, even with full hw access !

Currently, this feature is only available in Debian and Ubuntu tarballs. We will expand support to Arch and Alpine in the future if possible.

Testing:

https://github.com/Droidspaces/Droidspaces-rootfs-builder/releases/latest

Kernel requirements:

CONFIG_BINFMT_MISC=y
CONFIG_BINFMT_SCRIPT=y
CONFIG_BINFMT_ELF=y

@Droidspaces