4 ms·

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, ano

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.

pgeorgi 10y ago
> 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).
- digi_owl 10y ago
  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.
  - pgeorgi 10y ago
    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.

pgeorgi 10y ago

> 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).

digi_owl 10y ago
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.
- pgeorgi 10y ago
  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.