Droidspaces
1.23K subscribers
243 photos
26 videos
31 files
105 links
Download Telegram
Droidspaces
Photo
For clarification, Droidspaces supports two daemon modes:

1. Run the daemon via Magisk/Apatch/KernelSU modules' native post-fs-data.sh. By enabling the toggle in the app, you activate the logic in the post-fs-data.sh of the Droidspaces Magisk module to run the daemon on boot.

For 99% of users, this solves all issues with Magisk and Apatch. No modifications to your vendor.img are needed.

2. Run the daemon via Android's native init.rc:

- This mode is the most privileged and completely independent of Magisk/Apatch/KernelSU. It even works without any root solutions.
- The daemon is unkillable. If something kills it, init will automatically respawn it.
- Run-at-boot containers are unkillable as well. If droidspacesd gets killed, once init restarts it, run-at-boot will also restart all killed containers.

I don't think Android will ever kill the daemon, but even if it does, all edge cases are coveredβ€”thanks to my overthinking πŸ—Ώ

Notes: If the native init daemon is enabled, the app's toggle will be automatically enabled. The post-fs-data.sh script will auto-detect if the native init.rc daemon is running, so no collisions will happen if it is.

Everything is backward compatible. You don't even need to worry about daemons if everything is already working for you πŸ—Ώ

Nothing bad will happen; the binary still supports running everything natively, with or without a daemon πŸ—£

There are three different logics baked into the same binary:

- Daemon
- Client for the daemon
- Native execution if no daemon is running
πŸ—Ώ5πŸ’©1
In the latest CI build, we are moving from the magisk SELinux domain in Magisk/Apatch to our own droidspacesd domain to maintain compatibility with daemon mode in post-fs-data.sh

That means even if the binary is run under Magisk’s SELinux domain, we re-execute ourselves to run under our own SELinux domain, completely bypassing magisk domain restrictions.

We also have over ~200 lines of custom SELinux rules, specifically written for magiskpolicy, which we inject via post-fs-data.sh :)

https://github.com/ravindu644/Droidspaces-OSS/blob/main/Android/app/src/main/assets/boot-module/etc/droidspaces.te

TL;DR: we have our own permissive SELinux domain, completely independent from Magisk/APatch/KernelSU domains, giving us more freedom.

Also, all processes spawn under our droidspacesd domain. Even systemd inherits our permissive domain, meaning no denials can occur.

TL;DR: you can use Droidspaces in SELinux enforcing mode with 0 issues when using the boot-module daemon mode. No need to wire up an init.rc service.

This is the build:
https://github.com/ravindu644/Droidspaces-OSS/actions/runs/23706897589/artifacts/6165166335

According to my testing across 3 phones, everything seems normal for me.

But I suggest you guys test it and report if there are any issues. Especially, I recommend testers to drop a bug report even if there are no issues present, so I can cover all the edge cases.

Here's how:

1. Install
2. Enable daemon mode from settings
3. Reboot the device
4. Generate the bug report and drop it in the chat.
πŸ’©1
Get the latest updates as soon as they’re pushed to my GitHub!

@DroidspacesCI
❀1πŸ’©1
This media is not supported in your browser
VIEW IN TELEGRAM
Easy Termux-X11 with Droidspaces!

Requirements:

Container: sudo apt install mesa-utils
Termux: pkg install x11-repo && pkg install termux-x11

Steps:

01. Open Droidspaces, go to the container configuration menu, enable Termux-X11, and set the DISPLAY=:0 environment variable, then save the configuration.

02. Start the container.

03. Open the Termux app and type termux-x11 :0.

Now, any tool that requires a GUI can communicate with Termux-X11 for rendering, and the output will be displayed in the Termux-X11 app :)

Notes: :0 is the display number.

@Droidspaces
πŸ”₯5❀1πŸ’©1
cooking a tarball builder, specifically optimized for android :)
πŸ—Ώ3❀2⚑1πŸ’©1
Native GPU Acceleration tarball working in Qcom devices πŸ₯³

https://github.com/ravindu644/Droidspaces-rootfs-builder/releases/tag/v20260401-084954

How to use:

1. Download and install the tarball (GUI/base) with HW Access + Termux X11

2. Go to termux and type termux-x11 :0 to start the X server

3. Done !
πŸ—Ώ3❀1πŸ’©1
Get native GPU acceleration on Adreno GPUs with Droidspaces..!

