The platform change
Google released Android 17 to supported Pixel devices and AOSP with an adaptive-first standard. For apps targeting API level 37 on devices wider than 600dp, the system ignores several legacy restrictions, including fixed screen orientation, resizeableActivity=false and aspect-ratio limits. Google states that games remain exempt from this particular behavior.
The practical consequence is simple: a manifest flag can no longer be the product’s large-screen strategy. Tablet, foldable and desktop-window behavior must be tested as normal application states.
Where existing applications tend to break
A build may compile and still fail in use. Fixed-width forms can leave controls stranded. Dialogs designed for one height can overlap the keyboard. A screen that stores data inside an activity can lose work when window configuration changes. A list that expands without a maximum reading width can become harder, not easier, to scan.
Android 17 also changes some activity recreation behavior, which means teams should verify both the paths that now receive configuration callbacks and the paths that genuinely require resource recreation.
- Phone portrait: the current baseline and one-handed interactions.
- Phone landscape or desktop mode: minimum-height and keyboard behavior.
- Tablet at medium width: navigation rail and content-width limits.
- Large tablet or unfolded device: list-detail and supporting-pane opportunities.
- Free-form window resize: state continuity at several intermediate widths.
A migration order that reduces risk
Start with shared layout foundations: window-size information, content-width rules, adaptive navigation and a single owner for durable screen state. Then migrate the journeys that create revenue, retain data or contain complex input. Decorative surfaces can follow.
Do not convert every XML layout simply to claim a Compose migration. Google is moving Android guidance and new UI work toward Compose, but the useful unit of migration is a complete journey with tests. A mixed application is safer than a rushed rewrite when boundaries are explicit.
Release gate for target API 37
Before raising the target SDK, run the production application—not only a sample—through a window-size matrix. Include deep links, account recovery, media, purchases, background return and accessibility. Record state loss separately from layout defects because they have different owners and fixes.
The team should leave the review with an adaptive backlog, a list of release blockers and evidence that the highest-value journeys remain complete at every supported size.
| Window or state | Test scenario | Release condition | Evidence to retain |
|---|---|---|---|
| Compact phone | Run the journey in portrait and landscape with the keyboard, dialogs and deep links. | Essential controls fit, focus stays visible and returning from a deep link preserves the intended destination. | Screenshots and the device, Android version and build used. |
| Around the 600dp boundary | Resize repeatedly across the boundary while editing data or viewing selected content. | Navigation adapts without duplicate destinations, lost selection or a restarted task. | A screen recording and any configuration callbacks observed. |
| Expanded tablet or unfolded device | Open a list-detail flow, long-form content and the most complex input screen. | Content has a readable maximum width and added panes support the task instead of stretching it. | Screenshots of the highest-value journeys at the tested width. |
| Free-form desktop window | Drag continuously through intermediate widths, then minimize and restore the app. | No overlap, blank state or hidden action appears, and durable screen state returns correctly. | Resize recording plus the smallest failing width if a defect remains. |
| Accessibility variation | Repeat each width with larger text and TalkBack on a critical journey. | Reading order, labels and actions remain understandable without horizontal scrolling for body text. | Accessibility test notes linked to the same release candidate. |
Primary sources
Facts are grounded in the official announcements below. AppMe analysis and recommendations should be validated against the product being changed.