I'm so glad GrapheneOS is willing and able to pick up the pieces and polish Android into a usable product as Google continues to drive its clunker into the ground. The only question is if GOS can rescue Android before Google sends it off a cliff.
grapheneos 2 hours ago [-]
GrapheneOS users can update to the latest OS release to resolve it. It's now available in our Stable channel after making it through public Alpha and Beta channel testing.
infogulch 2 hours ago [-]
I updated about an hour ago. Thank you for your work! :)
Itoldmyselfso 1 days ago [-]
In the meanwhile you can try this temporary fix: Go to Developer Options->Apps>Background Process Limit and change the limit from Standard to "at most 4processes" [1]
GrapheneOS users can update to the latest OS release to resolve it. It's now available in our Stable channel after making it through public Alpha and Beta channel testing.
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.
d2kx 1 days ago [-]
Usually I am the one making fun of people who have been claiming that "the new update made everything buggy and slow and reduced battery life" with every update for the past 15 years, but this time this one's actually real and hitting my base Pixel 8 hard. Hopefully the October update fixes it.
grapheneos 2 hours ago [-]
GrapheneOS users can update to the latest OS release to resolve it. It's now available in our Stable channel after making it through public Alpha and Beta channel testing.
garbagewoman 1 days ago [-]
Based on the timeframes in the linked post, it likely won’t
0fflineuser 1 days ago [-]
I was wondering what was wrong with my phone, i thought a reboot would fix it and forget to do it everytime.
The lags are actually quite unpleasant and noticable, i wonder how it wasn't caught before the release.
ncr100 1 days ago [-]
Gosh, I have noticed a number of my apps (Pixel 11 fold 'pro') simply halting under high workload. This is that I suppose.
microtonal 17 hours ago [-]
The linked post seems to say that Pixel 11 hasn’t received QPR1 so far and might not have this bug?
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 16 hours ago [-]
I had assumed this was just Google effectively "ending support" for my 9a by forcing some AI thing into my lowish RAM. I can't believe even the latest Pixel users are having this problem since I thought they actually QA those.
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 3 hours ago [-]
It was introduced on September 15th for Pixel 6 through Pixel 10a. It will potentially never get fixed for the Pixel 6 and Pixel 6 Pro on the stock OS due to those now being past their guaranteed update periods. For GrapheneOS, it's fixed in out latest release for the Pixel 6 through Pixel 10a now available in our Stable channel.
Early in the month, the Pixel 11 series received a partial September 2026 security update release. Those didn't receive Android 17 QPR1 or the full 2026-09-05 Pixel security patch level 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.
We haven't launched Pixel 11 support yet due to the many issues with those. MTE support not being available at launch was the biggest issue but there are more. We'll see if they're usable devices meeting our security requirements with Android 17 QPR2 in December 2026.
williamtell 1 days ago [-]
I'll be interested to see if downstreams of AOSP ultimately weaponize updates against Google. For the kernel that's a minefield but Google made plenty of stuff Apache/MIT to keep its options open..
306bobby 21 hours ago [-]
As a custom ROM maintainer in that position, it's unlikely to cause a difference since Google has effectively monopolized their Play Integrity API for attestation. Even Graphene itself runs into this roadblock, and why in the current day it's still a minority user group using it or other ROMs
notpushkin 19 hours ago [-]
I’ve had some trouble with apps refusing to work because of Play Integrity, but it’s not ubiquitous yet. We can still fight it.
306bobby 14 hours ago [-]
Normie apps simply don't anymore. WhatsApp will refuse to log you in if it feels your device is modified and then fails a verdict. Google Wallet won't let you tap to pay. Most banks in the EU and basically all virtual ID systems require it
That's a big pain point for the average user
notpushkin 11 hours ago [-]
Google Wallet is the one I miss the most.
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 10 hours ago [-]
I do hope we can, I continue to work on custom ROMs after all :)
I just also like to be a realist, and right now things look a bit grim
RandomGerm4n 11 hours ago [-]
Both WhatsApp and banking apps (Santander/Openbank) work perfectly for me. You really shouldn't use Google Wallet because of privacy concerns. But if you absolutely want to, there are other equally questionable alternatives, such as PayPal, that work just fine on GrapheneOS.
306bobby 10 hours ago [-]
They work fine for me too personally, but not for everyone. Banks are ofc by institution, but with whatsapp there's some flag that can be put on an account which makes them get an "unofficial app" warning and not log in. Which gets cleared by using a stock device or something passing integrity. Definitely a weird situation, but there's plenty of proof out there that they're doing something strange
306bobby 10 hours ago [-]
And you can't tap to pay with PayPal, at least not in my region. Tap to Pay is the big thing
grapheneos 41 minutes ago [-]
PayPal only supports tap-to-pay in Germany. Curve Pay supports tap-to-pay on GrapheneOS in the UK and the whole European Economic Area. Many European banks have working tap-to-pay too, and the trend of those replacing their independent system with Google Pay has subsided. It's mostly a non-issue in Europe but there aren't similar alternatives for most of the world. Japan does have their own alternative which works on GrapheneOS with Japanese models of Pixels.
snaker 3 hours ago [-]
[dead]
subscribed 12 hours ago [-]
I'm using WhatsApp on my GrapheneOS handset without issues.
notpushkin 11 hours ago [-]
I’ve been using WhatsApp on LineageOS with microG and it worked just fine for me too. Even with Magisk (had to do some integrity trickery for another app, which didn’t work out ultimately but eh).
surajrmal 9 hours ago [-]
I'm not sure that's the reason a minority user group is using alternative ROMs. They have always been niche, even before the play integrity API took off.
bitpush 1 days ago [-]
Why wont GOS contribute this to upstream?
HybridStatAnim8 4 hours ago [-]
Upstream is both very contribution unfriendly and their treatment of GrapheneOS leads GOS to not want to contribute anything to them anymore.
BlackRabbit1 1 days ago [-]
Because Google is already picking patches from GOS ;-)
HybridStatAnim8 4 hours ago [-]
Citation needed.
bitpush 1 days ago [-]
I'm confused, so if open source is working as expected then what's the point of the blogpost?
Dylan16807 1 days ago [-]
It's a post about google screwing up their process and also pushing a bad update to a ton of people, and other people cleaning up their mess. I'm glad "open source is working" but that's a small part of the picture and I don't see why that would remove the point of the blog post.
bitpush 1 days ago [-]
Software bugs happen. That's a given. If GOS thinks they are above bugs, they are a) either not doing anything significant b) lying.
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 1 days ago [-]
Major performance bugs don't sneak themselves into releases and then prevent followup fixes from being promptly released.
The point of the post is not that grapheneos made the fix, it's that they had to.
stkdump 16 hours ago [-]
If you look at the patch, it is just disabling a (presumably new and buggy) feature.
4 hours ago [-]
grapheneos 4 hours ago [-]
There's no way to contribute this upstream. Google removed support for Pixels from the Android Open Source Project with the release of Android 16. We obtain the kernel driver sources through tarballs without commit history by making GPLv2 source requests. This is one of many ways Google has become increasingly hostile towards Android-based projects not certified by Google.
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.
LoganDark 1 days ago [-]
> We have rapidly growing resources and we'll handle it.
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.
1 days ago [-]
spottedmarley 1 days ago [-]
I love you, GrapheneOS. XOXOX
aboringusername 1 days ago [-]
It's concerning to hear about the disarray within the internal workings of Android, they've spoken quite a lot about this recently such as getting access to the code and having to make manual requests.
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.
surajrmal 6 hours ago [-]
The model for Android is that the OS is provided by the OEM. They work in partnership with Google. GrapheneOS tries to work against this model by not partnering with the OEM on supporting their hardware with its OS. Ultimately that's not sustainable given the dynamics of the ecosystem. This is why they are moving to a model where they do work with an OEM directly. These sorts of problems will subside once that happens.
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.
EmbarrassedHelp 20 hours ago [-]
The EU Commission at least seems comfortable with requiring that everyone uses Google approved versions of Android, because it makes their authoritarian push for mandatory age verification easier to enforce.
Most national governments in the EU are probably too authoritarian technology-wise to recognize the importance of supporting a project like GrapheneOS as well.
palata 1 days ago [-]
I read a lot of comments like this, saying "we should have an alternative". And I agree that it would be really cool, BUT:
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 1 days ago [-]
AOSP is open-source, but unlike Linux distros, AOSP per se doesn't really support any platform other than the Android emulator. To support real devices you need devicetree/firmware/drivers from a vendor. So it's concerning to see this move from Google, which is also the device vendor for all currently supported GrapheneOS devices.
microtonal 16 hours ago [-]
Linux also doesn’t have device trees and firmware for most phones. E.g. many Ubuntu Touch ports just use the device tree, firmware, and kernel tree provided by the manufacturer for Android.
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 4 hours ago [-]
AOSP and its derivatives are linux distros.
palata 24 hours ago [-]
Well to support real devices you need the device manufacturer to not prevent you from supporting it. Samsung can totally make a smartphone that does not support Android today. But I'm not sure what you are trying to say with that...
> 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.
joemazerino 21 hours ago [-]
Is this in stock Android? If so that is crazy.
grapheneos 3 hours ago [-]
It definitely impacts the stock Pixel OS and many users are complaining about it. Here are a bunch of user reports:
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.
1 days ago [-]
AzzyHN 24 hours ago [-]
I knew something was up!
mmooss 1 days ago [-]
[flagged]
Dezvous 1 days ago [-]
>Just zip it, be professional, focus on what you are doing and not on others.
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 1 days ago [-]
Look to "HugOps" as inspiration: when someone else is having a bad day, offer them a hug rather than running them down.
The article uses phrases like "completely broken", "awful", and "<delay> wouldn't be a surprise". Which might be true but it's not helping.
grapheneos 3 hours ago [-]
Google has been increasingly hostile towards GrapheneOS over the past several years despite our substantial contributions upstream. We've spent years helping Google with vulnerability reports, improvements submitted upstream and multiple proposals for security protections which were implemented for both Android and Pixels. We've been treated incredibly poorly by Google.
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 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 2 hours ago [-]
You're missing an essential point, it seems, about public communication (and behavior): It doesn't matter what the other guy does. Google's conduct is irrelevant here. I care about GOS, not Google. The question is, what is best for GrapheneOS? GOS may be competely justified in their criticisms of Google, but that doesn't matter at all:
* 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.
microtonal 16 hours ago [-]
We can hug the engineers that have to fix this while at the same time criticizing the process that led to this.
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 2 hours ago [-]
Google caused many of these problems with mass layoffs, buyouts and ending remote work which drove away many of their best engineers. The hostility of Google's business side towards projects based on AOSP has also led to many additional issues for the Pixel OS which could have been avoided. If they hadn't made it nearly impossible to contribute and been so hostile towards many projects including GrapheneOS then they could have a lot of help with these issues and could get them fixed far easier. The Beta releases aren't released as open source and there's no way to contribute.
notpushkin 19 hours ago [-]
“HugOps” is great (I’ll be stealing this term :-), but Google has been downright hostile to custom ROM maintainers lately. They deserve no hugs here.
Dezvous 20 hours ago [-]
Those phrases are true and they helped by making a patch, which Google will most likely end up merging. So what's your point? Should GrapheneOS blogs treat Google as if they're an individual with feelings having a bad day? The same Google that routinely and deliberately hampers the development of GrapheneOS and other similar projects?
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 11 hours ago [-]
No, we shouldn't treat Google like an individual, because it's not. But we can (and should) be mindful of the individuals who make up the various teams within Google.
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 2 hours ago [-]
Individuals at Google working on Android are ultimately responsible for Google's years of attempts to harm projects based on the Android Open Source Project. That includes Google coercing their OEM partners to sign illegal anti-competitive agreements, pushing the illegal anti-competitive Play Integrity API and breaking many public commitments to open source along with the promises they made to sell Pixel phones.
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.
GrapheneOS was initially collateral damage for Google's anti-competitive behavior but in the past couple years they've shown they feel threatened by us and are very actively trying to hold us back. It's not everyone at Google doing it but it's enough of them including the people in control.
phasephantasm 7 hours ago [-]
Ironic, you are being an example of what you project. People come out of the woodwork to say what you do, then respond to comments like mine with "maybe there is a reason for it"... but if you're gonna leave it to "maybe", you should just zip it yourself really.
williamtell 1 days ago [-]
There are plenty of messages on this site where the GOS lead assumed the best while Google tightened the rope.. Google was never the right choice for a partner when being able to choose only one hardware vendor. Google made changes to AOSP that are basically infringement of GPL using the usual embargo security theater. GOS making some noise is good for their business since if they don't, even their existing user base will assume they will be squashed like a bug.
palata 1 days ago [-]
> But they often choose to denigrate others, which is destructive, damages relationships
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.
grapheneos 33 minutes ago [-]
We've been defending ourselves from intense attacks aimed at destroying GrapheneOS and personally harming our team members since 2018. We now have a lot more project members, community members, money, legal representation and other resources to protect ourselves. We don't feel the need to defend ourselves nearly as much from non-technical attacks since even many people who don't use GrapheneOS are defending us. No need for us to directly address it if others have already done it. We'll still directly defend ourselves in cases where other people aren't aware or aren't doing it.
mmooss 24 hours ago [-]
The OP denigrates Google.
palata 24 hours ago [-]
Oh sorry, I thought you were talking about something else. Well... yeah IMO Google deserves it as it (as a company) is predatory.
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 22 hours ago [-]
If you have a relationship with a business, try publicly denigrating them and see what the response is. Google the entity has a reputation, and that affects their revenue and reflects strongly on the people who work there - 'Google' means something on a resume.
microtonal 16 hours ago [-]
Google’s relation with GrapheneOS is: make their lives harder by moving kernel trees from Git to Google Drive with a form that sometimes doesn’t get processed in weeks; block tap-to-pay and a bunch of apps with Play Integrity; closing the AOSP trees and only do major release and QPR2 drops; remove Pixel device trees etc. from AOSP even though they were sold as reference devices.
grapheneos 3 hours ago [-]
Google has been increasingly hostile towards GrapheneOS over the past several years despite our substantial contributions upstream. We've spent years helping Google with vulnerability reports, improvements submitted upstream and multiple proposals for security protections which were implemented for both Android and Pixels. We've been treated incredibly poorly by Google despite our contributions.
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.
What relationship does GrapheneOS have with Google? My understanding is that they fork the open source stuff made by Google, and as a response Google (the entity) does everything they can to screw GrapheneOS.
> Google the entity has a reputation
Yep: "EvilCorp"
HybridStatAnim8 4 hours ago [-]
GrapheneOS has no relationship with Google.
grapheneos 2 hours ago [-]
Google has been increasingly hostile towards GrapheneOS over the past several years despite our substantial contributions upstream. We've spent years helping Google with vulnerability reports, improvements submitted upstream and multiple proposals for security protections which were implemented for both Android and Pixels. We've been treated incredibly poorly by Google despite our contributions.
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.
Maybe it's well deserved. Google have been real pricks.
antonvs 20 hours ago [-]
“Denigrate” implies unfair criticism. Whether the OP is doing that is a matter of opinion, but it’s certainly possible to read it as straight criticism, i.e. not unfair and not denigrating.
fsflover 13 hours ago [-]
[flagged]
palata 10 hours ago [-]
This is not drama, this is a technical opinion about their competitors. Happy to have Fairphone and /e/OS do it constructively as well. And I mean constructively. When the founder of /e/OS says "we are not one of those hardened systems for pedophiles", it is not constructive. If they said (I'm inventing here, not sure if they did): "The problem of GrapheneOS is that they only run on Pixels. We try to run on more phones in a best-effort basis", that would be valid.
P.S. Flagging my comments, as the GrapheneOS fans do, is also far from constructive.
subscribed 12 hours ago [-]
Why do you even call the detailed, verifiable claims about a product a "drama"?
So it's impossible now to list the bad features or shortcomings without come one calling drama?
Why do you call it drama?
fsflover 9 hours ago [-]
One thing is to present the advantages of your system. Entirely different thing is to enter every discussion of alternative systems saying they have "atrocious" security. Also, the second link is an empty accusation, as it has no proofs.
subscribed 7 hours ago [-]
They have listed a very long, concrete list of issues with Fairphone in the (sub)thread about Fairphone.
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 3 hours ago [-]
Imagine that I would enter every conversation about GrapheneOS saying how atrocious their freedom is, including
(1) reliance on numerous non-auditable, proprietary drivers and firmware;
(2) full dependence on Google's direction of Android development and how fast Google shares the source code with others, as well as reliance on remote attestation [0];
(3) their disregard of GPLv3 that protects the user more [1];
(4) complete lack of flexibility concerning the user's threat model, e.g., intentional lack of support for root for whitelisted apps and lack of full user control over the running apps [2,3].
- would you call the above "a very long, concrete list of issues" or "attack and drama"?
> It seems especially dangerous being entirely dependant on Google's goodwill; Google has zero need for GOS.
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.
grapheneos 2 hours ago [-]
Google has been increasingly hostile towards GrapheneOS over the past several years despite our substantial contributions upstream. We've spent years helping Google with vulnerability reports, improvements submitted upstream and multiple proposals for security protections which were implemented for both Android and Pixels. We've been treated incredibly poorly by Google despite our contributions.
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.
All the justification in the world won't help GOS. Do they want to be justified or do they want GOS to succeed?
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 18 hours ago [-]
> 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 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.
armadyl 24 hours 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…
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 24 hours ago [-]
> This sentiment isn’t too different from politics in the US right now
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?
grapheneos 3 hours ago [-]
Google has been increasingly hostile towards GrapheneOS over the past several years despite our substantial contributions upstream. We've spent years helping Google with vulnerability reports, improvements submitted upstream and multiple proposals for security protections which were implemented for both Android and Pixels. We've been treated incredibly poorly by Google despite our contributions.
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.
GrapheneOS is not interested in silencing themselves for the sake of greed and optics. Their image is built on explicitly not doing that.
You are making a false dichotomy, and suggesting they give into sanitized, corporate slop approaches rather than stick to their mission. GrapheneOS has gained the resources and relationships they have because they tell it like it is, not because they bend to the will of others out of fear.
bitpush 1 days ago [-]
[flagged]
Rendered at 22:39:48 GMT+0000 (Coordinated Universal Time) with Vercel.
1: https://redlib.catsarch.com/r/GooglePixel/comments/1wr1767/c...
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.
The lags are actually quite unpleasant and noticable, i wonder how it wasn't caught before the release.
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.
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.
Early in the month, the Pixel 11 series received a partial September 2026 security update release. Those didn't receive Android 17 QPR1 or the full 2026-09-05 Pixel security patch level 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.
We haven't launched Pixel 11 support yet due to the many issues with those. MTE support not being available at launch was the biggest issue but there are more. We'll see if they're usable devices meeting our security requirements with Android 17 QPR2 in December 2026.
That's a big pain point for the average user
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.
I just also like to be a realist, and right now things look a bit grim
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.
The point of the post is not that grapheneos made the fix, it's that they had to.
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.
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.
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.
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.
Most national governments in the EU are probably too authoritarian technology-wise to recognize the importance of supporting a project like GrapheneOS as well.
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.
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).
> 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.
https://www.reddit.com/r/GooglePixel/comments/1wvnj9c/lags_o...
https://www.reddit.com/r/GooglePixel/comments/1wtxm0m/pixel_...
https://www.reddit.com/r/GooglePixel/comments/1wu9j93/is_the...
https://www.reddit.com/r/GooglePixel/comments/1wt0od2/new_up...
https://support.google.com/pixelphone/thread/470741051/septe...
https://support.google.com/pixelphone/thread/470915661/phone...
https://support.google.com/pixelphone/thread/470545577/major...
https://support.google.com/pixelphone/thread/470645986/laggy...
https://support.google.com/pixelphone/thread/470478102/phone...
https://support.google.com/pixelphone/thread/470472092/pixel...
Here are some news articles which are primarily about this issue:
https://www.droid-life.com/2026/09/22/latest-pixel-update-ei...
https://www.androidpolice.com/google-pixel-september-update-...
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.
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.
The article uses phrases like "completely broken", "awful", and "<delay> wouldn't be a surprise". Which might be true but it's not helping.
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 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.
* 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.
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.)
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.
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.
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.
GrapheneOS was initially collateral damage for Google's anti-competitive behavior but in the past couple years they've shown they feel threatened by us and are very actively trying to hold us back. It's not everyone at Google doing it but it's enough of them including the people in control.
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.
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?
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 https://news.ycombinator.com/edit?id=49946698.
> Google the entity has a reputation
Yep: "EvilCorp"
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 https://news.ycombinator.com/edit?id=49946698.
P.S. Flagging my comments, as the GrapheneOS fans do, is also far from constructive.
So it's impossible now to list the bad features or shortcomings without come one calling drama?
Why do you call it drama?
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.
- would you call the above "a very long, concrete list of issues" or "attack and drama"?
[0] https://news.ycombinator.com/item?id=45232164
[1] https://news.ycombinator.com/item?id=49594324
[2] https://news.ycombinator.com/item?id=49543420,
[3] https://news.ycombinator.com/item?id=48767841
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.
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 https://news.ycombinator.com/edit?id=49946698.
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.
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.
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.
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?
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 https://news.ycombinator.com/edit?id=49946698.
You are making a false dichotomy, and suggesting they give into sanitized, corporate slop approaches rather than stick to their mission. GrapheneOS has gained the resources and relationships they have because they tell it like it is, not because they bend to the will of others out of fear.