I guess it will be built around the system they use for ChromeOS and also introduced with Android 7. Meaning that you have two OS partitions. One is active, another on standby. When a update gets pushed it gets written to the standby partition. Then on the next reboot, the two partitions switch roles. If the new and updated partition fails to boot, then it falls back to the old one. If not the old one enters standby and will be overwritten when the next update gets pushed.

Thing is though that on ChromeOS, there is a core part that never gets updated. This is why only certain newer Chromebooks could get Android app support. Because the way they implemented it required a minimum Linux kernel version.

And over on the Android side you still have the issue of OEM and carrier meddling in the update process.

So i fear that this platform will be beset with similar issues once it starts to spread beyond the realm of enthusiast dev boards.

> Thing is though that on ChromeOS, there is a core part that never gets updated. This is why only certain newer Chromebooks could get Android app support. Because the way they implemented it required a minimum Linux kernel version.

It's possible to update kernels in ChromeOS (there are A/B partitions for them just like for pretty much everything else). The main question is how much effort should be invested in bringing "ancient" (in computer time) SoCs up to speed to support a use case (Android) they might not be powerful enough for (both CPU speed and memory availability).

My impression was that it was more a case of drivers (much like with getting older Android devices updated to recent Android) than the hardware capabilities themselves.

After all, the SoCs in use are much the same ones that are powering said Android devices already. The overhead of the ChromeOS addition should be minimal.

A configuration with a 3 year old SoC, lower end RAM setup and a very small disk (because Chrome OS is supposed to be stateless, unlike Android) might not provide a good environment to run Android in, especially if there's some overhead in having two display managers around that need to be coordinated.

Also, there might be additional requirements for the GPU - all that map-Android-display-to-Wayland stuff that is used to get Android output into Chrome OS windows requires a bunch of capabilities that aren't necessarily efficiently implemented on older SoCs. Rendering to offscreen buffers is a feature that GPU designers provided and improved bit-by-bit and only with lots of market pressure.

A couple hundred hours of work to bring the kernel forward (and test that it doesn't introduce regressions) for a feature that will only frustrate users (because it's there, just not practically usable) may not be a good investment.

This seems like a security vulnerability, especially when running up against a state actor who can demand you receive a specific update.

That is true but the risk of backdoored updates by state actors is a reasonable price to pay for security fixes to avoid every device being a node on a script kiddie enormous bothnet, or a WiFi ingress point, IMO. If the software is broken and not updated, a state actor can hack it anyway.

I believe if you want to avoid state actors, android and smartphones are not for you. This is sad reality. I don't know the alternative.

With this model at least you're not part of botnet for sale, so that's a good thing.

If you want to avoid state actors you have to live the lifestyle of Stalman or something similar.

Meanwhile security researchers publish security exploits against your now outdated device. Damned if you do, damned if you don't [upgrade] it seems.

So all of my network-aware things are now going to have an excuse to demand internet connectivity so they can dial Google on a regular basis? I'm not sure that's worth the tradeoff.

What exactly did you think the "I" in IOT stood for? Also, like Android there's no need to use Google services. Just patch it and update it yourself if you're so inclined.

I was kind of hoping it meant "internet" in the sense of "I can connect to and control the device from my phone", not "the device will be sending data to its manufacturer". Hopelessly naive, I know.

Last time I checked using Google Services was still an option when using an Android phone.

That is Intranet of Things, IoT's lesser known cousin.

Personally, I want "I" in IoT to stand for Intranet.

Local network connected devices that can be reached over the Internet if desired. You know, like PCs.

If they're using Weave they are going to need internet connectivity anyway.