Surprisingly quietly, in the middle of Apple’s WWDC, Google’s ChromeOS team has made a rather massive announcement that seems to be staying a bit under the radar. Google is announcing today that it is replacing many of ChromeOS’ current relatively standard Linux-based subsystems with the comparable subsystems from Android.
To continue rolling out new Google AI features to users at a faster and even larger scale, we’ll be embracing portions of the Android stack, like the Android Linux kernel and Android frameworks, as part of the foundation of ChromeOS. We already have a strong history of collaboration, with Android apps available on ChromeOS and the start of unifying our Bluetooth stacks as of ChromeOS 122.
↫ Prajakta Gudadhe and Alexander Kuscher on the Chromium blog
The benefits to Google here are obvious: instead of developing and maintaining two variants of the Linux kernel and various related subsystems, they now only have to focus on one, saving money and time. It will also make it easier for both platforms to benefit from new features and bugfixes, which should benefit users of both platforms quite a bit.
As mentioned in the snippet, the first major subsystem in ChromeOS to be replaced by its Android counterpart is Bluetooth. ChromeOS was using the BlueZ Bluetooth stack, the same one used by most (all?) Linux distributions today, which was initially developed by Qualcomm, but has now switched over to using Fluoride, the one from Android.
According to Google, Fluoride has a number of benefits over BlueZ. It runs almost entirely in userspace, as opposed to BlueZ, where more than 50% of the code resides in the kernel. In addition, Fluoride is written in Rust, and Google claims it has a simpler architecture, making it easier to perform testing. Google also highlights that Fluoride has a far larger userbase – i.e., all Android users – which also presents a number of benefits.
Google performed internal tests to measure the improvements as a result from switching ChromeOS from BlueZ to Fluoride, and the test results speak for themselves – pairing is faster, pairing fails less often, and reconnecting an already paired device fails less often. With Bluetooth being a rather problematic technology to use, any improvements to the user experience are welcome.
At the end of Google’s detailed blog post about the switch to Fluoride, the company notes that it intends for the project as whole – which is called Project Floss – to be a standalone open source project, capable of running on any Linux distribution.
↫ Russ Lindsay, Abhishek Pandit-Subedi, Alain Michaud, and Loic Wei Yu Neng on the chromeOS dev website
We aspire to position Project Floss as a standalone open source project that can reach beyond the walls of Google’s own operating system in a way where we can maximize the overall value and agility of the larger Bluetooth ecosystem. We also intend to support the Linux community as a whole with the goal that Floss can easily run on most Linux distributions.
If Fluoride can indeed deliver tangible, measurable benefits in Bluetooth performance on Linux desktops, I have no doubt quite a few distributions will be more than willing to switch over. Bluetooth is used a lot, and if Fedora, Ubuntu, Arch, and so on, can improve the Bluetooth experience by switching over, I’m pretty sure they will, or at least consider doing so.
Generally, has anyone noticed that wireless technology tends to be a bit temperamental even today?
Bluetooth will sometimes mysteriously fail to pair or mysteriously drop connections. Similarly, WiFi routers will mysteriously drop connections or connecting to the router will mysteriously stop working (even after repeated attempts) until you reboot the router (but Ethernet will keep functioning, which means the router is still alive). Things are slowly getting better over the years with every new batch of devices, but shouldn’t this kind of stuff have already been figured out since day one?
kurkosdr,
I still use an ancient netgear 802.11g router, and it does that. I always figured this would be fixed in new products, but I couldn’t be bothered to replace it given that I don’t use wifi much. I know for a fact that my netgear router would frequently deplete it’s connection tracking memory, which was not configurable. When this happens, all new connections get dropped until the old ones disconnect or expire.
Peer to peer software nearly always triggers this because P2P can rapidly contact hundreds.of UDP peers in a short time for each file. The router keeps track of each session for 2 hours and it just runs out of space. Dropping old/idle connections in favor of new active ones would probably be more useful, but most stacks do the opposite and drop the new packets.
TCP is supposed to be a bit more robust to this because the router knows that it can delete the mapping on FIN or RST, which indicates the end of a TCP connection. So while a computer may make hundreds of connections while browsing the web, the sessions are typically short lived. However, if a device is pwered down while TCP sessions are in progress, the TCP channels may start to accumulate in the tables even though they are dead. Many TCP stacks will keep idle TCP sessions around for hours. So on the WIFI router dead mappings can add up.
In my experience most cellular connections have the opposite problem: they are very quick to drop NAT session maps. IIRC on tmobile I would get udp disconnections at around 20-30s and tcp around 1minute. This was very infuriating when I was doing SSH from my phone, I’d constantly loose my connection!. A VPN with rapid keepalives could probably keep the connection up indefinitely but I generally try avoid using phones for any work, only rare emergencies. I’m using ATT now, but I haven’t tested their session timeouts.
I hope that the Linux community stays as far away from this project as possible. It would be nice to have better bluetooth support, but at what cost? Watching how MV3 plays out will tell us all we need to know.
It makes sense for Google to move to make ChromeOS an OS that is more compatible with Android. Microsoft seems to screwing over their users with the directions windows 11 is taking, and it’s opening up the market for other player to move in. Android on a laptop will probably be easier to sell to end users in the future than locked down ChromeOS on a laptop, when you want to replace windows, but still retain the option to install applications.
ChromeOS used to be able to run Android apps until google ripped that out.
Now they’re replacing the linux subsystem with their own AOSP crap… frightening.
Run far away from google and everything they poison.
ChromeOS still run Android apps.