Google shipped Android 17 QPR1 to Pixels on September 15 with a new API level, 37.1, and no matching source drop to the Android Open Source Project. GrapheneOS pointed this out on September 16: it is the first Android release since Honeycomb, back in 2011, to add app developer APIs that other OEMs can't build against. The code reaches AOSP with Android 17 QPR2 in December.

Google's own API diff report between level 37 and 37.1 lists one new package, android.hardware.hid, and changes in 16 existing packages, including android.media, android.os, android.telecom, android.view, and android.health.connect. That's a normal minor SDK bump. The abnormal part is that the only devices running it are Pixels.

How the cadence got here

The cause is a schedule change Google announced in January. Effective 2026, AOSP source drops happen twice a year, in Q2 and Q4, instead of quarterly. Google's stated reason, as quoted by How-To Geek, was to "align with our trunk-stable development model and ensure platform stability." Android 16 was the trial run. Its QPR1 source landed in November 2025, about two months after the Pixel release, against a historical norm of 24 to 48 hours. With Android 17, QPR1 and QPR3 are Pixel releases, full stop.

That was tolerable while QPRs were what Google said they were: fixes and UI tweaks. Google's release notes for Android 17 QPR1 still say these updates "don't include app-impacting API changes" and that QPRs are "delivered both to AOSP and to Google Pixel devices." The same page then says the API surface locked at Beta 6 and links to the 37.1 diff report. Both statements can't be true. There's a new package in the diff and no AOSP tag to check out.

Honeycomb is the right comparison. In 2011 Google withheld the Android 3.x source because the tablet build wasn't ready for phones, and it took Ice Cream Sandwich that November to put everything back in AOSP. That was one gap, explained at the time, and it never repeated. This one is scheduled. It happens twice a year by design.

Targeting API 37.1 today

If you write an Android app, you can compile against 37.1 now. Your users on Pixel 6 through Pixel 11 get the new code paths. Everyone on Samsung, Motorola, OnePlus, or anything else gets whatever fallback you wrote, because their OEM has no source to build 37.1 from. December is when that changes, and then the usual OEM update lag adds months on top.

Minor SDK levels were already awkward. The idea behind 36.1 and 37.1 was that features would arrive between major releases and apps would check for them at runtime. That works when every OS maker can ship the extension. It stops working when only one of them can.

Android has had a "Google first, AOSP later" split for over a decade. Play Services, launched in 2012, moved feature after feature off the platform and into a proprietary layer, and nobody was shocked that Google's own apps got things before the open source equivalents did. The platform API itself was the line that didn't move. Every OEM built against the same android.* surface and shipped it, some faster than others. A three month head start on public platform APIs, for Google's own hardware, is a different thing from Google apps having a head start.

Patches for shared code, Pixels only

GrapheneOS's second complaint is the bigger one. The September 2026 Pixel Update Bulletin includes patches to standard Android platform components, the code every OEM ships, which are not in the September Android Security Bulletin and not in the preview patches partners get. Other OEMs receive them in December with QPR2. GrapheneOS says it will ship them earlier by reverse engineering the Pixel build.

Consider that from the position of someone managing a fleet of Android devices. Google knows about bugs in shared platform code. Google has fixed them, on Pixels, in a public release. Anyone can diff the Pixel build and locate the fixes. Samsung and Motorola devices can't get the patch through official channels for three months. That is a disclosure with no fix available, published by the vendor, on a schedule.

Google's answer, given to Android Authority, is that QPR1 is rolling out to Pixels first and the additions are now part of the wider Android platform, so they could show up in updates from other manufacturers later. That's the same fact with a friendlier verb.

GPL requests are slipping too

GrapheneOS requested the GPL kernel sources for build CD1A.260905.001.A1 on September 1 and got access on September 16. Two weeks for a source request on a shipped binary is a compliance problem no matter how you feel about custom ROMs. The GPL has no "next quarter" clause. Google's legal team, GrapheneOS suggested, might want to know that Pixels now get months of early access to platform features and security fixes over Google's own OEM partners.

GrapheneOS had a port of Android 17 QPR1 done before the September 15 release and can't publish it, because the platform source it would need to ship isn't public. The project is backporting Pixel firmware, kernel drivers, userspace drivers, and HALs to Android 17 instead and waiting for December. Its conclusion is that Pixels are now harder to support than many other devices, and that its upcoming Motorola partnership, with official firmware and driver code, will be easier. The one hardware line that was supposed to be the reference Android device is now the hard one.

I run servers, not phones, but the pattern is familiar. A vendor with a shared codebase and a house product starts shipping the house product ahead of the code. Every step is defensible on its own: one trunk, fewer drops. The end state is that the open version becomes a reference implementation nobody ships, and the real platform is the one you can only get on the vendor's own hardware. That is how Android turns into a Google product with an AOSP snapshot attached, rather than the reverse.

Anyone who chose Android for a device fleet because it was open, with multiple suppliers building from one source, should revise that assumption. There are still multiple suppliers. They're now a quarter behind, on APIs and on security fixes, and Google has said in writing that this is the schedule.

December's QPR2 will close the gap for a quarter. QPR3 in March will reopen it. My prediction: Android 18 will include at least one more API bump that AOSP gets late, and nobody at Google will call it a policy change.