Not true, actually. See https://www.jwz.org/xscreensaver/toolkits.html ... (I'm assuming this hasn't changed, of course, as this was written over 10 years ago... but the fundamental reasons why he was unable to write the dialog as a separate process should still remain, since they're fairly well-known and not-particuarly-surmountable issues with X.)

The password input screen uses only low-level X11 calls (and not a higher-level GUI toolkit) in an attempt to reduce the library dependency list and therefore the possibility of crasher bugs. But if you do indeed manage to find a crash bug in libX11 (or a dep) that you can trigger from xscreensaver's password entry box, that will indeed unlock the screen.

Now, the xscreensaver configuration panel is written using GTK, which is indeed a separate process, and a crash in the config panel won't affect the screen locker.

Oh, I don't remember that page, I must have missed it.

Still, Android doesn't run X, and since they control the whole OS, it shouldn't be too hard to avoid having input "pass through" the lock screen.