Docs

Android 17's Resizability Mandate: What to Track

Android 17 removes the orientation-lock opt-out on large screens — track layout and rage-tap signals before ratings drop.

Engagement

Android 17 removes the developer opt-out that Android 16 introduced for orientation and resizability restrictions on large-screen devices. Once an app targets API level 37, android:resizeableActivity="false", minAspectRatio, and maxAspectRatio simply stop working on any display with a smallest width over 600dp — tablets, foldables, and most ChromeOS windows. An app that was built phone-first and relied on a locked portrait layout to avoid dealing with tablet UI will now be force-resized whether or not its layout was ever tested for it.

That’s a rollout most teams will feel before they diagnose it. If a large-screen user suddenly gets an app forced into a landscape or split-screen layout that was never designed for it, the visible symptom is a spike in mistaps, abandoned flows, or one-star reviews mentioning “broken layout on my tablet” — not a clean error anywhere in your crash reporting. Without device form factor and window configuration attached to your engagement events, that regression looks like unexplained noise in session duration or conversion rate rather than a specific, fixable layout problem tied to one Android version and one device class.

Data Points to Track

  • Window size class and smallest-width (dp) attached to every session-start and screen-view event, not just device model
  • Device form factor (phone, foldable, tablet, ChromeOS) segmented out in session, crash, and ANR dashboards rather than blended into an “Android” total
  • Layout-specific rage-tap and dead-tap events on screens likely to reflow when a fixed aspect ratio or orientation lock stops being honoured
  • App version and target SDK level logged alongside every crash and ANR event, so a regression can be isolated to builds that shipped a hard-coded aspect ratio or orientation
  • Session duration and screen-view depth, compared for the same screens before and after a device receives the Android 17 update, split by form factor

Setup Steps

  1. Add window size class and smallest-width to your session-start event now, even before Android 17 adoption is significant, so you have a clean baseline to compare against.
  2. Audit your manifest and code for resizeableActivity="false", fixed aspect ratios, or orientation locks still shipping in production builds — these are the exact configurations Android 17 stops respecting.
  3. Segment existing engagement dashboards by form factor today, since a large-screen regression will otherwise get averaged away by a much larger phone user base.
  4. Instrument rage-tap and layout-abandon events on the screens most likely to reflow — anything built assuming a single fixed orientation or aspect ratio.
  5. Set an alert on crash rate, ANR rate, and session duration scoped specifically to the smallest-width > 600dp segment, so a rollout regression surfaces as a flagged alert rather than a support ticket backlog.

Actionable Insights

The apps most exposed here are the ones that never built a genuinely responsive tablet or foldable layout and instead relied on locking orientation or aspect ratio to sidestep the problem — Android 17 removes that shortcut regardless of readiness. Segmenting engagement and stability metrics by form factor before the update lands gives you a real baseline to detect the regression the moment it starts, and layout-specific rage-tap tracking turns a vague “large-screen users are less engaged” observation into a concrete list of screens that need a genuine adaptive-layout fix rather than another orientation lock that Android will stop honouring next time anyway.

Expert help

Need help tracking this in your app?

Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.

Talk to an expert