Pop-out player: PiP first, and the overlay permission is not free

[StaticHumStudio]

The ask

A pop-out player.

First, what already exists

There IS an in-app mini player: ui/components/MiniPlayer.kt, used from
HomeScreen and MainActivity. So this issue is not that. "Pop-out" means the
player surviving OUTSIDE the app, which Android offers in two very different
shapes with very different costs.

Option A: Picture-in-Picture

A small floating window the system manages, appearing when you leave the app.

• Permission cost: zero. Needs android:supportsPictureInPicture on the
  activity and an enterPictureInPictureMode call. Nothing in the manifest's
  permission block changes.
• Designed for video, and this is an audio app, so the PiP window renders
  whatever Compose surface it is given. Cover art plus transport is fine.
• Real limitation: PiP is tied to the Activity. When the activity finishes, the
  window goes. It is "the player follows you out of the app for a while," not
  "a permanent floating control."

Option B: a floating overlay bubble

A true always-on-top control that works over any app, any time.

• Requires SYSTEM_ALERT_WINDOW. This is the expensive one.
• The manifest currently declares SEVEN permissions and not one of them is
  sensitive: INTERNET, ACCESS_NETWORK_STATE, three FOREGROUND_SERVICE flavors,
  WAKE_LOCK, POST_NOTIFICATIONS. No storage, no microphone, no location. That
  clean list is doing real work for a listing whose headline section is NOTHING
  PHONES HOME.
• "Display over other apps" has a scary out-of-app grant flow, draws Play
  scrutiny, and reads to a privacy-minded installer as the app asking for
  something it should not need. The r/selfhosted and Show HN crowd the venue
  plan targets is precisely the audience that notices.

Recommendation

Start with PiP. It delivers most of the felt benefit for none of the
positioning cost, and it does not touch the permission list that the app's
main differentiator rests on.

Take on SYSTEM_ALERT_WINDOW only if PiP is tried and genuinely does not do
what Jeff wants, and even then decide it as a positioning tradeoff rather than
a technical one.

Question for Jeff before any work starts

Which behavior is actually wanted?

• "Keep the controls visible when I switch to another app for a minute" ...
  that is PiP, and it is cheap.
• "A control that floats over everything all the time, like a chat bubble"
  ... that is the overlay permission, and it costs the clean manifest.

The answer changes which of the two above gets built, so it is worth answering
before anyone opens an editor.

Post-2.1.0.

[StaticHumStudio]

DECIDED by Jeff, 2026-08-24: the overlay bubble, not PiP

His picture of it: the old chat-head bubbles, except it is a little cat you tap
and it expands into controls. Which, for an app called Nine Lives, is the kind
of idea you do not talk someone out of. Read ~/.claude/BRAND.md before drawing
anything, since the bubble becomes a permanent piece of brand surface sitting on
someone's screen next to apps that spent real money on their icons.

Correcting my own framing above

I put SYSTEM_ALERT_WINDOW in the same bucket as RECORD_AUDIO (issue #11).
That was sloppy and the two are not the same category of cost.

SYSTEM_ALERT_WINDOW is a UI-capability appop. It lets the app draw on top
of other apps. It cannot read anything, cannot see other apps' content, cannot
capture input outside its own window. So the NOTHING PHONES HOME paragraph stays
literally true with it declared. RECORD_AUDIO would have made that paragraph a
lie. This one only costs a line on the listing's permission list.

That is a real cost and worth naming honestly, just a much smaller one, and
Jeff's call to pay it is defensible.

The mitigation falls straight out of Jeff's own opt-in rule

SYSTEM_ALERT_WINDOW is not a runtime permission. It is granted through
Settings.ACTION_MANAGE_OVERLAY_PERMISSION, which drops the user on a system
settings page where they flip a toggle. Clunky, and normally that clunkiness is
the problem.

Here it is the feature. The bubble is off by default, so the permission is
requested lazily, only when someone turns the bubble on. Anyone who never
enables it never sees the flow at all. Declare it in the manifest, request it at
enable time, never at launch, and never as part of onboarding.

Dead end, skip it

Android's Bubbles API (Notification.BubbleMetadata, API 30+) was the official
successor to chat heads and looks like exactly the right tool. It is not. Bubbles
are restricted to conversation notifications, which require a long-lived
shortcut and MessagingStyle. A media player cannot post one of those without
abusing the API, and it would read as abuse to anyone reviewing it.

The real chat-head bubble for a player is SYSTEM_ALERT_WINDOW. Do not spend an
afternoon rediscovering this.

Requirements, from the standing opt-in rule

• Ships OFF. Always.
• One obvious toggle to turn it on, and turning it off actually removes it.
• The settings row says what it is, what it does, and what it costs, including
  battery, in plain words rather than a marketing sentence.
• The overlay never blocks input to what is underneath it when collapsed, and
  it is draggable out of the way.
• It has to survive the app's process being killed, same constraint as the
  widget in Home-screen widget: build the thing the listing used to claim #8. Source of truth is the MediaSession in PlaybackService,
  reached through a MediaController, not app-process state.