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
Kid: Can we have Azure?
Mom: We have Azure at home.
Azure at home:
Mom: We have Azure at home.
Azure at home:
πΏ16π5β€1π1π―1
Droidspaces v6.2.0 has been released! π₯³
What's new?
and misc. UI improvements and bug fixes.
Full Changelog and Downloads:
https://github.com/ravindu644/Droidspaces-OSS/releases/tag/v6.2.0
@Droidspaces
What's new?
- Added resource virtualization support. This means you'll see a unique uptime and loadavg for your container with this update. For example, fastfetch will now show the correct container uptime instead of the host's!
- Added support for limiting CPU, RAM, and PIDs (CLI only)
- Added custom init support
- app: added custom icons for 23 popular Linux distributions in containers and the panel tab
- backend: fixed a race condition that randomly nuked container.config
and misc. UI improvements and bug fixes.
Full Changelog and Downloads:
https://github.com/ravindu644/Droidspaces-OSS/releases/tag/v6.2.0
@Droidspaces
4π₯15πΏ2β€1π1π©1
Droidspaces
Droidspaces v6.2.0 has been released! π₯³ What's new? - Added resource virtualization support. This means you'll see a unique uptime and loadavg for your container with this update. For example, fastfetch will now show the correct container uptime insteadβ¦
Re-uploaded due to a minor cosmetic UI bug that only happened when the stars aligned, but I could not let it live:
https://github.com/ravindu644/Droidspaces-OSS/releases/tag/v6.2.0
https://github.com/ravindu644/Droidspaces-OSS/releases/tag/v6.2.0
1π8β€1π₯1π©1
This is just an announcement for people who use 69 different root-hiding modules and 1 billion root detectors to hide root.
Root, then install 1 billion pieces of duct tape on top of it to hide what you did, just to use 1 root tool?
If you know me, I'm strongly against root hiding, including susfs and others. In our official README, we clearly state we do not support susfs.
It's not because I have a beef with the developer; it's because these types of hiding mechanisms affect the user experience of our project.
For example, if networking in Droidspaces is dead because /proc is being hidden, or if loop mounting the rootfs.img image fails, people are going to point the blame at Droidspaces, not at the duct tape they are using.
I did my very best to hide the mounts from the Android userspace of a Droidspaces container. Android won't see the internal mounts of a container because it lives inside a private mount namespace. I did my part.
To maintain maximum compatibility for the project, I highly recommend you do not use any kind of root hiding embedded into the kernel itself or userspace, as it will affect the functionality of Droidspaces.
Also, you are the one who chose Droidspaces. Droidspaces is not a tool for non-technical people. You gotta know what you are doing. The project is made by enthusiasts for enthusiasts, to unlock the true potential of their silicon.
That means you can't have it both ways. You have two choices: "pleasure" your root detectors, or just accept the consequences. Accept that problems exist cuz Google is evil, be like Bob, and use Droidspaces.
From now on, it's a hard requirement for any type of bug report opened in the repo. If a user is caught using any kind of root hiding that affects the functionality of Droidspaces, the issue will be closed immediately.
The entire point is, Droidspaces was never meant to babysit people who insist on using "Banking apps" at all.
We don't care if your detector detects something related to Droidspaces.
This might hurt some feelings, but this is the raw truth from the project's perspective.
Do LXC or Docker hide themselves from userspace to enter full stealth mode? They don't even care.
Thank you.
Root, then install 1 billion pieces of duct tape on top of it to hide what you did, just to use 1 root tool?
If you know me, I'm strongly against root hiding, including susfs and others. In our official README, we clearly state we do not support susfs.
It's not because I have a beef with the developer; it's because these types of hiding mechanisms affect the user experience of our project.
For example, if networking in Droidspaces is dead because /proc is being hidden, or if loop mounting the rootfs.img image fails, people are going to point the blame at Droidspaces, not at the duct tape they are using.
I did my very best to hide the mounts from the Android userspace of a Droidspaces container. Android won't see the internal mounts of a container because it lives inside a private mount namespace. I did my part.
To maintain maximum compatibility for the project, I highly recommend you do not use any kind of root hiding embedded into the kernel itself or userspace, as it will affect the functionality of Droidspaces.
Also, you are the one who chose Droidspaces. Droidspaces is not a tool for non-technical people. You gotta know what you are doing. The project is made by enthusiasts for enthusiasts, to unlock the true potential of their silicon.
That means you can't have it both ways. You have two choices: "pleasure" your root detectors, or just accept the consequences. Accept that problems exist cuz Google is evil, be like Bob, and use Droidspaces.
From now on, it's a hard requirement for any type of bug report opened in the repo. If a user is caught using any kind of root hiding that affects the functionality of Droidspaces, the issue will be closed immediately.
The entire point is, Droidspaces was never meant to babysit people who insist on using "Banking apps" at all.
We don't care if your detector detects something related to Droidspaces.
This might hurt some feelings, but this is the raw truth from the project's perspective.
Do LXC or Docker hide themselves from userspace to enter full stealth mode? They don't even care.
Thank you.
β€25πΏ8π₯5π©2
This media is not supported in your browser
VIEW IN TELEGRAM
Built-in rootfs downloader π
Tap -> Tap -> Install πΏ
Tap -> Tap -> Install πΏ
β€11πΏ9π₯3π2π1
Droidspaces
Built-in rootfs downloader π Tap -> Tap -> Install πΏ
How's now π?
2π₯10π3π1π©1πΏ1