Android 17 QPR1 is the first release since Android Honeycomb (3.x) adding new APIs for app developers without a release to the Android Open Source Project. The new APIs are currently exclusive to the Pixel OS and aren't available to other Android OEMs.
https://developer.android.com/sdk/api_diff/37.1/changes
developer.android.com
API Differences between 37 and 37.1
JDiff is a Javadoc doclet which generates an HTML report of all the packages, classes, constructors, methods, and fields which have been removed, added or changed in any way, including their documentation, when two APIs are compared.
Sep 16, 2026, 06:15 PM
··Web
2d
Non-Google Android OEMs and AOSP-based projects can ship yearly and QPR2 releases. There are also security backports to those releases. Security preview access is needed to ship patches without months of delay. We've had that since before our Motorola partnership via another OEM.
2d
We already ported our code to Android 17 QPR1 since before it was released on September 15th but don't have permission to release it yet. We're working on backporting Pixel firmware, kernel drivers, userspace drivers and HALs from Android 17 QPR1 to Android 17 for now instead.
2d
Pixel Update Bulletin for September 2026 has additional patches to standard Android platform components used by non-Pixel devices. These patches are relevant to non-Pixel devices but haven't been made available via the September 2026 Android Security Bulletin or preview patches.
2d
Google should not be gatekeeping security patches to the standard Android platform code from Android OEMs but that's what they've started doing. Other OEMs will get these patches in December 2026 via Android 17 QPR2. We can ship them early by reverse engineering the code instead.
2d
It would be interesting to know if Google's legal team is aware they're giving Pixels months of early access to new Android features and bug fixes including certain important security patches. Pixels being given this competitive edge over Google's OEM partners is very dubious.
2d
Google is also once again failing to comply with our GPL source requests for weeks. We requested CD1A.260905.001.A1 sources on September 1st and were only provided access today. The kernel build IDs are the same for 17 QPR1 Beta 9 and 17 QPR1 so we have that already at least.
2d
We could have shipped an Android 17 QPR1 update already since our port was completed. Instead, we have to deal with ongoing pain until Android 17 QPR2 is released in December 2026. This will not be an issue for Motorola since we'll have official firmware and driver code provided.
2d
Pixels are now significantly harder to support than many other devices. One of the only advantages of Pixels is now a disadvantage instead. They're still the best fit for us due to the updates and security features but it burns time we want to spend on privacy and security work.
2d
It will be far easier for us to support upcoming Motorola devices than Pixels. Qualcomm will hopefully expand MTE support beyond the highest end flagship SoC soon so we can expand to more than flagships. Pixel 11 didn't remove it from hardware, only firmware, so that's good news.
2d
@GrapheneOS Are these APIs used for features that are only available in Pixel OS to differentiate it?
I assume that they will be pushed to AOSP as Android 17 QPR2?
2d
@danieldk No, these are standard Android APIs included since Android 17 QPR1. These will be available through AOSP and other OEMs via Android 17 QPR2 in December 2026. It's currently exclusive to Pixels because it was released as part of Android 17 QPR1 since QPR1 and QPR3 releases are now Pixel exclusive since Android 16.
This is simply the first time they've added APIs in a QPR1 or QPR3 release following no longer releasing QPR1 and QPR3 to AOSP after the release of Android 16.
2d
@GrapheneOS @danieldk 🤔 👌🏼 👍🏼
1d
@GrapheneOS These new APIs are currently exclusive to Pixel OS and are not available to other Android device manufacturers... and what exactly are they supposed to bring? What advantages or disadvantages does this entail for Pixel devices or GrapheneOS?
@GrapheneOS@grapheneos.social Blergh >:(
2d
@GrapheneOS I assume this is not good news?
2d
@GrapheneOS yep google locking down android even more.
would not suprise me they kill AOSP altogether in some years
2d
@GrapheneOS Is Motorola willing to be as open as google was with Pixels, or do they see it as an opportunity for good press?
1d
@GrapheneOS Did you see this?🤔 This poor guy 
lost his job🤦🏼 now🤷🏼 #privacy
1d
Samuel Tunick allegedly wiped his GrapheneOS phone before CBP officials could search it, in what has become a high profile civil liberties case. Now Georgia State University has rescinded a job offer to him.
404 Media
· 1d
University Rescinds Job Offer to Activist Who Allegedly Wiped Phone Before DHS Could Search It
Samuel Tunick allegedly wiped his GrapheneOS phone before CBP officials could search it, in what has become a high profile civil liberties case. Now Georgia State University has rescinded a job offer to him.
1d
@GrapheneOS will Motorola’s folding phones be included?
1d
*
@GrapheneOS logistically speaking, how would graphene operate for locked Motorola phones? Have you found a work around for that?
@sschuler @GrapheneOS if a phone has been locked to a carrier at any point in it's lifetime, 9 times out of 10, the bootloader is permanently locked. There's nothing the gos team can do about that. There are exceptions which are rare, but carriers almost always permanently lock the bootloaders on phones they sell you. Some older phones have firmware cracks to re-unlock it, but that's also a rare occurrence with modern phones.
@GrapheneOS are you already planning to drop the support for pixel phones?
@taraxippos No, and we still plan to support the Pixel 11 series as long as it gets fully functional MTE support.
@GrapheneOS maybe a good thing in the end. It quite bothered me to buy a google phone to get a degoogled and secured phone.
@GrapheneOS
> Pixel 11 didn't remove it from hardware, only firmware, so that's good news.
So performance could be okay if you tinker around with the firmware?
@tofudude Performance appears to be fine for MTE on the Pixel 11. We don't know which it was completely removed from firmware and disabled at launch. It's added back to firmware but still disabled in Android 17 QPR2 Beta 4 which was released after our initial thread about it. We used that to enable it and test it. It passes all our tests and other standard tests. We benchmarked it and the performance is fine. There may be cases where it has higher overhead but the faster CPUs make up for it.
@GrapheneOS I really hate Google more and more. Unfortuntaly because they do that, I bought a pixel because i care about my privacy and security, and now I would have to either buy a motorola phone in like 1-2 years because google stops letting us install custom roms... I am not saying i don't like motorola, they are making great phones but yeah... wish you the best in the project and the collab with motorola
Worth checking : a potential abusive anti-competitive practice from Google.
@GrapheneOS Is it even worse than merely contractual or regulatory?
With today's AI-powered rapid reverse-engineering, isn't releasing a security fix tantamount to disclosing the vulnerability to threat actors?
If so, doesn't availability of fixes for only some affected Android devices constitute irresponsible/negligent/malicious disclosure for the rest?
> With today's AI-powered rapid reverse-engineering, isn't releasing a security fix tantamount to disclosing the vulnerability to threat actors?
Yes, and we can reverse engineer it ourselves to ship it before December 2026 so it's not the end of the world.
It heavily draws into question what is supposed to be accomplished by the security preview system instead of simply allowing the patches to be shipped immediately as source code. It's hardly hidden by hiding that for months.
How on earth have you ported to it already? Do you have early partner access?
Who is the party that needs to give permission to release the code/binary? Google?