---
title: "foregroundServiceType=\"health\": permissions, prerequisites and exceptions"
canonical: "https://aifitnessapi.com/phone-sensors/foreground-service-type-health"
cluster: "Phone Sensors"
primary_query: "foregroundServiceType=\"health\""
last_reviewed: "2026-10-03"
description: "Declaring a health foreground service on Android 14+: the manifest type, FOREGROUND_SERVICE_HEALTH, runtime prerequisites, and each exception it can throw."
publisher: "AIFitnessAPI — independent, not sponsored"
cite_as: "\"foregroundServiceType=\"health\": permissions, prerequisites and exceptions\", AIFitnessAPI, https://aifitnessapi.com/phone-sensors/foreground-service-type-health"
---

# foregroundServiceType="health": permissions, prerequisites and exceptions

> From Android 14 (API level 34), a foreground service that tracks a workout declares android:foregroundServiceType="health" in the manifest, holds the FOREGROUND_SERVICE_HEALTH permission, and passes FOREGROUND_SERVICE_TYPE_HEALTH to startForeground(). Google's runtime prerequisite is that the app either declares HIGH_SAMPLING_RATE_SENSORS or has been granted at least one of BODY_SENSORS (API 35 and lower), READ_HEART_RATE, READ_SKIN_TEMPERATURE, READ_OXYGEN_SATURATION or ACTIVITY_RECOGNITION. Google documents what happens otherwise: a missing manifest type raises MissingForegroundServiceTypeException, a missing type permission or unmet runtime prerequisite throws SecurityException, and passing a type the manifest does not declare throws IllegalArgumentException.

- Canonical: https://aifitnessapi.com/phone-sensors/foreground-service-type-health
- Last reviewed: 2026-10-03
- Publisher: AIFitnessAPI (https://aifitnessapi.com) — independent, not sponsored
- Cite as: "foregroundServiceType="health": permissions, prerequisites and exceptions", AIFitnessAPI, https://aifitnessapi.com/phone-sensors/foreground-service-type-health

---

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](https://developer.android.com/develop/background-work/services/fgs/service-types) page, the [Android 14 type requirement](https://developer.android.com/about/versions/14/changes/fgs-types-required), the [launch](https://developer.android.com/develop/background-work/services/fgs/launch) and [declare](https://developer.android.com/develop/background-work/services/fgs/declare) guides, the [background start restrictions](https://developer.android.com/develop/background-work/services/fgs/restrictions-bg-start), and the `ServiceInfo` and `Manifest.permission` references, all read 2026-10-03.

## The three names

| Where | Value |
| --- | --- |
| Manifest attribute | `android:foregroundServiceType="health"` |
| Manifest permission | `android.permission.FOREGROUND_SERVICE_HEALTH` (API level 34, protection level normal) |
| Constant for `startForeground()` | `ServiceInfo.FOREGROUND_SERVICE_TYPE_HEALTH` (value 256) |

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](/phone-sensors/android-16-body-sensors-health-permissions).

## What Android throws

| Situation | Documented result | Source |
| --- | --- | --- |
| Service has no type in the manifest, and none passed | `MissingForegroundServiceTypeException` on `startForeground()` | Android 14 change page; declare guide |
| `FOREGROUND_SERVICE_HEALTH` not declared | `SecurityException` | Android 14 change page |
| Runtime prerequisite not met | `SecurityException` after `startForeground()` | Android 14 change page; launch guide |
| Type passed that the manifest does not declare | `IllegalArgumentException` | Launch guide |
| Starting from the background on Android 12+ without an exemption | Not allowed; Google's sample catches `ForegroundServiceStartNotAllowedException` | Launch guide |

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

```xml
<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>
```

```kotlin
// 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](/compliance) 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](/watch-apps/wear-os-exercise-tracking).

## FAQ

### What exception does Android throw when a health foreground service has no type in the manifest?

MissingForegroundServiceTypeException. Google's Android 14 foreground service page says that if an app targeting Android 14 doesn't define types for a service in the manifest, the system raises it when startForeground() is called, and that if no type is passed at runtime the type defaults to the manifest's. Declare android:foregroundServiceType="health" on the service element. A missing FOREGROUND_SERVICE_HEALTH permission is a different failure, a SecurityException.

[Permalink](https://aifitnessapi.com/phone-sensors/foreground-service-type-health#faq-1)

### Is FOREGROUND_SERVICE_HEALTH a runtime permission?

No. The Manifest.permission reference lists FOREGROUND_SERVICE_HEALTH with protection level normal, added in API level 34, and Google's Android 14 page says the per-type foreground service permissions are normal permissions, granted by default, that users cannot revoke. You only declare it. What does need a runtime grant is the type's prerequisite, such as ACTIVITY_RECOGNITION, unless you rely on declaring HIGH_SAMPLING_RATE_SENSORS instead.

[Permalink](https://aifitnessapi.com/phone-sensors/foreground-service-type-health#faq-2)

### Can a step-tracking app run a health foreground service with only ACTIVITY_RECOGNITION?

Google's documentation says yes. ACTIVITY_RECOGNITION appears both in the foreground service types page's list of runtime prerequisites for the health type and in the ServiceInfo reference's list for FOREGROUND_SERVICE_TYPE_HEALTH. Google's background-start restrictions page also notes that the while-in-use problem affecting BODY_SENSORS does not apply to a health service that needs different permissions, like ACTIVITY_RECOGNITION. The general Android 12 rule against starting foreground services from the background still applies.

[Permalink](https://aifitnessapi.com/phone-sensors/foreground-service-type-health#faq-3)

### Can I start a health foreground service while my app is in the background?

Usually not. Google's launch guide says apps targeting Android 12 or higher are not allowed to start a foreground service from the background, with a few specific exceptions, and its sample catches ForegroundServiceStartNotAllowedException. For a health service that relies on body sensors there is a second limit: Google says it cannot be created in the background unless the app holds BODY_SENSORS_BACKGROUND on API 33 to 35 or READ_HEALTH_DATA_IN_BACKGROUND on API 36. Start the service while the user is in your app.

[Permalink](https://aifitnessapi.com/phone-sensors/foreground-service-type-health#faq-4)