GrapheneOS has fixed the Android 17 QPR1 kernel performance regression

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.

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.

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.

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.

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.