Situation
A brief blank or black window flashed on screen for about a second when users launched a first-party application on Pixel devices, before the main UI became visible.
Investigation
Established reproducibility first, since that shapes whether you're chasing a hardware quirk or a platform-level bug. It reproduced 100% of the time on the reported configuration, and I verified it on prototype devices running early developer builds, then tracked it across successive OS releases to rule out a single-build issue.
Form factor testing was the most useful signal: standard phones did not show it, but foldables and tablets reproduced it consistently, pointing to a window management or task boundary problem specific to multi-window environments. I combined screen recordings of the launch transition with ActivityManager and WindowManager transaction logs, mapping the lifecycle of the three activities involved and comparing timestamps across them.
Root cause
A multi-stage trampoline in the app's launch flow. Tapping the icon started a lightweight, translucent entry activity, which immediately routed the intent to an intermediate gateway activity owned by a separate host package. WindowManager drew a window for that gateway activity and prepared its transition before the final main activity even existed, and since the gateway had no content of its own, it briefly rendered as an empty container before launching the real main activity and finishing itself.
Engineering collaboration
The fix swapped the standard drawing gateway activity for a non-drawing version. Enabling a specific property on the intermediate activity told WindowManager not to render a physical container for it at all, letting the preceding screen stay visible until the main interface was fully rendered. I updated the entry point activity to route directly to this non-drawing handler, removing the transient black screen.
Validation
Sideloaded the fix onto test devices and confirmed through system logs that the gateway activity's window was bypassed during the transition draw, then ran a broader bug bash to confirm other deep-linking workflows still worked and the host app and launcher could be updated independently.
Communication
Shipped through a phased rollout: early access, dogfood, then a gradual public release at 1%, 20%, and 100%, so telemetry could confirm stability before it became permanent.
Lesson learned
Reproducibility and form-factor segmentation are often the fastest way to tell a device-specific rendering bug apart from a genuine platform issue, and a fix that only hides a symptom is worth far less than one that removes the extra window from existing at all.