Android 17 Readiness for React Native and Expo Apps
Android 17 is API level 37. Preparing a React Native or Expo app for it is not one switch: running the existing app on an Android 17 device, compiling against SDK 37, and targeting API 37 are three different decisions.
This guide keeps those layers separate so a team can find compatibility issues before opting into a new target SDK.
This article was reviewed on September 7, 2026. Android 17 documentation and tooling are still changing. Recheck the linked Android, React Native, Expo, and Google Play sources before changing a production build or store submission.
The four Android 17 states
| State | What changes | Why it matters |
|---|---|---|
| Existing binary on Android 17 | Device OS only | Finds behavior changes that affect every app, regardless of target SDK |
Existing target with compileSdk = 37 | Build API surface | Lets native code compile against Android 17 APIs without opting into all target-37 behavior |
| Existing app with selected compatibility toggles | Individual runtime changes | Isolates a targeted behavior before the full target SDK change |
targetSdk = 37 | Runtime behavior contract | Enables changes that apply only to apps targeting Android 17 or higher |
Google's Android 17 migration guide
recommends the same two-phase approach: test compatibility first, then adopt the
new target and APIs. You can usually correct all-app compatibility problems
without immediately changing targetSdk.
Phase 1: run the existing app on Android 17
Start with the current signed or release-like app on an Android 17 emulator or device. Do not change the target SDK yet. Review the official behavior changes for all apps and prioritize the parts your app actually uses.
The documented all-app changes include areas such as:
- memory-limit enforcement;
- one-time-password and SMS handling;
- per-app Android Keystore limits;
- cross-profile loopback traffic;
- background audio behavior.
This is not a substitute for an app-specific inventory. A media app, an enterprise app, and a simple catalog app have different risk surfaces.
Compatibility test matrix
Test at least:
- cold and warm launch;
- sign-in, recovery, deep links, and authentication callbacks;
- foreground and background transitions;
- notifications and notification actions;
- camera, photo picker, microphone, files, and location when used;
- audio focus, playback, and media controls when used;
- local-network, Bluetooth, or companion-device workflows when used;
- uploads, downloads, offline mode, and interrupted requests;
- large data sets and memory-intensive screens;
- app update from the currently published version.
Capture device, OS build, app version, target SDK, and reproduction steps for each failure. “Works on the emulator” is not enough evidence for a release.
Phase 2: compile against SDK 37
Google's current Android 17 SDK setup guide uses SDK 37 for both the platform and build tools. At the time of this review, it recommends Android Studio Meerkat 2024.3.1 or newer and AGP 8.9.0-rc01 or newer for direct SDK access.
android {
compileSdk = 37
defaultConfig {
// Keep the existing target during compatibility work.
targetSdk = 36
}
}
compileSdk = 37 exposes Android 17 APIs to native code. It does not, by
itself, opt the app into every target-37 behavior change.
React Native 0.87 already compiles against SDK 37 and also raises other Android toolchain requirements, including Android Gradle Plugin 9 and Kotlin 2 or newer. Treat that as a framework-and-toolchain migration, not merely an SDK edit. Run the React Native 0.87 upgrade readiness check before combining the changes.
Phase 3: evaluate target SDK 37 changes
The official target-37 behavior guide documents changes that apply only after the app targets Android 17. Review the full current list; relevant examples at the time of this article include:
- a new
MessageQueueimplementation that can break reflection on private fields or methods; - rejection of attempts to mutate
static finalfields through reflection or JNI; - stricter background activity and audio behavior;
- certificate transparency enabled by default;
- safer rules for loading native code dynamically;
- changes to Contacts Provider access;
- mandatory adaptive behavior on large screens, with older orientation and aspect-ratio opt-outs removed;
BluetoothSocketreads returning-1when an RFCOMM connection closes.
Do not infer that an app is affected merely because a change exists. Search the application and native dependencies for the relevant API, reproduce the behavior, and attach evidence to the migration ticket.
Android compatibility toggles can help test individual target-gated changes without enabling every change at once. Use them in debug or automated test environments and reset the device state after each focused experiment.
React Native dependency checklist
Inventory every dependency with Android code, then verify its release notes, issue tracker, and actual build against the chosen React Native and Android toolchain combination.
Pay particular attention to:
- navigation, screens, gestures, and animations;
- Firebase and other Google SDKs;
- authentication and deep-link callback libraries;
- notifications, background tasks, and foreground services;
- audio, video, camera, Bluetooth, and local networking;
- storage, databases, encryption, and dynamic code loading;
- maps, location, payments, and in-app purchases;
- custom Java, Kotlin, C++, or JNI modules;
- Gradle plugins and scripts that access internal AGP APIs.
Remove unused native packages before the upgrade. Each unnecessary module adds a build and runtime compatibility boundary.
Expo dependency checklist
For an Expo app, the supported React Native and Android versions come from the
selected Expo SDK. Do not force compileSdk or React Native beyond that
supported combination merely to match a generic guide.
Before opting into Android 17:
- check the current Expo SDK changelog and supported React Native version;
- run Expo's project and dependency diagnostics;
- inventory config plugins and packages that generate native code;
- create a clean prebuild diff if the project uses generated native projects;
- verify EAS Build images and local CI toolchains;
- build an Android App Bundle and an installable release APK;
- test
expo-updatesruntime compatibility separately from native changes.
Changing the native SDK, permissions, config plugins, or dependency graph requires a new binary. It is not an OTA-only change.
Large-screen testing is part of the migration
Apps targeting API 37 cannot use the previous large-screen opt-out for orientation, resizability, or aspect-ratio restrictions on devices with a smallest width of at least 600dp, subject to documented exceptions.
Test phone, tablet, foldable, portrait, landscape, split view, resize, keyboard, and state restoration. Look for:
- fixed-width layouts and clipped controls;
- dialogs or sheets that assume a phone width;
- lost state after configuration changes;
- media or camera previews with incorrect aspect ratios;
- navigation elements that become unreachable with a keyboard or pointer.
Use the system behavior as a product-quality test, not only a compliance task.
Keep Google Play's current requirement separate
As of September 7, 2026, Google Play's published policy requires new mobile apps and updates to target Android 16 / API 36 from August 31, 2026. Existing mobile apps generally need API 35 or higher to remain available to new users on newer Android versions. Check the current category exceptions in the official target API requirements.
That submission requirement is not the same as Android 17 compatibility work. Testing on Android 17 and compiling with SDK 37 can begin before Google Play requires target API 37.
Release gate
Do not change targetSdk in the release branch until you can answer yes to each
question:
- Does the existing app pass the Android 17 all-app compatibility matrix?
- Does the project compile against SDK 37 with a supported framework and build toolchain?
- Are native dependencies and custom modules verified, not merely assumed?
- Have relevant target-37 changes been tested individually and together?
- Do signed release builds pass phone, large-screen, accessibility, background, and upgrade tests?
- Are analytics, crash reporting, staged rollout, and rollback ownership ready?
Then use the Android release build guide to create and verify the signed artifact. A successful debug build is not the release gate.