Five Foldable Lessons for San Diego Android App Teams

A phone-only Android app rarely crashes on a foldable. It just looks wrong: one tall column in the middle of a wide screen, or a half-written note that disappears after a rotation. That outcome is about to become common, because apps aimed at Android 17 can no longer pin their orientation or block resizing on big displays, and Play makes that target mandatory from August 2027. Here are five lessons for San Diego teams planning the work.

Lesson one: state comes before layout

It is tempting to start with a nicer two-pane design, but state deserves the first sprint. A caregiver or a front-desk worker forgives an awkward layout far sooner than losing typed text. Keep screen data in a ViewModel, keep small UI details with rememberSaveable, and use SavedStateHandle so the screen recovers after the process is killed. The test is blunt: unfold the device halfway through typing and check that the text is still there.

Lesson two: think in windows, not devices

Device checks feel natural and age badly. A foldable is a phone one minute and a small tablet the next, and split screen turns a tablet into a narrow window. Window size classes avoid that trap by describing the space the app actually has. One layout for Compact, one for Medium and one for Expanded lets the same code serve every device shape.

Lesson three: navigation should move with the space

A bottom bar is fine in portrait and awkward on a wide screen, where it sits far from the thumbs. NavigationSuiteScaffold handles the switch, showing a bar on compact windows and a rail elsewhere. A drawer only appears when a team adds one on purpose, a detail that older tutorials often get wrong.

Lesson four: the hinge is part of the layout

A separating fold can slice a video or a button in half. WindowManager reports where the fold sits and whether the device is half opened. A horizontal half fold is tabletop posture, good for a video above its controls, while a vertical one suits a two-page book layout. Not every app needs these extras, but knowing where the hinge is keeps key content off it.

Lesson five: make the audit repeatable

Pick one important flow and check each screen in it: rotate twice and fold once, resize through the size classes, look at short sideways windows, try a keyboard-only pass, and check the camera preview. Then put the same window sizes into automated tests so a regression fails the build. Android Studio ships tablet and foldable emulators, so running this every sprint costs very little.

A sensible starting point

When the backlog feels large, the screens where people type the most are the right place to begin. Fix state there, then add a list-detail layout for wide windows, and leave posture features for later. Each stage is small enough to ship on its own.

The team at Bitcot wrote up the whole sequence, with the API 37 changes and a three-stage rollout, in this detailed walkthrough. For any San Diego app that still assumes a phone held upright, it is a useful place to start.