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 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.
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 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.
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.
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.
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.
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.
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..
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
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
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.
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.
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
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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 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.
I updated about an hour ago. Thank you for your work! :)
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 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.
Based on the timeframes in the linked post, it likely won’t
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]
1: https://redlib.catsarch.com/r/GooglePixel/comments/1wr1767/c...
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.
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.
Gosh, I have noticed a number of my apps (Pixel 11 fold 'pro') simply halting under high workload. This is that I suppose.
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.
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.
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.
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..
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
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.
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
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.
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
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.
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
And you can't tap to pay with PayPal, at least not in my region. Tap to Pay is the big thing
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.
I'm using WhatsApp on my GrapheneOS handset without issues.
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).
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.
Why wont GOS contribute this to upstream?
Upstream is both very contribution unfriendly and their treatment of GrapheneOS leads GOS to not want to contribute anything to them anymore.
Because Google is already picking patches from GOS ;-)
I'm confused, so if open source is working as expected then what's the point of the blogpost?
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.
Citation needed.
If you look at the patch, it is just disabling a (presumably new and buggy) feature.
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.
> 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.
I love you, GrapheneOS. XOXOX
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.
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.
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.
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.
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.
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).
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.
AOSP and its derivatives are linux distros.
Is this in stock Android? If so that is crazy.
It definitely impacts the stock Pixel OS and many users are complaining about it. Here are a bunch of user reports:
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.
I knew something was up!