Interesting, it's indeed this line that fails:

result.code_is(125);

which I added in that PR. But the it should definitely have run the program by that point. So I dug around and found this in the standard library on ExitStatus::code (which is used to get the code used by code_is):

On Unix, this will return None if the process was terminated by a signal.

This suggests that the command was terminated by a signal and hence doesn't have an ExitCode, so I think this uncovered an issue rather than created one. We need to make sure that the command is not terminated prematurely.

Although, I guess that if we can't figure that out we should probably disable this test (or remove the line I added).

Oh, this is expected on Android because of the seccomp filter, which will send a SIGSYS to any process that makes a chroot syscall, terminating it unless explicitly handled. See the "Seccomp restrictions" check box in this relevant comment. The correct solution here would probably be to skip that particular check on Android, or skip the test entirely (chroot should theoretically work in an appropriately configured Android development environment, but that's so rare we decided not to explicitly support it, just not intentionally break it).

Was disabled in #4005, I think this can be closed now.