Wispr stopped working on my Pixel 7 Pro again. I tried the recovery app I built around it. That did not fix it. I rebooted. That did not immediately fix it either. The phone then crashed, appeared to reinitialize parts of the system, and Wispr eventually worked again.

I am tired of this. I paid for Letterly as an alternative even though I still prefer Wispr’s results. Letterly does not work nearly as well for the way I dictate. This is not a claim that Letterly wins a controlled accuracy or reliability benchmark; it is where repeated interruptions have pushed me as a customer.

I want Wispr to work. Liking the output does not make losing my input method acceptable.

What we actually found on the phone

The investigation connected to the actual Pixel and examined retained Android crash records, process exits, permissions, services, recovery status, and alarm scheduling. Wispr was version 2.3.1, build 156, on Android 16. All times below are Mountain Daylight Time on September 5.

During the later working-state inspection, Wispr’s accessibility service was enabled and bound. Its effective overlay permission was allowed, its microphone permission was granted, and it was already exempt from device-idle optimization. Roughly 45 GB of storage was free. Simply saying “enable the permissions” does not explain this incident.

We did not prove that Wispr caused the Android crash. The system exception explicitly describes the lost network stack as a downstream effect. The initiating cause was not established by the surviving records. Nor did we capture the original, pre-reboot Wispr failure state this time. The invisible, non-touchable overlay documented below is an earlier verified incident, not a diagnosis we can automatically apply to every later failure.

My recovery app needs fixing too

The workaround is mine, and its shortcomings belong in this update:

• It could not reach its ADB control connection, so the actual repair never began on the recorded failed attempt.
• Its concurrency lock is acquired after ADB startup and discovery. Those operations therefore sit outside that protection. A socket collision is confirmed; the exact competing caller is not.
• The app reported termux_check_requested, while the worker’s separate result was control_unavailable. Requested is not checked, and checked is not repaired.
• Android delayed the nominal three-minute alarm by about 51 minutes under app standby during inspection. My original wording below overstated that schedule as an execution guarantee.

The next repair is specific: protect connection startup, rediscover the paired connection after reboot, report results independently of that connection, and verify actual scheduling under standby. Then test a successful dictation after recovery. No permanent fix was installed during this investigation, and there is no evidence that my helper was what eventually restored Wispr that night.

What I want from Wispr

Please make the Android input path recover reliably, expose a useful failure state, and provide diagnostics that distinguish overlay failure, accessibility disconnection, and transcription or insertion failure. Users should not need a second application to babysit the first.

Wispr’s bubble troubleshooting guide describes reconnection and repair indicators. Its release notes list Android 2.3.2, but the listed change is sign-in handoff—not a demonstrated fix for this incident.

I would rather keep using the dictation I like than build another app or keep paying for alternatives. But reliability has to be part of the product. The detailed findings above are why I am asking for a real fix, while being clear about the problems in my own workaround and the causes we have not established.

The original September 2 field note follows. Raw device logs and private identifiers are not published.

Original September 2 field note

Wispr Flow disappeared from my Pixel 7 Pro on September 2.

The obvious explanation was wrong.

The app was still installed and enabled. Its overlay permission was allowed. Its Accessibility Service was bound. The foreground service and process were alive. I had a normal text editor focused, the keyboard was open, and the microphone was not recording.

The Flow bubble was even still attached to Android’s window manager.

It was just invisible and impossible to touch.

The failure state

This happened with Wispr Flow 2.3.1 on Android 16. The important window-manager fields looked like this:

window type: APPLICATION_OVERLAY
requested size: 263 x 263
alpha: 0.0
shown alpha: 0.0
flag: NOT_TOUCHABLE

That is a nasty failure mode because almost every normal health check says the app is fine. Reinstalling, randomly toggling permissions, or blaming Android’s process killer would have missed the actual condition.

The reliable test was not “is the permission enabled?” It was:

Is the real overlay window attached, visible, nontransparent, on screen, and touchable while a harmless editor has an active input connection?

In this case the answer was no.

