public abstract class WorkoutSession

A workout being recorded.

Obtained from WorkoutManager.startSession(WorkoutConfiguration). The state machine, the elapsed clock and the rollup of fed samples live here in shared code; ports implement only the do* methods.

Live and recorded sessions

isLive() tells you whether the operating system is running a real workout session – keeping the app alive and collecting sensor data itself. It is false everywhere in this release: the only implementation here is a recorded session, and WorkoutManager.isLiveSessionSupported() says so on every platform. HKWorkoutSession on watchOS and iOS 26, and the Wear OS exercise client, are what would change that answer; nothing here drives them yet. Do not assume the OS keeps your app alive or collects data for you – backgrounding can end the process and take the session with it.

On an Android phone it could not be live in any case, because Health Connect has no such concept: Google’s documented approach there is to record the session yourself and write it when it ends, which is exactly what a recorded session does. So a recorded session is not a degraded shim – it is the platform-correct design – but it does mean nothing is collected unless you feed it, through addSamples(List) or by attaching a Bluetooth sensor with SensorSessionOptions.setWorkoutSession(WorkoutSession).

Check WorkoutManager.isSensorCollectionSupported() before building UI that assumes a heart rate will appear on its own.

A killed workout is over

Sessions are deliberately not restored after the process dies. end() was never called, so nothing is written. An app that needs crash-resilient workouts should write partial records as it goes – which is what the recorded path does anyway.