It’s 2025, and we’re going to talk about BeOS, AtheOS, Cosmoe, and OpenBeOS, all in one news item, right here, right now, on OSNews.

In the very early 2000s, Cosmoe was a unique project that started out as a merger of the AtheOS userland with the Linux kernel. AtheOS, in turn, was one of the quintessential hobby operating systems of the golden age of the advanced hobby operating systems, the early 2000s. AtheOS would eventually be abandoned in 2002, but would be forked into Syllable and continue development until it, too, was eventually abandoned in 2012.

Cosmoe was the brainchild of Bill Hayden, and originally consisted of the AtheOS userland running on top of the Linux kernel, in order to address the lack of supported hardware a custom operating system kernel inevitably has to deal with. Not long after the start of Cosmoe, AtheOS was abandoned, as mentioned above, but a new project had entered the scene: OpenBeOS, now known as Haiku. Hayden switched gears, and instead started porting the parts that made up OpenBeOS to run on the Linux kernel.

This project progressed nicely, but in 2007 Cosmoe came to a halt (ironically, our last item about Cosmoe is “Cosmoe is back“) as Hayden had no more free time left to work on it, being a father of five, and so he decided to put the project on hold indefinitely. That is, until last year, when everything changed.

In mid-2024, my 3rd son Joshua, not even born when I started this project but who is now in college studying to be a programmer himself, had some questions about operating systems. I decided to dust off Cosmoe and see if I could get it running again, to show him what I had worked on. At first it would only compile and run on extremely old 32-bit versions of Mandrake Linux from 2007. But I had caught the bug again. Not only had I forgotten how fun Cosmoe was to program, but the intervening 17 years of progress made by OpenBeOS (now Haiku) made the certain aspects of this revival come at lightning speed. Day by day, week by week, I got it running on newer versions of Linux, and re-synchronized it with ever-more-recent releases of Haiku. After about 2 months of late-night effort, I had a version of Cosmoe that was 64-bit compatible, ran on multiple modern Linux releases, and was almost completely up-to-date with the latest Haiku source changes.

↫ Cosmoe’s history page

We’re halfway through 2025 now, and Cosmoe now exists as two separate, but related projects. There’s Cosmoe Classic, which is the updated and modernised incarnation of Cosmoe’s original concept: Haiku’s userland running on top of the Linux kernel. In its current form, it runs inside an SDL window on your Linux desktop, as there’s no native video driver. Cosmoe Classic, however, is not what Hayden is focusing on.

Instead, Hayden is focusing on the new Cosmoe, which takes the same idea – the Haiku userland running on a Linux kernel – but implements it in a completely different way:

Cosmoe is a C++ class library that allows developers to build rich, native Linux apps with the easy-to-use BeOS API. This library is a light-weight, serverless version of Cosmoe Classic which targets the Wayland compositor on Linux.

↫ Cosmoe’s GitLab page

What Cosmoe on Wayland (to differentiate it from Cosmoe Classic) allows you to do is run BeOS/Haiku applications on Linux, provided you are running Wayland. The project is in an alpha state, but once compiled, it comes with a few BeOS/Haiku sample applications you can run right on your Wayland-based Linux desktop. Hayden states that about 95% of the BeOS API is implemented in Cosmoe, with the TODO file giving an idea of what tasks need to be done to improve compatibility and implement other improvements.

The return of Cosmoe is certainly not something I saw coming, but I’m incredibly excited. I’m not entirely sure about the usefulness of running Haiku applications on Wayland on Linux, but who the hell cares – this is an awesome project, with a ton of cherished history behind it that gives me butterflies in my stomach. It’s absolutely beautiful to see a project like this come back to life in 2025.

Cosmoe is back. Again.

The lone volunteer maintainer of libxml2, one of the open source ecosystem’s most widely used XML parsing libraries, has announced a policy shift that drops support for embargoed security vulnerability reports. This change highlights growing frustration among unpaid maintainers bearing the brunt of big tech’s security demands without compensation or support.

[…]

Wellnhofer’s blunt assessment is that coordinated disclosure mostly benefits large tech companies while leaving maintainers doing unpaid work. He criticized the OpenSSF and Linux Foundation membership costs as a financial barrier to single person maintainers gaining additional support.

↫ Sarah Gooding

The problem is that, according to Wellnhofer, libxml2 was never supposed to be widely used, but now every major technology company with billions in quarterly revenue are basically expecting an unpaid maintainer to fix the security issues – many of which questionable – they throw his way.

