Green in the Embedded Emulator, Broken on the First Real Device — Putting a Parity Gate on AI-Generated Compose Apps

The first thing that broke was a settings screen in one of my wallpaper apps. I asked AI Studio to rearrange the settings into cards, checked it in the embedded emulator, and the spacing and corners looked exactly right. Reassured, I pushed it over USB to a real device — and only there did I notice the bottom card was half-hidden under the navigation bar.

Green in the emulator, red on the device. That combination is the worst one. Now that generation, execution, and device transfer all connect in a single screen, the round trip of checking has become remarkably fast. But what got faster was checking in the emulator, not checking on a device. For my first few weeks I underestimated that gap, and more than once I took the long way around — shipping to internal test and getting the problem reported back by a tester.

This article is about how to put a verification gate on Compose apps generated by AI Studio or Antigravity that gets ahead of the emulator-versus-device gap. The faster generation gets, the more deliberately slow and firm I keep verification. Here is where I draw that line, and the implementation behind it.

Why the emulator passes and the device breaks

Device differences look capricious, but their sources fall into roughly four buckets. Holding that map in advance tells you where to suspect the generated code.

System insets — notch and navigation bar

The first is system insets. Emulators often run with plain gesture navigation and no cutout, so a generated layout that ignores WindowInsets never shows the problem. Real devices have notches, punch holes, three-button nav, and rounded corners, and that is where elements first disappear. My sunken card was exactly this: the generated code never applied navigationBarsPadding().

Font scale — the weakness of fixed dp

The second is fonts and scale. Real users change display size and font scale. A fixed dp height that looks tidy only at the emulator default (scale 1.0) clips its text on a device at fontScale 1.3. AI-generated layouts tend to reach for fixed heights to make the visuals neat, and that is where they are weak.

GPU rendering — how effects drop

The third is GPU rendering differences. The emulator uses the host GPU, so effects like blur, graphicsLayer, and RenderEffect come out smooth. On a specific device GPU and OS, the same effect can drop or turn into visible jank. For an app like a wallpaper browser that leans on blur, this gap is not negligible.

Locale and RTL — breaking on the flip

The fourth is locale and RTL. If you only ever check in your own language in the emulator, you never notice where elements flip and break under RTL languages like Arabic. Even for a Japanese-market app, store review and overseas testers will hit RTL routinely.

With these four in mind, "check the generated screen on a device" becomes "hunt for device differences along four axes." That finds breakage far faster than staring at the screen vaguely.

Turn the axes into checks that don't disappear

Axes that live in your head slip away on a tired night. I decided to fix the four axes as checks that don't disappear — in code and in previews. The aim is to drop the assumption that a human has to remember them on every generation.

First, insets and font scale get surfaced in Compose previews. Placing extreme-condition previews next to the generated composable puts the breakage in front of you before you ever start the emulator.

// Pin "mean previews" next to the generated code to surface device gaps.
// Raise fontScale, squeeze into a short height, apply RTL.
@Preview(
    name = "Large font + short height",
    fontScale = 1.5f,
    heightDp = 360,
    showBackground = true,
)
@Preview(
    name = "RTL locale",
    locale = "ar",
    showBackground = true,
)
@Composable
private fun SettingsCardStressPreview() {
    AppTheme {
        // Inject a simulated system-bar region to make a missing inset visible.
        Box(Modifier.windowInsetsPadding(WindowInsets.systemBars)) {
            SettingsCardList(items = sampleSettingsItems)
        }
    }
}

Just applying fontScale = 1.5f and heightDp = 360 makes text crammed into a fixed dp height visibly clip in the preview. Adding locale = "ar" reveals where asymmetric padding flips and breaks. Right after generation, you can hand it back to the AI — "this preview is broken, make the layout follow fontScale" — and close the loop before opening the emulator.

Missing insets get sealed permanently on the layout side. For a scrolling list, convert the insets into padding so the end of the content never hides under the navigation bar.

// Flow insets into contentPadding so the list tail never sinks behind the system bar.
LazyColumn(
    contentPadding = WindowInsets.systemBars
        .add(WindowInsets(top = 8.dp, bottom = 8.dp))
        .asPaddingValues(),
) {
    items(settingsItems, key = { it.id }) { item ->
        SettingsCard(item)
    }
}

This makes the sunken-card accident structurally impossible. The point is not to "ask for this fix every time" against the generated code, but to hold it in the template so it is built into the starting point of generation. You confine what you delegate to the AI to a foundation that resists breaking. I strongly recommend hardening this footing before you move into production operation. The pitfall is overtrusting that a human will recall the same caveats on every generation.