The Pixel-Only Android 17 APIs Include 24 Linux Flags Already Sitting in AOSP
Hacker News spent 478 comments arguing about Google's motives without naming a single API. We read the diff: 84 additions, 0 removals, and 12 of the 48 names we checked are already in public AOSP source.
The WJS Desk
Sep 21, 2026 · 7 min read
GrapheneOS posted two sentences to Mastodon on 16 September, and Hacker News turned them into 890 points and 478 comments. The claim was narrow and precise: Android 17 QPR1 is the first release since Honeycomb (3.x) to add new APIs for app developers without a corresponding release to the Android Open Source Project.
What we could not find in those 478 comments was a single added API named out loud. So we opened the diff GrapheneOS linked, all 317 changed elements of it, and then checked every added name against AOSP's own public API signature files. The headline number is 84 additions and 0 removals. The more useful number is 12, which is how many of the 48 added names we sampled are already sitting in public AOSP source right now.
What GrapheneOS actually claimed
The original post is worth reading in its exact wording, because the HN thread drifted a long way from it within about forty comments. GrapheneOS said the new APIs "are currently exclusive to the Pixel OS and aren't available to other Android OEMs."
When a reader asked whether these were Pixel differentiation features, GrapheneOS answered themselves, and the answer is the least inflammatory reading available:
"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."
So the mechanism is a release-schedule change that landed a year ago, not a new decision about these particular APIs. Since Android 16, the first and third quarterly releases each year go to Pixels only. Android 17 QPR1 is simply the first of those to contain app-facing API additions. The gap is roughly three months: QPR1 shipped 15 September 2026, QPR2 is due in December.
The diff is 317 elements and about half a percent of the API
Google's own JDiff report compares API level 37 to 37.1 and puts hard numbers on it, which is more than the thread did.
| Type | Additions | Changes | Removals |
|---|---|---|---|
| Packages | 1 | 16 | 0 |
| Classes and interfaces | 13 | 40 | 0 |
| Methods | 28 | 10 | 0 |
| Fields | 42 | 167 | 0 |
| Total | 84 | 233 | 0 |
Google computes the overall difference between the two levels at 0.52%. Nothing was removed, which matters: no app compiled against API 37 breaks. The single added package is android.hardware.hid. The most-changed package by percentage is android.hardware.input at 60%, and the most-changed class in the entire release is java.util.jar.JarOutputStream at 90%, which is not a sentence anybody expected to write about a Pixel exclusivity story.
The largest single block of additions is 24 constants named MADV_COLD, MADV_COLLAPSE, MADV_HUGEPAGE, MADV_WIPEONFORK and so on, plus one method, Os.madvise(long, long, int). Those are the flags to the Linux madvise(2) syscall. They are not a Pixel feature in any sense. They are a thin wrapper over a kernel call that has existed for decades, now exposed to app developers.
We checked every added name against AOSP source
This is the part the thread skipped. AOSP publishes API signature files (api/current.txt) that record exactly what is public. We pulled them from the android17-release branch of platform/libcore, platform/frameworks/base, packages/modules/HealthFitness, packages/modules/Connectivity and packages/providers/MediaProvider, took 48 names from the diff's additions index, and grepped each one.
Twelve of the 48 are already there. Including, in full, the madvise block:
method @FlaggedApi("com.android.libcore.madvise_api") public static void madvise(long, long, int) throws android.system.ErrnoException;
field @FlaggedApi("com.android.libcore.madvise_api") public static final int MADV_COLD;
field @FlaggedApi("com.android.libcore.madvise_api") public static final int MADV_COLLAPSE;
...24 MADV_* constants totalThe implementation is public too. Os.java on the android16-release branch already carries the method, annotated the same way. The new package is public as well: android.hardware.hid.HidManager appears in frameworks/base behind @FlaggedApi("com.android.hardware.input.hid_api"), along with the ACCESS_HID permission string.
What this changes: for those twelve, the code is not being withheld. The declaration and the implementation are both in public AOSP, gated behind an aconfig flag. What is Pixel-exclusive is the build where that flag is flipped on, which is what makes the API usable from an app. "Google is hiding the source" is the wrong description. "Google is shipping the build that enables it to one OEM first" is the right one.
What is genuinely not in AOSP yet
Thirty-six of the 48 we checked returned nothing. The biggest cluster is peripheral customization, which is the feature that actually looks like a product: addPeripheralCustomization, getPeripheralCustomization, removeAllPeripheralCustomizations, ButtonCustomizationTrigger, KeyCustomizationTrigger, AppCustomizationAction, UriCustomizationAction, isKeyAllowedForCustomization, and a MANAGE_PERIPHERAL_CUSTOMIZATION permission. That is keyboard and mouse button remapping, and it explains the 60% churn in android.hardware.input.
The rest is a grab bag: MediaStore.DeletedFiles and queryDeletedFiles (a trash-can query), KEYCODE_CONTEXTUAL_QUERY, getFinishedRequestTimings in android.net.http, photo picker tab control (TAB_ALBUMS, TAB_IMAGES, setLaunchTab), and focus navigation tuning. One small detail we enjoyed: Build.VERSION_CODES.CINNAMON_BUN is in AOSP at value 37, but CINNAMON_BUN_1, the constant that names the QPR1 release itself, is not.
Two honest caveats on our own number. We sampled 48 names from the additions index rather than all 84 reported elements, because the index lists symbols and the count lists highest-level program elements, so they are not the same unit. And we could not locate a public signature file for every module, so a symbol we marked absent could in principle live somewhere we did not look. The twelve we found present are confirmed by direct quotation from the files.
The thread argued about motive and missed the mechanism
Most of the 478 comments were about whether Google regrets open-sourcing Android. A handful did the actual work. HN user bri3d laid out the release mechanics correctly and then landed on the conclusion we think holds up: "it's highly unlikely any app developer would actually depend on these new APIs, since Pixel marketshare is tiny to begin with. This in essence just makes Pixels a weird beta-testing device for what will come out a quarter later."
The sharpest dissent came from mdwrigh2, who pushed back on the framing entirely: "All of the major OEMs have access to the internal source with a very small delay. OEMs don't ship these intermediate releases because they choose not to, not because Google withholds the source for them." jeroenhd made a related point, that Google is not singling out GrapheneOS, and that "despite their very worst, selfish intentions, Google is the very best vendor of commercial open source software."
Nobody forks an operating system over a keyboard remapping API.
The real cost is four posts down the thread
GrapheneOS's own follow-up posts contain a much sharper complaint than the one that went viral, and it is not about APIs at all. They say the September 2026 Pixel Update Bulletin "has additional patches to standard Android platform components used by non-Pixel devices" that were not published in the September Android Security Bulletin, and that other OEMs get them in December via QPR2. Their phrasing: "Google should not be gatekeeping security patches to the standard Android platform code from Android OEMs but that's what they've started doing."
They also report a practical consequence for themselves. Their Android 17 QPR1 port was finished before the 15 September release, and they do not have permission to ship it, so they are backporting Pixel firmware, kernel drivers and HALs to Android 17 instead. And they say Google took from 1 September until 16 September to answer a GPL source request for build CD1A.260905.001.A1.
That is the story with teeth. A three-month window where one OEM has security fixes for shared platform code and the others do not is a competition question and a user-safety question at the same time. The API diff is a symptom; this is the disease. The open question we cannot answer is how many of those September Pixel patches are genuinely security-relevant to non-Pixel devices, because Google does not publish that breakdown, and GrapheneOS characterising them as "certain important security patches" is an assessment rather than a count.
Your turn
If you ship an Android app, the practical question is small: are you actually going to compile against API 37.1 before December, knowing the features behind it reach non-Pixel devices in QPR2? We think almost nobody will, and we would like to be wrong. If you have a real reason to want Os.madvise or peripheral remapping on a three-month exclusive, tell us what you are building, because that is the case for this being a genuine problem rather than a scheduling artefact.
If you are tracking how much control Google is taking back over what ships on Android devices, the other half of that picture is the developer verification requirement we covered earlier: Google starts blocking unverified Android apps on September 30, and F-Droid has the harder problem. Same direction of travel, different lever.
