Two reasons I can think of:

1) security. Container breakouts are much more common than VM breakouts

2) compatibility - the Android kernel is known to be heavily modified and Debian may benefit from being run on a more vanilla kernel as it does on desktop/server

What changes do you think makes the Android kernel heavily modified?

For starters, the microkernel like driver model, where classical Linux drivers are considered legacy, since Android 8 all modern drivers run on their own processes (Java or C++) and talk with the kernel via Android IPC, known as Binderized HAL.

https://source.android.com/docs/core/architecture/hal/archiv...

https://source.android.com/docs/core/architecture/hal

Processes are sandboxed, in which app gets its own user id, everything that Google considers not a public API gets blacklisted, via a mix of LinuxSE and seccomp.

Native executables are not allowed per se on userspace, native code outside system processes has to always be a shared object loaded into the Zygote process fork, which takes the init role on Android. There are ways to launch executables, but they are frowned upon.

https://source.android.com/docs/core/runtime/zygote

Android is quite stright in memory consumption, an application that is seen as misbehaving gets killed without remorses.

For all details, you can go from here https://source.android.com/docs/core/architecture/kernel

Modern distros supports binder too. In the reverse, you can run Waydroid, which is an Android userland under a Wayland distro.

On native executables and such, file and objdump once I installed clang under termux to compile a simple binary tells me otherwise.

I bet you didn't install Termux from the PlayStore.

What matters is how an Android device as bought on a random shop as consumer behaves, not how one can hack around Android and AOSP.

Install it from F-Droid. If you are advanced enough to run Terminal bound software, using PlayStore is not the developers' fault.

It is the developers fault for Termux's architecture not being aligned with Android's app model.

Thus my point is made, should have placed the bet.

TIL that binderfs is a mainline kernel feature now,

Back when I used Waydroid, I had to use an out-of-tree module picked from the Anbox project. I have stopped using Waydroid but good to know that binderfs is a thing!

Containers are native executables (with cgroup rules sprinkled on top). If Android does not let you call exec in the traditional way then you have a problem.

Also you're moving the goalpost with this comment a bit. My original comment says "may benefit from" being run under a "vanilla" kernel, as opposed to saying it would be completely non-functional under Android's kernel.

Try to run a mainline kernel on a phone and let us know how it goes!

It's not the Android part that would get in the way. Assuming the kernel supported the hardware, Android would work.

Presumably because container breakouts are fairly common and "external Linux software downloaded by the user" is at least as presumptively malicious as an app from the store. Modern consumer systems need to be safe vs. the user being tricked to run terrible things. A docker or whatever isn't quite up to the standards[1] required on its own.

[1] Though I'm very much not one of the pedants who refuse to see any security value at all in container isolation. Containers isolate software access (e.g. limiting access to libraries with vulnerabilities) and network communication (writing firewall rules for a container is a lot easier than it is for an app) really well, for example. Use them! But not for this.

Development independence of guest VM from host kernel, security policy, attestation, etc.

If you have to depend on the host kernel, you will likely be stuck on some old kernel fork at some point in your device's life.

You can run whatever kernel you want in a VM, though.