Starting from v6.1.0, we stopped masking
this is the exact feature that finally allowed real hardware access.
before this,
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
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.
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.
🗿8❤2💩1
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 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 👍
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 👍
😁14❤1💩1
Arch Linux Rootfs:
( Kernel 5.10+ only )
https://github.com/Droidspaces/Droidspaces-rootfs-builder/releases/latest
( Kernel 5.10+ only )
https://github.com/Droidspaces/Droidspaces-rootfs-builder/releases/latest
🔥6❤1💩1
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!
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!
👍4🔥4🗿3😱2💩1
Added the ability to boot a custom init binary or execute a script, just like Docker does.
This means you can choose
TLDR: A cool hack to sneak into the container without systemd, exactly how Docker works. You can even boot Arch Linux on a potato kernel.
Testing:
https://t.me/DroidspacesCI/337?single
This means you can choose
/bin/bash as the init, start the container, and use it like an isolated pivot_root container without relying on systemd screaming about an old kernel version.TLDR: A cool hack to sneak into the container without systemd, exactly how Docker works. You can even boot Arch Linux on a potato kernel.
Testing:
https://t.me/DroidspacesCI/337?single
🔥5❤1💩1🗿1
Droidspaces Official rootfs release 🎉
🟢 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
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
❤8🔥3💩2
Reliability of Droidspaces containers..!
It's been 16 days since I touched my Galaxy S10.
I just set it up and forgot it. Using my setup every day, including Jellyfin and Gitea.
I think we did something extraordinary for the Linux on Android community..
Like, this is every Linux enthusiast's dream :)
It's been 16 days since I touched my Galaxy S10.
I just set it up and forgot it. Using my setup every day, including Jellyfin and Gitea.
I think we did something extraordinary for the Linux on Android community..
Like, this is every Linux enthusiast's dream :)
🔥16❤5🗿3💩1
Do you guys love this match distro icons for installed containers option I just added?
Supports 22 distros includingFreeBSD
Supports 22 distros including
❤16🤩5💩1
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:
@Droidspaces
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
3❤13🗿2🥰1💩1
Droidspaces now has a CONTRIBUTING.md
If you're planning to submit a PR, read it before you open one.
https://github.com/ravindu644/Droidspaces-OSS/blob/main/CONTRIBUTING.md
Short version:
- Your feature must work on kernel 3.10+. No exceptions.
- Must be tested across multiple SoCs and OEMs, not just your device.
- Android-only code must be guarded with
- Android app changes must not break Android 8.
- If your feature is merged, you own it. If it breaks later and you're gone, it gets removed.
- PRs that solve nothing, add bloat, or ignore these rules get closed. Repeat offenders get blocked.
@Droidspaces
If you're planning to submit a PR, read it before you open one.
https://github.com/ravindu644/Droidspaces-OSS/blob/main/CONTRIBUTING.md
Short version:
- Your feature must work on kernel 3.10+. No exceptions.
- Must be tested across multiple SoCs and OEMs, not just your device.
- Android-only code must be guarded with
is_android(). Linux is a supported target.- Android app changes must not break Android 8.
- If your feature is merged, you own it. If it breaks later and you're gone, it gets removed.
- PRs that solve nothing, add bloat, or ignore these rules get closed. Repeat offenders get blocked.
A feature that doesn't exist is better than a broken implementation.
@Droidspaces
2🗿15💩1