DEV Community

Cover image for Android 17 QPR1: why the new APIs are Pixel-only until December
Nikoloz Turazashvili (@axrisi)
Nikoloz Turazashvili (@axrisi) Subscriber

Posted on

Android 17 QPR1: why the new APIs are Pixel-only until December

#android #google #opensource #security

Android 17 QPR1 reached Pixel phones on September 15 with 84 new APIs for app developers, and for about three months exactly one phone maker is allowed to ship them: Google. The source code did not go to the Android Open Source Project (AOSP) with the release. GrapheneOS noticed, the Hacker News thread reached 951 points, and the more serious problem turned out to be the security patches stuck behind the same door.

TL;DR

  • The official API diff from level 37 to 37.1 has 84 additions, 233 changes and 0 removals. Google's own page puts it at about 0.52 % of the platform: small, but it includes a whole new package.
  • Per GrapheneOS, since Android 16 the first and third quarterly releases (QPR1, QPR3) are Pixel-only. Samsung, Motorola and custom ROMs get these APIs with QPR2 in December.
  • GrapheneOS says the September Pixel bulletin fixes standard Android components that other phones run too, and those fixes are not in the public Android Security Bulletin.
  • The last time Google held back a release's source was Honeycomb, Android 3, in 2011.

GrapheneOS on X, Sep 16 2026:

What is new in Android 17 QPR1 for developers?

Android now ships a platform release every year and a quarterly platform release (QPR) in between. QPR1 went out on September 15 with the September Pixel Drop to 25 Pixel models, from Pixel 6 to Pixel 11 Pro Fold. It is API level 37.1, and Google publishes a machine-generated API diff for it, dated June 29.

Android Developers API Change Statistics, level 37 to 37.1: 84 additions, 233 changes, 0 removals, 317 total,

The biggest item is a new package, android.hardware.hid, with its own system service and permission. It lets an app talk to USB and Bluetooth HID peripherals (controllers, keyboards, custom input devices) directly, without a custom driver. The rest, from the additions index:

# symbol names from the 37.1 additions index (not a complete list)
android.hardware.hid                      # new package
Context.HID_SERVICE
Manifest.permission.ACCESS_HID
InputManager.addPeripheralCustomization   # android.hardware.input
ButtonCustomizationTrigger
Build.VERSION_CODES_FULL.CINNAMON_BUN_1
Enter fullscreen mode Exit fullscreen mode

There are also new java.util.jar CEN constants, photo picker UI parameters and a telecom CAPABILITY_TRANSFER. And CINNAMON_BUN_1 is the internal dessert name of Android 17. The dessert names are back, in a constant, where nobody can see them.

If you write controller or peripheral software, the HID package is the API you wanted. You can ship it today to Pixel owners only.

Why are the Android 17 APIs Pixel-only?

Because of how Google now builds Android. On March 26, 2025, Google confirmed to Android Authority that all Android OS development was moving to its private internal branch, and said it was "committed to publishing source code to AOSP after each release".

"After each release" turned out to have a schedule. Per GrapheneOS, since Android 16:

Release Goes to When
Android 17 AOSP June
Android 17 QPR1 Pixel only September
Android 17 QPR2 AOSP December
Android 17 QPR3 Pixel only March

So the 84 APIs reach the open source project, and with it every other Android OEM, with QPR2 in December. That's three months of Pixel exclusivity per cycle, twice a year.

There was a warning. Android 16 QPR1 shipped to Pixels on September 3, 2025; its source landed on AOSP on November 11, 69 days late. At the time Google told Android Authority that it "typically publishes source within 24–48 hours" and that the code would come "in the coming weeks". What's new this time is that a Pixel-only release adds public APIs for app developers.

Is Android still open source? The Honeycomb precedent

GrapheneOS reached for one word: Honeycomb. Android 3.x was the tablet-only release from 2011, and Google kept its code back too. It appeared with Ice Cream Sandwich, Android 4.0. For fifteen years it was the one exception people pointed to.

The top comment on HN, from wps, was blunter: "Google simply regrets android being open source." I wouldn't go that far. Android is still open source in the sense that the code arrives. What changed is when, and who gets it first. The yearly release and QPR2 still land in AOSP; the gap is a timing gap, and Google's own phones are on the right side of it.

The part that matters more: security patches

The APIs are the headline. The patches are the problem.

GrapheneOS says the September Pixel Update Bulletin contains fixes to standard Android platform components, code that every other OEM builds on, and that those fixes are in neither the September Android Security Bulletin nor the preview patches partners receive. Other OEMs get them in December, via QPR2.

Think about what that means for one quarter. Pixels are patched against bugs in code that billions of other devices also run, and the fix sits in a binary anyone can download but nobody outside Google can read in source form. GrapheneOS plans to reverse engineer the patches out of that binary and ship them early. That rather defeats the purpose of keeping them private: anyone with a disassembler and worse intentions can do the same.

