Why Apps Kept Pausing on Tablets
Early Android assumed only one application could ever hold the user's attention at a time. The system kept the currently touched application in the resumed state and forced everything else into a paused state. This model broke down as screens grew large enough to support foldables and tablets. Users would place a game side-by-side with a chat application, only to watch the game freeze the moment they tapped the keyboard to type a message.
The platform needed a way to keep multiple applications fully active simultaneously. Android introduced the multi-resume mechanism to solve this exact limitation. This feature fundamentally changed the core contract between the operating system and the application lifecycle.
This mechanism requires tight coordination between the Activity Task Manager Service and the Window Manager Service. The Activity Task Manager Service keeps all visible activities fully in the resumed state at the same time. Meanwhile, the Window Manager Service continuously calculates the physical window boundaries and enforces them on the respective application surfaces.
Such a fundamental shift forces developers to rethink application state entirely. You can no longer rely on a pause signal as a definitive indicator that your application is hidden from the user. An app can be paused but fully visible on older versions, or fully resumed while sharing the screen on modern versions.
The following sequence diagram shows what happens when the system transitions an active application into split-screen mode. This visual helps clarify the division of labor between system services during a resize event. Pay attention to how the Activity Task Manager handles the state transition immediately after the Window Manager confirms the new boundaries.
The system sends the new boundaries to the application, triggering a configuration change. The application immediately updates its layout to fit the new dimensions and remains fully active.
Dividing the Physical Display
When two apps share the screen, the system faces a difficult geometry problem. If an application expects a full tablet display but only has half the pixels available, its user interface will clip and break. The system needs a reliable way to force an application to redraw itself within strict new constraints.
Split-screen mode solves this by physically dividing the screen into distinct partitions. The system maintains two independent applications that are visible and active simultaneously. The Window Manager Service creates separate root tasks for each partition and handles the divider user interface between them.
Entering split-screen instantly alters the physical dimensions of the application window. The operating system treats this resize event exactly like a device rotation, triggering a massive configuration change. The system immediately destroys and recreates the Activity by default. This aggressive approach forces the application to load new layout resources that natively fit the smaller window constraints.
From the application perspective, resizing is conceptually identical to rotating the device. You can avoid the destruction cycle by declaring specific configuration changes in your manifest file. You then override the configuration changed callback to adjust the user interface manually without crashing.
Common Mistake: Many developers assume a pause signal means the user cannot see their app. In split-screen mode on older Android versions, an app can be paused but fully visible if it loses focus. Always stop video playback in the stop callback, not the pause callback.
Floating Windows for Continuous Playback
Video playback and video calling applications need to remain visible while the user navigates elsewhere. However, these applications should not consume half the screen like a standard split-screen application. Pinning a small video feed to the corner of the screen provides a much better user experience.
Picture-in-Picture is a specialized multi-window state designed specifically for this use case. The Activity shrinks into a tiny, floating window that hovers on the highest Z-layer above the main user interface. Users can freely drag this window around the screen without disrupting the underlying applications.
The application must explicitly tell the operating system what aspect ratio the floating window should maintain. When the user leaves the application, you trigger this mode by building a parameter object and calling the enter mode function. Expect the system to immediately move your window into a pinned stack and resize it.
@Override
protected void onUserLeaveHint() {
PictureInPictureParams params = new PictureInPictureParams.Builder()
.setAspectRatio(new Rational(16, 9))
.build();
enterPictureInPictureMode(params);
}
The most common mistake engineers make here is forgetting to update the aspect ratio dynamically if the video content changes.
This specialized mode shifts the responsibility of user interface adaptation directly back to the application. It requires precise coordination between the physical window bounds defined by the Window Manager and the internal rendering state managed by your code.
Scaling Mobile Apps to Desktop Environments
Tablets and foldables increasingly need to compete with traditional desktop operating systems. Power users expect to see overlapping, resizable windows with title bars and close buttons. Forcing every application into a strict full-screen or split-screen grid severely limits productivity.
Freeform window mode is the most complex state in the Android windowing system. Activities render inside independent, floating windows instead of snapping to predefined grids. The system provides traditional window decorations like resize handles and title bars to make the mobile application behave like a desktop program.
The Window Manager renders each window surface independently. When a user drags a corner to resize the window, the system handles the touch events directly. It continuously dispatches configuration changes to the application as the physical dimensions shift frame by frame. Applications built for this environment must handle these continuous resizing events natively without restarting to maintain smooth performance.
This mode represents the final evolution of Android window management. It transforms a mobile operating system originally built for small screens into a full-fledged desktop environment. We now understand how a single Activity scales from a floating video to a resizable desktop application. But managing multiple overlapping windows creates a massive new problem for the hardware. When a user taps a crowded screen, how does the system actually know which window should receive the input?