Development

Three Changes in Android 16 That Might Break Your App

Steamclock • Jul 16th, 2025

Google rolled out a flurry of AI demos, developer announcements, and… AI demos at Google I/O 2025. But looking past Google’s LLMapalooza you’ll find a grab bag of under the radar deprecations in Android 16 (released June 10th) that are bound to cause headaches as users start upgrading.

Three changes in particular deserve attention: changes to edge-to-edge layouts, portrait locking, and back navigation. Whether you’re maintaining a production app or planning a new release, it’s worth staying on top of details like these to keep problems from sneaking up on you over the coming months. Let’s dive in.

1. No More Edge-to-Edge Opt-Out

Starting in Android 16, Google has deprecated the ability to automatically make sure app content doesn’t overlap with an app’s nav or status bar. Android encourages developers to embrace edge-to-edge layouts—designs that extend behind the system status and navigation bars at the top and bottom of the screen—for a more immersive feel. Before Android 16, if you didn’t want to update your app manually to handle edge-to-edge designs, you could simply opt out and have the OS take care of the additional padding for you.

That option is going away in Android 16. Apps now must respect system insets, meaning you’ll need to manually account for padding around navigation bars, gesture areas, and status bars. Otherwise, your content risks being overlapped or hidden altogether. For apps with older layouts or don’t-worry-we’ll-fix-this-later padding hacks, this change could lead to unexpected UI bugs.

2. Portrait Locking is Being Deprecated

The ability to lock an app in portrait mode via the manifest is being phased out. Essentially, Google is forcing devs to support landscape orientations for tablets and foldables now (in Android 16) and phones next year (in Android 17). While there are still a couple of workarounds to force portrait mode programmatically—manually handling an onConfigurationChanged() callback, or requesting Portrait orientation in the Activity—both may have unintended side effects depending on the use case.

For teams that relied on portrait locking as a shortcut to avoid layout complexity, this is a not-so-subtle nudge from Google that adaptable designs aren’t optional anymore.

3. Back Navigation is Changing

Predictive Back navigation is the ability to let users preview where a back gesture will take them before they fully commit. It was introduced back in Android 13, and it required effort to make it look and work well. Android 16 is doubling down on Predictive Back navigation by turning it on by default while also deprecating KEYCODE_BACK and removing onBackPressed() altogether, which until 16 was the typical approach for handling backpresses.

The predictive cross-task animation (source: Android developer documentation)

This means apps now need to use the newer OnBackInvokedCallback system or risk broken navigation flows. If your app has custom back handling for web views, forms, or nested navigation, this is a breaking change that you need to test for deliberately.

Next Steps

These changes (and others introduced in Android 16) point to a theme: Google is pushing Android developers toward more adaptable, future-proof designs that support new kinds of interactions and device types.

While that future might sound exciting, the reality is that as Android users upgrade their devices (and as more devices roll out with 16 pre-installed), the work needed to handle these deprecations and keep apps feeling polished and durable can’t be ignored.

New versions of Android typically don’t see super-quick uptake, but planning for these updates now sure beats scrambling to fix things after it’s too late. If you’re navigating the transition to Android 16 or just want a partner that obsesses over this kind of detail, let’s talk!

Steamclock • Android Team

Handling deprecations proactively since 2010.