Android foreground service permission — check manifest declarations

A 58-line AndroidManifest.xml comes back with 19 findings — 15 of them errors — the moment an Android developer measures it against what Google Play asks to be declared, rather than against the Android SDK.

That is what the 15 checks in Play Declaration Gap Lint return on the sample manifest shipped with the extension: 17 permissions, 3 services, 58 lines, 19 findings, 15 errors, 4 warnings. All 15 checks fire on that file, naming 14 Play Console surfaces plus one thing that is not a form at all.

Android Lint measures your manifest against the SDK: is the attribute spelled right, is the permission known, is the component exported. It says nothing about the second life a manifest line has — some permissions open a form in Play Console that a human reviewer reads before your update ships. QUERY_ALL_PACKAGES opens the App visibility declaration; MANAGE_EXTERNAL_STORAGE opens All files access; ACCESS_BACKGROUND_LOCATION opens the Location permissions declaration and wants a video of the feature. READ_SMS, READ_MEDIA_IMAGES, the android.permission.health.* family, exact alarms and the advertising ID each have their own answer waiting in the console. None of them stop the build.

One check is different. Since Android 14 (API 34) a foreground service must declare its type, and each type needs its own permission: foregroundServiceType="location" needs FOREGROUND_SERVICE_LOCATION, "camera" needs FOREGROUND_SERVICE_CAMERA, "specialUse" needs FOREGROUND_SERVICE_SPECIAL_USE and a PROPERTY_SPECIAL_USE_FGS_SUBTYPE property inside the same service element. When the permission is missing the app compiles, installs, and throws a SecurityException the first time the service starts. In the sample manifest three services trip exactly that, which is why the run returns 15 errors rather than 12.

This is the failure mode of generated code: an assistant writes the permission the feature needs, not the declaration behind it, and it cannot see which service Play will ask about. The manifest looks finished. The upload is where it is not.

Timing matters this year: Google Play's yearly target API requirement lands on 2026-08-31, when updates have to target API 36. An app sitting on an older target crosses the API 34 and API 35 foreground service rules on the way there, all at once.

The free part is the whole job on one file: open an AndroidManifest.xml, run "Play Declaration Gap: Check this file", and every triggering line is marked in the Problems panel with its line number and the Play surface it belongs to. No key, no limit, no watermark. The identical engine runs in the browser on the product page, so a reviewer without VS Code can paste a manifest; nothing is uploaded. On the clean sample manifest — 44 lines, a <queries> block, a dataSync service with its permission in place — the run returns 0 errors and 1 warning: that service still needs a use case in the foreground service declaration.

The licensed part changes the scope, not the depth: it sweeps every manifest the workspace holds — app module, library modules, the merged manifests SDKs bring in — into a dated playDecl-report.md, one block per manifest, so whoever fills in Play Console reads a file instead of a screenshot. That sweep asks for a licence key, $29 once, one key per person or CI seat.

For comparison: a freelance Android release engineer bills $60-$120 an hour, and walking a multi-module app's manifests against every current Play declaration is most of a working day.