It is extremely flaky on GrapheneOS, at least on my Pixel 8 Pro. Just typing Ctrl-D to exit will corrupt it, requiring a full reinstallation of the Debian VM
The built-in terminal app seems to be similarly flaky on my Pixel 8. Also, the kernel it boots into is really stripped down, and it lacks a ton of essential features. I was not able to install VirtualHere client to pass through USB devices, and there's no built-in functionality. There's also no way to open it full-screen on the Pixel 8's DP-over-USB-C desktop mode. Hopefully it continues to improve, but it seems like Google is more into extracting value than they are improving their products at this point.
Oh wow. I did a very basic test this morning `ping google.com` and then ctrl+c and it seemed to work okay. Not done any more extensive testing than this though.
Could it be that it's just very flaky on all pixel devices? Or maybe something graphene is doing to harden the OS doesn't play nicely with how it's been implemented?
I just tried it on my S25. I can enable the option an open the APK but can't download it because it fails to create the VM because the S25 does not support Non-protected VMs, so I may require a rooted device. I guess I will stick to Termux but interesting feature nonetheless
Termux is doing a container. The android terminal is doing a virtual machine. That's the difference.
Termux would definitely be the light weight option, but you will be pinned to whatever version of the kernel your device is shipped with (may be a bit old.)
No, termux isn't a container, it's running directly in userspace on the host. The only weird thing is that because it's running directly on the host, it has to be built to use unusual paths, eg. /data/data/com.termux/files/usr/bin/bash instead of /usr/bin/bash. If it used containers (which IIRC it can't because Android doesn't really support it) that would actually be easier because then it could use a chroot to make the paths look normal.
Ah, well that stinks a little. I guess it makes sense, if android doesn't mandate a few kernel settings then working with containers might not be an option.
Couldn’t it implement a “fake chroot” by e.g. creating its own libc which wraps the real one but with path remapping, and then linking all its executables against that?
That would only work for things that use libc (so eg. most Go programs are probably not going to work). The main way that you can do an unprivileged fake chroot is proot, which termux does offer - see https://wiki.termux.com/wiki/PRoot - but that has a significant performance hit.
