# Android 14 foreground services: declare the type and permission

> For Android 14 targets, map each foreground service to its type, permission, and runtime prerequisites before release.
> By Dave · 2026-10-11
> Source: https://otf-kit.dev/blog/android-foreground-service-types-api-34

A foreground service can keep certain user-visible work running while an app is not on screen. Starting with Android 14, apps that target API level 34 or higher must declare a type for each foreground service and request the permission that matches that type. If the specific permission is missing, Android can throw a `SecurityException` when the app starts the service.

The fix is not to add a generic type to every service. First identify the work the service actually performs, then make its manifest declaration and permissions agree with that work. Test the release variant at the target SDK you plan to ship.

## What changes at target API 34

Android’s change is conditional on the app targeting API 34 or higher. For those apps, every foreground service needs a declared service type, and the app must request the appropriate permission type for the service’s work. The type-specific permission is in addition to `FOREGROUND_SERVICE`. Android’s example: a camera foreground service needs both `FOREGROUND_SERVICE` and `FOREGROUND_SERVICE_CAMERA`; without the specific permission, an API 34-targeting app gets a `SecurityException`.

That makes the service declaration part of the runtime contract. A manifest entry that only says the app has a foreground service is not enough for a target 34 release. The service’s purpose, its declared type, the permissions in the merged manifest, and the call that starts the service must all describe the same operation.

Older target levels can hide incomplete configuration. A development build that still targets API 33 may start successfully while the release build targeting API 34 fails. Check the target level of the signed variant and inspect its merged manifest rather than relying on a source manifest or a developer’s local run.

## Map each service to the work it performs

Inventory every foreground service in the app before changing XML. Look for service classes, manifest declarations contributed by libraries, and code paths that call `startForegroundService()` or promote a service with `startForeground()`. For each one, record the task it keeps active and the user action that started it.

Use that task to choose the type. Android’s examples distinguish camera access, data synchronization, location work, and microphone capture. A camera type is for continuing camera access, such as a video chat that continues while the user multitasks. A `dataSync` type covers operations such as uploading or downloading, backup and restore, import and export, fetching data, local file processing, or transferring data between device and cloud. A location type covers long-running tasks such as navigation or location sharing. These are examples of specific work categories, not interchangeable labels for any persistent process.

![Dex and Nova match real foreground work to its service type and required permission.](https://cdn.otf-kit.dev/blog/android-foreground-service-types-api-34/inbody-service-type-permission-match-20261011a.png)

If one service genuinely performs more than one category of work, verify which types Android allows for that exact use case and what each requires. Do not add types just because a library supports them or because adding more appears to avoid a startup error. If the service’s work does not fit a documented type, stop and investigate the supported design rather than labeling it inaccurately.

Some tasks may not need a foreground service at all. Android notes that purpose-built APIs are often a better option when they exist. Check the alternatives for the work category before carrying forward a long-running service that is difficult to justify or maintain.

## Align the manifest and permissions

For each service, the manifest should declare its specific type on the service element and include the matching type permission, alongside the base foreground-service permission. For a data transfer service, the shape is:

```xml
<manifest>
    <uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
    <uses-permission android:name="android.permission.FOREGROUND_SERVICE_DATA_SYNC" />

    <application>
        <service
            android:name=".SyncService"
            android:exported="false"
            android:foregroundServiceType="dataSync" />
    </application>
</manifest>
```

Treat this as a pattern to adapt to the service’s real job, not a copy-and-paste declaration for every service. For a camera service, for example, change the type and the type-specific permission to the camera equivalents. Other categories have their own permissions and may have additional runtime prerequisites.

Review the merged manifest for the exact release build. Dependencies can contribute service declarations or permissions, and product flavors can alter the final configuration. Check that the service name in the merged output matches the class you start, that the service is not accidentally declared twice with conflicting attributes, and that every foreground service has a purpose-specific type.

The manifest is only one part of the configuration. Some types require a runtime permission or another prerequisite before launch. Android’s camera example requires the app to request and receive the runtime `CAMERA` permission. A type declaration does not grant that access. Check the service’s prerequisite before starting it and handle a missing grant in the feature flow that needs the camera.

## Diagnose a SecurityException from the release build

When a service fails on Android 14 or later, capture the exception and identify the exact service and call site. Then compare four things:

1. The app’s target SDK in the failing build.
2. The service’s `android:foregroundServiceType` value in the merged manifest.
3. The base and type-specific foreground-service permissions in that same merged manifest.
4. Any runtime permission or other prerequisite for the declared type.

A missing type-specific permission is one documented cause of a `SecurityException` when an app targeting API 34 or higher launches the foreground service. A service with no matching declared type also fails the new requirement. Do not resolve either symptom by catching and suppressing the exception; that leaves the feature’s work unsupported and the actual mismatch hidden.

Test the exact release flavor and target SDK. If your project has multiple Android variants, run the one that matches the Play artifact. Test the service from the real user action, with and without its relevant runtime permission, and confirm the failure path is understandable when access is unavailable. Keep the build variant, target SDK, service name, merged declaration, and exception together in the bug report so the next engineer can reproduce the configuration.

![Luna and Byte review a release build with aligned service declarations and catch a mismatched setup before release.](https://cdn.otf-kit.dev/blog/android-foreground-service-types-api-34/inbody-release-readiness-check-20261011a.png)

## Keep notification permission separate

A foreground service has its own declaration and permission requirements. Android’s notification runtime permission is a separate user-facing control: an app does not need `POST_NOTIFICATIONS` just to launch a foreground service, although it must include the service notification. Keep the two checks distinct when diagnosing a service that fails to start. See the [Android notification permission guide](/blog/android-notification-permission-post-notifications) for the user prompt, target-SDK behavior, and notification outcomes.

## Add a target-SDK release check

Before raising the target to API 34, make a small inventory of every foreground service and review the merged manifest for the release artifact. For each service, document the work it performs, its selected type, the base and type-specific permissions, any runtime prerequisite, and the user flow that starts it. Then launch each service in a device test that targets API 34 or higher and inspect log output if startup fails.

Repeat the review when you add a service, change its purpose, or update a dependency that contributes manifest entries. A passing test on an older target does not prove the API 34 configuration is complete. The useful release gate is whether the exact target-34 build starts each justified service with the declarations and permissions its work requires.

## Sources

- [Changes to foreground services — Android Developers](https://developer.android.com/develop/background-work/services/fgs/changes)