One source-code gap pulled 508 points and 247 comments on Hacker News in less than a day. Android 17 QPR1 exposes 84 new public API elements, but Google has not published the matching quarterly platform release in AOSP. The September 15 update is already rolling out to supported Pixel phones. For developers, that creates an odd interval. The API contract is public and the implementation is shipping on Pixels, while AOSP-based projects have no corresponding public source release to build.
The 0.52 percent gap
Google's API comparison between levels 37 and 37.1 measures the change at 0.52 percent. That small percentage contains 84 additions and 233 changes, with no removals. The additions are counted at their highest level: one package, 13 classes or interfaces, 28 methods, and 42 fields. A newly added class can contain methods that do not appear again in the method total, so 84 is the conservative count supplied by Google's own report.
The additions index shows where the new surface lands. Android 37.1 adds an android.hardware.hid package and APIs for peripheral button or key customization. It expands the embedded photo picker, adds a query for deleted media files, and exposes madvise with Linux memory-advice constants. The list also includes request-timing access for Android's HTTP stack and new Health Connect record metadata. These are callable framework interfaces, rather than Pixel launcher decoration.
The proportions show how concentrated the work is. Google's change statistics put android.hardware.input at a 60 percent difference, the photo picker package at 12 percent, and java.util.jar at 28 percent. Most of the other affected packages move by less than 1 percent. A small platform-wide diff can still be a large revision for the subsystem an app uses.
The CINNAMON_BUN_1 constant gives the release a machine-readable identity. Android 17 remains major API level 37, while QPR1 is full SDK level 37.1. That distinction is how an app can tell a base Android 17 device from one that implements the newer calls.
An API release moved into the wrong quarter
Google set a different expectation when it announced Android's faster cadence. Its Android 16 developer preview schedule assigned APIs to the Q2 major release and Q4 minor release. The updates in Q1 and Q3 were described as incremental feature releases. The first Android 17 beta repeated that plan, with a Q4 minor SDK carrying additional APIs.
By Google I/O in May, QPR1 had become an exception. Google's developer roundup said the third Android 17 QPR1 beta contained a minor SDK release for features that could not wait for QPR2. The 37.1 diff was generated on June 29, and the final Pixel update began rolling out on September 15. The public schedule had gained an extra API release between the two planned ones.
GrapheneOS identified the source mismatch and called QPR1 the first Android release since the tablet-only Honeycomb 3.x series to add app APIs without a simultaneous AOSP release. That historical comparison comes from GrapheneOS. The current mismatch is independently visible in Google's repositories: the public AOSP manifest refs contain the Android 17 release branch and android-17.0.0_r1 tag, with no Android 17 QPR1 or 37.1 release tag at publication time. Google's public frameworks/base branch still points to a May 21 commit for the 26Q2 release, months before the QPR1 rollout.
Public headers are not platform source
An app developer can read the 37.1 additions, download the SDK, and compile against it. Those materials define classes, methods, fields, and availability checks. An operating-system project needs the framework implementation plus the device integration beneath it. API documentation cannot supply changes to system services, framework internals, hardware abstraction layers, drivers, or build configuration. The empty space between those two needs is the issue that GrapheneOS raised.
GrapheneOS says it ported its code to QPR1 before the September 15 release through partner access, but does not have permission to publish that work. The project says it is instead backporting Pixel firmware, kernel and userspace drivers, and hardware abstraction layers onto the public Android 17 base. That account explains why publishing the SDK does not put an AOSP derivative on equal footing with Pixel OS. It also needs source and releasable integration code.
In a follow-up explanation, GrapheneOS said the 37.1 interfaces are standard Android APIs rather than permanent Pixel-only extensions. The project expects them to reach AOSP and other manufacturers with Android 17 QPR2 in December. Google's original Android 17 plan does place the next minor SDK in Q4, but Google has not used the GrapheneOS thread to confirm the exact source-release timing. Until a tag appears, December is an attributed expectation, not a completed release.
37.1 changes the build matrix
A recent Android Gradle Plugin can select a minor SDK explicitly. Google's CompileSdkSpec reference documents the minorApiLevel field, which makes a 37.1 Kotlin build configuration look like this:
android {
compileSdk {
version = release(37) {
minorApiLevel = 1
}
}
}
Compilation is only half of the change. Android does not let an app set targetSdkVersion to a minor release because minor SDKs are not supposed to carry app behavior changes. Google's platform-version guidance tells developers to inspect the full SDK value before calling a minor-release API:
if (Build.VERSION.SDK_INT_FULL >=
Build.VERSION_CODES_FULL.CINNAMON_BUN_1) {
// Call an API introduced in Android 17 QPR1.
}
That full-version guard matters during the current source gap. An app may run on two devices that both report Android 17 at the major-version level, while only the Pixel on QPR1 supplies a 37.1 method. Developers adopting the new surface need a fallback path and tests on both 37.0 and 37.1. A major-version check against SDK_INT alone is too coarse for this release.
The toolchain effect can arrive through a dependency before an app calls any 37.1 API itself. Google's Glance Adaptive 1.0.0-alpha02 notes say its Compose libraries moved to compileSdk 37.1 and that apps and libraries using them must update transitively. A minor platform release can therefore force a build configuration change across a dependency graph even when the final app keeps its runtime behavior unchanged.
That dependency example also changes the decision for library authors. Publishing against 37.1 can raise the minimum compile environment for every consumer, even if the library uses the new call on one optional path. The Gradle API can express the requirement exactly, but downstream teams still need the newer SDK and plugin in continuous integration. Waiting for wider 37.1 device availability may cost less than forcing that upgrade through a large project.
A temporary gap still changes who can ship
The base Android 17 source remains public. Google released it to AOSP in June, and the public android17-release branch is active. The narrower problem is the time between a Pixel API release and the next AOSP release that contains its implementation. Under GrapheneOS's December estimate, that interval lasts about three months.
GrapheneOS's release estimate makes three months the relevant window. That is enough to affect product decisions. Apps running on Pixels can adopt new peripheral, photo picker, and system interfaces while developers for a wider device fleet must keep fallback code. An AOSP project can study the signatures but cannot publish the same platform from those signatures. An Android manufacturer waiting for the shared release receives the implementation later than Google's own phones. Google's minor-SDK design gives software a precise way to describe this split. It does not remove the split.
Google introduced minor SDKs to ship APIs more often. The first such release, Android 16 QPR2, paired that faster API cadence with a normal Q4 release. Android 17 QPR1 tests a different arrangement: the SDK moved forward during a quarter whose platform source was not released to AOSP. Faster interfaces and slower source publication can coexist, and developers now have to account for both clocks.
QPR2 will settle the timing
A QPR2 tag in Google's AOSP manifest refs will make the timing measurable. Its framework surface can then be compared with the 37.1 and 37.2 SDKs. If the QPR1 APIs arrive unchanged in December, the present dispute amounts to a three-month Pixel head start. If future QPR1 or QPR3 builds keep acquiring APIs before their matching source releases, 37.1 will have established a repeatable Android release pattern. Until the tag lands, developers should treat CINNAMON_BUN_1 as a device capability distinct from Android 17.