Wispr’s own Android documentation says the Flow bubble depends on both display-over-other-apps permission and its Accessibility Service. Those prerequisites were present here. The broken state was one layer deeper: the overlay lifecycle had produced an attached but inert window. The official Android setup guide and Flow overview explain the intended permission stack and bubble behavior.

What restored it

The recovery had to account for an Android 16 behavior that can make a careless fix destructive: force-stopping Flow removes Flow’s component from the enabled Accessibility Service list.

So the recovery order was:

1. Capture the complete enabled Accessibility Service list.
2. Refuse to proceed if the phone identity, editor state, overlay permission, microphone state, or non-Flow service baseline is unsafe.
3. Confirm the same fault twice, 20 seconds apart.
4. Force-stop only Wispr Flow.
5. Verify every non-Flow accessibility component survived, normalizing Android’s short and fully qualified component-name formats.
6. Reinsert only Flow’s accessibility component.
7. Launch Flow, return to the original editor, and inspect the actual bubble window again.

The repaired window read:

alpha: 0.8
shown alpha: 0.8
on screen: true
visible: true
touchable: true
requested size: 263 x 263

It held that state in a second check 20 seconds later. The microphone remained idle, and every other accessibility service remained enabled.

I added a watchdog because this was not a one-off

I have now seen the Flow affordance disappear on both a TCL phone and this Pixel. A manual repair is useful; a recurring input failure needs a guarded recovery loop.

The Pixel now has an isolated, device-bound watchdog modeled after the one I built for the TCL. It requests a safe check on a nominal three-minute schedule and after boot/unlock events. September 5 correction: Android can defer that alarm, and a requested check can fail before reaching Wispr; see the update above. It does not type, record audio, or touch arbitrary apps. It refuses to repair while the phone is locked, the microphone is active, a sensitive input type is focused, the overlay permission is missing, or the non-Flow accessibility baseline cannot be proven.

It also has:

• two-sample fault confirmation
• a 10-minute cooldown
• a maximum of six recoveries per day
• concurrent-run locking and stale-lock recovery
• rollback on accessibility-list mismatch
• device, model, and app-scoped identity binding
• a post-repair requirement that the original editor regain focus and the bubble become visible and touchable

The offline regression suite passed 19 scenarios, including healthy no-op, sleeping and locked devices, sensitive editors, an active microphone, revoked overlay permission, wrong-device refusal, a flapping fault, concurrent workers, stale locks, missing accessibility, a missing bubble, and an inert bubble.

Then I tested it against the real phone. The worker first reported a healthy no-op with all accessibility services unchanged. It later detected the inert bubble, performed one ordered restart, preserved the accessibility list, and logged a verified healthy bubble. When I deliberately injected another fault inside the 10-minute window, it correctly refused a second restart as cooldown instead of entering a repair loop.

That last distinction matters. “The automation ran” is not proof. A useful watchdog needs evidence that it repaired the intended condition, evidence that it preserved unrelated state, and evidence that it knows when not to act.

What Wispr should fix

The product-side fix is smaller than my workaround.

Wispr’s Android watchdog should treat an attached overlay as unhealthy when any of these are true in an active text-input context:

• effective alpha is zero
• shown alpha is zero
• the window is non-touchable
• the overlay is off screen or not visible

When that state survives a short debounce, Flow should rebuild the overlay without requiring the user to toggle permissions or restart the whole app.

The current health model appears to stop too early at “service alive” or “window attached.” An invisible, non-interactive microphone button is not healthy just because Android still has a window record for it.

The practical takeaway

If Flow vanishes on Android, check the actual overlay state before tearing apart the installation:

1. Confirm the app, Accessibility Service, and overlay permission are present.
2. Open a harmless text editor and show the keyboard.
3. Confirm Flow is not actively recording.
4. Inspect whether the overlay is attached but transparent or non-touchable.
5. Preserve the full accessibility list before any force-stop or rebind.
6. Verify the repaired bubble itself, not just the process.

Wispr Flow is still the dictation tool I keep using. That is exactly why this failure is so aggravating: when a tool becomes part of your input system, an invisible button is not a cosmetic bug. It is an outage.