Foreground service types on Android in 2026: picking the one your feature actually qualifies for

Starting a foreground service used to be one line and a notification. It isn’t anymore. Every foreground service on a current target SDK has to declare a type in the manifest, request the matching permission, and in a couple of cases justify its own existence to Google before the app ships. None of that is bureaucracy for its own sake — each type carries a different lifetime guarantee, and picking the wrong one is how a feature that worked fine in testing gets silently killed on a real device weeks later. Here’s how to actually choose, using the decision Mintly’s focus timer had to make as the running example.

Why “just start a foreground service” stopped working

The old model was permissive: call startForeground(), show a notification, and the system mostly left you alone as long as the notification stayed visible. That made foreground services a magnet for abuse — a “sync” service that never synced, a “listening” service that just kept the process alive. The platform’s answer has been to tie every foreground service to a declared type, each with its own permission and its own contract about how long it’s allowed to run unsupervised. You don’t get to say “trust me, this is important.” You say which kind of important, and the system enforces the rest.

<service
    android:name=".timer.FocusSessionService"
    android:foregroundServiceType="specialUse"
    android:exported="false">
    <property
        android:name="android.app.PROPERTY_SPECIAL_USE_FGS_SUBTYPE"
        android:value="active-focus-timer" />
</service>

Skip the type declaration and the service simply won’t start on a current target SDK — startForeground() throws, not warns.

The types that actually fit most indie features

The curated list covers cases like camera, microphone, location, phoneCall, mediaPlayback, and connectedDevice — each tightly scoped to what it sounds like, each gated by a permission that maps to the real capability (FOREGROUND_SERVICE_CAMERA needs CAMERA, and so on). If your feature is genuinely playing audio or streaming from a wearable, the type is obvious and the permission is one you probably already hold.

The two worth understanding in more depth are the ones that don’t map to a single sensor: dataSync and specialUse.

dataSync is for a background transfer with a clear finish line — uploading a backup, pulling a remote update. It’s not a resting state; as of Android 15, dataSync and mediaProcessing services get a cumulative runtime budget of roughly six hours in a rolling 24-hour window. Run past it and the system calls Service.onTimeout(), giving you a short grace period to wrap up before it force-stops the service. That’s a reasonable trade for what the type is for — a transfer that’s supposed to end — and a bad fit for anything meant to sit there indefinitely.

specialUse: the type for everything that isn’t on the list

A 25-minute focus timer isn’t a data sync, isn’t media playback, isn’t tied to a sensor. It’s exactly the gap specialUse exists to cover — a foreground service that’s genuinely time-bound and user-initiated, but doesn’t match any of the named categories. The catch is that you can’t just declare it and move on: the manifest <property> tag requires a subtype string describing what the service does, and Google Play’s app review reads that string. Declare specialUse for something that’s actually a disguised data-sync or a keep-alive hack, and it’s the kind of mismatch that gets flagged during review, not after launch.

For Mintly, the subtype is active-focus-timer, and the Play Console’s foreground service declaration form spells out the same thing in plain English: a running session the user started and is actively watching, ending at a specific time. That’s a straightforward case to justify because it’s true. Writing an honest one-line description of what the service does is time better spent than trying to find a type that avoids review scrutiny.

shortService: built for the burst, not the session

The other type worth knowing is shortService, meant for a foreground service that only needs a couple of minutes to finish something — writing a large export, running a one-off cleanup — for less time than users would tolerate a WorkManager expedited job’s cold start. It comes with a hard runtime cap of about three minutes; the system doesn’t negotiate past it, and the type exists precisely so short-lived work stops abusing dataSync or specialUse to get a longer leash than it needs. If your task predictably finishes in under three minutes, this is the honest type to use. If it sometimes runs long, it’s the wrong one, and you’ll find out in production, not in testing.

Getting the type wrong is a production bug, not a lint warning

The type you declare isn’t metadata Android politely ignores if you’re not confident. Declare dataSync for something that runs eight hours a day and it gets timed out mid-run — a state your app then has to detect and recover from correctly, or the user just sees a stalled feature with no explanation. Declare specialUse without an honest subtype and Play review can reject the update outright, which is a worse launch delay than the ten minutes it takes to pick the right type up front.

The decision reduces to two questions: does this service map to a real capability like camera or mediaPlayback? If not, is the work naturally bounded to minutes (shortService), hours with a clear end (dataSync), or open-ended but user-initiated and actively watched (specialUse, honestly declared)? Answer those before writing the manifest entry, not after the crash report shows up. The type system is annoying to learn once and then it’s just a fact about the platform — the same way Android 16’s Live Updates sit on top of Mintly’s timer service rather than replacing the need to get its foreground service type right in the first place.