GrapheneOS

GrapheneOS TalkBack version 23 released: github.com/GrapheneOS/T... See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog. Forum discussion thread: discuss.grapheneos.org/d/43100-grap... #GrapheneOS #privacy #security

Google made a change to their RCS service breaking using it for a small number of users. It's likely in the process of being rolled out and is gradually causing issues for more users. We're already working on resolving it. It isn't caused by the OS update about to move to Stable.

Resolving this before it impacts a much larger number of users is one of our highest priorities. It's likely only going to be possible to resolve it with an OS update rather than a GmsCompatConfig release. We've only just started working on it so we don't know the cause yet.

Our latest OS release moved to using the Linux 6.18 LTS branch for both arm64 and x86_64 for the emulator, Cuttlefish and microdroid targets. We've made a highly experimental port of the Pixel kernel drivers to 6.18 and are planning on moving to it across all supported devices.

We've successful made an initial port for using the upstream LTS branch for Pixels. We need to do a massive amount of code review and fixing regressions. Once we have it shipped, it will become trivial to ship each upstream revision, although those do often introduce regressions.

Our latest OS release moved to using the Linux 6.18 LTS branch for both arm64 and x86_64 for the emulator, Cuttlefish and microdroid targets. We've made a highly experimental port of the Pixel kernel drivers to 6.18 and are planning on moving to it across all supported devices.

Google wasted an enormous amount of resources to develop GKI. It was supposed to make it much easier to keep Android devices on an up-to-date kernel. It's a disastrous failure. It does not make it substantially easier because updating kernel drivers for LTS ABI changes is easy.

Our latest OS release moved to using the Linux 6.18 LTS branch for both arm64 and x86_64 for the emulator, Cuttlefish and microdroid targets. We've made a highly experimental port of the Pixel kernel drivers to 6.18 and are planning on moving to it across all supported devices.

The main purpose of the Android GKI branch is to implement a stable ABI for kernel drivers. The ABI is only stable within an LTS branch. It has no practical use case and a massive maintainability cost. This system collapsed under the massive increase in Linux kernel patches.

Our latest OS release moved to using the Linux 6.18 LTS branch for both arm64 and x86_64 for the emulator, Cuttlefish and microdroid targets. We've made a highly experimental port of the Pixel kernel drivers to 6.18 and are planning on moving to it across all supported devices.

The changes required to move the Pixel drivers from 6.1, 6.6 and 6.12 to 6.18 are tiny. The changes needed to use the upstream 6.18 LTS ABI instead of the stable 6.18 GKI LTS ABI are larger but quite manageable. It's preserving all the extra improvements which is extremely hard.

Our latest OS release moved to using the Linux 6.18 LTS branch for both arm64 and x86_64 for the emulator, Cuttlefish and microdroid targets. We've made a highly experimental port of the Pixel kernel drivers to 6.18 and are planning on moving to it across all supported devices.

We have a Pixel 7 working with the upstream Linux 6.18.58 release. We'll be getting all supported devices fully working with all hardware functionality. The upcoming Motorola flagship uses a fork of the 6.18 GKI LTS branch and we'll need to port it to the upstream kernel too.

Our latest OS release moved to using the Linux 6.18 LTS branch for both arm64 and x86_64 for the emulator, Cuttlefish and microdroid targets. We've made a highly experimental port of the Pixel kernel drivers to 6.18 and are planning on moving to it across all supported devices.

Our discussion forum is the only software we have using PHP. We've taken it down temporarily while waiting for the patches for www.php.net/archive/2026... due to vulnerability details already being available and proof of concept exploits being developed. Don't want to take the risk.

From one of the PHP core developers: phpc.social/@Girgias/117... > The only thing I can say is that the only mitigation is patching / upgrading PHP. I sadly know too much.

Our discussion forum is the only software we have using PHP. We've taken it down temporarily while waiting for the patches for www.php.net/archive/2026... due to vulnerability details already being available and proof of concept exploits being developed. Don't want to take the risk.

This is the new GrapheneOS boot animation. It's generated frame-by-frame using a script. It has a minimum 3.5s total runtime for the intro including a small pause. The rest of the animation gets interrupted once the device is booted to avoid any delay so there can't be an outro.

The animation included in 2026101600 holds the logo for 0.8s rather than 2.0s in the video above since the new zips weren't committed to the OS yet. We've reduced that to 1.6s though. For the Pixel Tablet, we've reduced the size of the logo to 30% of the screen height from 40%.

This is the new GrapheneOS boot animation. It's generated frame-by-frame using a script. It has a minimum 3.5s total runtime for the intro including a small pause. The rest of the animation gets interrupted once the device is booted to avoid any delay so there can't be an outro.

Android Security Bulletins have been twisted into a way to mislead the public about security. Patches are only listed in the bulletins 2-6 months after they're disclosed to each Android OEM and allowed to be shipped. Patches listed in the September 2026 bulletin were available to ship for months.

Each Android Security Bulletin also has a 2nd section with listing an extraordinarily small subset of the vulnerabilities patched in the upstream Linux kernel along with a small subset of vulnerabilities patched in drivers/firmware shared by many devices. This is deliberate to keep the bar very low.

Android Security Bulletins have been twisted into a way to mislead the public about security. Patches are only listed in the bulletins 2-6 months after they're disclosed to each Android OEM and allowed to be shipped. Patches listed in the September 2026 bulletin were available to ship for months.

In 2026, Google has been completely overwhelmed by the volume of vulnerabilities being discovered by AI models both internally and externally. They recently announced to OEMs that the full set of High and Critical severity patches will only be available through the latest yearly and QPR2 releases.

Android Security Bulletins have been twisted into a way to mislead the public about security. Patches are only listed in the bulletins 2-6 months after they're disclosed to each Android OEM and allowed to be shipped. Patches listed in the September 2026 bulletin were available to ship for months.

The security preview patches aren't only for Android projects but rather also include patches to external projects. Some of these external patches are already publicly disclosed while others are not. As one example, there have been non-publicly-disclosed security preview patches for wpa_supplicant.

Android Security Bulletins have been twisted into a way to mislead the public about security. Patches are only listed in the bulletins 2-6 months after they're disclosed to each Android OEM and allowed to be shipped. Patches listed in the September 2026 bulletin were available to ship for months.

Android Security Bulletins are divided into two sections. The first section contains High and Critical severity Android Open Source Project (AOSP) patches backported to older releases. For years already, Low and Moderate severity AOSP patches have required updating to the latest major releases.