Requirements: Base/XFCE tarball from the latest GitHub release, Latest CI Build

01. Download the latest Base/XFCE tarball from the Droidspaces-rootfs-builder repository.

02. Install it using the Droidspaces app by enabling "Hardware Access" and "Termux X11", and add the environment variable DISPLAY=:0 in the environment variables section.

03. Start the container, then open the Termux app AFTER starting the container and run termux-x11 :0 to start the X server.

04. Done!

Additional: Using GPU acceleration with non-root users

05. Open a container root terminal and create a new user: newuser <username>

06. Add the newly created user to the sudo group: usermod -aG sudo <username>

07. Add the newly created user to the droidspaces-gpu group: usermod -aG droidspaces-gpu <username>

08. Log in to your new user and check GPU access with: glxinfo -B!

To start the XFCE in the XFCE tarballs: dbus-launch --exit-with-session startxfce4

@Droidspaces
πŸ”₯3πŸ’©1πŸ—Ώ1
Documentation update:

Added native init.rc integration for Developers: https://github.com/ravindu644/Droidspaces-OSS/tree/main/init

Added 3 ways of using GPU Acceleration in Android, as well as documented about GPU Acceleration in Linux:

https://github.com/ravindu644/Droidspaces-OSS/blob/main/Documentation/GPU-Acceleration.md
πŸ’©1
I'm taking a temporary break from all my development work.

I'll release v5.9.0 today.

You won't hear from me on Telegram anymore. Any project-related questions should be directed to the admins in the discussion group.

I'll be back in a few months.
🀣6😁1πŸ’©1
Droidspaces v5.9.0 has been released..! πŸ₯³

In this release,

we introduced a daemon, that supports two daemon modes: Native init.rc (lowest-level integration with auto-spawn/unkillable persistence) and Userspace Daemon (app-togglable, starts via post-fs-data.sh, no image modification required). Both modes bypass root-domain seccomp blocks to ensure stable container lifecycles.

Thanks to daemon mode, Magisk/APatch users can now use DroidSpaces without any issues!

Also fixed a lot of issues related to the Android app, including the built-in terminal, container configuration menu, etc.


Full changelog and release: https://github.com/ravindu644/Droidspaces-OSS/releases/tag/v5.9.0

Note: I'm actually taking a break from this. I'm planning to wipe out my entire development rig tonight. The app is stable now. Will continue cooking after some time. Peace.. :)

https://github.com/ravindu644/Droidspaces-OSS/discussions/27

@Droidspaces x @ravindu ❀️
πŸ”₯2πŸ’©1
Now, suggest a way to charge this thing πŸ˜„

My plan is to use another USB 3 adapter that has a Type-C port for power input, while plugging the UGREEN adapter into it.

The issue is that my existing adapter capable of doing that only has USB-A ports for inputs.

I'll have to buy a USB-C to USB-A adapter to plug in the UGREEN hub.

This is going to be some kind of human-centipede type of thing πŸ—Ώ
πŸ’©1
Droidspaces is now on Weblate!

You can now help translate the Droidspaces Android app into your language - no coding skills required.
https://hosted.weblate.org/engage/droidspaces/

Just pick your language and start translating. Every contribution helps make Droidspaces accessible to more people around the world
❀9πŸ₯°1πŸ’©1
This is fire πŸ”₯
πŸ”₯7❀1πŸ’©1
Added a new toggle to mirror GPU nodes, even without the hardware access mode.

There is no need to add bind mounts.

So, users don't have to worry about ruining the isolation by enabling hardware access just to use the GPU :)

A single toggle, and you're good to go πŸ—Ώ
πŸ—Ώ5πŸ’©1
New option for OverlayFS users 🀑

explanation
πŸ—Ώ3πŸ’©1
Droidspaces
New option for OverlayFS users 🀑 explanation
For more context: when installing the backend, we don't create the symlink by default. The user has the complete ability to control the symlink via a toggle.

This is my best solution for a problem that the overlayfs developers don't want to fix πŸ‘πŸΌ

IF you are a power user AND use magic mount, use this toggle to use Droidspaces with the droidspaces command from adb shell/root shells.

IF you are an overlayfs user, don't even enable this toggle.

Both users still have full backend access via /data/local/Droidspaces/bin/droidspaces though.

Testing: https://t.me/DroidspacesCI/83
πŸ’©1πŸ—Ώ1