foregroundServiceType="health": permissions, prerequisites and exceptions

A phone app that tracks a walk or run with the screen off needs a foreground service, and from Android 14 that service needs a type. For fitness the type is health. Sources: Google's foreground service types page, the Android 14 type requirement, the launch and declare guides, the background start restrictions, and the ServiceInfo and Manifest.permission references, all read 2026-10-03.

The three names#

Google's description of the type: "Any long-running use cases to support apps in the fitness category such as exercise trackers." The Android 14 page says health is one of the types that "are new in Android 14", and that the per-type permissions "are defined as normal permissions and are granted by default. Users cannot revoke these permissions." You still need the base FOREGROUND_SERVICE permission as well.

The runtime prerequisite#

The service types page says at least one of these must be true:

• Declare the HIGH_SAMPLING_RATE_SENSORS permission in your manifest.
• Request and be granted at least one of: BODY_SENSORS on API 35 and lower, READ_HEART_RATE, READ_SKIN_TEMPERATURE, READ_OXYGEN_SATURATION, ACTIVITY_RECOGNITION.

The ServiceInfo reference for FOREGROUND_SERVICE_TYPE_HEALTH gives a different list: ACTIVITY_RECOGNITION, HIGH_SAMPLING_RATE_SENSORS, READ_HEART_RATE, READ_SKIN_TEMPERATURE, READ_OXYGEN_SATURATION, READ_BLOOD_PRESSURE, READ_HEART_RATE_VARIABILITY, READ_RESPIRATORY_RATE and READ_VO2_MAX, without BODY_SENSORS. The overlap is what both pages agree on, and for a phone step or walk tracker the obvious member is ACTIVITY_RECOGNITION. The BODY_SENSORS line changes on Android 16; see the Android 16 health permissions page.

What Android throws#

On the runtime-prerequisite case Google adds that the exception "prevents the foreground service from starting, might cause a running foreground service to be removed from the foreground process state, and might cause your app to crash." Order matters: "Permissions must be requested and granted before the app attempts to call startForeground()."

Manifest and start#

<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_HEALTH" />
<uses-permission android:name="android.permission.ACTIVITY_RECOGNITION" />

<application>
    <service
        android:name=".WalkTrackingService"
        android:foregroundServiceType="health"
        android:exported="false" />
</application>

// Inside WalkTrackingService.onStartCommand(), after ACTIVITY_RECOGNITION was granted in the UI:
ServiceCompat.startForeground(
    this,
    NOTIFICATION_ID,
    notification,
    ServiceInfo.FOREGROUND_SERVICE_TYPE_HEALTH
)

Google recommends the ServiceCompat form of startForeground(), "available in androidx-core 1.12 and higher". If a session later needs GPS, call startForeground() again with both types, which Google's Android 14 page describes with a running-tracker example; the service must then meet the requirements "of all types".

Starting from the background#

Two rules stack. Apps targeting Android 12 or higher "are not allowed to start a foreground service while the app is in the background, with a few specific exceptions." And BODY_SENSORS-based health services are subject to while-in-use limits: Google says you cannot create one "that uses body sensors while your app is in the background" unless granted BODY_SENSORS_BACKGROUND (API levels 33 to 35) or READ_HEALTH_DATA_IN_BACKGROUND (API level 36). The restrictions page adds that this "doesn't apply if it's a health service that needs different permissions, like ACTIVITY_RECOGNITION", and warns that checkSelfPermission() is no guide here, because for a while-in-use permission it "returns PERMISSION_GRANTED even if the app is in the background."

Play Console#

"If your app targets Android 14 or higher, you'll need to declare your app's foreground service types in the Play Console's app content page (Policy > App content)." The policy itself is out of scope here; the compliance section covers store rules.

Pitfalls#

• Declaring the type but not the permission. Two separate manifest entries, two separate failures.
• Requesting the runtime permission after startForeground(). Ask first; the system checks at start.
• Trusting checkSelfPermission() from the background. For while-in-use permissions it reports what the app has while in use.
• Passing a type the manifest lacks. IllegalArgumentException.
• Reading one list of prerequisites as complete. The guide and the ServiceInfo reference differ; design for the overlap.

On Wear OS, Google's Health Services guide declares android:foregroundServiceType="health|location" for exercise recording; that side is on Wear OS exercise tracking.