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 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

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 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

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

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.

Built-in rootfs downloader 👀

Tap -> Tap -> Install 🗿

Testing:

https://t.me/DroidspacesCI/419