Android 14 made foreground services declare what they are for, and skipping the declaration breaks your app at runtime and can block your Play submission. If your app targets Android 14 or higher and runs a foreground service, you must say which type of work it does in the manifest, request a matching permission, and declare the types in Play Console with a justification. Miss the permission and the system throws an exception when the service starts; miss the Play declaration and the update is rejected. Here is what changed, the declaration requirements, and how to comply.
Short answer
Apps targeting Android 14 (API level 34) or higher that use a foreground service must declare a foreground service type for each one. Per Android's documentation, you set an android:foregroundServiceType on each foreground service in the manifest and declare and request the matching permission for that type, for example declaring the camera type requires the FOREGROUND_SERVICE_CAMERA permission; calling startForeground without the right type permission throws a SecurityException. Separately, Google Play requires you to declare your foreground service types in Play Console with a description, the user impact, and a demo video justifying them by a user-initiated, perceptible use. So declare the type in the manifest, request the permission, and justify it in Play Console.
What you should know
- Foreground services need a type on Android 14+: declared per service.
- A matching permission is required: per foreground service type.
- Missing it throws at runtime: a SecurityException when the service starts.
- Play requires a declaration too: in Play Console, with justification.
- Justify by user-perceptible use: foreground services are for visible work.
What changed in Android 14?
Foreground service types became mandatory, with a permission and a Play declaration. A foreground service is one that keeps running with a visible notification, for ongoing, user-aware work like media playback or location during navigation, and Android 14 requires apps targeting it to declare what kind of work each foreground service does. In your manifest, each foreground service element must set an android:foregroundServiceType attribute identifying its purpose, and you must declare and request the foreground service permission that corresponds to that type. The system enforces this: if you call startForeground without having declared the appropriate type permission, it throws a SecurityException, so the service simply will not start. Google added this to ensure foreground services are used for legitimate, perceptible tasks rather than as a way to keep doing background work, which is why Play also requires you to justify the types you use.
What are the declaration requirements?
A manifest type, a matching permission, and a Play Console declaration. The table summarizes them.
| Requirement | What you do |
|---|---|
| Manifest service type | Set android:foregroundServiceType on each foreground service |
| Matching permission | Declare and request the FOREGROUND_SERVICE permission for that type |
| Correct type for the work | Choose the type that matches what the service does |
| Play Console declaration | Declare your foreground service types with a justification |
| Justification and demo | Describe the user impact and provide a demo video |
The manifest and permission are the runtime requirements: for each type, like camera, location, or media playback, you set the type on the service and request the corresponding FOREGROUND_SERVICE permission, or startForeground fails. The Play Console declaration is the policy requirement: for apps targeting Android 14 or higher, you declare the foreground service types you use, with a description, the user impact, and a demo video showing the user-initiated, perceptible action that justifies each one. Both must be satisfied for the app to run and to pass review.
How do you comply?
Match each service to a type, request the permission, and justify it. For each foreground service in your app, choose the foreground service type that accurately reflects the work it does, set that android:foregroundServiceType in the manifest, and declare and request the corresponding foreground service permission so startForeground succeeds. Use the type that genuinely matches the task, since a mismatched or unjustified type invites problems. Then complete the foreground service declaration in Play Console for your app targeting Android 14 or higher, describing what each service does, its user impact, and providing a demo video of the user-initiated, perceptible behavior that justifies it. Where a task does not need a foreground service, prefer a background-work mechanism like WorkManager instead, since foreground services are meant for ongoing, user-aware work. The goal is that each foreground service has an accurate, justified type and the permission to match.
What to watch out for
The first trap is calling startForeground without declaring the type permission, which throws a SecurityException and breaks the service on Android 14 or higher. The second is skipping the Play Console foreground service declaration, which can get your update rejected. The third is using a foreground service for work that should be a background task, which the type system and justification requirements discourage. This is a platform compliance and correctness matter rather than a binary-security one, so it sits apart from a pre-submission scan such as PTKD.com (https://ptkd.com), which reads the binary against OWASP MASVS for security; the service-type declarations you handle in your manifest and Play Console.
What to take away
- Apps targeting Android 14 or higher must declare a foreground service type for each foreground service in the manifest and request the matching FOREGROUND_SERVICE permission, or startForeground throws a SecurityException.
- Google Play separately requires declaring your foreground service types in Play Console with a description, user impact, and a demo video justifying a user-perceptible use.
- Choose the type that accurately matches each service's work, request the permission, and justify it; prefer background-work mechanisms where a foreground service is not needed.
- This is a compliance and correctness matter handled in your manifest and Play Console, separate from the binary security a pre-submission scan such as PTKD.com checks.
