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
What CPU architecture does your Android device use?
If you use Droidspaces, please vote! We need to see if anyone uses 32-bit ARM or x86/x86_64 devices, so we know whether to provide rootfs tarballs for them
If you use Droidspaces, please vote! We need to see if anyone uses 32-bit ARM or x86/x86_64 devices, so we know whether to provide rootfs tarballs for them
Anonymous Poll
97%
aarch64 (Modern 64-bit ARM / Most modern phones)
7%
armhf (Old 32-bit ARM)
6%
x86_64 (64-bit PC or Emulator)
1%
x86 (32-bit PC or Emulator)
β€1π©1
Droidspaces
Photo
Testing:
https://t.me/DroidspacesCI/433?single
rootfs.json:
https://t.me/DroidspacesCI/433?single
rootfs.json:
https://github.com/Droidspaces/linuxcontainers-mirror/raw/refs/heads/main/rootfs.jsonβ€2π©1
The first YouTube video covering Droidspaces is out!
He is even running Android Studio directly on Android πΏ
The video also showcases running Jellyfin, Immich, Docker, Nextcloud, and Home Assistant.
It's incredible to see the community staying by our side, no matter what challenges we face. We are growing! Almost 1K stars π₯³
https://youtu.be/gPUXC-xwyIQ?si=CskAV0DnUf4U-DbI
He is even running Android Studio directly on Android πΏ
The video also showcases running Jellyfin, Immich, Docker, Nextcloud, and Home Assistant.
It's incredible to see the community staying by our side, no matter what challenges we face. We are growing! Almost 1K stars π₯³
https://youtu.be/gPUXC-xwyIQ?si=CskAV0DnUf4U-DbI
YouTube
Droidspaces - Linux DE VERDADE no Android?!
No vΓdeo de hoje vamos conhecer o Droidspaces!
Uma soluΓ§Γ£o incrΓvel pra vocΓͺ rodar distribuiΓ§Γ΅es Linux no Android com alta performance, suporte pra interface grΓ‘fica, acesso total ao hardware etc..., rodando diretamente ao lado do Android, sem precisar deβ¦
Uma soluΓ§Γ£o incrΓvel pra vocΓͺ rodar distribuiΓ§Γ΅es Linux no Android com alta performance, suporte pra interface grΓ‘fica, acesso total ao hardware etc..., rodando diretamente ao lado do Android, sem precisar deβ¦
π₯26πΏ4β€1π©1
Forwarded from ππ»π±πΏπΌπ―πππΈπ²π | Linux & Android (/etc/SyntaxSpin)
DroidSpaces π±
A lightweight, LXC-like container runtime for Android and Linux. Run full Linux distributions natively with zero performance penalty
π: GitHub
π: Preview
π₯: Codebase
π: #Android #Linux #Containers #Kotlin
Join us: @Androbusket π
A lightweight, LXC-like container runtime for Android and Linux. Run full Linux distributions natively with zero performance penalty
βΉοΈ Overview :
- Real native Linux containers on Android with 0 virtualization overhead
- Boot time 150ms to 750ms with full systemd as PID 1, nothing else on Android comes close
- Run systemd, OpenRC, runit, s6, SysVinit, whatever init system you want, natively
- Truly unkillable. Survives 25+ days, immune to Android's battery killers and LMK
- Zero data loss even after app uninstallation, containers and daemons keep running, your data lives in /data/local/Droidspaces, independent of everything
- Starts before any user app, even before you unlock your phone while its encrypted, via native init.rc/service.d integration
- Run Docker, LXC, Podman inside Droidspaces, nested containers work natively on ALL kernels
- Real hardware access out of the box, full udev/systemd-udevd support like a real Linux PC
- Out of the box Qualcomm Turnip/Virgl GPU acceleration and Termux:X11 support, single toggle
- Arch, Alpine, Fedora, Ubuntu, Debian, OpenWRT, you name it, Droidspaces runs it
- Full namespace isolation: PID, MNT, IPC, UTS, Cgroup, completely separate from Android
- NAT/Host/None networking with port forwarding, TCP and UDP, works out of the box, no manual bridge setup
- Volatile/ephemeral containers via OverlayFS, all changes in RAM, gone on exit
- Portable rootfs.img support with loop mount, fsck, and SELinux hardening
- 0 dependencies. The entire runtime is a single ~400KB static musl binary
- Works on kernels as old as 3.10, supports aarch64, armhf, x86_64, x86 and riscv64
- Beautiful Android app to manage unlimited containers with full GUI control
- Custom bind mounts, multi-DNS, per-container cgroup hierarchies, and dozens more features
π: GitHub
π: Preview
π₯: Codebase
π: #Android #Linux #Containers #Kotlin
Join us: @Androbusket π
πΏ7π₯2π©1