Bubble up - Android 17's new multitasking feature explained

Only with the release of 12L, Google became serious about making Android a productivity powerhouse across screen sizes and form factors. While we had tablets much earlier, neither the OS nor Mountain View’s flagship apps took advantage. With 12L, we got the persistent taskbar, which made dragging and dropping apps into split-screen mode a natural gesture. Subsequent updates like Android 14 and 15 refined this by adding app pairs and improving how the system handles unoptimized apps in multi-window mode. Android 16 introduced the Desktop Mode that allows for freeform window resizing similar to a traditional PC. And yes, we had seen precursors of this much earlier. Android 7.0 Nougat shipped with a hidden freeform windows developer flag, though it languished for years without proper app support or official ecosystem commitment.

While ChromeOS can be considered a productivity hub, too (many devices are either detachables or convertibles, and some come with a stylus in the box), it's not Android. Although it runs Android apps (in a container called ArcVM), and even though the apps are shown in freely movable and resizable windows, apps run on an outdated Android version (depending on the device, Android 11, 13, or 15); what's more, the integration is plagued by a couple of annoying user-facing bugs that make the split-screen feature practically unusable.

(Chat) Bubbles

With chat bubbles, Google introduced an alternative to notifications, specifically targeting conversations. Introduced with Android 11, these floating windows aimed at making chats more accessible without switching apps by putting them on top of other content. The implementation always felt like an experiment. The Bubbles API is an extension of the ShortcutInfo and Notification APIs. To this day, the feature is tied to the MessagingStyle notification category. Consequently, developers can't just bubble any arbitrary app component, limiting a promising windowing concept to a niche utility for messengers like WhatsApp, Signal, or Telegram. Until Android 17, that is. This version can finally treat (almost) every app as a flexible, floating entity that can live on top of other apps.

Apps are bubbled up from their launcher icons. By long-pressing any app on the home screen, app drawer, or taskbar, you’ll find a new Bubble option in the context menu. Tapping it pops the app into a floating window that persists over the current activity. On larger screens, you can drag an app icon from the taskbar directly into a screen corner to trigger the transition. Once active, the bubbles can be moved freely, stacked with other apps, or minimized into a floating pill on the edge of the display.

Transforming an app into a floating bubble, fortunately, is far from requiring a total rewrite. But it does require moving away from a fixed-screen mindset towards adaptability. On Android 17, the system treats bubbles as a specialized windowing mode; therefore, the technical hurdles are now closely aligned with standard multi-window support. To ensure your app is ready to be bubbled, it must meet these core requirements:

• Support Multi-Window Mode
• Correctly handle configuration changes
• Target API level 37
• Optimize for Adaptive Layouts

A Glimpse Behind the Curtain

The new Bubbles feature required a fundamental reorganization of the system's task management. Android now leverages TaskView (the robust successor to the internal ActivityView) to reparent an entire app task into a specialized floating container. This architecture is a direct sibling to the new Desktop Mode, sharing the same underlying freeform windowing logic. Internally, this convergence is often referred to as Desktop Interactive PiP (iPiP), which leverages the USE_PINNED_WINDOWING_LAYER permission to manage these interactive, persistent layers.

When an app is bubbled, the WindowManagerService creates a virtual display environment, intercepting and translating touch events and window insets in real-time to ensure the app remains responsive in its new dimensions. To keep the transition fluid, the system utilizes Shell Transitions, performing an atomic handoff that moves the task from a full-screen state to a floating layer without a flicker. This process avoids the typical destroy-and-recreate lifecycle by heavily favoring onConfigurationChanged, preserving the user’s backstack and state perfectly.

Ultimately, what looks like a simple UI pop is a complex orchestration of task reparenting and display abstraction that brings Android closer to a true desktop-class windowing engine.

The Secondary Display Pitfall

Because the system creates a virtual display environment to host the bubbled task, your app is technically no longer running on the default display. This introduces an important requirement for context management:

• Avoid Application Context: Always use the Activity context for UI-related tasks, such as inflating layouts or querying WindowManager. The Application context is tied to the primary display and will not reflect the bubble's unique window metrics, density, or insets.
• Dynamic Layout Queries: Don't cache screen dimensions at startup. Since the bubble can be resized or moved between different display states (like folding/unfolding), your app must rely on WindowMetrics and the onConfigurationChanged callback to adapt to its floating container in real-time.
• Resource Loading: Resources loaded via the Activity context will correctly resolve to the bubble's specialized configuration, whereas the Application context may return values intended for the full-screen state

Managing the Task Lifecycle

Beyond the UI, the transition to a bubble affects how Android manages your app's task- and backstack. To ensure a seamless pop, you need to keep a few details in mind. When an app is bubbled, the system re-parents the existing task. If your app relies on complex launch modes like singleInstance or singleTask, ensure that your intent handling doesn't inadvertently clear the backstack when the user toggles between full-screen and bubble mode. Also, because the system utilizes Shell Transitions for an atomic handoff, it preserves the user's state perfectly without a destroy-and-recreate cycle. However, if your app is killed in the background while minimized as a floating pill, it will restart into the bubble container. Finally, the Bubble up mechanism utilizes the ShortcutManager. If your app uses dynamic shortcuts, ensure the LocusId remains consistent so the system can correctly associate the floating window with the specific user context or conversation it originated from.

Wrap-up

From a user's perspective, the Bubble feature is activated from a simple context menu item. But code-wise? Google expanded the LauncherApps and ShortcutManager services to bridge the gap between the launcher and the window manager. There is a new system-level intent handling logic that allows the launcher to query an app's compatibility with the TaskView stack without the app ever needing to fire a notification. Essentially, the system now checks for android:resizeableActivity="true" and android:supportsPictureInPicture="true" (or the new android:allowUntrustedEmbedding) as a signal that the app can handle the floating lifecycle. This turns multitasking from something an app requests into something the user commands.

What about third-party launchers? Historically, whenever Google introduced a deep system-level multitasking change, third-party developers were left in the lurch, and Android 17 is no different. While the new Bubble feature is baked into the platform, the specific Bubble menu item and the drag-and-drop gestures are currently exclusive to the system’s own launcher. Third-party launchers can’t simply opt-in to this context menu (or provide their own) because the underlying intent handling and TaskView orchestration are tied to privileged system permissions that aren't exposed to the public SDK. At this stage, while third-party launchers can of course see your app, they lack the system-level handshake required to command the window manager to reparent your task into a bubble. Until Google decides to open up these specific LauncherApps flags to non-system callers, the Bubble up power remains a walled-garden feature for the default launcher experience.