Scenario
You own an Android app that mixes legacy Views, Jetpack Compose, and third-party SDKs. For apps targeting Android 16+, windowOptOutEdgeToEdgeEnforcement is removed, so the app must handle window insets correctly. Explain how you would find risks, change layouts, validate device forms, and control release risk.
What the interviewer evaluates
- Separating “runs compatibly on Android 16” from “raising targetSdkVersion to 16.”
- Systematically checking system bars, IME, cutouts, gesture areas, and scroll containers.
- Covering combinations of Views, Compose, libraries, and SDKs.
- Designing compatibility toggles, canaries, and observable rollback.
Clarifying questions
Confirm target and compile SDKs, supported Android versions, View/Compose split, portrait/landscape and foldable coverage, and use of fullscreen camera, maps, or WebView. Ask for screenshot-test, crash, and layout-complaint baselines, and whether third-party SDKs document edge-to-edge support.
30-second answer
I would use two phases. First, expose behavior changes on Android 16 without raising target, then separate inset fixes from the target upgrade. Check root layouts, bars, IME, gesture areas, and scrolling across Views and Compose. Ship a compatibility-only build to a small cohort and watch crashes, occlusion complaints, and key-flow completion. Raise target only after screenshot regression and device-matrix tests pass. Keep target changes separate from large features so a bad layout can be rolled back cleanly.
Step-by-step reasoning
1. Separate compatibility from target upgrade
Android’s migration guidance recommends testing the existing app on Android 16 first; many fixes do not require an immediate target change. Then address behavior changes for apps targeting Android 16, keeping the source of regressions clear.
2. Build an inset checklist
Check whether the root consumes system-bar insets and whether toolbars, bottom navigation, the last list item, inputs, and dialogs are obscured. Establish one inset convention for Compose and avoid duplicate padding in legacy Views. Test camera, maps, and WebView screens with their own safe-area rules.
3. Use compatibility tools to narrow scope
Android 16 compatibility toggles can enable targeted behavior without changing targetSdkVersion. Add them to an automated device matrix covering 4 KB/16 KB pages, orientation, three-button/gesture navigation, foldables, and font scaling. Record change IDs and screenshot diffs.
4. Canary and rollback
Ship a layout-only compatibility build, then raise target in beta and 1% production traffic. Monitor startup crashes, ANRs, key-page tap success, bottom-occlusion complaints, and SDK errors. Keep target migration isolated; roll back the previous build or disable the affected entry when needed.
High-quality sample answer
I would establish a compatibility baseline by installing the current production build on Android 16 emulators and real devices, running every flow, and capturing edge regions. Then I would enable only the edge-to-edge behavior through compatibility toggles to identify whether the root layout, an SDK, or target changes cause the issue. I would create one inset-handling layer, explicitly assign top, bottom, and IME consumption, and prevent View/Compose double padding; camera, map, WebView, and dialogs get separate safe-area tests. Ship the compatibility fixes without changing target. After screenshot, accessibility, orientation, foldable, and IME tests pass, raise target as an isolated change: beta first, then 1% canary. Track crashes, ANRs, core conversion, and occlusion feedback; roll back or disable the new entry on regression. This satisfies the platform change while preserving clear attribution and rollback.
Common mistakes
- Raising targetSdkVersion immediately and losing regression attribution.
- Fixing only the status bar while missing navigation, IME, foldables, list ends, and dialogs.
- Consuming insets in multiple layers and creating double padding.
- Testing only emulators while skipping SDKs, real devices, and font scaling.
- Bundling edge-to-edge migration with a large feature and losing an independent rollback.
Follow-up questions and responses
“Must targetSdkVersion become 16 immediately?”
No. Test the current target on Android 16 and fix compatibility first. Upgrade target separately according to Play requirements and product timing.
“How do you handle third-party SDKs?”
Inventory them and test on real devices with compatibility toggles. Prefer versions that document edge-to-edge support; otherwise add a safe-area wrapper or isolate the affected screen.
“How do you prove older Android versions still work?”
Run the same screenshot and critical-flow matrix on the minimum supported version, Android 15, and Android 16 across orientation, navigation mode, and font scale. Compare tappable regions and occlusion, not just startup success.