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.
Sources and further reading
- Android Developers: Foreground services
- Android Developers: Background work overview
- Android foreground-service changes by version
Reference review: 22 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
