Foreground Service for Offline Transcription on Android

Direct answer

An offline model does not grant permission to record in the background. A microphone transcription feature must treat user intent, runtime permission, service type, notification, lifecycle, and inference as distinct steps. Android requires the microphone foreground-service type for foreground services that access the microphone on applicable target versions, and newer versions enforce additional permissions and restrictions. Starting a microphone service from the background can fail because microphone permission is a while-in-use permission. The safest design begins recording from a visible user action while the app has the required permission, communicates ongoing capture, and defines what happens when the user stops, locks the screen, revokes permission, or the process is removed. Do not choose a foreground service solely to keep a model warm or to hide a long task. The service must correspond to a user-visible, policy-appropriate task and must comply with current Android platform rules for the target SDK. Persistent background work such as a model download and microphone capture are different jobs with different allowed lifecycle mechanisms. A transcription pipeline may capture audio while a foreground service is active, but the service does not make transcription accurate, offline, resumable, or safe by itself. Those claims need separate evidence for capture, model inference, storage, and any playback. A useful implementation separates a recording session from inference. The service owns the microphone recorder and its notification; a repository or task coordinator owns the session identifier and events; the inference engine receives a bounded audio segment only after the recording stage produces it. Every state change should be observable: waiting for permission, recording, finalizing audio, transcribing, displaying a result, stopped, and failed. Do not keep an open microphone because an inference coroutine is still running. If transcription can continue after capture ends, persist only the minimum task metadata needed to complete or recover it. Test platform boundaries on the minimum and target SDK configurations that the product supports. Start from a visible activity, grant and deny permission, start the service, lock the screen, switch apps, stop through the notification, revoke permission, and recreate the process. Record which transitions preserve capture, which intentionally stop it, and what the user sees. Do not generalize one emulator or phone run to every device. A failure to start from background should be diagnosed against platform restrictions before adding exemptions or a second service. Never request microphone permission at app launch if no user action yet needs it. This guide is an architecture and verification method. It does not say Cove Voice has a finished background-recording feature or that a public Cove release can transcribe while the screen is locked. The repository currently describes Cove Voice as in progress; public distribution and behavior must be verified separately. Use this sequence: 1. Define the user promise: whether recording is explicitly started by the user, whether it continues while the screen is locked, what notification and stop control remain visible, and which interruption ends the task. 2. Declare the service type and permissions for the target SDK using the current Android documentation. Request RECORD_AUDIO in the feature context, handle denial, and do not attempt to create a while-in-use microphone service from a background state unless a documented exemption applies. 3. Implement and test state ownership. Keep recorder lifecycle in the service, communicate session events through an app-owned repository, and keep model inference separate from the capture resource. 4. Run acceptance tests for permission grant and denial, visible start, screen lock, app switching, notification stop, process recreation, audio finalization, inference completion, cleanup, and a new session after failure. A service declaration is not evidence of an uninterrupted recording promise. Publish only the transitions that the exact app version reproduces.

A user begins a long recording and locks the phone

A user presses Record in a visible transcription screen, grants microphone permission, and then locks the device while waiting for a private meeting transcript. The team needs to decide which component owns capture and what interruption behavior to disclose.

Decision

Start capture from the visible user action, use a properly declared microphone foreground service only where platform policy requires it, and define an explicit stop or resume boundary for each lifecycle event.

Expected outcome

The app displays a clear ongoing state and stop action; test records distinguish capture, audio finalization, and transcription instead of claiming a single background feature.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Service and task state machine
• Background and process-death fixtures
• Stop, cleanup, and recovery outcomes

A runtime comparison is publishable only when artifact identity, build configuration, selected backend, task fixture, and failures are recorded.

Implementation workflow

1. Specify user-visible recording behavior. Write when recording may start, which controls remain available, whether lock-screen capture is expected, how interruption is reported, and what data remains after a stop. Do not infer these promises from a service manifest entry.
2. Request microphone access in context. Ask only after the user chooses a feature that needs the microphone. Check permission at use time, explain the feature impact if denied, and provide a graceful path that does not keep requesting after a clear denial.
3. Separate capture, inference, and persistence. Let the recording owner manage the microphone and foreground notification. Emit a session identifier and state events to the app layer, then send a completed bounded audio segment to inference. Avoid tying native inference lifetime to an open recorder.
4. Exercise lifecycle transitions. Test visible start, lock, app switch, notification stop, permission revocation, process recreation, audio finalization, inference completion, cleanup, and a new recording after failure. Repeat on declared target SDK configurations and preserve the exact outcomes.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• The recording begins only through a documented user-visible path with the required permission.
• The service notification and stop action remain coherent for the tested lifecycle path.
• Capture interruption, transcription, cleanup, and recovery are reported as distinct states.

Decision table

Failure patterns to prevent

• Keeping a hidden recorder active
• Calling a service durable completion by itself

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• Android persistent background work
• Android Developers — declare foreground services and request permissions
• Android Developers — restrictions on starting a foreground service from the background
• Android Developers — capture audio input

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions