Match the service to a supported use case
The foreground-service documentation defines types and their requirements. Examples include location, media playback, camera and data synchronization, but each has conditions that should be checked against the current reference.
Do not declare several unrelated types “just in case.” Some types require additional permissions or runtime prerequisites, and a broad declaration can create both technical and policy problems.
Review the four-part contract
| Part | Question |
|---|---|
| Manifest service type | Does it describe the operation actually running? |
| Required permissions | Are the type-specific and feature permissions satisfied? |
| Start context | Is starting from this foreground or background state allowed? |
| Notification and lifecycle | Can the user understand and stop the ongoing work? |
Version-specific changes can introduce additional limits. Record both the device API and target SDK when investigating a failure.
Do not fix a start exception blindly
A foreground-service start failure can mean the app is in a restricted background state, lacks a prerequisite permission or selected an inappropriate type. Adding the base foreground-service permission alone may not solve it.
Capture the exact exception and the event that triggered the start. Compare it with the current type's documented prerequisites before changing the manifest.
Make stopping and recovery explicit
Stop the service when the user-visible work finishes. Persist enough state for a safe retry when the operation is interrupted. Avoid an endless service whose only purpose is preventing process termination.
For deferrable work, review background-work alternatives. A specialized API or WorkManager can be a better fit than forcing the task into a foreground service.
Test the built release
Test permission denial, app backgrounding, user cancellation, process loss and representative OS versions. APKLint can inspect declarations and flag missing or broad settings, but it cannot prove start eligibility at runtime or predict every OEM scheduling decision. Keep the service's user-visible purpose and actual test evidence in the release review.
Review an audio recording service as four connected requirements
Suppose a user starts an audio recording from a visible screen and expects it to continue while switching apps. Confirm the appropriate service type, its manifest permission, the microphone runtime grant and the allowed start context. These checks describe different requirements. Passing one does not automatically satisfy the others, and adding an unrelated type cannot repair a missing microphone grant.
The foreground-service type reference lists each type's prerequisites and restrictions. Camera and microphone types have while-in-use constraints. Review the documented exceptions before assuming a background receiver can start the same service that works from a visible user action.
Make stopping the work release the underlying resources
Test the notification's stop control and the corresponding in-app action. Confirm that recording actually stops, the output is finalized where possible and sensor resources are released. Removing a notification while capture continues is not a completed stop operation. Likewise, a stopped timer in the interface should not hide a service that remains active.
Use a short synthetic recording with a known spoken marker, stop it, then start another containing a different marker. Open both files independently and verify that their duration and content match the separate sessions. Test permission revocation and an interruption during the second session so a previous successful output is not presented as the new recording.
For data synchronization or media processing, choose the type that actually matches the operation and review current time limits and start restrictions. A foreground service is not an unlimited scheduling mechanism. Implement the required completion, failure and timeout cleanup for the supported device and target combinations; do not keep restarting finished work merely to maintain a background process.
Keep notification permission separate from the service's own obligations. The notification guidance explains that the runtime notification grant is not itself required to launch a foreground service, while a service notification is still required. Test the presentation under both granted and denied notification states instead of inferring it from a single development device.
Record the initiating app state, device API, target SDK, service type and observed exception when a start fails. This evidence identifies whether the problem is configuration, access, timing or lifecycle. Fix the relevant contract and rerun the same transition before declaring the service reliable.
Sources and further reading
- Android Developers: Foreground services
- Android Developers: Background work overview
- Android foreground-service changes by version
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
