NIH barely applies here at all. If we take into account the constraints they were under and the absolute state of desktop Linux when Android started, it makes total sense.

Starting a lot of the components as greenfield projects will fortunately help a ton with shedding years and years of legacy cludge, hacks and desktop first design. Without mentioning the colossal amount of friction they would've faced if they tried to upstream any of the code they would've produced by the end. "We don't care about that issue. Closing."

Because of the above, they still would've needed to have their own fork regardless and still would've eventually diverged further and further -- so why bother? With a greenfield project, you can just optimize to your specific constraints. If the maintenance becomes too burdensome, just pick up the best of your design and reimplement them onto the non-greenfield project, everyone wins :D

I don't think it's NIH so much as the glibc ABI is a broad surface of implementation specific choices outside the C standard, and a moving target. It's an emergent property of many small implementation choices that another libc project would find too difficult to replicate.

I had a recent experience fighting this sort of thing when I wanted to cross-compile from a distro using glibc to a distro using musl.

Glibc is also kind of bloated and it's reasonable that android or a similar embedded project would not want to pull the whole thing in. Especially when you consider the original goal of bionic was just to bootstrap Java code, which was meant to be the primary platform interface rather than C, they would want a very minimalist libc for that purpose.

SurfaceFlinger is not NIH. When Android was being never Wayland was barely a thing and Xorg is inappropriate for embedded.