This is entirely unsurprising. It's been clear that Google has been into their Android duopoly-abusive stage for a while now, with more and more of their Android changes moving into GMS or non-AOSP Google apps (like camera, messages, location services, etc) over the last decade. Graphene has been doomed to this fate for a long time, and anyone who thought otherwise was naively optimistic.
The same is clearly coming for Chromium forks, which is why I've always thought the privacy and ad-blocking forks are a joke - if they ever gain enough marketshare, or if google just tires of the public open source charade, they have no chance of maintaining a modern browser on their own.
This is all the more likely now that Google has been emboldened by not having to sell off Chrome for anticompetitive reasons.
Security patches aren't being delayed for AOSP specifically but rather Android as a whole including the stock Pixel OS. The title is misinterpreting our reply. We didn't say they're delaying patches to AOSP specifically. Stock Pixel OS has delayed patches too.
GrapheneOS has an OEM partner and early access to the security patches so our complaint isn't about us not having access. Google has added an exception to the embargo where binary-only patches can be released which we could use for a special security update branch but that's a ridiculous exception and it should be allowed to release the sources. It can be reversed from the security patches anyway and is trivial for Java and Kotlin. We can't break the embargo ourselves but we CAN publish the security patches early under the rules of the embargo via a special branch and people could reverse the patches from there which could then be applied to the regular GrapheneOS branch. The system is ridiculous and our hope is these changes are undone.
The title should really be changed from "for AOSP" to "for Android". There's a binary-only exception in the embargo now but that's not really about AOSP and isn't being used in practice even for Pixels. They've really just delayed all patches 4 months instead of 1 while also destroying any semblance of there being a real embargo (which was already very weak).
Thanks for the clarification. Delaying patches for all Android is even worse than delaying for AOSP. Excerpts below.
.. Google recently made.. misguided changes to Android security updates.. almost entirely quarterly instead of monthly to make it easier for OEMs. They're giving OEMs 3-4 months of early access which we know for a fact is being widely leaked including to attackers.
.. Google's existing system for distributing security patches to OEMs was already.. problematic. Extending 1 month of early access to 4 months is atrocious. This applies to all of the patches in the bulletins. This is harming Android security to make OEMs look better by lowering the bar.. The existing system should have been moving towards shorter broad disclosure of patches instead of 30 days.
.. Android's management has clearly overruled the concerns of their security team and chosen to significantly harm Android security for marketing reasons.. Android is very understaffed due to layoffs/buyouts and insufficient hiring.. Google does a massive portion of the security work on the Linux kernel, LLVM and other projects.. providing the resources and infrastructure for Linux kernel LTS releases. Others aren't stepping up to the plate.
This would be a good discussion topic for the Linux Plumbers conference in 3 months.
Just a year prior, I would have been against a decision to force Google to part with either Android or Chrome.
Now, I'm of the opinion that they should have been forced to sell off both, and maybe Chromebooks too, for the good measure.
No company with a direction as vile and openly user-hostile as what Google currently demonstrates should have anywhere near this level of control over the ecosystem.
They should lose YouTube as well. Remember how they used their control over YouTube to kill Windows Phone back in the day also. They should have lost it right then.
Google is very clearly an abusive monopoly, and has been for a very long time. We all overlooked it because they were mostly benevolent. That is no longer the case.
The sad thing is I think Google keeping Chrome is actually likely the better of two possible bad outcomes... Anyone else interested and willing to pay the true value of owning the entire Internet ecosystem is almost certainly going to look to extract value from that, and that's almost certainly worse than what Google does today. E.g. using everyone's browser to extract training data for AI without getting IP blocked.
Yep. If we’re gonna be forking browsers, Firefox should be the base, not Chromium. Mozilla is in much less of a position to abuse their position, and more Firefox forks means more chances that one catches on with some slice of the larger public and helps chip away at Blink hegemony.
Fully agreed. I am however worried by the fact that Firefox is basically kept alive by Google. I assume it's just so that they can pretend Chrome isn't a monopoly, but the minute Firefox becomes an inconvenience they can stop financing it. I hope we can find a way for Firefox to sustain itself long term.
Last time I suggested brave on hn to base off on Firefox and they said its pita but we have unpaid.volunteer run waterfox and others, then we have floorp, tor and others so I know for a fact brave not basing on Firefox is pure politics because of brendan
Our reply here was linked on Hacker News with an inaccurate title ("Delayed Security Patches for AOSP"). Security patch backports were pushed to AOSP on September 2nd for Android 13, 14 and 15 as expected.
More information is available at x.com/GrapheneOS/sta… explaining the situation with security patches. It would be better to have a thread linking to that instead. We have early access to the security patches, but we can't break the embargo. We can only release the sources once source release is allowed. We could make a security preview branch but the system simply doesn't make sense.
Android 16 QPR1 is a new major release, not a security patch release. Our reply is talking about 2 different issues. Android 16 QPR1 is what was delayed for AOSP and we don't currently know why. It's possible it was a mistake and it will be pushed on Monday.
"No tags were pushed to AOSP for the July 2025 monthly release of Android. We asked about this on the android-building group but each of our posts was rejected. We emailed people at Google we've previously contacted about mistakes pushing tags but received no response this time."
That's about the monthly and quarterly releases of Android, not the Android security patches. The post title is misinterpreting what's wrong. There is a lot wrong but that's not it. The baseline Android security patches are being delayed for Android as a whole, not AOSP specifically.
Not having the very tiny monthly updates pushed to AOSP is an annoyance which will delay a subset of non-security bug fixes until the quarterly releases. It's a bad change, although we know have a good idea why it happened and need the reason it happened to be reversed for them to push those again.
We've been told by multiple people at Google that the quarterly releases would still be pushed and that monthly releases are largely being phased out. However, the quarterly update was not pushed as expected on September 3rd. If it's pushed on Monday, it will be 6 days late. There hasn't been a similar delay for quarterly and yearly releases in the past.
GrapheneOS can still provide security updates but not having the quarterly release is a major problem and it's not clear why it wasn't pushed when they said it was going to be pushed.
There's a separate issue not specifically tied to AOSP impacting security patches which is what the initial part of our reply was about. See https://x.com/GrapheneOS/status/1964754118653952027 for an explanation.
Serious question: do we know as a matter of fact that iOS and family are safer than Android, including Pixel, especially when it comes to 0-day exploits?
The title of this post linking our reply is inaccurate and is not what we said ("Delayed Security Patches for AOSP"). It should really be changed from "for AOSP" to "for Android". Security patch backports were pushed to AOSP on September 2nd for Android 13, 14 and 15 as expected. The issue isn't the security patches being delayed for AOSP. We didn't say patches are being delayed for AOSP.
Security patches for Android are being delayed as a whole. The delays aren't specific to AOSP. They're moving to quarterly security updates with 4 months of early OEM access instead of monthly security updates with 1 month of early OEM access. They realize that the patches distributed to OEMs are hardly secret once they're so broadly distributed. Therefore, they've relaxed the rules of the embargo and permitted releases of patches under certain rules without being allowed to providing a description or the sources for the patch. This is ridiculous because it's easy to reverse the patches from binary-only releases.
Google trying to cover for OEMs not keeping up with patches by making it seem as if the patches are now quarterly and largely being delivered on time while actually broadly disclosing them 4 months early and permitting quietly fixing them early.
Google sold Android to nerds as open source. We thought that mobile operating systems would be won by the "Linux of mobile OSs."
But Google has made sure that didn't happen and we're left with devices more locked down than the proprietary Windows ecosystem we were hoping to leave in the past - and with a company in charge looking to exert even more power over us than Microsoft did.
The trick is adding a ton of features which expose extra attack surface that needs them to maintain and fix, under the pretense that it will make everyone's life easier. Make it complicated enough so that the community cannot maintain it, enabling the corporation to throw its weight around.
It’s the perfected form of what MS was trying to achieve with IE back in the 90s. All the power of a closed source monopoly, further enhanced by friends and foes alike incorporating your tech as a load-bearing pillar of their strategies, with a cloak of plausible deniability in the form of an open source repo protecting you from antitrust enforcement. A true have your cake and eat it situation.
This is what happened with the Qt app dev framework. The Qt Company delayed releases of LTS updates to non-paying users by 1 year, while not properly dealing with the steady stream of regressions that were affecting normal releases. I quit Qt development partially because I felt that I was dealing with forever-beta software.
But actually, with Qt you do have KDE devs who push their own patches which does help deal with the flaws in the upstream project.
In the Android world, they need more devs doing the same and supporting projects like GrapheneOS with security testing/hardening.
Security of the Android ecosystem should not be compromised just to make the lives of Googlers easier in handling the public, internal, and pixel branches of AOSP.
Edit: The HN title is false and security patches were released. But this is more about Google trying to appease OEMs who aren't capable with keeping up with a monthly OS release schedule.
The reason this happens is that greedy companies like Google have made apps the de facto way to get anything done.
There's 0 reason you should need an app to fucking pay for parking. Why do you then?
Because running mostly unsandboxed native code on customers devices is a fantastic way to steal data and build profiles. Browsers just don't cut it - they're too safe, too secure, too abstracted.
Let's be honest here - what is a banking app? Web forms, some more web forms, and then to top it off, some web forms. I mean, hell, half these apps are just web views with spywa - I mean analytics - slapped on top.
The same is clearly coming for Chromium forks, which is why I've always thought the privacy and ad-blocking forks are a joke - if they ever gain enough marketshare, or if google just tires of the public open source charade, they have no chance of maintaining a modern browser on their own.
This is all the more likely now that Google has been emboldened by not having to sell off Chrome for anticompetitive reasons.
A more detailed explanation is at https://x.com/GrapheneOS/status/1964754118653952027.
GrapheneOS has an OEM partner and early access to the security patches so our complaint isn't about us not having access. Google has added an exception to the embargo where binary-only patches can be released which we could use for a special security update branch but that's a ridiculous exception and it should be allowed to release the sources. It can be reversed from the security patches anyway and is trivial for Java and Kotlin. We can't break the embargo ourselves but we CAN publish the security patches early under the rules of the embargo via a special branch and people could reverse the patches from there which could then be applied to the regular GrapheneOS branch. The system is ridiculous and our hope is these changes are undone.
The title should really be changed from "for AOSP" to "for Android". There's a binary-only exception in the embargo now but that's not really about AOSP and isn't being used in practice even for Pixels. They've really just delayed all patches 4 months instead of 1 while also destroying any semblance of there being a real embargo (which was already very weak).
Deleted Comment
Now, I'm of the opinion that they should have been forced to sell off both, and maybe Chromebooks too, for the good measure.
No company with a direction as vile and openly user-hostile as what Google currently demonstrates should have anywhere near this level of control over the ecosystem.
Google is very clearly an abusive monopoly, and has been for a very long time. We all overlooked it because they were mostly benevolent. That is no longer the case.
Would you start to actually pay for all those hundreds of engineers maintaining the OS?
Exactly. The only thing that can prevent this behaviour is regulations. But apparently nobody wants to regulate, so we're screwed.
https://x.com/grapheneos/status/1964757878910136346?s=46
They say this:
Our reply here was linked on Hacker News with an inaccurate title ("Delayed Security Patches for AOSP"). Security patch backports were pushed to AOSP on September 2nd for Android 13, 14 and 15 as expected.
More information is available at x.com/GrapheneOS/sta… explaining the situation with security patches. It would be better to have a thread linking to that instead. We have early access to the security patches, but we can't break the embargo. We can only release the sources once source release is allowed. We could make a security preview branch but the system simply doesn't make sense.
Android 16 QPR1 is a new major release, not a security patch release. Our reply is talking about 2 different issues. Android 16 QPR1 is what was delayed for AOSP and we don't currently know why. It's possible it was a mistake and it will be pushed on Monday.
https://x.com/GrapheneOS/status/1964754118653952027
https://bsky.app/profile/grapheneos.org/post/3lyb6rx46tc2r
https://grapheneos.social/@GrapheneOS/115164133992525834
https://xcancel.com/GrapheneOS/status/1952413110947430786
"July monthly release was not pushed to AOSP and then neither was the August monthly release. September quarterly release hasn't been pushed yet."
https://xcancel.com/GrapheneOS/status/1963812920673861981
Not having the very tiny monthly updates pushed to AOSP is an annoyance which will delay a subset of non-security bug fixes until the quarterly releases. It's a bad change, although we know have a good idea why it happened and need the reason it happened to be reversed for them to push those again.
We've been told by multiple people at Google that the quarterly releases would still be pushed and that monthly releases are largely being phased out. However, the quarterly update was not pushed as expected on September 3rd. If it's pushed on Monday, it will be 6 days late. There hasn't been a similar delay for quarterly and yearly releases in the past.
GrapheneOS can still provide security updates but not having the quarterly release is a major problem and it's not clear why it wasn't pushed when they said it was going to be pushed.
There's a separate issue not specifically tied to AOSP impacting security patches which is what the initial part of our reply was about. See https://x.com/GrapheneOS/status/1964754118653952027 for an explanation.
The title of this post linking our reply is inaccurate and is not what we said ("Delayed Security Patches for AOSP"). It should really be changed from "for AOSP" to "for Android". Security patch backports were pushed to AOSP on September 2nd for Android 13, 14 and 15 as expected. The issue isn't the security patches being delayed for AOSP. We didn't say patches are being delayed for AOSP.
Security patches for Android are being delayed as a whole. The delays aren't specific to AOSP. They're moving to quarterly security updates with 4 months of early OEM access instead of monthly security updates with 1 month of early OEM access. They realize that the patches distributed to OEMs are hardly secret once they're so broadly distributed. Therefore, they've relaxed the rules of the embargo and permitted releases of patches under certain rules without being allowed to providing a description or the sources for the patch. This is ridiculous because it's easy to reverse the patches from binary-only releases.
Google trying to cover for OEMs not keeping up with patches by making it seem as if the patches are now quarterly and largely being delivered on time while actually broadly disclosing them 4 months early and permitting quietly fixing them early.
We posted a much more detailed explanation at https://x.com/GrapheneOS/status/1964754118653952027. It would be better to link to our more detailed post.
But Google has made sure that didn't happen and we're left with devices more locked down than the proprietary Windows ecosystem we were hoping to leave in the past - and with a company in charge looking to exert even more power over us than Microsoft did.
But actually, with Qt you do have KDE devs who push their own patches which does help deal with the flaws in the upstream project.
In the Android world, they need more devs doing the same and supporting projects like GrapheneOS with security testing/hardening.
Edit: The HN title is false and security patches were released. But this is more about Google trying to appease OEMs who aren't capable with keeping up with a monthly OS release schedule.
In what scenario is this a serious threat because I can't think of any.
and this identification does nothing about that, this is not to protect users. such phishing are always found on play-store alone.
There's 0 reason you should need an app to fucking pay for parking. Why do you then?
Because running mostly unsandboxed native code on customers devices is a fantastic way to steal data and build profiles. Browsers just don't cut it - they're too safe, too secure, too abstracted.
Let's be honest here - what is a banking app? Web forms, some more web forms, and then to top it off, some web forms. I mean, hell, half these apps are just web views with spywa - I mean analytics - slapped on top.
The problem represented in the tweet is deeper. It is about not receiving patches which means the device is basically unsafe to use altogether.