16 · Background operation, interruption, suspension and recovery

Starting state

User explicitly starts local ride while foreground with permissions and selected route; service is active.

Ordered events

1. Android → Service

   Screen/background or focus/route callback arrives

2. Service → Runtime

   Update platform state and local audio enabled state

3. Runtime → Runtime

   Invalidate local PCM epoch while keeping authorized relay if transport remains

4. Service → UI

   Emit sanitized active/interrupted/ready snapshot

5. Android → Service

   Revalidate route/focus before supported audio resume

Fields and messages

Foreground service/audio permissions, route device/session, local enabled epoch, interrupted/audioReady and transport generations.

Authorization and invariants

UI lifetime does not own protocol timers. Remote messages never grant microphone consent. Suspended/killed OS process cannot be claimed to relay.

Timers

Native protocol deadlines remain monotonic; Android scheduling/background policies can terminate availability.

Resource lifetime

Identity/preferences persist across runtime recreation; active ride/session continuity across process death is not promised.

What the rider sees

Screen shows interruption/readiness truthfully; user can retry route or leave.

Failure branches

Lost Aware availability retires resources; a new attach gets new session generation; inability to run in background is a device qualification failure, not silently simulated success.

Resulting state

Supported background service retains native timers/relay; local audio enters interrupted on focus/route loss and resumes only through supported verified recovery.

Evidence boundary

Host interrupted-relay/session retirement, JVM audio route policy, compiled service/runtime instrumentation. Screen-off physical endurance remains unqualified.