Well, that reasoning seems absolutely contrary to what you would do if Android Things was a success.
1. Most IoT devices are still based on smaller MCUs, not Linux. FreeRTOS and systems like it are where the majority of vendors go.
2. The smaller (but still sizable) market for embedded linux don't naturally gravitate to Java.
3. It was a subpar developer experience, IMHO. For example, see this link for a "Blinky" app, which is a sort of like the "hello world" for embedded:
https://medium.com/@monkeytypewritr/android-things-getting-t...
To put that in context, here's a blinky app in mbed, which is C++ based:
https://github.com/ARMmbed/mbed-os-example-blinky/blob/maste...
To be far: It's apples and oranges comparison (Mbed is for bare metal), but it gives you a taste for the amount of boilerplate Android Things required.
Now, if one of the major vendors invested in Rust? That would be interesting...
I've enjoyed using Espressif's esp-idf project, though I wish Rust could target Xtensa processors. mbed looks nice as well!
I hadn't heard of it before either and I'm pretty sure I work in their target market, but that's because they're doubling or tripling the amount of work I have to do to get something working relative to Embedded Linux.
The big difference is that they are actually tailored for embedded development, with standard Java, real time support and not phone APIs trying to fit somewhere.
Additionally the NDK experience is relatively bad, forcing devs to download and manually compile NDK libraries, that are part of the SDK for Java, e.g. userspace drivers.
Finally, using something like yoctos + whatever language is still more flexible.
I never really understood the pivot from Brillo into Android Things.
I am not saying that it makes a lot of sense .. I am an Android Engineer myself and the amount of boilerplate for that blinky sample makes me vomit but that's how it is.
They might call it "the internet of things" but often other protocols are involved.