Is 画面共有 part of v1, and does Android MediaProjection block it? #45

New issue

Closed

opened 2026-07-30 13:15:04 +00:00 by aiko · 1 comment

aiko commented

2026-07-30 13:15:04 +00:00

Owner

Question

denpa#31 shipped screen sharing on desktop through getDisplayMedia.
denpa#36 moves acquisition into Rust because ADR-0002 requires it and because
Android has no usable getDisplayMedia — capture there is MediaProjection,
which needs a system consent dialog and a foreground service, alongside the one
denpa#23's overlay already runs.

v1's destination is the conversation works. Screen sharing is not obviously
part of a conversation, but #31 is already built and its renderer path calls a
browser media API that ADR-0002 forbids — so leaving it alone is not free either.

Decide:

Is 画面共有 inside v1, or does it wait for v2?
If it waits: does #31's getDisplayMedia call stay in the tree as a known
ADR-0002 violation, get disabled, or get removed?
If it is in: does the Android MediaProjection half have to land for v1, or is
desktop-only capture acceptable given #36 explicitly rejects
"a capture path that only exists on desktop"?

denpa#36, denpa#31, denpa#23
denpa/docs/adr/0002-hardware-goes-through-rust.md

Map: aiko/denpa#41

## Question `denpa#31` shipped screen sharing on desktop through `getDisplayMedia`. `denpa#36` moves acquisition into Rust because ADR-0002 requires it and because Android has no usable `getDisplayMedia` — capture there is `MediaProjection`, which needs a system consent dialog and a foreground service, alongside the one `denpa#23`'s overlay already runs. v1's destination is *the conversation works*. Screen sharing is not obviously part of a conversation, but `#31` is already built and its renderer path calls a browser media API that ADR-0002 forbids — so leaving it alone is not free either. Decide: - Is 画面共有 inside v1, or does it wait for v2? - If it waits: does `#31`'s `getDisplayMedia` call stay in the tree as a known ADR-0002 violation, get disabled, or get removed? - If it is in: does the Android `MediaProjection` half have to land for v1, or is desktop-only capture acceptable given `#36` explicitly rejects "a capture path that only exists on desktop"? ## Related - `denpa#36`, `denpa#31`, `denpa#23` - `denpa/docs/adr/0002-hardware-goes-through-rust.md` --- Map: `aiko/denpa#41`

aiko added the

wayfinder:ticket

wayfinder:grilling

labels

2026-07-30 13:15:04 +00:00

aiko referenced this issue

2026-07-30 13:58:58 +00:00

Is the Android overlay pal part of v1? #47

aiko referenced this issue

2026-07-30 17:02:25 +00:00

Move screen capture into Rust, out of the webview #36

aiko commented

2026-07-30 17:04:52 +00:00

Author

Owner

Resolution

画面共有 is in v1. Moving it into Rust is not.

The question this ticket was filed with turned out to be the wrong one. It asked whether screen sharing belongs in v1 at all; the answer arrived by observation on 2026-07-30 — it already works on Windows, through #31's shipped path, and it is wanted.

So the real question was whether #36's migration has to happen in v1. It does not.

Why deferring is defensible

Desktop works today. screen-capture-context.tsx:32 calls getDisplayMedia and captures.
#35 proved the pattern. The Rust boundary — a command surface, a worker, events — is now built and running for the microphone. Migrating capture is a well-understood repeat rather than an unknown, which is exactly what makes it safe to schedule later.
Android is not incomplete because of screen sharing. It has no voice either, and the mic path is what makes a tablet usable at all. Screen sharing is not the thing standing between the tablet and a conversation.

What deferring costs, stated rather than glossed

A known ADR-0002 violation stays in the tree, on the surface used daily. The ADR says the renderer holds no device handles; today it holds a display-media stream. That is a real inconsistency between what is written down and what runs.
画面共有 does not exist on the tablet or the phone. Android has no usable getDisplayMedia, so the grant surface #31 built is desktop-only until #36 lands.
It works because of the thing that failed on the microphone. The webview media layer is precisely what produced NotAllowedError on Android with RECORD_AUDIO already granted. Screen capture has not hit that yet on Windows; it has not been proven immune to it either.

Sequencing

#36 is labelled v2 and travels with the Android capture work — the MediaProjection consent dialog and its foreground service, which #47 established cannot lean on the overlay's service because the overlay is out of v1.

## Resolution **画面共有 is in v1. Moving it into Rust is not.** The question this ticket was filed with turned out to be the wrong one. It asked whether screen sharing belongs in v1 at all; the answer arrived by observation on 2026-07-30 — it already works on Windows, through `#31`'s shipped path, and it is wanted. So the real question was whether `#36`'s migration has to happen in v1. It does not. ### Why deferring is defensible - **Desktop works today.** `screen-capture-context.tsx:32` calls `getDisplayMedia` and captures. - **`#35` proved the pattern.** The Rust boundary — a command surface, a worker, events — is now built and running for the microphone. Migrating capture is a well-understood repeat rather than an unknown, which is exactly what makes it safe to schedule later. - **Android is not incomplete *because* of screen sharing.** It has no voice either, and the mic path is what makes a tablet usable at all. Screen sharing is not the thing standing between the tablet and a conversation. ### What deferring costs, stated rather than glossed - **A known ADR-0002 violation stays in the tree**, on the surface used daily. The ADR says the renderer holds no device handles; today it holds a display-media stream. That is a real inconsistency between what is written down and what runs. - **画面共有 does not exist on the tablet or the phone.** Android has no usable `getDisplayMedia`, so the grant surface `#31` built is desktop-only until `#36` lands. - **It works because of the thing that failed on the microphone.** The webview media layer is precisely what produced `NotAllowedError` on Android with `RECORD_AUDIO` already granted. Screen capture has not hit that yet on Windows; it has not been proven immune to it either. ### Sequencing `#36` is labelled `v2` and travels with the Android capture work — the `MediaProjection` consent dialog and its foreground service, which [#47](https://git.aiko.works/aiko/denpa/issues/47) established cannot lean on the overlay's service because the overlay is out of v1.

aiko closed this issue

2026-07-30 17:04:52 +00:00

aiko referenced this issue

2026-07-30 17:04:53 +00:00

Move screen capture into Rust, out of the webview #36

aiko referenced this issue

2026-07-30 17:04:53 +00:00

Wayfinder map — the conversation works (v1) #41

aiko referenced this issue

2026-08-01 13:01:03 +00:00

What does the microphone need from Android 17 to keep capturing? #81