Backports, quarterly releases, security patches, embargoes

Graphene1

With the QPR1 delay can someone explain to me like I'm five what's going on?

I know the quarterly QPR1 is delayed to AOSP and therefore delayed for GOS, are security patches also delayed as part of this?

What's a backport and what's been embargoed?

I have read some of the linked responses in other threads but I still don't understand fully what they mean or what the result is.

Watermelon

Graphene1 I believe I got most of the details correctly. Let's break it down:

Backporting: The act of taking a feature, program, etc from the future and making the necessary tweaks and release procedure to make it available on something in the past. This is a general definition because it's not specific to GrapheneOS or even Android. There's two kinds of backports relevant here to GrapheneOS, see below.

AOSP (Android Open Source Project): AOSP publishes a new major version every quarter of a year. Once per four of them is a yearly release with a major version increment, the others are Quarterly Platform Releases (QPRs). The GrapheneOS project said that QPRs are as large as yearly releases, they just keep many future features in disabled state (although Android 16 QPR1 is a good counterexample due to how different it is from the original Android 16). Every new major version (yearly and quarterly) has security design improvements (changing architecture of things to work more securely) and security patches (patches for specific vulnerabilities discovered).

ASB (Android Security Bulletin): ASBs are Android's backports of security patches from the latest major AOSP version to the last three to four yearly AOSP versions (currently the original Android 16, original Android 15, original Android 14, and original Android 13). The GrapheneOS project says that these backports are incomplete because they don't backport all of the security patches from the latest AOSP version.

PUB (Pixel Update Bulletin): These are the vulnerabilities in Pixel device code like Pixel firmware, Pixel drivers, etc. As far as I understand, not only is Pixel device code closed source, but (at least the firmware) must be signed by Google and thus must be built by Google and none of it can be modified by GrapheneOS. Google always ships the latest major AOSP version in the stock Pixel OS, thus they create Pixel device code for it in mind.

Now to the two backporting issues at hand here:

PUB: GrapheneOS had to backport the Pixel device code from the Android 16 QPR1 release of the stock Pixel OS onto the Android 16 releases of GrapheneOS that we use now to provide the security patches in the device code. This is because Google has yet to publish any AOSP release at all in the past three months despite promising back in June that “AOSP is NOT going away”, so GrapheneOS had to retrofit the future device code onto the GrapheneOS releases based on an earlier major AOSP version. This may not be possible to continue doing in the future, for example the GrapheneOS project said that at the previous time they had to do this (backport Android 16 device code to Android 15 QPR2 GrapheneOS releases) was only possible because Android 16 and Android 15 QPR2 were similar to each other and wouldn't have been possible to backport it to the original Android 15 release. So Google must release AOSP as soon as possible, or we're screwed.
ASB: Ignoring all the thing with the embargos, the ASBs are still incomplete backports, so GrapheneOS must have the latest major AOSP version to have all of the security patches and security design improvements of AOSP.

Regarding the embargos: Google used to release security patches (both as new AOSP releases and as backports in the form of ASBs) on a monthly basis. This was awful because it means they wait a whole month before fixing security vulnerabilities they were already aware of, but it was even more awful because they provided early access for manufacturers to both AOSP releases and ASBs, so they were distributed “internally” rather than kept secret, or fixed as they should've been.

But in June/July Google changed it so that there's no more minor monthly AOSP releases, only quarterly and yearly, and basically no more ASBs when there's no AOSP release in the month. Even worse, each month's ASBs are finalized early in the month previous to it — any more vulnerabilities patched will not be patched in the coming month's ASB, but in its next month (i.e. at least a whole month later). The former extends the unpatched time from 1 month to 3 months, and the latter from 3 months to 4 months. Even worse, Google is now permitting to release the embargoed patches to the public in built form without source code, making it even easier for attackers to reverse engineer the built form to see what was fixed, without having to hack/bribe/etc anyone who has access to the “internal” distribution of the embargoed patches. This doesn't impact manufacturers who make non-open source Android versions, but impacts GrapheneOS which is an open source project that wants to publish corresponding source code for their releases.

GrapheneOS wants to abuse this for their own benefit: publish patched built form releases containing the embargoed patches separate from the main releases, let external people reverse engineer them and publish source code for the embargoed patches based on that, and then GrapheneOS can take the embargoed patches from these external people and apply it to the main releases we use in our devices because the patches are then public. They don't necessarily have to wait for people to reverse engineer their patched built form GrapheneOS releases, as the GrapheneOS project also calls for whistleblowers to leak publicly the embargoed patches source code that's distributed “internally” to manufacturers.

