This became so common that "An update on ${employee_name}" was a humorous way inside Google to announce one's departure. Or to joke about it when merely switching teams.
Searching for ["an update on" Google] and ignoring other sites gives results such as
While the discontinued product that is still most commonly brought up, Reader, had a quite different headline, probably because that day was a carnage:
I used "an update on" for everything. If I was sick, it was "an update on jrockway". If I released a new version of something, it was "an update on foo". The fact that "an update on" guaranteed dread made it humorous in both contexts.
I am sure that the author of any google blog post that is titled "an update on..." is poking a little fun at google. Or maybe they don't get the joke and this is the wording that keeps coming up. I'm guessing it's the first one, though.
I used to work at Google on search, among other projects. :-) I left it out because there's also blog.google now and there isn't a consistent choice of canonical URLs. It's not merely a hostname change, because the new Reader link is https://blog.google/inside-google/company-announcements/a-se...
An even more focused search would be [intitle:"an update on"], which is pretty effective, and you can see different results depending on which site you restrict the query to.
Ah, so what we really need are Boolean operators for multiple URL rules.
On the handy operators note, do you still know people on the Search team, and could you ask them to give us + back now that Google Plus is shutting down?
I work in this sector. Google has been having a lot of internal problems. They are turning into Microsoft under Steve Ballmer. Disjointed product teams, not capable of innovation, hiring the wrong people. Internal fighting.
Bad or mediocre leadership. More "Stewardship" than "Leadership." You get ongoing cultural decay in that world.
Lots of teams duplicate doing the same things. Google Cloud is likely the "chosen" team right now. That means they get their way. You can see the obvious conflict between the Android Team and Cloud Team pursuing IoT and AI at the same time.
Classic big company internal politics. Looks like Google Cloud is winning the fight here, not that Android Things was going anywhere.
The key phrase here is: "Therefore, support for production System on Modules (SoMs) based on NXP, Qualcomm, and MediaTek hardware will not be made available through the public developer platform at this time."
Translation: They are cancelling major key parts of their IoT story. They had put into place relationships for 5+ years to guarantee software support for long lifecycle of certain hardware SoCs for industrial and other purposes.
This is super embarrassing and the language could not be more carefully designed to obfuscate what is happening. I bet they had to draw straws to write this.
I'm a VP for a software consultancy focused on IoT: I'm not surprised it wasn't a success. I give them props for trying to leverage Android for IoT, but in the end I think it was a poor fit:
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:
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...
Oh god, I hadn't heard of Android Things before this article, and I do some hobbyist IoT work. Writing that sort of hardware stuff in Java with the Android SDK looks downright depressing. I'm not surprised either.
I've enjoyed using Espressif's esp-idf project, though I wish Rust could target Xtensa processors. mbed looks nice as well!
Hilariously if you want to actually use Android Things on anything besides their supported hardware you'd still have to write all the low-level code to make it work, plus the Java code to make it work in Android.
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.
There are a couple of embedded domains using Java, mostly from MicroEJ, PTC, Aicas, IBM.
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.
To be even fairer : it seems that the goal was to allow the
sizeable Android dev community to reuse some of the APIs they already know in the context of 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.
I think many people aren't aware of the comm ecosystems such as ZigBee which let you build very low cost devices that don't need to have Linux, an internet stack, CPU with MMU, etc.
They might call it "the internet of things" but often other protocols are involved.
Success for OEMs vs success for individual consumers/developers mean different product strategies. Focusing efforts on a limited set of popular consumer boards seems like a better use of resources. I bet OEMs have their own private channels to get custom system images for their own hardware.
Not hugely surprising. As I recall it was originally a C++ system, Which vaguely made sense but was an arse to actually develop with. Then they totally scrapped it and moved to Java which is an insane decision for an embedded system.
I suppose the fundamental issue is that embedded systems are massively cost constrained, so they're always going to use custom hardware, and that hardware is going to vary a lot. Smart scales can get away with an M3 microcontroller, whereas a smart CCTV camera is going to need a proper SoC with lots of RAM, some kind of DSP etc. Good luck making an OS that works on both of those.
Not sure what you're trying to say here - Android Things was always targeted at relatively powerful devices. Things where people right now use stripped down tablets or massacre AOSP Android to make it do things like power a touchscreen kiosk device. It was never really capable of working on a smart scale or CCTV camera type thing - it was always a best fit for a phone-like hardware powering a display.
And it is a decently nice platform to work with for those use-cases - certanly better than most of the others. It has almost all Android APIs available.