The point is that libxml2 never had the quality to be used in mainstream browsers or operating systems to begin with. It all started when Apple made libxml2 a core component of all their OSes. Then Google followed suit and now even Microsoft is using libxml2 in their OS outside of Edge. This should have never happened. Originally it was kind of a growth hack, but now these companies make billions of profits and refuse to pay back their technical debt, either by switching to better solutions, developing their own or by trying to improve libxml2.

The behavior of these companies is irresponsible. Even if they claim otherwise, they don’t care about the security and privacy of their users. They only try to fix symptoms.

↫ Nick Wellnhofer

It’s wild that a library never intended to be widely used in any critical infrastructure is now used all over the place, even though it just does not have the level of quality and security needed to perform such a role. These are the words of Wellnhofer himself – an addition to the project’s readme now makes this point very clear, and I absolutely love the wording:

This is open-source software written by hobbyists, maintained by a single
volunteer, badly tested, written in a memory-unsafe language and full of
security bugs. It is foolish to use this software to process untrusted data.
As such, we treat security issues like any other bug. Each security report
we receive will be made public immediately and won’t be prioritized.

↫ libxml2’s readme

If you want libxml2 to fulfill a role it was never intended to fulfill, make it happen. With contributions. With money. Don’t just throw a whole slew of security demands a sole maintainer’s way and hope he will do the work for you.

Welcome news coming out of Jolla, the company that develops Sailfish OS. Up until now, if you bought their Jolla C2 smartphone, you had to pay a yearly subscription fee in order to get updates (with the first year included in the purchase price). Today they’ve announced their dropping this construction, and they now guarantee five years of free updates.

We’re happy to announce that from now onwards long-term Sailfish OS updates are included free-of-charge to all Jolla C2 devices for a minimum of 5 years. This applies also to everybody who have already purchased the Jolla C2.

↫ Announcement at the Jolla forums

People don’t like subscriptions, and I wouldn’t be surprised if Jolla was simply running into a lot of resistance to this subscription model from potential customers. Nobody likes subscriptions, and I think that counts doubly so for the kinds of people interested in buying a phone like the C2 with Sailfish OS.

With the possibility that Google is going to make some big changes to the open source status of Android, the importance of smartphones that don’t run either iOS or (some form of) Android is definitely increasing. Linux on smartphones is not as complete as iOS or Android, and I personally think one of the primary reasons for that is a lack of easy access to devices that don’t require manual installation or other forms of hackery, only to then end up with a partially supported device because the device in question was never originally designed to run regular Linux.

A few companies are trying to change this, developing Linux-first smartphones instead. One of the newcomers here is Liberux, a Spanish company who just unveiled the crowdfunding campaign for their Liberux Nexx, a Debian-powered smartphone with excellent specifications and some unique additions you won’t find on any other smartphone. It’s powered by an octa-core Rockchip RK3588S (four Cortex-A76 cores and four Cortex-A55 cores up to 2.4 GHz), 32 GB LPDDR4x RAM, tons of expendable storage, and a 6.34″ 2400×1080 OLED display.

At the top of the device sit something you won’t find on many other smartphones: dedicated hardware switches to physically cut power to the modem, Wi-Fi/Bluetooth chip, and the microhone/camera array. When all three switches are disabled, a number of other features, like GPS and sensors, are also turned off. On top of all this, various internal components are designed to be replaceable and possibly even upgradeable, with manufacturing of the device taking place in Europe – which probably refers to assembly, but still. The device is supposed to become open source, too.

It will run Debian 13 with a customised version of the mobile GNOME Shell using a standard Linux kernel. Android applications will also be supported using Waydroid, which you’ll most likely have to rely on for things like banking and other application categories exclusive to iOS and Android. Liberux promises that any development done on both the Linux distribution and other related applications will be done openly, which is something we can hold them to quite easily.

I’m always weary of crowdfunding campaigns, and all the usual caveats, warnings, and concerns still apply here. I’m highlighting this campaign because I feel like many of the kinds of people who read OSNews are longing for a modern, capable smartphone that runs not iOS or Android, but proper Linux, even if Linux on smartphones isn’t quite there yet to go toe-to-toe with the two duopolists. For more information on the device and the people involved, be sure to read LINMOB.net’s excellent interview with Liberux.

Liberux has told me they want to send over a review device once development has reached a point where that’s possible. So, assuming the crowdfunding campaign is successful, you can look forward to a review of the Liberux Nexx on OSNews somewhere between now and mid-2026.

