Handle Screen Lock During Offline Audio Recording

Direct answer

A screen lock is a lifecycle test point, not proof that recording must continue or must stop. The correct result depends on the feature’s user promise, how recording started, microphone permission, service declaration, Android version and target SDK, and any audio-focus or capture behavior in the app. For a microphone foreground service, the app must meet the applicable service-type and permission rules; Android also restricts starting while-in-use microphone services from the background. A developer should test the user-visible path from start to lock and record what the app actually does. The first distinction is between an Activity becoming non-visible and the recording owner being stopped. An Activity can pause or stop while a properly owned service continues, but an Activity-bound recorder may be released when the screen lifecycle changes. Neither behavior should be inferred from a single callback. Make a state diagram for permission, ready, recording, paused or interrupted, finalizing, transcribing, and stopped. Ensure that every transition updates the notification or screen and that the microphone is released when the task ends. The second distinction is capture versus transcription. A recording can continue while inference waits, or capture can stop and a saved segment can be transcribed later. These are different product behaviors with different memory, privacy, and interruption boundaries. If the app buffers audio in memory, screen lock, process death, and low-memory conditions can lose the segment; if it writes to local storage, protect the file lifecycle and deletion behavior. Do not use a “recording” indicator when the service is only processing a previously captured file. Test a matrix that varies one condition at a time: user starts recording in the visible screen; user locks the phone; the screen turns off automatically; the app is backgrounded; permission is revoked; the notification stop action is pressed; the process is killed and recreated; the audio source is interrupted by a call or another recorder; and the task is reopened. Capture timestamps, state transitions, recorder result, file existence and duration, finalization status, and whether inference completed. Do not store real meeting contents in the diagnostic log. If recording intentionally stops at lock, tell the user and preserve any completed segment. If it is designed to continue, verify the foreground service and notification under each supported OS configuration and ensure the stop action works. A successful run on one device is evidence only for that device and build. It does not prove every Android phone behaves identically, and a local inference engine does not change microphone rules. This guide gives a test method, not a claim about Cove Voice’s current release behavior. The project source alone does not establish a public app’s lock-screen recording capability. A reviewable test protocol is: 1. Write the intended contract: whether a user-started session continues after locking, whether a notification remains, what can stop the recording, and what data survives interruption. 2. Start from the visible activity, verify permission, service type, foreground notification, and recorder state before locking. Record the OS build and target SDK. 3. Lock and unlock while observing only safe metadata: active state, elapsed time, recorder status, file finalization, and notification actions. Repeat with permission revocation and a competing audio capture. 4. Separate audio finalization from transcription. Reopen the task, verify the expected saved segment, run inference as a new phase, and confirm deletion or retention follows the disclosed policy. 5. Run a process-recreation case. If the session cannot safely resume, show that it stopped and preserve only the portion the app can verify. Acceptance is an explicit, tested user-visible behavior—not the assumption that screen lock leaves a microphone session untouched.

A recording changes state when the display turns off

A user starts an audio note from a visible screen and places the phone in a pocket. Later the transcript is shorter than expected. The engineer needs to determine whether capture stopped at lock, audio finalization failed, a competing app took the microphone, or transcription processed only a saved portion.

Decision

Instrument the pipeline at capture boundaries and repeat the exact sequence on a declared OS and app build before changing the service policy.

Expected outcome

The team can explain whether the recording contract continues, pauses, or stops and can distinguish missing audio from a later transcription failure.

Evidence to collect

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

• Screen and recording state machine
• Lock, unlock, and process-death fixtures
• Audio continuity and user-visible stop behavior

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

Implementation workflow

1. Define expected lock-screen behavior. State whether user-started recording continues after lock, what notification and stop action remain, which interruptions end it, and whether partial audio is retained. If the product does not promise continuation, make that limit visible before the user starts.
2. Record permission and service state before locking. Start from the visible screen, verify microphone permission and any foreground-service type and notification, then capture a timestamped state transition. Do not start a while-in-use microphone service from an unverified background state.
3. Test lock and interruption boundaries. Lock and unlock the display, background the app, revoke permission, press notification stop, and simulate an audio interruption. Change one condition per run and record capture state, finalization, and output-file metadata without saving private speech in logs.
4. Inspect final audio before inference. Verify whether the audio segment exists and was finalized before starting transcription. Run inference as a separate stage, compare the expected segment boundary, and apply the app’s stated retention or deletion rule after the test.

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

Acceptance criteria

• Every tested lock path ends in a clear state: continuing, intentionally stopped, interrupted, or failed.
• The recorder releases the microphone after stop, revocation, or failure, and any retained audio follows the disclosed policy.
• A transcript failure is not reported as a capture failure unless the recorded audio stage proves it.

Decision table

Failure patterns to prevent

• Keeping hidden recording active
• Assuming background execution is durable

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 — changes to foreground services
• Android Developers — request runtime permissions
• Android Developers — capture audio input

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

Frequently asked questions