I'm glad they'll be focusing on a single OS across more devices, but I'm very concerned there will be no workaround for installing "untrusted" apps. Without ultimate user control of the device, they'll just be ad/influence appliances.
That's definitely where things are heading I think. All of Google's changes point to getting ready for this.
The big tech companies are boiling the frog, trying to get us used to Linux just being an "app" we run on our licensed, not managed by us devices.
Google will point to the linux terminal app on Android and go "see, it's OK that we're making these sideloading changes - you can just run Linux (in a VM, on a device you don't have root on). WSL also gets us used to the idea that Linux is just an app.
Get ready for people to not see between the lines, adopt it, and then the rug will get pulled. We'll see hardware OEMs that lock boot loaders, no more alternative OS for you, or if you do manage to install another OS, you won't get to access any internet services because you won't pass the device attestation checks.
Yes. There is a potential future a year or two from now where your system will be required to prove firmware-upward that it is unmodified, and that you're licensed (and perhaps over-18 too), to access a huge percentage of websites.
All it will take is Cloudflare et al. offering it as a free option for every CDN customer and who wouldn't turn it on? Especially if the alternative is having to handle ID verification yourself, right?
Brazil already has a law on the books requiring online services and "terminal operating systems" to do age verification in a government approved manner.
Qualcomm Arm PCs support hardware nested virtualization for pKVM L0 and KVM L1 hypervisor, similar to Pixel devices. This could enable Debian Linux in a VM, currently available on Pixel as "Linux Terminal" for developers, with all Debian Arm packages and root access in the VM.
I really miss the days where companies sold tools and consumers could use them in flexible and creative ways that would never have been considered by the manufacturer.
Same, but companies discovered they could make more money by rent seeking instead. Blame growth culture. It wasn't enough to have a sustainable business, it must grow rapidly with a clear exit, either IPO or acquisition.
Example, the way NDK is supposed to be used on Android, as means to implement native methods for Java/Kotlin, or plain games, with a specific list of supported APIs and nothing else.
Anything outside of what is allowed, may work or crash and burn.
If you can adb unlock, and it's not a closed box, then people can run F-Droid and install apps. Which means they can run independent path code without "sideload" in the apk download-and-install-by-hand sense. I guess for google, F-Droid IS sideloading.
If you unlock and you cannot run google wallet or your banking app, it's a closed box and the EU anti-monopoly lawsuit may still apply on this. But, if they can make a "trust" story run about LEA access to lawful decode or something, this might go away.
I'd say that the projections about fuschia and the like have turned out to be less interesting than some people hoped: but having two OS in the public eye (3 or more if you include Android TV and whatever closed systems run on Nest and Chromecast) was always a mistake.
I can live inside termux but there are things termux struggles to do, (like tcpdump maybe? and interacting simply with data downloaded from outside termux because of sandbox rules), which I very much would want.
I do not like how Android interacts with removable storage. It's an anti-pattern.
Anything that termux manages to do outside of that list is more out of sheer luck that Android team hasn't closed down that specific Linux syscall.
Initially Android only got the NDK back in Android 2.0, due to pressure from game developers, and Dalvik having such a lame performance, it was never for writing full applications.
I love termux, but it's really not a replacement for full fat linux. There's tio many incompatibilities with how linux software expects to run for it to work for a dev workflow (unless your workflow is to immediately ssh into something else).
The most compatible setup I found is proot-distro into alpine, which bypasses a lot of the android blockers, and the bionic-libc incompatibilities by using musl. Comes at a performance cost, however.
I think in general their plans are contrary to the DMA if they prevent F-Droid from existing. The big bet seems to be that Trump can coerce the EU into repealing the law entirely.
> (50) [...] In order to ensure that third-party software applications or software application stores do not endanger the integrity of the hardware or operating system provided by the gatekeeper, it should be possible for the gatekeeper concerned to implement proportionate technical or contractual measures to achieve that goal if the gatekeeper demonstrates that such measures are necessary and justified and that there are no less-restrictive means to safeguard the integrity of the hardware or operating system.
> (54) Gatekeepers can hamper the ability of end users to access online content and services, including software applications. Therefore, rules should be established to ensure that the rights of end users to access an open internet are not compromised by the conduct of gatekeepers. Gatekeepers can also technically limit the ability of end users to effectively switch between different undertakings providing internet access service, in particular through their control over hardware or operating systems. This distorts the level playing field for internet access services and ultimately harms end users. It should therefore be ensured that gatekeepers do not unduly restrict end users in choosing the undertaking providing their internet access service.
Surely most governments have a compelling interest in preserving the ability to sideload apps on Android for software development, information security research, and preserving the open competitive ecosystems that so many bought into and invested in with such terms.
The ability for open source software developers to write and run applications on their [fork of AOSP with a bunch of binary closed source out-of-tree kernel modules] devices should be protected, in order to prevent anti-competitive practices from squandering the open platform the community has helped to build.
Play Store requires a DUNS number and registration therefore these days.
F-Droid does not require a DUNS number for app upload.
(F-Droid is one of a number of third party APK registry and APK installer services. The F-Droid web service hosts signed Android "APK" software packages and updates which can be uploaded by registered users and downloaded without registration or login. The F-Droid application installs APKs from the F-Droid web service; though app install and update requires more taps to install or update multiple packages due to Android's lack of functionality to add third-party package repos with keys, a standard feature in modern Linux software package management systems.)
Android app developers can already choose whether their app can be installed or run on a device that doesn't pass Play Integrity checks.
If non-rooted third-party AOSP forks with recent Security Patch Levels fail Play Integrity checks and thus cannot work with retail banking apps for example, then old versions of Android for which there are no longer updates should also fail Play Integrity checks.
Open standards for modern software management include: schema.org/SoftwareApplication , W3C Verifiable Credentials, Sigstore, SLSA, and OCI Artifact registries which already support signatures.
There are various tools which sideload APKs over HTTPS without any checksum or signature (e.g. from GitHub releases instead of from for example an OCI Registry) which are as reckless as curl | sh.
Couldn't bash and zsh run in a container2wasm WASM container that, in a browser tab without install, gets its own SELinux security context like all apps since Android 4.4+?
Does ls -Z work in Android Terminal (or termux, or the ChromeOS term)?
Students and Family Link accounts are currently denied access to containers on Chromebooks.
So on a Chromebook the same curriculum is limited to JupyterLite in WASM which almost works offline in a browser, instead of a local repo2docker container or a devcontainer.json (because there is no money for students to have server resources (like shells, CI, GitLab+k8s resource quotas) other than their provisioned computer).
I'd guess that these will support their virtualization framework so that you don't have to depend on tmux.
Android Terminal works pretty well on the pixel at the moment, so hopefully the merged version in ChromeOS-style laptops and tablets will be fully usable.
I wonder if they'll drop support for ChromeOS Flex, their install-it-on-whatever version. Would be kind of interesting to have a semi-official Android for various x86 machines I have lying around.
AFAIK a majority of Chromebooks are x86 (which has always been funny to me because surely that's the best case for ARM but w/e). Therefore, I think it's reasonable to assume that any new ChromeOS-on-Android OS will probably run on x86. Now I grant that x86 Chromebooks are already not using normal UEFI so there is a small gap there... but if you're already building the same OS for the same CPU on basically the same hardware, surely it's worth the... what, couple days of work?... to add an UEFI bootloader to vastly increase your hardware coverage. For bonus points, this should make it (even) easier to run in VMs for dev reasons.
All of which to say: Yeah, I'm actually somewhat optimistic that we get official Android x86 out of this.
Seriously though this is inevitable as Fuchsia wound down and Android essentially proved its worth running on Windows (which was a nice experiment I guess).
Fuchsia actually continues to receive hundreds of commits per week and is under VERY active development including moving into Android itself (although fuchsia itself remains uncoupled to Android and cna be used in other contexts)
The only android on Windows I know about was the subsystem but that was shackled to the Amazon app store and was killed off when Amazon finally gave up on their app store.
> To buttress his argument that Android can work on laptops, Samat pointed to the OS being "super successful" on tablet computers.
In like 2015 before all the OEMs lost interest when it turned out tablets didn't have phone-esque upgrade cycles maybe? Isn't the Android tablet market basically on life support from occasional Samsung refreshes at this stage?
I dont think so, it's more active recent year. There are a lot of good Chinese tablet(from well known brand). Xiaomi, lenovo, vivo, oppo and oneplus all have "flagship" tablet(running high end CPU, with very good screen and build quality)
Yeah, I think in proportions, tablets have always been a small niche — Not small in absolute numbers, but in comparison to phones. And since companies that make tablets also make phones, the phones always get all the priority.
Touch and Linux is still a terrible experience (vs W8/W10). Windows 11 replaces the useful W10 gesture (edge screen swipe) for win+tab with a widget for ads so I have no hopes in MS
Linux has multiple touch-based interfaces these days, including Phosh, Plasma Mobile and the upcoming GNOME Mobile. The interfaces themselves seem to work quite well and are broadly comparable with AOSP (or sometimes better). The Firefox browsing experience (based on the desktop version of Firefox with custom "mobile" tweaks) and things like the software keyboard tend to still be subpar compared with what's available on AOSP.
It's been a while since I've tried it. I assume the experience got better with ubuntu putting in around ubuntu touch but honestly I can't say if it's much better.
I've got a Lenovo tablet. It's bad - I only use it to read music and it's so laggy. It was cheap but I feel I'd have been better off getting a used ipad.
I would suspect that they continue to support those until they hit their agreed upon EOL. At some point they will ship new units that are essentially identical in use (running chrome), but are locked down under the hood (for school use) to be more like chromeOS and less like Android.
There is a good chance the average end user wont even notice the difference. It seems doable, but I guess the devil is in the details. If they can't pull it off, Apple is rumored to be launching a ~$599 macboook. Would not be really stretch to see them complete in this space again in the future.
I think ChromeOS has been slowly making the merge for awhile now, hence the chrome store being killed and replaced by the android store. Everytime I updated my Chrome book over the past year or so it gets a bit more android like.
They see an entrance into the windows desktop market and they are taking it. I personally like this path because the only good laptop+phone integrated combo I see is from Apple. Hope they don’t screw up on opportunities like clipboard sharing and other integrations.
Shame, my impression is that ChromeOS did a lot of the foundational stuff better than Android. Would have been better to merge them the other way, but that would never fly politically.
Not convinced this will happen. Plenty of k-12 Chromebooks with an extended support life to 2032+. Having used both seems to be still quite a big task to merge these together.
This could be the "next generation" ChromeOS that are exclusively available on new/recent Chromebook devices, while Google keep updating the "legacy" ones with only security patches. From what I can tell, Google never explicitly promised that every supported Chromebook can get the latest feature updates. The only said "updates".
Of course this is pure speculation and I'd love to be proven wrong.
Fuchsia actually continues to receive hundreds of commits per week and is under VERY active development including moving into Android itself (although fuchsia itself remains uncoupled to Android and cna be used in other contexts)
I'm glad they'll be focusing on a single OS across more devices, but I'm very concerned there will be no workaround for installing "untrusted" apps. Without ultimate user control of the device, they'll just be ad/influence appliances.
Worse, surveillance appliances. Highly likely we'll see mandatory client-side scanning apps in EU soon, and possibly Digital ID stuff in the UK.
Great opportunity for mandatory remote attestation and mandatory software.
That's definitely where things are heading I think. All of Google's changes point to getting ready for this.
The big tech companies are boiling the frog, trying to get us used to Linux just being an "app" we run on our licensed, not managed by us devices.
Google will point to the linux terminal app on Android and go "see, it's OK that we're making these sideloading changes - you can just run Linux (in a VM, on a device you don't have root on). WSL also gets us used to the idea that Linux is just an app.
Get ready for people to not see between the lines, adopt it, and then the rug will get pulled. We'll see hardware OEMs that lock boot loaders, no more alternative OS for you, or if you do manage to install another OS, you won't get to access any internet services because you won't pass the device attestation checks.
Yes. There is a potential future a year or two from now where your system will be required to prove firmware-upward that it is unmodified, and that you're licensed (and perhaps over-18 too), to access a huge percentage of websites.
All it will take is Cloudflare et al. offering it as a free option for every CDN customer and who wouldn't turn it on? Especially if the alternative is having to handle ID verification yourself, right?
Brazil already has a law on the books requiring online services and "terminal operating systems" to do age verification in a government approved manner.
Qualcomm Arm PCs support hardware nested virtualization for pKVM L0 and KVM L1 hypervisor, similar to Pixel devices. This could enable Debian Linux in a VM, currently available on Pixel as "Linux Terminal" for developers, with all Debian Arm packages and root access in the VM.
"Terminal app can now run full graphical Linux apps in the latest Android Canary", https://news.ycombinator.com/item?id=44681858
"Coding without a laptop: Two weeks with AR glasses and Linux on Android", https://news.ycombinator.com/item?id=43985513
So?
Technical capability often has little to do with how the product works.
I really miss the days where companies sold tools and consumers could use them in flexible and creative ways that would never have been considered by the manufacturer.
Same, but companies discovered they could make more money by rent seeking instead. Blame growth culture. It wasn't enough to have a sustainable business, it must grow rapidly with a clear exit, either IPO or acquisition.
Example, the way NDK is supposed to be used on Android, as means to implement native methods for Java/Kotlin, or plain games, with a specific list of supported APIs and nothing else.
Anything outside of what is allowed, may work or crash and burn.
> This could enable Debian Linux in a VM,
This is like making sex in public. It is doable, but dangerous.
They decided it'd be more efficient to make one thing worse than two at the same time.
If you can adb unlock, and it's not a closed box, then people can run F-Droid and install apps. Which means they can run independent path code without "sideload" in the apk download-and-install-by-hand sense. I guess for google, F-Droid IS sideloading.
If you unlock and you cannot run google wallet or your banking app, it's a closed box and the EU anti-monopoly lawsuit may still apply on this. But, if they can make a "trust" story run about LEA access to lawful decode or something, this might go away.
I'd say that the projections about fuschia and the like have turned out to be less interesting than some people hoped: but having two OS in the public eye (3 or more if you include Android TV and whatever closed systems run on Nest and Chromecast) was always a mistake.
I can live inside termux but there are things termux struggles to do, (like tcpdump maybe? and interacting simply with data downloaded from outside termux because of sandbox rules), which I very much would want.
I do not like how Android interacts with removable storage. It's an anti-pattern.
> I can live inside termux but there are things termux struggles to do,
Because that isn't part of the set of allowed NDK APIs.
https://developer.android.com/ndk/guides/stable_apis
Anything that termux manages to do outside of that list is more out of sheer luck that Android team hasn't closed down that specific Linux syscall.
Initially Android only got the NDK back in Android 2.0, due to pressure from game developers, and Dalvik having such a lame performance, it was never for writing full applications.
I love termux, but it's really not a replacement for full fat linux. There's tio many incompatibilities with how linux software expects to run for it to work for a dev workflow (unless your workflow is to immediately ssh into something else).
The most compatible setup I found is proot-distro into alpine, which bypasses a lot of the android blockers, and the bionic-libc incompatibilities by using musl. Comes at a performance cost, however.
I think in general their plans are contrary to the DMA if they prevent F-Droid from existing. The big bet seems to be that Trump can coerce the EU into repealing the law entirely.
> (50) [...] In order to ensure that third-party software applications or software application stores do not endanger the integrity of the hardware or operating system provided by the gatekeeper, it should be possible for the gatekeeper concerned to implement proportionate technical or contractual measures to achieve that goal if the gatekeeper demonstrates that such measures are necessary and justified and that there are no less-restrictive means to safeguard the integrity of the hardware or operating system.
> (54) Gatekeepers can hamper the ability of end users to access online content and services, including software applications. Therefore, rules should be established to ensure that the rights of end users to access an open internet are not compromised by the conduct of gatekeepers. Gatekeepers can also technically limit the ability of end users to effectively switch between different undertakings providing internet access service, in particular through their control over hardware or operating systems. This distorts the level playing field for internet access services and ultimately harms end users. It should therefore be ensured that gatekeepers do not unduly restrict end users in choosing the undertaking providing their internet access service.
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%...
Surely most governments have a compelling interest in preserving the ability to sideload apps on Android for software development, information security research, and preserving the open competitive ecosystems that so many bought into and invested in with such terms.
The ability for open source software developers to write and run applications on their [fork of AOSP with a bunch of binary closed source out-of-tree kernel modules] devices should be protected, in order to prevent anti-competitive practices from squandering the open platform the community has helped to build.
Play Store requires a DUNS number and registration therefore these days.
F-Droid does not require a DUNS number for app upload.
(F-Droid is one of a number of third party APK registry and APK installer services. The F-Droid web service hosts signed Android "APK" software packages and updates which can be uploaded by registered users and downloaded without registration or login. The F-Droid application installs APKs from the F-Droid web service; though app install and update requires more taps to install or update multiple packages due to Android's lack of functionality to add third-party package repos with keys, a standard feature in modern Linux software package management systems.)
Android app developers can already choose whether their app can be installed or run on a device that doesn't pass Play Integrity checks.
If non-rooted third-party AOSP forks with recent Security Patch Levels fail Play Integrity checks and thus cannot work with retail banking apps for example, then old versions of Android for which there are no longer updates should also fail Play Integrity checks.
Open standards for modern software management include: schema.org/SoftwareApplication , W3C Verifiable Credentials, Sigstore, SLSA, and OCI Artifact registries which already support signatures.
There are various tools which sideload APKs over HTTPS without any checksum or signature (e.g. from GitHub releases instead of from for example an OCI Registry) which are as reckless as curl | sh.
Couldn't bash and zsh run in a container2wasm WASM container that, in a browser tab without install, gets its own SELinux security context like all apps since Android 4.4+?
Does ls -Z work in Android Terminal (or termux, or the ChromeOS term)?
Students and Family Link accounts are currently denied access to containers on Chromebooks.
So on a Chromebook the same curriculum is limited to JupyterLite in WASM which almost works offline in a browser, instead of a local repo2docker container or a devcontainer.json (because there is no money for students to have server resources (like shells, CI, GitLab+k8s resource quotas) other than their provisioned computer).
container2wasm: https://github.com/container2wasm/container2wasm :
I'd guess that these will support their virtualization framework so that you don't have to depend on tmux.
Android Terminal works pretty well on the pixel at the moment, so hopefully the merged version in ChromeOS-style laptops and tablets will be fully usable.
Google tried to merge Android and ChromeOS back in 2016 in a project called Andromeda: https://www.neowin.net/news/google-has-reportedly-killed-its...
I mean, Pixels run a "desktop mode" today if you enable stuff in dev options and connect a display, keyboard, mouse via USB.
Not a stretch to imagine that its the same work, so its desktop android, not, ChromeOS merge, this time.
I wonder if they'll drop support for ChromeOS Flex, their install-it-on-whatever version. Would be kind of interesting to have a semi-official Android for various x86 machines I have lying around.
AFAIK a majority of Chromebooks are x86 (which has always been funny to me because surely that's the best case for ARM but w/e). Therefore, I think it's reasonable to assume that any new ChromeOS-on-Android OS will probably run on x86. Now I grant that x86 Chromebooks are already not using normal UEFI so there is a small gap there... but if you're already building the same OS for the same CPU on basically the same hardware, surely it's worth the... what, couple days of work?... to add an UEFI bootloader to vastly increase your hardware coverage. For bonus points, this should make it (even) easier to run in VMs for dev reasons.
All of which to say: Yeah, I'm actually somewhat optimistic that we get official Android x86 out of this.
I sense an impending merge conflict.
Seriously though this is inevitable as Fuchsia wound down and Android essentially proved its worth running on Windows (which was a nice experiment I guess).
Fuchsia actually continues to receive hundreds of commits per week and is under VERY active development including moving into Android itself (although fuchsia itself remains uncoupled to Android and cna be used in other contexts)
Android on Windows?
Google Play Store on Windows really.
Ok, but what are you talking about?
The only android on Windows I know about was the subsystem but that was shackled to the Amazon app store and was killed off when Amazon finally gave up on their app store.
https://play.google.com/googleplaygames/
There were two attempts at it from Microsoft, the first one was still in the Windows 8.x timeline, and out of its ashes WSL was born.
The one with Amazon store was the second attempt.
> To buttress his argument that Android can work on laptops, Samat pointed to the OS being "super successful" on tablet computers.
In like 2015 before all the OEMs lost interest when it turned out tablets didn't have phone-esque upgrade cycles maybe? Isn't the Android tablet market basically on life support from occasional Samsung refreshes at this stage?
Nope, because outside US, where Android dominates, most folks also go for an Android tablet, between Samsung, Xiomi or Huawei.
I think usually people that only see iPads around come from the few markets that are dominated by Apple.
I'm not from the US and Android also dominates phones in my country, but not tablets.
As you can see, in Europe Apple only has around 46%, 49% if worldwide, with the remaining being shared across all Android vendors.
https://gs.statcounter.com/vendor-market-share/tablet/europe
If you go world wide in another data set, it is around 54%
https://www.bankmycell.com/blog/global-tablet-market-share/
Even considering the more generous number, that makes half of the tablets being sold across the planet are not iPads.
> Android tablet market basically on life support
I dont think so, it's more active recent year. There are a lot of good Chinese tablet(from well known brand). Xiaomi, lenovo, vivo, oppo and oneplus all have "flagship" tablet(running high end CPU, with very good screen and build quality)
Yeah, I think in proportions, tablets have always been a small niche — Not small in absolute numbers, but in comparison to phones. And since companies that make tablets also make phones, the phones always get all the priority.
It's pretty bad. The only place it sort of thrives is Amazon's tablets and android ereaders.
They are all (AFAIK) based around android 9 or 10.
You are seriously almost better off just doing something like a windows tab converted to a linux machine.
Touch and Linux is still a terrible experience (vs W8/W10). Windows 11 replaces the useful W10 gesture (edge screen swipe) for win+tab with a widget for ads so I have no hopes in MS
Linux has multiple touch-based interfaces these days, including Phosh, Plasma Mobile and the upcoming GNOME Mobile. The interfaces themselves seem to work quite well and are broadly comparable with AOSP (or sometimes better). The Firefox browsing experience (based on the desktop version of Firefox with custom "mobile" tweaks) and things like the software keyboard tend to still be subpar compared with what's available on AOSP.
It's been a while since I've tried it. I assume the experience got better with ubuntu putting in around ubuntu touch but honestly I can't say if it's much better.
> They are all (AFAIK) based around android 9 or 10.
That’s not what I see when I lookup tablets. My old cheap Samsung Tab S6 Lite (2022 version) has Android 14 with security patch from May 2025.
My SO bought a cheap Xiaomi tablet this month with Android 15 and patch from August 2025.
I've got a Lenovo tablet. It's bad - I only use it to read music and it's so laggy. It was cheap but I feel I'd have been better off getting a used ipad.
I am on a Samsung Android tablet
Sounds more like they're killing ChromeOS and attempting to implement a Laptop experience for Android.
I wonder what this means for all the schools that invested in Chromebooks.
I would suspect that they continue to support those until they hit their agreed upon EOL. At some point they will ship new units that are essentially identical in use (running chrome), but are locked down under the hood (for school use) to be more like chromeOS and less like Android.
There is a good chance the average end user wont even notice the difference. It seems doable, but I guess the devil is in the details. If they can't pull it off, Apple is rumored to be launching a ~$599 macboook. Would not be really stretch to see them complete in this space again in the future.
Every chromebook ever sold can have its bootloader unlocked and software replaced, doing so un-enrolls it from whatever management the school set up.
I think ChromeOS has been slowly making the merge for awhile now, hence the chrome store being killed and replaced by the android store. Everytime I updated my Chrome book over the past year or so it gets a bit more android like.
ChromeOS support is contracted and thus guaranteed.
But one day they'll have to switch, when the support runs out. IIRC it's 7-10 years depending.
They see an entrance into the windows desktop market and they are taking it. I personally like this path because the only good laptop+phone integrated combo I see is from Apple. Hope they don’t screw up on opportunities like clipboard sharing and other integrations.
Wonder if android will scale up to a windowing interface for larger screens or will it be like samsung dex.
There seems to be a lot more Google activity in the past 3 - 4 years. I wonder what happened. Because the merge should have happened for a long time.
China in happening.
It will actually be the Fuchsia OS operating system.
The Register "confirmed" with Google the the mobile OS will be "trumphant?"
Shame, my impression is that ChromeOS did a lot of the foundational stuff better than Android. Would have been better to merge them the other way, but that would never fly politically.
It did, yeah. A merge the other way would have probably been a bad idea too, they should remain separate.
Not convinced this will happen. Plenty of k-12 Chromebooks with an extended support life to 2032+. Having used both seems to be still quite a big task to merge these together.
I think it matters what "support" means.
This could be the "next generation" ChromeOS that are exclusively available on new/recent Chromebook devices, while Google keep updating the "legacy" ones with only security patches. From what I can tell, Google never explicitly promised that every supported Chromebook can get the latest feature updates. The only said "updates".
Of course this is pure speculation and I'd love to be proven wrong.
Hopefully replacing Linux with Fuchsia at the same time?
Fuchsia is DoA. They tried moving nest and smart speakers to it and scrapped the project in 2023.
It does not seem dead by any means, as they keep making meaningful releases[0].
0. https://fuchsia.dev/whats-new/release-notes
Google Nest Hub is still using Fuchsia.
Fuchsia actually continues to receive hundreds of commits per week and is under VERY active development including moving into Android itself (although fuchsia itself remains uncoupled to Android and cna be used in other contexts)
Then what is the actual goal of that, and what is it being used for?
[dead]
Sooooo ChromeOS 26 with Liquid -Glass- Material Design? :trollface: