Implementing Picture-in-Picture Mode for an Android App

Why Android Picture-in-Picture breaks on real devices

Android Picture-in-Picture stops working where the emulator ends and a live device begins: the window doesn't appear when the app is minimized, the sound cuts out after a couple of seconds, and after returning from picture-in-picture mode the interface opens again and loses the player state.

On the test bench everything reproduces reliably, but for the user it doesn't, and this is the most expensive category of defects: reproducibility is near zero, and complaints arrive without logs.

The reason is that picture-in-picture mode is not "flip a flag" but an agreement between the app and the system.

The device decides whether to allow the transition when it has enough resources and the manufacturer's policy doesn't block it; the system may reject entry if the activity isn't ready for a configuration change; and background playback lives separately from the window and requires its own service, otherwise the sound dies along with the interface.

Different manufacturer skins interpret these rules in their own way — hence "PiP won't start" on some models and works on others.

The cost of such a failure is higher than it seems. The user minimizes the app precisely to keep listening or watching — if the window didn't appear or the sound disappeared, the scenario breaks, and the person leaves for a competitor that holds this scenario.

At the same time, the defect itself is invisible in crash reports: the app doesn't crash, it simply behaves differently than expected.

We break down how this is closed: where exactly the transition to picture-in-picture mode is lost, why background playback drops out, and which checks separate a working scenario from "works on my phone."

What a correctly configured Picture-in-Picture mode delivers

Playback continuity when the app is minimized

The key metric is the share of sessions in which video keeps playing after the app goes to the background.

With the standard onPause() the player stops, and the user loses their position; when Picture-in-Picture is configured correctly, the activity transitions to onStop() rather than being destroyed, and playback continues without interruption.

In our experience, this increases viewing session retention by 1.5–2x: the user minimizes the app to reply in a messenger and comes back to the same second.

Window stability and lifecycle management

The PiP window lives in a separate system task, so its behavior is determined by how the app handles onPictureInPictureModeChanged() and onUserLeaveHint().

If you don't switch the layout to a compact one and don't detach heavy views from the lifecycle, the window collapses or shows a black frame.

We split the UI into two states — full screen and a compact set of controls (play/pause, seek), — and the window remains controllable at any size.

What this delivers in numbers

After moving the player to a unified lifecycle with PiP transition handling, the share of failures when minimizing drops from ~15% to single-digit percentages, and the number of app relaunches decreases — the user doesn't need to search for the content again.

We test scenarios across different firmware versions, because window behavior differs between manufacturer shells.

Android Picture-in-Picture — a system mode that we configure for a specific viewing scenario rather than enabling "as is".

Stages of implementing Picture-in-Picture mode in an app

Implementing Picture-in-Picture Android starts not with code, but with an audit: we look at how the app behaves when minimized and when the screen is locked, where player state is lost, and which screens use the same video container.

At this stage we pin down the target scenarios — background playback, switching between sections, answering a call — and determine which of them are broken right now. Then we structure the work in stages so that the changes don't affect the rest of the logic.

1. App audit. We analyze the current lifecycle of screens with video, the points where focus is lost and the player is re-initialized. We pin down which states need to be preserved when switching to PiP and back.
2. Designing window behavior. We define the aspect ratio, the response to dragging and closing, and the set of available actions in minimized mode. We agree on what happens when returning to full screen.
3. Lifecycle setup. We tie the transition to PiP to activity events so that playback isn't interrupted and the position isn't reset. We separately work through the conflict with other windows on top of the app.
4. Implementation and player integration. We connect the mode to the video container and synchronize the state of audio, subtitles, and the selected quality when minimizing and restoring.
5. Minimization testing. We run scenarios on different OS versions and screen sizes: minimizing during buffering, with the screen locked, and during an incoming call. We check that the window doesn't overlap system elements.
6. Testing on real devices. We separately look at behavior on budget models and tablets — that's where discrepancies in rendering and resource consumption show up more often.
7. Configuration handover. We give the client's team the window settings, lifecycle description, and a testing checklist so that further edits don't break the mode.

Each stage closes with a verifiable result: preserved player state, no playback interruptions, predictable window behavior. This order makes it possible to embed the mode without rewriting the existing screen logic. Describe your task — we'll come back with an estimate and a plan for your app.

How does system PiP mode differ from a custom floating window?

Android's system Picture-in-Picture is a mode fully handled by the operating system: the app merely signals that it's ready to collapse into a window, passes a set of actions, and receives callbacks about state changes.

The window lives on top of other tasks; its position, size, drag and close gestures are controlled by the system, while our app keeps running in the background without losing playback context.

A custom floating window is a separate layer on top of the interface that the app itself draws: we hold the coordinates ourselves, handle dragging, monitor the activity lifecycle, and manually return the user to full-screen mode.

The difference in effort shows immediately. System PiP is a few days of work: declare support in the manifest, describe the actions, carefully handle transitions between full-screen and collapsed states so playback position isn't reset.

A custom window is a whole separate subsystem: a layer on top of all screens, its own gestures, conflicts with system bars, manual focus management, and separate collapse logic.

Such a window has to be maintained with every system update, because the behavior of permissions and overlays changes from version to version.

Version compatibility is the second divide. The system mode is available starting from a certain Android branch and behaves predictably on all current devices: the system itself decides how to position the window and how to react to screen rotation.

A custom window formally works everywhere, but it's precisely in that "everywhere" that the pain begins: on some firmware the overlay covers system elements, on others it loses focus, on yet others it gets unloaded when memory runs low. Every deviation is a separate bug report and a separate fix.

Behavior across different system versions also diverges. System PiP inherits power-saving policies and correctly goes to the background without risking being killed.

A custom window lives in the app's process and shares its fate: the moment the system frees up memory, the window disappears along with it. For scenarios like a video call or a player, this is critical: the user expects the picture to stay in place.

The practical conclusion is simple. If the task is video, a call, or navigation, the system mode covers it at lower cost and with fewer failures.

A custom window is justified only where a non-standard interface on top of other apps is needed — for example, custom controls outside system restrictions. Describe your scenario — we'll come back with an estimate and a plan for each of the approaches.

Case study: how picture-in-picture mode stopped failing on minimize

The client — a delivery service — was not complaining about the absence of the mode, but about its instability: when minimizing, the app would either keep showing video on top of other windows, or stop playback entirely.

According to the logs, the share of successful minimizations held at 78%, and recovery after returning to the app took up to 4 seconds — the user had time to lose context and close the session.

What it was before implementation

The analysis revealed three independent sources of failures. The first — the activity was not transitioned into the required lifecycle mode: the system did not receive a correct transition, and the picture-in-picture window either did not appear or overlapped system elements.

The second — the player state was not preserved on minimize, so after returning, playback started from scratch. The third — the handling of gestures and control buttons conflicted with the system window, which caused some actions to be simply ignored.

What was changed

We moved window control to explicit calls of the system interface with correct configuration of proportions and bounds, added preservation of the playback position and buffer before minimizing and restoration from that state on return.

Separately, we synchronized the control handlers with the state of the system window so that actions would not be lost. For monitoring, we added telemetry for each transition — now a failure is visible at a specific step, rather than "somewhere during minimize."

What it became

The class of failures related to loss of player state has been eliminated completely — playback continues from the same second. The remaining isolated cases relate to devices with aggressive power saving and are resolved by configuring exceptions.

We built the transition and recovery logic according to the Android lifecycle model, so the behavior is predictable across different shells. If your picture-in-picture mode works intermittently — describe the task, and we will come back with an estimate and a plan.

Doubts before implementation: compatibility, rollback, and access

Before enabling Picture-in-Picture in a release, three questions usually come up: will the mode break behavior on older devices, can the change be rolled back selectively, and what exactly will the client's team have after handover. Below is how we address each of these at the level of code and process, not promises.

What if PiP conflicts with the current screens? The mode is enabled by the supportsPictureInPicture attribute in the manifest and setAutoEnterEnabled in PictureInPictureParams — that is, it is controlled selectively at the level of an activity, not the entire app.

Screens where PiP is not needed (onboarding, payment, video calls with their own overlay) are simply not marked, and their behavior does not change.

For devices without support for the mode, we keep a hasSystemFeature check and a standard fallback — minimized playback stops, and the app works as before.

How is the change rolled back? PiP is isolated in a separate module and feature flag: disabling the flag restores the previous behavior without rebuilding the screen logic.

A rollback is a revert of a single commit or a change to the flag value on the configuration side; recovery time is minutes, not a release cycle.

• Module source code with a clean commit history and a description of changes
• Feature flag configuration and the procedure for enabling/disabling it
• Activity lifecycle diagram and transitions into and out of PiP
• Compatibility matrix: Android versions and tested devices
• Regression checklist for the affected screens
• Access to the repository, CI, and rights to roll back the release
• Instructions for handing over support to the in-house team

Describe your task — we will come back with a scope estimate, an implementation plan, and a list of what will be required on your side for access.