Android OS 17: What's New, Release History & Support Lifecycle

What Is New in Android 17

How does Android 17 change multitasking and productivity?

Android 17's most visible change for daily use is Bubbles, a floating-window mode that turns any app into a small overlay you can keep open while doing something else. Long-pressing an app icon converts it into a bubble that floats on top of other apps; on large screens, bubbles dock into a dedicated bubble bar so users can switch, resize, or maximize them with one tap.

Screen Reactions pairs the front camera and screen recording into one flow, with a redesigned toolbar that captures both at once without switching apps or needing a green screen. Foldable gaming mode adds an optimized 50/50 layout, with the game view on top and a dynamic gamepad below, and supports native controller remapping for external controllers.

A handful of smaller changes round out the release: an option to hide app names on the home screen, a dedicated volume control for the assistant, expanded dark theme controls, and Parental Controls now available on all Android devices rather than a subset.

In practice, none of this requires code changes for most apps, since bubbles and foldable gaming mode are system-level window behaviors. It is still worth re-testing how your activity handles being resized into a small bubble window or a 50/50 split, especially if your layout code assumes a minimum width.

What new privacy and permission requirements land in Android 17?

Android 17 closes off several data access paths apps have relied on without explicit consent, and the one most teams will hit first is the new ACCESS_LOCAL_NETWORK runtime permission. It falls under the existing NEARBY_DEVICES group, so users who already granted other nearby permissions are not prompted again, but apps targeting API level 37 must either adopt a system-mediated device picker or explicitly request the permission to keep discovering devices on the LAN.

• Encrypted Client Hello (ECH) encrypts the SNI in the TLS handshake for apps targeting API level 37, configurable per domain through a new domainEncryption element; it only activates if both the app's networking library and the remote server support it.
• A new contact picker lets apps request specific contacts instead of broad READ_CONTACTS access.
• Contacts Provider 2 removes ACCOUNT_NAME, ACCOUNT_TYPE, and ACCOUNT_TYPE_AND_DATA_SET from the data view for apps targeting API level 37; pull those columns from RawContacts by joining on RAW_CONTACT_ID instead.
• Contacts Provider 2 also enforces strict SQL grammar and column checks when an app queries the data table without READ_CONTACTS, rejecting incompatible query patterns.
• SMS OTP protection now extends to WebOTP-format messages for all apps, and to standard SMS messages for apps targeting API level 37; affected messages are withheld from SMS_RECEIVED_ACTION and provider queries for three hours unless the app is exempt.
• Cross-profile loopback traffic is blocked by default for every app on the device, regardless of target SDK.

This matters if your app discovers smart home or casting devices over the local network, mirrors contacts for backup or sync, or extracts OTPs by parsing raw SMS messages, since each of those paths now needs explicit migration to the supported APIs.

What breaking changes should you test before targeting API level 37?

Several changes in Android 17 can break working code silently once targetSdkVersion moves to 37, so they deserve a dedicated regression pass before launch. The large-screen orientation and resizability opt-out introduced in API level 36 is removed entirely on devices with a smallest width of 600dp or more, meaning locked orientation and fixed aspect ratios are ignored and apps must rely on adaptive layout APIs like window size classes instead of hardcoded screen dimensions.

static final fields can no longer be modified at runtime: reflection throws an IllegalAccessException, and modifying one through JNI's SetStaticField family crashes the app outright. Watch out for this if your test suite swaps constants via reflection to fake dependencies between tests, since that pattern needs to move to proper dependency injection before targeting API level 37.

The new lock-free MessageQueue implementation improves performance and reduces missed frames, but it can break code that reflects into MessageQueue's private fields or methods. RFCOMM BluetoothSocket reads also change behavior: the InputStream.read() method now returns -1 when the connection drops instead of relying on an IOException, so a read loop that only catches the exception to detect disconnects will need an explicit check.

int bytesRead;
while ((bytesRead = inputStream.read(buffer)) != -1) {
    handleData(buffer, bytesRead);
}
// bytesRead == -1 now means the remote device disconnected or the socket closed

Two more changes apply regardless of target SDK and are easy to miss in QA: if your activity does not handle a configuration change such as rotation, the IME no longer reappears automatically afterward (set android:windowSoftInputMode to stateAlwaysVisible or request it explicitly in onCreate() or onConfigurationChanged()), and background audio playback, focus requests, and volume changes now require the app to be running a foreground service with while-in-use capabilities, or to hold the exact alarm permission for alarm streams.

How does Android 17 manage memory and improve performance?

Android 17 enforces app memory limits for every app on the device, regardless of targetSdkVersion, which is the headline performance change in this release. Limits are based on the device's total RAM and set conservatively in this release to catch extreme memory leaks and outliers before they cause UI stuttering, higher battery drain, or app kills; Google expects minimal impact on the vast majority of sessions, but recommends teams establish a memory baseline now rather than after users start reporting kills.

If your app was affected, you can confirm it through ApplicationExitInfo after the next launch.

List<ApplicationExitInfo> infos =
        activityManager.getHistoricalProcessExitReasons(null, 0, 1);
ApplicationExitInfo info = infos.get(0);
if (info.getReason() == ApplicationExitInfo.REASON_OTHER
        && info.getDescription().contains("MemoryLimiter:AnonSwap")) {
    // the previous session was likely killed by the new memory limiter
}

ART also gets a tuning pass, running more frequent and lighter young-generation collections alongside full-heap collections to cut overall garbage collection CPU cost; these improvements reach devices back to API level 31 through Google Play system updates, not just devices on Android 17. For day to day debugging, LeakCanary is now built directly into the Android Studio Profiler as a dedicated task, and ProfilingManager gains a new anomaly trigger that captures a heap dump automatically when the memory limiter kicks in.

On the gaming side, more efficient memory cleanup reduces frame drops and stutters during high-definition gameplay. Keystore also gets a usage ceiling in this release: apps targeting API level 37 are capped at 50,000 keys, versus 200,000 for everyone else, and exceeding the limit throws a KeyStoreException.

Most teams will not notice a day to day difference, but if your app has a known memory leak you have been putting off, this release is where it starts costing you in the form of background kills rather than just slow growth.

What security and anti-theft features land in Android 17?

Android 17's security story splits into anti-theft tools for users and secure-by-default platform changes for developers. On the user side, an enhanced "Mark as lost" option in Find Hub locks a missing phone behind biometrics, so even a thief with the correct passcode cannot access the device or turn off tracking; Live Threat Detection blocks more suspicious apps and scams, Advanced Protection mode is hardened against sophisticated attacks, and the system now allows fewer PIN guesses with longer wait times between failed attempts.

Bluetooth gets autonomous re-pairing, so the system resolves a lost bond in the background instead of forcing the user into Settings to unpair and re-pair a peripheral. Developers should note the new EXTRA_PAIRING_CONTEXT extra on pairing requests, which distinguishes a standard request from an autonomous re-pairing attempt, and that ACTION_KEY_MISSING now only fires if the autonomous attempt fails.

For developers, two platform defaults shift in this release. Certificate transparency is enabled by default for apps targeting API level 37, where it previously required an explicit opt-in on Android 16, and Safer Dynamic Code Loading now extends to native libraries, so any file loaded with System.load() must be marked read-only or the system throws an UnsatisfiedLinkError.

This matters if your app dynamically loads native libraries for plugins, mods, or a game engine, since an unmarked file that worked fine on Android 16 will now fail to load instead of silently succeeding.