Android 17 formalises app bubbles into a proper windowing mode, the same tier as split screen, rather than the messaging-only chat-heads feature it used to be. Any app can now be long-pressed into a floating bubble on a phone, foldable, or tablet, and the system reparents the whole task into a specialised floating container via TaskView. For most analytics implementations, that’s a problem nobody has tested for yet, because a bubbled instance of your app doesn’t behave like a normal foreground session — it can be repeatedly minimised, kept alive at the edge of the screen while the user works in something else, and resumed dozens of times in a way a full-screen session never is.
The risk is quiet but compounding. Session-length and engagement metrics that assume “foreground equals attention” will systematically misread bubbled usage: a bubble parked on screen while the user ignores it for ten minutes looks identical, in most SDKs, to ten minutes of genuine engagement. Conversely, a bubble that gets opened, glanced at for two seconds, and collapsed twenty times in a row can look like session churn or a UX failure when it’s actually a completely normal, lightweight interaction pattern that this windowing mode is designed to encourage. Without a way to tell a bubbled session from a full-screen one, both failure modes land in the same aggregate numbers and neither is diagnosable.
Data Points to Track
- Window mode at session start and on every transition — a flag distinguishing full-screen, split-screen, and bubble windowing modes, captured whenever
onResume/onPause-equivalent lifecycle callbacks fire - Bubble open/collapse frequency per session — how many times a bubble is expanded and re-collapsed, since this is the primary interaction unit in bubble mode, not session duration
- Foreground-visible time versus bubble-docked time — separating time the bubble’s content was actually expanded and visible from time it sat collapsed at the edge of the screen
- Bubble-to-full-screen promotion rate — how often users expand a bubbled instance into a full-screen window, a strong signal of genuine intent versus passive glancing
- Task re-parenting events — TaskView transitions that move a task in or out of bubble mode mid-session, which can otherwise appear as spurious session restarts
Setup Steps
- Instrument the windowing-mode API available in Android 17’s adaptive-apps guidance to read the current mode at every activity lifecycle transition, not just at cold start.
- Tag every analytics event with the active window mode so downstream funnels and engagement dashboards can filter bubbled sessions in or out rather than blending them with full-screen data by default.
- Add a distinct expand/collapse event pair around the bubble’s TaskView container, separate from your existing screen-view events, so glance-and-collapse interactions get counted as their own pattern.
- Exclude collapsed-bubble dwell time from session-length calculations by default, and expose it as a separate “docked time” metric instead.
- Backfill a test matrix covering full-screen, split-screen, and bubble mode for your core funnels before Android 17 reaches meaningful adoption, so you have a pre-migration baseline to compare against.
Actionable Insights
Once window mode is tagged, the first useful comparison is bubble-to-full-screen promotion rate against your existing engagement benchmarks — a feature that gets promoted to full-screen often is one users genuinely want more room for, and a strong candidate for bubble-specific onboarding or a persistent-bubble default. A high collapse frequency with low docked time is healthy, expected bubble usage and shouldn’t be flagged as churn; a high collapse frequency paired with long docked time suggests the bubble is being left open passively and your session-length metric needs the docked-time exclusion applied retroactively. Above all, don’t let bubbled sessions blend into your headline engagement numbers unlabelled — even a small share of bubble adoption can quietly drag average session duration in either direction and make an unrelated release look like it moved a metric it didn’t touch.
Related Resources
Need help tracking this in your app?
Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.
Talk to an expert