This is why the GrapheneOS project published a post saying that they can release the December 2025 patches right now (i.e. in a built form without corresponding source code in a separate release from the main ones we have on our devices, and in the main releases if external people would be kind enough to leak the embargoed patches or reverse engineer the built form releases and create the unpublished corresponding source code), and why they now raised the security patch level to 2025-10-01. The 2025-10-01 security patch level was finalized a few days ago (early September). The 2025-12-01 security patch level isn't finalized yet, as more patches could be added to it over time, so GrapheneOS can't raise the claimed patch level within the OS to it yet. Depending on whether the 2025-10-01 security patch level contains zero or at least one security patch: if zero, then GrapheneOS didn't have to break any embargo to deliver us this update; if at least one, that means that GrapheneOS's plan to abuse Google's embargo system is already working, because Google hasn't published the 2025-10-01 ASB yet (it's still embargoed).

I asked a GrapheneOS project member in private and was told that Google's embargos on the patches don't prevent the GrapheneOS project from informing us whether the main GrapheneOS releases contain all of the currently embargoed patches. This means that GrapheneOS could inform us whether we're fully patched, because the security patch level doesn't (and never was, but now it's just significantly worse) inform us whether we're truly fully patched against all known vulnerabilities.

fph

I hope I'm describing everything correctly:

A backport is a kind of security fix.

From now on, Google is going to give Android security fixes to phone manufacturers with the instructions not to publish their source code for the following 3 months.

In theory, this is good because publishing their source code would also reveal the vulnerabilities that they fix to the Bad Guys; so in this way the phone manufacturers have 3 months to adapt the patches to their phones and publish the updates.

Previously this embargo period was one month only, and most phone manufacturers struggled to publish updates in that time frame (mostly because of lack of effort, not because of technical limitations.)

In real life, this countermeasure is ineffective: a truly dedicated Bad Guy (like NSO or state actors) has no problems getting the source code of these updates: they can either decompile the binaries, or bribe one of the thousands of people that get them at phone manufacturers around the world.

The phone manufacturers are happier this way, because it gives them more time and lets them continue being lazy. The Bad Guys are happier this way, because it means that phones will stay without security fixes for longer.

The Graphene OS team is unhappy, because they would have liked to continue publishing these fixes immediately, and to do so following good open source practices. Instead, they will have to switch to publishing binary-only updates to a separate channel.

Graphene1

So this means the usual GrapheneOS security patches/ updates will be three months behind PixelOS until GOS become a manufacturer?

wizoatk

Graphene1

Not necessarily, and probably not. The expectation is that either the embargoed source might leak, or that someone will reverse engineer the binaries (which are not embargoed), or that the project will release binary only versions in addition to the normal releases, or some combination. It's also a possibility that Google will reconsider their questionable reasoning.

fph

Graphene1 So this means the usual GrapheneOS security patches/ updates will be three months behind PixelOS until GOS become a manufacturer?

If I understand correctly, Graphene OS developers already have the same early access level to patches as phone manufacturers, so that's not the issue.

The devs wrote that they are considering a separate binary-only early update channel, so they can release the patches (without source, unfortunately) as soon as they are released by Google.

Graphene1

wizoatk what do you mean by binary and how would the end user be impacted with binary only releases?

wizoatk

Graphene1

ELI5: Source code is text that is human readable and is compiled by developers to machine readable binary images which are then copied and loaded onto end devices (phones).

For the vast majority of end users there would be no fuctional impact. They only directly use compiled binaries (and packages and images) now. For the relatively small number of people that build their own images, they would have to wait for source updates for the security patches to become available.

The overall impact would be significantly more work for the project to do to maintain two sets of releases.

My hope is that common sense will prevail and things might reach a new relative normal some time around QRP2 release in early December.

Watermelon

wizoatk For the vast majority of end users there would be no fuctional impact. They only directly use compiled binaries (and packages and images) now. For the relatively small number of people that build their own images, they would have to wait for source updates for the security patches to become available.

This isn't true. The GrapheneOS project said that the main releases of GrapheneOS would still have corresponding source code published to keep them open source, and the binary-only builds with the embargoed patches would be in separate releases. They didn't say whether these binary-only releases would be installable as optional OTA update packages on top of the main releases, it's possible that they won't.

wizoatk

Watermelon This isn't true.

The context for my previous post was, if the project creates parallel binary only releases in addition to the standard releases and if an end user chooses to use/test/reverse-engineer the binary only release then [...].

Watermelon it's possible that they won't.

That's certainly true. I didn't mean to imply that decisions have already been made. Just one of possible things being discussed to preclude GrapeneOS users from having to wait 3-4 extra months for security updates.

Watermelon

Watermelon Just two more additions:

GrapheneOS didn't raise the claimed security patch level to 2025-10-05 (rather than 2025-10-01 which we have now), as far as I know, because the Pixel device code is kept secret at Google and not properly released by them yet (remember, it's closed source and GrapheneOS can't modify it, so it has to run properly). Or it's just not yet finished, unlike the October 2025 ASB which was finalized a few days ago.
The GrapheneOS project hasn't said yet whether their separate patched built form releases would be installable on users' devices running the main releases as an opt-in OTA update. It seems clear that they would make it opt-in rather than opt-out because they want to keep GrapheneOS open source. And maybe they wouldn't be installable (i.e. users would have to factory reset to install the patched releases instead of installing nicely as an optional OTA update).

wizoatk

Watermelon

Well done!

de0u

Watermelon Google used to release security patches (both as new AOSP releases and as backports in the form of ASBs) on a monthly basis.

And they used to release Pixel-specific driver source code into AOSP monthly so that up-to-date AOSP could be built on Pixels. That is over, so the official AOSP target is an emulator (a different emulator from the one that plugs easily into Android Studio, I believe).

Overall, at present the job the GrapheneOS project is working on is maybe twice as hard as it was. At least for a while people might consider dialing back requests for new features, and/or might consider contributing some code.

Another way to contribute would be to buy a second device, sign it up for the alpha-release channels for system and app updates, and test to make sure that important things still work when a new release is announced. More testers would help.

Please note that I do not speak for the GrapheneOS project.

Graphene1

Thanks both. Great info