Testing all 74 possible combinations of scenarios

Droidspaces final demonstration !

This is where the frontend is properly communicating with the backend 👀

All of this is just 12MB, with multi-architecture support (both frontend and backend: aarch64, armhf, x86, x86_64) 🗿,

with a fully functional systemd manager for Android! (World’s first time?) 🟢

This kind of thing has never been done by anyone, and it is totally unique to our work, which we achieved after spending over a month on research.

That means we won't open source everything,

but we will provide some documentation about how the backend works,

and provide you with a simple set of example code to show how to achieve something like this.

I hope you guys understand this situation from the perspective of just a single developer :)

Test APK if anyone wants to test (I haven't added the requirement checks for the kernel features yet):

https://news.1rj.ru/str/Samsung_Tweaks/97028

These are the only things that need to be enabled to make this project work:

# IPC mechanisms
CONFIG_SYSVIPC=y

# Namespaces support
CONFIG_NAMESPACES=y
CONFIG_PID_NS=y
CONFIG_UTS_NS=y
CONFIG_MNT_NS=y
CONFIG_IPC_NS=y

# devtmpfs for hw access
CONFIG_DEVTMPFS=y

# Cgroup devices for systemd
CONFIG_CGROUPS=y
CONFIG_CGROUP_DEVICE=y

Droidspaces - pre-release #6

Supported architecture: universal
Demonstration: here

🪵 Changelog:

- Improved the console width on high DPI screens
- Fixed Android file picker when selecting files from the Recent tab when installing a tarball
- Added a post-fix noscript to tell systemd to mask the udev trigger service, which resets the permissions of the hardware and leads to bugs when the container is started
- Enabled systemd-resolved and systemd-networkd in systemd-supported containers to auto-detect network changes

Get containers from: https://images.linuxcontainers.org/images/

❤️ Note:

1. Kernel support is required to start a container: click here
2. On kernels below 5.10, you won’t be able to run modern containers like Arch, Fedora, or openSUSE because newer systemd requires a newer kernel

@SamsungTweaks

I want to talk about the situation of DroidSpaces support on GKI kernels (Kernel 5.4 and up on Android)

It is theoretically possible to add support for GKI devices, like my 5.15.167 kernel for the Galaxy A16 5G, where I added support for Docker, LXC, and DroidSpaces.

Forget about LXC and Docker for a bit.

To make DroidSpaces even run, we only need to enable 6 configs:

- PID namespaces
- UTS NS
- IPC NS & SYS V IPC
- devtmpfs support
- cgroup devices support

Even though it looks simple, enabling those configs alone makes the device unbootable.

Why?

In GKI devices, the core kernel and drivers are separated.

The kernel lives inside the boot partition, while the drivers live across partitions like vendor_boot, vendor_dlkm, system_dlkm, etc.

By compiling the kernel with these 6 configs enabled, we only modify the boot partition. The other partitions like vendor_boot and vendor_dlkm still contain the stock modules (LKMs) from the OEM.

Enabling something big like cgroup devices support breaks the kernel’s ABI. Because of that, the kernel cannot load the stock kernel modules provided by the OEM (exec format errors due to ABI mismatch), leading to a completely unbootable device.

But don’t worry, there’s a fix.

You must properly wire up the loadable kernel modules built during the kernel compilation into the device’s driver partitions such as vendor_boot and vendor_dlkm. But this isn’t an easy task.

Why?

- Most GKI kernels lack proprietary drivers that the OEM doesn’t want to share 🤡

- Even if those modules exist as out-of-tree drivers, the build system usually refuses to build them, leading to missing drivers in the final staging directory.

On my device, the build system compiled almost every ~600 module except Wi-Fi and Bluetooth.

I spent over 7 days wiring them up properly into the kernel root and reverse engineering what variables I needed to export during build to generate binaries for my exact hardware. It was painful, but I eventually figured it out.

That’s how I made a fully functional kernel with an automated build system that compiles boot, vendor_boot, and vendor_dlkm partitions and packages them together. The final result: no matter what you enable - it just boots ™️

My device is MTK.

But on Qualcomm devices, which most users have, the kernel source code is pure chaos.

There are two kernel roots: one for building the kernel image and another for compiling Qualcomm-specific drivers.

Most of the time, many out-of-tree drivers don’t even compile due to build errors, like WLAN.

Often, critical drivers like msm_video or msm_drm aren’t built at all, and Qualcomm basically says, “yeah, figure it out and wire the driver yourself” 🖕

On my Galaxy M14 4G, which is Qualcomm-based with a 5.15.167 kernel:

The build system doesn’t compile 19 drivers!

That makes adding DroidSpaces support like 10× harder (easily 15–30 days of work).

It already took me a week to get my MTK kernel working.

Why would I waste time wiring up 19 missing kernel modules?

Not impossible - but not worth the time and the brain cells.

This means DroidSpaces is mostly limited to legacy non-GKI devices (Kernel 4.19 or lower). You simply enable the configs and it “just boots” 🗿

But on GKI?

You must go through a ton of pain, and we don’t even know what surprises come at the end. Even one missing driver = we’re screwed.

I’m saying all this after messing around with my own GKI devices.

If someone *really* wants to implement support for GKI kernels, please refer to my A16 5G kernel for inspiration, and use my LKM Tools repo to wire up LKMs across vendor_boot, vendor_dlkm, and system_dlkm partitions:

https://github.com/ravindu644/android_kernel_a166p

https://github.com/ravindu644/LKM_Tools

This is Google’s way of making Android freedom 100× worse..

So yeah…

Even if someone gave me $1000 and told me to compile a GKI kernel with DroidSpaces/Docker/LXC support, I still wouldn’t do it. The situation is too unpredictable, and my health is more important than wasting time on something where the final result isn’t even guaranteed.

Droidspaces - Stable v2.7.1

Supported architecture: universal
Demonstration: here

🪵 Changelog:

- Backend: Fix isolation issues by mounting sysfs as read-only when the --hw-access flag is not specified, preventing any process from interfering with the device’s real hardware.

- Backend: Mount essential sysfs paths as read-write for networking applications such as Tailscale, WireGuard, SSH, etc.

- Manager: Added an option to display kernel requirements and check them in real time.

Get containers from: https://images.linuxcontainers.org/images/

❤️ Note:

1. Kernel support is required to start a container. Check it from the manager settings
2. On kernels below 5.10, you won’t be able to run modern containers like Arch, Fedora, or openSUSE because newer systemd requires a newer kernel

@SamsungTweaks | @ravindu644

#droidspaces

If you want to translate the app into your own language, here are the required files:

https://github.com/ravindu644/Droidspaces-Locales

Please read the README carefully and apply your translations accordingly,

before I vanish from development & Telegram for ~1 year after December 31 :)

❤️