Accessibility is something that doesn’t get nearly enough attention, especially considering because not only will we need accessibility features eventually as we grow older, but also because a lot of accessibility features are just helpful even if you don’t technically need them. Given these facts, it’s a shame that accessibility is usually an afterthought, doubly so on open source desktops, a problem we recently talked about.

But what if you don’t just need to use a few applications as, say, a blind person, but also actually program as a blind person? Acidic Light, accessibility engineer at KDE e.V., has published a blog post about how screen readers actually work, and what it’s like to program while blind, and the conclusions are not exactly great.

I truly feel that, based on my experience with KDE and my experience actually delving into the weeds with AccessKit in a custom UI system, that accessibility programming just isn’t accessible. Unless you happen to already understand the way each platform works, trying to find resources on how to actually let a screen reader know your UI exists is just painful. It’s going to involve reading code other people have already written. It’s going to involve hours, if not days, if not weeks of research and painful debugging. You likely won’t be able to ask many people for help, because they’ll know as much as you do.

↫ Acidic Light

If the people who know most what is needed to make a program accessible have so many problems actually making programs accessible, because the tooling, documentation, and institutional knowledge just isn’t there, what hope do other programmers have to make their code accessible? If a blind programmer can’t scratch their own itch, so to speak, we’re never going to reach a point where accessibility becomes a given.

I’m very happy awareness of accessibility is growing, but I feel like this isn’t the first time we’ve seen an increase in accessibility awareness only for it to eventually fizzle out without meaningful improvements for those that need it the most. I really hope it sticks this time.

A new version of Plasma is here, and it feels even more like /home, as it becomes smoother, friendlier and more helpful.

Plasma 6.4 improves on nearly every front, with progress being made in accessibility, color rendering, tablet support, window management, and more.

↫ KDE Plasma 6.4 release announcement

KDE Plasma 6.4 comes with a big improvement in window and virtual desktop management, allowing you to create entirely custom tiled configurations per virtual desktop. Accessibility was another focus of this release, as we talked about a few weeks ago, bringing number pad mouse pointer navigation, improved desktop zoom, screen readers improvements, better contrast i the dark theme, tons of little legibility improvements across the desktop environment and its applications, and more.

Furthermore, there’s now finally a dedicated page in Settings for animations, so you no longer have to dig your way through the oddly placed and obtuse Desktop Effects page. Notifications have been improved as well, with new additions like a speed graph in file transfer notifications or Plasma notifying you when you’re trying to use a muted microphone input. KRunner can now visualise colours when searching for a hex code, Spectacle has received some love, various widgets have been touched up, and much more.

There’s a brand new HDR wizard, support for Extended Dynamic Range, and the addition of the P010 video color format. System Monitor will now show usage information for Intel and AMD GPUs, and Info Center will show raw sensor data from the sensors in your device. There’s a ton more, as this is a fairly major release.

You can download and compile KDE Plasma 6.4 now, or just wait a few days until it lands in your distribution’s repository.

Wayland this, Liquid Glass that – but what if you just want a nice, comforting text-based environment? Sure, you can just boot straight into a terminal, or perhaps get fancy about it with Screen or whatever, but what if you want a text-based environment, but don’t want to give up windows, menus, your mouse? How about a graphical user interface made up entirely of text?

Twin is text-based windowing environment with mouse support, window manager, terminal emulator, networked clients and the ability to attach/detach mode displays on-the-fly.

It supports a variety of displays:

• plain text terminals: Linux console, twin’s own terminal emulator, and any termcap/ncurses compatible terminal;
• X11, where it can be used as a multi-window xterm;
• itself (you can display a twin on another twin);
• twdisplay, a general network-transparent display client, used to attach/detach more displays on-the-fly.

↫ The Twin GitHub page

It looks exactly like what you’d think this would look like, and I find it absolutely fascinating. I’m not entirely sure how usable it is or who or what use case it’s optimised for, but I adore the dedication to the cause. It works on both Linux and FreeBSD, and most likely other systems as well.

A new image loading machinery, called glycin, has been in the works for a while. It is already used by GNOME’s default Image Viewer (Loupe), as well as by a bunch of other apps. Glycin provides many security benefits over existing solutions due to the use of the Rust programming language and sandboxing. Distributions will now be able to use the security benefits and broader format support of glycin for other GNOME apps, thumbnailers, and GNOME Shell, whithout changing any existing software. This is made possible by a new option for GNOME’s legacy image-loading library, GdkPixbuf, to use glycin internally.

