Wear OS Ongoing Activity for Workout Tracking

A Wear OS workout app has a problem the phone version does not: the watch face wins. Left alone, the system goes back to it, and the app tracking the run is no longer what the user sees when they lift their wrist. Ongoing Activity is the mechanism for telling the system that something is still happening.

What Google documents#

Google's documentation states that "as of Wear OS 7, the solution is to pair an ongoing notification with an OngoingActivity, or a Live Update notification. This lets the device display information about the long-running activity across the user interface, enabling features like the tappable icon at the bottom of the watch face."

On the behavior that matters most for a workout, Google documents that "an ongoing activity or Live Update also keeps your app visible for longer, preventing the system from returning to the watch face after a period of inactivity."

The activity also surfaces in the Recents section of the global app launcher, which is the second documented route back into a session already in progress.

Google documents appropriate use of this as a requirement under the Wear OS App Quality guidelines. For a workout tracker that is not a polish item — it is the kind of thing a quality review can hold against you.

The shape of the thing#

The unit is a pair, not a single object: an ongoing notification, plus an OngoingActivity attached to it. That has a consequence teams tend to discover in QA.

Because the carrier is a notification, everything on the Android permission side applies. Google's wording for POST_NOTIFICATIONS covers "non-exempt (including Foreground Services (FGS)) notifications," and a denial means, in Google's words, that "all notification channels are blocked, except for a few specific roles." A user who declined your notification permission is a user whose workout may not get the surface you designed the whole session experience around. Handle that as a supported configuration rather than an edge case — push notifications for a fitness app covers the permission model and exactly what a denial takes with it.

What it is not#

It is not a data source. Ongoing Activity is about presence and navigation: keeping the app on screen, putting a tappable icon on the watch face, keeping the session reachable from Recents. The exercise data comes from Health Services on Wear OS, which is a separate concern with its own lifecycle — see Wear OS Health Services.

It is not a tile or a widget. Those are ambient surfaces that exist whether or not anything is happening. An ongoing activity exists only while the activity does, and that difference should drive what you put in each.

It is not a Live Activity. iOS Live Activities are a dedicated framework with their own surfaces and update paths, and nothing ports between them. See Live Activities for workout tracking for what the other platform gives you, and treat the two as parallel implementations of a shared product idea rather than one feature behind two SDKs.

Designing the session lifecycle around it#

The interesting engineering is not in creating the ongoing activity. It is in knowing precisely when it should end.

Start it when the session starts, not when the screen appears. If a user can begin a workout from a tile, a complication, or the paired phone, the ongoing activity belongs to the session object, not to a particular UI entry point.

End it on every terminal path. Completed, cancelled, discarded, crashed — and the awkward one, abandoned. Somebody who takes the watch off mid-run and never comes back should not find a tappable icon on their watch face the next morning.

Decide what abandoned means before you ship. This is a policy question rather than a platform question, and it is the same question the iOS side has to answer about a stale Live Activity. Our judgement is to define it in terms of the data — no sensor samples and no user interaction for a defined window — rather than by wall clock alone, because a long slow hike is not the same thing as a forgotten session.

Keep the content current and small. The surface exists to answer two questions: is it still going, and where do I tap. Elapsed time plus one primary metric is the whole brief.

Battery, honestly#

Anything that keeps an app visible and updating on a watch is competing for the battery. We are not going to quote consumption figures, because we have not measured them and neither had most of the sources that publish them.

What is safe to design by: update the ongoing activity at the cadence a human can perceive rather than the cadence your sensors emit, keep the data pipeline separate from the presentation pipeline so you can change one without disturbing the other, and let Health Services own the sampling decisions it was built to own rather than reimplementing them above it.

A test matrix worth writing down#

Permission granted and permission denied, because those are effectively two different products.

Session started on the watch versus started on the phone, since the ongoing activity has to belong to the session either way.

Watch face visible, launcher open, and app in the background — the three states the documented behavior is actually about.

Every terminal path, including the ones happy-path testing never reaches.

An app update in the middle of a session, because a workout can outlive a process.

Verify all of this against Google's current Wear OS documentation before building. This part of the platform has changed across releases, and the Wear OS 7 wording quoted above is what Google documents as of this page's review date.