Sure, but glibc being bloated doesn't explain why they didn't take working, tested code from glibc and cobble together a stripped-down version instead of starti

Sure, but glibc being bloated doesn't explain why they didn't take working, tested code from glibc and cobble together a stripped-down version instead of starting entirely from scratch. You can absolutely fork a version of glibc that pulls out things like dynamic NSS backends, sunrpc, nscd, etc. even if it won't be accepted upstream, and it'll get you a working libc way faster than writing your own cleanroom libc. (With the important bonus of working with existing software that expects glibc and not just a pure POSIX libc, of which there's quite a bit!) Also, Android isn't "embedded" in the sense you're thinking of: the first Android phone had a 528 MHz ARM processor with DSP coprocessor, 256 MB boot disk + storage on microSD, and 192 MB RAM, which was quite a bit more powerful than e.g. the computer I had in 1995 (75 MHz Pentium, 16 MB RAM, 1 GB disk) that ran Red Hat Linux 6 just fine and definitely far more powerful than the machines glibc was originally developed on. So glibc was certainly not too big for Android. And plenty of "embedded systems" along the lines of Android did / do in fact use glibc, from OpenEmbedded to Emdebian to Maemo. Heck, there was even a project called "embedded glibc" (EGLIBC), which is now the official glibc.