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.

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/260?single

It's hella stable, with a new UI, Ubuntu 26.04 support, systemd-udevd support without messing up Android, enhanced security, and more!

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/

> 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.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