GrapheneOS has fixed the Android 17 QPR1 kernel performance regression
Thread
Loading the complete thread in the background. This saved snapshot is available now. Refresh
Unofficial Hacker News client; not affiliated with Y Combinator.
GrapheneOS has fixed the Android 17 QPR1 kernel performance regression
Loading the complete thread in the background. This saved snapshot is available now. Refresh
Unofficial Hacker News client; not affiliated with Y Combinator.
LoganDark · · focus · HN ↗
This is such a rarity to see in today's world. I'm glad GrapheneOS is getting the support it needs. I wish that happened more often.
[deleted] · · focus · HN ↗
[deleted]
0fflineuser · · focus · HN ↗
The lags are actually quite unpleasant and noticable, i wonder how it wasn't caught before the release.
ncr100 · · focus · HN ↗
microtonal · · focus · HN ↗
Pixel 11 series received a bug fix release near the start of September 2026 with the 2026-09-01 patch level. That update wasn't Android 17 QPR1 and also doesn't include the September 2026 Pixel firmware/driver security patches. Perhaps they noticed this issue and cancelled it.
pjjpo · · focus · HN ↗
Sorry but at this point, for me it is shame on every Googler for continuing at a company that has absolutely no interest in user experience anymore. It's on you, directly or indirectly.
grapheneos · · focus · HN ↗
Early in the month, the Pixel 11 series received a partial September 2026 security update release. Those didn't receive Android 17 QPR1 on September 15th. Pixel 11 series users aren't on the latest major release of Android so they don't have the latest and greatest features. It's likely it was cancelled for the Pixel 11 series due to regressions but they still released it for the older generations of Pixels.
pjjpo · · focus · HN ↗
GrapheneOS looks really good thanks for working on it. Unfortunately Google Pay is critical for me and it's unfortunate Google is gatekeeping that, but I will look on jealously.
d2kx · · focus · HN ↗
garbagewoman · · focus · HN ↗
grapheneos · · focus · HN ↗
williamtell · · focus · HN ↗
306bobby · · focus · HN ↗
notpushkin · · focus · HN ↗
306bobby · · focus · HN ↗
That's a big pain point for the average user
subscribed · · focus · HN ↗
notpushkin · · focus · HN ↗
RandomGerm4n · · focus · HN ↗
306bobby · · focus · HN ↗
306bobby · · focus · HN ↗
grapheneos · · focus · HN ↗
Andromxda · · focus · HN ↗
snaker · · focus · HN ↗
[dead]
notpushkin · · focus · HN ↗
EU banks are hit and miss, but e.g. LHV and Wise both work fine. (Wise might limit some functions if it detects root, but custom ROMs seem to be okay. It also has most of the functions available in the web version anyway.) N26 is flaky (sometimes it just works for me, sometimes refuses to even log in; no idea what’s wrong). Revolut has lost me as a user.
Smart-ID (used in Estonia) has been working fine for me, but they seem to limit biometric signup on custom ROMs. But you can sign up using ID card and a USB reader, so it’s only mildly inconvenient.
Now, of course, YMMV in other countries, but I think my final point still stands: we can fight it.
306bobby · · focus · HN ↗
I just also like to be a realist, and right now things look a bit grim
surajrmal · · focus · HN ↗
infogulch · · focus · HN ↗
grapheneos · · focus · HN ↗
infogulch · · focus · HN ↗
bitpush · · focus · HN ↗
BlackRabbit1 · · focus · HN ↗
bitpush · · focus · HN ↗
Dylan16807 · · focus · HN ↗
bitpush · · focus · HN ↗
Am I surprised that a bug happened in Pixel? Sure. Is there a cause to call for better processes? Yes. But saying "well well well, I fixed the bug" just comes across very amateur.
Dylan16807 · · focus · HN ↗
The point of the post is not that grapheneos made the fix, it's that they had to.
HybridStatAnim8 · · focus · HN ↗
Andromxda · · focus · HN ↗
stkdump · · focus · HN ↗
HybridStatAnim8 · · focus · HN ↗
[deleted] · · focus · HN ↗
[deleted]
grapheneos · · focus · HN ↗
Android 17 QPR1 is also a Pixel OS exclusive release of Android not available to ship by other OEMs and not released as part of the Android Open Source Project. We have Android 17 QPR1 firmware, drivers and HALs since we can obtain all of the kernel sources and we largely switched to using the Pixel OS builds of the userspace code for Android 16 and later. It's one of the problems which will be solved through our partnership with Motorola where they're not only going to be providing everything we need but also helping us port and maintain GrapheneOS for their devices. This is quite the contrast with Google making it increasingly hard to support Pixels.
Prior to Android 16, each monthly and quarterly release of Android used to be pushed to AOSP. Those are now Pixel OS exclusive and there are only 2 releases per year for both Google's OEM partners and AOSP-based projects to use. Google also ended the AOSP main branch where large portions of Android were developed in public. This all makes it far more difficult to contribute anything upstream. It also makes it quite clear that those contributions are unwelcome.
Android's security preview system for security patches where patches are shared with OEMs and allowed to be shipped without sources months in advance is another way things have become more hostile. We have access to the security preview patches and are the only OS fully shipping the patches in advance. GrapheneOS gets most of the Android Security Bulletin patches months before the Pixel OS or other OEMs. Samsung is also shipping a subset of these patches early. Neither Google or Motorola are the ones providing the patches to us, but we're still required to follow the rules by not releasing the sources early so we have 2 separate variants of each GrapheneOS release with and without the patches. We used to have security partner access from Google granted by the head of the Android security team at the time, but Android's business team found out and had it revoked. We stopped reporting as many vulnerabilities upstream after this happened. Why should we share what we discover with them when they don't share it with us even when they do with other OEMs?
Play Integrity API device and strong integrity levels combined with heavily pushing adopting it in Android Studio and the Play Console is the elephant in the room. It bans using GrapheneOS despite it being far more secure than any of what it permits using. Google has made it clear they wouldn't allow us to get certified even if we were willing to follow all of their highly anti-competitive and anti-privacy restrictions in the Compatibility Definition Document. Google also has the Play Integrity API integrated as an opt-in store listing filter for Play Store apps which developers are encouraged to adopt.
Google also appears to have explicitly asked their engineers to stop communicating much with open source projects based on AOSP and others. There was a regular meeting set up between open source projects based on AOSP and Google engineers which was cancelled and the person who set it up then left the company. Nowadays, we can contact people there as we used to and get little in the way of a response. We contact them about actual issues all the time and are met with radio silence. We can use their regular issue tracker where they'll close most of what we report as WONTFIX without even trying to understand what we're talking about.
Google also funded and participated in publishing AI slop paper with blatant misinformation about GrapheneOS falsely claiming it has missed security patches it hasn't. The first security patch on their list of hallucinated missed patches was literally reported by us to Android in one of the first Android security bulletins. Google has yet to acknowledge our valid complaints about the paper. Someone working at a company we're working with filed a formal complaint with the IEEE.
GrapheneOS was not created as an anti-Google project and we made substantial contributions upstream for years. We were on good terms with their security team including leadership and many of their engineers for many years. Google has changed and so has Android. It's only reluctantly kept as an open source project, likely because they realize there would be major regulatory and legal action against them for not following their word and doing a rug pull. They did do that rug pull for Pixels despite selling the Pixel 9a and earlier as Android Open Source Project reference devices and committing to 7 years of updates for the last 2 generations sold as AOSP reference devices (9th/8th gen) and 5 years for the prior 2 generations (7th/6th gen).
Google has become a very poor steward of Android. Many of Google's Android OEM partners are increasingly unhappy with the overall direction of Android towards more control and restrictions from Google. Samsung has been given special rules without the same anti-competitive restrictions imposed on other Android OEMs due to their outsized market share and court victories in South Korea. For example, non-Samsung Android OEMs aren't allowed to directly sell devices with GrapheneOS and Google will only permit it within a quota. It can and is being worked around and there will be devices sold with GrapheneOS as the stock OS without Google restricting how many can be sold.
drewfax · · focus · HN ↗
Wow, that is so cheap of Google. That company has lost all it's values and deserves to die.
They built their empire with open source projects including Debian, KDE's KHTML (Webkit predecessor), Linux kernel, MySQL etc. But now, these leeches won't even allow OEMs to use different flavor of Android.
gib444 · · focus · HN ↗
spottedmarley · · focus · HN ↗
Itoldmyselfso · · focus · HN ↗
1: <a href="https://redlib.catsarch.com/r/GooglePixel/comments/1wr1767/comment/pd2l9vb/" rel="nofollow">https://redlib.catsarch.com/r/GooglePixel/comments/1wr1767/c...
grapheneos · · focus · HN ↗
Android is supposed to have memory pressure during regular use on devices without a lightweight setup which it's supposed to quickly handle by killing frozen cached app processes, trimming unused memory across cached/background apps and much more. Many users have tons of apps installed so they depend on this more. Some users have multiple profiles (Private Space, work profile, secondary users) and other setups increasing memory usage.
Reducing the background process limit has a high cost to usability and won't solve the issue. It will reduce memory usage and therefore reduce how much memory pressure needs to be handled. There are better ways to reduce memory usage including disabling AI Core to free around 3GB of memory which isn't applicable to GrapheneOS.
In general, we recommend not having developer options enabled in production due to the issues created by many of the options which appear benign. Using ADB also heavily reduces security by placing massive trust in another computer. GrapheneOS adds a user-facing log viewer outside of developer options in the Settings app because we don't want people to need developer options and have more similar improvements planned.
mmooss · · focus · HN ↗
GOS can just talk about the upside, their solution to this problem. That's great work. But they often choose to denigrate others, which is destructive, damages relationships (the most essential assets - especially when you have no money to offer!), and is myopic: GOS's sh-t stinks too; they f- things up too. Forgive us our trespasses as we forgive those who tresspass against us.
It seems especially dangerous being entirely dependant on Google's goodwill; Google has zero need for GOS. I'd think Motorola, who now has money and reputation depending on GOS's success, would tell GOS to zip it. If I were in that industry and looking to partner, I might love GOS's technology but their behavior would be hard to overcome. For example, I love OpenBSD, but who partners with them? And OpenBSD isn't dependant on someone else.
Just zip it, be professional, focus on what you are doing and not on others. Great job on this fix!
Dezvous · · focus · HN ↗
How do you propose they "focus on what [they're] doing and not on others" when their entire project is dependent on other's (Google's) work that directly impacts their own users? There's nothing about this blog post that is unprofessional. GrapheneOS released a patch for a rather severe performance bug, which is outside the scope of their normal work, so they provided context into why they made the decision to do so.
andrewaylett · · focus · HN ↗
The article uses phrases like "completely broken", "awful", and "<delay> wouldn't be a surprise". Which might be true but it's not helping.
Dezvous · · focus · HN ↗
Google pushed out bugged code ostensibly breaking millions of phones, mine included. They have the means to fix it in a short amount of time like GrapheneOS devs did, but they won't do it, so GrapheneOS took the initiative.
andrewaylett · · focus · HN ↗
That's part of the motivation behind HugOps: the people working on fixing a thing are only rarely the people who are responsible for the system that caused the breakage.
grapheneos · · focus · HN ↗
South Korea and multiple other countries have already found the Google Mobile Services licensing agreements to be illegal, so it's an objectively true statement to call it illegal. Samsung has been largely freed from the restrictions due to the court decisions in South Korea combined with their market share, which is good, but also incredibly unfair to other Android OEMs.
andrewaylett · · focus · HN ↗
I'd suggest that Google aren't your primary audience for this kind of post: it's folk like me, who are quite keen on the idea of GrapheneOS but don't actually use it yet (I actually bought a second-hand spare phone last week with the ulterior motive of trying GrapheneOS on it, we'll see...). What do you want your average reader to think about you, from reading what you've written?
I should add that this post (that I'm directly replying to) comes across to me as very much more appropriate than the original blog post, even as it's in many ways a lot harsher. It's putting Google's behaviour in context, rather than drawing comparisons between your own abilities and their poor performance.
You don't need to drag Google down in order to look good; there are many reasons why what Google (and especially their management) have done is bad for society (and not just for you) and also many reasons why what you're doing is excellent on its own merits, not merely compared to Google.
grapheneos · · focus · HN ↗
There were a small number of complaints prior to us moving the release introducing the issue to Stable. There were very important security updates in the updated firmware/driver code and we decided we needed to release it despite that. It took several days for most people's setups to build up enough memory usage to start triggering it. It started impacting a lot more people after a while and we realized it was a severe issue we had to address ourselves instead of waiting for Google to do it.
Google likely had the same reasoning for pushing it out to people to get many other issues including security bugs fixed despite a major known regression. We did not have time to avoid the situation in advance. We had to either delay driver/firmware security updates or ship it and then fix this afterwards. The problem is that it typically takes them at least around 4 to 6 weeks to ship a fix for even a critical issue. They've sometimes managed to do it in 3 weeks in extremely critical cases. It's unusual for them to move that quickly and it takes them longer to do kernel changes userspace ones. Once we figured out the issue was, it was quickly fixed and we started builds for a release in the same day.
It takes a long time for us to build a release for 21 different devices despite having build machines for it due to each having a specialized build with only what they used and their CPU architecture, etc. and we actually need 42 builds due to security preview releases. We plan to make incremental builds reliable enough to use those for production but it requires great care and potentially ongoing CI testing of reproducible builds to make sure incremental builds haven't regressed. If memory wasn't so expensive, we could buy a bunch of hardware to upgrade or replace our existing 4 local build machines for official releases.
mmooss · · focus · HN ↗
Whatever your 'reasons', the consequences are the same. Of course you know that "announcement on our forum for our userbase" can spread much more widely than that.
To lead successfully, we can't just do what we want and ignore the consequences. A leader's job is to get the best consequences.
notpushkin · · focus · HN ↗
microtonal · · focus · HN ↗
Google has betas for QPRs and yet this was not caught. It makes you wonder if Google is dogfooding the devices themselves or at least the devices that are not the latest gen and have 16GB memory.
The other issue is that it often takes weeks or months to fix show-stopping issues. Compare to e.g. Apple who rolled out a fix for Apple Watch 12/Ultra reboots or the iPhone 18 Pro Face ID issues within a week.
There are seriously things wrong in their process if they don’t catch these bugs and/or fix them quickly. (Or the other possibility is that they are understaffed.)
grapheneos · · focus · HN ↗
grapheneos · · focus · HN ↗
They're trying to limit how many devices can be sold with GrapheneOS by Android OEMs, reduced the number of AOSP releases from 12 to 2 per year with 10 of those now being Pixel exclusive, removed Pixel support from AOSP, unsuccessfully tried to cut us off from early access to security patches which are now allowed to be shipped early by OEMs while under embargo (which we do), are trying to convince app developers to ban using GrapheneOS via the Play Integrity API and even recently funded an AI slop paper with misinformation about GrapheneOS falsely claiming it missed security patches that it did not based on an entirely false premise that it has diverged from AOSP in a way that it hasn't and has to port patches to a diverged fork of the OS which isn't how it works. More info at <a href="https://news.ycombinator.com/edit?id=49946698">https://news.ycombinator.com/edit?id=49946698.
Many of the things Google has done to hinder open source projects based on Android are illegal and they continue doubling down on it despite a lot of regulatory and legal actions already taken against them.
mmooss · · focus · HN ↗
* If GOS is justified in their criticisms and tone, and expresses them, and it harms GOS's relationship with Google (problematic as it is), then it causes GOS harm.
* If GOS is not justified in their criticisms and tone, and expresses them, and it harms GOS's relationship with Google (problematic as it is), then it causes GOS the exact same harm.
So if you're thinking about justification, you are distracted - it doesn't matter. 'What is best for GOS' is the only question, and what is best is very likely to not antagonize the company and its employees when GOS is at their mercy entirely. What is best is to find a way to work with them and form as solid a bond as possible (and have a plan B if they screw you).
We all have to work with people we don't like and who treat us poorly; that's life when you have higher priorities.
grapheneos · · focus · HN ↗
mmooss · · focus · HN ↗
Maybe that's partly due to GOS's behavior toward Google and its engineers. For example, maybe there would be more workarounds and back channels otherwise.
> The future of Android is as an independent company forcefully split away from Google.
You are putting a lot of eggs in that quite uncertain and unlikely basket (given how impossible it is to predict the future and also the very wide range of possibilities). Splitting Google hasn't happened yet, anywhere, despite many attempts.
If they do split, there's no reason to think Android will be independent: It could be part of a larger subset of Google, even 'old' Google. It could be sold to another large company - many would love to control half the world's phones, if only to guarantee their applications are easiest to use and competitors can be disrupted (e.g., Meta or Microsoft could benefit enormously - and Microsoft could finally extend its OS business to phones).
Even if independent, why would Android act the way you hope? Who will run it - who will its shareholders and managers be? Likely current many Google shareholders and managers would be part of the spin-off. There's no reason to think they - or even completely new people - will be more supportive of FOSS; they could go the other way.
GOS is amazing. I don't know you so likely this is off-target to some degree - my apologies: Many engineers have learned, through defeat or success, that they need more than great engineering to get their passion into people's hands and change the world. Just as essential - more essential (lots of poor engineering is widely used!) - are great business skills. There's no shame in it: very few people can do it all (who is both a great engineer and great business manager?), and none have time to do both.
I hope someday the world knows 'Graphene' and a billion use it. It's one of the most important projects around - how else can typical end users have a chance at privacy? Good luck!
bitpush · · focus · HN ↗
There's a certain humility in how Igalia conducts business, and they contribute sooo much to the web ecosystem.
williamtell · · focus · HN ↗
palata · · focus · HN ↗
It used to be like that (and to be fair, all the similar communities were contributing to the drama, not just GOS), I agree, but I genuinely feel like it has become a lot more professional lately. Like I haven't seen drama in... at least 6 months?
Now I almost exclusively see them explain their technical decisions, which is very interesting.
mmooss · · focus · HN ↗
olyjohn · · focus · HN ↗
palata · · focus · HN ↗
Don't get me wrong, there are brilliant engineers at Google and I'm glad they are paid to contribute to open source projects like Android. But it doesn't make Google less evil.
And criticising a company is very different from "denigrating people". I don't think that the Google entity has feelings, does it?
mmooss · · focus · HN ↗
palata · · focus · HN ↗
> Google the entity has a reputation
Yep: "EvilCorp"
microtonal · · focus · HN ↗
HybridStatAnim8 · · focus · HN ↗
grapheneos · · focus · HN ↗
They're trying to limit how many devices can be sold with GrapheneOS by Android OEMs, reduced the number of AOSP releases from 12 to 2 per year with 10 of those now being Pixel exclusive, removed Pixel support from AOSP, unsuccessfully tried to cut us off from early access to security patches which are now allowed to be shipped early by OEMs while under embargo (which we do), are trying to convince app developers to ban using GrapheneOS via the Play Integrity API and even recently funded an AI slop paper with misinformation about GrapheneOS falsely claiming it missed security patches that it did not based on an entirely false premise that it has diverged from AOSP in a way that it hasn't and has to port patches to a diverged fork of the OS which isn't how it works. More info at <a href="https://news.ycombinator.com/edit?id=49946698">https://news.ycombinator.com/edit?id=49946698.
Many of the things Google has done to hinder open source projects based on Android are illegal and they continue doubling down on it despite a lot of regulatory and legal actions already taken against them.
antonvs · · focus · HN ↗
grapheneos · · focus · HN ↗
They're trying to limit how many devices can be sold with GrapheneOS by Android OEMs, reduced the number of AOSP releases from 12 to 2 per year with 10 of those now being Pixel exclusive, removed Pixel support from AOSP, unsuccessfully tried to cut us off from early access to security patches which are now allowed to be shipped early by OEMs while under embargo (which we do), are trying to convince app developers to ban using GrapheneOS via the Play Integrity API and even recently funded an AI slop paper with misinformation about GrapheneOS falsely claiming it missed security patches that it did not based on an entirely false premise that it has diverged from AOSP in a way that it hasn't and has to port patches to a diverged fork of the OS which isn't how it works.
Many of the things Google has done to hinder open source projects based on Android are illegal and they continue doubling down on it despite a lot of regulatory and legal actions already taken against them.
More info at <a href="https://news.ycombinator.com/edit?id=49946698">https://news.ycombinator.com/edit?id=49946698.
fsflover · · focus · HN ↗
<a href="https://news.ycombinator.com/item?id=49600114">https://news.ycombinator.com/item?id=49600114
<a href="https://news.ycombinator.com/item?id=49600021">https://news.ycombinator.com/item?id=49600021
subscribed · · focus · HN ↗
So it's impossible now to list the bad features or shortcomings without come one calling drama?
Why do you call it drama?
fsflover · · focus · HN ↗
subscribed · · focus · HN ↗
A very long list of severe issues. This is not presenting the advantages, it's listing of the problems.
When did that become a "drama", and not a fact-based criticism?
Re: second link - I don't have time to waste on digging through the code, I'd rather count pebbles in my garden, but I'm happy to bet £100 that it's fully facts based. I didn't even comment on the second link previously, BTW.
fsflover · · focus · HN ↗
- would you call the above "a very long, concrete list of issues" or "attack and drama"?
[0] <a href="https://news.ycombinator.com/item?id=45232164">https://news.ycombinator.com/item?id=45232164
[1] <a href="https://news.ycombinator.com/item?id=49594324">https://news.ycombinator.com/item?id=49594324
[2] <a href="https://news.ycombinator.com/item?id=49543420">https://news.ycombinator.com/item?id=49543420,
[3] <a href="https://news.ycombinator.com/item?id=48767841">https://news.ycombinator.com/item?id=48767841
subscribed · · focus · HN ↗
I don't see how the evidence of the project unwilling to keep up with the mainstream security or a statement that their hardware doesn't come close to the top would be relevant to this:
(1) and how do you imagine releasing the OS for the hardware not owned by the project? Does your Fairphone release source code of all the firmware? Do you have source code of the BIOS, firmware and microcode of your chosen Qubes OS pc? :D
(2) LOL, Google pretty much owns AOSP, how do you imagine GOS project takes the helm? Please explain. I read these as the strategic decision of GrapheneOS project, or unwillingness to take action. Please explain.
[0] what are you even on with remote attestation? This is an optional feature for the OS provider to prove the whole chain of custody hasn't been broken. Can you explain how the GOS project providing an option for the software developers to check that the OS hasn't been tampered with is a downside.
Of course in the light of the Fairphone unable to do as much as peivide timely patches or the OS available for over 6 months now.
(3) they explained they "want GrapheneOS to have no additional restrictions beyond AOSP. AOSP uses GPLv2 but not GPLv3". I don't understand what the charge is? How does GPLv3 benefit end user more? Why aren't you complaining to Google?
(And why are we even talking about that? Are you trying to stoke some drama, LOL?)
(4) lack of support for root becomes what, a proof they're stoking drama?! what are you even on? They prove source code, build instructions and more details, you're free to build your own images with root, it's actually super simple - the only things you lose is their signature and remote attestation you hate anyway.
Why do you expect a project focused on the reasonable security of all the reasonably safe handsets to bow to you exactly?
Because frankly it looks like you're trying to cause some drama. None of your "charges" carry any weight. Quoting the team explaining why they chose GPLv2 over v3 as the "evidence" of drama?
What's your angle? What i#/your post really about? Yeah, I see you see all the above as a serious charges against the project, and you're free to throw these every time.
But.... Do you really think they're approximately the same weight?
fsflover · · focus · HN ↗
How is this mainstream security, if GrapheneOS are the only ones offering it? Cutting edge, maybe. Except Qubes OS of course.
> or a statement that their hardware doesn't come close to the top
I specifically mentioned that the GOS crowd comments on every single topic of other projects, which to me is just attacking them. They have different tradeoffs, just like GOS itself. This is why I chose to word it that this is akin to me attacking every GOS post with their own flaws, which are the result of the chosen (mostly fair but real) tradeoffs. I do not want to attack every GOS discussion. I want to demonstrate how ridiculous their actions are, dividing projects that in the end have the same goals: to fight with megacorps and reclaim user freedom and security.
(1) I do not. And I do not have a Fairphone. I just hate drama and fight against it. I have a Librem 5 though. All its drivers are free and all its firmware sits on external, removable devices. If (when) a certain vendor starts to misbehave and use their power against the user, we can replace the device.
(2) I do not believe that AOSP developed by Google will provide the necessary freedom in the future, at all. Google have shown again and again how they use their power against the users and against GrapheneOS. If you can't develop it independently, just don't. I use Librem 5, because I do not believe in the future of AOSP. Linux though doesn't obey a single megacorp: Its development is distributed over many organizations, greatly reducing the danger of misbehavior against users. Librem 5 is less secure than a GrapheneOS phone today, but nothing prevents the community to change that.
[0] GrapheneOS supports the option of using the phone against its users with DRM. People who value freedom are not okay with that.
> Of course in the light of the Fairphone unable to do as much as peivide timely patches or the OS available for over 6 months now.
AFAIK they follow the upstream patches, i.e., just like GOS, they are at the mercy of the corporations with their security. This is not exactly their fault, as they chose different main goals, which are important, too. Attacking them does not help anyone except the megacorps.
> Why aren't you complaining to Google?
Google do not promise privacy or control to their users. But they should definitely be fought against.
> How does GPLv3 benefit end user more?
You can read all the reasoning at gnu.org.
> (And why are we even talking about that? Are you trying to stoke some drama, LOL?)
I am trying to stop some drama by explaining why the GOS crowd should not do as they do.
(4) You completely missed my point. Read the above.
> you're free to build your own images
> Why do you expect a project focused on the reasonable security of all the reasonably safe handsets to bow to you exactly?
I did not demand that GOS does this.
> None of your "charges" carry any weight.
I did not suggest changes. I do understand the GOS choices. I demand that they, too, understand the choices of others.
> Quoting the team explaining why they chose GPLv2 over v3 as the "evidence" of drama?
The choices have nothing to do with drama. The inability of GOS to understand the choices of others and attacking these choices every single time something is posted is drama.
Thanks for the genuinely trying to understand me.
subscribed · · focus · HN ↗
Not their fault. I should probably say "reasonable security". Settling for anything less is folly, seeing how malvertising isn't the only danger to the normal users. Broad availability of the powerful LLMs increases the amount of the vulnerabilities found and exploited in the wild.
Anything can carry an RCE now, web font, image, background audio on the cute website, attachment in the MMS or WhatsApp message.
I guess all those with "nothing to hide" (except their text messages, financial data, money on their bank accounts) are happy to have their lives sold in the open on more and more darknet marketplaces, their devices to mine some obscure crypto and serve as proxy for some nefarious actors.
You're using Qubes, I guess not because you like slower and less streamlined experience, but because you want security.
> My Qubes laptop runs coreboot with Heads with disabled and neutralized Intel ME.
Congrats, then, really.
Oh, wait, Qubes openly supports "CPU-vendor-provided blobs for silicon and memory initialization as well as other internal operations" -- which means you either strike "reliance on numerous non-auditable, proprietary drivers and firmware" from GOS (which runs it on the hardware that guarantees the separation), or raise the same for Qubes OS.
And actually, while we're at it, does your phone OS rely on the "numerous non-auditable, proprietary drivers and firmware" or not? Because if yes, why would you even complain that a very secure platform does that too?
Re: Coreboot: for me it would mean that I cannot use Qubes OS with hardware I want, because mean someone doesn't provide coreboot fw for my laptop, and even worse still, Qubes doesn't support my laptop.
I guess it's their fault then, seeing as some people throw a hissy fit that GrapheneOS doesn't want to officially support a phone they want to be supported :)
> I specifically mentioned that the GOS crowd comments on every single topic of other projects,
Will all due respect, this is just raging BS requiring extraordinary evidence.
> This is why I chose to word it that this is akin to me attacking every GOS post with their own flaws, which are the result of the chosen (mostly fair but real) tradeoffs
But you didn't list even one actual, objective flaw.
Not releasing firmware patches impacts everyone is objective, clearly negative. Not allowing to use custom keys is objective flaw. Not allowing to relock the bootloader is a flaw. Not having a secure element that processes PIN is a flaw.
Running privileged Google services isn't an objective flaw, if it's openly disclosed and benefits some users (so their handset can pass Play Integrity). No, GOS don't do it, for me it's an example what is and what isn't objective.
Supporting only one family of the phones is not an objective flaw if that's the only hardware platform that can back the security posture. And with the upcoming Motorola handsets support it's proved beyond doubt it's a flaw of the hardware manufacturers, not of the project trying to provide a secure platform for the increasingly dangerous Internet.
Maybe you remember how the freshly installed Windows XP without firewall couldn't get connected to the internet or it'd get immediately infected. Maybe you've seen logs from the Linux servers showing endless attempts to break in.
We're approaching the same for mobile devices, just worse, because most of these devices are grossly insecure, and the LLMs will be able to prepare custom exploits for all the common ones en masse.
> I do not want to attack every GOS discussion.
You do you. If you have actual flaws, by all mean, you're good.
But you didn't show a single one yet. You shared your opinion on how you believe that not supporting root is somewhat bad, or complained that GOS does something ALL the other vendors do (like reliance on AOSP, not changing licensing, or using fw blobs (at least in their case - securely))
> I want to demonstrate how ridiculous their actions are, dividing projects that in the end have the same goals: to fight with megacorps and reclaim user freedom and security.
I think it's a mistake to project your own position or understanding on all the projects.
Like, LineageOS supports a very broad range of hardware increasing security for many of these abandoned by their vendors (f*k Sony, for example, for releasing security patches for barely year-and-a-half for so-called flagship).
GOS has different goals. They result in the similar gains (i.e. ensuring security benefits privacy), but it's a result, not goal per se.
> Librem 5
So you don't have source code of the firmware for your chosen phone but you're attacking GOS for using firmware they don't have source of? I'm confused.
> (2) I do not believe that AOSP developed by Google will provide the necessary freedom in the future
Wait, wait, but you said "full dependence on Google's direction of Android development and how fast Google shares the source code with others" as presumably an evidence/example of specifically GrapheneOS flaw.
You "accused" AOSP-based operating systems team of being fully dependent on the AOSP.
And now you're saying it was about your *feelings*?
Do you attack projects stating your feelings as an "evidence" of the project's shortcomings?
Can you see how it's hard to have a fact-based, neutral discussion with that? It's broadly pointless because you either confuse facts and evidence with feelings or you equate these two.
> Librem 5 is less secure than a GrapheneOS phone today, but nothing prevents the community to change that
If the hardware is secure, sure. You can even backport a lot of GOS improvements back to Linux.
But if the hardware is not secure, then no, community cannot make it as secure as GOS phone today.
> GrapheneOS supports the option of using the phone against its users with DRM
I'm confused, first I don't know what specifically you're talking about (not saying it's untrue but throwing "DRM" randomly doesn't help much), and is it something unique to GrapheneOS that is NOT shared by other projects? Because, seriously, you're singling out the safest, most private and most secure project listing things that are probably done by everyone else but its somehow only GOS issue?
(Also, is it a safety issue or only privacy? GOS never promised a focus on privacy)
> [Fairphone] AFAIK they follow the upstream patches, i.e., just like GOS, they are at the mercy of the corporations with their security.
They're always late by many months. Months. They're free to do what GrapheneOS do, to keep requesting these patches.
But what are we talking about, they didn't even do as much as move to Android 17, which in itself is the evidence they don't follow upstream, because most patches are not backported by Google. Raising that is not "attacking" any more than listing unsafe features of a a specific car.
>> [about not supporting root] Why do you expect a project focused on the reasonable security of all the reasonably safe handsets to bow to you exactly?
> I did not demand that GOS does this.
But you specifically complained: "(4) complete lack of flexibility concerning the user's threat model, e.g., intentional lack of support for root for whitelisted apps"
They openly support users building their own images (with root. It's trivial to build the image with root enabled), and you actually complain they do not support root. They do not in their official images.
So you are now saying that by complaining that GrapheneOS do not support root in the official image, which you provided as (presumably) objective flaw of the OS, isn't in fact you demanding they support it officially and build it in, thus bowing to the request?
I'm utterly confused here.
About as much as when you send me to FSF website to read about some licence when I ask you how the project's decision to stick to the parent licence in order to not impose limitations on the users is imposing the limitations on the users.
fsflover · · focus · HN ↗
Quote:
About this identifier: <a href="https://doc.e.foundation/os/learn/staged-rollout/" rel="nofollow">https://doc.e.foundation/os/learn/staged-rollout/No evidence that it is used or can be used for tracking. The accusation is strongly overstated. (You can keep your £100 though.)
subscribed · · focus · HN ↗
> a random identifier, generated on your device the first time it boots
So it's a persistent, unique identifier, is it?
> No evidence that it is used or can be used for tracking.
It's even worse than Google's Advertising ID that at least can be easily reset.
> The accusation is strongly overstated
> (You can keep your £100 though.)
I don't think how you disproved anything. You even confirmed the phone ID is immutable until factory reset.
I was talking about all four claims.
GOS>> They also spent years sending user speech data to OpenAI without informing users beyond fine print in the terms of use.
Here's the discovery by the user and confirmation from the owner of the project: <a href="https://community.e.foundation/t/voice-to-text-feature-using-open-ai/70509/10" rel="nofollow">https://community.e.foundation/t/voice-to-text-feature-using...
(This is sharing users' biometric data with third party without express consent, then shared further with unspecified )
GOS>> It's presented as not using Google services but has a whole bunch of Google services with privileged access enabled by default.
<a href="https://eylenburg.github.io/android_comparison.htm" rel="nofollow">https://eylenburg.github.io/android_comparison.htm
GOS>> It even downloads and runs Google Play executables such as droidguard by default with privileged access far beyond the regular app sandbox.
<a href="https://doc.e.foundation/os/learn/calls-to-google-servers/" rel="nofollow">https://doc.e.foundation/os/learn/calls-to-google-servers/
I believe it also enables Safetynet checks by default which downloads and executes proprietary code straight from Google.
So you didn't disprove the first one and you didn't touch remaining three.
I'll keep my £100 indeed.
palata · · focus · HN ↗
fsflover · · focus · HN ↗
P.S. Flagging my comments, as the GrapheneOS fans do, is also far from constructive.
subscribed · · focus · HN ↗
In the past it was really commonplace, so it cooled my curiosity about the project for a couple of years.
Still, they hand the interactions to people with people skills.
grapheneos · · focus · HN ↗
warrantisall · · focus · HN ↗
armadyl · · focus · HN ↗
Sorry, but no. This sentiment isn’t too different from politics in the US right now where the politicians that “call it like it is” are significantly more popular than the “traditional take the high road speech” candidates. It’s a lame thought process.
I appreciate GrapheneOS telling it like it is, and their language highlights the failings of Google. It’s unacceptable that the maintainer of Android/AOSP is performing like this.
> I'd think Motorola, who now has money and reputation depending on GOS's success, would tell GOS to zip it. If I were in that industry and looking to partner, I might love GOS's technology but their behavior would be hard to overcome.
This has little to no effect on Motorola. They didn’t even promote their partnership with GOS and mostly only GOS users and tech enthusiasts are even aware of this partnership. People who need / want GOS don’t care about the attitude of the developers as long as they deliver beneficial things and don’t go off the fascist/racist/socially unacceptable deep end (and even that is debatable just look at Omarchy and it’s sponsors as well as Brave). The average consumer could not care less and will continue to be unaware of GOS at best, and at worst view it as negatively as the press tries to portray it when the government tries to attack someone’s digital civil liberties.
mmooss · · focus · HN ↗
That's a pretty big stretch; the stakes and actors differ vastly.
> I appreciate GrapheneOS telling it like it is,
You may like it but it may hurt GOS's prospects. It deters others from working with GOS (I expect, based on common sense of the professional world), and Google has tremendous power over GOS.
Is the trade-off worth it? Is hearing what you want worth risking GOS's future, and possibly reducing its resources, distribution, and reputation?
The scrappy newcomer can say what they want - indeed, it gets attention. But once you have something worth protecting - a product and a reputation - you have competing interests: say what you want or further your product and name?
HybridStatAnim8 · · focus · HN ↗
grapheneos · · focus · HN ↗
They're trying to limit how many devices can be sold with GrapheneOS by Android OEMs, reduced the number of AOSP releases from 12 to 2 per year with 10 of those now being Pixel exclusive, removed Pixel support from AOSP, unsuccessfully tried to cut us off from early access to security patches which are now allowed to be shipped early by OEMs while under embargo (which we do), are trying to convince app developers to ban using GrapheneOS via the Play Integrity API and even recently funded an AI slop paper with misinformation about GrapheneOS falsely claiming it missed security patches that it did not based on an entirely false premise that it has diverged from AOSP in a way that it hasn't and has to port patches to a diverged fork of the OS which isn't how it works. More info at <a href="https://news.ycombinator.com/edit?id=49946698">https://news.ycombinator.com/edit?id=49946698.
Many of the things Google has done to hinder open source projects based on Android are illegal and they continue doubling down on it despite a lot of regulatory and legal actions already taken against them.
csdreamer7 · · focus · HN ↗
Google's justification for Android over Apple is it being open source and attracting this crowd and people they recommend it to. They have a very strong need for it or they would have stopped contributing years ago.
> GOS can just talk about the upside, their solution to this problem. That's great work. But they often choose to denigrate others, which is destructive, damages relationships (the most essential assets - especially when you have no money to offer!), and is myopic: GOS's sh-t stinks too; they f- things up too.
Look up false equivalence.
GOS isn't a trillion dollar company with a massive possible budget for quality control. Google can do better and they should do better.
If Google's internal issues (or deliberate withholding of source code) is causing a small group to surpass them in product quality then that is something to talk about. Especially without the ad tracking and data collecting money Google brings in.
If it gets Google to improve AOSP then all the better.
> would tell GOS to zip it. > Just zip it, be professional,
This is very rude-esp for a group trying to make Android better. I downvoted you.
mmooss · · focus · HN ↗
At work you can say things and say them in a manner that you think is justified, or you can behave in ways that let you keep your job. I want GOS to succeed.
csdreamer7 · · focus · HN ↗
I saw nothing in the post that is even close to that.
> I want GOS to succeed.
By making poor arguments on HN and being rude to them? Sounds productive.
You think you can do better? Contribute to another/Make your own fork of Android and help the community reduce it's dependence on Google.
grapheneos · · focus · HN ↗
Many of the things Google has done to hinder open source projects based on Android are illegal and they continue doubling down on it despite a lot of regulatory and legal actions already taken against them.
More info at <a href="https://news.ycombinator.com/edit?id=49946698">https://news.ycombinator.com/edit?id=49946698.
phasephantasm · · focus · HN ↗
aboringusername · · focus · HN ↗
I'm curious if there's any back up plan to an operating system used by billions. One would think, and hope, the EU would have an alternative ready to go at a moment's notice. Android is literally too big to fail, but I doubt the EU would be ready even though you could consider the failing of Android a national security emergency.
I would like to know more about what's going on at Google that are causing these issues.
palata · · focus · HN ↗
AOSP and the Android SDK are open source. GrapheneOS is exactly an alternative to Google Android. Sure, Google could shut down the Play Store (but alternative stores exist), or destroy the Play Services (but even then, there is microG).
I am happy that Google is still contributing to Android because they have a ton of money and many brilliant engineers, even though as a company it seems like it's somehow trying to burn it to the ground. But I am optimistic: it would be possible to build on top of the open source parts of Android if needed.
0xcde4c3db · · focus · HN ↗
palata · · focus · HN ↗
> So it's concerning to see this move from Google, which is also the device vendor for all currently supported GrapheneOS devices.
It is, and the solution to that is the partnership with Motorola.
microtonal · · focus · HN ↗
So from that perspective there is not really a difference between AOSP and Linux, you need support from the device vendor. But AOSP is many times more secure than the traditional Linux desktop and has many times more apps available (most of which do not require Play Integrity).
HybridStatAnim8 · · focus · HN ↗
EmbarrassedHelp · · focus · HN ↗
Most national governments in the EU are probably too authoritarian technology-wise to recognize the importance of supporting a project like GrapheneOS as well.
surajrmal · · focus · HN ↗
You could argue that the current ecosystem dynamic is not great for the longer term, but it will require a change from the OEMs to enable something different as they are the ones actually in control of the situation.
AzzyHN · · focus · HN ↗
joemazerino · · focus · HN ↗
grapheneos · · focus · HN ↗
<a href="https://www.reddit.com/r/GooglePixel/comments/1wvnj9c/lags_on_google_pixel_8/" rel="nofollow">https://www.reddit.com/r/GooglePixel/comments/1wvnj9c/lags_o...
<a href="https://www.reddit.com/r/GooglePixel/comments/1wtxm0m/pixel_8_slowed_down/" rel="nofollow">https://www.reddit.com/r/GooglePixel/comments/1wtxm0m/pixel_...
<a href="https://www.reddit.com/r/GooglePixel/comments/1wu9j93/is_there_any_chance_google_will_address/" rel="nofollow">https://www.reddit.com/r/GooglePixel/comments/1wu9j93/is_the...
<a href="https://www.reddit.com/r/GooglePixel/comments/1wt0od2/new_update_is_really_slowing_my_9a_down_anyone/" rel="nofollow">https://www.reddit.com/r/GooglePixel/comments/1wt0od2/new_up...
<a href="https://support.google.com/pixelphone/thread/470741051/september-update-android-17-made-my-pixel-laggy-and-notifications-won-t-show-in-the-shade?hl=en" rel="nofollow">https://support.google.com/pixelphone/thread/470741051/septe...
<a href="https://support.google.com/pixelphone/thread/470915661/phone-running-slowly-after-the-september-update?hl=en" rel="nofollow">https://support.google.com/pixelphone/thread/470915661/phone...
<a href="https://support.google.com/pixelphone/thread/470545577/major-pixel-9-pro-issues-starting-9-23?hl=en" rel="nofollow">https://support.google.com/pixelphone/thread/470545577/major...
<a href="https://support.google.com/pixelphone/thread/470645986/laggy-and-frozen-after-september-update?hl=en" rel="nofollow">https://support.google.com/pixelphone/thread/470645986/laggy...
<a href="https://support.google.com/pixelphone/thread/470478102/phone-became-noticeably-laggy-after-the-september?hl=en" rel="nofollow">https://support.google.com/pixelphone/thread/470478102/phone...
<a href="https://support.google.com/pixelphone/thread/470472092/pixel-6a-lagging-after-september-2026-update?hl=en" rel="nofollow">https://support.google.com/pixelphone/thread/470472092/pixel...
Here are some news articles which are primarily about this issue:
<a href="https://www.droid-life.com/2026/09/22/latest-pixel-update-either-greatest-ever-or-buggiest-ever/" rel="nofollow">https://www.droid-life.com/2026/09/22/latest-pixel-update-ei...
<a href="https://www.androidpolice.com/google-pixel-september-update-issues/" rel="nofollow">https://www.androidpolice.com/google-pixel-september-update-...
<a href="https://www.androidauthority.com/android-17-qpr1-issues-survey-3717366/" rel="nofollow">https://www.androidauthority.com/android-17-qpr1-issues-surv...
There are also new Wi-Fi compatibility issues covered in those news articles. However, it's fairly likely that's caused by fixing security vulnerabilities which caused routers with a buggy implementation of the protocols to become incompatible. It's something we've seen happening regularly with Wi-Fi and especially Bluetooth. Older Bluetooth devices not receiving updates are increasingly becoming incompatible with smartphones receiving proper security updates. Android only lists a tiny portion of driver and firmware patches in the Android Security Bulletins so OEMs aren't obligated to ship the patches and non-Pixel devices largely aren't shipping most of it so they don't experience as many incompatibilities. Pixels get more Wi-Fi and Bluetooth incompatibilities due to actually getting the security updates for those. Other devices may eventually get it many months or even over a year later after many routers get updated and sometimes workarounds are implemented on the client side.
We're not going to complain about Google fixing security vulnerabilities requiring a break in compatibility, but they announced that's what they're doing if it's the cause and provided a per-network toggle to work around it. Wi-Fi authenticated encryption often isn't particularly important since nearly everything has authenticated transport encryption and people can also use a VPN to avoid revealing their connections to local networks. A compatibility toggle with a security warning would make sense. The same applies to a lesser extent to Bluetooth.
It's also worth noting there are a bunch of unpatched upstream kernel vulnerabilities in the Pixel OS with publicly available exploits on GitHub and elsewhere. A bunch of companies selling exploit tools are actively using those vulnerabilities to exploit Pixels. Google isn't doing much about it since their release engineering process is so slow combined with the Generic Kernel Image (GKI) system entirely collapsing under the weight of AI accelerated vulnerability discovery. We're having to pick up the pieces from the mess created by GKI by doing painful merges of the upstream updates for the short term and then outright replacing it with directly using the upstream kernels for the long term. Android works with the upstream kernel releases but the drivers for devices are written against the GKI interface. We need to port a minimal GKI interface to the upstream kernels and update the drivers to handle dropping the ABI stability it provides.