Multi-Window - AOSP Framework & Internals

Historically, Android was designed for small, 3-inch smartphone screens where only a single application could be visible at any given time. Today, Android powers massive foldable screens, tablets, and even desktop environments (like Samsung DeX).

To support this, the Android framework relies heavily on Multi-Window capabilities.

Multi-Window Modes

The system supports three distinct multi-window modes, all governed internally by the WindowManagerService (WMS):

1. Split-Screen Mode

The screen is physically divided into two halves (or quadrants on larger devices). Two completely independent apps are visible and active simultaneously.

Lifecycle Impact: In older Android versions, only the app currently being touched was in the RESUMED state; the other was PAUSED. In modern Android (10+), both visible apps remain fully in the RESUMED state simultaneously to prevent games from pausing when running side-by-side.

2. Picture-in-Picture (PiP)

Primarily used for video playback or video calling. The Activity is shrunk into a tiny, floating window that hovers above the main UI layer.

The developer must explicitly tell the OS what aspect ratio the tiny window should be.
The UI must adapt instantly, hiding playback controls and chat boxes to maximize the actual video content.

// Example of an Activity entering PiP mode when the user presses Home
@Override
protected void onUserLeaveHint() {
    PictureInPictureParams params = new PictureInPictureParams.Builder()
        .setAspectRatio(new Rational(16, 9))
        .build();
    enterPictureInPictureMode(params);
}

3. Freeform Window Mode

The most complex mode, turning Android into a traditional desktop operating system like Windows or macOS. Activities are rendered inside floating, resizable windows with title bars and close buttons. This is heavily utilized in ChromeOS when running Android apps and on high-end Android tablets.

Handling Window Resizing

When an app is pushed into Split-Screen or resized in Freeform mode, the physical dimensions of the window change dynamically.

To the application, this is treated exactly like a device rotation—it triggers a massive Configuration Change. The ActivityManagerService immediately calls onDestroy() and recreates the Activity to force it to load new layout files that fit the smaller window constraints.

Developers who want to manually handle these resizing events without their app crashing or restarting must declare android:configChanges="screenSize|smallestScreenSize|screenLayout|orientation" in their manifest and manually override the onConfigurationChanged() callback.