Foreground Service Location Permission Enforcement Boundary on API 29+

Question

Foreground Service Location Permission Enforcement Boundary
Goal: start a foreground service with the location type on Android 10 (API 29) and later without triggering a SecurityException, while preserving the ability to launch the service from both foreground and background app states.
Constraint: apps targeting API 29+ must declare the normal-level FOREGROUND_SERVICE_LOCATION permission in the manifest when using a location-related foreground service type. The permission is granted at install time, but the exact point at which the platform validates it during the service lifecycle remains unclear.
Uncertainty: it is not documented whether the check occurs when calling startForegroundService(), when calling startForeground(), or only when the app is in the background. OEM-modified Android builds may also apply different enforcement timing or strictness compared with the AOSP baseline.
Questions:

On API 29+, is FOREGROUND_SERVICE_LOCATION enforced at startForegroundService() or at startForeground()?
Does the permission check apply when the app is visibly in the foreground, or only during background service starts?
Do manufacturer-customized Android distributions change the enforcement boundary for this manifest permission?

Tasadduq Burney · Answer

Direct answer
On AOSP Android 10 (API 29) and later, FOREGROUND_SERVICE_LOCATION is enforced when the service is promoted to the foreground, not when startForegroundService() is called. The platform checks the manifest permission during startForeground(id, notification, FOREGROUND_SERVICE_TYPE_LOCATION). If the permission is missing, the rejection typically appears as a SecurityException at promotion time. The check is bound to the foreground service type, so it applies whether the app is visible or in the background.

Confirmed facts

Apps targeting API 29+ must declare android.permission.FOREGROUND_SERVICE_LOCATION in the manifest for a location-type foreground service.
It is a normal permission granted at install time.
It does not replace ACCESS_FINE_LOCATION, ACCESS_COARSE_LOCATION, or ACCESS_BACKGROUND_LOCATION.
A missing permission usually surfaces as a SecurityException when the system rejects the foreground service start or promotion.

Likely behavior, not guaranteed

AOSP validates the permission at startForeground() promotion rather than at startForegroundService().
Enforcement is not limited to background starts; visible apps are subject to the same check.
OEM-customized Android builds may enforce earlier, later, or more strictly than AOSP; AOSP does not publish a uniform manufacturer boundary.

Steps for this case

Declare android.permission.FOREGROUND_SERVICE_LOCATION in the manifest.
Add android:foregroundServiceType='location' to the service component.
Request ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION at runtime if your app needs actual location data.
Call startForegroundService(), then immediately call the API 29+ overload of startForeground() that includes FOREGROUND_SERVICE_TYPE_LOCATION.
Do not delay startForeground(); the system may stop the service if promotion is not prompt.

Verification
On an API 29+ device or emulator, start the service from both visible and background states and inspect logcat around system_server and ActivityManager for denial messages. Repeat on a different OEM device if you suspect manufacturer-specific strictness.

Missing diagnostic detail: share your targetSdkVersion. If it is below 29, this permission requirement may not apply in the same way, and the steps above change.

Foreground Service Location Permission Enforcement Boundary on API 29+