↫ Sophie Herold

Clearly, this is an improvement over the previous image loading library, but there’s a bit of a catch that is in line with GNOME’s increased reliance on systemd features: glycin only works on Linux due to its sandbox mechanisms and how it communicates with its loaders. However, there’s no need to fret this time, and that’s why I’m posting this item – you just know this tiny little tidbit will find their way into internet discussion forums and social media as another example of GNOME not caring about non-Linux users.

While some of the sandboxing and communication features in glycin can be made to work on the BSDs and perhaps macOS, it won’t be perfect. As such, great care has been taken to ensure non-Linux platforms can continue to use GdkPixbuf just fine, since support for other platforms is part of the goals of this change before traditional loaders are removed.

As a general solution for other platforms, I am planning a mechanism to compile the loaders into the library. This will not provide sandboxing and format extendability without recompilation. But since most loaders are written in Rust, this is still a huge step-up security wise. Contributions for support on other platforms are welcome. For GdkPixbuf users, this will not pose an immediate issue since traditional gdk-pixbuf loaders are not going away until all platforms it supported, are supported by glycin.

↫ Sophie Herold

There are a few other issues, as any change like this tends to cause, like the list of supported images formats. Glycin supports AVIF, BMP, DDS, Farbfeld, QOI, GIF, HEIC, ICO, JPEG, JPEG XL, OpenEXR, PNG, PNM, SVG, TGA, TIFF, and WEBP out of the box, but some of the subformats within each of these might potentially not work entirely correctly due to incorrect implementations by, say, camera manufacturers. A special case here is the TIFF format, which apparently still has a number of issues and might end up relying on a fallback.

Glycin brings a ton of benefits, such as improved colour support for things like HDR and wider colour gamut displays, better metadata support, basic image editing functions out of the box, increased performance, as well as the benefits inherent in using a memory-safe language like Rust.

Are you still using Windows 7, 8, 8.1, or a 32 bit version of Windows, relying on LibreOffice for your sexy office tasks of writing TPS reports and calculating and tabulating juicy, plump numbers? Bad news: the next version of LibreOffice will remove support for these platforms. Buried deep in the release notes of the second beta for LibreOffice 25.8, it reads:

Support for Windows 7 and 8/8.1 was removed.

Support for x86 (32-bit) Windows builds is deprecated.

↫ LibreOffice 25.8 beta 2 release notes

I honestly doubt many people actually still rely on LibreOffice on these platforms, and even if for some unfathomable reason you do, you are probably also okay with sticking with an older version of LibreOffice to keep your weird setup going a few years longer. You do you.

Since Void Linux uses a rolling release model, there’s not much to report on in the form of new releases and major new features, so I’m taking the release of version 0.60 of XBPS, Void Linux’ package manager, to cheat my way into talking about this excellent Linux distribution. I always think of Void as the “BSD of Linux distributions”, which should give you some vague hint as to what it’s going for.

XBPS 0.60 doesn’t come packed with major new features either, and mostly fixes a ton of bugs, addresses few memory leaks, and changes the way held dependencies and directory removal/creation works when reinstalling a packages, just to name a few. There’s also some performance improvements, as there were apparently some problems in that department due to the increasing number of virtual packages in the Void repository.

If you’re looking for a more traditional, hands-on Linux distribution, Void is an excellent choice. It’s my back-up for if (let’s face it: when) Fedora messes something up.

With the release of Android 16, Google changed how it developed Android. Development is now taking place behind closed doors, with the code dropped after the corresponding version has been released to Pixel devices. Well, it turns out this wasn’t the only thing Google has changed about Android development. As the developers of CalyxOS, a popular de-Googled Android ROM, dove into the Android 16 AOSP source code, they realised something very important was missing: the device-specific source code for modern Pixel devices.

Android 16 was released to AOSP yesterday but with a one big difference than typical releases: Google did not publish any device-specific source code for supported, modern Pixel devices. In previous years, Google released full device trees alongside new Android versions. This allowed developers to build and boot AOSP on Pixel hardware relatively easily. With Android 16, only the platform/framework code has been released. The device trees are missing, at least for now.

This means AOSP 16 cannot currently be built or run on any recent Pixel device easily just using official source. It’s unclear whether this is a delay or a policy change. Either way, it seriously disrupts custom ROM development and our porting efforts.

↫ CalyxOS on Reddit

