Play foreground service types
Every foreground service has to say why it exists, and the reason has to be true.
Recent Android versions require a foregroundServiceType on each foreground service, matching what the service actually does — location, data sync, media playback, camera, microphone, connected device, and so on. Play asks for a justification for the sensitive types, in the same shape as the background-location declaration.
The React Native problem is that you probably did not add the service. Background location, audio playback, download managers, push handling and geofencing libraries all commonly register one, and it arrives in the merged manifest rather than the one you wrote. Your app declares capabilities you have never read.
And a mismatch is not paperwork. On recent Android versions the platform can throw when the service starts, so the wrong type is a crash in a feature rather than a note in a review.
Read the manifest that actually ships
The one in your repository is not it. The merged manifest is your file combined with every library's.
# the merged manifest is the one that ships
find android -path '*intermediates*' -name 'AndroidManifest.xml' | head -1 \
| xargs grep -nE 'foregroundServiceType|<service|uses-permission'
# and which library asked for what
./gradlew :app:processReleaseManifest --info 2>&1 | grep -i 'manifest merger' | head -20For every service that appears, answer one sentence: which user-facing feature stops working if this is removed? That answer is what you will need for Play's declaration, and it is the same question App Review asks about iOS background modes. Auditing what config plugins added.
Where they come from in an RN project
| Library shape | Service type it usually needs |
|---|---|
| Background location and geofencing | location |
| Audio or video playback | mediaPlayback |
| Download or upload managers | dataSync |
| Health and fitness trackers | health |
| Bluetooth and wearable companions | connectedDevice |
| Camera or microphone capture in the background | camera, microphone |
| Push handling that does real work on receipt | usually none; often over-declared |
The last row is the common over-declaration. Handling a push notification rarely needs a long-running foreground service, and declaring one invites a question you would rather not answer.
The Expo trap, again
With continuous native generation, android/ is a build artefact regenerated on every prebuild. Editing the manifest there works locally, vanishes when EAS rebuilds, and produces an identical second rejection.
Express changes in app.json / app.config.js or a config plugin. Anything that only exists in a generated directory does not exist as far as the build server is concerned. Why RN and Expo fail differently.
The permission that travels with it
A location foreground service almost always means ACCESS_BACKGROUND_LOCATION is in the merged manifest, and that carries its own requirements: a Permissions Declaration in Play Console with a written justification and a demonstration video, and Google's expectation that you use the least invasive option that satisfies the use case.
So one library can add a service, a service type, a dangerous permission, a Play declaration obligation and a Data safety row, none of which appear in your diff. Google Play policy for RN apps. · The Data safety form.
The check to run before every submission
- Read the merged manifest. Every
<service>, everyforegroundServiceType, every dangerous permission. - Justify each in one sentence, naming the feature.
- Remove what you cannot justify. An unused declaration is a question you invited.
- Confirm the type matches the behaviour. A
dataSyncservice that reads location is a mismatch that can throw. - Prepare the Play declarations for anything sensitive, video included.
- Re-run this after every dependency change, because that is when the surface moves, not when your code does.
Every step is static, local and deterministic. shipcheck reads the merged manifest, the config plugins and the dependency tree together and reports services with no matching feature, types that do not match observed behaviour, and permissions with no Play declaration prepared — before you build, inside the Claude Code session you already have open. What it checks.
Android revises these requirements, and Play revises the declaration flow. Every claim here links to Google's own documentation. Take the current type list and declaration requirements from those pages rather than from any article.
Questions and answers
What is a foreground service type on Android?
A declaration in the manifest saying why a foreground service runs - location, data sync, media playback, camera, microphone and so on. Recent Android versions require the type to be declared and to match what the service actually does, and Play requires a justification for the more sensitive types.
Why does my React Native app have a foreground service I did not add?
Because a library added one. Background location, audio playback, downloads, push handling and geofencing libraries all commonly register foreground services, and they arrive in the merged manifest rather than in the one you wrote.
How do I see what foreground services my app declares?
Read the merged AndroidManifest under the build intermediates directory, not the one in your repository. The merged file is what ships and is the only place a library's additions are visible.
What happens if the declared type does not match the behaviour?
The platform can throw at runtime when the service starts, and Play can reject the submission or take enforcement action. A mismatch is not a paperwork problem; on recent Android versions it can crash the feature.
Does Play require a justification for foreground service types?
For the sensitive ones, yes. Play Console asks you to declare the use case and can require a demonstration video, in the same shape as the background-location permissions declaration. Check the current requirement in Play Console since Google revises it.
shipcheck. “Play foreground service types.” Baker Ventures LLC, September 6, 2026. https://shipcheck.bakerventuresstudio.com/rejections/play-foreground-service-types/