Android 17 QPR1 APIs are Pixel-only until December: check the minor version

Android 17 QPR1, released to Pixel phones in the September Pixel Drop, adds new developer APIs that other Android phones do not yet have. According to GrapheneOS, it is the first Android release since the Honeycomb era to ship new Android 17 QPR1 APIs without publishing them to the Android Open Source Project at the same time. For app teams, the consequence is simple and easy to get wrong: until the code reaches other manufacturers, two phones on "Android 17" can expose different APIs.

What happened with Android 17 QPR1 APIs

As Android Authority reports, Google released stable Android 17 QPR1 on Pixels as part of the September Pixel Drop. GrapheneOS, which builds its operating system from AOSP, says the release contains APIs and other changes not made available to the wider ecosystem. It says it ported its code to QPR1 before the 15 September release but does not have permission to ship it, and expects other manufacturers to receive the changes with Android 17 QPR2 in December.

Android Authority notes that Android's developer documentation does show API differences between Android 17 and Android 17 QPR1, and that Google previously gave developers QPR1 GSI builds described as built from the same AOSP and GMS sources as the Pixel builds. GrapheneOS also says some security fixes for standard platform components appeared in the Pixel Update Bulletin but not in the general Android Security Bulletin for other manufacturers. Google has not been quoted in response, and the dispute about openness is between Google and AOSP-based projects. The engineering consequence for app developers is the part you control.

Why the usual version check is not enough

Since Android 16, Google has shipped new developer APIs in a minor release in Q4 as well as the main release. The Android 16 documentation explains that checks using SDK_INT continue to work for major releases, while the new SDK_INT_FULL constant covers both major and minor versions. The Build.VERSION reference describes SDK_INT_FULL, added in API level 36, as "the major and minor SDK version of the software currently running on this hardware device", and notes that it may increase when the manufacturer provides an update.

That system assumes a minor version means the same APIs everywhere it exists. For QPR1, it currently means "on a Pixel". A Samsung, Motorola or Xiaomi phone on Android 17 will not report the QPR1 minor version until its manufacturer ships the QPR2-based update, so a correct SDK_INT_FULL check simply returns false there — which is fine, as long as the app has a fallback.

Some early coverage has garbled the details. One widely shared developer post describes the change as affecting "Android 17" in general and uses the wrong SDK level in its example. The accurate version is narrower: the gap is in the QPR1 minor release, and the right guard is a minor-version or feature check, not a major-version one.

How to check if an Android API is available

1. Use the right constant. Guard QPR1 APIs with SDK_INT_FULL against the minor-version code, not SDK_INT against the major one.
2. Prefer feature checks where they exist. Where an API is exposed through a system service or a feature flag, check that it is present rather than inferring it from the version.
3. Isolate new-API code. Keep QPR1-only calls behind a small wrapper class, so class loading on older devices does not touch them, and so the wrapper can be deleted when the API is universal.
4. Write the fallback first. Decide what the feature does on a phone without the API — hide it, degrade it, or use an older API — and test that path, not just the new one.
5. Test on more than Pixels. Add at least one non-Pixel device or an AOSP-based emulator image on Android 17 to your test matrix. A Pixel-only matrix will pass while most of your users see the fallback.

Cross-platform apps are not exempt. React Native and Flutter plugins call the same platform APIs underneath, so a plugin that adopts a QPR1 API needs the same guard. If you are weighing frameworks, our comparison of React Native and Flutter covers how each handles native API access.

Should apps use Android 17 QPR1 APIs now?

For most apps, only for enhancements. Pixels are a minority of Android phones in most markets, and certainly in India and the Gulf. A feature that exists only on the newest Pixels until December — and on other brands only when their QPR2 updates arrive, which historically takes months — cannot carry core functionality. Use QPR1 APIs where they make an experience better on phones that have them, and ship nothing that depends on them.

Library authors should be more cautious still. Waiting a release before depending on a minor-release API avoids pushing the fragmentation problem onto every app that uses the library.

When will Android 17 QPR1 APIs reach other phones?

According to GrapheneOS, other manufacturers receive the code with Android 17 QPR2 in December 2026. Each manufacturer then decides when to ship it to users. Plan for a long tail: the API will be available on some non-Pixel phones in early 2027, and on many others later or never.

This is the second Android change this month that affects how apps reach users, after developer verification from 30 September. Both reward teams with a disciplined release and test process over those that test on one flagship and ship. If your Android test matrix is a single Pixel, our Android app development team can set up device coverage and API guards that keep new features from turning into crashes.