If this is truly a policy change, it’s a big one that affects custom ROM developers considerably. Pixel devices were “special” among custom ROM developers because support for them was part of AOSP releases, so they were well-supported by projects like CalyxOS, GrapheneOS, and LineageOS, including all the hardware components, and with quick updates. Without access to the Pixel-specific source code for the Pixel 6 to Pixel 9a, these devices will now have to be treated like any other Android phone as far as ROM developers go, meaning it’ll take a lot more work and time to get them to work properly with new major Android releases.

Google did not announce this potential policy change, and this has some in the custom Android ROM community on edge. I’ve been talking to people in the custom ROM community, and the story goes that a few months ago, at least one of these communities was approached by a journalist who wanted to talk to them. This journalist claimed that Google intends to discontinue the Android Open Source Project, with the first step Google would take being no longer releasing the device-specific Pixel source code (something nobody knew would happen until yesterday). The fact that this first step has now become a reality lends some credence to the journalist’s claim that Google is discontinuing AOSP. However, since such tips are not uncommon, and since there was no way to verify, the custom ROM developers in question didn’t really know what to do with it.

During the writing of this article over the past 12 hours, Google itself has also responded to what is apparently a growing, now public concern in the wider Android community. Seang Chau, Google VP and GM of Android Platform, published a Tweet, disclaiming Google has any intentions to close up shop for AOSP.

We’re seeing some speculation that AOSP is being discontinued. To be clear, AOSP is NOT going away. AOSP was built on the foundation of being an open platform for device implementations, SoC vendors, and instruction set architectures.

AOSP needs a reference target that is flexible, configurable, and affordable – independent of any particular hardware, including those from Google. For years, developers have been building Cuttlefish (available on GitHub as the reference device for AOSP) and GSI targets from source. We continue to make those available for testing and development purposes.

↫ Seang Chau

This seems like a solid denial from Google, but it leaves a lot of room for Google to make a wide variety of changes to Android’s development and open source status without actually killing off AOSP entirely. Since Android is licensed under the Apache 2.0 license, Google is free to make “Pixel Android” – its own Android variant – closed source, leaving AOSP up until that point available under the Apache 2.0 license. This is reminiscent of what Oracle did with Solaris. Of course, any modifications to the Linux kernel upon which Android is built will remain open source, since the Linux kernel is licensed under the GPLv2.

If Google were indeed intending to do this, what could happen is that Google takes Android closed source from here on out, spinning off whatever remains of AOSP up until that point into a separate company or project, as potentially ordered during the antitrust case against Google in the United States. This would leave Google free to continue developing its own “Pixel Android” entirely as proprietary software – save for the Linux kernel – while leaving AOSP in the state it’s in right now outside of Google. This technically means “AOSP is not going away”, as Chau claims.

Of course, other parties would then be free to continue working on and contributing to AOSP, but AOSP itself would no longer benefit from the work done by Google. Again, this feels very similar to how illumos and OpenIndiana are built atop the last open source release of Solaris from 2010, without any of the additional work Oracle has done on Solaris since then. As you can tell, there’s a lot of speculation here, because even if all of this is true, it seems the ongoing court case and any rulings that come of it will play a major role in Google’s decision-making process.

The Android Open Source Project has been gutted over the years, with Google leaving more and more parts of it to languish, while moving a lot of code and functionality into proprietary components like Google Mobile Services and Google Play Services. Taking “Pixel Android” closed source almost feels like the natural next step in the process of gutting AOSP that’s been ongoing for well over a decade. As it stands today, a default AOSP installation requires a lot of additional components and applications before it can be considered a complete mobile operating system, and if it were to be spun off into a separate, non-Google project to which Google itself contributes nothing, its future seems quite uncertain.

My own perception is that this is just one of the courses of action Google is considering in light of potentially being forced to spin off Android as part of the antitrust case in the United States. I doubt any decisions have been made yet, but if they go through with it, it would allow Google to develop “Pixel Android” in such a way that it wouldn’t benefit any of their Pixel competitors, unless these competitors specifically opt to license “Pixel Android” – assuming Google would even offer such licensing options. Regardless, it seems the Android world might be in for a shock.

GNOME has announced it’ll be increasing its dependency on systemd, the popular init system used by most (popular) Linux distributions. While GNOME already had a few relatively inconsequential dependencies on systemd, it was effectively not a huge problem to run GNOME on operating systems that don’t have systemd, which most notably includes the various flavours of BSD. That’s going to change.

