the Android sandbox is basically a user id sandbox: every app in the system runs as a different user id, and that way the OS can control what different apps have access to. However, each user id still has access to a lot of system resources (file system, networking) if given permissions.
The Chrome sandbox denies
all access to the file system and networking. The only thing the app and the renderer process in which the app is running can do is to ask for resources to the Chrome browser process even
if the app has those permissions.
That way, if the Chrome app manages to exploit a bug in Chrome and execute code in the renderer process, it still has to ask the browser process for any resource, or find another bug to break out of the sandbox.
Moreover, Chrome implements another
layer of sandboxing that restricts what procesess can call in the kernel. This is the Seccomp-BPF sandbox, and basically guarantees that even if malicious code is executing in the renderer, it cannot call crazy kernel functions that might allow it to locally escalate privileges (to the root user, for example).
The kernel includes a huge amount of code, so you need to restrict that as well in a sandboxed process.
Notice that I haven't even discussed Verified Boot in Chrome OS, which guarantees that your system is always free from malware.