# ADR-MOB-004 — Activation on mobile: hold-the-mic-key, with a hold/toggle accessibility switch **Status:** Accepted (2026-08-07) · design only, no code yet **Deciders:** Mohsen Seyedkazemi Ardebili **Context links:** [[adr-mob-003]] (IME), [[adr-011]] (no ambient capture), [[adr-v2-129]] (activation-source seam on desktop), desktop analogue: `src/yazses/hotkeys/hold_detector.py` --- ## Context The desktop's defining interaction is **hold-to-talk**: press and hold a key, speak, release, the words appear. It is not an arbitrary choice — it is what makes "no ambient capture" ([[adr-011]] §9) true by construction: the microphone is open exactly while a human is physically holding something down. A phone has no keyboard to hold, so the interaction must be re-derived rather than copied, and the derivation has to survive three constraints the desktop does not have: 1. **`RECORD_AUDIO` is while-in-use.** An app can capture only while it is foreground, or from a `microphone`-typed foreground service — and Android 14+ blocks *starting* such a service from the background. Any activation gesture that fires while YazSes is not on screen therefore cannot simply open the mic. (Meeting Mode's FGS is [[adr-mob-007]].) 2. **A held finger occupies the screen.** Holding the mic key is natural, but it conflicts with users who cannot sustain a press — the accessibility constituency that YazSes explicitly serves (`adr-v2-012`, `adr-v2-021`). 3. **Always-listening is disqualified by [[adr-011]]**, which forbids ambient capture outright. A wake word is not a small feature on mobile; it is the abandonment of the product's central privacy claim, and on battery it is expensive besides. ## Decision 1. **Primary: press-and-hold the mic key on the YazSes keyboard.** Down → start capture (with the same pre-speech ring-buffer padding the desktop uses, so the first word is not clipped); up → stop, decode, deliver. The desktop's hold-debounce semantics (`hold_detector.py`: a key must be held ≥ N ms before a burst starts, so a stray tap is not a burst) port directly and are covered by contract vectors ([[adr-mob-008]]). 2. **A user-selectable hold/toggle switch, defaulting to hold.** In toggle mode a tap starts and a second tap stops, with a hard safety cap (`max_burst_seconds`, default 120 s) and a persistent, unmissable recording indicator. This is an accessibility requirement, not a convenience: it must be present in M1, not deferred. 3. **Secondary, M2: the headset button.** A wired or Bluetooth headset's `KEYCODE_HEADSETHOOK` / media-button press maps to start/stop *while the YazSes keyboard is the active input method*. This gives a genuinely hands-free path within the permission model, with no always-on mic. 4. **Tertiary, M3, opt-in: the floating bubble** ([[adr-mob-003]] §5) — a draggable mic button over other apps, for users who want to keep their own keyboard. Requires the overlay grant; off by default. 5. **A Quick Settings tile and a launcher shortcut start Meeting Mode**, which is a deliberate, visible, user-initiated foreground action — the only capture path that outlives the on-screen UI, and it shows a permanent notification for its whole life ([[adr-mob-007]]). 6. **No wake word, no ambient capture, no "raise to speak", in any milestone**, unless a future ADR supersedes [[adr-011]] — which is not anticipated. 7. **The activation source is an interface, not a hard-wired listener**, mirroring the desktop's activation-source seam from [[adr-v2-129]]: `:core:session` exposes `ActivationSource` with `onHoldStart`/`onHoldEnd`, and the IME key, the media button, the bubble and (later) a watch or a hardware switch are all just implementations. This is what makes external-switch accessibility hardware a contributor-sized addition rather than a refactor. ## Consequences - The mic is open only while a finger is down, a toggle session is explicitly running, or Meeting Mode is explicitly running — so [[adr-011]]'s no-ambient-capture claim holds on Android with the same strength as on desktop, and the app can say so without hedging. - Hold-to-talk on a touchscreen has a failure mode the desktop lacks: the finger slides off the key. The key must keep the burst alive while the pointer is anywhere in the keyboard view and end it on `ACTION_UP`/`ACTION_CANCEL`, and the visual state must make an ended burst obvious. This is a named acceptance test, not a detail. - Toggle mode reintroduces the risk the hold model eliminates (a session left running). Mitigated by the hard cap, the ongoing indicator, and auto-stop on prolonged silence (the desktop's semantic-autostop idea, `adr-v2-029`, is the natural M3 upgrade). - The headset-button path only works while YazSes is the active IME, which will surprise someone; the setting's description must say it. ## Rejected - **Wake word / always-listening** — contradicts [[adr-011]] §9, drains battery, and would make the app's central claim false. The desktop's own wake-word ADR (`adr-v2-033`) is likewise unshipped for the same reason. - **Volume-key or power-key hold as a global hotkey.** Requires an `AccessibilityService` to intercept keys globally ([[adr-mob-003]] rejects that grant), hijacks a control users need for media and for the camera, and is fragile across OEM skins. - **Shake-to-dictate / proximity-sensor gestures.** High false-positive rate; opening a microphone on an accidental gesture is exactly the failure this project must never have. - **A persistent notification with a mic action as the primary path.** Android's notification-action latency and the extra tap make it worse than the keyboard key for the common case; it survives as part of Meeting Mode only.