There’s going to be two changes, one of which is relatively minor, and one of which will pose much bigger problems. The minor change involves GDM becoming dependent on systemd’s userdb infrastructure in order to clean up a lot of GDM’s code involved in multi-seat setups and remote login. Currently, this works through a series of hacks that the GDM developers are going to clean up, switching to using systemd-userdb to “dynamically allocate user accounts, and then runs each login screen as a unique user”.

To aid non-systemd environments during this transition, GDM will get a temporary alternate code path that enables you to run GDM without systemd-userdb. So if you compile GDM against elogind, GDM will use an alternative trick to enable multiple graphical sessions under the same user. This trick will remain in place at least until GNOME 50, but its future after that is uncertain.

The second change is much more involved.

Next, the bigger change. Since GNOME 3.34, gnome-session uses the systemd user instance to start and manage the various GNOME session services. When systemd is unavailable, gnome-session falls back to a builtin service manager. This builtin service manager uses .desktop files to start up the various GNOME session services, and then monitors them for failure. This code was initially implemented for GNOME 2.24, and is starting to show its age. It has received very minimal attention in the 17 years since it was first written. Really, there’s no reason to keep maintaining a bespoke and somewhat primitive service manager when we have systemd at our disposal. The only reason this code hasn’t completely bit rotted is the fact that GDM’s aforementioned hacks break systemd and so we rely on the builtin service manager to launch the login screen.

Well, that has now changed. The hacks in GDM are gone, and the login screen’s session is managed by systemd. This means that the builtin service manager will now be completely unused and untested. Moreover: we’d like to implement a session save/restore feature, but the builtin service manager interferes with that. For this reason, the code is being removed.

↫ Adrian Vovk

Mitigating this change will be a lot more involved for operating systems that don’t use systemd, and the blog post goes into detail into what, exactly, needs to be done in systemd-less environments. There’s quite a few systemd components and other little tidbits that you will need to find or create alternatives for, and considering you’ll need to have all of it in place roughly by GNOME 50, roughly a year from now, I can imagine this causing quite a few headaches for platforms like the BSDs and Linux distributions using init systems other than systemd.

With these changes, GNOME further solidifies itself as a Linux desktop only – and lest anyone forget, that’s entirely within their right to do. Systemd haters can jump up and down all they want, but in the end, they have no right to demand that GNOME developers spend precious time and resources testing GNOME on and developing it for platforms that they themselves do not use. They’re clearly targeting the trifecta of Linux, system, and Wayland, and that’s their choice to make, not anyone else’s.

Still, if operating systems like OpenBSD and FreeBSD, or Linux distributions without systemd intend to continue offering a fully functional GNOME desktop, they’re going to have some work to do.

Xeneva is an operating system for both x86_64 and ARM64 architectures, built from the ground up. The Kernel is known as ‘Aurora’ with hybrid kernel design and the entire operating system is known as ‘Xeneva’.

↫ XenevaOS GitHub page

It’s remarkably complete, with driver loading and linking, up to SSE 3 support, USB3 and Intel HD audio support, networking, and a whole lot more of the basics that make up a modern complete operating system. On top of all this, it also has a compositing window manager, a desktop environment, a terminal with VT100 support, Freetype2 font rendering, and much more. It also comes with a few basic applications like a file manager, calculator, audio player, and so on.

It’s written in C (and some C++), and uniquely, can only be built in a Windows environment, something you don’t see very often. It definitely looks quite impressive.

Today, we’re bringing you Android 16, rolling out first to supported Pixel devices with more phone brands to come later this year. This is the earliest Android has launched a major release in the last few years, which ensures you get the latest updates as soon as possible on your devices.

Android 16 lays the foundation for our new Material 3 Expressive design, with features that make Android more accessible and easy to use.

↫ Seang Chau at the Google blog

Android 16 doesn’t seem like a very big release, and that’s because for most users, it really isn’t. There’s some neat features in here, like improved notification grouping, live notifications, a slew of protection features for people who run increased risk (think journalists or victims of abuse), and proper desktop-style windowing on tablets, which seems like the tentpole feature for now. The Material 3 Expressive design is not really here yet, though as that will come in subsequent Android 16 updates.

The release for devices coincides with the release of the source code, which is no longer released as part of the development process, but dumped across the fence at release time. This means that those of us using a de-Googled Android ROM – I use GrapheneOS – will have to wait a bit longer than we’re used to before getting the new version.