--- title: "Wear OS Health Services for Live Workout Data (2026)" canonical: "https://aifitnessapi.com/devices/wear-os-health-services" cluster: "Connected Devices" primary_query: "wear os health services live workout data" last_reviewed: "2026-08-14" description: "ExerciseClient for rapid updates during a workout, PassiveMonitoringClient for infrequent ones, and when to pair a BLE sensor directly instead." publisher: "AIFitnessAPI — independent, not sponsored" cite_as: "\"Wear OS Health Services for Live Workout Data (2026)\", AIFitnessAPI, https://aifitnessapi.com/devices/wear-os-health-services" --- # Wear OS Health Services for Live Workout Data (2026) > Health Services is the platform service on Wear OS 3 and later that sits between your app and the watch's sensors and algorithms, so you ask it for metrics rather than reading hardware yourself. Use ExerciseClient for an active workout: it manages the workout, sets exercise goals, reports exercise state updates, and delivers rapid data updates while exercise is in progress, across metrics Google lists as heart rate, distance, calories, elevation, floors, speed, pace and more. Use PassiveMonitoringClient for the long-lived, low-frequency case, which Google describes as suited to experiences where data updates are relatively infrequent. Google states that Health Services conserves battery using sensor configurations optimized for power efficiency, and verifies data consistency across all applications on the same device by using standardized platform computations. You would still pair a Bluetooth sensor directly when the signal has to come from hardware the watch does not contain, or when the same code has to run on phones and in a browser. - Canonical: https://aifitnessapi.com/devices/wear-os-health-services - Last reviewed: 2026-08-14 - Publisher: AIFitnessAPI (https://aifitnessapi.com) — independent, not sponsored - Cite as: "Wear OS Health Services for Live Workout Data (2026)", AIFitnessAPI, https://aifitnessapi.com/devices/wear-os-health-services --- On Wear OS the mistake mirrors the one people make on watchOS: reaching for the health data store and wondering why the numbers arrive slowly. Health Connect on the phone is a store. The live path on the watch is Health Services, and it is not a thin sensor wrapper — it is a platform service that owns the sensors and the algorithms on top of them. ## What sits between you and the sensor Google describes Health Services on Wear OS 3 and later as an intermediary between apps and the device's sensors and algorithms. You do not open a heart rate sensor and integrate accelerometer samples into a pace figure yourself; you tell Health Services what you want and it decides how to produce it. Two claims Google makes about that arrangement are worth reading as design constraints rather than marketing. The first is battery: Health Services "conserves battery by using sensor configurations from Health Services that are optimized for power efficiency." The second is consistency: it "verifies data consistency across all applications on the same device by using standardized platform computations." That second one matters more than it looks. If two apps on the same watch each computed calories their own way from raw sensor data, a user would see two different numbers for the same run and would reasonably conclude one of the apps is broken. Standardized platform computations mean the watch answers the question once. The cost is that you are consuming the platform's answer rather than your own, which is a real constraint if a differentiated metric is your product. ## ExerciseClient: the active-workout path `ExerciseClient` is the API for a workout that is happening now. Google's description of it covers managing workouts, setting exercise goals, listening for exercise state updates, and receiving rapid data updates during active exercise. The metrics list Google gives is "heart rate, distance, calories, elevation, floors, speed, pace, and more." Three parts of that are easy to skim past. *Exercise goals* means the platform can tell you when a target is reached rather than you polling and comparing — a distance goal or a duration goal is something Health Services tracks on your behalf. *Exercise state updates* means the session has a lifecycle you subscribe to, and your UI should follow that lifecycle rather than assume it. And *rapid updates during active exercise* is the phrase that answers the question this page exists for: the high-frequency path is a property of being in an exercise, exactly as it is on watchOS with a workout session (see [live heart rate on Apple Watch](/devices/apple-watch-live-heart-rate) for the parallel). ## PassiveMonitoringClient: the everything-else path `PassiveMonitoringClient` is the other half. Google's framing: you use it to "receive updates about a data type or an event," and it "is suited for long-lived experiences where data updates are relatively infrequent." That is the client for a background step count, a daily activity ring, a passive heart rate trend, or an event you want to react to without holding an exercise open all day. The choice between the two clients is not a preference; it is a statement about whether the user is doing a workout right now. Holding an exercise session open to get frequent updates for an ambient feature is the kind of decision that shows up in battery complaints and in store reviews rather than in your test suite. A useful rule of thumb, offered as judgement: if the user tapped "start," you want the exercise client, and when they tap "stop" you should stop wanting it. ## Where the store fits Health Services gives you live data. Health Connect on the phone is where records land and where other apps read them from, and it is a separate integration with separate permissions — [integrating Health Connect](/integrate/google-health-connect) covers that side. Getting a workout onto the watch screen and getting it into the user's phone-side health record are two pieces of work, and a plan that assumes one implies the other will discover the gap late. ## When you would still pair a BLE sensor directly Health Services is the right default on Wear OS, and there are three situations where it is not enough. The first is hardware the watch does not have. Cycling power and cadence come from sensors on the bike, not the wrist, and they arrive over the SIG-standard Cycling Power (0x1818) and Cycling Speed and Cadence (0x1816) services — see [cycling sensors for power and cadence](/devices/cycling-sensors-power-cadence). Gym equipment reports through the Fitness Machine Service (0x1826), covered in [FTMS](/devices/ftms-fitness-machine-service). No platform service on the watch can conjure those. The second is a chest strap the user already owns and prefers. That is a standard Heart Rate service (0x180D) connection, described in [Bluetooth heart rate monitors](/devices/bluetooth-heart-rate-monitor). On placement and sensor type: they genuinely differ between a wrist optical sensor and a strap, and we will not publish accuracy numbers for either — measure it for your own use case. The third is portability. Health Services code runs on Wear OS. A direct BLE integration against the standard GATT profiles is the same conceptual work on [iOS](/devices/ios-ble-fitness-devices), on Android phones, and — on Chromium browsers only — [in the browser](/devices/web-bluetooth-fitness). If one implementation has to serve several surfaces, the standard profiles are what ports. ## Testing it Live sensor behavior on a watch is not something a unit test reaches. Put a seam between the Health Services callbacks and your aggregation logic so recorded update streams can drive the pipeline without hardware, keep the arithmetic behind that seam pure, and reserve real watches for a device pass. The general pattern is in [testing BLE fitness device integrations](/devices/testing-ble-fitness-devices) and [the device lab and CI](/test/device-lab-and-ci); [mocking wearable data](/test/mock-wearable-data) covers making the fixtures ugly enough to be worth running. ## FAQ ### Should a Wear OS app use ExerciseClient or PassiveMonitoringClient for heart rate? It depends on whether a workout is in progress. Google describes ExerciseClient as the API for managing workouts, setting exercise goals, listening for exercise state updates and receiving rapid data updates during active exercise, with metrics including heart rate, distance, calories, elevation, floors, speed and pace. PassiveMonitoringClient is for receiving updates about a data type or an event, and Google says it suits long-lived experiences where data updates are relatively infrequent. So an exercise the user explicitly started uses the exercise client, and an ambient all-day feature uses passive monitoring. Holding an exercise open to get frequent updates for a background feature is the classic battery mistake. [Permalink](https://aifitnessapi.com/devices/wear-os-health-services#faq-1) ### What does Health Services on Wear OS do about battery and cross-app consistency? Google makes two specific claims. On power, Health Services conserves battery by using sensor configurations that are optimized for power efficiency, which is one of the main arguments for going through the platform service rather than approaching sensors yourself. On consistency, it verifies data consistency across all applications on the same device by using standardized platform computations. The practical effect is that two apps on the same watch report the same figure for the same activity, so a user does not see two contradictory calorie counts and assume one app is broken. The trade is that you are consuming the platform's computation rather than your own. [Permalink](https://aifitnessapi.com/devices/wear-os-health-services#faq-2) ### Does Wear OS Health Services replace pairing a Bluetooth sensor to the watch? For anything the watch itself senses, it generally should be your default. It does not help for signals that come from hardware the watch does not contain, such as cycling power or cadence from bike-mounted sensors, or data from gym equipment reporting over the Fitness Machine Service. It also does not help when a user prefers a chest strap they already own, or when you need one implementation that also runs on iOS, on Android phones, or in a Chromium browser, since the standard Bluetooth GATT profiles are what port across those surfaces. Many products end up doing both: Health Services for wrist metrics, direct Bluetooth for external sensors. [Permalink](https://aifitnessapi.com/devices/wear-os-health-services#faq-3)