Then the kernel. The Linux kernel is GPL, so its source for a shipped build has to be available. GrapheneOS requested the kernel sources for build CD1A.260905.001.A1 on September 1 and got access on September 16: fifteen days.

GrapheneOS and Motorola: who is leaving Pixel

For years GrapheneOS told people to buy a Pixel, because they were the best fit for a hardened OS. It had already ported to 17 QPR1 before the release, but "don't have permission to release it yet" (GrapheneOS on X). Instead it is backporting the Pixel firmware, kernel drivers and HALs from QPR1 onto plain Android 17, by hand, until December.

In their words, "Pixels are now significantly harder to support than many other devices. One of the only advantages of Pixels is now a disadvantage" (thread).

The timing is convenient. On March 2, 2026, GrapheneOS announced a long-term partnership with Motorola, with official firmware and driver code included, and the same thread says: "It will be far easier for us to support upcoming Motorola devices than Pixels" (X, Mastodon). The most security-focused Android project spent seven years recommending Pixels, and Google has spent eighteen months talking it out of that.

The other side: why some developers don't care

The best dissent on HN came from bri3d. Google still drops real source every half year, and Pixels get four updates a year. He calls it "highly unlikely any app developer would actually depend on these new APIs, since Pixel marketshare is tiny". This, he argues, "makes Pixels a weird beta-testing device for what will come out a quarter later", which is "a weird thing to get really mad about".

On the APIs, I agree. Half a percent of an API is not a fork. The HID package will be everywhere in December, and nobody ships a production feature that works on one brand of phone.

The security patches are a different argument, and GrapheneOS asked the sharper question: "It would be interesting to know if Google's legal team is aware they're giving Pixels months of early access… Pixels being given this competitive edge over Google's OEM partners is very dubious" (thread). Android's defence against antitrust claims has long been that it is the open platform. A head start for the platform owner's own hardware is an odd thing to hand the other side. As of the episode, Google had not publicly responded.

What Android developers should do now

  • Treat 37.1 APIs as Pixel-only until QPR2. Gate them on the minor SDK version (37.1 is Build.VERSION_CODES_FULL.CINNAMON_BUN_1 in the diff) and keep a fallback path. December is when the HID package becomes a real target.
  • If you build peripheral or controller apps, prototype on a Pixel now. It's the one device where you can.
  • If you run a custom ROM or ship your own Android build, plan for a quarter-long lag on platform fixes, twice a year, and watch the Pixel bulletin as well as the Android Security Bulletin.
  • If you pick phones for security-sensitive users, the Pixel-by-default advice now comes with an asterisk. GrapheneOS's Motorola devices are the thing to watch.

Also today: Cloudflare Quick Tunnels and OpenAI's chip

Cloudflare Quick Tunnels hit #1 on HN. 766 points for try.cloudflare.com, Cloudflare's quick tunnel page. The top-voted correction, from noname120: Quick Tunnels have existed for more than five years, with an archive.org snapshot from December 2021. The front-page hit was a new landing page.

OpenAI and its Jalapeño chip. IEEE Spectrum reported how OpenAI used its own LLMs to help design its Jalapeño chip (HN). The article is paywalled; the video covered the headline only.

Verdict: REVERT

I stamped it REVERT, and the target is narrow. Eighty-four APIs are a footnote; nobody's roadmap depends on half a percent of a platform for one quarter. A security fix for shared code that only one OEM can ship for three months is another matter: it's a fork with a press embargo. The fix costs Google nothing but a push: publish the QPR source, or at least the platform patches, when the Pixel build ships.

FAQ

When will Android 17 QPR1 source code be released to AOSP?
Per GrapheneOS, the QPR1 changes reach AOSP with Android 17 QPR2 in December 2026. QPR1 and QPR3 are Pixel-only releases since Android 16.

What are the new APIs in Android 17 QPR1?
The official diff lists 84 additions, headed by the new android.hardware.hid package for direct USB and Bluetooth HID access, plus input customization, photo picker and telecom additions.

Does Google still publish Android source code?
Yes, the yearly release and QPR2 go to AOSP. Since March 2025 development happens in a private branch, and QPR1 and QPR3 source now arrives a quarter later.

Why is GrapheneOS moving to Motorola?
GrapheneOS says Pixels are now "significantly harder to support" because of the delayed source, and that Motorola's partnership gives it official firmware and driver code.

Sources

This article expands on an episode of **The Daily Diff, a five-minute daily video on what shipped and what broke in tech.
Watch the episode · Subscribe on YouTube · the written diff lands in your inbox every morning at thedailydiff.dev.

Top comments (0)